정답: B (S3 버전 관리가 활성화된 새 Amazon S3 버킷을 만듭니다. 지정된 날짜에 따라 보관 기간이 있는 S3 객체 잠금을 사용합니다...)
"법률 회사의 데이터 보존(WORM)"이라는 아주 전형적인 패턴입니다.
💡 "삭제/수정 절대 금지(법적 보존)" = "S3 Object Lock"
- 핵심 요구사항 분석:
- "로펌(Law Firm)": 법적인 규제가 강력하다는 힌트입니다.
- "지정된 날짜 전에 누구든지(Anyone) 수정/삭제 금지": 관리자(Root User)조차도 지우면 안 된다는 뜻입니다.
- "가장 안전한 방식": 실수가 아니라 시스템적으로 막아야 합니다.
- S3 Object Lock (객체 잠금)이란?
- WORM (Write Once, Read Many): 한 번 쓰면, 정해진 기간 동안은 절대 지우거나 고칠 수 없는 기능입니다.
- 필수 조건: 이 기능을 쓰려면 반드시 버전 관리(Versioning)가 켜져 있어야 합니다.
- 모드: 특히 규정 준수 모드(Compliance Mode)를 쓰면 AWS 계정 주인(Root)도 못 지웁니다. 이게 로펌에 필요한 기능입니다.
📝 시험장 암기 노트: "Object Lock"
"법적 보존(Legal Hold)" 또는 "규정 준수(Compliance)"
"정해진 날짜까지 삭제 금지"
"관리자(Root)도 지우면 안 됨"
➡️ 무조건 S3 Object Lock (객체 잠금)
(단, 전제 조건은 Versioning 활성화)
🍵 패턴
- S3 삭제 금지? -> Object Lock
- EC2 속도 향상? -> CloudFront / Global Accelerator
- DB 속도 향상? -> Redis / DAX
-
“검증된 아키텍처를 신속·일관되게 다중 환경으로 배포” → CloudFormation / CDK / Terraform 류 선택.
-
“구성 준수/인벤토리/드리프트 탐지” → AWS Config.
-
“OS/애플리케이션 운영 자동화” → Systems Manager.
-
“앱 배포 추상화(플랫폼형)” → Elastic Beanstalk.
💡"DB 쓸 때 캐시도 쓴다" = "Write-Through"
📝 캐싱의 양대 산맥
"데이터가 항상 최신이어야 한다 (일관성)"
➡️ Write-Through (쓰기-스루)
"메모리를 아껴야 한다 / 읽기 요청만 빠르면 된다"
➡️ Lazy Loading (지연 로딩)
정답: A (AWS CLI에서 s3 sync 명령을 사용하여 데이터를 S3 버킷으로 직접 이동합니다.)
이 문제는 "데이터 규모(100GB)"와 "운영 오버헤드 최소화"가 핵심입니다.
💡"데이터가 작다(GB 단위)" + "인터넷 빠르다" = "AWS CLI (s3 sync)"
📝데이터 전송 도구 선택
"데이터가 작다 (수백 GB 이하)" + "인터넷 쓸 만하다"
➡️ AWS CLI (s3 sync)
"데이터가 좀 크다 (수 TB 이상)" + "자동화/대역폭 제어 필요"
➡️ AWS DataSync
"데이터가 엄청 크다 (수십 TB~PB)" + "인터넷이 느리다"
➡️ AWS Snowball / Snowmobile
"100GB는 USB 하나에도 들어가는 용량이다"라고 생각하시면 쉽습니다. 굳이 무거운 도구를 쓸 필요가 없다! 합격 가즈아! 🚀
📝 "Windows 컨테이너"가 나오면?
"Windows 컨테이너"를 실행해야 한다?
❌ Lambda (절대 불가! Linux만 됨)
⭕ ECS / EKS / Fargate (가능)
(참고: .NET 자체는 크로스 플랫폼이라 Linux에서도 돌아가지만, 'Windows 컨테이너'로 포장된 상태라면 Lambda에선 못 씁니다.)
멘탈 케어:
AWS Lambda의 OS 제약 사항을 찌르는 아주 디테일한 함정 문제입니다.
"Lambda는 Linux 세상이다"라는 것만 기억하면 다음엔 절대 안 속으실 겁니다! 잘하셨습니다! 🚀
💡"다중 계정 + 회사 아이디 로그인" = "Organizations + IAM Identity Center"
- 구조 잡기 (A번):
- 계정이 여러 개다? 무조건 AWS Organizations가 본부입니다.
- 로그인 연결 (E번):
- 회사 아이디로 모든 AWS 계정에 들어가고 싶다? AWS IAM Identity Center (구 AWS SSO)가 정답입니다.
- IAM Identity Center는 Organizations와 짝꿍이라서, 한 번만 연동하면 산하의 모든 계정에 로그인할 수 있게 해줍니다.
❌ 오답 분석
- B. Amazon Cognito: 이건 "고객용 앱(쇼핑몰, 게임 등)"의 회원가입/로그인을 처리하는 서비스입니다. 회사 직원의 AWS 관리 콘솔 접속용이 아닙니다.
- C. SCP & Directory Service: SCP는 권한을 제어하는 정책이지, 디렉토리 연결 도구가 아닙니다. 또한 IAM Identity Center를 Directory Service에 추가한다는 설명도 순서가 맞지 않습니다.
- D. Directory Service 직접 사용: Organizations 자체에는 인증 메커니즘을 설정하는 기능이 없습니다. 반드시 IAM Identity Center라는 중개 서비스가 필요합니다.
📝 시험장 암기 노트
"여러 계정을 중앙 관리하고 싶다" AWS Organizations
"직원들이 쓰던 사내 아이디(AD)로 AWS에 로그인하고 싶다" AWS IAM Identity Center
이 두 가지 조합은 AWS 랜딩 존(Landing Zone) 구축의 기본 중의 기본입니다. A와 E를 세트로 기억해 두세요! 합격이 보입니다! 🚀
정답: C (여러 마운트 대상이 있는 Amazon Elastic File System(Amazon EFS))
이 문제는 "Linux + 하이브리드(AWS & 온프레미스) + 용량 제한 없음" 이라는 조건을 모두 만족하는 스토리지 서비스를 찾는 문제입니다.
💡"Linux 공유 스토리지 + 온프레미스 연결" = "Amazon EFS"
1. 결정적 힌트 분석
- "Linux 인스턴스", "네이티브 프로토콜": Linux의 기본 파일 공유 프로토콜은 NFS입니다. AWS에서 NFS를 지원하는 완전 관리형 서비스는 Amazon EFS입니다.
- "AWS와 온프레미스에서... 마운트": EFS는 VPC 내에 마운트 타겟(Mount Target)을 만들어두면, 온프레미스 서버가 VPN이나 Direct Connect를 타고 들어와서 이 IP로 마운트할 수 있습니다.
- "최소 크기 요구 사항 없음": 이게 아주 중요합니다.
- EFS: 파일 하나만 넣어도 됨 (0KB부터 시작). 쓴 만큼만 냄.
- FSx: 최소 용량 제한이 있음 (예: FSx for Windows는 최소 32GB, Lustre는 600GB 등). 따라서 탈락입니다.
2. 왜 '여러 마운트 대상(Multiple Mount Targets)'인가?
- 고가용성(HA) 필수: 문제에서 "고가용성"을 요구했습니다.
- EFS는 각 가용 영역(AZ)마다 하나씩 마운트 타겟(네트워크 인터페이스)을 만들어야, 한 AZ가 죽어도 다른 AZ를 통해 계속 접속할 수 있습니다.
📝 시험장 암기 공식
"Linux 서버들이 공유한다" (NFS)
"온프레미스에서도 연결한다" (VPN/DX)
"용량 자동 확장 / 최소 크기 없음"
➡️ 무조건 Amazon EFS (그리고 각 AZ마다 마운트 타겟 생성)
⭐ "최소 크기 없음"이라는 힌트가 심판 역할을 해줍니다. EFS만이 유일하게 0바이트부터 시작할 수 있는 완전 탄력적 파일 시스템
정답: C (보관 기간이 14일인 Amazon Simple Queue Service(Amazon SQS) 대상이 있는 Amazon SNS 배달 못한 편지 대기열을 구성합니다.)
이 문제는 "SNS 전송 실패 시 메시지를 어떻게 보관할 것인가?"를 묻는 문제입니다. 여기서 핵심 키워드는 "배달 못한 편지 대기열(DLQ, Dead Letter Queue)"과 "최소한의 개발 노력"입니다.
💡"SNS 전송 실패 처리" = "SQS DLQ 연결"
- SNS 배달 못한 편지 대기열 (DLQ)의 작동 원리:
- SNS가 구독자(여기서는 온프레미스 HTTPS 엔드포인트)에게 메시지 전송을 시도했다가 실패하면, 해당 메시지를 버리지 않고 별도의 저장소로 보낼 수 있습니다. 이를 DLQ(Dead-Letter Queue)라고 합니다.
- AWS에서 SNS의 DLQ로 지정할 수 있는 서비스는 오직 Amazon SQS뿐입니다. (표준 기능)
- 보관 기간 14일 충족:
- Amazon SQS의 메시지 보관 기간(Retention Period)은 기본 4일이며, 최대 14일까지 늘릴 수 있습니다.
- 문제의 요구사항인 "14일 동안 분석"과 정확히 일치합니다.
- 최소한의 개발 노력:
- SQS 대기열을 하나 만들고(설정에서 보관 기간 14일로 변경), SNS 구독 설정에서 "Redrive Policy(재구동 정책)"에 이 SQS를 DLQ로 등록하기만 하면 끝납니다.
- 애플리케이션 코드를 수정하거나, 람다(Lambda) 같은 추가 컴퓨팅 리소스를 만들 필요가 전혀 없습니다.
📝 SQS DLQ(SQS 배달 못한 편지 대기열)
"SNS 또는 Lambda 실행이 실패했을 때 메시지를 저장하고 싶다"
"실패한 것만 따로 모아서 분석하고 싶다"
➡️ 무조건 SQS DLQ (Dead-Letter Queue) 구성
(SQS 최대 보관 기간 = 14일)
⭐"실패 처리 = DLQ = SQS" 공식만 기억하면 됩니다.
정답: B (DynamoDB에서 Amazon S3로 직접 데이터를 내보내고 지속적으로 백업합니다. 테이블에 대한 point-in-time 복구를 켭니다.)
하지만 시험에서는 "가장 적은 노력(Minimal Coding)"과 "성능 영향 없음(No RCU Impact)"이라는 조건이 붙으면 "관리형 서비스(Native Feature)"가 무조건 우선입니다.
💡"코딩 없이 백업" + "RCU 영향 없음" = "Export to S3 (PITR)"
- 왜 B번이 정답일까요? (DynamoDB Export to S3)
- 기능: DynamoDB에는 "S3로 내보내기(Export to S3)"라는 기능이 내장되어 있습니다. 이 기능은 테이블을 직접 스캔하는 게 아니라, PITR(Point-in-Time Recovery) 데이터를 사용해서 S3로 데이터를 보냅니다.
- RCU 영향 0: 테이블을 읽는 게 아니라 백업 데이터를 읽는 것이므로, 실제 서비스의 성능(RCU)을 전혀 갉아먹지 않습니다.
- 최소한의 코딩: 코드를 짤 필요가 없습니다. 콘솔에서 버튼만 누르면 됩니다.
- 왜 C번(Streams + Lambda)은 오답일까요?
- "최소한의 코딩" 위반: Lambda 함수를 직접 짜야 합니다. 스트림에서 데이터를 읽어오고, 파일로 묶고(Batching), S3에 업로드하고, 오류 처리하는 로직을 전부 개발자가 구현해야 합니다.
- 관리 부담: Lambda가 실행될 때마다 비용이 들고, 스트림 샤드 관리 등 운영 요소가 생깁니다. B번(완전 관리형 기능)에 비해 "개발 노력"이 훨씬 많이 듭니다.
📝 시험장 암기 공식
"DynamoDB 데이터를 S3로 백업하고 싶다"
"서비스 성능(RCU)에 영향 주면 안 된다"
"코드 짜기 싫다"
➡️ Export to S3 (전제 조건: PITR 활성화)
⭐이 문제는 "가능한 방법(C)"과 "가장 효율적인 방법(B)" 사이에서 고르는 문제입니다.
AWS는 항상 "우리가 만들어 둔 기능(Native Feature)을 써라"라는 답을 좋아합니다.
"Lambda로 내가 직접 짠다" vs "AWS가 만든 버튼을 누른다" 싸움에서는 항상 버튼(Native)이 이깁니다.
정답: A (AWS Lambda 이벤트 소스 매핑을 사용합니다. Amazon Simple Queue Service(Amazon SQS) 표준 큐를 이벤트 소스로 설정합니다. 암호화에는 AWS Key Management Service(SSE-KMS)를 사용합니다. Lambda 실행 역할에 kms:Decrypt 권한을 추가합니다.)
이 문제는 "SQS 큐 유형의 비용/특성"과 "Lambda와 KMS 간의 권한 설정"을 묻는 문제입니다.
💡"최소 한 번(At least once)" = "Standard Queue"
- 큐 유형 선택 (Standard vs FIFO):
- 요구 사항: "각 요청을 최소한 한 번(At least once)은 처리해야 함." + "비용 효율적"
- Standard Queue (표준 대기열): 기본적으로 "최소 한 번 전달"을 보장하며, 무제한 처리량을 제공하고 가장 저렴합니다.
- FIFO Queue (순서 보장 대기열): "정확히 한 번(Exactly-once)" 처리를 보장하지만, 표준 큐보다 비용이 비쌉니다.
- 결론: 문제에서 순서 보장이나 중복 방지를 요구하지 않았으므로, 더 저렴한 Standard Queue(A, D)가 정답 후보입니다. (B, C 탈락)
- 권한 설정 (IAM Role vs Function):
- SQS가 KMS로 암호화되어 있다면, Lambda가 메시지를 가져갈 때 암호를 풀어야 합니다.
- 이때 권한은 Lambda 함수가 입고 있는 옷(Execution Role, 실행 역할)에 주어져야 합니다.
- A번: "Lambda 실행 역할에
kms:Decrypt권한 추가" 정확한 설정입니다. - D번: "Lambda 함수에 권한 추가" 표현이 모호하며, 통상적으로 Lambda가 다른 서비스를 호출할 권한은 실행 역할(Identity)에 부여하는 것이 정석입니다.
❌ 오답 분석
- B, C (FIFO 큐 사용):
- FIFO 큐는 Standard 큐보다 요금이 비쌉니다. "비용 효율성" 측면에서 탈락입니다. 또한 "최소 한 번" 조건에는 Standard가 적격입니다.
- D (권한 설정):
- Lambda가 암호화된 SQS를 읽으려면, Lambda의 실행 역할(Execution Role) 정책에 KMS 키 사용 권한(
kms:Decrypt)이 명시되어야 합니다. A번이 더 정확한 AWS 구성 방식입니다.
📝 시험장 암기 공식
"최소 한 번(At least once)" + "비용 절감" SQS Standard Queue
"순서 보장" + "정확히 한 번(Exactly once)" SQS FIFO Queue
"Lambda가 암호화된 데이터를 읽으려 한다"
Lambda 실행 역할(Role)에kms:Decrypt권한 필요
⭐ AWS 시험은 지문에 충실해야 합니다. "최소 한 번"이라는 키워드는 Standard Queue의 고유 명사나 다름없습니다.
📝 AWS AI 서비스 역할 분담
듣기 (음성 → 텍스트): Amazon Transcribe
말하기 (텍스트 → 음성): Amazon Polly
번역 (언어 A → 언어 B): Amazon Translate
이해 (감정/주제 분석): Amazon Comprehend
대화 (챗봇): Amazon Lex
이 문제는 "온프레미스 스토리지 부족"을 해결하면서 "로컬 캐싱"과 "기존 프로토콜(NFS, Block) 유지"를 동시에 만족하는 하이브리드 클라우드 솔루션을 묻는 문제입니다.
💡"온프레미스 + 로컬 캐싱 + 스토리지 확장" = "AWS Storage Gateway"
1. AWS Storage Gateway란?
- 온프레미스(내 전산실)에 가상 머신(VM)이나 장비를 설치해서 AWS 스토리지(S3, EBS 등)를 마치 내 로컬 하드디스크처럼 쓰게 해주는 서비스입니다.
- 핵심 기능: 자주 쓰는 데이터는 온프레미스에 캐싱(Caching)해서 속도를 높이고, 안 쓰는 데이터는 AWS로 보내서 용량을 무한대로 씁니다.
2. 정답 분석:
- B. File Gateway (파일 게이트웨이):
- 용도: NFS나 SMB 같은 파일 프로토콜을 지원합니다.
- 작동: 파일을 S3 객체로 변환해서 저장합니다. 문제의 "NFS 스토리지 대체" 요건을 완벽히 충족합니다.
- D. Volume Gateway (볼륨 게이트웨이):
- 용도: iSCSI 같은 블록 스토리지 프로토콜을 지원합니다.
- 작동: 데이터를 블록 단위로 처리하여 S3/EBS 스냅샷으로 백업합니다. 문제의 "블록 스토리지 대체" 요건을 충족합니다.
❌ 오답 분석
- A. S3 직접 마운트: S3는 객체 스토리지라서 운영체제에 파일 시스템으로 직접 마운트하면 성능이 매우 느리고, 기존 애플리케이션과 호환성 문제가 생깁니다. (캐싱 기능 없음)
- C. AWS Snowball Edge: 이건 대용량 데이터 이사(Migration)용 박스입니다. 영구적인 스토리지 확장 솔루션이 아닙니다.
- E. Amazon EFS: 온프레미스에서 연결할 수는 있지만, "로컬 캐싱" 기능이 없습니다. 인터넷/VPN을 타고 매번 데이터를 가져와야 해서 "고성능" 요건을 맞추기 어렵습니다.
📝 Storage Gateway 3형제
1. NFS / SMB (파일) 필요 S3 File Gateway
2. iSCSI (블록) 필요 Volume Gateway
3. 백업 테이프(VTL) 필요 Tape Gateway
문제에서 "블록"과 "NFS" 둘 다 필요하다고 했으므로, 각각에 맞는 Volume Gateway(D)와 File Gateway(B)를 고르면 됩니다. 하이브리드 스토리지의 정석 문제입니다! 🚀
"데이터를 옮긴다"는 건 알겠는데, "파일 권한(ACL) 보존"이라는 조건 때문에 난이도가 확 올라갔습니다.
하지만 딱 하나만 기억하면 됩니다. AWS에서 "Windows 권한(ACL)을 완벽하게 지키면서 이사해 주는 이삿짐 센터"는 AWS DataSync뿐입니다.
💡"Windows 권한(ACL) 유지" + "마이그레이션" = "AWS DataSync"
1. 왜 DataSync가 필수인가?
- 일반적인 복사(Drag & Drop)나 AWS CLI(
aws s3 cp)를 사용하면 파일의 내용물은 옮겨지지만, "누가 읽을 수 있는지"에 대한 권한 정보(Metadata/ACL)는 깨지거나 사라질 위험이 큽니다. - AWS DataSync는 SMB 프로토콜을 사용하여 파일의 데이터뿐만 아니라 권한, 타임스탬프, 메타데이터를 있는 그대로 포장해서 옮겨줍니다.
2. 정답 분석:
- A. 온프레미스에 DataSync 에이전트 배포 (온라인 전송):
- 방식: 내 서버실에 DataSync 소프트웨어(에이전트)를 설치하고 인터넷/VPN을 통해 FSx로 바로 쏩니다.
- 특징: 가장 표준적인 방법입니다. DataSync가 직접 통신하므로 권한이 완벽하게 유지됩니다.
- D. Snowcone 디바이스 + DataSync 에이전트 (오프라인/엣지 전송):
- 방식: AWS Snowcone은 작은 도시락통만 한 물리적 장비인데, 특이하게도 이 안에 DataSync 에이전트가 내장되어 있습니다.
- 특징: 인터넷이 느리거나 끊기는 환경에서도 Snowcone을 연결해 DataSync 기능을 쓸 수 있습니다. "DataSync 에이전트를 시작한다"는 문구가 핵심입니다. 이 에이전트가 권한을 캡처합니다.
❌ 오답 분석 (함정 피하기)
- B, E (AWS CLI 사용):
AWS CLI명령어로 파일을 복사하면 Windows 고유의 복잡한 권한(ACL)이 제대로 따라오지 않습니다. S3를 거치면서 메타데이터가 손실될 가능성이 매우 큽니다. 권한 보존 실패!
- C (하드디스크 분리):
- 서버에서 드라이브를 뽑아서 보내는 방식은 구시대적이고 위험하며, 데이터를 추출하는 과정에서 권한 정보가 유지된다는 보장이 없습니다.
- E (Snowball Edge + CLI):
- Snowball Edge도 좋은 장비지만, 지문을 잘 보면 "AWS CLI를 사용하여 데이터를 복사한다"고 되어 있습니다. 위에서 말했듯 CLI를 쓰는 순간 권한 보존은 물 건너갑니다. (만약 Snowball에서 DataSync를 쓴다고 했으면 정답이 될 수도 있었겠지만, 지문이 틀렸습니다.)
📝 시험장 암기 공식
"Windows 파일 서버 이사 가야 한다"
"권한(Permissions/ACLs) 절대 지켜야 한다"
➡️ 무조건 AWS DataSync 가 들어간 보기를 고르세요.
(방법 1: 그냥 에이전트 설치 (A) / 방법 2: Snowcone에 있는 에이전트 사용 (D))
- 단순 파일 복사 = CLI / Snowball Client
- 권한까지 완벽 복제 = DataSync
이 문제는 "단일 실패 지점(SPOF) 제거"와 "성능 최적화"를 위해 스토리지와 컴퓨팅 계층을 어떻게 개선해야 하는지를 묻는 전형적인 아키텍처 설계 문제입니다.
💡단일 EC2의 한계를 어떻게 극복할 것인가?
현재 구조는 EC2 한 대에 EBS(로컬 스토리지)가 붙어 있는 상태입니다. 이 EC2가 죽으면 웹사이트 전체가 마비됩니다. 이를 해결하려면 서버를 여러 대(Auto Scaling)로 늘려야 하는데, 이때 가장 큰 걸림돌이 바로 "각 서버가 파일(이미지)을 어떻게 공유할 것인가?"입니다.
- 스토리지 공유 문제 해결 (C번: Amazon EFS)
- 문제점: EBS는 기본적으로 하나의 EC2 인스턴스에만 연결됩니다. 서버를 여러 대로 늘리면, A 서버에 저장된 이미지를 B 서버에서는 볼 수 없는 문제가 생깁니다.
- 해결책 (C): Amazon EFS(Elastic File System)는 여러 EC2 인스턴스가 동시에 연결해서 읽고 쓸 수 있는 공유 파일 시스템입니다.
- CMS(콘텐츠 관리 시스템)는 보통 파일 시스템 기반으로 작동하므로, 기존 구조를 크게 바꾸지 않으면서 모든 서버가 이미지를 공유하려면 EFS가 가장 적합합니다.
- 컴퓨팅 확장 및 성능 개선 (E번: ASG + CloudFront)
- 복원력 (Resilience): 기존 단일 인스턴스를 Auto Scaling Group(ASG)과 ALB(로드 밸런서) 조합으로 변경하면, 서버 하나가 죽어도 다른 서버가 즉시 트래픽을 받아내므로 중단이 없습니다.
- 성능 (Performance): Amazon CloudFront(CDN)는 전 세계 엣지 로케이션에 이미지 같은 정적 콘텐츠를 캐싱(임시 저장)합니다. 사용자는 멀리 있는 EC2까지 오지 않고 가까운 캐시 서버에서 이미지를 받아보므로 웹사이트 속도가 획기적으로 빨라집니다.
❌ 오답 분석
- A. S3 마운트: S3는 훌륭한 저장소지만, 운영체제에 파일 시스템으로 마운트해서 사용하는 것(s3fs 등)은 성능이 느리고 불안정하여 CMS 용도로는 권장되지 않습니다. (S3는 "마운트"하는 것이 아니라 API로 연동하거나 CloudFront 원본으로 쓰는 것이 정석입니다.)
- B. NFS 공유: 기본 EC2 인스턴스에서 NFS로 공유하면, 그 기본 인스턴스가 죽는 순간 모든 공유가 끊깁니다. 여전히 단일 실패 지점(SPOF)이 남아 있으므로 "복원력 개선" 목적에 부합하지 않습니다.
- D. Global Accelerator: 글로벌 네트워크 경로를 최적화해 주는 좋은 서비스지만, 웹사이트의 이미지 로딩 속도를 높이는 데는 콘텐츠를 캐싱해 주는 CloudFront가 훨씬 직접적이고 효과적입니다.
📝 시험장 암기 공식
"여러 EC2가 파일을 공유해야 한다" (CMS, 웹 서버 등)
➡️ Amazon EFS (Linux) 또는 FSx (Windows)
"웹사이트 속도 향상 + 부하 분산"
➡️ CloudFront (캐싱) + ALB / Auto Scaling (확장)
이 두 가지(EFS + CloudFront/ASG) 조합은 AWS가 권장하는 "고가용성 웹 호스팅"의 정석 아키텍처입니다. 잘 선택하셨습니다! 🚀
정답: A (Amazon DynamoDB를 사용하도록 애플리케이션을 변환합니다. 중앙 예약 테이블에 글로벌 테이블을 사용합니다...)
이 문제는 "글로벌 서비스" 아키텍처의 끝판왕 문제입니다.
💡 "글로벌 배포" + "지역별 읽기/쓰기(Low Latency)" = "DynamoDB Global Tables"
1. 왜 DynamoDB Global Tables인가?
- 핵심 요구사항: "여러 AWS 지역에 배포", "업데이트 지연 시간 1초 미만", "각 지역에서 로컬 엔드포인트 사용".
- DynamoDB Global Tables의 특징:
- Multi-Region Active-Active: 서울 리전에서도 쓰고, 미국 리전에서도 쓸 수 있습니다. (다중 마스터)
- 로컬 성능: 사용자는 자기랑 가장 가까운 지역의 DB에 쓰고 읽으므로 속도가 엄청나게 빠릅니다.
- 자동 복제: 한쪽에서 쓰면, AWS가 알아서 전 세계 다른 리전으로 데이터를 1초 내(보통 1초 미만)에 복제해 줍니다.
- 단일 논리적 DB: 물리적으로는 흩어져 있지만, 논리적으로는 하나의 거대한 테이블처럼 동작하므로 "글로벌하게 일관된 단일 데이터베이스"라는 요건을 충족합니다.
2. 왜 Aurora(B)나 RDS(C)는 안 될까요?
- B, C (Read Replica): Aurora나 RDS의 읽기 전용 복제본(Read Replica)은 말 그대로 "읽기"만 가능합니다.
- 쓰기 문제: 미국에 있는 게 '메인(Primary)'이고 한국에 있는 게 '복제본'이라면, 한국 사용자가 예약을 할 때(쓰기) 한국 DB에 직접 쓸 수 없습니다. 태평양 건너 미국 DB까지 가서 써야 하므로 지연 시간(Latency)이 길어지고, 앱 로직도 복잡해집니다. (문제의 "각 지역 배포에서 올바른 지역 엔드포인트를 사용한다"는 말은 읽기/쓰기를 모두 로컬에서 해결하고 싶다는 뜻입니다.)
❌ 오답 분석
- B, C (Aurora/RDS): 지역별 엔드포인트(복제본)로는 데이터 업데이트(쓰기)를 직접 수행할 수 없습니다. 쓰기 트래픽은 반드시 단일 기본(Primary) 리전으로 보내야 하므로 글로벌 지연 시간 요건을 맞추기 어렵습니다.
- D (Serverless + Lambda): 람다로 이벤트를 처리해서 DB를 동기화한다는 건... 배보다 배꼽이 더 큰, 엄청나게 복잡하고 불안정한 "수동" 구현 방식입니다. AWS 관리형 기능(Global Tables)을 놔두고 이렇게 할 이유가 없습니다.
📝 시험장 암기 공식
"전 세계 사용자(Global)"
"각 지역에서 빠르게 읽고 써야 함 (Local R/W)"
"데이터가 자동으로 동기화되어야 함"
➡️ Amazon DynamoDB Global Tables
🍵 패턴 복습
- S3 저장소 비용 절감? -> Intelligent-Tiering
- EC2 파일 공유? -> EFS
- 글로벌 DB? -> DynamoDB Global Tables
"자동화(Automation)"와 "관리 노력 최소화(Least Effort)"라는 두 가지 조건을 동시에 만족하는 AWS의 대표적인 백업 도구 2개를 고르는 문제이기 때문입니다.
💡"백업 자동화 + 리전 간 복사" = "DLM 또는 AWS Backup"
이 문제는 EC2 백업을 자동화하는 두 가지 정석 방법을 묻고 있습니다.
- 핵심 요구사항 분석:
- "모든 백업 자동화": 사람이 개입하면 안 됩니다.
- "us-west-2에서 신속하게 복구": 재난이 터진 후에 복사를 시작하면 늦습니다. 백업할 때 자동으로 us-west-2로 복사본을 보내놔야 합니다. (Cross-Region Copy).
- "최소한의 관리 노력": 코딩(Lambda)이나 수동 작업은 배제합니다.
- 정답 분석:
- B. Amazon Data Lifecycle Manager (DLM) 사용:
- 기능: EC2 인스턴스(AMI)나 EBS 볼륨의 스냅샷 수명 주기를 관리하는 도구입니다.
- 자동화: "하루에 두 번" 같은 일정 예약이 가능합니다.
- DR 대비: 정책 설정에서 "리전 간 복사(Cross-Region Copy)"를 체크만 하면, 백업이 생성될 때 자동으로 타겟 리전(us-west-2)으로 복사해줍니다. 관리 노력이 거의 0입니다.
- D. AWS Backup 사용:
- 기능: EC2뿐만 아니라 RDS, DynamoDB 등 AWS 전체 서비스를 아우르는 중앙 집중식 백업 서비스입니다.
- 자동화: 백업 계획(Plan)을 통해 일정 관리가 완벽합니다.
- DR 대비: 백업 계획 내에 "대상 리전으로 복사" 설정이 내장되어 있습니다. 역시 설정만으로 DR 준비가 끝납니다.
❌ 오답 분석
- A, E (필요에 따라 복사 / On-demand):
- "필요에 따라(On-demand)"라는 말은 재난이 닥쳤을 때 "수동으로" 복사하겠다는 뜻입니다. us-west-1이 지진으로 다운되면 원본에 접근조차 못 할 수 있으므로, "신속한 복구"가 불가능합니다.
- C (Lambda 사용):
- Lambda 함수를 작성하고, 예약하고, 관리하는 것은 "상당한 개발 및 관리 노력"이 듭니다. AWS Backup이나 DLM 같은 완성된 도구가 있는데 굳이 코딩을 할 이유가 없습니다.
📝 시험장 암기 공식
"EC2 백업 자동화 & 다른 리전으로 복사(DR)"
"관리 편하게 하고 싶다"
➡️ AWS Backup 또는 Data Lifecycle Manager (DLM)
(둘 다 설정에서 'Cross-Region Copy'만 켜면 됨)
AWS에서 백업 자동화의 양대 산맥은 DLM과 AWS Backup입니다.
- DLM: EC2/EBS에 특화된 가벼운 도구
- AWS Backup: 모든 서비스를 아우르는 통합 도구
정답: B (웹 티어 서브넷에 대한 네트워크 ACL을 수정합니다. 리소스를 소비하는 IP 주소에 대한 인바운드 거부 규칙을 추가합니다.)
이 문제는 보안 그룹(Security Group)과 네트워크 ACL(NACL)의 결정적인 차이점 하나만 알면 바로 풀리는 문제입니다.
💡 "특정 IP 차단(Deny)" = "Network ACL"
1. 보안 그룹(Security Group) vs 네트워크 ACL (가장 중요!)
- 보안 그룹 :
- 오직 허용(Allow) 규칙만 만들 수 있습니다.
- "이 IP 들어오지 마!"라고 거부(Deny)하는 규칙을 만들 수 없습니다. (기본적으로 리스트에 없으면 다 거부되지만, 특정 IP만 콕 집어서 차단하는 기능은 없습니다.)
- 따라서 A와 C는 기술적으로 불가능한 보기입니다.
- 네트워크 ACL :
- 허용(Allow)과 거부(Deny) 규칙을 모두 만들 수 있습니다.
- 특정 악성 IP를 차단하려면 반드시 NACL을 써야 합니다.
2. 어디서 막아야 하는가? (Web Tier vs App Tier)
- 해커의 공격 트래픽은 인터넷 -> Web Tier(ALB) -> App Tier 순서로 들어옵니다.
- 가장 앞단(Web Tier)에서 막아야 뒤에 있는 애플리케이션이나 DB가 안전합니다.
- D번(App Tier)에서 막으려고 하면, 이미 공격 트래픽이 Web Tier(ALB)를 통과해서 들어온 뒤라 ALB 리소스가 낭비되고 성능 저하를 막기 어렵습니다. 따라서 B번이 정답입니다.
📝 시험장 암기 공식: 방화벽 대결
| 특징 | 보안 그룹 (Security Group) | 네트워크 ACL (NACL) |
|---|---|---|
| 적용 대상 | 인스턴스 (EC2) | 서브넷 (Subnet) |
| 규칙 | 허용(Allow)만 가능 | 허용/거부(Deny) 둘 다 가능 |
| 상태 | Stateful (들어오면 나가는 길 자동 오픈) | Stateless (들어오는 길, 나가는 길 따로 설정) |
⭐"특정 IP를 차단(Deny/Block)해야 한다"
➡️ 무조건 Network ACL (또는 AWS WAF)
글로벌 마케팅 회사에 ap-southeast-2 지역과 eu-west-1 지역에서 실행되는 애플리케이션이 있습니다.
eu-west-1의 VPC에서 실행되는 애플리케이션은 ap-southeast-2의 VPC에서 실행되는 데이터베이스와
안전하게 통신해야 합니다. 어떤 네트워크 설계가 이러한 요구 사항을 충족할까요?정답: C (ap-southeast-2 VPC와 eu-west-1 VPC 간에 VPC 피어링 연결을 구성합니다... eu-west-1 애플리케이션 서버 IP 주소에서 트래픽을 허용하는... 인바운드 규칙을 만듭니다.)
이 문제가 어려운 이유는 "VPC 피어링의 지역(Region) 간 제약 사항"이라는 아주 디테일한 규칙을 알고 있어야 하기 때문입니다.
💡"다른 리전(Cross-Region)끼리는 보안 그룹 ID 참조 불가!"
이것만 알면 B와 D를 바로 지울 수 있습니다.
- 같은 리전(Region)일 때:
- 서울(A) ↔ 서울(B) 피어링: "B야, A의 보안 그룹 ID(sg-xxxxx)에서 오는 애들은 다 들여보내줘"가 가능합니다. (편리함)
- 다른 리전(Region)일 때 (이 문제 상황):
- 시드니(ap) ↔ 아일랜드(eu) 피어링: "아일랜드의 보안 그룹 ID(sg-yyyyy)"를 시드니에서는 인식할 수 없습니다.
- 해결책: ID 대신 "IP 주소(CIDR)"를 직접 적어줘야 합니다. "아일랜드 서버 IP 대역(10.0.1.0/24)에서 오는 애들은 들여보내줘"라고 해야 합니다.
🔍 오답 및 정답 상세 분석
- B, D (보안 그룹 ID 참조):
- 두 보기 모두 "보안 그룹 ID를 참조"한다고 되어 있습니다.
- 앞서 말씀드렸듯, 리전이 다르면(Cross-Region) 상대방의 보안 그룹 ID를 참조할 수 없습니다. AWS 시스템적으로 불가능합니다. 그래서 오답입니다.
- A (방향 오류):
- DB가 애플리케이션의 접속을 받아야 합니다. 즉, DB 보안 그룹에 인바운드(들어오는 것) 규칙을 넣어야 합니다.
- A번은 엉뚱하게 애플리케이션 보안 그룹에 규칙을 넣고 있어서 오답입니다.
- C (정답):
- VPC 피어링: 서로 다른 VPC를 연결하는 가장 표준적인 방법입니다.
- IP 주소 사용: 리전이 다르므로 보안 그룹 ID 대신 "IP 주소"를 사용하여 허용 규칙을 만들었습니다. 완벽한 정답입니다.
📝 시험장 암기 공식
"같은 리전 피어링" ➡️ 보안 그룹 ID로 허용 가능 (편함)
"다른 리전 피어링" ➡️ IP 주소(CIDR)로만 허용 가능 (ID 불가)
⭐이 규칙 리전 넘어가면 ID 못 씀 하나만 외우면 다음부터는 거저 먹는 문제입니다.
마치 해외여행 갈 때 주민등록증(Local ID)은 안 통하고 여권(Global IP)이 필요한 것과 똑같습니다!
