[AWS] AWS Solution Architect Associate (SAA-C03) 핵심 정리

AWS SAA-C03 자격증을 준비하며 정리한 핵심 내용들을 공유합니다.
해당 자격증을 준비하시는 분들께 도움이 되길 바랍니다.

개념 공부 및 기출 문제를 공부하며 준비했습니다.
시험일: 2025.09 / 합격

🎯 시험을 관통하는 3가지 핵심 설계 원칙 (심화)

시험 문제의 대부분 시나리오는 다음 세 가지 목표를 어떻게 기술적으로 구현할 것인지 묻고 있습니다. 각 문제의 요구사항을 이 세 가지 원칙에 대입해 보면 좋을 것 같습니다.

1. 고가용성, 확장성, 내결함성 (High Availability, Scalability, Fault Tolerance)
   어떤 상황에서도 서비스가 중단되지 않고, 사용자 요청에 따라 유연하게 확장하며, 장애가 발생해도 살아남는 아키텍처를 구축하는 것이 SAA 시험의 가장 중요한 주제라고 생각됩니다.

• 고가용성 확보: 단일 장애 지점(Single Point of Failure)을 제거하는 것이 핵심입니다. 다중 가용 영역(Multi-AZ)에 리소스를 분산 배포하는 것은 가장 기본적인 전략입니다. 예를 들어, 단일 AZ에서 운영되던 EC2 인스턴스와 데이터베이스를 Multi-AZ로 확장하여 가용성을 높이는 문제가 자주 등장합니다. Amazon RDS 다중 AZ 기능은 장애 발생 시 자동으로 예비 데이터베이스로 장애 조치(Failover)하여 서비스 중단을 최소화합니다.

• 유연한 확장성: 예측 불가능한 트래픽 변화에 대응하기 위해 Auto Scaling 그룹은 필수입니다. 단순히 EC2 인스턴스 수를 늘리는 것뿐만 아니라, 어떤 지표를 기준으로 확장할지 결정하는 것이 중요합니다. CPU 사용률에 기반한 일반적인 확장 외에도, 처리해야 할 작업이 쌓이는 SQS 큐의 길이를 기준으로 확장하는 등 복합적인 시나리오를 이해해야 합니다.

2. 디커플링 아키텍처 (Decoupled Architectures)
   애플리케이션의 구성 요소를 느슨하게 연결(Loosely Coupled)하여 서로에게 미치는 영향을 최소화하는 설계 방식입니다. 이는 시스템의 안정성과 유연성을 극대화합니다.

• 비동기 처리와 버퍼링: 갑작스러운 트래픽 급증으로 인해 백엔드 시스템(예: 데이터베이스)이 과부하되는 것을 방지하기 위해 Amazon SQS(Simple Queue Service)를 버퍼로 사용하는 패턴이 매우 중요합니다. 주문 처리 시스템에서 주문이 폭주할 때, 요청을 일단 SQS 큐에 저장해두고 백엔드 EC2 인스턴스들이 자신의 처리 속도에 맞춰 순차적으로 작업을 가져가 처리함으로써, 요청 손실 없이 안정적으로 시스템을 운영할 수 있습니다.

• 팬아웃(Fan-out) 패턴: 하나의 이벤트가 발생했을 때 여러 시스템에 동시에 알림을 보내야 하는 경우 Amazon SNS(Simple Notification Service)를 사용합니다. 예를 들어, 주문이 완료되면 SNS 주제(Topic)에 메시지를 게시하고, 이 주제를 구독하는 여러 마이크로서비스(재고 관리, 배송 알림, 데이터 분석 등)가 동시에 해당 주문 정보를 받아 처리하는 아키텍처를 구성할 수 있습니다.

3. 비용 최적화 (Cost Optimization)
   AWS의 다양한 요금 모델과 서비스를 이해하고, 주어진 요구사항을 만족시키면서 비용을 최소화하는 능력은 솔루션즈 아키텍트의 핵심 역량 중 하나입니다.

• EC2 구매 옵션: 워크로드의 특성에 따라 최적의 구매 옵션을 선택해야 합니다.

• On-Demand: 예측 불가능한 단기 워크로드에 적합합니다.

• Reserved Instances / Savings Plans: 1년 또는 3년 약정을 통해 할인을 받는 방식으로, 24시간 계속 실행되는 프로덕션 워크로드에 적합합니다.

• Spot Instances: 중단되어도 괜찮은 배치 작업이나 테스트 환경 등 유연한 워크로드에 사용하면 최대 90%까지 비용을 절감할 수 있습니다.

• S3 스토리지 클래스: 데이터의 접근 빈도와 보관 기간에 따라 적절한 스토리지 클래스를 선택하고, 수명 주기 정책을 통해 자동으로 클래스를 변경하여 비용을 최적화해야 합니다.

• [중요]
  자주 접근하는 데이터는 S3 Standard,
  접근 빈도가 낮아지면 S3 Standard-IA,
  접근 패턴을 예측하기 어렵다면 S3 Intelligent-Tiering,
  장기 보관이 필요하면 S3 Glacier 계열로 이동시키는 시나리오가 단골로 출제되고 있습니다.

📚 주요 AWS 서비스별 핵심 정리

문제에 자주 등장하는 서비스들을 기능별로 묶어, 구체적인 문제 상황과 함께 깊이 있게 살펴보겠습니다.

📦 스토리지 (Storage)

1. Amazon S3 (Simple Storage Service)

• 데이터 전송 가속: 여러 대륙에서 수집된 대용량 데이터(500GB/일)를 단일 S3 버킷으로 최대한 빠르게 집계해야 하는 시나리오에서는 S3 Transfer Acceleration이 정답입니다. 이는 AWS의 엣지 로케이션을 활용하여 장거리 데이터 전송 속도를 극대화합니다.

• 데이터 보호 및 불변성: 중요한 감사 문서나 규제 대상 데이터를 실수로 삭제하거나 수정하는 것을 방지해야 할 때, 버전 관리와 MFA 삭제를 활성화하는 것이 기본입니다. 더 강력한 규제 준수가 필요하다면, 정해진 기간 동안 데이터 변경 및 삭제를 원천적으로 차단하는 S3 객체 잠금(Object Lock)을 사용해야 합니다.

• 하이브리드 스토리지 (S3 파일 게이트웨이): 온프레미스 파일 서버의 용량이 부족하지만, 자주 사용하는 파일은 로컬에서 빠르게 접근해야 하는 경우 S3 파일 게이트웨이를 사용합니다. 이는 온프레미스 환경에 SMB/NFS 인터페이스를 제공하면서 실제 데이터는 S3에 저장하여 스토리지 용량을 사실상 무제한으로 확장하고 비용을 절감하는 효과를 줍니다.

2. 파일 시스템 (EBS vs. EFS vs. FSx)

각 파일 시스템의 명확한 사용 사례를 구분하는 것이 중요합니다.

• EBS → EFS로의 전환: 처음에는 단일 EC2와 EBS로 구성된 웹 애플리케이션을 고가용성을 위해 여러 가용 영역의 여러 EC2 인스턴스로 확장하는 시나리오가 자주 등장합니다. 이 경우, 단일 EC2에만 연결 가능한 EBS로는 여러 인스턴스가 파일을 공유할 수 없으므로, 여러 Linux EC2 인스턴스에서 동시에 마운트 가능한 공유 파일 시스템인 Amazon EFS로 전환해야 합니다.

• Windows 공유 파일 시스템: 온프레미스에서 Windows 파일 서버를 사용하던 환경을 AWS로 마이그레이션할 때는 Amazon FSx for Windows File Server가 최적의 솔루션입니다. 기존 Windows 환경과 완벽하게 호환되며, SMB 프로토콜과 Active Directory 통합을 지원합니다.

3. 대용량 데이터 마이그레이션 (Snowball & DataSync)

데이터를 온프레미스에서 AWS로 옮기는 방법입니다.

• 오프라인 마이그레이션 (Snowball): 70TB의 대용량 비디오 파일을 마이그레이션해야 하지만 네트워크 대역폭 사용을 최소화해야 한다는 제약 조건이 있다면, 물리적 전송 장치인 AWS Snowball을 사용하는 것이 정답입니다.

• 온라인 마이그레이션 (DataSync): 전용선(Direct Connect)이 있고, 민감한 데이터를 안전하고 안정적으로 AWS로 전송해야 한다면 AWS DataSync를 사용합니다. DataSync는 전송 가속, 암호화, 데이터 무결성 검증 기능을 제공합니다.

⚙️ 컴퓨팅 (Compute)

1. EC2 & Auto Scaling

가장 중요한 컴퓨팅 환경입니다.

• 다양한 확장 정책: 단순히 CPU 사용률뿐만 아니라, SQS 큐에 쌓인 메시지 수를 기준으로 EC2 인스턴스를 확장(Scale-out)하는 아키텍처는 디커플링과 확장성을 동시에 만족시키는 대표적인 패턴입니다. 이는 작업 처리량에 맞춰 유연하게 컴퓨팅 자원을 조절할 수 있게 해줍니다.

• 비용 최적화 조합: 24시간 운영되는 프로덕션 환경에는 예약 인스턴스나 Savings Plans로 기본 용량을 확보하고, 예측 불가능한 피크 타임에 필요한 추가 용량은 스팟 인스턴스나 온디맨드 인스턴스로 충당하는 조합이 비용 효율적입니다.

2. 컨테이너 (ECS & Fargate)

운영 오버헤드 최소화가 키워드라면 Fargate를 떠올려야 합니다.

• 서버리스 컨테이너: "기반 인프라의 프로비저닝 및 관리에 대한 책임을 원하지 않는다"는 요구사항이 있다면, EC2 인스턴스 없이 컨테이너를 실행할 수 있는 AWS Fargate가 정답입니다. 이는 개발자가 인프라 관리가 아닌 애플리케이션 개발에만 집중할 수 있게 해줍니다.

3. 서버리스 (Lambda & API Gateway)

이벤트 기반의 애플리케이션 아키텍처 핵심입니다.

• 완전한 서버리스 아키텍처: "밀리초 단위의 지연 시간", "수백만 개의 요청 처리", "최소한의 운영 오버헤드"와 같은 요구사항을 만족시키는 e-커머스 웹사이트를 구축할 때, S3(정적 콘텐츠) + CloudFront(CDN) + API Gateway(API) + Lambda(백엔드 로직) + DynamoDB(데이터베이스) 조합은 좋은 솔루션입니다.

🌐 네트워킹 및 콘텐츠 전송 (Networking & Content Delivery)

1. VPC와 프라이빗 연결

보안과 성능을 위해 인터넷을 우회하는 방법을 반드시 알아야 합니다.

• VPC 엔드포인트: VPC 내의 EC2 인스턴스가 인터넷을 거치지 않고 S3 버킷이나 DynamoDB 테이블에 접근해야 한다는 보안 요구사항이 있다면, VPC 게이트웨이 엔드포인트가 정답입니다. 이는 AWS 네트워크 내에서 안전하고 빠른 비공개 통신을 가능하게 하며, 데이터 전송 비용도 절감할 수 있습니다.

2. 로드 밸런서 (ALB vs. NLB)

트래픽의 종류에 따라 적절한 로드 밸런서를 선택해야 합니다.

• Layer 7 vs. Layer 4: 일반적인 HTTP/HTTPS 웹 트래픽은 ALB를 사용합니다. 반면, 게임이나 VoIP처럼 TCP/UDP 기반의 고성능, 저지연이 중요한 트래픽에는 NLB를 사용해야 합니다. "NLB가 HTTP 오류를 감지하지 못한다"는 문제는 NLB가 Layer 4에서 작동하기 때문이며, 이 경우 Layer 7을 이해하는 ALB로 교체하는 것이 해결책입니다.

3. 글로벌 서비스 (CloudFront vs. Global Accelerator)

전 세계 사용자를 위한 성능 최적화입니다.

• 콘텐츠 캐싱 (CloudFront): 정적/동적 웹 콘텐츠(HTTP/S)를 전 세계 사용자에게 빠르게 전달해야 할 때, CDN 서비스인 Amazon CloudFront를 사용합니다. S3와 ALB를 모두 오리진으로 지정하여 정적 및 동적 콘텐츠를 함께 서비스할 수 있습니다.

• 네트워크 경로 최적화 (Global Accelerator): UDP를 사용하는 VoIP 서비스처럼 비-HTTP 트래픽에 대해 지연 시간이 가장 짧은 리전으로 사용자를 라우팅하고, 빠른 장애 조치가 필요할 때는 AWS Global Accelerator를 사용해야 합니다.

🗄️ 데이터베이스 (Databases)

1. 관계형 데이터베이스 (RDS & Aurora)

• 고가용성 (Multi-AZ): 프로덕션 데이터베이스의 안정성을 위해 다중 AZ 배포는 필수입니다. 한 가용 영역에 장애가 발생해도 서비스 중단 없이 자동으로 다른 AZ의 예비 데이터베이스로 전환됩니다.

• 읽기 부하 분산 (읽기 전용 복제본): 분석 쿼리나 보고 작업으로 인해 프로덕션 데이터베이스의 성능이 저하되는 경우, 읽기 전용 복제본을 생성하여 읽기 트래픽을 분산시켜야 합니다.

• 고성능 (Aurora): 기존 MySQL, PostgreSQL보다 더 높은 성능과 가용성이 필요하다면 Amazon Aurora가 해답입니다. Aurora는 스토리지 자체가 3개의 AZ에 걸쳐 6중 복제되어 내구성이 매우 높고, Aurora Auto Scaling을 통해 읽기 복제본을 자동으로 확장할 수 있습니다.

2. NoSQL (DynamoDB)

유연한 스키마와 초고속 성능이 필요할 때 사용됩니다.

• 성능 가속화 (DAX): DynamoDB의 응답 시간을 밀리초에서 마이크로초 단위로 단축해야 한다면, 완전 관리형 인메모리 캐시인 DAX (DynamoDB Accelerator)를 사용해야 합니다.

3. 인메모리 캐시 (ElastiCache)

반복적인 데이터베이스 읽기를 줄여 성능을 극대화합니다.

• 세션 관리 및 쿼리 캐싱: 여러 EC2 인스턴스에서 사용자 세션 데이터를 공유하거나, 반복적으로 수행되는 데이터베이스 쿼리 결과를 캐싱하여 DB 부하를 줄이고 응답 속도를 높일 때 Amazon ElastiCache를 사용합니다.

🔒 보안, 자격 증명 및 규정 준수 (Security, Identity & Compliance)

1. 자격 증명 관리

• IAM 역할 (IAM Role): EC2 인스턴스가 S3 버킷에 접근하는 것처럼, AWS 리소스가 다른 AWS 서비스에 접근할 때는 반드시 IAM 역할을 사용해야 합니다. 이는 액세스 키 같은 장기 자격 증명을 코드에 저장하지 않는 가장 안전한 방법입니다.

• Secrets Manager: 데이터베이스 자격 증명과 같이 민감한 정보를 애플리케이션 코드에서 분리하고, 자동으로 주기적인 교체(Rotation)까지 관리하고 싶다면 AWS Secrets Manager가 정답입니다.

2. 거버넌스 및 감사

• Organizations & SCP: 여러 AWS 계정을 중앙에서 관리하고, 특정 리전 사용 금지나 특정 EC2 인스턴스 타입 생성 금지 같은 보안 정책을 강제하고 싶을 때 AWS Organizations의 서비스 제어 정책(SCP)을 사용합니다.

• Config vs. CloudTrail: 이 두 서비스의 차이를 명확히 알아야 합니다.

• AWS Config: 리소스의 구성 변경 이력을 추적하고, "S3 버킷이 공개적으로 열려있다"와 같은 규정 준수 여부를 평가하는 데 사용됩니다.

• AWS CloudTrail: "어떤 사용자가 언제 어떤 API를 호출했는지"와 같은 계정 활동(API 호출)을 기록하고 감사하는 데 사용됩니다.

✨ 결론

SAA-C03 시험은 단순히 AWS 서비스의 기능을 묻는 시험이 아닙니다. 문제에서 제시된 비즈니스 요구사항과 기술적 제약사항을 정확히 파악하고, 위에서 정리한 핵심 원칙과 서비스들의 특징을 조합하여 가장 이상적인 아키텍처를 그려내는 능력을 평가하는 문제들로 출제되고 있습니다.

이 글이 여러분의 AWS SAA-C03 자격증 합격 및 학습에 작은 보탬이 되었으면 좋겠습니다.
모두 좋은 결과 있으시길 바랍니다!😊

오늘도 하고픈걸 향해 떠나는
zooy였습니다 :)