[SAA-C03] 문제 유형 161-170 정리

Q161)

EC2는 프라이빗 서브넷

DynamoDB 접근 필요

트래픽이 AWS 네트워크를 벗어나면 안 됨

가장 안전한 방법

 

DynamoDB

// Key-Value NoSQL 데이터베이스

//퍼블릭 AWS 서비스( VPC 안에 존재 X)

//기본적으로 인터넷 경로 사용

 

-> VPC Endpoint를 사용하면
인터넷을 거치지 않고
AWS 내부 네트워크로 접근 가능

 

 

#시험 포인트

프라이빗 서브넷 + AWS 서비스 안전 접근
=  VPC Endpoint

---

Q162)

DynamoDB 사용 중
읽기 집약적 (read-heavy)
지연 발생
운영 인력 부족
애플리케이션 재구성 최소

// 읽기 많음, 지연발생, 코드변경 최소, 운영 오버헤드 x
-> DynamoDB Accelerator (DAX)

DynamoDB Accelerator (DAX)
-> DynamoDB 전용 인메모리 캐시
완전 관리형
읽기 성능 밀리초 → 마이크로초 수준
기존 DynamoDB API와 호환
코드 변경 최소 (endpoint 변경 정도)

// DynamoDB 전용 캐시 = DAX


# 시험포인트
DynamoDB 읽기 지연 + 코드 변경 최소
= DAX

---

Q163)

현재:
단일 리전, EC2 인스턴스, RDS DB 인스턴스

요구사항:
다른 리전에 백업, 최소 운영 오버헤드

// Cross-Region Backup, 최소 운영

여러 리소스(EC2 + RDS)를
한 번에 중앙에서 자동으로
다른 리전으로 복사
-> AWS Backup

// AWS Backup
EC2(EBS) 지원, RDS 지원
Cross-Region Copy 지원
중앙 정책 기반 관리
자동화 가능, 최소 운영


#시험 포인트
EC2 + RDS + Cross-Region + 최소 운영
→ AWS Backup

---

Q164)

RDS 사용자 이름/암호 안전 저장
Systems Manager Parameter Store 사용
애플리케이션은 EC2에서 실행
보안 파라미터 (SecureString)
안전하게 접근

// SecureString, EC2에서 접근, KMS 암호화

AWS Systems Manager Parameter Store
-> 애플리케이션 설정값과 비밀번호를 저장하는 보관함
// DB 비밀번호, API 키 등을 코드에 직접 넣으면 위험
// Parameter Store에 따로 저장

Parameter Store 3가지 타입
1. String // 평문 텍스트
2. SecureString // 암호화된 값
3. StringList // 쉼표로 구분된 문자열 목록

// SecureString은 KMS로 암호화되어 있기 때문에
읽기 권한 + 복호화(KMS Decrypt) 권한이 모두 필요
-> EC2 인스턴스에 IAM Role을 연결
그 Role에 다음 권한을 부여:

ssm:GetParameter (Parameter 읽기)
kms:Decrypt (암호 해독 - 복호화)


#시험 포인트
EC2에서 SecureString 읽기
= IAM Role + ssm:GetParameter + kms:Decrypt

---

Q165)

[ 외부 사용자 -> API Gateway -> NLB -> EC2 ]

보안 요구사항:

1. SQL 인젝션 같은 웹 공격 방어 (L7 공격)
2. 대규모 정교한 DDoS 공격 탐지 및 완화

// L7 공격 + L3/L4 DDoS 보호 둘 다 필요

SQL Injection, XSS -> AWS WAF
고급 DDoS 보호 -> Shield Advanced

API Gateway
// HTTP 요청을 처음 받는 지점
REST/HTTP API 엔드포인트
사용자와 가장 가까운 L7 레벨

WAF
// HTTP 요청 내용을 검사함
헤더, 바디, 쿼리스트링 분석 가능
SQL Injection 패턴 탐지 가능

-> WAF는 HTTP를 이해하는 API Gateway에 붙여야 함

Shield Advanced
// 대규모 네트워크 트래픽 공격 방어
L3/L4 보호 (NLB 같은 네트워크 리소스를 보호)

-> 네트워크 트래픽이 실제로 몰리는 NLB를 보호해야 함


#시험 포인트
WAF는 HTTP 공격 방어 (API Gateway 보호)
Shield는 네트워크 DDoS 방어 (NLB 보호)

---

Q166)

EC2 기반 모놀리식

순차 처리

결과 순서 중요하지 않음

수직 확장만 가능

 

변경 후:

ECS 기반 마이크로서비스

확장 가능해야 함

서비스 간 통신 필요

 

// Data is processed sequentially, 

but the order of results does not matter

(연속적으로 처리 되어야하지만 순서는 안 중요)

 

마이크로서비스 통신 원칙

// 느슨하게 결합

// 비동기 통신

// 확장 가능

 

-> SQS

비동기 메시징

생산자/소비자 분리

순서 중요하지 않으면 Standard Queue 사용

수평 확장 쉬움

ECS와 궁합 좋음

 

 

#시험 포인트

마이크로서비스 간 비동기 통신 = SQS

---

Q167)

MySQL을 AWS로 마이그레이션

과거 DB 장애 경험

데이터 손실 최소화

모든 트랜잭션이 최소 두 노드에 저장

신뢰성 높은 솔루션

 

// stores every transaction on at least two nodes

minimizes data loss

-> 동기식 복제 (synchronous replication) 필요

 

RDS MySQL Multi-AZ 

// Primary + Standby

// 동기식 복제

// AZ 장애 시 자동 Failover

// 데이터 손실 최소화

// 트랜잭션이 두 노드에 동기 저장

 

Amazon RDS

-> 요청한 인프라 용량 프로비저닝에서 데이터베이스 소프트웨어 설치에

이르기까지 관계형 데이터베이스를 관리형으로 제공하는 서비스

// Multi-AZ 활성화하면 Primary + Standby 인스턴스 구성

-> 자동 장애 조치, 동기식 데이터 복제 (고가용성)

 

 

#시험 포인트

데이터 손실 최소화 + 동기 복제

= RDS Multi-AZ

---

Q168)

새로운 동적 주문 웹사이트 구축중

서버 유지보수 최소화

패치 관리 최소화

웹사이트 고가용성

읽기/쓰기 빠르게 확장

사용자 수요 변화에 즉각 대응

 

// 최소운영, 빠른 확장, 고가용성

-> (서버리스 아키텍처)

S3 → 정적 콘텐츠

API Gateway + Lambda → 동적 처리

DynamoDB On-Demand → DB

CloudFront → 글로벌 전달

 

왜 완벽한가?

// 완전 서버리스

EC2 없음(참고: Aurora는 인스턴스 기반, 읽기전용)

패치 없음

DynamoDB On-Demand는 읽기/쓰기 즉시 자동 확장

고가용성 기본 제공

 

“scale read and write capacity as quickly as possible”

→ DynamoDB On-Demand가 가장 빠름

 

DynamoDB = NoSQL, 완전 서버리스, 자동 확장

Aurora = 관계형(SQL) DB, 고성능 RDS

 

 

#시험 포인트

완전 서버리스 웹사이트 

= S3 + API Gateway + Lambda + DynamoDB

---

Q169)

AWS 계정 있음

온프레미스 데이터센터와 Direct Connect 연결됨

모든 비-VPC 트래픽은 Virtual Private Gateway로 라우팅됨

Lambda 함수 새로 생성됨

Lambda가 온프레미스 private subnet DB에 접근해야 함

 

// Lambda → 온프레미스 DB 접근

 

기본적으로 Lambda는 VPC 밖 실행

(-> AWS가 관리하는 AWS 내부 VPC에서 실행)

Direct Connect 경로 사용 불가

-> Lambda가 온프레미스 접근하려면

반드시 내 VPC 안에서 실행되어야 함

 

// Lambda 기본 상태는 “AWS 공용 공간”

VPC 연결하면 “내 VPC 네트워크 안

 

Lambda를:

VPC에 연결

적절한 Subnet 지정, Security Group 설정

 

[ Lambda (VPC 내부) -> VPC Route Table

 -> Virtual Private Gateway -> Direct Connect

 -> On-Prem DB ]

 

#시험 포인트

Direct Connect를 쓰려면 Lambda가 VPC 안에 있어야 함

---

Q170)

애플리케이션은 ECS에서 실행

이미지 리사이징 후

S3 API 호출해서 업로드

S3 접근 권한 필요

 

// ECS 컨테이너가 S3에 접근할 수 있어야 함

 

-> IAM Role을 사용해야 함

 

ECS 2가지 Role 개념

1.Execution Role // ECS가 이미지 pull 등 수행

2.Task Role // 컨테이너 애플리케이션 권한

 

-> 애플리케이션이 S3 접근(Task Role 필요)

 

=> IAM Role 생성 + taskRoleArn 지정 

// 1. S3 읽기/쓰기 권한 가진 IAM Role 생성

// 2. ECS Task Definition에서 taskRoleArn에 지정

 

[ ECS Task -> IAM Role (taskRoleArn) -> S3 접근 ]

 

// ARN은 AWS 리소스의 고유한 식별자이고,

taskRoleArn은 ECS Task에 붙일 IAM Role의 주소

 

 

#시험 포인트

ECS 컨테이너가 AWS 리소스 접근

-> Task Role 사용

---

(~Q185)