Amazon ANS-C01: 자동화, IaC 및 네트워크 운영 — 학습 가이드

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

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

핵심 개념

AWS 네트워킹을 위한 코드형 인프라(Infrastructure as Code)는 네트워크 토폴로지, 보안 정책, 라우팅을 선언적 템플릿과 결정론적 수명 주기 작업으로 전환합니다. CloudFormation 템플릿(AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup)은 원하는 상태를 인코딩하고, CloudFormation API(CreateStack, UpdateStack, DeleteStack, DescribeStacks, ChangeSet 작업)는 변경 사항을 원자적으로 적용합니다. 중첩 스택과 모듈식 템플릿을 사용하여 네트워킹 도메인(공유 서비스, 계정별 애플리케이션 VPC, 인그레스/이그레스 영역)을 격리하고, StackSets를 사용하여 AWS Organizations 전반에 일관된 네트워크 스택을 전파합니다. 드리프트 탐지(DetectStackDrift)와 변경 세트는 가드레일을 제공하여, 자동화가 대역 외(out-of-band) 네트워크 변경을 탐지하고 사람의 검토를 요구할 수 있도록 합니다.

자동화는 CloudFormation이 기본적으로 표현할 수 없거나 수명 주기 후크가 필요한 네트워크 부분도 다루어야 합니다. 예를 들어 계정 간 리소스 공유, 온프레미스 통합, 호스트의 런타임 구성 등이 있습니다. CloudFormation 사용자 지정 리소스(Lambda 기반) 또는 CloudFormation 모듈은 CreateResourceShare(AWS RAM)와 같은 API를 호출하여 Transit Gateway나 서브넷을 공유하거나, Systems Manager(SSM) SendCommand를 호출하여 인스턴스에 인증서나 라우팅 정책을 주입할 수 있습니다. EKS의 Kubernetes의 경우, AWS Load Balancer Controller는 Helm을 통해 설치되고 서비스 어노테이션을 통해 관리됩니다. CloudFormation은 AWS::EKS::Cluster와 사용자 지정 리소스를 통해 IAM 역할, OIDC 공급자, HelmRelease 객체를 프로비저닝할 수 있지만, 파드 IP와 NLB 대상 그룹 간의 런타임 매핑은 컨트롤러가 처리합니다.

주요 서비스 및 구성

네트워크 운영을 자동화할 때 반복적으로 사용하게 될 주요 AWS 서비스와 API는 다음과 같습니다: CloudFormation(CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager(CreateResourceShare, AssociateResourceShare), AWS Transit Gateway(CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2(CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda(CreateFunction, AddPermission, Invoke), Systems Manager(PutParameter, SendCommand, CreateDocument), AWS Config(PutEvaluations, StartConfigurationRecorder). 이러한 서비스들은 안전하고 감사 가능한 네트워킹을 위한 일반적인 자동화 스택을 형성합니다.

템플릿과 자동화를 설계할 때 특정 리소스 속성과 컨트롤러 어노테이션에 주의를 기울여야 합니다. 로드 밸런서의 경우, 올바른 유형과 속성을 선택해야 합니다. TCP 리스너가 있는 NLB는 소스 IP를 보존하고, CreateLoadBalancer/ModifyTargetGroupAttributes 및 대상 그룹에 “proxy_protocol_v2.enabled” 설정을 통해 Proxy Protocol v2를 지원합니다. ALB(Application Load Balancer)는 TLS를 종료하고 클라이언트 IP에 대한 X-Forwarded-For 헤더를 삽입하며, HTTPS 리스너로 구성 시 gRPC/HTTP2를 지원합니다. EKS의 경우, service.beta.kubernetes.io/aws-load-balancer-type: "nlb"와 같은 어노테이션이나 AWS Load Balancer Controller의 Ingress/Service 어노테이션을 사용하여 TLS 통과(passthrough) 대 종료(termination)를 제어하고, 직접적인 파드 타겟팅을 위해 대상 유형을 ip로 설정합니다. 계정 간 공유 및 다중 계정 네트워크의 경우, AWS RAM을 사용하여 Transit Gateway를 공유하고, CloudFormation StackSets를 위임된 관리자 역할과 결합하여 소비자 계정에서 연결(attachment) 및 액세스를 생성합니다.

설계 패턴과 장단점

일반적이면서 대조적인 두 가지 패턴은 Transit Gateway를 이용한 허브 앤 스포크(hub-and-spoke)와 AWS RAM을 통한 공유 VPC입니다. Transit Gateway를 이용한 허브 앤 스포크는 라우팅, 검사, VPC 간 연결을 중앙 집중화합니다. 연결(attachment)과 라우팅 테이블이 세분화를 허용하므로 확장성이 좋고, RAM을 사용하여 TGW를 공유할 수 있어 다른 계정들이 전체 소유권을 이전하지 않고도 연결을 생성할 수 있습니다. 단점은 경로 전파와 라우팅 테이블 제한입니다. Transit Gateway 라우팅 테이블과 연결 제한은 계획이 필요하며, 정책을 강제해야 하는 단일 지점이 생길 수 있습니다(트래픽을 격리하려면 여러 라우팅 테이블과 AWS Network Firewall을 사용하세요). 공유 VPC(AWS RAM을 통한 VPC 공유)는 호스트 계정에 서브넷을 배치하고 소비자 계정이 해당 서브넷에 리소스를 시작할 수 있도록 합니다. 이는 연결에 대한 중앙 보안 제어를 단순화하지만, 보안 그룹 소유권과 IAM 경계를 신중하게 관리해야 하므로 계정 수준의 자율성을 감소시키고 비즈니스 단위별 네트워크 격리를 복잡하게 만듭니다.

인그레스 및 TLS 종료의 경우, 엔드 투 엔드 암호화의 필요성과 확장성 및 클라이언트 IP 보존 사이에서 균형을 맞춰야 합니다. 로드 밸런서에서 TLS 종료가 필요한 경우(WAF, 인증서 중앙 관리, HTTP 라우팅 등), ALB가 적합한 도구입니다. ALB는 애플리케이션 로깅이 클라이언트 IP를 캡처할 수 있도록 X-Forwarded-For를 추가하며, 경로 및 호스트 기반 라우팅을 통해 여러 대상 그룹으로 트래픽을 보낼 수 있습니다. 로드 밸런서가 트래픽을 복호화해서는 안 되는 진정한 엔드 투 엔드 TLS 또는 mTLS가 필요한 경우, TCP 모드의 NLB를 사용하여 백엔드 엔드포인트(파드 또는 인스턴스)로 TLS를 통과시키고, Kubernetes에서 대상 유형을 ip로, externalTrafficPolicy: Local로 구성하여 소스 IP를 보존하세요. 수천 개의 동시 양방향 mTLS gRPC 연결의 경우, 원시 TLS를 파드 포트로 전달하는 NLB와 mTLS를 종료하는 파드를 결합하면 확장성과 진정한 엔드 투 엔드 암호화를 제공할 수 있으며, 이때 AWS Load Balancer Controller 어노테이션을 사용하여 적절한 NLB 리스너와 대상 그룹을 생성합니다.

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

자주 발생하는 함정은 TLS 종료 위치와 클라이언트 IP 요구사항을 혼동하는 것입니다. ALB는 TLS를 종료할 때 X-Forwarded-For를 제공하지만, NLB처럼 원본 IP를 대상으로 보존하지는 않습니다. 만약 ALB의 기능(호스트/경로 라우팅, WAF)과 백엔드에서의 원본 소스 IP가 모두 필요하다면, HTTP 종료를 위해 ALB를 사용하고 X-Forwarded-For에서 원본 IP를 재구성하는 리버스 프록시나 사이드카로 전달하는 방법을 고려하거나, NLB가 TLS를 mTLS를 수행하는 서비스로 통과시키고 HTTP 라우팅을 클러스터 내 프록시로 오프로드하는 아키텍처를 사용하세요. 또 다른 함정은 계정 간 권한을 잘못 구성하는 것입니다. Transit Gateway나 다른 네트워크 리소스를 RAM으로 공유할 때, 명시적인 리소스 공유와 올바른 IAM 역할 및 RAM 주체를 사용해야 합니다. 그렇지 않으면 불투명한 “permission denied” 오류가 발생합니다.

규정 준수 자동화와 관련하여, 개인 키나 CA 자료를 암호화되지 않은 평문으로 저장하지 마십시오. 접근이 필요한 역할과 주체만 허용하는 최소한의 키 정책을 가진 KMS 키와 함께 SSM Parameter Store SecureString을 사용하세요. AWS Config 관리형 규칙(예: vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check)을 사용하고, 관리형 규칙이 기준을 충족하지 못하는 경우 PutEvaluations를 호출하는 Lambda 기반 Config 규칙을 구현하세요. 수정 조치는 Config 수정 작업이 호출할 수 있는 SSM Automation 문서나 Systems Manager Run Command를 통해 자동화되어야 하지만, 고위험 변경에 대해서는 항상 알림 및 승인 경로를 제공해야 합니다.

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

회사: ApexTelemetrics — 과제: 전 세계적으로 접근 가능한 EKS 호스팅 gRPC 서비스를 제공해야 합니다. 이 서비스는 진정한 종단 간 상호 TLS(클라이언트와 서버가 mTLS로 인증)를 요구하며, TCP 443 포트를 통해 수천 개의 동시 장기 연결을 지원하고, 파드 자동 확장이 가능해야 하며, 인증서 배포 및 교체가 자동화되고 감사 가능하도록 보장해야 합니다.

접근 방식:

CloudFormation으로 네트워크 및 로드 밸런서 프로비저닝: TCP 리스너 포트 443과 targetType이 “ip"로 설정된 대상 그룹, 그리고 TCP 상태 확인을 갖춘 AWS::ElasticLoadBalancingV2::LoadBalancer를 통해 NLB를 생성합니다. VPC, 서브넷, NLB에 대해 CloudFormation CreateStack/UpdateStack과 모듈식 중첩 스택을 사용합니다. 각 Service가 NLB 대상 그룹을 파드에 직접 생성하도록 EKS Service에 AWS Load Balancer Controller 어노테이션(service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”)을 사용합니다.
파드에서 TLS 통과 및 mTLS 종료 보장: EKS Service가 TCP 443을 파드 포트로 직접 전달하도록 구성합니다. 각 파드 내에 클라이언트와의 mTLS 종료 및 상호 인증을 수행하는 사이드카 또는 envoy 프록시를 구현합니다. 필요한 경우 원본 IP가 보존되도록 Service에 externalTrafficPolicy: Local을 설정하고, 노드와 파드를 함께 확장하기 위해 Cluster Autoscaler와 함께 파드 수준 자동 확장(Horizontal Pod Autoscaler)을 사용합니다.
인증서 수명 주기 및 배포 자동화: CA 및 서버 인증서 개인 키를 KMS 키로 암호화된 SSM Parameter Store SecureString에 저장합니다. 스택 생성 중에 SSM 파라미터를 생성하기 위해 CloudFormation에 AWS Lambda 기반 사용자 지정 리소스를 생성합니다(적절한 IAM 역할로 CreateFunction 후, PutParameter를 호출하는 CloudFormation 사용자 지정 리소스). (IRSA를 통해) 파드에 바인딩된 IAM 역할을 통해 SSM에서 보안 암호를 가져오는 SSM Run Command 또는 불변의 DaemonSet을 사용하여 사이드카에 인증서를 주입합니다. 교체를 위해 Lambda 함수(CreateFunction + EventBridge 규칙)를 예약하여 새 인증서를 생성하고 PutParameter를 실행한 후, SSM 또는 Kubernetes Job을 사용하여 롤링 재시작을 수행합니다.
규정 준수 및 감사: AWS Config 규칙(vpc-flow-logs-enabled와 같은 관리형 규칙 및 PutEvaluations를 사용하는 사용자 지정 Lambda 기반 규칙)을 활성화하여 NLB 리스너가 TCP인지, 그리고 이 서비스를 위해 TLS를 종료하는 ALB가 없는지 확인합니다. 잘못된 구성이 감지되면 SSM Automation 문서를 호출하도록 Config 수정을 구성하고, 결과를 AWS Security Hub 및 CloudWatch Events로 전송합니다. AWS의 근거: TCP 모드의 NLB는 종단 간 mTLS에 필요한 진정한 TLS 통과(passthrough)를 제공하며, 로드 밸런서에서 연결당 적은 CPU 사용량으로 수천 개의 동시 연결로 확장됩니다. targetType=ip를 통해 파드를 타겟팅하면 추가적인 홉(hop)을 제거하고 자동 확장의 반응성을 유지합니다. KMS로 보호되는 SSM Parameter Store에 키를 저장하고 교체하면 IAM 제어를 통한 중앙 집중식, 감사 가능한 보안 암호 관리가 가능하며, CloudFormation과 Lambda 사용자 지정 리소스 및 EventBridge를 사용하면 전체 수명 주기가 코드화되고, 반복 가능하며, 관찰 가능하도록 보장됩니다.

← 네트워크 성능 및 모니터링 · 모든 도메인 · 컨테이너 및 서버리스 네트워킹 →

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