[AWS-Security] 5.2. 가상 프라이빗 클라우드 작업

1. 개요

1.1. VPC와 서브넷

• VPC (Virtual Private Cloud) : AWS 네트워킹의 가장 높은 수준에 위치하는 ‘격리된 가상 네트워크’ 공간이다.
• 서브넷 (Subnet) : VPC 내부에 존재하는 개별 ‘하위 네트워크’이다. EC2 인스턴스와 같은 대부분의 네트워크 리소스는 이 서브넷 안에 배치(연결)된다.
• 퍼블릭 vs 프라이빗 : 서브넷 내의 리소스가 퍼블릭 인터넷을 통해 접근할 수 있는지 여부에 따라 서브넷의 종류(퍼블릭/프라이빗)가 나뉜다.

1.2. 내부 트래픽 유지의 중요성 (보안 이점)

• VPC 내의 리소스 간에 통신하는 트래픽은 VPC 외부로 떠나지 않고 내부에서만 라우팅 된다.
• 퍼블릭 인터넷을 경유할 때 발생할 수 있는 Snooping이나 중간자 공격(MiTM) 같은 보안 위협으로부터 안전하다.
• 모범 사례 : 가능하면 트래픽을 외부로 보내지 않고 VPC 내부에 존재하도록 하는 것이 좋다. 이를 위해 VPC 피어링, PrivateLink, Transit Gateway 같은 기능들이 존재한다.

1.3. 이외 기본 네트워킹 요소

• ENI (Elastic network interface) : 네트워크 카드와 동등한 기능을 하는 가상 인터페이스
• EIP (Elastic IP) : 계정에 할당된 Public IPv4 주소
• Internet Gateway : 네트워크가 퍼블릭 인터넷과 통신할 수 있도록 하는 게이트웨이 리소스
• NAT Gateway : 네트워크 내에서 퍼블릭 인터넷에 대한 연결 시작을 허용하지만, 반대는 허용하지 않는 게이트웨이 리소스
• 송신 전용 인터넷 게이트웨이 : NAT Gateway와 동일한 IPv6 트래픽용 리소스

2. VPC

2.1. CIDR Block

• 개념 : 네트워크 구성 목적을 위해 일련의 IP 주소 범위를 간결하게 표기하는 방법(Classless Inter-Domain Routing)이다.
• 표기법 : IP주소/숫자 (ex. 10.0.0.0/24)
  • 앞의 IP 주소는 해당 블록에서 가장 작은(시작) IP를 나타낸다.
  • 슬래시 뒤의 숫자는 ‘네트워크의 크기(가용 IP 개수 범위)’를 나타낸다. 이 숫자가 클수록 네트워크의 크기(가용 IP 개수 범위)는 적어진다.
  • 크기 계산 공식 : 2^(32-n)
    

[CIDR Block 표기 예시]

• 10.0.0.0/24 : 10.0.0.0부터 시작하는 256개의 IP 주소 포함
• 192.168.1.1/32 : 딱 1개의 IP 주소만 해당
• 0.0.0.0/0 : 전체 IPv4 주소 공간(모든)을 의미

2.2. VPC CIDR Block 설정 시 주의 사항

1. 충분한 크기 선택 (EIP 고려)
   • VPC 내의 리소스(EC2 등)는 이 CIDR 범위 안에서 자체 Private IP를 할당 받는다.
   • /24 크기이면 256개의 IP를 사용할 수 있지만, AWS가 Subnet마다 기본적으로 5개의 IP를 자체 사용 목적으로 예약(미리 빼둠)한다.
   • 따라서 실질적으로 251개의 리소스만 넣을 수 있으므로 이를 고려해 넉넉한 크기로 선택해야 한다.
2. Private IP 대역 사용 (충돌 방지)
   • 구글이 쓰는 Public 대역과 똑같이 VPC(ex. 64.233.160.0/24)를 만든다면, 내부에서 통신할지 외부 구글 서버로 나갈지 트래픽 라우팅에 혼란이 생긴다.
   • 따라서 Private 네트워크용으로 약속된 대역(10.0.0.0/16, 172.16.0.0/16 등)을 사용해야 한다.
     (두 개의 VPC를 연결할 때에도 서로 IP 범위가 겹치면 안된다.)

2.3. Default VPC의 위험성

• AWS는 계정 생성 시 모든 리전에 172.31.0.0/16 범위의 Default VPC를 자동으로 생성해 둔다.
  (Public Subnet과 Internet Gateway가 자동으로 세팅되어 있어 EC2를 생성하기 매우 편리하다.)
• 모범 사례 : 이 기본 구성은 가장 안전한 형태가 아닐 확률이 높다. 따라서 실무에서는 Default VPC를 사용하지 않고, 직접 새로운 VPC를 생성하는 것이 원칙이다.

# 신규 VPC 생성 (Subnet과 같은 내부 리소스 제외)
aws ec2 create-vpc \
	--cidr-blcok 10.0.0.0/24

3. Subnet

3.1. Subnet 생성 및 배치

1. 서브넷의 개념과 위치 (리전 vs 가용 영역)
   • 네트워크의 세분화 : 서브넷은 VPC가 가진 전체 IP 주소 범위(CIDR) 중 일부를 떼어내어 만든 더 작은 하위 네트워크이다. 서브넷끼리 IP 범위가 겹쳐서는 안된다.
   • 물리적 위치 : VPC 자체는 넓은 ‘AWS 리전’ 전체를 포괄하지만, 서브넷은 그 리전 안의 특정 ‘가용 영역(AZ, Available Zone)’ 한 곳에 배치된다.
   • 리소스 배치 : EC2 인스턴스는 VPC 공간에 띄울 수 없으며, 반드시 특정 AZ에 만들어진 서브넷 내부에 배치해야 한다.
2. 서브넷 생성

   • 위에서 만든 /24 크기의 VPC를 /26 크기의 더 작은 서브넷 2개를 생성하는 명령어

       # 기존 VPC에 2개의 신규 서브넷 생성
       aws ec2 create-subnet \
           --vpc-id vpc-1234 \
           --cidr-block 10.0.0.0/26  # 10.0.0.0 ~ 10.0.0.63
     			
       aws ec2 create-subnet \
           --vpc-id vpc-1234 \
           --cidr-block 10.0.0.64/26  # 10.0.0.64 ~ 10.0.0.127
     

3. 퍼블릭 서브넷 vs 프라이빗 서브넷
   • 수동 생성 시 기본 값은 ‘프라이빗’ : 위 명령어처럼 사용자가 새로 만든 서브넷은 외부 퍼블릭 인터넷과 연결된 통로가 없다. 즉, 새로 만들어진 상태의 서브넷은 외부와 통신 되지 않는 상태인 ‘프라이빗 서브넷’ 상태이다.
   • 퍼블릭으로 전환하는 방법 : 추후 인터넷 게이트웨이와 라우팅 테이블을 별도로 달아주어야 한다.

   • AWS에서 서브넷의 Public/Private을 결정하는 요소는 서브넷에 연결된 라우팅이다.
   • 0.0.0.0/0 -> IGW의 경로가 있어야 Public Subnet이지만, 기본 생성된 서브넷은 메인 VPC Route table에 의해 local 라우팅 정보만 가지고 있다.

4. 운영 환경을 위한 모범 사례: 멀티 AZ
   • 서브넷을 여러 가용 영역(AZ)에 분산해서 생성하는 것이 필수적이다.
   • 특정 데이터 센터(AZ)에 화재나 정전 등 물리적 문제가 발생해도, 다른 가용 영역(AZ)의 서브넷이 살아있어 애플리케이션의 중단을 방지할 수 있다.

4. 네트워크 인터페이스(ENI) 및 IP (EIP)

EC2 인스턴스를 서브넷에 연결하려면 ‘Elastic IP’라는 매개체가 필요하다.

4.1. ENI (Elastic Network Interface)

• 개념 : 물리적 컴퓨터에 꽂는 ‘네트워크 카드(랜 카드)’와 동일한 역할을 하는 가상 네트워크 인터페이스이다. EC2 인스턴스와 가상 네트워크(서브넷) 사이를 연결하는 역할을 한다.
• 자동 생성 (추상화) : AWS에서 EC2를 생성하면 자동으로 기본 ENI(eth0)를 만들어 인스턴스와 지정한 서브넷에 알아서 연결해 준다.
• 이중 홈(Dual-homed) 인스턴스 : 인스턴스에 추가 ENI를 직접 달아줄 수도 있다. 각 ENI를 서로 다른 서브넷에 연결하여 하나의 EC2가 두 개의 네트워크에 동시에 발을 걸치게(이중 홈) 만들 수도 있다.

4.2. IP 주소와 EIP

ENI는 IP 주소와 리소스를 연결하는 메커니즘이며, IP 주소 자체도 별도의 리소스이다.

• 자동 할당 IP의 한계
  • EC2를 만들 때 AWS가 자동으로 부여하는 Public IP는 인스턴스가 삭제 혹은 중지되면 함께 사라진다.
  • 이 자동 할당 IP는 사용자가 마음대로 제어하거나 다른 곳에 재사용할 수 없다.
• 수동 EIP 생성 (고정 IP)
  • 인스턴스가 삭제 혹은 중지되어도 변하지 않는 고정적인 ‘Public IP’를 유지하고 싶다면, 새 EIP를 수동으로 생성한 다음 인스턴스의 ENI에 연결해야 한다.
  • 이렇게 생성한 EIP는 원할 때 언제든 다른 인스턴스로 유연하게 옮겨 Attach할 수 있다.
• 할당 제한
  • 수동으로 생성할 수 있는 EIP는 계정당 기본 5개로 제한되어 있어, 더 필요한 경우 AWS Support 팀에 Limit 증설을 요청해야 한다.

4.3. 서브넷에 EC2 인스턴스 배치

위에서 생성한 두 개의 서브넷에 각각 EC2 인스턴스를 하나씩 생성한다.

# 1. '퍼블릭 서브넷'으로 지정할 곳에 인스턴스 생성
aws ec2 run-instances \
	--instance-type t2.micro \
	--subnet-id subnet-1234 \    # 첫 번째 서브넷 ID
	--image-id ami-1234 # 사용할 AMI ID

# 2. '프라이빗 서브넷'으로 지정할 곳에 인스턴스 생성
aws ec2 run-instances \
	--instance-type t2.micro \
	--subnet-id subnet-5678 \    # 두 번째 서브넷 ID 
	--image-id ami-1234

위 명령어로 인스턴스는 생성되지만, 아직 인터넷 게이트웨이를 연결하지 않은 상태이다. 따라서, 첫번째 서브넷 이름을 퍼블릭 서브넷이라고 이름을 부여했더라도, 아직 기술적으로 외부와 단절된 프라이빗 서브넷 상태이다.

5. Internet Gateway 및 NAT Gateway

5.1. 인터넷 게이트웨이 (IGW) : 양방향 통신

• 역할 : VPC 내부에 있는 리소스(퍼블릭 서브넷의 EC2 등)가 인터넷으로 트래픽을 내보내고(Outbound), 동시에 외부 인터넷에서도 내부로 들어올 수 있게(Inbound) 해주는 ‘양방향’ 통로이다.
• 특징 : IGW는 특정 서브넷이 아니라 VPC 전체에 연결된다. (Route table에서는 서브넷 단위로 제어)
• 기본 제공 : AWS 계정 생성 시 만들어지는 Default VPC에는 이 IGW가 이미 생성되어 있고 라우팅까지 다 되어 있다.

aws ec2 create-internet-gateway    # 1. IGW 생성
aws ec2 attach-internet-gateway \  # 2. IGW를 VPC에 부착
	--internet-gateway-id igw-1234 \
	--vpc-id vpc-1234

5.2. NAT 게이트웨이 (NGW) : 단방향 통신

• 역할 : Private Subnet에 있는 리소스가 패키지 업데이트(yum, rpm) 등을 위해 ‘인터넷으로 나가는 것(Outbound)’은 허용하지만, 외부에서 ‘안으로 들어오는 연결(Inbound)’은 철저히 막는 방어적인 경로이다.
• 작동 원리 (네트워크 주소 변환)
  • NAT Gateway는 자신을 통과하는 트래픽 패킷의 주소를 변환한다.
  • Private 인스턴스가 밖으로 나갈 때, 인스턴스의 진짜 Private IP는 숨기고 NAT Gateway에 연결된 Public IP 주소에서 나온 것처럼 패킷을 위장하여 내보낸다.
• 유용성 : 보안이 중요한 데이터베이스나 깃허브 등에서 빌드 아티팩트를 읽어와야 하는 빌드 서버처럼, 밖으로 나갈 일은 있지만 밖에서 직접 찾아오면 안되는 호스트에 유용하다.
• 상호 보완 관계
  • NAT Gateway는 IGW를 대체하는 것이 아니다.
  • NAT Gateway를 거친 트래픽도 결국 IGW를 통과해야 외부로 나갈 수 있다. (두 게이트웨이는 함께 작동)

# 1. NAT에 씌워줄 신규 탄력적 IP(EIP) 할당
aws ec2 allocate-address \ 
	--domain vpc \
	--network-border-group us-east-1
	
# 2. NAT 게이트웨이 생성
aws ec2 create-nat-gateway \
	 --subnet-id subnet-1234 \
	 --allocation-id eipalloc-1234

5.3. NAT Gateway 배치 시 주의사항

1. 서브넷에 연결 : IGW가 VPC 전체에 연결되는 것과 달리, NAT Gateway는 반드시 ‘특정 서브넷’ 안에 배치되어야 한다.

2. 인터넷 액세스용 NAT Gateway는 퍼블릭 서브넷에 배치
   • Private Subnet의 트래픽을 인터넷으로 내보내기 위한 Public NAT Gateway는 반드시 퍼블릭 서브넷에 생성해야 한다.
   • 이 경우 NAT Gateway는 Elastic IP를 가져야 하며, 인터넷 방향 트래픽은 결국 VPC의 IGW를 통해 나간다.
3. Private NAT Gateway는 별도 개념
   • Private NAT Gateway는 인터넷 연결용이 아니라, 다른 VPC 또는 온프레미스 네트워크로의 아웃바운드 연결에 사용된다.
   • 이 경우 트래픽은 Transit Gateway(TGW) 또는 Virtual Private Gateway(VGW)로 라우팅할 수 있다.
   • 따라서 “NAT Gateway는 항상 퍼블릭 서브넷에 둔다”라고 일반화하기보다는, “인터넷 액세스용 Public NAT Gateway는 퍼블릭 서브넷에 둔다”라고 쓰는 것이 더 정확하다.