AWS VPC(Virtual Private Cloud)

논리적으로 격리된 가상 네트워크

물리적으로 서버가 따로 있는 건 아니지만, 네트워크 주소(IP), 라우팅, 접근 규칙 관점에서는 완전히 분리된 전용 네트워크
IP 대역(CIDR), 서브넷 구조, 라우팅 방식 등을 사용자가 직접 설계
즉, AWS 안에 내가 직접 만든 가상 사설 네트워크를 하나 갖는 것

(출처 : https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)

이 VPC는 하나의 리전 안에서, 각 가용 영역(Availability Zone, AZ)마다 하나의 서브넷을 가지고 있다.
각 서브넷 안에는 EC2 인스턴스들이 실행되고 있다. 그리고 VPC 내부 리소스들과 인터넷 간의 통신을 가능하게 하기 위해 Internet Gateway가 연결되어 있다.

서브넷

서브넷은 VPC 내부에서 사용되는 IP 주소 범위의 논리적 구획 VPC가 “네트워크 전체 공간”이라면, 서브넷은 그 안의 실제 리소스 배치 단위

서브넷 = CIDR 블록 (예: 10.0.1.0/24)
이 범위 안에서만 IP가 할당됨
VPC CIDR의 부분 집합
- 예: VPC가 10.0.0.0/16이면, 서브넷은 10.0.1.0/24, 10.0.2.0/24 같은 형태
EC2 인스턴스와 같은 AWS 리소스는 반드시 특정 서브넷에 소속되어 생성된다.
- 어느 서브넷에 두느냐가 곧 보안 + 가용성 + 접근성 결정

기본 개념

각 서브넷은 하나의 AZ 안에 완전히 포함되어야 하며, 여러 AZ에 걸쳐 구성될 수 없다.

즉, 서브넷 ↔ AZ는 1:1 종속 관계
이 제약은 물리적 장애 격리를 위한 설계 원칙
- AWS 리소스를 서로 다른 AZ에 분산 배치하면, 특정 AZ에 장애가 발생하더라도 애플리케이션 전체 장애를 방지할 수 있다.

서브넷 IP 주소 범위

서브넷을 생성할 때는, VPC의 IP 구성 방식(IPv4 only, Dual stack, IPv6 only)에 따라 서브넷의 IP 주소 체계를 지정해야 한다.

IPv4 only

IPv4 CIDR 블록만을 가지며 IPv6 CIDR 블록은 포함하지 않는다.
이 서브넷에 속한 리소스는 IPv4 프로토콜을 통해서만 통신할 수 있다.

Dual stack

듀얼 스택 서브넷은 IPv4와 IPv6 CIDR 블록을 모두 가진다.
이를 위해서는 VPC 자체도 IPv4와 IPv6 CIDR 블록을 모두 보유해야 한다.
듀얼 스택 서브넷의 리소스는 IPv4와 IPv6 양쪽 모두로 통신할 수 있다.

IPv6 only

IPv6 전용 서브넷은 IPv6 CIDR 블록만을 가지며 IPv4 CIDR 블록은 포함하지 않는다.
이를 위해 VPC는 반드시 IPv6 CIDR 블록을 가지고 있어야 한다.
해당 서브넷의 리소스는 IPv6을 통해서만 통신한다.
IPv6 전용 서브넷의 리소스에는 169.254.0.0/16 범위의 IPv4 링크 로컬 주소가 자동으로 할당된다.
- 이 주소들은 VPC 내부에서만 제공되는 서비스와의 통신에 사용된다.

서브넷 유형

서브넷의 유형은 라우팅 테이블 설정 방식에 의해 결정된다.

Public subnet

Internet Gateway로 향하는 직접적인 라우트가 설정된 서브넷이다.
이 서브넷의 리소스는 공인 인터넷에 직접 접근할 수 있다.
- 일반적으로 ALB, Bastion Host, NAT Gateway 등 위치

Private subnet

Internet Gateway로 직접 연결되는 라우트를 가지지 않는다.
퍼블릭 인터넷 접근이 필요할 경우 NAT 장치를 통해야 한다.

VPN-only subnet

Virtual Private Gateway를 통해 Site-to-Site VPN 연결로 향하는 라우트를 가진다.
Internet Gateway로의 라우트는 존재하지 않는다.

Isolated subnet

VPC 외부로 나가는 어떤 라우트도 가지지 않는다.
이 서브넷의 리소스는 동일 VPC 내 리소스와만 통신할 수 있다.

EVS subnet

Amazon EVS를 사용해 생성되는 특수한 서브넷이다.

서브넷 라우팅

각 서브넷은 반드시 하나의 라우트 테이블과 연결되어야 하며, 이 라우트 테이블은 해당 서브넷에서 외부로 나가는 트래픽이 어떤 경로로 나갈 수 있는지를 정의한다.

퍼블릭, 프라이빗 여부는 서브넷 자체가 아니라 라우트 테이블이 결정
새로 생성되는 모든 서브넷은 기본적으로 VPC의 메인 라우트 테이블(Main Route Table)과 자동으로 연결된다.
- VPC에는 반드시 Main Route Table이 1개 존재
서브넷과 라우트 테이블의 연결 관계는 변경할 수 있으며, 메인 라우트 테이블 자체의 라우팅 규칙 또한 수정할 수 있다.

예시 : 퍼블릭 서브넷용 Route Table

인터넷과 직접 통신 가능한 서브넷

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	igw-0a1b2c3d

10.0.0.0/16 → local
- 같은 VPC 내부 통신
  - 즉, 이 VPC의 CIDR 범위 안에 있는 모든 IP로 가는 트래픽은 VPC 내부(local)에서 처리하라는 의미
- 모든 Route Table에 기본으로 존재
  - AWS VPC는 “VPC 내부 통신은 항상 가능해야 한다”라는 전제를 깔고 설계됨
  - 그래서 VPC 생성 시, Route Table 생성 시 Subnet 연결 여부와 무관하게 VPC CIDR → local 라우트는 자동 생성
0.0.0.0/0 → IGW
- VPC 밖(인터넷)으로 나가는 모든 트래픽
- Internet Gateway를 통해 직접 인터넷 접근 가능

예시 : 프라이빗 서브넷용 Route Table

인터넷 직접 노출 없이, 아웃바운드만 허용

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	nat-0f9e8d7c

10.0.0.0/16 → local
- VPC 내부 통신
0.0.0.0/0 → NAT
- 외부 인터넷으로 나갈 때 NAT Gateway 경유
- 외부에서 직접 들어오는 인바운드는 불가

서브넷 설정

모든 서브넷에는 해당 서브넷에서 생성되는 네트워크 인터페이스에 공인 IPv4 주소(및 해당되는 경우 IPv6 주소)를 자동 할당할지 여부를 결정하는 설정 값이 존재하며, 수정이 가능하다.

이 설정은 인스턴스를 해당 서브넷에 생성할 때 자동으로 만들어지는 기본 네트워크 인터페이스(예: eth0)에도 적용된다.
서브넷의 기본 설정과 무관하게, 인스턴스 생성 시점에 개별 인스턴스 단위로 이 설정을 재정의할 수 있다.
- 예 : 퍼블릭 서브넷이지만 특정 EC2만 공인 IP 미부여 가능

서브넷 보안

AWS 리소스를 보호하기 위해, AWS는 프라이빗 서브넷 사용을 권장한다.

프라이빗 서브넷에 있는 EC2 인스턴스와 같은 리소스가 인터넷 접근이 필요할 경우, Bastion Host 또는 NAT 장치를 통해 접근하도록 구성한다.
- Bastion Host: 관리 목적 인바운드 접근
- NAT Gateway / NAT Instance: 아웃바운드 인터넷 접근
보안 그룹(Security Group)은 EC2 인스턴스와 같은 개별 리소스에 대해 허용되는 인바운드 및 아웃바운드 트래픽을 제어한다.
네트워크 ACL(Network ACL)은 서브넷 단위에서 인바운드 및 아웃바운드 트래픽을 허용하거나 차단한다.
- 대부분의 경우 보안 그룹만으로도 요구되는 보안 수준을 충족할 수 있다.
- 추가적인 보안 계층이 필요한 경우에는 네트워크 ACL을 함께 사용할 수 있다.
- 설계상 모든 서브넷은 반드시 하나의 네트워크 ACL과 연결되어야 한다.
- 새로 생성되는 모든 서브넷은 기본적으로 VPC의 기본 네트워크 ACL과 자동 연결된다.
- 기본 네트워크 ACL은 모든 인바운드 및 아웃바운드 트래픽을 허용한다.

보안 그룹 (Security Groups, SG)

자신이 연결된 리소스로 들어오거나(Inbound) 나가는(Outbound) 트래픽 중 허용된 트래픽만을 제어하는 보안 정책 집합

예를 들어, 보안 그룹을 EC2 인스턴스에 연결하면 해당 보안 그룹이 그 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하게 된다.
- 하나의 EC2에 여러 SG 연결 가능
- 여러 EC2가 같은 SG 공유 가능
VPC를 생성하면, 해당 VPC에는 기본 보안 그룹이 자동으로 함께 생성된다.
- 기본 SG 특징:
  - 인바운드 : 아무것도 허용 안 함 (단, 자기 자신 제외)
  - 아웃바운드 : 모든 트래픽 허용
각 인바운드 규칙에는 트래픽의 출발지, 포트 범위, 프로토콜을 지정할 수 있다.
각 아웃바운드 규칙에는 목적지, 포트 범위, 프로토콜을 지정할 수 있다.
다음 다이어그램은 VPC 안에 서브넷, Internet Gateway, 그리고 보안 그룹이 존재하는 구조를 보여준다.

(출처 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)

해당 서브넷에는 EC2 인스턴스가 존재하며, 이 인스턴스에는 특정 보안 그룹이 할당되어 있다.
보안 그룹은 가상 방화벽처럼 동작한다.
- 즉, EC2 인스턴스에 실제로 도달하는 트래픽은 보안 그룹 규칙에 의해 명시적으로 허용된 트래픽뿐이다.
- 예를 들어, 보안 그룹에 사용자 네트워크로부터의 ICMP 트래픽을 허용하는 규칙이 있다면, 사용자는 자신의 컴퓨터에서 해당 인스턴스로 ping을 보낼 수 있다.
- 반대로, 보안 그룹에 SSH 트래픽을 허용하는 규칙이 없다면, SSH를 사용해 인스턴스에 접속할 수 없다.

규칙

기본적으로 동일한 VPC 내에서 생성된 리소스에 할당할 수 있다.
동일 리전 내 다른 VPC에 대해서는 Security Group VPC Association 기능을 사용해 보안 그룹을 다른 VPC와 연결한 뒤 해당 VPC의 리소스에도 할당할 수 있다.
하나의 리소스에는 여러 개의 보안 그룹을 동시에 할당할 수 있다.
- 이런 경우, 하나라도 허용하면 통과
보안 그룹 이름은:
- 동일 VPC 내에서 유일해야 한다.
- 대소문자를 구분하지 않는다.
- 최대 255자까지 사용할 수 있다.
- 알파벳, 숫자, 공백 및 지정된 특수문자만 사용할 수 있다.
- 이름의 끝에 공백이 포함되어 있으면, 해당 공백은 저장 시 자동으로 제거된다.
- sg-로 시작할 수 없다.
다음 트래픽은 보안 그룹 규칙과 무관하게 허용된다:
- Amazon DNS 서비스
- Amazon DHCP 서비스
- EC2 인스턴스 메타데이터
- ECS 태스크 메타데이터 엔드포인트
- Windows 라이선스 활성화 통신
- Amazon Time Sync Service
- 기본 VPC 라우터가 사용하는 예약 IP 주소
제한 사항:
- VPC당 생성 가능한 보안 그룹 수
- 보안 그룹당 추가할 수 있는 규칙 수
- 하나의 네트워크 인터페이스에 연결할 수 있는 보안 그룹 수

Stateful

보안 그룹은 상태 저장(Stateful) 방식으로 동작한다.
- 예를 들어, 인스턴스에서 외부로 요청을 보낸 경우, 그 요청에 대한 응답 트래픽은 인바운드 규칙과 무관하게 허용된다.
- 마찬가지로, 허용된 인바운드 트래픽에 대한 응답은 아웃바운드 규칙과 관계없이 인스턴스에서 나갈 수 있다.
즉, 보안 그룹은 트래픽을 패킷 단위가 아니라 요청–응답 세션 단위로 기억하고 판단한다

Stateless였다면 ?

예시 : Network ACL
Inbound : 22 허용
Outbound : 없음

결과 : SSH 접속 안됨 (응답 패킷이 차단됨)
그래서 NACL에서는 항상:
- Inbound 22 허용
- Outbound 1024-65535 허용
- 같은 쌍 규칙을 만들어야 함

질문 : sg1을 만들고, sg2의 인바운드를 소스를 sg1으로 지정하면 ?

# sg2
inbound rule:
Source = sg1
Protocol = TCP
Port = 8080

이 규칙의 정확한 의미:
- sg1이 붙어 있는 리소스에서 오는 트래픽만 sg2가 붙어 있는 리소스로 들어오는 것을 허용한다
- 즉, 트래픽을 보낸 리소스의 IP 주소나 네트워크 대역 기준이 아닌 소속 보안 그룹으로 판단

[EC2-A] --(sg1) ---> [EC2-B] --(sg2)
sg2 인바운드 : ALLOW TCP 8080 FROM sg1

시도	결과	이유
EC2-A → EC2-B:8080	허용	sg1 → sg2 규칙 존재
EC2-B → EC2-A:8080	차단	sg2 → sg1 규칙 없음
다른 EC2 → EC2-B	차단	sg1 소속 아님

리소스가 어떤 보안 그룹에 ‘속해있다’ ?
- 그 리소스의 ENI(Network Interface)에 어떤 보안 그룹이 연결되어 있다.

EC2 Instance
 └─ ENI (eth0)
     └─ Security Group: sg1

AWS VPC(Virtual Private Cloud) - 기초 개념

AWS VPC(Virtual Private Cloud)

서브넷

기본 개념

서브넷 IP 주소 범위

서브넷 유형

서브넷 라우팅

서브넷 설정

서브넷 보안

보안 그룹 (Security Groups, SG)

규칙

Stateful

질문 : sg1을 만들고, sg2의 인바운드를 소스를 sg1으로 지정하면 ?

참고 자료

Trending Tags

AWS VPC(Virtual Private Cloud) - 기초 개념

AWS VPC(Virtual Private Cloud)

서브넷

기본 개념

서브넷 IP 주소 범위

서브넷 유형

서브넷 라우팅

서브넷 설정

서브넷 보안

보안 그룹 (Security Groups, SG)

규칙

Stateful

질문 : sg1을 만들고, sg2의 인바운드를 소스를 sg1으로 지정하면 ?

참고 자료

Further Reading

AWS ECS(Elastic Container Service) - 기초 개념

AWS ECR(Elastic Container Registry) - 기초 개념

AWS EFS(Elastic File System) - 기초 개념

Trending Tags