Amazon DOP-C02: 네트워킹 및 콘텐츠 전송 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

개요

AWS의 네트워킹 및 콘텐츠 전송은 기본적인 VPC 구성 요소, 다중 계정 및 하이브리드 토폴로지를 위한 상호 연결 선택, 전 세계적으로 애플리케이션을 보호하고 가속화하는 엣지 서비스를 포괄합니다. 이를 마스터하려면 VPC 내에서 패킷이 어떻게 이동하는지(서브넷, 라우팅 테이블, 게이트웨이, 필터링), VPC와 온프레미스 네트워크를 어떻게 상호 연결하는지(피어링, Transit Gateway, PrivateLink, Direct Connect, VPN), 그리고 엣지에서 트래픽을 어떻게 분산하고 보호하는지(CloudFront, AWS WAF, AWS Global Accelerator)를 이해해야 합니다. 그 다음 Amazon API Gateway와 같은 애플리케이션 진입점은 사용자 지정 도메인, 인증서, 엔드포인트 유형을 통해 이러한 기본 요소들과 통합됩니다.

VPC 아키텍처 및 보안 제어

VPC는 리전 단위의 논리적으로 격리된 네트워크이며, 각 가용 영역에 하나 이상의 서브넷을 가집니다. 장애 도메인과 기능에 따라 서브넷을 설계하십시오: 인터넷 연결 로드 밸런서 및 NAT 게이트웨이를 위한 퍼블릭 서브넷, EC2/ECS/EKS 노드를 위한 프라이빗 애플리케이션 서브넷, 데이터베이스를 위한 프라이빗 데이터 서브넷으로 구성합니다. 의도를 명확하게 하고 영역별 이그레스 설계를 지원하기 위해 서브넷 유형별로 별도의 라우팅 테이블을 할당하십시오.

인터넷 연결은 VPC 수준에 연결된 인터넷 게이트웨이(IGW)를 통해 제공됩니다. 서브넷의 라우팅 테이블에 IGW로 가는 기본 경로가 있고 리소스에 퍼블릭 IP 또는 탄력적 IP가 할당되면 해당 서브넷은 “퍼블릭"이 됩니다. 프라이빗 서브넷에서 아웃바운드 전용 인터넷 액세스를 위해서는 NAT 게이트웨이를 사용하십시오. 단일 장애 지점을 피하고 AZ 간 데이터 처리 요금을 줄이려면 가용 영역당 하나의 NAT 게이트웨이를 배치하고, 각 프라이빗 서브넷을 동일한 AZ의 NAT 게이트웨이로 라우팅하며, AZ 간 NAT는 비활성화하십시오. IPv6의 경우, 송신 전용 인터넷 게이트웨이가 NAT 없이 아웃바운드 전용 연결을 제공합니다.

라우팅 테이블은 대상 프리픽스에 대한 다음 홉을 결정합니다. 일반적인 대상에는 IGW, NAT 게이트웨이, VPC 피어링 연결, Transit Gateway 연결 및 로컬이 포함됩니다. 라우팅 테이블은 단순하게 유지하십시오: 이그레스를 위한 기본 경로와 프라이빗 상호 연결을 위한 명시적 경로로 구성합니다. 계정 간에 공유되는 대상을 참조하고 인적 오류를 줄이기 위해 접두사 목록을 사용하는 것이 좋습니다.

보안 그룹과 네트워크 ACL은 네트워크 필터링을 제공하지만, 작동 방식이 다릅니다:

보안 그룹은 상태 저장(stateful) 방식이며, ENI에 연결되고, 허용 규칙에 대해서만 평가됩니다. 반환 트래픽은 자동으로 허용됩니다. 다른 보안 그룹을 참조하여 애플리케이션 토폴로지를 안전하게 표현할 수 있습니다.
네트워크 ACL은 상태 비저장(stateless) 방식이며, 서브넷 경계에 적용되고, 인바운드 및 아웃바운드에 대한 명시적 허용/거부 규칙 순서에 따라 평가됩니다. 반환 트래픽은 명시적으로 허용해야 합니다. NACL은 서브넷 수준의 광범위한 거부나 규정 준수 패턴을 위해 제한적으로 사용하고, 운영 체제와 로드 밸런서에 필요한 임시 포트 범위를 유지해야 합니다.

상태 저장 방식과 상태 비저장 방식 필터링의 차이는 문제 해결에 중요합니다. 두 가지를 모두 사용하는 경우, 양쪽 모두에서 트래픽 흐름을 허용해야 합니다. 허용/거부된 트래픽을 분석하고 보안 태세를 검증하려면 VPC 흐름 로그를 활성화하여 CloudWatch Logs 또는 S3로 전송하십시오.

VPC 간 및 하이브리드 연결

VPC 피어링은 단일 장애 지점이나 대역폭 병목 현상 없이 두 VPC를 프라이빗하게 연결하지만, 전이적(non-transitive) 연결을 지원하지 않으며 CIDR이 겹치지 않아야 합니다. 각 VPC는 피어링 연결을 통해 피어에 대한 정적 경로를 추가해야 합니다. 피어링된 VPC 간의 보안 그룹 참조는 지원되지 않으므로, CIDR로 필터링해야 합니다. 리전 간 피어링이 가능하며 기본적으로 암호화됩니다.

AWS Transit Gateway(TGW)는 네트워크 확장 및 세분화를 단순화합니다. TGW는 VPC 및 하이브리드 연결을 위한 리전 허브 역할을 하며, 전이적 라우팅을 지원하고 연결당 수십 Gbps까지 확장됩니다. TGW 라우팅 테이블을 사용하여 세분화(예: 개발 vs 프로덕션 vs 공유 서비스)를 구현하고, 경로 전파 및 연결을 제어하십시오. 연결 대상에는 VPC, Site-to-Site VPN, 그리고 Transit VIF와 Direct Connect Gateway를 통한 Direct Connect가 포함됩니다. 중앙 집중식 이그레스를 위해서는 이그레스 VPC를 연결하고 경로를 전파하거나 선택적으로 공유하십시오. 리전 간 피어링으로 TGW를 연결하여 다중 리전 환경을 계획하십시오.

AWS PrivateLink는 서비스 공급자의 서브넷을 노출하거나 라우팅을 요구하지 않으면서 VPC/계정/리전 경계를 넘어 서비스에 대한 소비자 주도의 프라이빗 L4 액세스를 제공합니다. 서비스 공급자는 엔드포인트 앞에 NLB를 배치하고, 소비자는 자신의 VPC에 프라이빗 IP와 DNS 이름이 할당된 인터페이스 VPC 엔드포인트를 생성합니다. PrivateLink는 전이적 연결을 지원하지 않으며 TCP만 지원합니다. 내부 서비스를 게시하거나 AWS 서비스를 프라이빗하게 사용하려면 PrivateLink를 사용하십시오. 서비스 수준의 노출, DNS 기반 사용 또는 더 강력한 생산자 격리가 필요할 때는 피어링/TGW보다 PrivateLink를 사용하는 것이 좋습니다.

하이브리드 연결은 종종 Direct Connect(DX)와 Site-to-Site VPN을 혼합하여 사용합니다. Direct Connect는 1/10 Gbps 포트(및 호스팅 용량)를 통해 전용의 프라이빗하고 일관된 대역폭을 제공합니다. 동적 라우팅 및 장애 조치를 위해 BGP를 사용하십시오. 가상 인터페이스(VIF) 유형:

Private VIF: 가상 프라이빗 게이트웨이(VGW)를 통하거나 Transit VIF가 있는 Transit Gateway를 통해 VPC에 대한 프라이빗 IP 도달 가능성을 제공합니다.
Public VIF: AWS 퍼블릭 서비스에 대한 퍼블릭 IP 도달 가능성을 제공합니다. 사용자의 퍼블릭 프리픽스를 광고하고, AWS는 자사의 글로벌 퍼블릭 프리픽스를 광고합니다.
Transit VIF: 확장 가능한 다중 VPC/다중 리전 연결을 위해 Direct Connect 게이트웨이를 하나 이상의 TGW에 연결합니다. 별도의 DX 위치와 장비에 두 개의 물리적 DX 연결을 사용하고, 필요한 경우 별도의 LAG를 구성하며, 온프레미스에 이중 라우터를 배치하여 이중화를 설계하십시오. DX BGP 세션이 중단될 때 경로가 자동으로 장애 조치되도록 BGP를 사용하는 VPN을 백업으로 추가하십시오(인터넷을 통해 VGW 또는 TGW로 연결). VPN의 경우, 고가용성(HA)을 위해 연결당 두 개의 터널을 사용하고, 정적 경로보다 BGP를 선호하며, 터널 내부 CIDR과 보안을 검증하십시오.

엣지 네트워킹, 보안 및 가속화

Amazon CloudFront는 엣지 캐싱과 최적화된 네트워크 경로를 통해 정적 및 동적 콘텐츠를 가속화하는 글로벌 CDN입니다. 배포(distribution)는 다음을 정의합니다:

오리진(Origin): S3, 사용자 지정 오리진(ALB/NLB/EC2/API Gateway) 또는 장애 조치를 위한 오리진 그룹. Origin Shield를 활성화하여 추가적인 미드티어 캐시를 구성하고 오리진 부하를 줄일 수 있습니다.
동작(Behavior): 경로 및 메서드 기반 오리진 라우팅, 캐시 및 오리진 요청 정책(헤더/쿠키/쿼리 전달), 뷰어 프로토콜 정책(HTTP→HTTPS), 압축, 서명된 URL/쿠키, 함수 후크(경량 뷰어 요청을 위한 CloudFront Functions, 요청/응답 조작을 위한 Lambda@Edge).
캐싱: 캐시 정책을 통해 TTL을 조정하고, 필요한 차원에 대해서만 캐시 키를 변경하며, 오리진 요청 정책을 사용하여 캐시 파편화를 최소화합니다. API의 경우 불필요한 헤더/쿠키/쿼리 전달을 피합니다. 필요한 경우 필드 레벨 암호화를 사용합니다.
무효화: 변경된 경로에 대해 무효화를 실행하거나, 버전이 지정된 객체 키를 사용하여 무중단 캐시 업데이트를 수행합니다. 버전이 지정되지 않은 자산의 경우 배포 후 무효화를 자동화합니다.

AWS WAF는 L7에서 애플리케이션을 보호합니다. 웹 ACL은 순서대로 평가되는 규칙 및 규칙 그룹을 포함하며, 기본 작업을 가집니다. 기본적인 보호를 위해 AWS Managed Rules(예: CommonRuleSet, WordPress, SQLi/XSS)를 사용하고, 필요 시 선별된 파트너 규칙 그룹을 사용합니다. 일치 문(IP 집합, 헤더, URI, 본문 JSON, 레이블 일치)을 사용하여 사용자 지정 규칙을 추가하고, 논리 연산자와 결합합니다. 속도 기반 규칙은 특정 기간 내에 구성된 요청률을 초과하는 클라이언트를 조절(throttle)하며, 선택적으로 범위 축소 문을 사용하여 특정 경로 또는 헤더를 대상으로 지정할 수 있습니다. 웹 ACL을 CloudFront 배포, Application Load Balancer, API Gateway(REST/HTTP), AppSync와 연결합니다. 용량(WCU)을 모니터링하고, CloudWatch Logs 또는 Kinesis Data Firehose로 샘플링된 로그를 활성화하며, CAPTCHA/Challenge 작업을 사용하여 정상적인 트래픽을 차단하지 않고 봇을 완화합니다.

AWS Global Accelerator는 리전 엔드포인트 앞에 고정 애니캐스트(anycast) IP를 제공하고 AWS 글로벌 네트워크를 통해 TCP/UDP 트래픽을 가속화합니다. L4/7에서 작동하며, 상태 기반 라우팅과 신속한 장애 조치를 제공합니다. 구성 요소:

리전별 엔드포인트 그룹(상태 확인 및 가중치 포함).
트래픽 다이얼: 엔드포인트 가중치와 독립적으로 리전으로 전송되는 트래픽 비율을 제어합니다(예: 1% 카나리 또는 유지 관리 중 0%). 지원되는 엔드포인트에는 ALB, NLB, EC2 인스턴스, Elastic IP가 포함됩니다. 비 HTTP 또는 지연 시간에 민감한 상태 저장 프로토콜, 또는 고정 IP와 결정론적 장애 조치가 필요한 경우 Global Accelerator를 사용합니다. HTTP/S 캐싱 및 엣지에서의 함수 실행에는 CloudFront가 여전히 주요 선택지이며, 두 서비스는 상호 보완적입니다.

API 프런트 도어: 도메인, 인증서 및 엔드포인트 전략

Amazon API Gateway는 REST 및 HTTP API에 대해 세 가지 엔드포인트 유형을 제공합니다.

Edge-optimized(엣지 최적화) (REST API 전용): API Gateway가 CloudFront 배포를 생성하고 관리합니다. 엣지 로케이션에서 TLS를 종료하므로 글로벌 클라이언트에 최적입니다. 사용자 지정 도메인 인증서는 ACM을 통해 us-east-1(버지니아 북부) 리전에 있어야 합니다.
Regional(리전): 클라이언트가 동일 리전에 있거나, 자체 CloudFront 배포 또는 Global Accelerator로 API Gateway를 프런팅하려는 경우에 사용합니다. 사용자 지정 도메인 인증서는 API와 동일한 리전에 있어야 합니다.
Private(프라이빗): 인터페이스 VPC 엔드포인트를 통해서만 VPC 내에서 접근할 수 있으며, 공용 인터넷 경로가 없습니다.

사용자 지정 도메인은 여러 스테이지와 API에 걸쳐 라우팅과 TLS를 통합합니다. 기본 경로 매핑(base path mapping)을 사용하여 경로를 스테이지에 매핑합니다. 인증서는 ACM에 저장하고, 클라이언트 지원에 따라 RSA/ECDSA를 선택합니다. Edge-optimized의 경우 us-east-1에서 인증서를 요청/가져오기하고, Regional의 경우 해당 리전에서 요청/가져오기합니다. 규정 준수 상태에 맞는 TLS 정책을 적용합니다. Regional API에 웹 ACL을 직접 연결하거나 API를 프런팅하는 CloudFront 배포를 보호하여 WAF와 통합합니다. 고급 캐싱 및 헤더 정규화 기능을 갖춘 최저 지연 시간의 글로벌 API를 위해서는, Regional API 앞에 CloudFront 배포를 배치하고, 필요한 경우 오리진 액세스 컨트롤(OAC)과 서명된 요청을 사용하며, 캐시 및 오리진 요청 정책을 조정하여 캐시 비대화(cache bloat)를 방지합니다. 인증을 위해 Lambda authorizer 또는 Amazon Cognito와 결합하고, WAF의 속도 기반 규칙 외에도 조절(throttling) 및 사용량 계획(usage plan)을 활용하여 백엔드를 보호합니다.

실제 문제 시나리오

Shopify는 전 세계 판매자를 대상으로 하는 새로운 글로벌 결제 마이크로서비스를 출시하고 있습니다. 요구 사항: 20개 이상의 계정에 걸친 마이크로서비스 간의 프라이빗 동서(east–west) 트래픽, 내부 API의 제로 퍼블릭 노출, 결제 시 최종 사용자를 위한 결정적인 낮은 지연 시간, 적응형 속도 제한을 포함한 강력한 L7 보호, 온프레미스 위험 분석 엔진과의 복원력 있는 하이브리드 연결.

단계별 접근 방식:

허브 앤 스포크(hub-and-spoke) Transit Gateway 설계로 네트워크 분할

중앙 집중식 네트워킹 계정에 리전별 AWS Transit Gateway를 생성합니다. 각 계정의 모든 워크로드 VPC(스포크)를 RAM으로 공유된 TGW 연결을 통해 연결합니다. 여러 TGW 라우팅 테이블을 사용하여 세분화(프로덕션 vs 공유 서비스 vs 개발)를 강제하고 필요한 경로만 전파합니다.
TGW를 사용하는 이유: 풀 메시(full-mesh) 피어링에 비해 전이적 라우팅(transitive routing)을 확장하고 경로 관리를 단순화하며, 하이브리드 연결을 지원합니다.

AWS PrivateLink로 내부 마이크로서비스 게시

각 생산자 VPC에서 내부 마이크로서비스 대상 그룹 앞에 NLB를 배치하고 VPC 엔드포인트 서비스를 생성합니다. 소비자 VPC에서는 해당 서비스에 대한 인터페이스 엔드포인트를 생성하고 엔드포인트별 프라이빗 DNS를 활성화합니다.
PrivateLink를 사용하는 이유: 경로 노출이 없는 서비스 수준의 TCP 전용 비전이적(non-transitive) 연결입니다. 생산자는 격리된 상태를 유지하며 전체 CIDR 블록에 대한 인바운드 SG 허용이 필요하지 않습니다.

Direct Connect 및 VPN으로 이중화된 하이브리드 연결 설정

별도의 DX 로케이션에 2개의 10 Gbps Direct Connect 연결을 프로비저닝하고, 별도의 온프레미스 라우터에서 종료합니다. TGW에 대한 Transit VIF를 사용하여 Direct Connect Gateway를 생성합니다. 양쪽에 고유한 ASN과 MED/local-pref 정책으로 BGP를 구성합니다. TGW에 두 개의 터널이 있는 Site-to-Site VPN 연결을 백업으로 추가하고 BGP를 활성화합니다.
이 조합을 사용하는 이유: DX는 결정적인 대역폭과 낮은 지터를 제공하며, BGP와 VPN 백업은 자동 장애 조치 및 고가용성을 제공합니다.

AWS Global Accelerator로 퍼블릭 결제 시스템 프런팅

두 개의 리스너(80/443 → 443)가 있는 액셀러레이터를 생성합니다. us-east-1 및 eu-west-1에 엔드포인트 그룹을 정의하고, 각 그룹이 결제 서비스용 ALB를 가리키도록 합니다. 정상 상태(steady-state)에서 트래픽 다이얼을 50/50으로 설정하고 ALB 상태 엔드포인트에 대한 상태 확인을 활성화합니다. 세션 고정(session pinning)이 필요한 경우 클라이언트 어피니티(client affinity)를 활성화합니다.
Global Accelerator를 사용하는 이유: 애니캐스트(Anycast) 고정 IP, 빠른 리전 장애 조치, 그리고 낮은 지연 시간의 상태 저장(stateful) 결제 흐름을 위한 TCP 최적화를 제공합니다.

CloudFront 및 AWS WAF로 엣지에서 보호

(멱등성(idempotent) GET 및 정적 자산을 위해) Regional API Gateway 앞에, 그리고 헤더 정규화 및 TLS 오프로드의 이점을 누릴 수 있는 동적 콘텐츠를 제공하는 ALB 바로 앞에 CloudFront를 배치합니다. 캐시 정책을 구성하여 필요한 헤더/쿼리로만 변형(variance)을 제한하고, Origin Shield를 활성화하여 오리진 부하를 줄이며, 버전이 지정되지 않은 자산에 대한 무효화를 자동화합니다.
AWS Managed Rules, 비즈니스 로직 필터링을 위한 사용자 지정 규칙 그룹, 그리고 결제 경로에 대한 범위 축소 구문(scope-down statement)이 포함된 속도 기반 규칙(rate-based rule)을 사용하여 AWS WAF 웹 ACL을 CloudFront에 연결합니다. 의심스러운 스파이크에 대해 CAPTCHA를 활성화하고 분석을 위해 Kinesis Data Firehose에 로그를 기록합니다.
CloudFront + WAF를 사용하는 이유: 글로벌 TLS 종료, 안전한 경우 캐싱, 엣지 기반 L7 제어, 그리고 AWS Shield를 통한 DDoS 흡수를 제공합니다.

사용자 지정 도메인과 강력한 TLS로 API 노출

쓰기 집약적인 API 메서드에는 CloudFront 뒤에서 보호되는 API Gateway Regional 엔드포인트를 사용합니다. 리전별로 ACM에서 사용자 지정 도메인을 생성하고, 엄격한 TLS 정책을 적용하며, 기본 경로를 스테이지에 매핑합니다. 내부 관리 API의 경우, Private API를 배포하고 인터페이스 VPC 엔드포인트를 통해 액세스하며, 최소 권한 보안 그룹을 연결합니다.
이렇게 분리하는 이유: Regional 엔드포인트와 CloudFront를 함께 사용하면 엣지 제어의 유연성을 얻을 수 있으며, Private API는 내부 인터페이스를 인터넷에 노출시키지 않습니다.

계층화된 제어로 VPC 보안 강화

가능한 경우 생산자/소비자 SG를 참조하는 최소 권한의 상태 저장(stateful) 보안 그룹을 적용합니다. NACL은 규정 준수에 필요한 특정 서브넷 거부를 제외하고는 단순하게(모두 허용) 유지합니다. CloudWatch 지표 필터와 함께 VPC 흐름 로그(VPC Flow Logs)를 활성화하여 비정상적인 소스를 탐지합니다. AZ 간 종속성을 피하기 위해 AZ당 하나의 NAT 게이트웨이를 배치하고 프라이빗 서브넷을 로컬 NAT로 라우팅합니다.
계층화된 제어를 사용하는 이유: SG는 연결 추적을 통해 대부분의 의도를 처리하고, NACL은 대략적인 안전 장치를 제공하며, 영역별(zonal) NAT는 복원력과 비용을 개선합니다.

이 설계는 프라이빗하고 분할된 동서(east–west) 연결(Transit Gateway + PrivateLink), 복원력 있는 남북(north–south) 하이브리드 경로(BGP를 사용하는 DX + VPN), 전 세계적으로 가속화되고 보호되는 퍼블릭 진입점(Global Accelerator + CloudFront + WAF), 그리고 VPC 라우팅, 게이트웨이, 필터링에 대한 AWS 모범 사례에 부합하는 운영 제어를 제공합니다.

← 스토리지 · 모든 도메인 · Systems Manager →

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