Amazon ANS-C01: VPC 설계 및 고급 네트워킹 — 학습 가이드

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Advanced Networking Specialty ANS-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

VPC 아키텍처 및 서브넷팅 기본

VPC는 AWS의 기본 네트워킹 경계이며, CIDR 할당 방식이 그 이후의 모든 것을 결정합니다. 미래의 성장과 계정 간 연결성을 염두에 두고 CIDR 블록을 계획해야 합니다. 계정/리전별로 겹치지 않는 큰 주소 공간(예: 환경당 /16)을 할당하고, 이를 /20–/24 서브넷으로 세분화하여 기능 및 가용 영역별로 워크로드를 격리합니다. EKS 및 기타 컨테이너 플랫폼은 파드 ENI 또는 보조 IP를 위해 IP 주소를 사용한다는 점을 기억해야 합니다. AWS VPC CNI는 VPC 서브넷에서 파드 IP를 할당하며, 인스턴스별 ENI/IP 제한(DescribeInstanceTypes)은 최대 파드 밀도를 제약합니다. IPv6를 도입할 때는 듀얼 스택 설계를 선호하여 외부 공개 서비스는 IPv6로 오프로드하고 레거시 통합을 위해 IPv4는 유지하는 것이 좋습니다. API 호출 aws ec2 associate-vpc-cidr-block --vpc-id <vpc> --amazon-provided-ipv6-cidr-block을 사용하여 Amazon에서 제공하는 IPv6 CIDR 블록을 연결하고, create-subnet과 --ipv6-cidr-block 옵션을 사용하여 서브넷 수준에서 IPv6 할당을 활성화합니다. IPv4 이그레스(egress)를 위해서는 NAT 리소스를 계획하고, IPv6의 경우 CreateEgressOnlyInternetGateway로 생성하여 VPC에 연결하는 Egress-Only Internet Gateway를 사용합니다.

라우팅 테이블과 서브넷 배치는 토폴로지와 복원력을 강제하는 방법입니다. CreateRouteTable과 CreateRoute를 사용하여 서브넷 목적(퍼블릭, NAT가 있는 프라이빗, Direct Connect가 있는 프라이빗, 격리됨)에 따라 별도의 라우팅 테이블을 생성합니다. 단일 AZ 이그레스 장애를 방지하려면 여러 AZ에 걸쳐 다수의 NAT Gateway(또는 오토스케일링을 사용하는 NAT 인스턴스)를 사용하십시오. Transit Gateway(CreateTransitGateway, CreateTransitGatewayRouteTable)를 사용할 때는 의도한 곳에만 온프레미스 프리픽스가 주입되도록 전파된 라우팅을 명시적으로 관리해야 합니다. 계정 내부의 서비스 디스커버리를 위해서는 Route 53 프라이빗 호스팅 영역을 사용하고, 경계를 넘어 DNS 정보가 유출되지 않도록 레코드가 필요한 VPC와 연결합니다.

주요 서비스 및 구성 세부 정보

프라이빗 연결을 위해서는 VPC Peering, AWS Transit Gateway, AWS PrivateLink(인터페이스 VPC 엔드포인트)라는 세 가지 주요 구성을 이해해야 합니다. VPC Peering(CreateVpcPeeringConnection, AcceptVpcPeeringConnection)은 간단하고 저렴한 포인트-투-포인트 연결 방식으로, 라우팅 테이블 항목이 필요하며 전이적 라우팅(transitive routing)은 지원하지 않습니다. Transit Gateway(CreateTransitGateway, CreateTransitGatewayVpcAttachment)는 수천 개의 VPC를 지원하고 중앙 집중식 라우팅 제어 및 하이브리드 연결을 위한 Direct Connect Gateway와의 통합을 제공하는 확장 가능한 허브입니다. Transit Gateway 내에서 라우팅 테이블 전파 및 라우팅 테이블 연결을 사용하여 동서(east-west) 트래픽 흐름을 제어합니다. PrivateLink(CreateVpcEndpointServiceConfiguration으로 NLB 기반 서비스를 등록하고 CreateVpcEndpoint로 인터페이스 엔드포인트를 생성)는 VPC를 라우팅에 노출하지 않고 계정 간에 서비스를 노출하여, 서비스별 세분화된 보안과 간소화된 보안 그룹 제어를 제공합니다. 소비자가 인터페이스 엔드포인트를 생성하고 트래픽이 NIC 수준에 머무르기 때문에 확장성이 뛰어납니다.

로드 밸런싱과 클라이언트 IP 보존은 올바르게 설계해야 하는 일반적인 고려 사항입니다. Application Load Balancer(ALB)는 TLS를 종료하고, L7에서 라우팅하며(CreateLoadBalancer Type application), 백엔드가 클라이언트 IP 로깅을 위해 신뢰해야 하는 X-Forwarded-For/X-Forwarded-Proto 헤더를 주입합니다. Network Load Balancer(NLB)는 대상 그룹에 대해 소스 IP를 보존하고 수백만 개의 연결을 지원합니다. 백엔드로 완전한 TLS 패스스루(pass-through)를 구현하려면 TCP 리스너(CreateListener Protocol TCP)가 있는 NLB를 사용하고 대상을 IP별로 등록하여 암호화된 세션이 파드나 인스턴스에 그대로 도달하도록 합니다. gRPC 및 매우 높은 연결 수가 필요한 경우, EKS 앞에 대상 유형을 ip로 설정한 NLB를 배치하고 AWS Load Balancer Controller 어노테이션 service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"를 사용하여 파드 IP를 직접 등록하는 것을 선호합니다. 이 조합은 소스 IP를 유지하고, 파드에서의 mTLS 종료를 지원하며, 오토스케일러와 함께 확장됩니다.

VPC 엔드포인트는 AWS API 및 많이 사용되는 서비스에 대한 인터넷 이그레스를 제거합니다. S3 및 DynamoDB용 게이트웨이 엔드포인트(CreateVpcEndpoint와 --service-name com.amazonaws.<region>.s3 사용)는 엔드포인트 프리픽스 목록에 라우팅을 추가하며 무료입니다. 인터페이스 엔드포인트(CreateVpcEndpoint와 --vpc-endpoint-type Interface 사용)는 프라이빗 IP와 보안 그룹을 가진 탄력적 네트워크 인터페이스(ENI)를 생성합니다. 시간당 및 GB당 요금이 부과되지만, NLB 기반 서비스와 결합하면 PrivateLink 방식의 사용 및 계정 간 액세스가 가능해집니다.

설계 패턴과 장단점

여러 계정에 걸쳐 다수의 사업부가 사용하는 중앙 공유 서비스의 경우, 연결별 제어 및 격리가 필요할 때 PrivateLink와 엔드포인트 서비스가 가장 안전하고 확장 가능한 패턴입니다. 공유 서비스 VPC의 Network Load Balancer 뒤에 서비스를 호스팅하고, VPC 엔드포인트 서비스(CreateVpcEndpointServiceConfiguration)를 생성한 후, 소비자 계정에서 인터페이스 엔드포인트를 생성하도록 하여 이를 승인합니다. 이 방식은 풀 메시(full mesh)를 방지하고 전이 라우팅(transitive routing)을 막아주며, 인터페이스 엔드포인트의 보안 그룹을 통해 어떤 소비자가 연결할 수 있는지 제한할 수 있습니다. 반대급부로 엔드포인트별 비용이 발생하고 엔드포인트 연결을 수락하고 감사하는 데 약간의 관리 오버헤드가 있습니다.

Transit Gateway는 다수의 VPC가 광범위한 연결, 중앙 집중식 검사, 그리고 Direct Connect를 통해 온프레미스 접두사를 광고할 단일 지점이 필요할 때 특히 유용합니다(CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). 라우팅 테이블 분할 및 전파 제어를 사용하여 의도치 않은 수평적 이동(lateral movement)을 방지하십시오. Transit Gateway는 라우팅 우선순위 지정과 라우팅 테이블 연결을 지원하므로 신뢰도가 낮은 네트워크로부터 프로덕션 트래픽을 격리할 수 있습니다. 단점은 Transit Gateway가 트래픽을 중앙 집중화하여 로컬로 처리될 수 있었던 VPC 간 트래픽에 비용을 발생시킬 수 있다는 점입니다. 또한 장애 도메인을 변경하고 주소 중복을 방지하기 위해 신중한 CIDR 계획이 필요합니다.

CIDR 재사용이 제한적인 하이브리드 아키텍처의 경우, Direct Connect를 Transit Gateway 및 Direct Connect Gateway(CreateDirectConnectGateway)와 결합하여 가상 인터페이스(VIF) 수를 줄이는 것을 고려하십시오. 공유 물리적 링크에서 사업부별 대역폭 격리가 필요하다면, 여러 개의 프라이빗 가상 인터페이스를 배치하고 VIF별 CloudWatch 지표(지표 이름: AWS/DX: BytesIn, BytesOut 등)를 모니터링하며 VIF 수준의 CloudWatch 경보를 사용하십시오. 사용량이 많은 소비자를 식별하려면 VPC Flow Logs(CreateFlowLogs)를 S3 또는 CloudWatch Logs로 활성화하고 Athena 또는 CloudWatch Logs Insights로 분석하십시오. VM별 패킷 캡처가 필요하다면 짧은 시간 동안 Traffic Mirroring(CreateTrafficMirrorSession)을 사용하십시오.

IPv6 채택과 듀얼 스택 설계는 NAT 의존도를 줄이고, NAT Gateway 처리량 비용을 낮추며, 클라이언트 대면 주소 지정을 단순화합니다.

undefined

API 호출을 사용하여 Amazon이 제공하는 IPv6 접두사를 할당하고 IPv6 CIDR 블록으로 서브넷을 생성하십시오. 일부 서비스 및 서드파티 어플라이언스는 IPv6를 지원하지 않을 수 있다는 점에 유의해야 합니다. 이 경우 로드 밸런서에서 듀얼 스택(IpAddressType dualstack으로 CreateLoadBalancer)을 사용하여 IPv4와 IPv6 클라이언트를 모두 지원하면서 백엔드 시스템은 IPv4로 유지할 수 있습니다.

일반적인 함정과 의사결정 기준

Kubernetes 파드의 IP 주소 소모를 간과하는 것은 서비스 중단의 흔한 원인입니다. 인스턴스 유형별 ENI 및 보조 IP 제한을 고려하고, WARM_IP_TARGETS나 접두사 위임(prefix delegation)과 같은 VPC CNI 설정을 사용하여 IP 가용성을 개선하십시오. L7에서 클라이언트 IP를 보존하지 못하는 것도 또 다른 일반적인 문제입니다. 로드 밸런서에서 TLS를 종료해야 하는 경우, 애플리케이션이 X-Forwarded-For를 읽도록 하고 ALB 보안 제어가 직접적인 접근을 제한하여 헤더를 신뢰할 수 있도록 해야 합니다. VPC 피어링이 무한정 확장될 것이라고 가정하면 관리 불가능한 메시 구조로 이어지는 경우가 많습니다. 다대다(many-to-many) 연결에는 Transit Gateway를, 세분화된 보안 및 트래픽 격리가 필요한 일대다(one-to-many) 서비스 노출에는 PrivateLink를 선호하십시오.

보안 정책은 보안 그룹과 네트워크 ACL을 네임스페이스 수준의 제어와 함께 사용해야 합니다. 직접적인 ALB URL 대신 Global Accelerator를 통한 접근을 엄격하게 강제하려면, Global Accelerator IP 범위로 채워진 AWS WAF IP 세트(게시된 ip-ranges.json을 통해 자동화)를 사용하거나, ALB를 내부용으로 설계하고 Global Accelerator가 타겟으로 하는 NLB를 앞에 두어 Global Accelerator 프런트 도어만 노출하는 아키텍처를 사용하십시오. IP 기반 제어에 대한 업데이트는 항상 자동화하고, DescribePrefixLists 및 정기적인 ip-ranges.json 수집을 통해 검증하십시오.

실용적인 문제: 사용 사례 시나리오

회사: Equinox Payments. 과제: Equinox는 EKS 기반 gRPC 서비스를 운영하며, 수천 개의 동시 연결에 대한 종단 간 mTLS, Cluster Autoscaler 및 HPA를 통한 오토스케일링, 로깅을 위한 클라이언트 IP 보존이 필요합니다. 접근 방식: 1) AWS Load Balancer Controller를 통해 포트 443에 TCP 리스너를 구성한 Network Load Balancer 뒤에 서비스를 배포하고,

undefined

어노테이션을 사용하여 파드 IP가 타겟으로 등록되도록 합니다. 2) NLB가 아닌 파드에서 TLS를 종료하고 애플리케이션에서 상호 TLS(서버 및 클라이언트 인증서 검증)를 구현하며, 인증서에는 Kubernetes Secrets를, 타겟 등록을 위해서는 준비성 프로브(readiness probe)를 사용합니다. 3) 클라이언트 소스 IP를 보존하기 위해 타겟 유형을 ip로 사용하고, 중간 어플라이언스를 위해 필요한 경우에만 프록시 프로토콜을 활성화하며, TCP 연결에서 클라이언트 IP를 캡처하기 위해 파드 측 로깅에 의존합니다. 4) 헬스 체크를 TCP 또는 gRPC 인식 준비성 프로브로 구성하고, Cluster Autoscaler 정책과 노드 인스턴스 유형이 충분한 ENI 및 IP 용량을 갖도록 보장합니다. 5) CloudWatch Container Insights와 VPC Flow Logs(CreateFlowLogs)를 구현하여 연결 수와 VPC 수준의 원격 측정 데이터를 모니터링합니다. AWS 근거: TCP 리스너가 있는 NLB는 암호화된 세션과 소스 IP를 보존하면서 수백만 개의 연결로 확장할 수 있습니다. target-type ip는 파드가 NAT 없이 소스 IP를 직접 수신할 수 있게 합니다. 파드에서 mTLS를 종료하면 종단 간 암호화와 양방향 인증 요구사항을 충족합니다. 파드의 준비 상태가 타겟 등록에 직접 영향을 미치고 NLB가 연결 부하에 따라 투명하게 확장되므로 오토스케일링이 원활하게 작동합니다.

모든 도메인 · 하이브리드 연결: VPN 및 Direct Connect →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →