Amazon ANS-C01: 컨테이너 및 서버리스 네트워킹 — 학습 가이드

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

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

EKS 네트워킹 (CNI, 파드 네트워킹)

Amazon EKS의 파드 네트워킹은 Amazon VPC CNI 플러그인(amazon-vpc-cni-k8s)이 주도하며, 이 플러그인은 각 파드에 VPC의 IP 주소를 할당하고 파드 트래픽을 VPC 네트워크에 직접 배치합니다. 이러한 설계는 예측 가능한 VPC 수준의 보안 제어(보안 그룹, NACL)와 짧은 지연 시간의 라우팅을 제공하지만, ENI당 보조 IPv4 주소 수와 인스턴스 유형당 ENI 수가 하드웨어적으로 제한되기 때문에 신중한 IP 주소 및 ENI 용량 계획이 필요합니다. aws-node 데몬셋이 IP 할당 및 연결/분리 작업을 수행하며, 동작을 조정하기 위해 kubectl로 ConfigMap을 편집합니다(예: WARM_IP_TARGET, WARM_ENI_TARGET 또는 ENABLE_PREFIX_DELEGATION 설정). Prefix delegation(접두사 위임) 및 pod ENI 모드는 노드가 전체 /28 접두사를 ENI에 할당하도록 허용하거나(ENABLE_PREFIX_DELEGATION=true) 파드당 전용 ENI를 할당(높은 보안 격리에 유용)함으로써 노드별 IP 고갈을 줄여줍니다.

Cilium(eBPF)이나 Calico와 같은 Amazon VPC CNI의 대안은 다른 장단점을 제공할 수 있습니다. Cilium은 kube-proxy를 대체하고 eBPF를 사용하여 고성능 L3/L4 포워딩을 구현할 수 있으며, 노드 간 투명한 암호화(WireGuard 또는 IPsec)를 활성화하고, 오버레이 또는 마스커레이딩 접근 방식을 사용하여 노드 수준의 IP 부족 문제를 줄일 수 있습니다. Cilium을 사용하면 여전히 egress 및 ingress를 위해 VPC 라우팅과 통합하지만, 빈번한 ENI 연결/분리 작업을 피할 수 있습니다. 이는 파드 교체율(churn rate)이 높을 때 중요합니다. 매우 많은 연결 수와 엄격한 L7 동작이 요구되는 경우, kube-proxy 모드(IPVS) 튜닝 및 노드 커널 설정도 고려해야 합니다. 수천 개의 동시 장기 gRPC 연결 하에서 임시 포트(ephemeral port) 고갈을 피하기 위해 conntrack_max, tcp_tw_recycle/tcp_tw_reuse, ip_local_port_range를 조정하고, 이를 kubelet이나 데몬셋 초기화 스크립트를 통해 노출해야 합니다.

ECS 네트워킹 모드 및 Lambda VPC 통합

ECS 태스크 네트워킹에는 bridge, host, awsvpc의 세 가지 주요 모드가 있습니다. awsvpc 모드는 각 태스크(또는 태스크 그룹)에 ENI를 연결하고 프라이빗 IP와 보안 그룹을 태스크에 직접 할당하므로 Kubernetes 파드 네트워킹과 가장 유사합니다. awsvpc를 구성하려면 RunTask 또는 CreateService API 호출에서 awsvpcConfiguration에 서브넷과 securityGroups를 지정합니다. Fargate는 awsvpc 모드를 강제하므로 태스크 수준의 네트워크 격리를 제공하고 서비스 검색을 위해 AWS Cloud Map과 통합됩니다. 태스크별로 보안 그룹 기반 트래픽 필터링이 필요하거나 표준 VPC 라우팅 및 지표를 노출해야 할 때 awsvpc를 사용합니다.

VPC 액세스가 필요한 Lambda 함수는 함수에 구성된 서브넷 및 보안 그룹의 ENI를 통해 VPC에 연결됩니다. 이 ENI는 Lambda 컨트롤 플레인에 의해 생성 및 관리되지만, ENI 프로비저닝은 콜드 스타트 지연 시간을 추가할 수 있으며, 프로비저닝된 동시성(provisioned concurrency)으로 완화하거나 VPC 엔드포인트(AWS PrivateLink)와 신중하게 설계된 서브넷 아키텍처를 사용하지 않는 한 과거에는 빠른 스케일업을 제한했습니다. 많은 Lambda 함수를 VPC에 배치할 때는 서브넷에 사용 가능한 IP가 있는지 확인하고, 필요에 따라 egress를 위해 NAT Gateway 또는 NAT 인스턴스를 사용하며, 가능한 경우 인터넷을 통한 egress 라우팅을 피하기 위해 VPC 엔드포인트(AWS::EC2::VPCEndpoint를 통한 com.amazonaws.* 엔드포인트)를 선호해야 합니다. CloudWatch Logs 및 VPC Flow Logs를 사용하여 ENI 연결/분리 작업을 모니터링하여 스케일링 동작을 관찰하고 동시성 관련 스로틀링 문제를 해결합니다.

App Mesh 및 서비스 검색

AWS App Mesh는 Envoy 사이드카를 데이터 플레인으로 사용하며 L3–L7 가시성, 트래픽 셰이핑, 재시도, TLS 시작/종료 제어 기능을 제공합니다. App Mesh API(CreateMesh, CreateVirtualNode, CreateVirtualService) 또는 Kubernetes용 App Mesh 컨트롤러를 통해 메시, 가상 노드, 가상 서비스를 정의합니다. App Mesh는 VirtualNode 리스너의 TLS 블록에 clientPolicy와 인증 기관(certificate authority)을 구성하여 mTLS를 지원하며, 인증서 배포를 위해 AWS Certificate Manager(ACM) 또는 SDS와 통합할 수 있습니다. 그러나 App Mesh 사이드카는 설계상 트래픽을 종료하고 다시 암호화한다는 점에 유의해야 합니다. 만약 클라이언트와 애플리케이션 파드 간에 애플리케이션 트래픽이 종단 간(end-to-end) 암호화 상태를 유지해야 하는 요구사항이 있다면(네트워크 프록시에서 복호화 없음), TLS가 메시 인그레스나 로드 밸런서가 아닌 파드에서만 종료되도록 해야 합니다.

서비스 검색은 일반적으로 EKS의 경우 Kubernetes Service와 CoreDNS, 크로스 플랫폼의 경우 Cloud Map(CreateService, RegisterInstance), DNS 기반 조회의 경우 Route 53 프라이빗 호스팅 영역을 사용하여 수행됩니다. AWS Cloud Map은 ECS 및 App Mesh와 직접 통합되어 SRV 또는 A 레코드 및 API 기반 상태 확인을 활성화합니다. 인스턴스가 빠르게 확장되는 동적 환경에서는 오래된(stale) 레코드 조회를 피하기 위해 짧은 DNS TTL과 Cloud Map 상태 확인을 결합해야 합니다. 즉각적인 일관성이 필요한 경우, DNS 캐싱에 의존하는 대신 서비스 메시 컨트롤 플레인 API를 사용하여 엔드포인트를 가져와야 합니다.

설계 패턴과 트레이드오프

mTLS를 사용하는 대규모 gRPC over TLS를 설계할 때는 TLS를 어디서 종료할지 결정해야 합니다. 로드 밸런서(ALB)에서 TLS를 종료하면 인증서를 ACM으로 오프로드하고 인증서 교체를 단순화할 수 있지만, 종단 간 암호화(end-to-end encryption)가 깨지고 백엔드가 전달된 클라이언트 인증서 정보로 TLS를 다시 설정하지 않는 한 백엔드 파드에 상호 TLS(mutual TLS)를 제공할 수 없습니다. 애플리케이션 엔드포인트가 클라이언트를 직접 인증하는 진정한 종단 간 mTLS를 위해서는 Network Load Balancer와 같은 L4 패스스루(passthrough) 게이트웨이를 사용하고 파드/애플리케이션이 TLS/mTLS를 처리하도록 해야 합니다. NLB의 target-type을 ip로 설정하고 AWS Load Balancer Controller 어노테이션

undefined

을 함께 사용하여 파드 IP를 직접 등록합니다. 이 패턴은 NLB가 수백만 개의 연결을 처리하도록 설계되었고 TLS를 종료하지 않고도 오래 지속되는 TCP/gRPC 세션을 지원하므로 확장성이 뛰어납니다.

HTTPS를 종료하는 인그레스(ingress) 및 경로 기반 라우팅에는 호스트/경로 규칙, 리디렉션, WAF와의 통합을 지원하므로 Application Load Balancer가 더 적합합니다. ALB가 TLS를 종료할 때 클라이언트 IP를 보존하려면 X-Forwarded-For 헤더를 사용해야 합니다. 백엔드 웹 서버는 X-Forwarded-For를 사용하고 로그에 기록해야 하며, 확인을 위해 ALB 액세스 로그를 활성화해야 합니다. 서버 계층에서 실제 클라이언트 소켓 주소가 필요한 경우(레거시 소프트웨어 등), NLB와 proxy protocol v2를 사용하고 백엔드 서비스가 프록시 프로토콜을 지원하는지 확인해야 합니다.

여러 AWS 계정과 VPC에 걸친 서비스 연결은 패턴에 따라 확장성이 다릅니다. VPC peering은 간단하지만 관리가 N^2으로 복잡해집니다. Transit Gateway는 라우팅을 중앙 집중화하고 라우팅 테이블 분리를 통해 많은 VPC에 대해 더 나은 확장성을 제공합니다. AWS PrivateLink(Interface VPC Endpoint)는 NLB를 통해 엔드포인트 서비스를 노출하고 소비자가 자신의 VPC에 인터페이스 엔드포인트를 생성하는 방식이므로, 서비스별로 가장 세분화된 ID 인식 액세스 모델을 제공합니다. 엄격한 액세스 제어와 확장 가능한 온보딩이 필요한 다중 계정 공유 서비스의 경우, 라우팅을 격리하고(소비자 VPC의 라우팅 테이블 변경 없음) 보안 그룹을 사용하여 세분화된 제어를 할 수 있으므로 PrivateLink를 사용하는 것이 좋습니다.

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

반복되는 함정 중 하나는 모든 워크로드에 동일한 네트워킹 모델이 적합하다고 가정하는 것입니다. 상태 저장(stateful) 또는 장기 연결(long-lived connection) 워크로드(gRPC, 데이터베이스)는 프록시로 인한 지연 시간을 피하기 위해 파드 수준 TLS 종료 또는 hostPort/hostNetwork 패턴과 함께 L4 패스스루(NLB)를 선호합니다. 반면 경로 기반 라우팅, WAF 또는 WebSocket 종료가 필요한 HTTP 마이크로서비스는 ALB 및 App Mesh 기능의 이점을 누릴 수 있습니다. 또 다른 실수는 awsvpc 모드에서 EKS 노드나 ECS 태스크를 확장할 때 ENI/IP 한도를 고려하지 않는 것입니다. 항상 EC2 인스턴스 유형별 ENI 및 ENI당 IP 테이블을 참조하고, 높은 파드 밀도가 필요할 때는 접두사 위임(prefix delegation)이나 Cilium 오버레이를 사용해야 합니다.

모니터링과 디버깅에는 여러 소스가 필요합니다. 트래픽 이그레스/인그레스를 확인하기 위한 VPC Flow Logs 및 ENI 지표, AWS Load Balancer용 CloudWatch 지표(ActiveFlowCount, ProcessedBytes), 그리고 Envoy/App Mesh 또는 AWS X-Ray 에이전트로부터의 애플리케이션 수준 원격 측정(telemetry)이 그것입니다. Lambda와 Fargate의 경우, ENI 작업과 관련된 콜드 스타트는 프로비저닝된 동시성(provisioned concurrency)으로 완화하거나, 함수에 광범위한 이그레스가 필요하지 않도록 VPC 엔드포인트와 PrivateLink를 사용하도록 액세스 패턴을 재설계하여 해결할 수 있다는 점을 기억하십시오.

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

회사명: Acme Payments Inc. 과제: Acme Payments는 Amazon EKS에서 gRPC 서비스를 운영합니다. 이 서비스는 TCP 포트 443에서 수천 개의 동시 TLS 연결을 지원해야 하고, 클라이언트 인증서가 백엔드 서비스에 의해 검증되도록 상호 TLS(mTLS)를 사용해야 합니다. 또한 연결이 끊어지거나 로드 밸런서에서 TLS 종료가 필요 없이 Cluster Autoscaler와 HPA를 통해 EKS 클러스터가 자동 확장될 수 있어야 합니다.

단계별 접근 방식:

애플리케이션 또는 외부 클라이언트에 대한 엔드투엔드 TLS를 종료하지 않는 사이드카에 파드 수준 TLS 및 상호 인증을 구현하여 서비스를 배포합니다. 서버/클라이언트 인증서를 AWS Secrets Manager에 저장하고 Kubernetes CSI secrets store를 통해 마운트하거나, 파드 생명주기와 함께 작동하는 인증서 배포 메커니즘을 사용합니다.
AWS Load Balancer Controller를 사용하여 Service에 어노테이션(service.beta.kubernetes.io/aws-load-balancer-type: “nlb”)을 추가하여 Network Load Balancer를 생성하고, 대상 유형을 IP(service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”)로 설정한 다음, 포트 443에 TCP 리스너를 생성합니다. 이렇게 하면 NLB가 L4 패스스루를 수행하고 TLS를 종료하지 않도록 보장합니다.
NLB 대상 그룹을 프로토콜 TCP로 구성하고 파드 IP를 동적으로 등록합니다(Load Balancer Controller가 CreateTargetGroup 및 RegisterTargets를 호출함). 오토스케일링 중에 대상이 신속하게 정상으로 표시되도록 상태 확인을 TCP 또는 짧은 간격의 사용자 지정 TCP 기반 상태 프로브로 설정해야 합니다 (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
높은 파드 밀도를 지원하고 ENI 변동(churn)을 줄이도록 Amazon VPC CNI를 조정합니다. 지원되는 경우 접두사 위임(prefix delegation)을 활성화하고(aws-node ConfigMap에서 ENABLE_PREFIX_DELEGATION=true로 설정), 여분 주소를 유지하도록 WARM_IP_TARGET를 구성하고, aws-node 지표(kube-system 데몬셋 로그 및 CloudWatch 사용자 지정 지표)를 모니터링합니다. 노드 수준 IP 한도가 우려되는 경우, 더 높은 파드 밀도와 감소된 ENI 작업을 위해 eBPF와 함께 Cilium을 고려합니다.
클러스터를 안전하게 확장합니다. Cluster Autoscaler에 적절한 노드 그룹 태그와 IAM 권한이 있는지 확인하고, PodDisruptionBudgets를 설정하며, 스케일 다운 중에 장기 실행 gRPC 연결이 끊어지는 것을 방지하기 위해 대상 그룹 상태 확인과 NLB 연결 드레이닝이 구성되었는지 확인합니다.
인증서 교체 및 신뢰를 보안합니다. ACM Private CA 또는 Secrets Manager로 인증서 교체를 자동화하고, 파드가 NLB 재구성 없이 업데이트된 신뢰 번들(trust bundles)을 검색하도록 보장합니다. mTLS 핸드셰이크 준비 상태를 반영하는 Kubernetes readiness/liveness 프로브를 사용합니다.

AWS의 논리적 근거: IP 대상 모드의 Network Load Balancer는 파드까지의 TLS(진정한 엔드투엔드 암호화)를 보존하고 수백만 개의 영구 TCP 연결을 지원하므로 수천 개의 동시 gRPC 세션에 적합합니다. 파드 IP를 직접 등록하면 노드별 hostPort 또는 인스턴스 대상 등록의 복잡성을 피할 수 있으며, AWS Load Balancer Controller가 파드 확장에 따라 파드 IP를 등록 및 등록 취소하므로 Cluster Autoscaler/HPA와 깔끔하게 연동됩니다. VPC CNI를 조정하거나 eBPF 기반 데이터 플레인을 채택하면 IP 고갈을 방지하고 ENI 연결/분리 지연 시간을 줄일 수 있으며, 이는 빠른 오토스케일링과 높은 연결 수의 워크로드에 필수적입니다. Secrets Manager 또는 CSI 프로바이더를 통해 mTLS 아티팩트를 저장하고 전달하면 로드 밸런서를 건드리지 않고도 인증서 생명주기를 관리하기 쉽게 만듭니다.

← 자동화 · 모든 도메인

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