📄 2025.12.04 (Day 29) - AWS VPC: 네트워크 구성 및 연결
1. 핵심 개념 정리
| # | 핵심 개념 | 간결한 설명 | 실무/보안 관점에서의 중요성 |
|---|---|---|---|
| 1 | Amazon VPC (Virtual Private Cloud) | AWS 클라우드 내에서 논리적으로 격리된 가상 네트워크를 생성하는 서비스입니다. 사용자가 정의한 IP 주소 범위(CIDR 블록), 서브넷, 라우팅 테이블, 게이트웨이를 구성하여 완전한 제어 권한을 가집니다. | 네트워크 보안의 기본입니다. VPC로 리소스를 격리하고, Public/Private Subnet 분리, 보안 그룹 및 NACL로 트래픽 제어, VPC Peering/Transit Gateway로 안전한 내부 통신 구현. |
| 2 | CIDR (Classless Inter-Domain Routing) | IP 주소 범위를 표기하는 방식으로 IP주소/서브넷 마스크 형태입니다. 예: 10.0.0.0/16은 10.0.0.0 ~ 10.0.255.255 (65,536개 IP). VPC 생성 시 CIDR 블록을 지정합니다. | IP 주소 계획이 중요합니다. VPC CIDR은 변경 불가하므로 초기 설계 시 충분한 IP 확보 필요(예: /16). 다른 VPC나 On-Premise와 겹치지 않도록 RFC 1918 사설 IP 대역 사용. |
| 3 | 서브넷 (Subnet) | VPC 내에서 IP 주소 범위를 더 작은 단위로 분할한 네트워크 세그먼트입니다. 각 서브넷은 하나의 가용 영역(AZ) 에 속하며, Public Subnet(인터넷 게이트웨이 연결)과 Private Subnet(인터넷 직접 접근 불가)으로 구분됩니다. | 보안 계층화의 핵심입니다. Public Subnet에는 웹 서버/로드 밸런서 배치, Private Subnet에는 애플리케이션 서버/데이터베이스 배치하여 공격 표면 최소화. |
| 4 | 인터넷 게이트웨이 (IGW) | VPC와 인터넷 간 양방향 통신을 가능하게 하는 게이트웨이입니다. Public Subnet의 라우팅 테이블에 IGW를 기본 게이트웨이(0.0.0.0/0)로 설정하여 인터넷 접속을 허용합니다. VPC당 1개만 연결 가능. | Public Subnet 필수 요소입니다. EC2 인스턴스에 Public IP 또는 Elastic IP 할당 필요. 보안 그룹으로 인바운드 트래픽 제어 필수. |
| 5 | NAT Gateway | Private Subnet의 인스턴스가 인터넷에 아웃바운드 연결 (소프트웨어 업데이트, API 호출)을 가능하게 하지만, 인바운드 연결은 차단합니다. AWS 관리형 서비스로 고가용성과 자동 확장을 제공합니다. | Private Subnet 보안을 유지하면서 외부 통신을 허용합니다. NAT Gateway는 고가용성이지만 비용 발생. 각 AZ마다 NAT Gateway 배치 권장. |
| 6 | 라우팅 테이블 (Route Table) | 네트워크 트래픽의 경로를 결정하는 규칙 집합입니다. 각 서브넷은 하나의 라우팅 테이블과 연결되며, 목적지 IP 범위(Destination)와 타겟(IGW, NAT Gateway, VPC Peering 등)을 정의합니다. | 트래픽 흐름 제어의 핵심입니다. Public Subnet RT: 0.0.0.0/0 → IGW, Private Subnet RT: 0.0.0.0/0 → NAT Gateway. 잘못된 라우팅은 통신 단절 또는 의도치 않은 경로로 트래픽 유출. |
| 7 | 보안 그룹 (Security Group) | EC2 인스턴스 등 리소스에 연결되는 가상 방화벽으로, **상태 저장형(Stateful)**입니다. 기본적으로 모든 인바운드 차단, 모든 아웃바운드 허용. Allow 규칙만 정의 가능(Deny 불가). 응답 트래픽은 자동 허용됩니다. | 인스턴스 레벨 방화벽입니다. 최소 권한 원칙 적용: 필요한 포트와 소스 IP만 허용. 보안 그룹끼리 참조 가능(예: 웹 서버 SG는 ALB SG만 허용). |
| 8 | 네트워크 ACL (NACL) | 서브넷 레벨에서 작동하는 무상태형(Stateless) 방화벽입니다. 인바운드/아웃바운드 규칙을 번호 순서대로 평가하며, Allow와 Deny 모두 정의 가능합니다. 응답 트래픽도 명시적 규칙 필요. | 서브넷 레벨 보안 계층으로 보안 그룹과 함께 다층 방어 구현. NACL로 특정 IP 대역 차단, 보안 그룹으로 세밀한 제어. Stateless이므로 Ephemeral 포트(1024-65535) 허용 필요. |
| 9 | VPC Peering | 두 VPC 간 프라이빗 네트워크 연결을 제공합니다. AWS 백본 네트워크를 사용하여 두 VPC가 같은 네트워크에 있는 것처럼 통신. CIDR 블록이 겹치면 안 됩니다. 비전이적(Non-transitive): A-B, B-C Peering 시 A-C 직접 통신 불가. | VPC 간 안전한 통신을 위해 인터넷 경유 불필요. Peering 연결 후 각 VPC의 라우팅 테이블에 상대 VPC CIDR 추가 필수. 다중 VPC 연결 시 Transit Gateway 권장. |
| 10 | AWS Transit Gateway | 여러 VPC와 On-Premise 네트워크를 중앙 허브로 연결하는 서비스입니다. 수천 개의 VPC를 하나의 Transit Gateway에 연결 가능하며, 라우팅을 중앙 집중식으로 관리합니다. | 대규모 네트워크 아키텍처에 필수입니다. 수십 개 이상의 VPC 연결 시 Transit Gateway로 단순화. VPN 연결, Direct Connect를 Transit Gateway에 연결하여 하이브리드 클라우드 구성. |
| 11 | VPC Endpoint | VPC 내 리소스가 인터넷 게이트웨이, NAT 없이 AWS 서비스에 프라이빗 연결하는 기능입니다. Interface Endpoint(ENI 기반, 대부분 서비스 지원)와 Gateway Endpoint(S3, DynamoDB만 지원, 무료)로 구분. | 보안 및 비용 향상을 동시에 달성. Private Subnet에서 S3 접근 시 NAT Gateway 비용 절감(Gateway Endpoint 무료). 데이터가 인터넷 노출 없이 AWS 백본으로만 전송되어 안전. |
| 12 | VPN / Direct Connect | VPN: On-Premise와 AWS VPC를 IPsec 암호화 터널로 연결 (Site-to-Site VPN). 빠른 구축, 저렴, 인터넷 경유. Direct Connect: 전용 물리적 네트워크 연결 (1Gbps~100Gbps), 일관된 성능, 낮은 지연시간. | 하이브리드 클라우드 구축의 기본입니다. 빠른 구축은 VPN, 대용량/저지연 요구 시 Direct Connect 권장. |
2. 실습 내용
(A) VPC 생성 및 기본 구성
VPC 생성 (Console):
- AWS Console → VPC → VPC 생성
- 이름 태그: my-vpc, IPv4 CIDR 블록: 10.0.0.0/16 (65,536개 IP), 테넌시: 기본값
VPC 생성 (AWS CLI):
- aws ec2 create-vpc –cidr-block 10.0.0.0/16 –tag-specifications ‘ResourceType=vpc,Tags=[{Key=Name,Value=my-vpc}]’
- 출력: VPC ID 확인 (예: vpc-0abcd1234efgh5678)
- aws ec2 describe-vpcs –vpc-ids vpc-0abcd1234efgh5678 → VPC 정보 조회
- aws ec2 modify-vpc-attribute –vpc-id vpc-xxx –enable-dns-hostnames → DNS 호스트 이름 활성화
CIDR 계산 예시:
- 10.0.0.0/16 → IP 범위: 10.0.0.0 ~ 10.0.255.255, 사용 가능 IP: 65,531개 (65,536 - 5개 AWS 예약)
- 10.0.1.0/24 → IP 범위: 10.0.1.0 ~ 10.0.1.255, 사용 가능 IP: 251개 (256 - 5개 AWS 예약)
AWS 예약 IP (각 서브넷마다 5개):
- 첫 번째 IP (예: 10.0.1.0): 네트워크 주소
- 두 번째 IP (예: 10.0.1.1): VPC 라우터
- 세 번째 IP (예: 10.0.1.2): DNS 서버
- 네 번째 IP (예: 10.0.1.3): 향후 사용 예약
- 마지막 IP (예: 10.0.1.255): 브로드캐스트 주소
(B) 서브넷 생성 (Public & Private)
서브넷 설계 (권장 구조):
VPC: 10.0.0.0/16
- Public Subnets (인터넷 연결 / 웹 서버, 로드 밸런서):
- 10.0.1.0/24 (ap-northeast-2a)
- 10.0.2.0/24 (ap-northeast-2c)
- Private Subnets (애플리케이션 서버):
- 10.0.11.0/24 (ap-northeast-2a)
- 10.0.12.0/24 (ap-northeast-2c)
- Private Subnets (데이터베이스):
- 10.0.21.0/24 (ap-northeast-2a)
- 10.0.22.0/24 (ap-northeast-2c)
Public Subnet 생성:
- aws ec2 create-subnet –vpc-id vpc-xxx –cidr-block 10.0.1.0/24 –availability-zone ap-northeast-2a –tag-specifications ‘ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-1}]’
- aws ec2 modify-subnet-attribute –subnet-id subnet-xxx –map-public-ip-on-launch → Public IP 자동 할당 활성화
Private Subnet 생성:
- aws ec2 create-subnet –vpc-id vpc-xxx –cidr-block 10.0.11.0/24 –availability-zone ap-northeast-2a –tag-specifications ‘ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-1}]’
(C) 인터넷 게이트웨이 및 NAT Gateway 설정
인터넷 게이트웨이 (IGW) 설정:
- aws ec2 create-internet-gateway –tag-specifications ‘ResourceType=internet-gateway,Tags=[{Key=Name,Value=my-igw}]’
- aws ec2 attach-internet-gateway –internet-gateway-id igw-xxx –vpc-id vpc-xxx → VPC에 IGW 연결
NAT Gateway 설정:
- aws ec2 allocate-address –domain vpc → Elastic IP 할당 (AllocationId: eipalloc-xxx)
- aws ec2 create-nat-gateway –subnet-id subnet-public –allocation-id eipalloc-xxx → Public Subnet에 NAT Gateway 생성
- aws ec2 describe-nat-gateways –nat-gateway-ids nat-xxx → 상태 확인 (pending → available)
- 고가용성: 각 AZ마다 NAT Gateway 생성 권장
(D) 라우팅 테이블 구성
Public Subnet 라우팅 테이블:
- 라우팅 테이블 생성 → 기본 경로 추가: 목적지 0.0.0.0/0, 타겟 IGW
- Public Subnet과 라우팅 테이블 연결
Private Subnet 라우팅 테이블:
- 라우팅 테이블 생성 → 기본 경로 추가: 목적지 0.0.0.0/0, 타겟 NAT Gateway
- Private Subnet과 라우팅 테이블 연결
라우팅 테이블 구조:
Public Route Table:
- 목적지 10.0.0.0/16, 타겟 local (VPC 내부 트래픽)
- 목적지 0.0.0.0/0, 타겟 igw-xxx (인터넷 트래픽)
Private Route Table:
- 목적지 10.0.0.0/16, 타겟 local (VPC 내부 트래픽)
- 목적지 0.0.0.0/0, 타겟 nat-xxx (인터넷 트래픽을 NAT를 통해)
(E) 보안 그룹 및 NACL 설정
보안 그룹 생성 (웹 서버용):
- aws ec2 create-security-group –group-name web-server-sg –description “Security group for web servers” –vpc-id vpc-xxx
- HTTP 인바운드 허용: aws ec2 authorize-security-group-ingress –group-id sg-xxx –protocol tcp –port 80 –cidr 0.0.0.0/0
- HTTPS 인바운드 허용: port 443, cidr 0.0.0.0/0
- SSH 인바운드 허용: port 22, cidr 203.0.113.0/24 (특정 관리자 IP만)
보안 그룹 간 참조 (애플리케이션 서버용):
- aws ec2 authorize-security-group-ingress –group-id sg-app –protocol tcp –port 8080 –source-group sg-web
- 보안 그룹 참조 장점: IP 변경 시에도 자동으로 업데이트, 더 명확한 트래픽 제어
NACL 설정:
- NACL 생성 후 서브넷과 연결
- 인바운드 규칙 (번호 순서대로 평가):
- 규칙 100: HTTP(80) - allow, 0.0.0.0/0
- 규칙 110: HTTPS(443) - allow, 0.0.0.0/0
- 규칙 120: SSH(22) - allow, 203.0.113.0/24 (관리자만)
- 규칙 130: Ephemeral 포트(1024-65535) - allow, 0.0.0.0/0 (응답 트래픽용)
- 규칙 * (기본): DENY, 0.0.0.0/0
보안 그룹 vs NACL 비교:
| 특성 | 보안 그룹 | NACL |
|---|---|---|
| 작동 레벨 | 인스턴스 | 서브넷 |
| 상태 | Stateful | Stateless |
| 규칙 타입 | Allow만 | Allow + Deny |
| 규칙 평가 | 모든 규칙 평가 | 번호 순서대로 |
| 응답 트래픽 | 자동 허용 | 명시적 규칙 필요 |
| 기본 설정 | 모든 트래픽 차단 | 모든 트래픽 허용 |
방어 전략: NACL(서브넷 경계 방어, 거친 필터링) + 보안 그룹(인스턴스 세밀한 제어)
(F) VPC Peering 설정
VPC Peering 연결:
- aws ec2 create-vpc-peering-connection –vpc-id vpc-aaaaa –peer-vpc-id vpc-bbbbb → Peering 요청 생성 (상태: pending-acceptance)
- aws ec2 accept-vpc-peering-connection –vpc-peering-connection-id pcx-xxx → VPC-B에서 수락
라우팅 테이블 업데이트 (양방향 필수):
- VPC-A RT: 목적지 10.1.0.0/16 (VPC-B CIDR), 타겟 pcx-xxx
- VPC-B RT: 목적지 10.0.0.0/16 (VPC-A CIDR), 타겟 pcx-xxx
(G) VPC Endpoint 설정 (S3)
Gateway Endpoint 생성 (S3, DynamoDB - 무료):
- aws ec2 create-vpc-endpoint –vpc-id vpc-xxx –service-name com.amazonaws.ap-northeast-2.s3 –route-table-ids rtb-private
- 자동으로 라우팅 테이블에 S3 Prefix List → vpce-xxx 경로 추가됨
(H) 완전한 VPC 네트워크 구성 시나리오
고가용성 웹 애플리케이션 아키텍처:
인터넷 - (IGW) - VPC 10.0.0.0/16:
- Public Subnet 1 (10.0.1.0/24, AZ-A): ALB, NAT Gateway 1
- Public Subnet 2 (10.0.2.0/24, AZ-C): ALB, NAT Gateway 2
- Private Subnet 1 (10.0.11.0/24, AZ-A): Web Server 1 (EC2)
- Private Subnet 2 (10.0.12.0/24, AZ-C): Web Server 2 (EC2)
- Private Subnet 3 (10.0.21.0/24, AZ-A): RDS Primary
- Private Subnet 4 (10.0.22.0/24, AZ-C): RDS Standby
단계별 구성 순서:
- VPC 생성 (10.0.0.0/16)
- 서브넷 생성 (6개: Public 2, Private App 2, Private DB 2)
- IGW 생성 및 VPC에 연결
- NAT Gateway 생성 (각 AZ마다 1개)
- 라우팅 테이블 구성 (Public RT: 0.0.0.0/0 → IGW, Private RT: 0.0.0.0/0 → NAT GW)
- 보안 그룹 생성 (ALB SG, Web SG, DB SG 계층 구조)
- EC2 인스턴스 배포 (Auto Scaling Group)
- RDS 배포 (Multi-AZ)
- S3 Gateway Endpoint 생성
3. 실무/보안 관점 분석
| 분야 | 적용 시나리오 |
|---|---|
| 네트워크 아키텍처 설계 | 다층 방어 구조: Public Subnet(ALB/Bastion) → Private Subnet(App Server) → Private Subnet(Database)로 계층 분리. 고가용성: 최소 2개 AZ에 리소스 분산 배치, 각 AZ마다 NAT Gateway로 AZ 장애 시에도 인터넷 접속 가능. IP 주소 관리: VPC CIDR은 변경 불가하므로 초기 설계 시 충분한 IP 확보(/16 권장). |
| 보안 강화 전략 | Bastion Host 패턴: Private Subnet EC2는 직접 SSH 불가. Public Subnet에 Bastion Host 배치 → 여기서만 Private EC2 접속. VPC Flow Logs: 모든 네트워크 트래픽 로그를 S3 또는 CloudWatch에 저장. Athena로 SQL 쿼리 분석하여 포트 스캔, 대량 연결 시도 탐지. AWS Network Firewall: Suricata 호환 IDS/IPS 기능. VPC 경계에 배치하여 애플리케이션 레벨 공격 차단. |
| 하이브리드 클라우드 | VPN 연결: On-Premise 데이터센터와 VPC를 Site-to-Site VPN으로 연결. 빠른 구축(몇 시간), 저렴, 두 개의 터널 자동 생성. Direct Connect: 전용선으로 일관된 성능, 대용량 데이터 전송에 적합. Transit Gateway: 여러 VPC, On-Premise, Direct Connect를 하나의 허브에 연결. 중앙 집중식 라우팅 관리. |
| 비용 최적화 | NAT Gateway 비용 절감: S3/DynamoDB는 Gateway Endpoint(무료) 사용. 다른 서비스는 Interface Endpoint로 NAT 우회. VPC Peering vs Transit Gateway: 소수 VPC 연결은 Peering(무료, 데이터 전송만 과금), 다수 VPC는 Transit Gateway(관리 간소화). Elastic IP: 미사용 EIP는 시간당 과금 → 즉시 릴리스. |
4. 개인 인사이트 및 다음 단계
- 배운 점/느낀 점: VPC를 제대로 설계하지 않으면 나중에 아키텍처 변경이 매우 어렵습니다. CIDR 블록은 변경 불가하므로 초기 IP 주소 계획이 중요합니다. 보안 그룹은 Stateful(응답 자동 허용), NACL은 Stateless(명시적 규칙 필요)라는 차이가 핵심이며, 두 개를 조합하여 다층 방어를 구현하는 것이 Best Practice입니다. VPC Peering의 비전이적(Non-transitive) 특성으로 인해 다수 VPC 연결 시 Transit Gateway가 훨씬 효율적입니다.
- 심화 방향: Transit Gateway 실습, VPN 연결(IPsec 터널, BGP 동적 라우팅), VPC Flow Logs 분석(Athena SQL 쿼리로 포트 스캔/대량 연결 시도 탐지), AWS Network Firewall(Suricata 룰 작성), Bastion Host 또는 AWS Systems Manager Session Manager로 Private EC2 안전 접속, Terraform으로 VPC 자동화.
5. 추가 참고사항 (Quick Reference)
CIDR 블록 계산표
| CIDR | 서브넷 마스크 | 사용 가능 IP | 용도 |
|---|---|---|---|
| /32 | 255.255.255.255 | 1개 | 단일 호스트 |
| /28 | 255.255.255.240 | 11개 | 매우 작은 서브넷 |
| /24 | 255.255.255.0 | 251개 | 일반적인 서브넷 |
| /20 | 255.255.240.0 | 4,091개 | 큰 서브넷 |
| /16 | 255.255.0.0 | 65,531개 | VPC 권장 크기 |
| /12 | 255.240.0.0 | 1,048,571개 | 매우 큰 VPC |
VPC 구성 요소 제한 (기본값)
| 리소스 | 제한 | 증가 가능 여부 |
|---|---|---|
| VPC/리전 | 5개 | Yes |
| 서브넷/VPC | 200개 | Yes |
| IGW/VPC | 1개 | No |
| NAT Gateway/AZ | 5개 | Yes |
| VPC Peering 연결/VPC | 50개 | Yes (125개) |
| 보안 그룹/VPC | 2,500개 | Yes |
| 보안 그룹/인스턴스 | 5개 | Yes (16개) |
| 규칙/보안 그룹 | 60개 (In+Out) | Yes (1000개) |
| NACL/VPC | 200개 | Yes |
| 규칙/NACL | 20개 (In+Out) | Yes (40개) |
주요 AWS 서비스 포트 (보안 그룹 설정용)
| 서비스 | 포트 | 프로토콜 | 설명 |
|---|---|---|---|
| SSH | 22 | TCP | Linux 원격 접속 (Bastion에서만 허용) |
| RDP | 3389 | TCP | Windows 원격 데스크톱 (Bastion에서만) |
| HTTP | 80 | TCP | 웹 트래픽 (ALB에서 허용) |
| HTTPS | 443 | TCP | 암호화 웹 트래픽 (ALB에서 허용) |
| MySQL/Aurora | 3306 | TCP | 데이터베이스 (App SG에서만 허용) |
| PostgreSQL | 5432 | TCP | 데이터베이스 (App SG에서만 허용) |
| Redis | 6379 | TCP | ElastiCache (App SG에서만) |
| NFS | 2049 | TCP | EFS 마운트 (App SG에서만) |
| DNS | 53 | UDP/TCP | Route 53 (VPC 내부) |
| Ephemeral | 1024-65535 | TCP | 응답 트래픽 (NACL에서 허용 필요) |
보안 그룹 설계 패턴
1. 웹 계층 (ALB/Web Server):
- Inbound: HTTP(80) from 0.0.0.0/0, HTTPS(443) from 0.0.0.0/0
2. 애플리케이션 계층:
- Inbound: Custom TCP(8080) from web-tier-sg, Custom TCP(8443) from web-tier-sg
- Outbound: MySQL(3306) to db-tier-sg, HTTPS(443) to 0.0.0.0/0 (외부 API)
3. 데이터베이스 계층:
- Inbound: MySQL(3306) from app-tier-sg
4. Bastion Host:
- Inbound: SSH(22) from 관리자 IP/32
- Outbound: SSH(22) to app-tier-sg, SSH(22) to db-tier-sg
네트워크 트러블슈팅 체크리스트
- CIDR 블록 충돌 확인 (VPC Peering, On-Premise)
- 인터넷 게이트웨이가 VPC에 연결되었는지 확인
- NAT Gateway가 Public Subnet에 있고 EIP가 할당되었는지 확인
- Public Subnet 라우팅: 0.0.0.0/0 → IGW
- Private Subnet 라우팅: 0.0.0.0/0 → NAT Gateway
- 보안 그룹 인바운드 규칙 확인 (필요한 포트 허용)
- NACL 인바운드/아웃바운드 규칙 확인 (Ephemeral 포트 허용)
- EC2 인스턴스에 Public IP 또는 EIP 할당 확인 (Public Subnet)
- VPC Peering 시 양쪽 라우팅 테이블 업데이트 확인
- DNS 해석 활성화 확인 (VPC 속성)
- VPC Flow Logs로 REJECT 로그 확인
- Reachability Analyzer로 네트워크 경로 진단