SOA-C03 13/16 — VPC 연결·보호·비용
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 네트워크를 한 요청의 왕복 경로로 읽는다
VPC는 주소 공간과 네트워크 구성을 가진 논리적 경계다. Subnet은 특정 AZ 안의 주소 범위를 나누며, route table은 목적지에 따라 다음 대상을 선택한다. Security group과 NACL은 그 경로를 지나는 트래픽의 허용 여부를 판단한다. Route가 있다고 허용되는 것도, 허용 규칙이 있다고 route가 생기는 것도 아니다.
출발 ENI·주소·포트
→ 출발 subnet의 route·filter
→ gateway / endpoint / peering / firewall
→ 목적지의 filter·listener
→ 응답의 route·filter
→ 출발지처음에는 source·destination IP, protocol, destination port, source port, 시각을 적는다. NAT·proxy·load balancer를 통과하면 관찰되는 주소와 연결이 바뀔 수 있으므로 각 지점의 값으로 해석한다. Route tables
2. Public subnet이라는 이름만으로 인터넷에 연결되지 않는다
Subnet의 route table에 internet gateway로 향하는 경로가 있으면 public subnet으로 분류한다. 하지만 일반적인 EC2의 IPv4 직접 인터넷 통신에는 public IPv4 또는 Elastic IP, 올바른 route, SG·NACL 허용이 함께 필요하다. 인스턴스에 public IP만 붙여도 모든 구성 문제가 해결되는 것은 아니다.
| 경로 요소 | 주된 역할 | 혼동할 경계 |
|---|---|---|
| Internet gateway | VPC와 인터넷의 연결 | public subnet의 모든 자원이 자동 공개되지는 않음 |
| Public NAT gateway | 내부에서 시작한 IPv4 외부 연결의 주소 변환 | 외부에서 private instance로 신규 연결하는 진입점이 아님 |
| Private NAT gateway | 사설 네트워크 간 주소 변환 | IGW를 통한 인터넷 출구로 사용할 수 없음 |
| Egress-only internet gateway | IPv6에서 내부가 시작한 인터넷 연결 | IPv4 NAT나 IPv6 주소 변환 장치가 아님 |
Public NAT의 인터넷 경로는 NAT에서 IGW로 이어져야 한다. IPv6에서는 egress-only IGW의 outbound-only 연결과, IPv6 클라이언트가 IPv4 대상으로 가는 DNS64/NAT64 요구를 구분한다. NAT gateways, Egress-only IGW
운영에서는 사용 중인 NAT의 availability mode도 확인한다. Zonal NAT를 사용한 기존 설계의 AZ 의존성을 모든 NAT 구성에 동일하게 적용하지 않는다. 현재 문서에는 Regional NAT도 있으므로 실제 배포 유형을 먼저 읽는다.
3. SG와 NACL은 상태성과 평가 방식이 다르다
| 구분 | Security group | Network ACL |
|---|---|---|
| 적용 경계 | 연결된 resource·ENI | subnet을 출입하는 트래픽 |
| 규칙 | 허용 규칙 | 허용·거부 규칙 |
| 평가 | 적용 SG의 허용을 종합 | 낮은 번호부터 최초 일치 |
| 상태 | stateful | stateless |
| 응답 | 허용된 연결의 응답을 추적 | 응답 방향도 별도 허용 필요 |
예를 들어 client의 임시 source port에서 server의 TCP 443으로 연결한다면 응답 목적지는 그 임시 포트다. NACL에서 443만 양방향으로 열었다고 모든 응답이 허용되지는 않는다. 실제 OS·NAT·서비스의 포트 사용 범위를 확인한다.
SG의 stateful 동작은 route나 애플리케이션 listener를 대신하지 않는다. NACL은 같은 subnet 내부에서 라우팅되는 트래픽에 subnet 출입 때와 같은 방식으로 적용되지 않는다. AmazonProvidedDNS 같은 특별한 트래픽의 필터링 제한도 있으므로 일반 필터를 모든 AWS 내부 주소에 적용한다고 가정하지 않는다. SG, NACL
4. Endpoint는 서비스 접근 경로이고 IAM 허용을 대신하지 않는다
Gateway endpoint와 interface endpoint는 구성 위치부터 다르다.
- Gateway endpoint는 S3·DynamoDB 등 지원 대상의 경로를 route table에 연결하는 방식이다.
- Interface endpoint는 PrivateLink를 사용하며 subnet의 endpoint ENI·private IP, DNS, SG를 함께 확인한다.
- Endpoint policy가 지원되는 경우에는 통과할 수 있는 principal·action·resource 범위를 추가로 제한할 수 있다.
- 최종 service의 IAM·resource policy·KMS 접근 조건은 별도로 만족해야 한다.
같은 S3 접근도 VPC 안의 gateway endpoint 경로와 온프레미스에서 interface endpoint로 접근하는 경로가 다르다. Gateway endpoint를 peering·VPN·Transit Gateway 반대편 자원에 그대로 공유할 수 있다고 생각하면 안 된다. S3 gateway endpoint 자체에는 추가 요금이 없지만 모든 S3 요청·저장·전송 비용까지 사라지는 것은 아니다. S3 gateway endpoints
10의 SSM 사례처럼 “노드에서 HTTPS를 시작한다”는 조건과 “endpoint SG가 노드의 HTTPS 수신을 허용한다”는 조건을 연결한다. DNS가 public 주소를 반환하면 의도한 endpoint 경로를 실제로 사용하지 않을 수도 있다.
5. Peering은 VPC 두 개의 연결이다
VPC peering은 두 VPC가 사설 주소로 통신할 수 있도록 연결한다. 생성·수락만으로 필요한 양쪽 route와 보안 규칙이 자동 완성되는 것은 아니다. CIDR 중첩과 DNS 해석 옵션도 확인한다.
A와 B, B와 C를 각각 peer했다고 A에서 B를 통과해 C로 갈 수 있는 transitive routing이 생기지 않는다. Peering을 다른 VPC의 NAT·IGW·gateway endpoint를 공유하는 일반 transit 장치로 해석하지 않는다. 여러 네트워크를 중앙에서 연결하는 Transit Gateway의 경로는 15에서 다룬다. VPC peering 동작과 제한
6. 보호 서비스는 관찰하는 계층이 다르다
| 보호 기능 | 주로 판단하는 대상 | 구성 확인 |
|---|---|---|
| Resolver DNS Firewall | VPC의 Resolver를 지나는 DNS query | rule group·domain·action·VPC 연결 |
| AWS WAF | 지원 웹 resource로 들어오는 HTTP 요청 | web ACL 연결·rule 우선순위·action |
| AWS Shield | DDoS 보호 | 보호 서비스·지원 등급·대상 범위 |
| Network Firewall | 실제로 firewall 경로를 통과하는 network traffic | route·endpoint·policy·왕복 경로 |
DNS Firewall에서 domain을 차단하는 것과 WAF에서 HTTP path·header를 검사하는 것은 관찰 지점이 다르다. HTTPS라는 이유만으로 SG가 URL path를 검사할 수 있는 것도 아니다. DNS Firewall, WAF와 Shield
Network Firewall은 배치만으로 모든 VPC 트래픽을 검사하지 않는다. 검사할 트래픽을 firewall endpoint로 보내도록 route를 설계하고 stateful inspection에서 필요한 대칭 경로를 확인한다. Policy의 규칙 평가 방식과 로그를 함께 본다. Network Firewall
조직의 VPC Block Public Access는 중앙에서 인터넷 접근 구성을 제한하는 추가 경계다. Ingress-only·bidirectional 설정과 exclusion을 확인하며, 개별 SG가 허용한다고 조직 차원의 차단을 우회할 수 있다고 생각하지 않는다. 11의 declarative policy와 연결해 현재 effective configuration을 읽는다. VPC BPA
7. 비용은 경로 위의 처리량과 배치에서 발생한다
설계 비교에서는 장치 개수만 세지 않고 시간당 비용, 처리 GB, AZ·Region 간 전송, 인터넷 전송, endpoint 비용을 함께 본다. NAT를 하나로 집중하면 장치 비용이 줄어도 AZ 간 전송과 장애 의존성이 늘 수 있다. Endpoint를 여러 AZ·서비스에 만들면 사설 경로를 확보하는 대신 고정·처리 비용이 생긴다.
S3 트래픽이 큰데 NAT를 통과한다면 gateway endpoint 사용 가능성을 검토한다. 다만 bucket policy의 source 조건·기존 연결·DNS·다른 소비자 영향까지 확인해야 한다. 수치 견적은 Region과 실제 요금표·사용량으로 계산한다. NAT 비용 최적화
8. 완성된 운영 적용 — private fleet의 외부 호출 실패
가정: 배포 후 private subnet의 EC2가 외부 API를 호출하지 못한다.
- 실패 hostname·IP·port·AZ·시각을 고정한다.
- DNS가 기대한 주소를 반환하는지 확인한다.
- 실제 연결 subnet의 route가 올바른 NAT 또는 endpoint를 가리키는지 본다.
- NAT의 인터넷 경로라면 IGW까지 이어지는지 확인한다.
- 출발 SG 송신, 경계 NACL의 요청·응답, 목적지 접근 제한을 대조한다.
- 일부 AZ만 실패하면 AZ별 route·NAT 배치를 비교한다.
- 최소 변경 뒤 실제 호출 결과와 오류율을 확인하고 전송 경로·비용도 확인한다.
이 절차는 설명용 사례다. 시험에서는 요구에 맞는 경로·보호·비용 수단을 고르고 운영에서는 실제 왕복 연결을 검증한다. 범위: Domain 5 Task 5.1.
계획과 연결
-
ID:
13-vpc-connectivity-protection-and-cost -
의존:
01-operational-signals-and-evidence,11-identity-multi-account-and-continuous-compliance -
결정 축: 출발지·목적지·주소·경로·상태성·보호 계층·전송 비용을 한 경로 모델 안에서 구분한다.
-
범위: VPC, subnet, route table, security group, network ACL, NAT gateway, internet gateway, egress-only internet gateway, VPC endpoints, PrivateLink, VPC peering, Route 53 Resolver DNS Firewall, WAF, Shield, Network Firewall, network architecture cost.
-
시험 매핑: Domain 5, Task 5.1.