AWS SAA 432~

도은호·2025년 12월 22일

AWS SAA

목록 보기
52/53

Amazon SageMaker + Amazon QuickSight

이 문제는 "머신러닝(ML) 모델 구축"과 "BI 시각화"를 가장 쉽고 빠르게(최소 오버헤드) 연결하는 AWS의 골든 조합을 묻는 문제입니다.

💡 필승 조합: "SageMaker + QuickSight"

⭐1. 모델 구축 및 훈련: Amazon SageMaker

  • AWS에서 ML 모델을 만들고, 훈련하고, 배포하는 데 쓰이는 완전 관리형 서비스입니다.
  • EC2에 직접 딥러닝 프레임워크를 설치하는 것(C번)보다 훨씬 관리가 쉽습니다.
  1. 시각화 및 BI: Amazon QuickSight
  • AWS의 서버리스 BI(Business Intelligence) 대시보드 도구입니다.
  • 결정적 기능: QuickSight에는 "SageMaker 모델 통합" 기능이 내장되어 있습니다. 복잡한 코딩 없이 클릭 몇 번으로 SageMaker의 예측 결과(증강된 데이터)를 대시보드에 바로 띄울 수 있습니다.

📝 시험장 암기 공식

"ML 모델을 만든다" SageMaker
"데이터를 시각화/대시보드화 한다" QuickSight
"ML 결과를 대시보드에서 바로 보고 싶다"
➡️ SageMaker + QuickSight 조합이 정답.

⭐이 두 서비스는 AWS가 밀고 있는 "분석 + AI"의 가장 강력한 파트너입니다.

💡 "막아라! = SCP"

  1. SCP (Service Control Policy)의 역할:
  • SCP는 AWS Organizations의 최상위 법입니다.
  • 여기서 "태그 수정 금지(Deny)"라고 적어버리면, 개별 계정의 관리자(Root)조차도 태그를 수정할 수 없습니다.
  • 특정 조건(예: 결제 팀 IAM 역할)을 제외하고는 모든 사용자의 태그 변경을 원천 봉쇄할 수 있는 유일한 예방(Preventative) 도구입니다.
  1. 왜 나머지는 안 될까요?
  • A. AWS Config: 이건 감시 카메라입니다. "누가 태그를 바꿨네?"라고 탐지(Detect)하고 알람을 줄 순 있지만, 바꾸는 행위 자체를 막을 순 없습니다. (사후 처리).
  • B. CloudTrail: 이건 CCTV 녹화 장치입니다. "누가 언제 바꿨다"고 기록(Log)만 남깁니다.
  • D. CloudWatch Logs: 이것도 로그 저장소일 뿐입니다. 권한 제어 기능은 없습니다.

📝 SCP 시험장 암기 노트

"AWS Organizations(여러 계정)" + "못하게 막는다 / 제한한다 (Prevent/Restrict)"
➡️ SCP (Service Control Policy)
"설정이 잘 지켜지는지 감시한다 / 규정 준수 확인 (Compliance)"
➡️ AWS Config

"수정을 방지(Prevent)"해야 하므로 감시 도구인 Config가 아니라, 차단 도구인 SCP가 정답입니다.

정답: A (재해 복구 지역에서 자동 확장 그룹과 로드 밸런서를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. DNS 장애 조치를 구성하여 새 재해 복구 지역의 로드 밸런서를 가리킵니다.)

이 문제는 "최소한의 다운타임(Minimal Downtime)"을 달성하기 위한 "Warm Standby" 또는 "Active-Active" 전략을 묻는 문제입니다.

💡 핵심 분석

  1. DynamoDB Global Tables (데이터 계층):
  • DynamoDB 글로벌 테이블은 여러 리전에 걸쳐 데이터를 자동으로 복제합니다.
  • 재해 발생 시 데이터가 이미 DR 리전에 있으므로, 데이터 복구 시간을 0에 가깝게 줄일 수 있습니다. (B번처럼 템플릿으로 생성하거나 백업에서 복구하면 시간이 너무 오래 걸립니다.)
  1. 미리 생성된 인프라 (컴퓨팅 계층):
  • A번: DR 리전에 ASG와 로드 밸런서를 "만듭니다(Create)". 즉, 인프라를 미리 깔아두는 것입니다. 장애가 터지면 즉시 트래픽만 돌리면 되므로 다운타임이 최소화됩니다.
  1. DNS 장애 조치 (네트워크 계층):
  • Route 53의 DNS Failover 기능은 헬스 체크를 통해 기본 리전이 죽으면 자동으로 DR 리전으로 트래픽을 돌려줍니다. 가장 표준적이고 빠른 방법입니다.

❌ 오답 분석

  • B, C: "필요할 때 시작(Launch when needed)"한다는 것은 "파일럿 라이트(Pilot Light)"나 "백업 및 복구" 전략에 가깝습니다. 이는 비용은 아낄 수 있지만, 복구 시간(RTO)이 길어져서 "최소한의 다운타임"에는 맞지 않습니다.
  • D: 인프라 구성은 좋지만, 트래픽 전환 방식(Lambda)이 비효율적입니다. Route 53 자체 기능(DNS Failover)을 쓰는 것이 베스트 프랙티스입니다.

📝 시험장 암기 공식

"최소한의 다운타임" + "멀티 리전 DR"
1. DB: Global Tables (또는 RDS Read Replica)
2. App: 미리 생성해 둠 (Warm Standby / Active-Active)
3. Routing: Route 53 DNS Failover

정답 및 해설

정답: A (AWS Snowball Edge Storage Optimized 장치를 주문합니다...)

이 문제는 "대용량 데이터(20TB)"를 "짧은 시간(2주)" 안에, "최소한의 다운타임"으로 마이그레이션하는 AWS의 표준 아키텍처 패턴을 묻는 문제입니다.

💡 핵심 분석

  1. 데이터 크기 (20TB):
  • AWS Snowmobile (B): 이건 엑사바이트급(최대 100PB) 데이터를 옮길 때 쓰는 트럭입니다. 20TB를 옮기려고 트럭을 부르는 건 배보다 배꼽이 더 큽니다. (탈락)
  • AWS Snowball Edge: 용량이 80TB 정도라 20TB를 담기에 아주 적절합니다.
  1. 시간 제약 (2주) vs Direct Connect (D):
  • Direct Connect (DX): 전용선을 물리적으로 설치하고 개통하는 데는 보통 수 주에서 수 개월이 걸립니다. "2주 안에"라는 조건을 맞추기 불가능에 가깝습니다. (탈락)
  • 반면, Snowball은 주문하고 배송받고 다시 보내는 데 1주일 정도면 충분합니다.
  1. 장치 유형 (A vs C):
  • Compute Optimized (C): 이건 현장에서 머신러닝이나 복잡한 계산을 하라고 GPU를 달아놓은 비싼 장비입니다.
  • Storage Optimized (A): 데이터 전송이 목적이라면 저장 공간이 넉넉하고 저렴한 Storage Optimized가 비용 효율적입니다.
  1. 최소 다운타임 (DMS + SCT + Snowball 조합):
  • 가장 큰 덩어리(20TB)는 Snowball에 담아 택배로 보냅니다. (오프라인 전송).
  • 택배가 가는 며칠 동안 DB에 새로 쌓인 데이터는 DMS의 CDC(변경 데이터 캡처) 기능을 통해 인터넷으로 실시간 동기화합니다.
  • 이렇게 하면 대용량 전송 시간을 아끼면서도, 서비스 중단 시간은 마지막에 전환하는 순간(Cut-over)으로 최소화할 수 있습니다.

📝 시험장 암기 공식

"대용량 DB 마이그레이션" + "네트워크 느림 / 시간 촉박" + "최소 다운타임"
➡️ DMS + SCT + Snowball Edge
"페타바이트(PB)급 데이터"
➡️ Snowmobile

Direct Connect는 설치 시간이 오래 걸린다는 점을 꼭 기억하세요!
이 패턴은 실무에서도 대용량 마이그레이션 시 자주 고려되는 정석적인 방법입니다.

이 문제는 "성능 향상(수직적 확장)"과 "비용 최적화(예약 인스턴스)"를 동시에 달성하는 방법을 묻고 있습니다. "인프라를 추가하지 않는다"는 제약 조건이 핵심입니다.

💡 핵심 분석

  1. "더 큰 작업 부하 수용" 수직적 확장 (Scale Up):
  • "인프라를 추가하지 않고(without adding infrastructure)"라는 말은 서버 개수를 늘리는 것(수평적 확장, Read Replica 추가 등)을 피하겠다는 뜻입니다.
  • 기존 인프라 내에서 성능을 올리는 방법은 인스턴스 유형을 더 좋은 것(CPU, RAM이 높은 것)으로 변경하는 "인스턴스 크기 확장(Resize)"입니다.
  1. "가장 비용 효율적" 예약 인스턴스 (Reserved Instance):
  • 신제품 출시가 성공했고 작업 부하가 증가한 상태가 지속될 것입니다.
  • 이렇게 꾸준한 워크로드는 온디맨드(On-Demand)보다 1년 또는 3년 약정을 거는 예약 인스턴스(RI)가 훨씬 저렴합니다.

❌ 오답 분석

  • B. 다중 AZ (Multi-AZ):
  • Multi-AZ는 "고가용성(HA)"을 위한 기능입니다. 대기(Standby) 인스턴스는 평소에 놀고 있기 때문에 성능 향상에 도움을 주지 않습니다.

📝 시험장 암기 노트

"성능이 부족하다" + "인프라 추가(개수 늘리기) 싫다"
인스턴스 유형 변경 (Scale Up / 더 크게 만들기)
"사용량이 꾸준하다" + "싸게 쓰고 싶다"
예약 인스턴스 (Reserved Instances)

정답: B (AWS WAF를 배포하고 ALB와 연결한 후 속도 제한 규칙을 구성합니다.)

이 문제는 "특정 IP에서 요청이 폭주(DDoS 의심)"하는데 "IP가 자꾸 바뀐다"는 상황을 해결하는 전형적인 보안 문제입니다.

💡 3초 컷 필승 공식: "요청 폭주(High Request Rate)" + "IP 변경" = AWS WAF⭐

  1. AWS WAF의 속도 기반 규칙 (Rate-based Rules):
  • 이 기능은 "5분 동안 특정 IP에서 2,000번 이상 요청이 오면 자동으로 차단해!"와 같은 설정을 할 수 있습니다.
  • 동적 IP 대응: 공격자가 IP를 바꿔도, 그 새로운 IP가 또 요청을 많이 보내면 자동으로 감지해서 차단합니다. 관리자가 일일이 IP를 등록할 필요가 없습니다.
  • 합법적 사용자 보호: 일반적인 사용자는 5분 동안 수천 번 요청을 보낼 일이 없으므로 차단되지 않습니다. 공격자만 콕 집어냅니다.

❌ 오답 분석

  • A. Amazon Inspector:
  • 이건 "취약점 진단 도구"입니다. (예: 서버에 보안 구멍이 있나?). 들어오는 트래픽을 막는 방화벽 기능이 전혀 없습니다.
  • C. 네트워크 ACL (NACL):
  • NACL은 특정 IP를 수동으로 차단해야 합니다. 문제에서 "IP가 변경된다"고 했으므로, 바뀔 때마다 사람이 일일이 쫓아다니며 막을 수 없습니다. (관리 불가능).
  • D. Amazon GuardDuty:
  • 이건 "탐지(Detection)" 도구입니다. "공격받고 있어요!"라고 알려줄 수는 있지만, WAF처럼 트래픽을 직접 차단(Block)하는 기능은 없습니다. 또한 "속도 제한 보호"라는 기능 자체가 없습니다.

📝 시험장 암기 노트

"DDoS 공격 / HTTP 요청 폭주 (Flood)" + "자동 차단 필요"
➡️ AWS WAF (Rate-based Rules / 속도 제한 규칙)
"보안 취약점 스캔" ➡️ Inspector
"위협 탐지 (로그 분석)" ➡️ GuardDuty

문제의 핵심인 "높은 요청률"과 "불법 요청 차단"을 보고 WAF를 바로 떠올리셨다면 100점입니다!

정답: D (데이터베이스의 암호화된 스냅샷을 만듭니다. 감사자와 스냅샷을 공유합니다. AWS Key Management Service(AWS KMS) 암호화 키에 대한 액세스를 허용합니다.)

⭐이 문제는 "다른 AWS 계정과 RDS 데이터를 안전하게 공유하는 방법"을 묻는 전형적인 보안 시나리오입니다.

💡 핵심 논리: "스냅샷 공유 + KMS 키 허용"

  1. 계정 간 격리:
  • 감사자는 "자체 데이터베이스 사본"을 원합니다. 즉, 우리 회사 네트워크(프라이빗 서브넷)에 들어오게 하는 것이 아니라, 데이터를 그들 계정으로 넘겨줘서 알아서 보게 해야 합니다.
  • 가장 좋은 방법은 RDS 스냅샷(백업본)을 찍어서 감사자 계정과 공유하는 것입니다.
  1. 보안 (암호화):
  • "가장 안전한 방법"을 물었으므로 데이터는 당연히 암호화되어 있어야 합니다.
  • 암호화된 스냅샷을 다른 계정과 공유하려면, 단순히 스냅샷 권한만 줘서는 안 됩니다. 그 암호를 풀 수 있는 열쇠인 KMS 키(CMK) 사용 권한도 감사자 계정에 줘야 합니다.
  • 이렇게 하면 감사자는 스냅샷을 자기 계정으로 복사(Copy)해 가서, 본인들의 키로 다시 암호화한 후 DB를 복원할 수 있습니다. 이것이 AWS가 권장하는 표준 절차입니다.

❌ 오답 분석

  • A. 읽기 복제본 (Read Replica):
  • 읽기 복제본은 실시간으로 연동되는 DB입니다. 외부 감사자에게 실시간 DB 연결을 열어주는 것은 보안상 위험하며, 네트워크 설정(VPC Peering 등)이 매우 복잡해집니다. 감사 목적에는 "특정 시점의 사본(스냅샷)"이 더 적합합니다.
  • B. 텍스트 파일로 내보내기 + IAM 사용자:
  • DB를 텍스트로 덤프 뜨는 것은 데이터 무결성을 해칠 수 있고 관리가 어렵습니다.
  • 또한, 외부인에게 우리 계정의 IAM 사용자(장기 자격 증명)를 만들어 주는 것은 보안 모범 사례 위반입니다. (외부인은 그들의 계정 자격 증명을 써야 합니다.)
  • C. 스냅샷을 S3로 복사 + IAM 사용자 키 공유:
  • 여기서도 "사용자의 키(Access Key/Secret Key)를 공유"한다는 점이 치명적인 보안 결격 사유입니다. 장기적인 키 공유는 유출 위험이 매우 큽니다.

📝 보안과 공유 프로세스 시험장 암기 공식

"RDS 데이터를 다른 계정(감사자, 타 부서)과 공유해야 한다"
➡️ 1. 스냅샷 생성
➡️ 2. 스냅샷 공유 설정 (타 계정 ID 추가)
➡️ 3. (암호화된 경우) KMS 키 권한 부여

정답: A (추가 IPv4 CIDR 블록을 추가하여 IP 주소 수를 늘리고 VPC에 추가 서브넷을 만듭니다. 새 CIDR을 사용하여 새 서브넷에 새 리소스를 만듭니다.)

이 문제는 "VPC의 IP 주소가 부족할 때 어떻게 할래?"를 묻는 아주 전형적인 네트워킹 문제입니다.

💡 3초 컷 필승 공식: "부족하면 더 붙이면 된다 (Secondary CIDR)"

  1. 가장 간단한 해결책 (Option A):
  • AWS는 기존 VPC에 "보조(Secondary) CIDR 블록"을 추가하는 기능을 제공합니다.
  • 예를 들어, 처음에 10.0.0.0/24 (IP 256개)로 작게 만들었더라도, 나중에 10.1.0.0/16 (IP 65,000개)을 같은 VPC에 띡 하고 붙일 수 있습니다.
  • 관리 오버헤드 최소: VPC를 새로 만들거나, 피어링(Peering)을 맺거나, 라우팅 테이블을 복잡하게 건드릴 필요가 없습니다. 그냥 같은 집(VPC) 마당이 넓어진 셈이라 내부 통신도 아주 쉽습니다.
  1. 왜 나머지는 오답일까요? (전부 "새 집(VPC)을 짓는" 방식)
  • B (VPC 피어링): 새 VPC를 만들고 연결해야 합니다. 관리해야 할 VPC가 2개가 되고, 피어링 연결 설정, 라우팅 테이블 업데이트 등 손이 많이 갑니다.
  • C (Transit Gateway): 이건 VPC가 수십, 수백 개일 때 쓰는 중앙 허브입니다. 단순히 IP 늘리자고 비싼 TGW를 쓰는 건 닭 잡는데 소 잡는 칼 쓰는 격입니다.
  • D (VPN): 클라우드 내부 통신에 VPN을 쓰는 건 속도도 느리고 설정도 제일 복잡합니다. 최악의 선택입니다.

📝 시험장 암기 노트

"VPC IP 주소가 부족하다 (Running out of IP addresses)"
➡️ VPC에 보조(Secondary) CIDR 블록 추가
(절대 VPC를 새로 만들거나 크기를 '수정'한다고 생각하지 마세요. '추가'하는 것입니다.)

이 기능은 비교적 최근(2017년)에 추가된 기능이라, 과거 덤프에서는 "VPC를 새로 만든다"가 답이었을 수도 있지만, ⭐최신 AWS 시험에서는 "CIDR 추가"가 무조건 정답입니다.

이 문제는 기존에 생성해 둔 두 가지 백업(RDS 스냅샷, mysqldump 파일)을 활용하여 새로운 Aurora MySQL 호환 인스턴스를 생성하는 올바른 방법을 묻는 것입니다.

💡 헷갈림 방지: "누가 누구랑 짝꿍인가?"

1. 스냅샷 (Snapshot) = AWS 내부 셔틀버스 (A번)

  • 성격: AWS가 찍은 "하드디스크 통째로 복제본"입니다.
  • 특징: AWS 내부 시스템끼리는 호환이 아주 잘 됩니다.
  • 공식: RDS 스냅샷 [클릭 한 번] Aurora로 변신!
  • 결론: "직접 가져오기(Direct Import/Restore)"가 가능합니다. (가장 쉬움)

2. 덤프 파일 (mysqldump) = 이삿짐 박스 (C번)

  • 성격: 데이터가 글자(SQL 텍스트)로 적힌 "파일"입니다.
  • 특징: 파일이니까 일단 창고(S3)에 올려야 합니다.
  • 공식: 내 컴퓨터(Dump) S3(업로드) Aurora가 가져감(Import)
  • 결론: 덤프 파일은 무조건 S3를 거쳐서 가야 합니다.

❌ 왜 나머지는 오답일까요? (이게 핵심!)

여기가 헷갈리는 포인트입니다. "DMS(Database Migration Service)"는 만능이 아닙니다.

  • 오답 D (스냅샷 + DMS):
  • 이유: DMS는 "살아있는 DB"에 빨대를 꽂아서 데이터를 빨아오는 도구입니다.
  • 스냅샷은 죽어있는(멈춰있는) 파일입니다. DMS가 빨대를 꽂을 수 없습니다. (연결 불가)

📝 시험장 3초 암기 노트

  1. "RDS 스냅샷이 있다" 그냥 Aurora로 복원(Restore)해라. (S3나 DMS 필요 없음)
  2. "SQL 덤프 파일이 있다" S3에 올리고 넣어라.
  3. "DMS를 쓴다" 반드시 "소스 DB가 켜져 있어야" 한다. (스냅샷/덤프 파일에는 못 씀)

정답: C (Amazon S3 버킷의 정적 웹 콘텐츠를 호스팅하기 위해 Amazon CloudFront 배포를 생성합니다.)

출제자의 의도는 요금 할인이 아니라 "아키텍처를 바꿔서 일을 덜 하게 만드는 것"입니다.

💡 3초 컷 필승 공식: "비싼 인력(EC2)에게 전단지 배포(정적 파일) 시키지 마라"

❌ 오답 분석 (왜 자꾸 틀릴까요?)

  • A (예약 인스턴스), B (스팟 인스턴스):
  • 이건 "비효율적인 구조는 그대로 두고, 서버 값만 깎아보자"는 접근입니다.
  • 물론 할인은 되겠지만, 여전히 불필요한 서버가 계속 돌아가야 합니다. 아키텍처적으로 근본적인 해결책이 아닙니다.
  • D (API Gateway + Lambda):
  • Lambda는 코드 실행기입니다. 정적 파일 호스팅용으로 쓰면 S3보다 훨씬 비싸고 느립니다.

📝 시험장 암기 노트: "정적 콘텐츠" 패턴

"EC2가 정적 콘텐츠(이미지/동영상) 때문에 힘들어한다/비용이 많이 나온다."
1. 해결책: S3 + CloudFront 조합을 찾으세요. (무조건 이게 정답)
2. 원리: EC2의 짐을 덜어준다 (Offload).
3. 함정: EC2 인스턴스 타입 변경(Spot/RI)은 오답입니다.

⭐이 문제는 기술 지식보다 "문맥 파악"이 중요해서 한국인들이 특히 자주 틀립니다.
"서버를 싸게 쓰는 것"보다 "서버를 안 쓰는 것"이 더 훌륭한 비용 최적화라는 걸 기억하면, 다음엔 절대 안 틀립니다!

📝 시험장 암기 노트: Lake Formation

"Lake Formation" + "다른 계정과 공유" + "관리 쉽게/확장성 있게"
➡️ LF-Tags (태그 기반 액세스 제어)
"데이터를 복사한다(Copy/S3 Replication)"
➡️ 오답 (데이터 레이크 문제에서는 대부분 오답)

⭐ "Lake Formation 공유 = 태그(Tag)"

정답: A (Amazon S3를 Transfer Acceleration과 함께 사용하여 애플리케이션을 호스팅합니다.)

이 문제는 "전 세계 사용자(글로벌)"가 "대용량 파일(GB)"을 "업로드/다운로드"할 때 속도를 높이는 기술을 묻는 문제입니다.

💡 3초 컷 필승 공식: "S3 장거리 업로드/다운로드 가속"

  1. S3 Transfer Acceleration (전송 가속화):
  • 사용자가 S3 버킷에 파일을 올릴 때, 미국에 있는 버킷까지 인터넷 공용망을 타고 가면 느립니다.
  • 이 기능을 켜면, 사용자 집 근처의 엣지 로케이션(Edge Location)까지만 업로드합니다.
  • 그 뒤로는 AWS 전용 고속 네트워크(Backbone)를 타고 버킷까지 쏩니다.
  • 결과: "전 세계", "대용량", "업로드/다운로드" 속도가 획기적으로 빨라집니다.
  1. 왜 CloudFront(C)는 아닐까요?
  • CloudFront는 주로 "다운로드 캐싱(Caching)"이 주특기입니다.
  • 문제에서 "고유한 데이터(Unique data)"라고 했습니다. 고유하다는 건 캐시(복사본)를 못 쓴다는 뜻입니다. 캐시 적중률이 0%이므로 CloudFront의 장점이 사라집니다.
  • EC2를 거쳐 업로드하면 서버 병목이 생깁니다. S3로 직접 쏘는 게 가장 효율적입니다.

❌ 오답 분석

  • B. CacheControl: 이건 브라우저한테 "임시 파일 저장해 둬"라고 하는 겁니다. 업로드 속도와는 아무 상관이 없습니다.
  • C. EC2 + CloudFront: 위에서 설명했듯, "고유한 데이터"는 캐싱 효과가 없고, EC2를 거치면 비용과 병목현상이 발생합니다.
  • D. ElastiCache: 이건 DB 캐시(Redis/Memcached)입니다. 기가바이트(GB) 단위의 파일을 저장하는 곳이 아닙니다.

⭐"대용량 업로드?" → "Transfer Acceleration!"

정답: B (DB 인스턴스를 Multi-AZ로 업데이트하고 삭제 보호를 활성화합니다. EC2 인스턴스를 Application Load Balancer 뒤에 배치하고 여러 가용성 영역에 걸쳐 EC2 자동 확장 그룹에서 실행합니다.)

이 문제는 "단일 실패 지점(Single Point of Failure)" 제거와 "인적 오류(휴먼 에러) 방지"를 통해 인프라의 안정성을 극대화하는 방법을 묻는 문제입니다.

💡 핵심 분석: 안정성을 높이는 3단계 처방

  1. 데이터베이스 보호 (삭제 방지 + 고가용성):
  • 문제 상황: "직원이 실수로 DB를 지워서 24시간 장애 발생."
  • 해결책 1: 삭제 보호(Deletion Protection)를 활성화하면 실수를 막을 수 있습니다.
  • 해결책 2: Multi-AZ(다중 가용 영역) 배포를 하면, 하나의 DB가 죽어도 대기(Standby) DB가 즉시 살아나므로 안정성이 극대화됩니다.
  1. 웹 서버 보호 (자동 복구 + 분산):
  • 문제 상황: "수동으로 만든 EC2", "단일 가용 영역(AZ)에 몰려 있음."
  • 해결책: EC2가 죽으면 자동으로 다시 살려주는 Auto Scaling Group(ASG)을 사용하고, 화재나 정전 대비를 위해 여러 가용 영역(Multi-AZ)에 분산 배치해야 합니다.
  • 트래픽 관리: 분산된 서버에 트래픽을 골고루 나눠줄 Application Load Balancer(ALB)가 필수입니다.

❌ 오답 분석

  • A. EC2 하나 삭제: 안정성을 높이자고 서버를 줄이는 건 앞뒤가 맞지 않습니다. 이중화(Redundancy)를 포기하는 것입니다.
  • C. Lambda로 이중 쓰기: 애플리케이션이 Lambda를 통해 두 DB에 직접 데이터를 쓰는 방식(Dual Write)은 데이터 불일치 문제를 일으키기 쉽고 구현이 매우 복잡합니다. RDS 자체 기능인 Multi-AZ를 쓰는 것이 훨씬 안정적입니다.
  • D. 스팟 인스턴스 사용: 스팟 인스턴스는 AWS가 필요하면 회수해 가는 서버입니다. 언제 꺼질지 모르기 때문에 "안정성 극대화"가 목표인 웹 서버에는 부적합합니다. (비용 절감용입니다).

📝 시험장 암기 공식

⭐"안정성/고가용성(High Availability) 극대화"
1. DB: Multi-AZ + Deletion Protection
2. Web/App: Multi-AZ + Auto Scaling + Load Balancer (ALB/NLB)

이 조합은 AWS 아키텍처의 가장 기본적이고 강력한 "국룰"입니다.

정답: A (기업 데이터 센터에서 AWS DataSync 에이전트를 만듭니다. 데이터 전송 작업을 만듭니다. Amazon S3 버킷으로 전송을 시작합니다.)

이 문제는 "700TB 데이터", "10Gbps 전용선", "90일 이내", 그리고 "전송 중에도 데이터 사용/수정 가능(Online Migration)"이라는 조건을 모두 만족하는 솔루션을 찾는 것입니다.

📝 시험장 암기 공식

"네트워크가 빠르다 (1Gbps 이상)" + "전송 중에도 파일 쓴다 (Online/Live)"
➡️ AWS DataSync
"네트워크가 느리다" + "데이터가 너무 많다 (PB급)" + "마이그레이션 중에는 데이터 안 건드린다"
➡️ Snowball Family

700TB와 10Gbps 조합은 DataSync가 활약하기 가장 좋은 환경입니다.

S3 버킷에 대한 규정 준수 보관 모드로 S3 객체 잠금을 켭니다. 보관 기간을 7년 후 만료되도록 설정합니다. S3 일괄 작업을 사용하여 기존 데이 터를 규정 준수 상태로 만듭니다.

💡 핵심 분석: "법적으로 못 지우게 해라" + "옛날 파일도 싹 다"

  1. 법적 요구 사항 (Legal Requirement) = 규정 준수 모드 (Compliance Mode):
  • Object Lock(객체 잠금)에는 두 가지 모드가 있습니다.
  • 거버넌스 모드 (Governance Mode): 특별한 권한(Root 등)이 있으면 지울 수 있습니다. (B번 탈락)
  • 규정 준수 모드 (Compliance Mode): 그 누구도, 심지어 AWS 계정의 루트 사용자(Root User)도 정해진 기간 동안 절대 삭제하거나 덮어쓸 수 없습니다. 법적 보관 의무를 위해서는 이 모드가 필수입니다.
  1. 기존 데이터 처리 = S3 일괄 작업 (Batch Operations):
  • S3 버킷에 Object Lock을 켜도, 새로 들어오는 파일에만 자동 적용되고 이미 있던 파일(기존 데이터)은 잠기지 않습니다.
  • 기존 파일 수백만 개에 하나하나 잠금을 걸어야 하는데, 이걸 사람이 하거나 스크립트로 복사(Copy)하는 건(C번) 오버헤드가 너무 큽니다.
  • 이때 S3 일괄 작업(Batch Operations)을 사용하면, 클릭 몇 번으로 기존의 모든 객체에 "규정 준수 모드 7년" 설정을 한 방에 적용할 수 있습니다. 이게 "가장 적은 운영 오버헤드"입니다.

📝 시험장 암기 공식

"법적 규제 / 삭제 절대 불가 / WORM(Write Once Read Many)"
➡️ S3 Object Lock - Compliance Mode (규정 준수 모드)
"이미 저장된(기존) 객체에도 적용해야 함"
➡️ S3 Batch Operations (S3 일괄 작업)

이 문제는 S3의 심화 기능인 Object Lock과 Batch Operations를 결합한 난이도 높은 문제
⭐ "법적 요구사항 = Compliance(규정 준수 보존 모드)", "기존 대량 처리 = Batch"

정답: A (각 지역에 대한 Amazon Route 53 상태 검사를 만듭니다. 액티브-액티브 장애 조치 구성을 사용합니다.)

⭐"글로벌(리전 간) 트래픽 라우팅 = Route 53"

  1. 가장 높은 곳에 있는 신호등:
  • AWS 리전(미국, 한국, 일본...)보다 더 위에 있는 서비스는 DNS(Domain Name System)인 Route 53입니다.
  • 사용자가 www.example.com을 쳤을 때, "너는 한국이랑 가까우니까 서울 리전으로 가", "미국 리전이 죽었네? 그럼 유럽으로 가"라고 교통 정리를 할 수 있는 유일한 서비스입니다.
  1. 액티브-액티브 (Active-Active):
  • 두 리전(서울, 도쿄) 모두 살아있어서 트래픽을 나눠 갖는 방식입니다.
  • Route 53이 양쪽의 상태(Health Check)를 계속 감시하다가, 한쪽이 죽으면 살아있는 쪽으로만 보내줍니다. 이게 가장 표준적인 멀티 리전 아키텍처입니다.

❌ 오답 분석

  • B. CloudFront:
  • CloudFront는 CDN(캐시)입니다. 물론 '오리진 그룹'을 써서 장애 조치를 할 수는 있지만, CloudFront 자체가 "리전 간 트래픽 라우팅"의 주체는 아닙니다. 문제의 핵심인 "지역 장애 조치 및 라우팅"은 DNS 레벨(Route 53)에서 처리하는 것이 정석입니다.
  • C. Transit Gateway:
  • 이건 "내부 네트워크(VPC) 연결용"입니다. (예: 서울 VPC와 부산 VPC 연결). 외부 사용자의 인터넷 트래픽을 라우팅하는 도구가 아닙니다.
  • D. ALB (로드 밸런서):
  • ALB는 "리전 내부"에서만 작동하는 녀석입니다. (Region-Specific).
  • 서울 리전의 ALB가 죽으면 끝입니다. 리전 장애에 대비할 수 없습니다.

📝 시험장 암기 노트

"여러 리전(Multi-Region)으로 트래픽을 보낸다"
"지역 간 장애 조치(Failover)를 한다"
➡️ 무조건 Route 53 (DNS가 대장이다)

"리전(Region)"과 "글로벌(Global)" 서비스의 경계를 명확히 긋는 과정

  • EC2, ALB, Lambda = 리전 안에서 노는 애들
  • Route 53, CloudFront, IAM = 리전 위에서 노는 애들 (글로벌)

📝 시험장 암기 공식

"Oracle/SQL Server 마이그레이션" + "OS 접근 권한 필요 / 특수 기능 설치" + "관리는 편하게 하고 싶다" ➡️ Amazon RDS Custom

이 문제는 "단일 서버(Monolith)"에서 실행되던 애플리케이션을 AWS의 "Well-Architected(모범 사례)"에 맞춰 3계층(3-Tier) 아키텍처로 제대로 찢어발기는(분리하는) 방법을 묻는 종합 설계 문제입니다.

💡 3계층 아키텍처 필승 공식 (Well-Architected)

진정한 3계층 구조는 "분리(Decoupling)", "보안(Security)", "고가용성(HA)"이 핵심입니다.

1. 구조 및 컴퓨팅

  • 단일 서버 탈피: 기존에 한 서버에 뭉쳐있던 Web, App, DB를 리팩토링(Refactoring)하여 각각 독립된 계층으로 떼어내야 확장성(Scalability)이 생깁니다.
  • 이중화: 두 개의 가용 영역(2 AZ)에 걸쳐 VPC를 만들고, Web과 App 계층은 각각 Auto Scaling Group을 통해 자동으로 늘어나고 줄어들게 설정합니다. 이것이 복원성과 확장성의 기초입니다.

2. 트래픽 흐름 및 보안 그룹 체이닝

  • 입구는 ELB: 외부 트래픽은 반드시 Elastic Load Balancer(ELB)가 먼저 받아서 Web 서버로 넘겨야 합니다.
  • 보안 그룹 참조 (SG Chaining):
    • Web 서버 보안 그룹: "ELB에서 오는 것만 허용"
    • App 서버 보안 그룹: "Web 서버 보안 그룹에서 오는 것만 허용"
    • DB 서버 보안 그룹: "App 서버 보안 그룹에서 오는 것만 허용"
  • 이렇게 IP가 아니라 "보안 그룹 ID를 참조"하여 구멍을 뚫는 것이 AWS 보안의 정석입니다.

3. 데이터베이스 고가용성

  • Multi-AZ: 데이터베이스가 죽으면 서비스 전체가 멈춥니다. 따라서 단일(Single) RDS(B, D번)가 아니라 Multi-AZ(다중 AZ)를 써서 하나가 죽어도 바로 대체되도록 해야 합니다(복원성).
  • 접근 제어: DB는 프라이빗 서브넷에 숨기고, 오직 App 계층에서만 접속되도록 보안 그룹을 조여야 합니다.

📝 시험장 암기 공식: 3-Tier Architecture

1. 구조: 2 AZ 이상 + Auto Scaling (무조건 분산)
2. 보안: ELB Web App DB (보안 그룹 체이닝)
3. DB: Multi-AZ RDS (단일 DB는 오답)

⭐이 3가지 요소가 합쳐져야 완벽한 AWS 권장 아키텍처가 완성됩니다. 아주 중요한 설계 패턴입니다!

이 문제는 "AWS 공동 책임 모델(Shared Responsibility Model)"을 묻는 아주 중요한 개념 문제입니다. ⭐"사용자(Customer)가 해야 할 일"과 "AWS가 해주는 일"을 명확히 구분해야 합니다.

💡 3초 컷 필승 공식: "데이터와 설정은 내 몫, 하드웨어와 OS는 AWS 몫"

1. 사용자(Customer)의 책임 (정답 분석):

  • B. RDS DB 인스턴스 생성 및 유지 관리 창 구성:
  • AWS가 DB를 설치해 주지만, "어떤 DB를 만들지(생성)", "언제 점검할지(유지 관리 창 설정)"는 사용자가 결정해야 합니다. 이는 구성(Configuration)의 영역입니다.
  • C. ECS의 추가 소프트웨어 구성 (모니터링, 로그 등):
  • ECS가 컨테이너를 돌려주지만, 그 컨테이너 안에서 돌아가는 애플리케이션 로그를 어떻게 수집할지, 침입 탐지 에이전트를 심을지는 사용자가 직접 설정해야 합니다. (특히 EC2 기반 ECS라면 OS 보안도 사용자 책임입니다).
  • F. Direct Connect 암호화:
  • Direct Connect는 물리적인 전용선입니다. 기본적으로 암호화가 되어 있지 않습니다.
  • 이 선을 타고 지나가는 데이터를 암호화(예: VPN, TLS)하는 것은 전적으로 데이터 주인인 사용자의 책임입니다.

❌ 오답 분석 (AWS의 책임)

  • A. RDS 인프라, OS, 플랫폼 관리: RDS는 완전 관리형(Managed) 서비스입니다. OS 설치, 업데이트, 하드웨어 관리는 AWS가 합니다.
  • D. RDS 패치 설치: 사용자가 "언제(유지 관리 창)" 할지는 정하지만, 실제 패치 파일을 다운받아 설치하는 작업 자체는 AWS가 자동으로 수행합니다.
  • E. 물리적 보안: 데이터 센터 문지기, CCTV, 서버실 출입 통제 등 물리적 보안은 100% AWS의 책임입니다.
  • 공략법: "맞는 것을 찾기"보다 "확실히 아닌 것(AWS 책임)"을 지우는 소거법이 훨씬 빠릅니다.
  • "물리적 보안? AWS네. (E 탈락)"
  • "RDS OS 관리? AWS네. (A 탈락)"
  • "RDS 패치 설치? AWS가 해주지. (D 탈락)"
  • 남는 게 정답입니다.

너무 걱정 마세요. "물리적 보안 = AWS", "암호화/설정 = 나" 이 큰 원칙만 잡고 있으면 다중 선택 문제도 기계적으로 풀 수 있습니다.

정답: B (메모리가 1GB인 AWS Lambda 함수에 코드를 복사합니다. 매 시간 코드를 실행하기 위한 Amazon EventBridge 예약 규칙을 만듭니다.)

이 문제는 "짧은 시간(10초)" 동안 "간헐적(매 시간)"으로 실행되는 작업을 가장 싸게 처리하는 방법을 묻는, ⭐Lambda의 교과서적인 사용 사례입니다.

📝 시험장 암기 공식

"실행 시간이 짧다 (15분 미만)" + "가끔 실행된다 (Cron Job / 스케줄)"
➡️ 무조건 AWS Lambda + EventBridge (CloudWatch Events)

가장 저렴하고 관리하기 쉬운 B번이 정답입니다. 이 패턴은 비용 최적화 문제에서 단골 손님이니 꼭 기억하세요! 🚀

📝 시험장 암기 공식

"인수인계 자료 없음" + "전체 리소스 관계 파악 및 시각화(Diagram)"
➡️ Workload Discovery on AWS

📝 "예산 초과 시 자동 차단"

1. 설정 위치: Billing Dashboard (Budgets)
2. 권한 위임: IAM Role (Budgets 서비스가 사용할 역할)
3. 차단 방법(Organizations): SCP (Service Control Policy) 적용

이 기능은 "AWS Budget Actions"라는 이름으로 자주 출제되니 꼭 기억해 두세요!

cf.) Cost and Usage Reports(CUR) : 상세 청구 데이터를 파일로 떨어뜨려 주는 기능

정답: C (AWS Backup을 사용하여 백업 계획을 만듭니다. EC2 인스턴스에 대해 두 번째 Region에 대한 크로스 리전 백업을 구성합니다.)

이 문제는 "중앙 관리(Central Management)"와 "비용 효율성(Cost-effective)" 그리고 "리전 간 백업(Cross-Region)"을 동시에 해결하는 AWS의 표준 백업 솔루션을 묻는 문제입니다.

📝 시험장 암기 공식

"백업을 중앙에서 관리하고 싶다" + "다른 리전으로 보내고 싶다"
➡️ AWS Backup (Cross-Region Copy)

백업 문제에서 AWS Backup이 보기에 있다면, 90% 이상 정답일 확률이 높습니다. 특히 "중앙 관리"라는 단어와 찰떡궁합입니다!

정답 및 해설

정답: C (AWS Transfer Family를 사용하여 데이터를 전송합니다. IdP 인증을 위한 AWS Lambda 함수를 만듭니다.)

💡 3초 컷 필승 공식: "AS2 프로토콜" = "AWS Transfer Family"

  1. AS2가 뭐길래?
  • 제조업이나 유통업에서 서로 주문서/송장 데이터를 주고받을 때 쓰는 매우 오래된 B2B 전용 프로토콜입니다.
  • AWS에서 FTP, SFTP, FTPS, 그리고 AS2를 지원하는 서비스는 딱 하나, AWS Transfer Family뿐입니다. 다른 애들은 이 언어를 모릅니다.
  1. 자체 IdP 인증 (Custom Auth):
  • AWS Transfer Family는 기본적으로 서비스 관리형 사용자도 지원하지만, 회사가 원래 쓰던 아이디/비번(IdP)을 쓰고 싶으면 AWS Lambda를 연결해서 "얘 우리 직원 맞아?" 하고 물어보게 설정할 수 있습니다.

📝 시험장 암기 노트

"FTP / SFTP / FTPS" 혹은 "AS2 프로토콜"을 써야 한다?
➡️ 무조건 AWS Transfer Family
"자체 ID(IdP)를 쓰고 싶다"
➡️ Lambda나 API Gateway를 붙여서 커스텀 인증

⭐ "AS2 = Transfer Family"

📝 시험장 암기 공식

"최소한의 관리(Least Management)"
1. 컴퓨팅: Lambda (1순위)
2. 데이터베이스: DynamoDB (1순위)

⚠️ 단, "관계형(Relational)" 조건이 붙으면?
➡️ DynamoDB 버리고 RDS (또는 Aurora Serverless) 선택!

정답: A (조직 관리 계정 청구 콘솔에서 department라는 사용자 정의 비용 할당 태그를 활성화합니다...)

이 문제는 "내가 만든 태그(department)로 돈 계산을 하려면 어디서 버튼을 눌러야 해?"를 묻는 문제입니다.

💡 3초 컷 필승 공식: "누가 만들었나?" + "어디서 보나?"

  1. 태그의 종류 구분:
  • 사용자 정의 (User-Defined): department, Project, Owner 등 우리가 직접 이름 붙인 태그입니다.
  • AWS 정의 (AWS-Defined): aws:createdBy, aws:cloudformation:stack-name 처럼 AWS가 알아서 붙이는 태그입니다. (보통 aws:로 시작)
  • 문제에서 department 태그를 회사가 만들었다고 했으니 "사용자 정의"가 맞습니다. (B, D 탈락)
  1. 활성화 위치 (Organizations):
  • 여러 계정의 비용을 합쳐서 보려면 대장 계정인 "관리 계정(Management Account)"의 청구 콘솔에서 태그를 활성화해야 합니다.
  • 개별 멤버 계정에서 켜봐야 전체 통합 보고서에는 반영되지 않습니다. (C 탈락)

❌ 오답 분석

  • B, D (AWS 정의): department는 AWS가 자동으로 만든 시스템 태그가 아닙니다.
  • C, D (멤버 계정): 조직 전체(All Accounts)의 비용을 보려면 관리 계정(Master)에서 설정해야 합니다.

📝 시험장 암기 노트

"사용자가 만든 태그(부서명 등)" ➡️ User-Defined (사용자 정의)
"AWS가 붙인 태그(aws:*)" ➡️ AWS-Defined (AWS 정의)**
"조직 전체 비용 보고" ➡️ 관리 계정(Management Account)에서 활성화

이 개념은 비용 관리 문제에서 가장 기초이자 핵심입니다.
이제 태그 문제 나오면 "누가 만들었지? 어디서 켜야 하지?"만 생각하세요. 바로 풀립니다! 🚀

⭐이 문제는 "SaaS(Salesforce)랑 AWS랑 데이터 주고받기"가 핵심입니다.

📝 시험장 암기 노트

"Salesforce, Slack, ServiceNow 같은 SaaS 데이터를 가져오고 싶다"
➡️ Amazon AppFlow (코딩 없이 클릭만으로 연동)
(기존의 DataSync나 Transfer Family와 헷갈리지 마세요. 걔네는 파일/서버 용이고, AppFlow는 SaaS 앱 용입니다.)

🍵 데이터 이동 문제

시험에 나오는 "데이터 이동 도구"는 딱 4명만 기억하면 정리 끝입니다!

  1. 서버 파일 몽땅 이사: DataSync
  2. FTP/SFTP 레거시 통신: Transfer Family
  3. SaaS(Salesforce) 연동: AppFlow (오늘 배운 것!)
  4. 실시간 스트리밍: Kinesis

❌ 오답 분석

  • A (gp3), D (gp2): 범용 SSD는 다중 연결을 지원하지 않습니다. (단일 인스턴스 연결만 가능)
  • B (st1): HDD 타입도 다중 연결을 지원하지 않습니다.

📝 시험장 암기 노트: EBS 볼륨 궁합

"하나의 EBS를 여러 인스턴스가 공유해야 한다 (Multi-Attach)"
➡️ 무조건 io1 또는 io2 (Provisioned IOPS)
(gp3는 가성비 킹이지만, 여기선 입장 불가입니다!)

이 문제는 논리적인 추론보다는 "지원 여부 암기"를 묻는 문제입니다.
"다중 연결은 비싼 놈(io)만 된다"라고 외워버리면 다음엔 절대 안 틀립니다. 화이팅! 🤯

정답: A (Multi-AZ EC2 자동 확장을 사용하도록 애플리케이션을 구성하고 애플리케이션 부하 분산 장치를 생성합니다.)

이 문제는 "데이터베이스는 이미 튼튼한데(Multi-AZ), 웹 서버가 부실한(Single-AZ) 상태"를 고쳐주는 문제입니다.

💡 핵심 분석: 약점 보완 (Weakest Link)

  1. 현재 상태 진단:
  • DB: Amazon RDS Multi-AZ → 이미 고가용성(HA) 충족. (건드릴 필요 없음)
  • EC2: 단일 가용 영역(Single-AZ) → 여기가 약점! 해당 AZ에 불이 나면 웹사이트 전체가 다운됩니다.
  • 애플리케이션: 무상태(Stateless) → 서버를 여러 개로 늘려도 문제없음.
  1. 해결책 (고가용성 달성):
  • EC2 인스턴스를 하나의 AZ에만 두지 말고, 여러 AZ(Multi-AZ)에 분산 배치해야 합니다. 이를 자동화해주는 것이 Auto Scaling Group입니다.
  • 여러 곳에 흩어진 EC2들에게 트래픽을 골고루 나눠줄 Application Load Balancer(ALB)가 필수입니다.

❌ 오답 분석

  • B. 스냅샷을 다른 리전으로 전송: 이건 재해 복구(DR) 전략입니다. 실시간 고가용성(HA)과는 거리가 멉니다.
  • C. Route 53 지연 기반 라우팅: 이건 멀티 리전(Global) 환경에서 쓰는 것입니다. 지금은 단일 리전 내에서의 가용성을 논하고 있습니다.
  • D. Route 53 규칙 + ALB: ALB를 만드는 건 맞지만, "EC2를 Multi-AZ로 확장한다"는 핵심 내용이 빠져 있습니다. 서버가 한 곳에 몰려 있으면 ALB가 있어도 소용없습니다. 가장 근본적인 해결책은 A번입니다.

📝 시험장 암기 공식

"고가용성(High Availability)을 만들어라"
1. DB: Multi-AZ 켜기 (이미 되어 있음)
2. Server(EC2): Multi-AZ Auto Scaling + ALB

이제 패턴이 좀 보이시죠? "서버 한 곳에 몰빵(Single AZ)은 위험하다 → 흩어라(Multi-AZ ASG)" 이 논리만 기억하면 됩니다!

정답: B (회사 조직 관리 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.)

이 문제는 "AWS Organizations 내에서 남는 할인 혜택을 어떻게 처리할 것인가?"를 묻는 문제입니다.

💡 3초 컷 필승 공식: "남는 할인은 이웃에게 나눠줘라 (Discount Sharing)"

  1. 할인 공유 (Discount Sharing) 메커니즘:
  • AWS Organizations의 가장 큰 장점 중 하나는 "통합 결제(Consolidated Billing)"입니다.
  • 한 멤버 계정(A)에서 Savings Plan(SP)이나 예약 인스턴스(RI)를 샀는데 다 못 쓰고 남으면, 조직 내 다른 멤버 계정(B, C)이 그 남은 혜택을 자동으로 가져다 쓸 수 있습니다.
  • 단, 이 기능을 켜고 끄는 스위치는 오직 "관리 계정(Management/Master Account)"만이 가지고 있습니다. 멤버 계정은 권한이 없습니다.
  1. 관리 계정의 역할:
  • 관리 계정의 청구 설정에서 "RI 및 Savings Plans 할인 공유" 옵션을 켜야(Enable) 비로소 남는 혜택이 조직 전체로 퍼집니다. 이렇게 하면 낭비되는 50%를 다른 계정의 EC2 사용료를 깎는 데 쓸 수 있어 비용 효율이 최적화됩니다.

📝 시험장 암기 노트

"계정 A의 Savings Plan/RI가 남는다"
➡️ 관리 계정(Master)에서 "할인 공유(Discount Sharing)" 활성화
"Savings Plan을 잘못 샀다 / 남는다"
➡️ 판매 불가 (RI만 판매 가능)

정답: B (Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 프라이빗 VPC 링크를 만듭니다.)

이 문제는 "API Gateway(밖) 프라이빗 서브넷(안) 연결"을 묻는 패턴입니다.

💡 3초 컷 필승 공식: ⭐"프라이빗 API 연결 = VPC Link"

  1. 조건 1: REST API
  • 문제에서 "REST API"를 쓰라고 했습니다.
  • A, C (WebSocket API) 바로 탈락시킵니다. (50% 확률 확보)
  1. 조건 2: 프라이빗 서브넷 접근 (Outside to Inside)
  • API Gateway는 AWS가 관리하는 퍼블릭 인터넷 영역에 있는 서비스입니다.
  • ECS는 우리 집 프라이빗 서브넷(지하실)에 숨어 있습니다.
  • 밖에서 지하실로 안전하게 들어오려면 전용 "지하 터널"이 필요합니다. 이 터널의 이름이 바로 VPC Link입니다.
  • 단순히 보안 그룹(Security Group)만 연다고 해서(D번), 인터넷에 있는 API Gateway가 프라이빗 IP를 찾아서 들어올 수 없습니다. 길이 없으니까요.

📝 시험장 암기 노트

"API Gateway(공용망)" "프라이빗 서브넷의 EC2/ECS/ALB" 연결
무조건 VPC Link

  • 아까는 "S3 연결" "Gateway Endpoint" 였고,
  • 지금은 "API Gateway 연결" "VPC Link" 일 뿐입니다.

결국 "밖에서 안으로, 안에서 밖으로 어떻게 연결할래?" 라는 똑같은 주제를 주인공만 바꿔서 물어보는 겁니다.
지금 틀린 게 천만다행입니다. "API Gateway = VPC Link" 이거 하나 건졌으니, 실제 시험장에서는 1초 만에 맞힐 수 있습니다.

정답: C (S3 Lifecycle 규칙을 사용하여 S3 Standard에서 S3 Intelligent-Tiering으로 객체를 전환합니다.)

이 문제는 "액세스 패턴을 예측할 수 없다(Unknown/Unpredictable Access Patterns)"라는 문구가 나오면 무조건 선택해야 하는 S3 Intelligent-Tiering에 대한 문제입니다.

💡 3초 컷 필승 공식: "패턴 예측 불가" = "Intelligent-Tiering"

  1. 왜 Intelligent-Tiering인가?
  • 자동화된 계층 이동: S3 Intelligent-Tiering은 사용자가 데이터를 얼마나 자주 건드리는지(액세스 빈도)를 모니터링하다가, 30일 동안 안 쓰면 저렴한 계층(Infrequent Access)으로 내리고, 다시 쓰면 즉시 고성능 계층(Frequent Access)으로 올려줍니다.
  • 검색 비용(Retrieval Fee) 없음: 이게 핵심입니다. S3 Standard-IA(B번)는 보관료는 싸지만 데이터를 꺼낼 때마다 추가 요금을 냅니다. 패턴이 불규칙해서 자주 꺼내 쓰게 되면 오히려 요금 폭탄을 맞을 수 있습니다. 반면, Intelligent-Tiering은 데이터를 꺼내는 비용이 무료입니다. 따라서 언제 접근할지 모르는 데이터에 가장 안전하고 비용 효율적입니다.
  1. 구현 방법:
  • 처음부터 Intelligent-Tiering에 넣을 수도 있지만, 이미 S3 Standard에 있는 데이터를 비용 최적화하려면 S3 Lifecycle(수명 주기) 규칙을 걸어서 "며칠 지나면 Intelligent-Tiering으로 옮겨라"라고 설정하는 것이 가장 깔끔합니다.
  • D. S3 인벤토리 사용: 인벤토리는 목록을 뽑아주는 리포트 도구입니다. 이걸 보고 수동으로(또는 스크립트로) 옮기는 건 운영 오버헤드가 큽니다. C번처럼 수명 주기로 자동화하는 것이 훨씬 효율적입니다.

📝 시험장 암기 공식

"데이터에 언제 접근할지 모른다 (Unpredictable / Unknown)"
"비용을 최적화하고 싶다"
"검색 비용(Retrieval Fee) 걱정 없이 쓰고 싶다"
➡️ S3 Intelligent-Tiering

S3 문제는 스토리지 클래스(Standard, IA, Glacier, Intelligent-Tiering)의 특징만 확실히 잡으면 점수 밭입니다.

  • 자주 안 씀 + 꺼낼 때 돈 내도 됨 = Standard-IA
  • 몰라(예측 불가) + 꺼낼 때 돈 내기 싫어 = Intelligent-Tiering

정답: D (이그레스 전용 인터넷 게이트웨이를 생성하고 이를 서브넷 경로 테이블의 목적지로 만듭니다.)

이 문제는 "IPv6" 환경에서 "나가는 건 되지만, 들어오는 건 막아야 한다"는 보안 요건을 충족하는 전용 게이트웨이를 묻는 문제입니다.

💡 3초 컷 필승 공식: "IPv6 + 밖으로만 나감" = "Egress-Only IGW"

1. IPv4 vs IPv6의 차이 (가장 중요!)

  • IPv4: 사설 IP를 쓰기 때문에 인터넷에 나가려면 주소를 변환해 주는 NAT Gateway(A번)가 필요합니다.
  • IPv6: IPv6는 주소가 엄청나게 많아서 모든 인스턴스가 공인 IP(Public IP)를 가집니다. 그래서 주소 변환(NAT)이 필요 없습니다.
  • 문제점: 공인 IP라서 인터넷에서 누구나 내 서버로 접속(해킹) 시도를 할 수 있습니다. 이걸 막아야 합니다.

2. Egress-Only Internet Gateway의 역할

  • 정의: IPv6 전용 게이트웨이입니다.
  • 기능:
  • Outbound (나가는 것): 허용 (내 서버가 구글에 요청하는 건 OK)
  • Inbound (들어오는 것): 차단 (해커가 내 서버에 접속하는 건 NO)
  • 이름 그대로 "나가는 것(Egress) 전용"입니다. 문제의 보안 요구 사항과 완벽하게 일치합니다.

❌ 오답 분석

  • A. NAT 게이트웨이: 이건 IPv4를 위한 서비스입니다. IPv6 트래픽을 처리하는 표준 방법이 아닙니다.
  • B. 인터넷 게이트웨이 (IGW): 이건 "양방향" 문입니다. 나갈 수도 있지만, 밖에서 들어올 수도 있습니다. "외부 서비스는 연결을 시작할 수 없다"는 보안 정책을 위반합니다.
  • C. 가상 사설 게이트웨이 (VGW): 이건 VPN 연결용입니다. 인터넷 연결과는 상관없습니다.

📝 시험장 암기 공식

"IPv4" + "나가는 것만 허용" ➡️ NAT Gateway
"IPv6" + "나가는 것만 허용" ➡️ Egress-Only Internet Gateway

  • IPv4 짝꿍 = NAT Gateway
  • IPv6 짝꿍 = Egress-Only IGW

정답: C (Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. 이 엔드포인트를 VPC의 모든 경로 테이블과 연결합니다.)

이 문제의 핵심은 "S3"와 "비용 최소화" 두 단어에 있습니다.

💡 3초 컷 필승 공식: "S3랑 DynamoDB는 공짜 터널(Gateway)을 쓴다"

  1. ⭐VPC 엔드포인트의 종류 (이게 제일 중요!):
    AWS에서 VPC 내부에서 인터넷을 안 타고 AWS 서비스에 접속하는 방법(VPC Endpoint)은 딱 두 가지가 있습니다.
  • 게이트웨이 엔드포인트 (Gateway Endpoint):
    • 대상: 오직 S3와 DynamoDB 딱 2개만 지원합니다.
    • 비용: 무료 (Free)입니다. 데이터 처리 비용도 없습니다.
    • 방식: 경로 테이블(Route Table)을 수정해서 경로를 잡아줍니다.
  • 인터페이스 엔드포인트 (Interface Endpoint / PrivateLink):
    • 대상: 나머지 거의 모든 서비스 (EC2 API, Kinesis, SNS, ELB 등등).
    • 비용: 유료입니다. (시간당 요금 + 데이터 처리 용량당 요금).
    • 방식: ENI(랜카드)를 박아서 IP 주소로 통신합니다.

📝 시험장 암기 노트: VPC 엔드포인트 대결

질문: "S3"나 "DynamoDB"에 접속해야 한다.
조건: "인터넷 안 씀" + "비용 가장 저렴하게"
➡️ 무조건 Gateway Endpoint (게이트웨이 엔드포인트)
(나머지 서비스는 Interface Endpoint입니다.)

⭐ "S3/DynamoDB = 게이트웨이 = 공짜"

정답: A (새로운 메시지 테이블에 대해 Amazon DynamoDB Accelerator(DAX)를 구성합니다. DAX 엔드포인트를 사용하도록 코드를 업데이트합니다.)

이 문제는 "DynamoDB의 속도를 높여야 하는데, 코드는 거의 고치기 싫어!"라는 요구사항을 충족하는 전용 서비스를 찾는 문제입니다.

💡 3초 컷 필승 공식: "DynamoDB + 읽기 속도 향상 + 코드 변경 최소화" = "DAX"

❌ 오답 분석

  • B. 읽기 복제본 (Read Replica): DynamoDB에는 RDS처럼 엔드포인트를 따로 쓰는 "읽기 복제본" 개념이 없습니다(글로벌 테이블은 있지만 리전 간 복제용입니다). 또한 캐싱만큼의 속도 향상을 주지 못합니다.
  • C. RCU (읽기 용량) 2배: 이건 "처리량(Throughput, 얼마나 많이)"을 늘리는 거지, "지연 시간(Latency, 얼마나 빨리)"을 획기적으로 줄이는 방법은 아닙니다.

📝 시험장 암기 공식

"DynamoDB가 느리다 / 지연 시간을 줄여야 한다"
"애플리케이션 코드는 건드리기 싫다 / 호환되어야 한다"
➡️ 무조건 DAX (DynamoDB Accelerator)

정답: A (에지 위치에서 상태 파일을 캐시하기 위한 Amazon CloudFront 배포를 생성합니다.)

이 문제는 "정적 콘텐츠(Static Content)"와 "비용 절감"이라는 두 단어만 보고 CloudFront를 골라내는 문제입니다.

💡 핵심 분석: 왜 CloudFront가 정답일까요?

  1. 문제점:
  • 웹사이트 트래픽이 늘어나면 EC2가 바빠집니다(CPU 상승).
  • EC2를 더 늘리면(Auto Scaling) 비용이 비싸집니다.
  1. 해결책 (CloudFront):
  • CloudFront는 전 세계 곳곳(Edge Location)에 흩어져 있는 캐시 서버(CDN)입니다.
  • 이미지, CSS, HTML 같은 "정적 파일"을 사용자와 가장 가까운 캐시 서버에 미리 저장해둡니다.
  • 사용자가 접속하면 EC2까지 오지 않고 CloudFront 선에서 처리해 버립니다.
  • 결과: EC2는 할 일이 없어져서 푹 쉴 수 있습니다. (인스턴스 비용 감소 + 데이터 전송 비용 절감).

📝 시험장 암기 공식

"정적 콘텐츠(Static Content / Image / CSS)"
"속도 향상" 또는 "EC2 부하 감소/비용 절감"
➡️ 무조건 Amazon CloudFront

"정적 파일 = CDN(CloudFront)"

📝 시험장 암기 공식

"VPC가 많다" + "서로 다 연결해야 한다" + "관리하기 쉽게 해줘"
➡️ 무조건 AWS Transit Gateway

Peering은 1:1 연결만 가능

  • Windows 컨테이너나 SMB 프로토콜이 꼭 필요하다는 언급이 없으면, ECS에는 보통 무거운 FSx보다 가벼운 EFS를 씁니다.

📝 시험장 암기 공식

"ECS / Lambda / Fargate" + "공유 파일 스토리지" "각 AZ마다 마운트 타겟(Mount Target) 생성"
➡️ 무조건 Amazon EFS

  • 이 패턴은 "ECS에는 EFS"라는 공식으로 자주 출제

💡 3초 컷 필승 공식: "사람(User)과 그룹(Group)에는 무조건 '정책(Policy)'을 붙인다!"

  1. 그룹(Group) 생성: '개발팀', '인사팀' 그룹을 만듭니다.

  2. 정책(Policy) 생성: '개발 서버 접속 가능', '인사 DB 읽기 가능' 같은 권한 문서(Policy)를 만듭니다.

  3. 연결(Attach): 이 문서(Policy)를 그룹에 딱 붙입니다.

  4. 이제 신규 입사자를 그룹에 넣기만 하면 권한이 자동으로 생깁니다. 이게 AWS가 권장하는 "가장 안전하고 효율적인" 방법입니다.

정답 및 해설

핵심 원인: 리소스(Resource) 범위 지정 오류 (/* 누락)

이 문제는 "S3 버킷 자체(껍데기)" 권한과 "객체(알맹이)" 권한의 ARN 표기법 차이를 묻는 아주 디테일한 문제입니다. 이걸 구분 못 하면 실무에서도 정책 오류로 고생하게 됩니다.

💡 3초 컷 필승 분석: "누구를 건드리는가?"

정책 JSON을 보면 Resource가 "arn:aws:s3:::bucket-name"으로 딱 하나만 적혀 있습니다. 여기서 문제가 발생합니다.

  1. s3:ListBucket (버킷 내용물 목록 보기)
  • 대상: 버킷 그 자체 (컨테이너)
  • 필요한 ARN: arn:aws:s3:::bucket-name
  • 결과: 이 부분은 정상 작동합니다.
  1. s3:DeleteObject (객체 삭제하기)
  • 대상: 버킷 안에 들어있는 파일들(Objects)
  • 필요한 ARN: arn:aws:s3:::bucket-name/* (뒤에 /* 필수!)
  • 결과: 현재 정책은 버킷 껍데기에 대고 "삭제해!"라고 명령한 셈입니다. 객체를 가리키지 않았으므로 권한 거부(Access Denied)가 뜹니다.


정답: D (Resource에 /*가 포함된 것)

✅ 올바른 해결 방법

하나의 Statement에 억지로 묶으려다 보니 탈이 났습니다. 두 가지 방법으로 고쳐야 합니다.

방법 1: 리소스에 /* 추가 (가장 일반적)

"Resource": [
  "arn:aws:s3:::bucket-name",      // ListBucket용
  "arn:aws:s3:::bucket-name/*"     // DeleteObject용
]

방법 2: Statement 분리 (권장)

  • Statement 1: ListBucket 허용 -> Resource: bucket-name
  • Statement 2: DeleteObject 허용 -> Resource: bucket-name/*

📝 시험장 암기 공식: S3 ARN 구분

"버킷(통)을 건드린다" (ListBucket, GetBucketLocation)
➡️ bucket-name
"파일(내용물)을 건드린다" (PutObject, GetObject, DeleteObject)
➡️ bucket-name/* (슬래시 별표 필수!)

⭐코드 전체를 해석하려 하지 말고, Action이 Object로 끝나면 Resource 뒤에 /*가 있는지만 확인하세요.

profile
도은호
`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`
이전 포스트

AWS SAA 376~

다음 포스트

AWS SAA 해설 478~

0개의 댓글