Amazon SAA-C03: 콘텐츠 전송, 엣지 및 성능 최적화 — 학습 가이드
다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
Amazon CloudFront: 개념과 장점
Amazon CloudFront는 600개 이상의 PoP(Point of Presence)를 기반으로 구축된 전 세계에 분산된 콘텐츠 전송 네트워크입니다. 이 서비스의 역할은 가장 가까운 엣지에서 뷰어의 TLS를 종료하고, 캐시된 응답을 즉시 제공하거나 캐시 미스(cache miss)가 발생하면 AWS의 프라이빗 백본을 통해 오리진으로 요청을 프록시하는 것입니다. 성능상 이점은 두 가지입니다. 캐시 히트(cache hit)는 왕복 시간을 한 자릿수 밀리초로 줄이고 오리진의 부하를 완전히 덜어줍니다. 반면, 캐시 미스의 경우에도 엣지에서의 최적화된 TLS/TCP 종료, HTTP/2 및 HTTP/3 지원, 오리진에 대한 keep-alive 연결 재사용, 그리고 혼잡한 공용 인터넷을 피하는 백본 전송의 이점을 누릴 수 있습니다.
일반적인 오해 중 하나는 CloudFront가 정적 자산만 가속화한다는 것입니다. CachingDisabled 정책을 사용하여 CloudFront 뒤에 ALB를 배치해도 동적 API 성능이 향상됩니다. 뷰어의 핸드셰이크가 오리진 리전까지 인터넷을 통과하는 대신 로컬 PoP에서 완료되기 때문입니다. 여기에 /static/*은 S3에서, /api/*은 ALB에서 제공하는 것과 같은 혼합된 워크로드를 결합하면 하나의 배포로 두 가지를 모두 처리할 수 있습니다.
Distribution:
Aliases: [www.example.com]
ViewerCertificate: ACM cert in us-east-1
Origins:
- Id: s3-static
DomainName: static-assets.s3.us-east-1.amazonaws.com
S3OriginConfig:
OriginAccessControlId: !Ref OAC
- Id: alb-dynamic
DomainName: alb-1234.us-east-1.elb.amazonaws.com
CustomOriginConfig: { OriginProtocolPolicy: https-only }
DefaultCacheBehavior:
TargetOriginId: alb-dynamic
CachePolicyId: CachingDisabled
OriginRequestPolicyId: AllViewer
CacheBehaviors:
- PathPattern: /static/*
TargetOriginId: s3-static
CachePolicyId: CachingOptimized
- PathPattern: /api/*
TargetOriginId: alb-dynamic
CachePolicyId: !Ref ShortTtlPolicy
그런 다음 Route 53 별칭 레코드를 사용하여 www.example.com을 배포의 d123.cloudfront.net으로 지정합니다. 별칭 레코드는 무료이며 CloudFront의 애니캐스트 IP로 직접 확인됩니다.
인증서는 us-east-1에 위치해야 합니다
사용자 지정 도메인에서 제공되는 모든 CloudFront 배포의 경우, AWS Certificate Manager의 뷰어 대상 TLS 인증서는 오리진 버킷, ALB 또는 사용자의 위치와 관계없이 반드시 us-east-1(버지니아 북부)에서 발급되어야 합니다. CloudFront는 us-east-1에 컨트롤 플레인이 있는 글로벌 서비스이며, 엣지 로케이션은 해당 리전에서 인증서를 가져옵니다. S3 버킷이 eu-west-1에 있다는 이유로 해당 리전에서 ACM 인증서를 요청하는 것은 잘못된 패턴이며, 배포에서 해당 인증서를 인식하지 못합니다.
aws acm request-certificate \
--domain-name media.example.com \
--validation-method DNS \
--region us-east-1
만약 CloudFront와 ALB 오리진 사이에서 두 번째로 TLS를 종료하는 경우, 그 오리진 대상 인증서는 ALB의 리전에 위치합니다. 뷰어 인증서만 us-east-1에 종속됩니다. 이 규칙은 API Gateway 엣지 최적화 사용자 지정 도메인(내부적으로 AWS 관리형 CloudFront 배포를 사용)에도 동일하게 적용됩니다. 인증서는 반드시 us-east-1에 있어야 합니다. 반면, 리전별 API Gateway 엔드포인트는 API 자체 리전의 인증서를 사용합니다.
S3 오리진을 위한 Origin Access Control
S3 버킷을 공개 상태로 두고 CloudFront를 앞에 배치하는 것은 목적에 어긋납니다. 뷰어는 S3 REST 엔드포인트에 직접 접속하여 CloudFront를 우회하게 되며, 이는 WAF, 지역 제한, 서명된 URL, 캐시 이점을 모두 무시하게 되고 잠재적으로 데이터가 노출될 수 있습니다.
최신 해결책은 **Origin Access Control(OAC)**이며, 이는 기존의 Origin Access Identity(OAI)를 대체합니다. OAC는 SigV4 서명을 사용하고, SSE-KMS를 지원하며, 2022년 이후에 출시된 리전을 포함한 모든 S3 리전에서 작동하고, 동적 요청을 지원합니다. 퍼블릭 액세스 차단은 활성화된 상태로 유지하고 ACL은 필요하지 않으며, 버킷 정책은 CloudFront 서비스 보안 주체에만 읽기 액세스 권한을 부여하고 특정 배포 ARN으로 추가 제한됩니다.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": { "Service": "cloudfront.amazonaws.com" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::media-example-com/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
}
}
}]
}
OAI는 여전히 작동하지만 레거시로 간주해야 합니다. 새로운 작업에는 항상 OAC를 선택해야 합니다.
캐시 정확성
캐시 효율성은 오리진이 반환하는 Cache-Control 및 Expires 헤더와 CloudFront 캐시 정책의 최소/기본/최대 TTL의 조합에 따라 결정됩니다. 지문이 찍힌(Fingerprinted) 불변 자산은 적극적으로 캐시해야 하고, 이를 참조하는 HTML 셸은 배포가 전파되도록 수명이 짧아야 하며, 인증된 JSON은 공유 CDN에 전혀 캐시되어서는 안 됩니다.
Cache-Control: public, max-age=31536000, immutable # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300 # HTML that changes
Cache-Control: private, no-store # authenticated JSON
두 가지 대칭적인 함정이 일반적입니다. 첫째, 오리진이 캐시 헤더를 보내지 않으면 CloudFront는 배포의 기본 TTL을 사용하게 되어 동적 응답을 몇 시간 동안 조용히 캐시할 수 있습니다. 둘째, 캐시되어야 할 자산에 Cache-Control: no-cache를 무조건 적용하면 모든 요청이 오리진으로 돌아가 CDN의 목적을 무력화시킵니다.
가장 위험한 함정은 적절한 헤더 없이 개인화된 응답을 캐싱하는 것입니다. 만약 /account/dashboard가 사용자 A에게 특화된 HTML을 반환하는데 오리진이 no-store를 생략하고 캐시 정책의 캐시 키에 인증 헤더나 쿠키를 포함하지 않으면, 엣지는 사용자 A의 페이지를 사용자 B에게 기꺼이 제공할 것입니다. 이러한 응답은 private, no-store로 표시하거나, 세션 식별자를 캐시 키에 포함하고 낮은 히트율을 감수해야 합니다.
정적 콘텐츠를 제공하는 EC2 온디맨드 인스턴스로 구성된 Auto Scaling 그룹의 비용 최적화 시나리오에서 올바른 재설계는 자산을 S3로 옮기고, OAC와 함께 CloudFront를 앞에 배치하고, ASG를 제거하거나 축소하는 것입니다. 이렇게 하면 비용이 시간당 컴퓨팅 비용에서 요청당 전송 비용으로 전환되며, 이는 정적 워크로드의 경우 훨씬 저렴합니다.
서명된 URL, 서명된 쿠키, 그리고 지역 제한
CloudFront는 서명된 URL(시간 제한이 있고 선택적으로 IP가 제한된 단일 객체에 대한 액세스 - 구매한 비디오 다운로드, 일회성 PDF 링크 등)과 서명된 쿠키(경로 패턴과 일치하는 여러 객체에 대한 액세스 - 인증된 구독자가 카탈로그를 탐색하는 경우 등)를 지원합니다. 두 가지 모두 신뢰할 수 있는 키 그룹을 사용하며, 이 그룹의 퍼블릭 키는 CloudFront에 업로드됩니다. 프라이빗 키는 만료 시간, 소스 IP 범위 또는 URL 패턴을 지정하는 정책에 서명합니다.
https://d123.cloudfront.net/premium/movie.mp4
?Expires=1735689600
&Signature=...
&Key-Pair-Id=APKAI...
이는 CloudFront를 우회하여 버킷에 직접 액세스 권한을 부여하는 S3 미리 서명된 URL과는 다릅니다. CloudFront 서명된 URL을 OAC와 함께 사용하면 버킷은 엔드투엔드로 비공개 상태를 유지합니다.
지역 제한은 요청이 캐시나 오리진에 도달하기 전에 배포 수준에서 국가 단위의 허용 목록 또는 차단 목록을 적용합니다. 이는 CloudFront가 유지 관리하는 GeoIP 데이터베이스를 사용하며, 라이선스 금수 조치를 시행하기 위한 저렴하고 캐시 우회를 방지하는 메커니즘입니다. 더 세분화된 로직(주(state) 수준, 헤더 조합 등)이 필요하면 CloudFront Function 또는 Lambda@Edge를 사용하고, 완전한 규칙 엔진이 필요하면 WAF를 사용합니다.
AWS Global Accelerator
Global Accelerator는 CDN이 아니며 캐싱을 하지 않습니다. 전 세계 AWS 엣지 로케이션에서 광고되는 두 개의 고정 애니캐스트 IPv4 주소(또는 BYOIP)를 프로비저닝합니다. 클라이언트의 TCP 또는 UDP 연결은 가장 가까운 엣지에서 AWS 백본으로 들어와, AWS의 프라이빗 네트워크를 통해 하나 이상의 리전에 있는 가장 정상적인 엔드포인트(ALB, NLB, EC2 또는 Elastic IP)로 라우팅됩니다. 이 엔드포인트들은 트래픽 다이얼과 가중치가 있는 엔드포인트 그룹으로 묶입니다.
고정 IP는 세 가지 구체적인 이점을 제공합니다. 백엔드가 재설계되더라도 클라이언트와 방화벽 허용 목록은 변경되지 않습니다. 상태 확인 변경 시 엔드포인트 그룹 간에 트래픽을 이동시켜 리전 장애 조치가 몇 초 안에 완료되므로 DNS TTL 전파를 완전히 우회합니다. 그리고 TCP 핸드셰이크는 엣지에서 종료되고 장거리 통신은 AWS의 백본에서 실행됩니다.
다음과 같은 경우 Global Accelerator를 선택하세요:
- 프로토콜이 HTTP가 아닌 경우: 게임이나 VoIP용 UDP, MQTT, SIP, SFTP, 커스텀 TCP.
- 엔터프라이즈 허용 목록이나 주소를 하드코딩하는 모바일 앱을 위한 고정 IP가 필요한 경우.
- 상태 저장(stateful) 액티브-액티브 배포를 위해 1분 미만의 리전 장애 조치가 필요한 경우.
- 워크로드가 동적이고 캐싱할 수 없어 CDN의 가치가 거의 없는 경우.
다음과 같은 경우 CloudFront를 선택하세요:
- 콘텐츠를 캐싱할 수 있는 경우(이미지, 비디오 세그먼트, 정적 HTML, TTL이 있는 API 응답).
- Lambda@Edge 또는 CloudFront Functions를 통한 엣지 컴퓨팅을 원하는 경우.
- 엣지에서 WAF, 서명된 URL/쿠키 또는 필드 레벨 암호화가 필요한 경우.
| 요구 사항 | CloudFront | Global Accelerator |
|---|---|---|
| 캐싱 가능한 HTTP(S) 콘텐츠 | ✅ | ❌ |
| UDP 또는 임의의 TCP | ❌ | ✅ |
| 고정 애니캐스트 IP | ❌ | ✅ |
| 상태 저장 L4 앱을 위한 빠른 리전 장애 조치 | 부분적 | ✅ |
| 엣지에서의 WAF, 서명된 URL | ✅ | ❌ |
| 대용량 미디어의 오리진 이그레스 비용 절감 | ✅ | ❌ |
피해야 할 두 가지 함정이 있습니다. ‘게임 서버를 전 세계적으로 더 빠르게 만들기 위해’ CloudFront를 선택하는 것은 실패합니다. 게임은 UDP이고 캐싱할 수 없기 때문입니다. 이 경우 Global Accelerator가 필요합니다. 반대로 정적 웹사이트에 Global Accelerator를 선택하는 것은 비싸고(시간당 고정 요금 + GB당 요금) 캐싱을 포기하는 것입니다. 이 경우 CloudFront를 사용하면 오리진 이그레스 비용을 극적으로 줄일 수 있습니다. 사용자가 지연 시간을 감내할 수 있는 전 세계적으로 분산되었지만 단일 리전인 HTTP API의 경우, 일반 Route 53 지연 시간 기반 라우팅이 충분하고 두 서비스보다 저렴할 수 있습니다.
글로벌 트래픽을 위한 Route 53 라우팅 정책
Route 53은 클라이언트가 확인할 엔드포인트를 선택하고, 그 다음 CloudFront나 Global Accelerator가 연결을 처리합니다. 세 가지 정책이 글로벌 아키텍처에서 주로 사용됩니다.
지연 시간 기반 라우팅은 확인자(resolver)의 위치에서 각 리전까지의 실제 네트워크 지연 시간을 측정하여 가장 빠른 곳을 반환합니다. 여러 리전에 동일한 스택이 있고 사용자를 현재 가장 빠른 리전으로 보내고 싶을 때 사용합니다.
지리 근접 라우팅은 지연 시간 기반이 아닌 좌표 기반입니다. 각 엔드포인트의 위치(또는 AWS 리전)를 선언하면 Route 53은 사용자를 지리적으로 가장 가까운 곳으로 보냅니다. 고유한 특징은 유효 서비스 영역을 확장하거나 축소하는 바이어스(bias) 값(-99에서 +99)입니다. 이는 리전 출시 중 트래픽을 점진적으로 전환하거나 유지 관리를 위해 리전의 트래픽을 비울 때 유용합니다. 지리 근접 라우팅은 Route 53 트래픽 흐름(트래픽 정책)이 필요하며, 일반적으로 각 리전의 리전 NLB 또는 ALB와 함께 사용됩니다.
RecordSets:
- Region: eu-west-1
Endpoint: nlb-eu.example.internal
Bias: +30 # expand EU service area during launch
- Region: us-east-1
Endpoint: nlb-us.example.internal
Bias: 0
- Region: ap-southeast-1
Endpoint: nlb-ap.example.internal
Bias: 0
장애 조치 라우팅은 상태 확인에 연결된 기본/보조 쌍을 사용합니다. 이는 DNS 수준의 장애 조치이므로 TTL 및 확인자 캐싱의 영향을 받습니다. 따라서 Global Accelerator의 데이터 플레인 장애 조치보다 느립니다. 1분 정도의 DNS 전파를 허용할 수 있는 간단한 액티브-패시브 구성에는 장애 조치 라우팅을 선택하고, 몇 초 단위의 장애 조치가 필요할 때는 Global Accelerator를 선택하세요.
이러한 정책들은 조합하여 사용할 수 있습니다. 일반적인 글로벌 패턴은 다음과 같습니다: Route 53 지연 시간 또는 지리 근접 레코드가 Global Accelerator(TCP/UDP용) 또는 CloudFront(캐싱 가능한 HTTPS용)를 가리키고, 그 아래에 안전망으로 상태 확인이 적용된 장애 조치 레코드를 둡니다. 이러한 계층화는 의도적인 것입니다. Route 53이 리전을 선택하고, Global Accelerator나 CloudFront가 엣지와 백본을 통과하는 경로를 선택하며, 리전 로드 밸런서가 리전 내의 대상을 선택합니다.
API Gateway 엔드포인트 유형 및 사용자 지정 도메인
API Gateway는 서로 다른 토폴로지를 가진 세 가지 엔드포인트 유형을 제공합니다:
| 유형 | 경로 | 최적 사용 사례 |
|---|---|---|
| 엣지 최적화 | 클라이언트 → AWS 관리형 CloudFront → 리전 내 API Gateway | 지리적으로 분산된 클라이언트가 REST API를 호출하는 경우 |
| 리전 | 클라이언트 → 리전 내 API Gateway로 직접 연결 | 리전 내 호출자 또는 자체 CloudFront로 API를 프론팅할 클라이언트 |
| 프라이빗 | VPC 내 클라이언트 → 인터페이스 VPC 엔드포인트 → API Gateway | 인터넷에 노출되지 않는 내부 API |
엣지 최적화 엔드포인트는 직접 구성할 수 없는 AWS 관리형 CloudFront 배포로 API를 감쌉니다. 이는 빠른 글로벌 도달 범위를 확보하는 데는 편리하지만, 자체 캐시 동작, WAF 규칙 또는 오리진 요청 정책을 원할 때는 제한적입니다. 최대한의 제어를 위한 일반적인 패턴은 고객이 관리하는 CloudFront 배포를 앞에 둔 리전 엔드포인트를 사용하는 것입니다.
인증서 배치는 CloudFront의 규칙을 따릅니다. 엣지 최적화 사용자 지정 도메인은 us-east-1 리전의 ACM 인증서가 필요하며, 리전 엔드포인트는 API와 동일한 리전의 인증서가 필요합니다. HTTP API는 최소 TLS 1.2를 적용하며, REST API는 최대 TLS 1.3까지의 보안 정책을 지원합니다.
ACM 인증서: 발급, 검증, 가져오기
ACM은 공개 TLS 인증서를 무료로 발급하고 자동 갱신하며, CloudFront, API Gateway, ALB, NLB 및 기타 AWS 서비스와 직접 통합됩니다. 검증 방식에는 DNS 검증(ACM이 제공하는 CNAME을 Route 53이나 다른 DNS 공급자에 등록하는 방식. 이 레코드가 유지되는 동안 ACM이 영구적으로 자동 갱신) 또는 이메일 검증(갱신 시마다 수동으로 클릭해야 하므로 자동화에 취약)이 있습니다. 운영 환경에서는 DNS 검증을 기본으로 사용하는 것이 올바른 방법입니다.
ACM에서 발급한 인증서는 내보낼 수 없으며, 통합된 AWS 서비스 외부에서는 사용할 수 없습니다. 규제 또는 비즈니스 요구사항으로 인해 특정 서드파티 CA를 사용해야 하는 경우(예: 특정 상용 발급 기관에 체인을 연결하고 TLS 1.3을 강제해야 하는 REST API)에는 ACM 발급 인증서를 사용할 수 없습니다. 이 경우 필요한 CA에서 인증서를 발급받아 ACM으로 가져온(import) 후, TLS 1.3 보안 정책과 함께 리전별 API Gateway 사용자 지정 도메인에 연결해야 합니다.
인증서를 가져올 때 주의할 점은 두 가지입니다. 가져온 인증서는 자동 갱신되지 않으며(만료 전에 다시 가져오지 않으면 엔드포인트가 완전히 실패합니다), ACM은 가져올 때 인증서 체인을 검증하지 않습니다. 즉, 중간 인증서가 깨져 있다면 실제 클라이언트와의 핸드셰이크 시점에서만 문제가 드러납니다. 배포 전에 엄격한 클라이언트로 전체 체인을 테스트해야 합니다.
S3 Transfer Acceleration 대 CloudFront
CloudFront는 다운로드를 최적화하고, S3 Transfer Acceleration은 업로드를 최적화합니다. Transfer Acceleration은 동일한 CloudFront 엣지 네트워크를 역방향으로 사용합니다. 즉, PUT 요청이 가장 가까운 엣지로 들어와 AWS 백본을 타고 대상 버킷이 있는 리전으로 전송됩니다. 이 기능은 전 세계에 분산된 사용자들이 단일 리전의 버킷에 대용량 객체를 업로드할 때(예: 전 세계 현장 엔지니어들이 us-east-1에 있는 버킷으로 수 기가바이트 크기의 도면을 업로드하는 경우) 효과적입니다.
두 기능은 동일한 버킷에서 함께 사용할 수 있습니다. Transfer Acceleration을 활성화하고, 다운로드를 위해 OAC가 설정된 CloudFront 배포를 노출하면 됩니다. 객체가 작거나 클라이언트가 이미 버킷 리전과 가까운 곳에 있다면 Transfer Acceleration은 이점 없이 비용만 추가합니다. 사용하기 전에 S3 Transfer Acceleration 속도 비교 도구를 사용하여 측정해 보세요. 가속 기능을 사용하려면 클라이언트가 반드시 s3-accelerate 엔드포인트를 사용해야 합니다.
계층 7 보호를 위한 AWS WAF
AWS WAF는 HTTP(S) 요청이 보호 대상 리소스에 도달하기 전에 검사합니다. CloudFront 배포, ALB, API Gateway 스테이지, AppSync API, Cognito 사용자 풀, App Runner 서비스, Verified Access 인스턴스에 연결할 수 있습니다. 웹 ACL에는 URI, 헤더, 쿼리 문자열, 본문(기본 8KB, ALB/API Gateway에서는 최대 64KB까지 확장 가능), IP 세트, 지리적 위치를 기반으로 매칭하는 규칙이 포함됩니다.
가장 일반적인 구성 요소는 AWS Managed Rules입니다. AWSManagedRulesCommonRuleSet과 AWSManagedRulesKnownBadInputsRuleSet은 OWASP 상위 취약점을 방어하고, AWSManagedRulesSQLiRuleSet과 XSS 매치 문은 인젝션 공격을 처리합니다. 사용자 지정 규칙을 통해 지리적 위치 매치(규정 준수를 위한 국가 허용/차단 목록), IP 세트 매치, 그리고 **속도 기반 규칙(rate-based rules)**을 추가할 수 있습니다. 속도 기반 규칙은 5분 단위로 소스 IP당 요청 수를 계산하여 임계값을 초과하면 차단합니다. 이 규칙은 HTTP 플러드 및 크리덴셜 스터핑 공격에 대한 첫 번째 방어선입니다.
{
"Name": "LoginRateLimit",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 500,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": {"UriPath": {}},
"PositionalConstraint": "STARTS_WITH",
"TextTransformations": [{"Priority":0,"Type":"NONE"}]
}
}
}
},
"Action": {"Block": {}}
}
리전 규칙이 중요합니다. CloudFront용 웹 ACL은 글로벌 리소스이므로 반드시 us-east-1 리전에 생성해야 합니다. 리전별 리소스(ALB, API Gateway 등)용 웹 ACL은 해당 리소스가 있는 리전에 생성합니다.
S3의 정적 사이트를 보호하기 위해 WAF를 버킷에 직접 연결할 수는 없습니다. S3는 WAF가 지원하는 리소스가 아니기 때문입니다. 올바른 패턴은 버킷 앞에 CloudFront + OAC를 두고 웹 ACL을 CloudFront 배포에 연결하는 것입니다. CloudFront를 통해서만 버킷에 접근할 수 있게 함으로써 “모든 트래픽을 검사한다"는 목표를 달성할 수 있습니다.
다중 계정 WAF 거버넌스를 위한 Firewall Manager
WAF를 계정별로 하나씩 관리하는 방식은 확장성이 떨어집니다. 조직 전체에서 한 팀이 회사 기본 정책을 연결하지 않고 새 ALB를 가동하면 규정 준수 상태가 조용히 저하될 수 있습니다. AWS Firewall Manager는 조직 전체에 적용되는 정책을 통해 범위 내 계정과 리소스에 정책을 강제하여 이 문제를 해결합니다.
사전 조건: 모든 기능이 활성화된 AWS Organizations, 지정된 Firewall Manager 관리자 계정, 그리고 모든 멤버 계정에 활성화된 AWS Config가 필요합니다. 정책 유형에는 AWS WAF, AWS Shield Advanced, 보안 그룹(감사 및 사용), Network Firewall, Route 53 Resolver DNS Firewall, 서드파티 방화벽이 포함됩니다.
WAF 정책은 “첫 번째” 규칙 그룹(애플리케이션 소유 규칙보다 먼저 평가), “마지막” 규칙 그룹(애플리케이션 소유 규칙 이후에 평가)을 강제하거나, 웹 ACL을 완전히 대체할 수 있습니다. 리소스 범위와 일치하는 새로운 ALB나 CloudFront 배포는 자동으로 회사 규칙 세트를 적용받게 되며, 규정을 준수하지 않는 리소스는 플래그가 지정되고, 자동 수정 설정에 따라 자동으로 수정됩니다. 시나리오에서 “다중 계정”, “중앙 관리” 또는 “조직 전반의 일관된 WAF 규칙"이라는 말이 나오면, 계정별 WAF가 아닌 Firewall Manager가 정답입니다.
Shield Standard vs. Shield Advanced
WAF만으로 DDoS를 막을 수 있다고 생각하는 것은 중대한 실수입니다. WAF는 자신에게 도달한 요청에 대해 작동하며, 애플리케이션 계층 플러드, 크리덴셜 스터핑, 알려진 익스플로잇 시그니처에 대해서는 탁월합니다. 하지만 레이어 3/4의 대규모 볼류메트릭 공격(SYN 플러드, UDP 반사 공격)은 AWS Shield에 의해 흡수됩니다.
Shield Standard는 추가 비용 없이 기본적으로 활성화됩니다. 일반적인 L3/L4 공격을 자동으로 방어하며 CloudFront, Route 53, Global Accelerator에 적용되고, ELB, EC2 및 기타 리소스에 대한 기본 보호를 제공합니다. 하지만 공격별 가시성, Shield Response Team(SRT) 지원, 비용 보호는 제공하지 않습니다.
Shield Advanced(조직당 월 $3,000, 1년 약정)는 다음 기능을 추가로 제공합니다.
| 기능 | Standard | Advanced |
|---|---|---|
| L3/L4 자동 완화 | ✅ | ✅ |
| 향상된 L7 공격 탐지 및 완화(WAF 연동) | ❌ | ✅ |
| 실시간 공격 진단 및 가시성 | ❌ | ✅ |
| Shield Response Team(SRT) 연중무휴 지원 | ❌ | ✅ |
| DDoS 비용 보호(스케일링 요금) | ❌ | ✅ |
| 글로벌 위협 대시보드 | ❌ | ✅ |
| 보호 대상 리소스 | 자동 | CloudFront, Route 53, Global Accelerator, ALB, NLB, EIP |
‘비용 보호 및 전문가 대응을 포함한 대규모 DDoS’에 Shield Standard가 충분하다고 가정하는 것은 잘못입니다. 바로 Standard에는 가시성, 비용 보호, SRT 액세스가 없기 때문입니다. 오리진이 ELB 뒤의 EC2이고 DNS가 서드파티에 있어 Route 53 별칭 레코드를 사용할 수 없는 경우, 권장되는 패턴은 ELB에서 Shield Advanced를 활성화하고, 애플리케이션 앞에 CloudFront(마찬가지로 Shield Advanced로 보호)를 두어 완화 경계를 엣지로 이동시키고 리전에 도달하는 공격 표면을 줄이는 것입니다.
올바른 계층적 방어 구성은 다음과 같습니다: L3/L4 볼류메트릭 공격은 Shield로, L7 필터링은 WAF로, 두 서비스가 연결되는 엣지 진입점은 CloudFront 또는 Global Accelerator로, 모든 계정에 걸쳐 정책을 강제하는 것은 Firewall Manager로 구성합니다.
← 네트워킹 및 연결성 · 모든 도메인 · 데이터베이스 및 캐싱 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →