약 3주간 준비한 AWS SAA(Solutions Architect – Associate) 시험에 합격하였다.
바우처를 사용하긴 했지만 응시료가 10만 원이 넘는 시험이었기에, 불합격했다면 아쉬움이 컸을 것 같다.

원래는 5월 16일에 시험을 볼 예정이었으나, 학습이 부족하다고 판단하여 바우처 사용 가능한 마지막 날인 5월 21일로 미뤘다.

시험 당일

시험은 안양에 있는 앤아버 어학원에서 봤다. 

https://naver.me/FoELc8x7

 

네이버 지도

앤아버어학원 안양점

map.naver.com

 

시험장은 생각보다 단출했다.
20만 원 상당의 시험이라고 하기엔 시설이 다소 미흡하다고 느꼈다.
전체 시험 시간은 약 80분 정도 소요되었고, 영어 지문과 병행하여 문제를 풀었다.

학습 과정

1. 개념 학습 (약 1주 반)

  • 한 권짜리 교재를 활용하여 주요 서비스 개념과 역할 정리
  • 각 단원의 연습 문제를 통해 이해도 점검

2. 덤프 기반 문제 풀이

  • VCE 프로그램을 이용하여 900문제 중 랜덤으로 50~65문제로 구성된 세트를 총 5회 풀이
  • 오답노트를 따로 정리하고, 틀린 문제는 다시 복습함
  • 시험 직전 지하철에서 확인했던 20문제 중 1문제가 실제 시험에 출제됨

후기

시험을 통과하긴 했지만, AWS 서비스들이 머릿속에 온전히 정리되었다고는 느껴지지 않는다.
덤프를 기반으로 한 단기 암기식 학습이었던 만큼, 실전에서 바로 적용 가능한 수준은 아니라고 생각한다.

이 자격증의 의미는 AWS 내 주요 서비스의 존재와 용도, 상황에 따른 서비스 배치를 표면적으로라도 익혔다는 데에 있다.
이제는 실제 프로젝트에 다양한 AWS 서비스를 직접 배치하고 구성해 보면서 학습 내용을 체화하는 것이 필요하다.

'공부일지 > SAA 합격하기' 카테고리의 다른 글

SAA 모의고사 5차 오답노트  (2) 2025.05.19
SAA 모의고사 4차 오답노트  (0) 2025.05.19
SAA 모의고사 3차 오답노트  (0) 2025.05.18
SAA 모의고사 2차 오답노트  (0) 2025.05.17
SAA 문제 풀이 1~30  (0) 2025.05.13

1. EKS를 사용 중 Kubernetes 클러스터에 비밀 객체 형태로 민감한 정보를 저장하고 있음, 그 정보가 암호화 되었는지 확인

A. 컨테이너 앱을 사용하여 KMS를 사용해 정보 암호화

  • 직접 앱 코드 구현해야해서 운영 오버헤드 큼

B. KMS를 사용해 EKS 클러스터에서 비밀 암호화를 활성화 → 정답

  • EKS는 KMS를 사용한 Secrets 암호화 지원함
  • KMS 연동만 하면 가능

C. 람다로 따로 구현하는 건 과도한 오버헤드

D. 파라미터 스토어와 KMS 암호화

  • Parameter Store는 사용자가 데이터를 저장/조회할 때 사용하는 별도의 서비스임
  • Kubernetes native한 Secret 저장소 아님

EKS Secrets + KMS

→ 쿠버네티스 스크릿은 기본적으로 base64 인코딩 수준

KMS와 연동 시 암호화 보안이 강화

2. 공급업체 RDS와 자신의 VPC 간 데이터 엑세스를 위한 네트워크 연결 방법

  • Cross-account RDS 접근
  • 네트워크 통신 필요
  • 물리적 전용선/ 터널 방식 불가

정답 C. 공급업체 VPC에 NLB 생성 RDS 앞에 NLB 두고 PrivateLink 사용하여 회사의 VPC와 공급업체의 VPC를 통합함

PrivateLink는 한 VPC에서 다른 VPC의 서비스로 사설 IP 통신하는 것

→ 자신의 VPC 안에 서비스 처럼 사용가능

→ 반드시 NLB가 앞단에 구성되어야함

여기서 RDS는 완전관리형이기 떄문에 고객이 RDS 인스턴스를 NLB 뒤에 직접 배치할 수 없음

그렇기에 RDS Proxy를 통해 NLB와 연결함

A. direct connect X

B. VPN 연결 + VPC 피어링

  • VPN도 사용 금지

D. Transit Gateway + VPC 피어링

  • 트랜짓 게웨는 여러 VPC를 연결할 때 필요한거 과도함

3. SMB(Windows 파일 공유 프로토콜) 사용 앱을 완전 관리형 파일 공유 스토리지가 필요할 때

  • SMB(Windows 파일 공유 프로토콜)
  • 완전관리형 원함\

Storage Gateway

  • 볼륨 게이트웨이
    • 온프레미스와 AWS 간 캐시/스토리지 연결용
    • 운영부담 있음
  • 테이프 게이트웨이
    • 백업용 테이프 에뮬레이터, 미디어/파일 공유와 무관
  • EC2는 관리해야함

D. FSx는 윈도우 파일 공유 프로토콜 지원함

4. 고객의 AWS 계정에서 EC2 및 CloudWatch 데이터를 읽기 위한 가장 안전한 권한 위임 방식

  • 고객 계정에 접근해 모니터링 할 수 있어야함
  • 안전한 권한 위임 방식은 룰 기반 이고 신뢰 정책을 만드는 것이다.

A. 해당 서비스에 대한 권한을 역할로 만들고 신뢰정책을 작성 → 정답

B. 토큰 판매기 구현하는 서버리스 API 구현하고 임시 자격증명을 제공

→ API로 자격증명 제공하는 건 위험

C. 사용자로 관리하는 것 안됨

D. Cognito는 애플리케이션 사용자 인증용임

5. SQS에서 메시지가 중복 처리되지 않도록 보장하는 방법

메시지 큐에서 사용하고 삭제하는 그 순간에 다른 소비자가 사용할 수도 있음

이걸 방지하기 위해 일시적으로 메시지를 숨기는 것이다.

C. ReceiveMessage 이건 메시지 수신 apik

D. 가시성 타임아웃 하는거

6. 기존 온프레미스의 AD 인증 메커니즘 유지하며, SFTP 기반의 파일 전송을 AWS로 확장

  • 온프레미스의 SFTP 솔루션 확장
  • 저장소는 S3
  • 기존 Microsoft AD로 사용자 인증

A. SMB는 SFTP 와 다른 프로토콜

B. EC2 오버헤드

D. 자격 증명 공급자로 AD 해야되는데 AWS Directory service를 쓴다고하면 안됨

답 C Transfer family로 SFTP 지원 + AD Connector로 AD 연결 그대로 사용

7. Cross 리전 으로 DR 전략 구성 중 대기 시간 최소화하면서 DR 지역 DB 최신화 상태 유지 가장 낮은 RTO 복구 시간 목표

  • DR 리전 유지 → 다중 리전 구성
  • 최신 데이터 유지 → 데이터 동기화 함
  • 최소한의 DR 인프라 → 웜 스탠바이가 적절
  • RTO → DR 전환 시 빠른 복구 가능해야함

✅ 복구 전략 비교

전략 RTO RPO 비용 설명

백업 & 복원 매우 김 김 매우 낮음 저장만 하고, 복구 시 수동 재구성
파일럿 라이트 중간 중간 중간 DB만 가동, 앱 서버 등은 필요 시 확장
웜 스탠바이 짧음 짧음 약간 높음 축소된 형태의 전체 시스템 대기 중
핫 스탠바이 (멀티 리전 액티브/액티브) 매우 짧음 매우 짧음 높음 모든 시스템이 실시간 이중화 운영 중

Aurora 글로벌 DB는 멀티 리전에 데이터 복제 가능함

→ DR 리전에 최신화 Aurora가 해줌

웜 스탠바이는 축소된 규모로 DR 리전에 인프라 유지하는 거

→ 필요시 빠르게 확장

8. AWS에 마이그레이션된 데이터 웨어하우스를 쿼리하는 시각화 도구의 네트워크 비용 절감 방안

  • 시각화 도구는 많은 양의 쿼리 결과를 전송받음
  • 웹 페이지 당 500KB
  • AWS Direct Connect 존재
  • 비용 최소 → 인터넷 말고 전용선 사용하는 것

A. 인터넷으로 전송이 가장 비쌈

B. 동일 리전에 호스팅 but 인터넷으로 엑세스 → 동일 리전도 인터넷을 통하면 비용 있음

C. 온프레미스 + DC 이건 온프레미스에서 AWS로 전송하는 비용 발생

D. 같은 리전에 DC 통신은 무료임 전송비용도 쌈

대용량 전송 시 리전 안에서 사용하고 Direct Connect 사용하는게 좋음

9. 온프레미스 ↔ VPC 연결 단순화하고 향후 VPC 수 증가에 유연하게 대응할수 있는 구조는

  • 온프레미스 위치 여러 개 → 멀티 사이트 고려 필수
  • AWS 내 여러 VPC와 연결
  • 관리 쉬워야함 → 단순 구조 중앙 집중식
  • VPN 또는 DIrect connect 연결 존재 가능

A. vpc 많아지면 복잡

B. EC2 사용은 관리 어려움

C. 전송 게이트웨이가 Transit gateway 이건 VPC 중앙 집중식으로 여러개를 라우팅해줌 이건 무조건이지

D. 모든 VPC DC 연결은 불가능

10. 백업의 2가지를 Aurora로 만드는 법

  1. RDS의 스냅샷으로
  2. 데이터베이스 덤프로

A: RDS 스냅샷을 바로 가능

C: 덤프는 파일 같은 개념이니까 올리고 그걸로 Aurora는 바로 가능

B. RDS 스냅샷은 S3에 업로드 불가 내부 리소스임

D. DMS는 스냅샷을 마이그레이션 소스로 사용 불가임

E. DMS는 mysqldump 를 직접 처리 못함 CSV 같은 형식으로 구조화 된 포맷만 가능함

11. 로컬 도커 환경에서 호스트 볼륨에 영구 데이터를 저장하던 앱을 AWS의 완전 관리형 환경으로 이전하기

도커를 완전관리형으로는

파게이트 + ECS

영구저장할 볼륨도 필요함 파일스토리지

C. S3는 오브젝트 스토리지로 컨테이너의 마운트 볼륨으로는 부적합

12. 여러 AWS 계정의 보안 및 거버넌스를 표준화하고, 관리 오버헤드를 줄이면서 FSBP를 준수할 수 있는 관리형 솔루션

  • AWS Organi 전체에 적용
  • API 호출 및 로그인 감시
  • FSBP 준수 여부 파악
  • 자동화된 관리
  • 계정 생성 관리 표준화 필요

A. Control Tower가 멀티계정 환경에서 표준 보안/거버넌스 자동 설정 해줌

Security Hub: FSBP 준수 상태 자동 평가 및 중앙 집계 가능

B. 회원한테는 컨트롤 타워 환경 배포 못함

C/D: AWS Managed Services 사용은 맞지만, MALZ는 고객이 직접 관리불가함

RFC 제출 방식은 오버헤드 많음

RFC (Request for Change)

변경 요청서. AWS Managed Services(AMS)를 사용하는 고객이 인프라 변경을 요청할 때 사용하는 절차

고객이 변경을 요청할 때 변경해주는거니까 오버헤드 발생

AMS (AWS Managed Services)

AWS에서 전체 인프라 운영을 대신 관리해주는 유료 서비스임

자체 운영팀이 없는 고객에 적합함

Accelerate는 RFC로 고객이 원하는 걸 변경가능

Advanced는 완전 AWS가 운영

MALZ (Multi-Account Landing Zone)

계정 구조 표준화 모델

보안 계정, 로그 계정, 앱계정 등 다중 계정 아키텍처임

13. API 기반 애플리케이션을 보호하기 위한 최적의 보안 조합은?

SQL 인젝션 → WAF

DDoS → Shield Advanced

A. NLB는 4계층 그래서 WAF X

D. standard 로는 부족 GuardDuty는 탐지도구임 차단은 못함

E. stan 기본 부족함

DDoS 라고 콕찝었을땐 무료보단 유료인 어드벤스드를 더 좋아함 돈 벌 수 있으니까

14. Lambda 함수에서 온프레미스 데이터센터의 프라이빗 디비에 엑세스 해야하는 시나리오 DC 존재하고 가상 프라이빗 게이트웨이로 라우팅 되어 있음

  • 람다 함수에서 온프레미스 DB 접속해야함 → 람다는 VPC 내에서 실행되어야함
  • 온프레미스환경은 DC로 AWS에 연결됨
  • 모든 비VPC 트래픽은 VGW로 라우팅됨 → 라우팅만 올바르면 통신 가능

VGW는 VPN/DC가 AWS내의 VPC로 들어오는 곳에 관문역할 종단점

모든 비 VPC 트래픽은 VGW로 라우팅된다는건 모든게 다 DC로 들어온다는거

A. 적절한 보안 그룹을 사용하여 VPC에서 실행되도록 람다 함수를 구성

  • 람다 함수가 온프레미스 자원에 접근하려면 반드시 VPC 내 서브넷에 연결되어야함
  • 해당 서브넷은 프라이빗 서브넷 + 라우팅 테이블이 VGW를 통해 DC를 바라보도록 설정
  • DC로 온프레미스로도 접근이 가능함

즉 인터넷 없이 바로 연결이 가능함 프라이빗 서브넷이

B. VPN 연결 한다 → 이미 DC 있음

C. Lambda 가 DC를 통해 엑세스하도록 라우팅 테이블 업데이트

D. 람다는 탄력적 IP 직접 사용 불가

15. 윈도우 기반 온프레미스를 EC2 Windows 인스턴스로 마이그레이션 하려함 이때 파일시스템은 Windows 사용해야함

  • 윈도우 파일시스템인데 완전관리형을 원함

왜내가 EFS를 했을까

윈도우 파일 시스템이면 무조건 FSx인데 그냥

스토리지게이트웨이 볼륨 게이트웨이는 온프레미스 AWS 사이 캐싱 백업용임

EFS는 리눅스 기반임

EBS는 단독연결용

16. 자바 기반 함수에서 콜드 스타트 시간을 최소화하고 함수가 확장될 때 생기는 지연을 줄이면서 비용최적화

  • Java 11 이상에서 사용할 수 있는 콜드 스타트 시간 최소화 기술
  • 스냅샷으로 저장 후 즉시기동
  • 자바처럼 무거운 언어 시작 시간 90퍼 까지 단축
  • 추가요금 없음

A. 시간 단축되지만 비용 효율성 낮음

B: 무관

C. 조금의 향상 비용증가

17. AWS Outposts 사용 하이브리드 클라우드 환경에서 운영팀 업무

AWS Outposts: AWS에서 제공하는 온프레미스용 랙 기반 하드웨어 인프라. AWS 서비스를 로컬 데이터센터에서 실행 가능

AWS는 Outposts 랙 내부 구성 요소를 원격에서 관리

고객측 운영팀은 렉의 전원, 네트워크, 위치, 설치 환경 등을 관리

물리적인 걸 관리하고 렉 운영은 AWS가 함

18. VPC가 인터넷에 연결되면 안 되며, 또한 ap-northeast-3 리전만 사용 가능하다는 강력한 컴플라이언스 제약 조건을 만족해야함

  • 인터넷 연결 금지 IGW NAT Gateway 등 사용금지
  • 리전 제한 → 다른 리전은 차단

A. control tower 는 멀티계정 환경에 거버넌스와 제한 규칙을 제공함

리전 제한 정책 모두 쉽게 사용가능

B. WAF는 7계층 방어 VPC 인터넷 어차피 안될건데 필용벗음

D. NACL은 서브넷 단위 리전 못막음

E. 사후 감지 / 경고 용도임

Config는 리소스의 구성 상태 변경을 기록하고 정책 위반을 감지하고 알림을 주는 서비스

 

 

 

 

 

 

 

'공부일지 > SAA 합격하기' 카테고리의 다른 글

AWS SAA 자격증 3주 준비 후기  (0) 2025.05.21
SAA 모의고사 4차 오답노트  (0) 2025.05.19
SAA 모의고사 3차 오답노트  (0) 2025.05.18
SAA 모의고사 2차 오답노트  (0) 2025.05.17
SAA 문제 풀이 1~30  (0) 2025.05.13

1. 다중 AWS 계정 환경에서 개발자들이 Production 계정에 접근해야 하는 상황

  • 신뢰 관계, 역할 기반 접근, IAM 그룹 기반 위임 방식
  • Development 계정 + Production 계정
  • 개발자가 Production 에 접근하여 코드 배포할 수 있어야 함
  • 많은 개발자가 접근 예정 확장성 있는 방식 필요

Production 계정에 IAM그룹을 생성하고, 신뢰 정책을 통해 위임

A. 각 계정에서 정책 문서 생성 → 비효율 확장성 없음’

B. 개발 계정에 역할 생성 + 프로덕션 권한 부여 → 신뢰 관계가 반대임

C. 프로덕션 계쩡에 역할 생성은 맞지만 역할이 있는 쪽에 해야 함

Production 계정 접근 필요하면 역할을 Production 계정에 생

역할은 정책 + 누가 이 역할을 가질 수 있는가(신뢰 관계)

개발자는 Dev 계정, 리소스는 Prod 계정에 있으니 Production 계정에 역할 만들고 누구한테 이 역할을 줄지 설정해야하는것이다.

ElastiCache for Redis 환경에서 고가용성을 보장하는 상황, 노드 단위 장애, 가용 영역 쟁애, 리전 장애 대응

여러 노드가 포함된 샤트가 있는 다중 AZ Redis 복제 그룹

  • Redis 복제 그룹 Multi-AZ replication group 구성
    • 하나의 Primary 노드 + 다수의 Replica 노드
    • 다중 AZ에 배치 → 하나의 AZ 장애시 자동 장애 조치
    • 읽기 처리 분산 + 데이터 손실 최소화
  • ElastiCache Redis는 이 구조를 통해 고가용성과 내결합성 확보함

노드 수준 + AZ 수준 + 데이터 복제 까지 충족

EC Redis에서 복제 그룹이란

  • 하나의 프라이머리 _ 0~5개 레플리카 노드로 구성됨
  • 장애 조치를 구성하려면 이 복제 그룹이 있어야함
  • 이게 장애 조치를 활성화를 위한 유일한 단위

B. AOF(Append Only File)

  • 이건 로컬 지속성 옵션일 뿐
  • 레디스는 기본적으로 디스크 지속성을 비권장 메모리에서만 하는거니까
  • AOF만으로는 고가용성 구성 또는 자동 장애 조치 불가

D. Auto scaling 활성화는 레디스에서는 없음

EC 레디스는 복제 단위라는 걸로 가용성을 책임짐 기본 + 레플리카 노드로 구성 자동으로 패일오버해줌

3. Aurora DB 사용 중 읽기 트래픽 급증 비용 효율적 확장 솔루션

  • 사용자 읽기 쿼리 때문에 쓰기 쿼리 성능 저하

읽기 복제본을 늘려야함

A. 두 번째 Aurora 클러스터 생성

  • 관리 복잡 비용 증가

B. DynamoDB Accelerator 이건 오로라랑 전혀 상관없는데 왜 골랐지

D. Redshift 클러스터 생성

  • 이건 분석용임 + 비쌈

그니까 Aurora는 하나의 리전에 3개 az에 2개씩 총 6개를 자동 유지함

이 복제는 읽기 복제본이 아님 단지 스토리지 계층의 고가용성과 데이터 내구성을 위한 것

최대 15개의 읽기 복제본 구성 가능한것임 AZ에 분산해서

자동으로 읽기 요청은 이것들로 분산해줌

이걸로 읽기 트래픽 분

AWS Schema Conversion Tool은 MySQL 스키마를 AWS용 스키마로 자동 변환

AWS Database Migration Service는 Snowball 전송 후 네트워크 기반 지속 복제 수행

다운타임 최소화: 스위치 오버 직전까지 실시간 변경사항 반영

4. 고가용성 운영 자동화를 Aurora PostgreSQL 기반의 EC2 웹 애플리케이션 아키텍처에서 구현

  • DB ⇒ Aurora 단일 AZ 배포 중 이걸 고가용성 데이터 손실 최소화 운영 자동화를 해라

B. 여러 가용 영역을 사용해 Auto Scaling 그룹 구성 + DB 수전 AZ 구성 + RDS 프록시 구성

  1. 고가용성 확보
    1. EC2 Auto Scaling 그룹으로 장애시 서비스 중단 방지
    2. 다중 AZ를 통한 리더 / 레플리카 복제로 고가용성
    3. RDS Proxy로 연결 풀링해 장애 조치 자동 전환을 도움

A. 다른 리전은 복잡하고 지연 큼

Aurora PostgresSQL은 리전 간 복제를 공식 지원 안함

DNS 기반 리다이렉션은 느리고 DB HA에 맞지않음

C. 단일 AZ에.. 이건 가용성 없음

D. S3 + Lambda 로 백업 데이터 오로라 얘기 없음

5. HPC 워크로드에 대해서 EC2에서 어떤 설정을해야 적절한 네트워크 성능 확보 가능한가

 

인스턴스들간의 물리적으로 가까워야함

최대 네트워크 대역폭 제공 구조 필요

클러스터 배치 그룹은 인스턴스들을 물리적으로 서로 가까운 하드웨어에 배치하는 것임

그래서 최대 100Gbps ENA 네트워크 성능과 낮은 지연시간을 제공한다.

AWS가 권장하는 방식임

B.의 전용 인스턴스 테넌시는 성능보다 보안 규정 때문에 쓰임

HPC환경이다 했을 때 나오면 정답인 키워드

클러스터 배치 그룹 (Cluster Placement Group)

Amazon FSx for Lustre

io2 / io2 Express

EFA (Elastic Fabric Adapter)

6. 매월 1회 48시간 동안만 RDS 인스턴스 사용 테스트, 비용 효율성 높은건?

 

이건 아주 짧게만 사용하고 마는 것

비용 줄이는 게 우선

그럼 삭제하는게 최선

A. 중지는 삭제가 아님 EBS 요금 그대로 나감

C. 스냅샷 요금만 내면 됨 인스턴스는 삭제하는 거니까

7. AWS Organizations를 사용하는 환경에서 S3 버킷 접근을 조직 내 계정으로 제한하려는 상황

 

  • 특정 S3 버킷은 Organiz 내 계정만 접근 가능해야함
  • 운영 오버헤드 최소

A. 조직 ID에 대한 참조와 함께 aws:PrincipalOrgID 전영 조건 키를 S3 버킷 정책에 추가 → 조직 ID에 속한 모든 계정/사용자/역할만 허용할 수 있음 이러면 해당 조직 외의 접근을 전부 차단 가능

매우 간단

A는 조직 전역에게 한 번에 적용할 수 있는것

B. aws:PrincipalOrgPaths 는 조직 경로 즉 조금은 세부적으로 설정할 수 있는것 여기서 원하는건 전역으로 원하니 모든 경로를 다 설정해줘야함 A가 더 효율적

C. 감시만 하는거

D. 이건 사용자 태그를 관리해야 함 사용자 태그로 막는거니까 이러면 복잡함

조직 단위로 허용하고 막거나 할때는 PrincipalOrgID 전역 PrincipalOrgPaths 조금더 세부로 설정 가능

8. DynamoDB 사용 중 데이터 복구 요건 RPO RTO 맞추기

 

일단 RPO 데이터가 손실되고 얼마까지는 손실되어도 되는지 여기서는 15분 전기록까지

RTO는 얼마 뒤까지 복구 되어야 하는지 1시간 이내라고함

B. DynamoDB Point-in-Time Recovery PITR 이라는게 있음

  • 초 단위로 백업 유지함
  • 최대 35일까지 복원가능
  • 복구 지점은 15분 보다 훨씬 더 짧은 단위로도 가능
  • 복구 실행 → 새 테이블로 복원 수분에서 수십분이면 가능

RPO 조건이 몇분단위일경우는 PITR 활성화를 권장함 → 비싼 서비스겠네

A. 전역 테이블 구성

  • 이건 글러벌 장애 회복에 사용됨
  • RPO, RTO 요구 조건 충족 없음

D. EBS 스냅샷 활용

  • Dynamo는 완전관리형임 EBS 같은거 다룰 수 없음
  • 따라서 EBS 스냅샷 같은거 못함
  • 완전히 틀린 선지

DynamoDB 복구를 빠르게 해야한다? PITR 설정하자

9. ECS에서 실행되는 앱이 S3에 접근할 권한이 있는지 어떻게 확인하는가 즉 권한을 어떻게 부여하고 연결하는를 묻는거래요

ECS는 S3와 같은 다른 AWS 서비스에 접근하려면 IAM 역할을 ECS 태스크 또는 서비스에 정확히 연결해야함

B. S3 권한이 있는 IAM 역할 생성 하고 taskRoleArn에 지정하기

ECS에서 S3 API를 호출하려면 해당 ECS 태스크에게 IAM 역할을 위임해야함

ECS 태스크 정의에 taskRoleArn 속성을 설정해야 그 컨테이너가 해당 IAM Role의 권한으로 API 호출가능

즉 컨테이너가 생기고 사라지고 하는 과정에서 매번 주기 힘드니까 접근하는 권한이 담긴 역할을 연결해줘야함

A. ECS 클러스터 레벨이 아닌 태스크 레벨에 지정해야함 + 컨테이너 재시작만으로 적용되지않음

C. 보안 그룹은 IP/포트 차단 허용용

D. ECS에서 IAM 사용자로 직접 로그인할 일 없음

태스크가 직접 역할을 통해 권한 위임받음

10. EC2 + io2 EBS 기반 MySQL 환경 에서 비용 절감 IOPS 성능과 고가용성 유지 목표

  • EC2 자체 호스팅 MySQL + io2 프로비저닝 IOPS EBS 사용 중 근데 1000 IOPS 트래픽 예상
  • 2000 IOPS 까지 감당가능하면서 비용 낮추길 원함

지금 io2 EBS는 너무 오버 스팩임 이걸 줄이고 가용성을 위해선 그걸 줄이고 RDS를 멀티 AZ로 하는게 맞음

B. 범용 gp2 EBS인 RDS로 바꾸고 다중 AZ로 배포

A. io2도 오버스팩인데 Express는 정신 나간거고 이걸 왜골랐지

D. EC2 2개로 Active passive 조합은 운영 힘듬

11. ALB 로그 분석 및 비정상적인 트패픽 패턴 발견하기

  • ALB 인 상황 L7 HTTP/S 로 라우팅

ALB는 엑세스 로그 기능을 지원

  • 요청 경로, 응답 코드 , 지연시간 등 다양한 로깅
  • 로그는 S3 버킷에 저장됨

Athena

  • S3에 저장된 로그를 서버 없이 SQL로 분석가능

A. CloudTrail은 API 호출 로깅용 ALB 엑세스 로그와 별도임

사용자 요청 네트워크 트래픽 분석에는 부적절

ALB는 다양한 로깅기능이 있으며 S3에 저장됨 이걸 데이터 분석 툴로 분석할 수 있음

12. Organizations 환경에서 비용 초과를 감지하고, 초과 시 자동 알림 및 추가 리소스 프로비저닝 방지 구현

이제 진행할 AWS 프로젝트에서 실질적으로 필요한 내용인 듯

비용 통제 + 알림 + 리소스 제한(자동으로) 이 세 조건이 모두 충족되어야함

  1. 계정별 예산 임계값 도달 시 알림
  2. 추가 리소스 프로비저닝 자동 차단
  3. 자동화된 통제 정책

AWS 예산 생성 + 결제 대시보드에서 임계값 알림 구성

예산 작업용 IAM 역할 생성

예산 초과 시 SCP를 통해 프로비저닝 제한 + IAM 역할 연결

Service Control Policy: 계정 내 서비스 제한 가능

예산 초과 시 SCP로 서비스들 생성 제한 가능

13. SAML을 지원하지 않는 온프레미스 LDAP 디렉터리 서비스와 AWS 연동하기 by STS

LDAP(Lightweight Directory Access Protocol) 디렉터리 서비스

  • 회사 내부에서 사용자, 그룹, 권한을 관리하는 디렉터리 서비스의 표준
  • 대표적 구현체들이 있음

SAML(Security Assertion Markup Language)

이건 SSO 및 인증 토큰 교환 프로토콜임

역할 토큰을 만들어주는 역할을 함

그렇기에 LDAP와 호환안

STS는 임시 자격 증명을 발급하는 서비스

SAML 없이 온프레미스 LDAP 자격 증명을 브로커 애플리케이션으로 변환하고

AWS API 또는 콘솔에 접근할 수 있도록 임시 인증 토큰을 발급 해줌

A. LDAP는 SAML과 연동 불가 다른 프로토콜이니까

B. IAM 정책을 LDAP에 통합

  • IAM은 AWS 내부정책이므로 LDAP 와 통합 불가능

C. LDAP 자격 갱신 시 IAM 갱신

IAM 자격 증명은 수동으로 관리되어야 함

LDAP 변경에 따라 자동으로 갱신되는 구조 아님 → 비현실적 프로세스

즉 SAML 없는 LDAP 환경에서도 AWS 접근을 가능하게 하는 유일한 방법이 토큰을 만들어주는 역할을 대신해주는 AWS Security Token Service이다.

14. AS2 프로토콜 기반의 데이터 전송 + 자체 IdP를 이용한 사용자 인증이 필요한 경우 어떤 AWS 서비스 조합이 적절?

  • AS2(Applicability Statement 2): EDI(전자문서교환)에서 사용하는 전통적 B2B 데이터 전송 프로토콜
  • 자체 IdP 사용: 사용자는 사내 ID 공급자로 인증되어야 함(LDAP, AD, SAML 등)
  • 애플리케이션에서 인증과 전송을 동시에 처리해야 함

C. AWS Transfer Family + AWS Lambda + 자체 IdP 연동

AWS Transfer Family

  • AS2, FTPS, SFTP, FTP 등 기존 전송 프로토콜을 AWS로 확장 지원

자체 IdP와 연동

  • Transfer Family는 Lambda authorizer를 통해 사용자 인증을 자체 IdP와 연결 가능

A. DataSync는 파일 동기화 서비스 AS2 프로토콜 지원 안 됨

B. AppFlow + ECS

  • AppFlow는 SaaS 앱 간 데이터 연동용
  • AS2 와 무관
  • ECS도 과함

D. Storage Gateway + Cogito

이건 온프레미스 와 클라우드 파일 공유 에 사용되는것

Coginito는 자체 IdP와 맞지 않음

AWS Transfer Family는 온프레미스와 클라우드 사이의 파일전송 프로토콜을 사용할 수 있게 해주는 서비스

AWS Lambda의 Authorizer라는 것을 통해 자체 IdP인증이 가능함

 

 

 

 

 

 

 

 

 

 

'공부일지 > SAA 합격하기' 카테고리의 다른 글

AWS SAA 자격증 3주 준비 후기  (0) 2025.05.21
SAA 모의고사 5차 오답노트  (2) 2025.05.19
SAA 모의고사 3차 오답노트  (0) 2025.05.18
SAA 모의고사 2차 오답노트  (0) 2025.05.17
SAA 문제 풀이 1~30  (0) 2025.05.13

1. 메시지 풀링 처리 중 늘어나는 메시지 양에 적절하게 대응하는 솔루션

  • EC2 사용중
  • SQS 사용 중
  • 점점 더 많아지고 있음 → 확장성 필요
  • 운영 비용도 절감하고자 함 → EC2보다 효율적인 방식 필요

도출과정

  • 점점 더 많아지는 메시지

→ Auto Scaling 이나 Severless 구조 필요

  • 운영 비용 절감하고 싶음 → EC2는 항상 켜져있음 → 람다가 유리
  • 스크립트를 실행 중 → 코드 기반임 → 람다에 적합함

오답노트

A. 수직 확장은 단기적인 해결

비용 증가, 확장성도 그닥

B. EventBridge는 이벤트 라우팅 서비스 대체 불가

확장성과는 거리가 멈 끄는 건

D. Sysytems Manager Run Command

이건 그냥 EC2에 접속하는 방법 중 하나임 이걸로 대체되는건 아님

Sysytems Manager Run Command

AWS 인스턴스에 명령을 원격으로 실행할 수 있게 해주는 완전관리형 서비스 SSH 없이도 EC2나 온프레미스 서버에 명령을 실행할 수 있어서 보안, 운영 자동화, 대규모 관리에 탁월

서버리스 구조는 EC2 기반 대비 비용 효율적이며, 메시지 양이 많아질수록 더 유리함]

2. SNS + SQS 아키텍처에서 민감한 의료 데이터를 저장 및 전송할 떄 보안 강화

  • SQS + SNS
  • 저장 및 전송 암호화 필요
    • 서버 측 암호화
  • 승인된 직원만 엑세스 가능
    • 접근 제어 필요 → KMS키 + 정책 필요
  • 아키텍처 보안 강화
  • 데이터 암호화(저장 시)
    • SNS/SQS 메시지 암호화 하려면 KMS 기반 서버 측 암호화 (SSE-KMS)가 필요
    • 각 서비스별로 별도 암호화 설정과 키 권한 정책 설정 필요
  • 키 접근 제어
    • KMS 키 정책을 통해 인증된 보안 주체만 키를 사용할 수 있도록 제한
    • 승인되지 않은 IAM 사용자/서비스는 키를 사용할 수 없음
  • 데이터 전송 암호화
    • TLS 연결을 강제하는 조건을 SQS/SNS 정책에 포함하여, 전송 시 보안 강화

SNS에 KMS 암호화 + 키 정책 제한

KMS

데이터 암호화에 사용할 키를 생성, 저장, 관리, 감사

CKK SMK 를 사용할 수 있음

여러 서비스와 연동해 자동으로 암호화/복호화 처리 가능

Key Policy 키정책

KMS 키 자체에 부여하는 IAM 정책과 유사한 접근 제어 정책 문서

KMS 키의 소유자, 사용할 수 있는 사용자/서비스/역할을 정의

TLS 연결만 허용(Deny HTTP)하는 건 SQS에서만 공식 지원

TLS 강제한다는 건 SQS에 요청 API을 HTTPS 로 보냈냐를 확인하는 것

즉 생산자든 소비자든 접근 시 검사

SNS는 TLS 연결 강제가 없기때문에 키 정책 제한으로 IAM 주체 제한 정책을 설정함

SQS는 KMS으로 데이터 암호화 + TLS 강제 정책으로 전송 암호화 구축

3. 고성능 i/o 스토리지, 내구성 대용량 콘텐츠 저상소, 장기 보관용 아카이브 스토리지 구성하기

 

  1. 실시간 비디오 처리용 10TB 최대 I/O 성능 필요
  2. 300TB 내구성 자주접근
  3. 900TB 거의 접근 안함 저렴

EBS보다 인스턴스 스토어가 더 빠름 왜? 해당 서버에 붙어있는 저장소니까

최대 IOPS, 최소 지연을 충족함 + 저장 지속성 없음 처리용으로만 두는거니까 이보다 더 인스턴스 스토어가 적절한게 없음

4. Lake Formation , 중요한 민감 정보에 대한 세밀한 접근 제어를 어떻게 구성할지

  • AWS Lake Formation 사용 → 데이터 분석 플랫폼 구성 중
  • 다양한 소스에서 데이터 수집
  • 민감 정보에 대한 접근 제한 필요 → 열/행 수준 보안 필요
  • 엑세스를 방지할 수 있는 보안 솔루션 → 필터링

Lake Formation

데이터 레이크를 쉽고 안전하게 구축하고 데이터 접근 제어를 통합적으로 관리하기 위한 서비스

주로 S3에 저장된 구조적 / 비구조적 데이터

아테나 글루 레드쉬프트 이앰알 세이지메이커 등

  • 데이터 권한 중앙 관리
  • 행열 수준 보안
  • 정책 기반 데이터 필터링
  • Federated IAM/Roles 인증 연동

주 목적이 정제된 데이터 접근 제어

데이터 필터를 통해 누구에게 어떤 행과 열을 보여줄지 결졍할 수 있음

이 기능으로 민감한 정보들을 부분만 접근이 필요한 것들에 적용

A. IAM 역할 생성

  • 이건 서비스 수준의 권한 제어
  • 데이터 내부까지는 불가

C,D: 민감한걸 제거한다는건 원본데이터를 제거한다는 것 아니면 두번 저장한다는것 별로임

 

5. 외부 벤더가 회사의 AWS 계정에서 작업 수행하는 상황에서 가장 보안적이고 권한 위임이 가능한 방식으로 엑세스 제공

  • 외부 벤더가 회사 AWS 계정에서 작업 수행해야함
  • 밴더는 자신의 AWS 계정을 가지고 있음
  • 회사 계정에서는 벤더에 IAM 사용자 역할 권한 부여 필요
  • 최소 권한 부여/ 공급업체 계정에서 접근 가능/ 회사 계정보호

외부 계정에서 회사 계정의 자원에 접근하려면, 회사 계정 내에 IAM Role을 생성하고

벤더 계정을 신뢰 주체(Trusted Principal)로 설정해야함

회사 계정에 새로운 역할 만들고

신뢰 정책에 공급업체 AWS 계정 ID를 지정’

벤더는 자신의 AWS계정에서 AssumeRole 을 통해 권한 위임받아 작업

왜 그룹에 넣어 주는 것보다 역할을 만들어서 주는게 좋을까?

임시의 경우

그룹과 역할(Role)의 차이 요약

항목 IAM 그룹 IAM 역할 (AssumeRole)

소속 사용자(User)를 직접 소속시켜 권한 부여 사용자가 역할을 일시적으로 assume(가정)
사용 방식 AWS 계정 내 사용자에게만 적용 AWS 계정 간 위임 가능 (벤더 계정 포함)
외부 사용자 사용 ❌ 불가능 ✅ 가능 (신뢰 정책에 외부 AWS 계정 ID 명시)
일시적 접근 제어 ✖️ 직접 제거 전까지 계속 권한 유지 ✅ 일시적 세션 (예: 1시간~12시간 설정 가능)
세션 기반 접근 ❌ X ✅ Yes (STS 토큰 기반, 세션 추적 가능)
감사 로그 어려움 ✅ CloudTrail에 누가 역할을 assume 했는지 명확하게 기록
보안 계정 내부 사용자라 관리 어려움 ✅ 최소 권한 원칙 + 제한된 세션 + 외부와 격리

명시적으로 삭제 대신 세션으로 유지되어 권한이 뺏기고 CloudTrail이 추적해줌

B. 사용자로 직접추가하는건 추적 힘들고 관리힘듬

C. 그룹은 역할보다 추적힘듬

D. 교차 계정 사용자 등록은 존재하지 않는 방식

중요포인트

  • 외부 계정에서 AWS 자원에 접근할 때는, 역할을 생성하고 신뢰 정책을 통해 권한을 위임하는 방식이 정석임

6. 업로드한 이미지에 부적절 콘텐츠 사전 검사 개발 노력은 최소화

  • 입력 데이터: 이미지
  • 요구 사항 : 부적절 콘텐츠 감지
  • 이미지 기반 자동 감지
  • 최소한의 개발 노력 → 사전 학습된 서비스

Rekognition은 AWS 완전관리형 컴퓨터 비전 서비스임

사전 학습된 모델과 신뢰도 점수 반환함

A. Amazon Comprehend → 텍스트 분석 서비스

C. Amazon SageMaker → 커스텀 모델을 직접 학습시키고 배포하는 것

D. AWS Fargate 이건 컨테이너 기반 EC2 자동 관리해주는 서비스임

SageMaker는 직접 모델을 만들어야하는것

Comprehend는 텍스트 분석 서비스

Rekognition은 컴퓨터 비전 서비스

7. CSV 형식의 보고서를 생성하는 온프레미스 → AWS로 실시간 업로드하고 분석인데 오버헤드는 가장 적게

  • 보고서 저장 위치 → 온프레미스 네트워크 공유(Network Share)

온프레미스에서 네트워크 공유를 AWS S3와 연결하려면

Amazon S3 File Gateway가 최적임

Amazon S3 File Gateway란

온프레미스 환경에서 S3를 네트워크 드라이브처럼 사용할 수 있게 해주는 하이브리드 스토리지 솔루션

  • 온프레미스 서버에 설치된 VM으로 제공
  • NFS/SMB 를 통해 로컬처럼 마운트
  • 자주 접근하는 파일 로컬 캐시에 저장해 빠르게 접근
  • 사용자가 파일을 쓰면 S3버킷에 자동 업로드

AWS DataSync

온프레미스 ↔ AWS 간 데이터 전송 자동화 서비스(파일 단위)

  • NFS/SMB 또는 S3/EFS 간 대규모 파일 동기화 자동화

DataSync Api를 사용하는 앱이란

DataSync 작업을 시작하거나 중지 등 요청할 수 있는 앱

작업 트리거가 될 수 있는

비교: File Gateway vs DataSync

항목 S3 File Gateway AWS DataSync

용도 파일 서버처럼 S3 사용 대량 전송/복제/마이그레이션
연결 방식 NFS/SMB → S3로 실시간 업로드 NFS/SMB/EFS ↔ S3/EFS 간 복제
사용 방식 항상 연결되어 실시간 동기화 수동/스케줄링 기반 실행
실시간성 ✅ 실시간 파일 쓰기 → S3로 업로드 ❌ 전송 트리거 시 동기화
전송 대상 S3 전용 S3, EFS, FSx 등
로컬 캐시 있음 (빠른 읽기 가능) 없음
앱 통합 파일시스템처럼 사용 가능 백엔드 또는 CLI/SDK 호출 필요
CLI/API 사용 일반 파일 API 전송 작업을 CLI/API로 정의 및 실행
비용 구조 파일 수 기반 GB 단위 데이터 전송 요금

✅ File Gateway가 적합한 경우:

  • 온프레미스 직원/서버가 S3를 로컬 파일 시스템처럼 써야 할 때
  • 애플리케이션 변경 없이 기존 워크플로 그대로 S3에 저장하고 싶을 때
  • 사용 빈도가 높은 파일을 로컬에서 빠르게 다시 사용해야 할 때

✅ DataSync가 적합한 경우:

  • 주기적으로 백업/이전/이관해야 하는 대규모 파일 전송 작업
  • 마이그레이션, DR 복제, S3 ↔ S3 또는 S3 ↔ EFS 간 동기화
  • 고속/압축/병렬 처리가 필요한 배치 데이터 복제

즉 드라이버처럼 항상 마운트 해놓고 사용할 경우는 File Gateway가 유리(실시간 유리 캐싱기능)

주기적으로 대량의 파일들을 AWS로 이전할 때는 DataSync가 적합함(배치 병렬 압축 등 대용량에 유리)

8. CloudFront을 사용해 배포 시 HTTPS 보안과 민감 정보 보호를 함께 충족하기 위한 구성 요소

CloudFront로 배포한다는 건

  • 경로 기반 라우팅
  • 캐싱 정책
  • HTTP 헤더 제어
  • 인증/보안(SSL인증서 등)

7계층을 관여하는 것

  • 민감 정보를 전체 CDN에 노출시키지 않고
  • 특정 백엔드 앱에서만 필터링 되도록 제한하고자 함

CloudFront Field-Level Encryption (필드 수준 암호화)

민감한 양식 필드를 CloudFront 엣지에서 특정 필드만 암호화하고

지정된 백엔드 서버만 복호화 할 수 있는 기능

핵심 포인트

민감 정보를 제외하고 보여주거나 허용하고 싶다?

필드단위 행 열 단위 암호화/ 필터링

Lambda@Edge

원래 Cloudfront 는 정적 요청만 처리했음

근데 여기에 간단한 동적 요청도 처리하고 싶음

그래서 넣은게 람다 엣지

A. CloudFront 서명 URL 구성

  • CloudFront 까지 접근은 제한할 수 있지만 데이터 필드 보호에는 관여 안함

B. 서명 쿠키 세션

  • 웹사이트 전체 또는 특정 경로 접근 제어에는 사용 가능
  • 필드 수준 암호화 불가
  • 인증/인가 목적임

D. 뷰 프로토콜 정책 설정을 HTTPS 제한

  • 이미 HTTPS 사용중
  • 전송 보안이지 데이터 보안 아님

CloudFront 필드 수준 암호화는 민감한 사용자 입력 필드만을 암호화하여 특정 애플리케이션에서만 복호화할 수 있도록 보호함

HTTPS는 전송 계층 보호이고, 필드 수준 암호화는 애플리케이션 데이터 보호에 사용

HTTP는 물론 기술적으로 7계층 프로토콜이다.

여기에 TLS로를 씌운 것이 HTTPS이다 여기서 TLS로 보호되는 부분이 바로 전송 과정이다.

그렇기에 HTTPS는 전송 계층 보호라고 한 것이다.

지문에서 요구한건 HTTPS와 다른 보안 계층이 필요했음

그렇기에 안에 내용(L7)까지 암호화하는 필드단위 암호화가 필요한것

9. 애플리케이션의 재해 복구(DR) 목적에서 가용성을 최대화하면서 다운타임 없이 AWS 리전 간 이중화 구성

  • AWS에서 애플리케이션 호스팅 중
  • ELB + Auto Scaling + EC2 + DynamoDB 구조
  • DR 목적 → 장애 시 다른 리전에서 애플리케이션 사용 가능해야 함
    • 여기서 DR은 단순 이중화(AZ 수준)이 아닌 리전 단위로 해야함
    • AZ 수준은 일상적인 고가용성을 위한 것(트래픽 몰리는걸 대비)
    • DR은 하나의 리전이 가용이 불가할 경우를 대비하는 것이기 때문에 다른 리전에 구성
    • RTO(Recovery Time Objective): 장애 발생 후 얼마나 빨리 복구할 수 있어야 하는가
    • RPO(Recovery Point Object): 복구 시점 기준, 데이터 손실 허용 범위는 얼마인가
    • 비용/속도 Trade-off : 빠른 복구일수록 비용 증가
  • 다운타임 최소화가 중요
  • 자동 장애 조치 필요 → 빠르게 DNS 전환될 수 있어야 함

재해 복구에서 다운타임을 최소화하려면

  • 사전 프로비저닝(Warm Standby)구성
  • → 리전도 미리 구성하고, 장애 발생 시 빠르게 전환해야함

정답 A. DR 지역에 동일하게 구성해 놓음 그리고 DNS 장애 조치로 이 ELB 가르키도록 함

이러면 장애 발생 시 프로비저닝 없이 바로 전환 가능

B. 장애 발생 시 리소스 생성하면 다운 타임 큼

C. 이것도 동일

D. 경보를 생성하는걸로는 안됨 자동으로 DNS 단에서 장애조치로 설정된 리전으로 바꿔 줘야

10. 민감데이터 S3 저장 시 최소한의 노력으로 암호화와 키 제어 모두 만족할 수 있는 자동화 암호화 방식

  • 민감 데이터를 S3에 저장
  • 저장 시 암호화
  • 키 관리를 회사가 직접 제어해야함
  • 하지만 최소한의 노력으로 구성

중요 문장

회사는 암호키를 생성, 순환 및 비활성화할 수 있는 ~~~ 완전히 제어해야 한다.

→ 고객 관리형 키

근데 최대한 적은 노력?

→ KMS 사용

11. AWS 서비스 중 최약점 능동적 스캔 후 보고서 주는 서비스

보안 관련 서비스

AWS Shiled - DDos 전

CloudTrail - API 호출 로그 기록용

Macie - S3 민감 정보 검색용

GuardDuty - 의심스러운 행동 분석

이상 행동, 악성 IP, 비정상 접근 감지(AI 기반)

Inspector

EC2, 컨테이너 이미지, Lambda 함수에 대해 보안 취약점과 잘못된 구성을 자동으로 스캔하고 보고하는 서비스

  • 알려진 보안 취약점(CVE 목록 기반)
  • 오래된/취약한 OS 패키지 (ex. openssl, glibc 등)
  • 루트 계정 사용 여부, 포트 오픈 상태, 무단 접근 가능성
  • 잘못된 IAM 권한이나 보안 설정

🔐 2. 암호화 및 키 관리 (Encryption & Key Management)

서비스 설명

KMS (Key Management Service) 대칭/비대칭 키 생성, 저장, 관리 및 서비스 연동 암호화 지원
CloudHSM HSM(Hardware Security Module) 기반 키 저장 및 암호화 연산 (FIPS 140-2 인증)
Certificate Manager (ACM) SSL/TLS 인증서 발급 및 관리 (ALB, CloudFront 등에 연동)
Secrets Manager DB 비밀번호, API 키 등 민감한 정보를 안전하게 저장 및 자동 교체
Parameter Store (SSM) 구성 변수나 민감 정보 관리 (일반 값 + SecureString 지원)

🔐 3. 위협 탐지 및 모니터링 (Threat Detection & Monitoring)

서비스 설명

CloudTrail API 호출 로그 추적 (누가, 언제, 무엇을 했는지)
GuardDuty 이상 행동, 악성 IP, 비정상 접근 감지 (AI 기반)
Security Hub 여러 보안 서비스 결과를 통합 분석 및 리포팅
Detective 이상 탐지 후 원인 분석을 돕는 시각화 기반 분석 도구
Amazon Macie S3의 민감 정보 자동 탐지 (예: 주민번호, 카드번호 등)

🔐 4. 네트워크 보안 (Network & Infrastructure Security)

서비스 설명

VPC Security Group / NACL 인스턴스 또는 서브넷 단위 접근 제어 방화벽
AWS WAF (Web ACL) 웹 애플리케이션 계층 방화벽 (XSS, SQLi 차단)
Shield / Shield Advanced DDoS 공격 보호 (ALB, Route53, CloudFront 등 대상)
Network Firewall VPC 경계에서의 상태기반 L3/L4 트래픽 필터링
PrivateLink / VPC Endpoint 인터넷 노출 없이 서비스 내부적으로만 통신
Route 53 Resolver DNS Firewall DNS 레벨 악성 도메인 필터링

🔐 5. 애플리케이션 및 접근 제어 (Application Security)

서비스 설명

Cognito 사용자 인증, 회원가입, 토큰 기반 로그인 (OAuth2, OpenID)
CloudFront Field-Level Encryption 민감 필드만 암호화 (카드번호 등)
Firewall Manager 조직 전체 보안 정책 통합 관리 (WAF, Shield 등 중앙 제어)
AppConfig (SSM) 앱 설정 변경 시 안전하게 롤아웃 및 검증

🔐 6. 컴플라이언스 및 보안 점검 (Compliance & Governance)

서비스 설명

AWS Config 리소스 구성 변경 추적 및 정책 준수 여부 검사
AWS Audit Manager 보안 감사 및 규정 준수 자동 보고서 생성 (HIPAA, PCI 등)
Trusted Advisor 보안 권고, 비용 최적화, 고가용성 점검 가이드 제공
Access Analyzer IAM 정책의 외부 공개 여부 분석 및 경고
Organizations SCP (Service Control Policy) 계정 전체에 서비스 제약 정책 적용 (상위 통제 정책)

11. AWS Organizations + IAM Identity Center 환경에서 중앙 집중식 사용자 관리 꼐정 권한 부여의 효율적 구성

  • 환경: AWS Organizations 기반 다중 계정
  • 사용자: 개발자 / 관리자
  • 목표: 중앙 집중 사용자 관리 + 계정 별로 권한 제어 + 신규 사용자 쉽게 추가

IAM Identity Center로 중앙 사용자 생성 + 계정 그룹 & 권한 세트 기반 계정 매핑 구성

답 C

IAM Identity Center 사용

그룹을 분리

권한 세트 구성

계정 할당해서 그룹에 넣음으로써 쉽게 추

12. 온프레미스 쿠버네티스 환경에서 AMQP 기반 애플리케이션 운영 중 확장성 증가 요구

 

  • 쿠버네티스 환경 → EKS
  • AMQP 메시지 브로커 필요 → Amazon MQ: ActiveMQ, RabbitMQ 기반 메시징(AMQP지원)

위 두 서비스 관리형 서비스이므로 확장성 운영 오버헤드 낮아짐

A. ECS 는 쿠버네티스 대체 아님 SQS는 AMQP 미지원

AMQP란

Advanced Message Queuing Protocol

메시지 지향 미들웨어를 위한 표준 프로토콜임

바이너리 기반의 7계층 프로토콜

비동기 메시지 기반이면서 신뢰성이 높다.

순서보장 가능함

이걸 따르는 브로커는 RabbitMQ, ActiveMQ

아마존에 있는 건 Amazon MQ 이다.

13. ECS에서 컨테이너 이미지에 대해 CVE(보안 취약점) 검사를 자동화하는 솔루션

  • 컨테이너 실행 환경 ECS
  • 이미지 저장소 언급없음
  • 이미지 보안 검사 CVE 스캔 필요

A. Amazon ECR(Elastic Container Registry)

이미지 저장하면서 기본적인 보안 취약점 스캔까지 해주는 Amazon 서비스

오답노트

B. macie는 민감 데이터 탐지 서비스이지 보안 취약점 찾는건 아님

D. Inspector는 취약점 탐지는 맞지만 구성된 구조가 복잡함

14. Auto Scaling의 확장 전략 중 예측 기반 확장

  • EC2 + Auto Scaling
  • 주간 기록 + 트래픽 패턴 분석 기반 예측
  • 자동 확장 계획 수립
  • 이걸로 자동 조절 원함

정답 B

예측 확장 + 대상 추적 기반 동적 조정

  • 예측 확장: 과거 트래픽 패턴을 기반으로 사전에 인스턴스를 확장
  • 다상 추적: 현재 상태를 기반으로 실시간 조정

이걸 조합해 예측과 실시간 대응 모두가능

A. 이건 예측이 아닌 대응

C. 예측만 언급 현재 상태 보면서 조정하는건 언급 안됨

D. 시간으로 하는 건 단순 예약 스케일

과거 사용량 기반 예측 → Predictive Scaling

현재 사용량에 따른 반응 → Target Tracking Scaling

이걸 통해 예측도 하고 지금 상태로 늘리고 줄이고가 가능

15. RDS의 자동 백업 기능을 활용하여 운영 오버헤드 최소화 + 매일 백업/30일 보관 충족시키기

  • RDS
  • 매일 백업
  • 30일간 보관
  • 운영오버헤드 최소화

정답B: 자동 백업 기능을 활성화하고 보존 기간을 30일로 설정

  • RDS는 자동으로 매일 스냅샷(백업) 생성
  • 보존 기간을 30일로 설정하면 자동으로 삭제 관리도 함
    • 운영 오버헤드 최소

오답 노트

A. 람다 코드를 직접 짜야하는 것부터 운영 오버헤드 + 30일간 보존에 관한 내용 없음

C. 시스템 관리자 유지 관리 기간은 패치 및 업그레이드 시간 관련된 것

백업 주기 보존 설정과 무

D. CLI로 수동 이건 오버헤드 최강

매일 백업 + 지정된 기간 보존은 RDS 자동 백업 + 보존 기간 설정으로 자동화

16. 수요 급증 시 EC2 빠르게 Auto Scaling 그룹에 프로비저닝하기 위해 초기 대기 시간 줄이기위한 솔루션

  • EC2 인스턴스를 빠르게 프로비저닝
  • 대규모 AMI 사용, Auto Scaling 구성
  • 빠른 부팅, 빠른 이미지 생성/사용

정답B: 스냅샷에서 EBS 빠른 스냅샷 복원을 활성화

  • 일반적인 EBS 스냅샷 이용은 Lazy loading으로 인해 부팅 지연 발생
  • 빠른 스냅샷 복원(FSR)을 활성화하면 이미 프리워밍 되어 빠르게 부팅 가능

AMI를 이 스냅샷으로 만들어 Auto Scaling에 등록하면 빠르게 프로비저닝 가능

A. 수동으로 register-image → 운영 오버헤드 큼

  • Step Functions, Auto Scaling과 연결하려면 직접 구성 필요 → 시간 소요

C. Data Lifecycle Manager은 스냅샷/AMI의 정기적 생성 및 라이프사이클 관리 가능하지만 실시간 확장 대응, 빠른 부팅과는 관련 없음

D. 이건 백업 자동화지 빠른 프로비저닝과는 상관없음

Data Lifecycle Manager는 EBS 스냅샷 및 AMI를 일정에 따라 자동 생성 보존 삭제 하는 서비스

  • 백업 자동화 + 비용 최적화 목적

AMI EC2 인스턴스를 시작할 때 사용하는 머신 이미지 템플릿임

여기에는 OS는 물론 설정들과 설치된 앱들이 포함되어 잇음

그니까 바로 이걸 설치하면 동일한 환경에서 시작할 수 있는 것

스냅샷은 AMI과 동일하지만 백업용이고 여기서 스냅샷을 AMI로 만들 수 잇고 그럼 배포하기도 용이해

17. S3 버킷에 저장된 대용량 데이터를 유럽의 마케팅 회사와 공유하면서도, 데이터 전송 비용을 최소화

  • S3 원본은 미국
  • 3TB 대용량 + 계속 증가 예정
  • 유럽 마케팅 회사와 공유 → Cross-region 간 접근
  • 데이터 전송 비용 낮추기 원함
  • 직접 접근보다 간접적 저비용 공유 방식

회사는 전송비용을 가능한 한 낮게 하려고 함

이는 다른 리전에 복제를 하든지의 가용성 문제가 아님

단지 저비용을 목적으로함

그렇다면 그냥 요청자에게 비용을 전가하면 됨

답: A

18. 전 세계 고객 대상 웹사이트에서 다양한 버전 콘텐츠 제공할지

  • 전 세계 고객 대상 → CDN 필요
  • 다양한 버전의 콘텐츠 제공 → 조건부 라우팅/필터링 필요
  • User-Agent 기반 → 모바일/브라우저 종류에 따라 다르게 처리 필요

A. Cloudfront에 캐싱

C. 람타 엣지로 클라우드 프론트 단에서 분기 시키기

B. NLB + 호스트 헤더 설정

  • LNB는 L4 수준 로드 밸런서
    • HTTP 헤더 기반 조건 분기 불가능
  • Host 헤더 설정은 ALB에서만 가능

D/E: Global Accelerator + NLB

Global Accelerator는 전 세계에 있는 사용자 트래픽 최적의 리전에 라우팅 해줌

  • 콘텐츠 버전 구분/헤더 기반 분기 기능은 없음
  • NLB 역시 HTTP 못 봄

19. AWS로 마이그레이션한 이후 운영팀이 담당해야 할 관련 업무(신유형)

  • ECS, RDS, Direct Connect 사용 → 완전관리형 기반 인프라임
  • 운영 팀의 관리 영역 → 사용자가 직접 관리해야하는 것들이 뭔지

B. RDS 인스턴스 생성 및 예약, 유지 관리 기간 구성

RDS는 완전관리형 서비스이지만,

  • 인스턴스 생성, 예약 인스턴스 구매, 유지보수 시간 설정은 고객이 설정함

C. ECS의 로그 관리, 패치 관리, 소프트웨어 요소 구성

  • ECS는 관리형이지만, 컨테이너 내부 애플리케이션은 직접 관리해야함
    • 로그, 패치, 미들웨어 설치 등은 운영팀이

F. Direct Connect를 통해 이동하는 데이터 암호화

  • Direct Connect 자체는 암호화 미지원 → 운영팀이 VPN 연결 등 암호화 계층 직접 구성 필요
  • 네트워크 보안 운영 측면의 책임

20. 규제 준수에 따라 특정 리전에서만 AWS VPC 인터넷 연결을 허용하고 나머지 리전은 모두 차단해야할 때 어떻게?

  • 하나의 리저만 사용 가능
  • 다른 리전의 VPC에서 인터넷 연결 불가
  • 정책 기반으로 리전제한 + 인터넷 차단 설정 필요

A. AWS Control Tower + Guardrail로 리전 제한

Control Tower에서 특정 리전을 제외한 다른 리전 사용을 방지하는 가드레일 설정 가능

C. AWS Organizations + SCP(Service Control Policy)

SCP는 조직 내 계정이 특정 리전에서 리소스를 생성하지 못하게 제한 가능

이걸로 나머지 모두 막는 정책 작성 가능함

B. WAF 는 7레이어에서 동작함 특정 국가 지리적 위치에서의 요청을 차단하는 기능

D. NACL + IAM

  • NACL로 VPC 내 트래픽 차단 가능
    • 그러나 리전 기반으로 적용 불가능 → 서브넷단위
  • IAM 정책도 리전 제한 가능하지만 범위나 통제력 부족

E. Config는 상태 감시 및 경고용

차단 못함

리전 단위 제어는 AWS Control Tower 와 Guardrail

21. 세션 데이터를 안정적으로 관리해야 하는 상황에서, EC2가 자동확장 + 세션 유지 → 기계 코드 변경 없이

  • EC2 + Auto Scaling 으로 자주 생성/종료됨
  • ALB 사용 중
  • 세션 데이터(상태) 공유/관리 필요
  • 기계 코드 변경은 없어야함

A. ElastiCache는 세션 데이터를 외부 중앙 저장소에 저장 가능함

  • 자동 확장 중에도 모든 인스턴스는 동일한 세션 저장소를 사용하므로 세션 유지됨
  • 코드 수정없이 세션 라이브러리를 Redis 백엔드로 설정만 하면됨

B. ALB의 세션 선호도(스티키 세션) 사용

  • 단일 인스턴스에 계속 요청을 보내는 방식
  • 인스턴스 종료 시 세션 소실 → 자동확장축소중이니까
  • Auto Scaling엔 적합하지 않음

C. AWS Systems Manager Session Manager

  • 이건 관리자가 EC2 인스턴스에 접근하기 위한 세션 (관리용 세션임)
  • 애플리케이션 사용자 세션 데이터 관리와 무관함

D. AWS STS(Security Token Service)의 GetSessionToken API 작업을 사용해 세션 관리

  • STS는 IAM 권한 관련 임시 자격 증명 발급에 사용됨
  • 로그인 세션이나 애플리케이션 세션 데이터 관리와 관련 없음

IAM 사용자, 역할, 또는 외부 사용자에게 일정 시간 동안 유효한 임시 자격 증명을 발급하는 서비스임

22. Amazon API Gateway를 사용하여 HTTPS 기반의 커스텀 도메인 API 엔드포인트 설정하려함 올바른 설정 절차

  • EC2 + Auto Scaling 으로 자주 생성/종료됨
  • ALB 사용 중
  • 세션 데이터(상태) 공유/관리 필요
  • 기계 코드 변경은 없어야함

A. ElastiCache는 세션 데이터를 외부 중앙 저장소에 저장 가능함

  • 자동 확장 중에도 모든 인스턴스는 동일한 세션 저장소를 사용하므로 세션 유지됨
  • 코드 수정없이 세션 라이브러리를 Redis 백엔드로 설정만 하면됨

B. ALB의 세션 선호도(스티키 세션) 사용

  • 단일 인스턴스에 계속 요청을 보내는 방식
  • 인스턴스 종료 시 세션 소실 → 자동확장축소중이니까
  • Auto Scaling엔 적합하지 않음

C. AWS Systems Manager Session Manager

  • 이건 관리자가 EC2 인스턴스에 접근하기 위한 세션 (관리용 세션임)
  • 애플리케이션 사용자 세션 데이터 관리와 무관함

D. AWS STS(Security Token Service)의 GetSessionToken API 작업을 사용해 세션 관리

  • STS는 IAM 권한 관련 임시 자격 증명 발급에 사용됨
  • 로그인 세션이나 애플리케이션 세션 데이터 관리와 관련 없음

IAM 사용자, 역할, 또는 외부 사용자에게 일정 시간 동안 유효한 임시 자격 증명을 발급하는 서비스임

22. Amazon API Gateway를 사용하여 HTTPS 기반의 커스텀 도메인 API 엔드포인트 설정하려함 올바른 설정 절차

  • ca-central-1 리전
  • API 엔드포인트 URL에 자체 도메인 이름 사용
  • HTTPS 사용 → ACM에서 공인 인증서 필요
  • 인증서는 us-east-1 리전에 있어야함
  • Route 53을 통해 도메인 이름을 DNS로 연결

ACM 인증서가 위치해야 하는 리전

  • Regional API Gateway(HTTP/REST API)
    • 인증서는 해당 리전의 ACM에 있어야 함
  • Edge-Optimized API Gateway(기본값)
    • 인증서는 반드시 us-east-1 리전의 ACM에 있어야 함

API Gateway에서 도메인 연결이 필요한 이유

기본적으로 API Gateway의 URL은 이런 형태다.

https://abc123.execute-api.ca-central-1.amazonaws.com/prod

이걸 서비스 할 순 없으

https://api.company.com

이런식으로 바꿔야함

거기다가 HTTPS 를 사용하기위해선 TLS인증서가 필요함

이걸 생성 및 관리하는게 ACM

만약 사용자가 API Gateway를 자신의 리전에서만 사용하겠다 하면 인증서 또한 자신의 리전ACM에서 관리가능

하지만 Edge-Optimized 만들면 CloudFront 들이 요청을 프록시 해줘 전세계에서 내 api gateway로

이렇게되면 전세계에서 인증서를 사용해야하므로 east의 ACM이 인증서관리함

 

 

'공부일지 > SAA 합격하기' 카테고리의 다른 글

AWS SAA 자격증 3주 준비 후기  (0) 2025.05.21
SAA 모의고사 5차 오답노트  (2) 2025.05.19
SAA 모의고사 4차 오답노트  (0) 2025.05.19
SAA 모의고사 2차 오답노트  (0) 2025.05.17
SAA 문제 풀이 1~30  (0) 2025.05.13

모의고사 2 오답노트

1.

  • 50TB
    • 네트워크로 전송 시 비현실적으로 오래 걸림
      • VPN, Direct Connect, DataSync 힘듬
  • 2주 이내 → 빠른 전송 필요 → 물리적 장치 필요
    • AWS Snowball Edge
  • Site-to-site VPN 이미 존재
    • 있으나 속도 한계 존재 → 대용량 부적합
  • 안전하게 전송 → Snowball Edge는 하드웨어 암호화 + 추적 지원

A. AWS DataSync는 수백 GB ~ 10TB 까지가 적절함

B. 현재 Direct Connect는 없음 즉 설치/설정엔 수 주 ~ 수개월 소요됨 2주는 불가능

D. AWS 스토리지 게이트웨이는 주로 하이브리드 클라우드 환경에서 파일/볼륨/NFS 접근을 위해 사용

→ 대용량 일회성 데이터 이전에는 부적합함

  • AWS Snowball Edge는 수십 TB 이상의 데이터를 물리적으로 안전하게 전송하기 위해 사용됨
  • DataSync는 네트워크 기반 서비스, VPN 환경에서는 대규모 데이터 이전에 비효율적임
  • Direct Connect는 빠른 연결이지만, 구성이 수주 이상 소요됨 급한 작업에 부적합 → 선을 물리적으로 깔야아하니까

2.

  • 고성능 컴퓨팅(HPC)
    • 매우 빠른 처리량 + 낮은 지연
      • FSx for Lustre
  • 병렬 엑세스
    • 동시에 여러 인스턴스에서 처리 → 병렬 파일 시스템 필요
  • 밀리초 이하 지연
    • EFS보다 빠른 성능 필요 → FSx for Lustre

정답: Lustre 스크래치 파일 시스탬 + FSx for Lustre

  • 고성능 병렬 파일 시스템(HPC에 특화)
  • 스크래치 모드는 일시적 작업에 적합(고속 읽기/쓰기, 비용 효율)
  • 처리량 수백 GB/s 이상, 지연 밀리초 미만 제공 가능
  • 수천 개 인스턴스에서 동시에 엑세스 가능

B. Lustre 퍼시스턴스(Persistent) 모드

  • 가능은 함 하지만 이건 장기 보존 목적 → 성능보단 내구성 중심

C,D: EFS는 범용 공유 스토리지로는 좋으나,

지연/처리량/병렬 엑세스 성능이 부족함

  • Amazon FSx for Lustre는 HPC 환경을 위한 고성능 병렬 파일 시스템이다.
  • 스크래치 모드는 일시적 고성능/ 퍼시스턴스 모드는 지속적 내구도
  • EFS는 범용이기에 이런 특화된 작업은 힘듬

핵심 포인트

30일 이후 거의 엑세스 안됨

파일에 즉시 엑세스 가능

4년 보관(긴시간)

비용효율적

즉시 엑세스 수 밀리초 안에 접근 할 수 있으면서, 저렴한 건

S3 Standard-Infrequent Access 가 있고, Glacier Instant Retrieval 이 있다.

하지만 거의 사용하지 않을 경우 가장 비용 효율적인건 글랜시어 쪽이다.

큰틀에서 S3와 글랜시어의 차이는 저장비용과 접근비용의 트레이드오프

글랜시어는 저장비용은 저렴하지만 꺼낼때 드는 비용이 비싸다.

그렇기에 왕창저장하고, 안 꺼내 쓸때 그 진가를 발휘함

3.

  • 중요한 AMI → 복구 불가능 시 서비스 중단 가능
  • 실수로 삭제될 수 있음 → 대비책 필요
  • 복구는 빠르고 자동화 → 사람이 직접 복원 X
  • 운영 오버헤드 최소화 → 자동 백업 또는 분산 저장

정답: B

  • 크로스 계정 백업은 AWS 백업 전략의 기본 중 하나
  • 복구는 다른 계정에서 AMI를 공유하거나 재등록하면 됨
  • 이걸 자동 스크립트 or AWS Backup + 복사 규칙으로 운영 오버헤드 낮출 수 있음

A. AMI의 EBS 스냅샷을 별도 계정에 저장

  • 스냅샷 복사만으로는 AMI 복원 불안정

C. AMI 삭제 시 자동으로 보관되는 휴지통 같은 건 없음

D. AMI는 S3로 직접 업로드 불가

  • AMI는 EBS 스냅샷 + 메타데이터로 구성되며, 삭제 시 복구가 불가능하므로 다른 계정 또는 리전에 복사해두는 것이 권장된다.
  • AMI를 S3로 직접 저장할 수는 없으며, 교차 계정/리전 복사는 CopyImage API 또는 콘솔로 수행 → 운영오버헤드 증가

4.

  • 트래픽 급증이 매우 빠르게 발생 → 순간적인 트래픽 처리능력 필요
  • 트래픽 예측 불가 → Auto Scaling 이나 사전 설정 기반 운영이 어렵
  • 아침엔 사용 거의 없음, 저녁에 몰림 → 변동 크고 비효율 발생 가능성 있음
  • 비용최적화 중요 → 사용한 만큼만 지불하는 구조 선호됨

트래픽 매우 빠르게 발생 + 예측 불가능
보통의 상황이라면 오토스케일링으로 충분하지만, 인스턴스가 늘어나는데는 수분이 걸림 하지만 갑자기 늘어나는 거에는 대응하기 힘듬

그렇기에 온디멘드를 사용하는 것

이건 미리 준비된 걸 바로 트래픽을 받을 수 있기에 즉각적으로 가능

트래픽이 무섭다고 프로비저닝 용량 + 오토 스케일링 하면 매우 비효율적

저녁에만 몰리는 트래픽 때문에 비싼걸 계속 유지할 수는 없는 노릇

온디멘드로 몰릴때만 조금 더 내는 구조로 만드는 것이 유리

5. 온프레미스 FTP 기반 일괄 처리 시스템 AWS로 마이그레이션

먼저 FTP란 File Transfer Protocol의 약자로

인터넷을 통해 파일을 주고받기 위한 표준 통신 프로토콜

SSH 기반 보안 강력히 한게 SFTP 22포트

기존 FTP에 TLS 암호화 추가한게 FTPS 21포트 + 데이터포트

  • FTP 클라이언트에서 수신 → 기존 FTP 호환 유지
    • AWS Transfer Family
      • SFTP, FTPS, FTP를 지원하는 완전관리형 파일 전송 서비스
      • 기업들이 레거시 시스템과 호환되도록 보안 파일 전송을 AWS로 손쉽게 연결할 수 있도록 설계되었음
  • 작은 파일 다수, 주기적 수신 → 이벤트 기반 수신으로 자동 처리
    • S3 + 이벤트 트리거 구조
  • 빠른 수신 , 빠른 처리 ⇒ Glacier 와 같은 느린 스토리지말고 S3 스탠다드로
  • 수신 완료 시 자동처리 → 배치 실행
    • 자동화된 워크플로우 트리거
    • S3 Event + Lambda 또는 AWS Batch
  • 파일 삭제까지 자동화 → 람다 또는 배치 후 작업

A, B: EC2에서 FTP 수동 운영은 운영 부담 큼 또한 EBS, Glacier는 저장 후 트리거 구성 어려움, 실시간 자동화 부적합

C: Transfer Family + EBS + FTP 서버 + Batch

→ S3 대신 EBS 사용은 관리필요함, 자동 삭제 로직 추가 구현

6. RDS 인스턴스 전송 중 암호화

  • RDS에 저장된 데이터는 KMS로 암호화
  • 전송 중 암호화가 되지않고있음

정답: D

루트 인증서를 다운로드하고 RDS 인스턴스 연결 시 인증서를 제공

서버 인증서(RDS가 가진)와 루트 인증서(클라이언트가 가진)

AWS 자체 CA 혹은 ACM이 발급

  • RDS에서 SSL/TLS를 통한 암호화된 연결을 지원
  • 이를 사용하려면 클라이언트에서 AWS 제공 인증서를 다운로드해 연결 시 제공해야함

B: 자체 인증서를 생성해 사용

  • 가능은 함 하지만 RDS는 기본적으로 자체 인증서 업로드 불가 AWS가 제공하는 인증서 사용이 표준임

7. EKS 개발용 클러스터 구성 시 비용 효율성 극대화

  • 개발 전용 EKS 클러스터 필요 → 테스트 실험목적, 프로덕션 아님
  • 복원력을 테스트하기 위한 비정기적 사용 → 항상 X 유휴 시간 많음
  • 비용 효율성 강조
  • 모든 노드가 관리형 → EKS에서 관리형 노드 그룹 사용

여기서 관리형 노드 그룹이란?

EKS가 EC2 워커 노드를 자동으로 생성 패치 삭제 스케일링까지 해주는 기능임 + 장기 실행 시 유리 하지만 운영이 Fargate보다는 어려울 수도 있음

이건 Fargate랑 비슷한 기능인데 fargate는 완전관리형으로 서버리스이다. 눈에 보이는 ec2같은게 없음

비용 최적화는 스팟 인스턴스로 구성하게 하는 것

관리형 노드 그룹을 만들 때 테스트 목적이므로 싼 스팟 EC2로 만들어지게 해도됨

두 그룹을 만드는건 프로덕션과 개발 그룹을 분리할때는 좋지만 여기선 해당안됨

8. 글로벌 사용자 대상, NLB 뒤의 EC2 서비스 지연 최소화

  • 여러 리전에 NLB + EC2 → 다중 리전 아키텍쳐
  • 글로벌 사용자 대상 → 전 세계 지연 최소화
  • 사용자별 지연 줄이기 → 전송 경로 최적화 필요

내가 했던 답

회사의 대규 고객 기반이 있는 다른 지역에 추가 NLB 및 EC2 인스턴스 생성

  • 직접 구성해야하다는 면에서 운영 효율성 증가함
  • NBL은 IP 기반이라 사용자 위치에 따라 가장 빠른 리전으로 자동 유도 안됨

네트워크 지연은 물론 처리가 느려져서 발생할 수도 있음

하지만! 거리가 멀면 네트워크 이동 그 자체의 지연을 무시할 수 없음 처리를 아무리 빨리해도 생기는 지연이 있음

이걸 줄이는게 바로 Global Accelerator이다.

전 세계 엣지 로케이션을 통해 사용자 요청을 가장 가까운 AWS 글로벌 네트워크로 전달

  1. 사용자와 가장 가까운 엣지 로케이션으로 트래픽 유도
  2. 그 후 엣지로케이션에서 연결된 백본망을 통해 이동

→ 백본망이라 빠름 그래서 지연 낮아짐

9. 밀리초 수준 지연 요구, 자주 읽는 데이터에 대한 일회성 쿼리 실행

  • 밀리초 미만 지연 → 매우 빠른 응답 시간
  • 자주 엑세스하는 데이터 → 캐시 활용 시 효율성 높음
  • 일회성 쿼리

캐시로 성능 향상을 노려야함

DynamoDB + DynamoDB Accelerator(DAX)

매우 짧은 시간에 데이터 읽고 일회성 쿼리 실행하고 싶다면

빠르게 가져오는 S3 + SQL으로 분석하는 Athena가 적절

오답인 D는 Kinesis는 대용량 데이터 실시간 스트리밍처리용임 SQL로 조회 분석은 아님

10. AWS Lambda의 초기 지연을 줄이기 위한 전략

  • Lambda + API Gateway 사용 중 → 서버리스 구조
  • 앱 시작 시 대기 시간 길다 → 람다 콜드 스타트 문제일 수 있음
  • 예측가능한 트래픽

람다 콜드 스타트는 초기 요청 시 함수 환경 설정 때문에 대기시간이 생기는 걸 말함

Provisioned Concerrency는 람다 함수 미리 실행 환경을 준비해 두는 것을 말함

특히 이 상황처럼 언제 사용할지 예측이 된다면 예약된 시간에 프로비저닝 동시성을 높이기 위해 예약된 조정을 해 미리 설정해둘 수 있음

A. API 게이트웨이 조절 한도는 처리량을 높이기 위한 방법

C. 경보를 통해 하는건 갑작스럽게 생길때 지금은 예측 가능함

D. 처리속도가 증가하는 방법임 콜드 스타트 해결방법은 아님

Lambda Cold Start를 해결하기 위해선 Provisioned Concerrency를 사용하여 항상 준비된 실행 환경을 유지해야함

예약된 시간에만 프로비저닝을 설정하면 비용도 절감하면서 성능 문제도 해결할 수 있음

11. Amazon CloudFront에 사용자 지정 도메인을 연결할 때 사용할 SSL 인증서를 비용 없이 발급받기

보통의 서비스의 인증서는 비용없이 ACM을 통해 발급 받을 수 있다.

하지만 CloudFront의 경우에는 미국 동부 리전(us-east-1)에서 인증서를 요청하거나 가져와야 무료이다.

CloudFront의 관리 인프라가 us-east-1에 기반하고 있기 때문이라고 한다.

12. 공급업체가 SFTP만 지원하고 S3 API는 지원하지 않는 상황, 최소한의 운영 오버헤드로 AWS에 데이터를 업로드하는법

  • 공급업체는 SFTP 기반 전송 → API 사용 불가(FTP/SFTP 프로토콜 유지 필수)
  • 회사는 AWS로 마이그레이션 중
  • 운영 최소화 원함 → 관리형 서비스 선호

SFTP를 유지하면서 S3 API를 원하는 서비스와 연결하고 싶다는거

이렇게 레거시 FTP 환경을 고수하고 싶은 고객을 위한 서비스가 AWS Transfer Family 이다.

고객의 SFTP 환경은 건드리지 않고 중간에 S3로 변환해주는 걸 두는 것

거기다가 서버리스의 완전관리형 서비스이므로 운영오버헤드 현저히 낮음

A. AWS Database Migration Service 사용

이건 데이터베이스 마이그레이션 전용/ 지금 하는건 전송 서비스

C. 인스턴스를 만들라는건 운영 오버헤드 늘리는 일

D. SMB는 다른 프로토콜이라 고객의 요구사항과 맞지 않음

13. Apache + PHP + Redis 기반 웹 애플리케이션을 AWS의 관리형 서비스 기반으로 재설계하면서 가용성, 확장성, 비용 효율성을 만족 시켜라

  • Apache + PHP 웹 서버 → 정적 콘텐츠 제공하는 역할 → S3 + CloudFront로 대체가능
  • Redis → PHP 애플리케이션 세션 저장용 → ElastiCache Redis로 대체가능
  • EC2로 직접 운영 중 → 완전관리형으로 마이그레이션 원함
    • ECS, Fargate, ElastiCache

A. Elastic Beanstalk는 편리 하지만 EC2 기반이라 운영 부담 존재 고객은 완전관리형을 원함

B. 람다로 정적콘텐츠 제공하는건 비효율,

여기서 나오는 API Gateway는 HTTP 요청을 받아 백엔드로 연결해주는 완전관리형 API 프록시 서비스임 NGINX 의 완전관리형 서비스

API Gateway REST API는 여기에 REST API 기반으로 요청을 받는것일 뿐

거기에 CORS 설정이 필요한 건 클라이언트 (뷰 같은 거)의 주소와 api gateway의 주소가 다르면 CORS 정책 적용됨 이걸 처리하는 거

람다는 무상태 함수임 상태저장하려면 레디스 같은 게 필요

자주 등장하는 PHP란

동적 웹페이지를 만들기 휘한 서버 사이드 스크립트 언어

HTML에 삽입하는거 JSP 같은 거지

정답은 S3 + CloudFront(정적콘텐츠) + Fargate(자동으로 관리) + ECS(컨테이너환경) + ALB + ElastiCache(세션관리)

14. IAM 기반 인증을 통해 HTTPS 경로로 AWS Lambda로 구성된 마이크로서비스를 호출할 수 있도록 구성

  • Lambda 함수로 Go 마이크로서비스 작성 → 서버리스 마이크로서비스
  • 클라이언트가 HTTPS를 통해 접근 → HTTPS 엔드포인트 필요
  • IAM으로 인증된 사용자만 접근 → AWS_IAM 인증 필요
  • 효율적인 운영방식 → 관리형 / 비용 효율

HTTPS 엔트포인트를 위해 API Gateway REST API 사용 + 람다로 서버리스 구현 + API에 IAM 인증 활성화

API에 IAM 인증 활성화 한다는건

해당 API를 호출하기 위해서 적절한 자격증명이 있어야 한다는 뜻

B. 람다로만 API 관리하면 힘듬

C. Lambda@Edge는 CloudFront 요청 응답 흐름 조작용임 API 요청 처리용이 아님

D. CloudFront Functions는 간단한 헤더/쿼리 수정 용도임

백엔드 호출은 직접 하지 못함

15. 사진 호스팅 서비스에서 다양한 국가의 사용자가 업로드하고 조회하는 사진을 비용 효율적으로 저장 + 메타데이터 조회 성능까지 고려하기

  • 사진 1장당 최대 20MB → 대용량 정적 파일임 객체 스토리지 필요함
  • 일부 사진은 수개월간 자주 조회 → 접근 패턴 불규칙함 자동 계층 전환이 필요
  • 사진 메타데이터 활용 → 별도 DB에 메타데이터 저장 필요
  • 비용 효율 중요 + 성능도 고려 → 스토리지 전환 + 빠른 메타 쿼리 필요

불규칙한 접근이면 각 객체마다 자동으로 계층이동하는 S3 Intelligent-Tiering이 적합함

A. 대용량 사진을 DynamoDB에 저장하는건 적합하지않음

C. S3 계층 이동하는 걸로 비용절감은 가능하지만 불규칙적인 접근이라 이렇게 일관된 이동은 적합하지 않음

D. 글랜시어는 말도 안되고

16. HPC 환경에서 수백 개의 EC2 인스턴스가 1ms 이하 지연으로 공유 데이터에 동시 엑세스하기

  • 수백 개 EC2 인스턴스 → 대규모 병렬 컴퓨팅 환경
  • 공유 파일 시스템 필요 → 다수 인스턴스에서 동시에 데이터 엑세스 필요
  • 1ms 이하 지연 요구 → 매우 빠른 응답 속도 필요(저지연 고처리량)
  • 후처리도 포함 → 쓰기/읽기 모두 고성능 요구

정답은 Amazon FSx for Lustre

이게 바로 고성능 컴퓨팅을 위한 공유 파일 시스템

높은처리량, 병렬처리, 저지연 모두를 만족함

A. EFS는 파일 공유 시스템은 맞지만 범용이라 HPC에서는 부족함

17. 복구 빈도는 거의 없지만, 복구 시에는 최대 5분 이내에 사용할 수 있어야하며 가장 저렴하게 저장까지 되어야하는 스토리지 구성

먼저 빈도가 적고 저장이 저렴한 걸 찾음

→ 글랜시어 계열

거기에 5분이라는 짧은 시간에 접근할 수 있어야한다’

→ Expedited Retrieval

18. AWS Systems Manager Parameter Store에 암호화된 DB 사용자 정보를 저장하고, EC2 인스턴스에서 해당 파라미터를 안전하게 읽도록 구성할 때 필요한 IAM 및 KMS 접근 제어 설정은?

RDS DB 인스턴스에 접근하려고하는 EC2가 파라미터 스토어에 접근하고 복호화 하는 것까지 해야함 그걸위해 IAM으로 적절한 권한을 부여 받아야함

AWS Systems Manager Parameter Store란?

Parameter Store = 설정값(키-벨류) + 보안 저장소(KMS 암호화 가능) + 버전 관리까지 되는 중앙 설정 서비스

디비 비번, API 키, 환경 변수, 앱 설정 같은 민감 정보를 관리해주는 것

Parameter Store 읽기권한 + KMS 복호화 권한 있는 IAM 역할을 EC2에 부여하는 것이 정답

C,D 신뢰관계는 EC2와 파라미터 스토어가 맺어야함

신뢰관계란

AWS 리소스가 IAM 역할을 사용할 수 있도록 허용하는 관계임

역할을 부여받을 수 있는 관계 AssumeRole 로 역할을 받아올 수 있는 관계

19. 게임 시스템에서 이벤트 순서 보장하는 AWS 이벤트 기반 시스템 요구

  • 게임 시스템의 이벤트 순서 보장
  • AWS 이벤트 기반 시스템 필요
  • 게임이란 도메인 → 여러 시스템/사용자에게 동시에 전달 필요 → SNS 최적
  • 매치메이킹, 리더보드 시스템 등 → 빠르고 신뢰할 수 있는 이벤트 순서 보장 → FIFO

⇒ SNS + FIFO

SQS를 사용하려면 여러 큐를 만들고 복사해야함

비동기 작업이라 유리할 수도 있음

SNS는 메시지를 브로드캐스트 하는 것(1대다)

  • 하나의 이벤트를 여러 수신사에게 동시에 전달
  • 빠르게 여러 시스템에 알릴 때 유용
  • 순서와 신뢰성이 중요할 경우 → SNS FIFO + SQS FIFO 조합

SQS는 메시지를 큐에 쌓아서 소비자가 꺼내 처리하는 것(1대1 혹은 1대다)

  • 작업을 큐에 넣고 소비자가 꺼내 처리하는 비동기 처리 패턴
  • 순서와 중복 방지가 중요할 경우 → SQS FIFO

순서 보장 & 처리 보장 정리

기능 SNS (표준) SNS FIFO SQS (표준) SQS FIFO
순서 보장 ❌ 불가능 ✅ 가능 ❌ 보장 안됨 ✅ 가능
중복 방지 ❌ 없음 ✅ 가능 (deduplication ID) ❌ 없음 ✅ 가능
1회만 처리 ❌ 최대 보장 아님 ✅ ❌ (At-Least-Once) ✅ (Exactly-Once)
지연 전송 지원 ❌ ❌ ✅ ✅
대기 시간 있음? ❌ (푸시 방식) ❌ ✅ (폴링 or long polling) ✅

20. 여러 AWS 계정을 사용하는 회사에서 재무 팀이 RDS 비용을 최적화하기 위해 AWS Trusted Advisor를 통해 적절한 계정을 사용해 RDS 비용 관련 권장 사항 확인 요구

  • 여러 AWS 계정 보유 → 비용 최적화는 적절한 계정 수준 기준으로 수행되어야함
  • RDS for Oracle 온디멘드로 사용 중 → 비싼 서비스임 최적화 필요
  • 재무팀은 Trusted Advisor를 통해 권장사항 및 사용률 확인해서 최적화

B. 통합 결제 계정의 Trusted Advisor 권장 사항을 사용하여 모든 RDS 인스턴스 확인을 동시에 확인함

  • AWS Organizations를 구성한 경우, 관리 계정에서 전체 계정의 Trusted Advisor 권장 사항 확인할 수 있음
  • 모든 계정에서 RDS 인스턴스 사용 내역을 한 눈에 파악 가능
  • 비용 최적화, 예약/유휴 인스턴스 여부 확인에 적합

D. Amazon RDS 유휴 DB 인스턴스에 대한 Trusted Advisor 검사를 검토

  • Trusted Advisor는 유휴 RDS 인스턴스를 식별하여 사용되지 않는 인스턴스의 종료 또는 다운사이징을 권장함
  • 비용 최적화에서 가장 실질적인 절감 방안

오답노트

A. RDS 인스턴스가 실행 중인 계정만 TA로 확인?

모든 계정을 일일이 확인하기 힘듬

C. 예약 인스턴스는 일단 어떤 필요에 때문에 예약한 것

이걸 줄이는 건 면밀한 검토 필요

유휴 인스턴스는 켜져있는데 안 쓰고 있는 것이니까 이걸 줄이는 건 합리적

E. RedShift는 지금 RDS와 거리가 멈

21. Amazon EC2 기반의 데이터베이스를 고가용성 환경으로 구성 + 중단 이벤트 발생 시 자동 장애 조치(Failover)가 가능함

  • 데이터베이스는 EC2 위에 구축됨
    • RDS가 아닌 EC2 기반 DB임
  • 가용성이 높아야 함
    • Active-Active 혹은 Active-Passive 구성 필요
  • 중단 시 자동 장애조치 필요
    • 자동화된 Failover 요구됨

정답: A 동일한 AWS 리전의 서로 다른 가용 영역에 EC2를 구성 + EC2 간 복제 구성(이게 Active-Active혹은 passive)

  • 클러스터링 구성 → Failover
  • 단일 리전에서 짧은 지연으로 이중화 구성

B: AMI는 정적 이미지일 뿐, 장애 조치 자동화 구조 아님

CloudFormation은 인프라 생성 도구

C: 서로 다른 리전에 EC2 인스턴스 5개? 이건 과도한 설정임

22. Amazon RDS를 사용하는 서비스형 애플리케이션 + 예기치 않은 트래픽 증가에도 애플리케이션 코드 변경하지 않고, 확장성과 가용성을 유지하는 방법

  • RDS 사용 중 → DB 확장 문제
  • 트래픽 갑자기 증가해서 DB 오류 발생 중
  • 코드 변화 없이 해결

RDS 자체의 가용성도 있긴하다.

  • RDS Multi-AZ
  • 백업, 모니터링, 자동 패치

→ 기본적인 이프라 수준의 고가용성 제공

Amazon RDS Proxy

애플리케이션과 RDS 사이의 연결을 최적화하고 안정화하는 역할

가용성 보다는 DB 연결 관리 성능

  • Connection pooling
    • 새롭게 연결하는게 아니라 연결을 미리 해놓고 나눠주는 것
  • Failover 시 연결 유지
    • 교체되는 타임에도 끊김 없이 서비스 해줌
  • 보안 강화
  • 코드 없이 수정 가능
    • 엔드포인트만 Proxy로 교체하면 됨

A. 최대 연결 수 증가하면 DB에 더 부담

B. 인스턴스 스케일업

수직한계는 한계가 있음

D. 읽기 전용 인스턴스 구매 → 읽기 쓰기 구분 없는 일반 서비스에는 큰 효과가 없음

23. AWS에서 이벤트기반 아키텍처로 마이그레이션 + 분산 , 서버리스 개념 사용해 운영 오버헤드 최소화

  • 이벤트 기반 아키텍쳐로 전환 → 이벤트가 발생했을 때 자동으로 처리하는 시스템 필요
  • 워크플로우는 다양한 측면을 수행 → 여러 단계를 거쳐서 이벤트를 처리해야 하므로 각 단계 자동화

AWS Step Functions: 서버리스 워크플로우 서비스, 다양한 AWS 서비스와 연동해 상태 기계를 생성할 수 있음

Amazon EventBridge: 이벤트 버스를 사용하여 다양한 AWS 서비스 간의 통신을 관리하는 서비스, 이벤트 중심 아키텍처에 적합

뭔가 단계 별로 해야하는데 서버리스를 원한다? 그럼 스텝 펑션

24. Amazon EC2 인스턴스와 ALB를 사용하여 APP 트래픽 분산해 최적

  • ALB가 EC2에 분배 있때 상태 검사 필요

인스턴스 편중때문에 요청 지연이 발생함

편중의 이유는 세션 선호도(고정 세션) 때문임

이걸 비활성화하면 불균형 해결

B. 로드벨런서를 NLB로 바꾸면 더 세세한 조절을 할 순 없음

C. 각 가용 영역의 EC2 인스턴스 수를 늘리려도 편중 있으면 다시 발생함

D. ALB 대상 그룹 상태 빈도 체크를 많이 해도 편중이 발생해 문제가 생겨도 다시 발생함

25. 세션 관리 및 데이터 저장

  • EC2, ALB, Auto Scaling → 확장성 및 로드 밸런싱을 활용하여 웹 애플리케이션을 실행
  • 고객 세션 지속적으로 저장해야한다 → 저장소에 저장해야함

A. 세션 선호도는 ALB가 특정 사용자의 요청을 동일한 ec2 인스턴스로 라우팅하는 기능

이는 세션 유실 가능성을 줄여주지만, 특정 인스턴스에 과부하가 걸리거나 해당 인스턴스가 실패할 경우 문제가 발생할 수는 있음

C. Cognito 사용자 풀을 배포해 관리하는 건 사용자 인증 및 권한 부여 하는 서비스임

트랜잭션 중 발생하는 세션 데이터를 저장 관리하는 것은 아님

D. AWS Systems Manager Application Manager는 애플리케이션 운영 및 관리를 위한 중앙 집중식 허브임 세션 관리 기능을 직접적으로 제공하지 않음

이건 인프라 구성과 운영 모니터링을 위한 대시보드 중심 서비스

26.

  • Micro SQL Server → AWS로 마이그레이션
  • 읽기 작업 쓰기 작업 많음
  • 운영 오버로드 줄이려함

A. RDS에 Microsoft sql server와 동일한 DB 엔진을 사용한 SQL Server가 존재함 그렇기에 관리형으로 전환이 쉽게 가능함

오답 D: Aurora가 성능 면에서는 좋지만 MySQL로 마이그레이션을 또 해줘야 해서 오답임

27. Auto Scaling 그룹의 서버 클라 UDP 통신하는 실시간 멀티 게임 + 하루 트래픽 증가 예상

  • 하루 트래픽 증가 → 가용성 + 온디멘드
  • UDP 실시간 멀티게임 → NLB
  • 비관계형 데이터 저장 원함 → DynamoDB

A. 라우트53은 트래픽 분산도 가능하지만 UDP 트래픽 세션 기반으로 분산은 NLB가 탁월

Aurora는 관계형에 특화됨 비정형 비관계 경우는 Dynamo가 좋다.

C. 트래픽 분산을 위해 NLB ok

Aurora Global DB

재해 복구 및 글로벌 읽기 확장 시나리오에 최적화된 관계형 데이터베이스

글로벌 데이터베이스는 약간의 지연 시간이 발생해 실시간엔 어울리지 않는다.

D. ALB로 X UDP 세세한 라우팅 불가

28. EBS KMS를 사용해 저장 데이터 암호화되었는지 확인 + 암호 순환 제어

  • 암호키 순환 → 키 로테이션
  • 운영 오버헤드 감소
  • EBS를 KMS로 암호화
  • 회사가 암호화 키의 순환을 제어할 수 있어야 한다.

→ 즉 회사가 키를 가지고 제어권을 가져야함

고객 관리형 키를 통해 암호화해야함

KMS 키 유형 (핵심 구분)

키 유형 생성 주체 제어 가능 여부 용도
AWS 관리형 키 (AWS Managed Key) AWS 자동 생성 ❌ 제어 불가 S3, EBS 등에서 자동 암호화 시
고객 관리형 키 (Customer Managed Key) 고객 요청 → AWS 생성 ✅ 완전 제어 가능 직접 암호화, 로깅, 권한 설정 등
외부 키 (BYOK) 고객이 외부에서 생성 → 가져옴 ✅ 직접 제어 보안 규제 엄격한 환경
CloudHSM 키 고객이 직접 HSM에서 생성 ✅ 직접 제어 가장 높은 보안 요구

만약 키관리를 전부 관리형에 맞기고 싶다면 AWS 관리형 키를 사용하면됨

29. API Gateway 보안 강화 + 속도 기반 요청 제어 + 비용/오버헤드 최소화 아키텍쳐

  • HTTP flood → DDoS 계열 공격 → WAF, rate limit 필요
  • 요청 수 증가 → 속도 기반 제어 필요
  • 공공 인터넷 노출오류 → WAF + CloudFront 보호 계층 고려
  • 오버헤드 최소화

A. TTL은 캐싱전략임 얼마나 캐싱할지에 관한것

C. CloudWatch는 단지 모니터링용 대응이 자동화되는거아님

D. Lambda로 속도 제한은 너무 복잡함

Web Application Firewall

웹 애플리케이션에 대한 공격 트래픽을 필터링하고 차단할 수 있는 L7 보안 서비스

기능 설명
SQL Injection, XSS 탐지 웹 공격 유형 필터링 가능
IP 기반 차단 특정 IP나 국가의 요청 차단
속도 제한 (Rate-based) 일정 시간 안에 너무 많은 요청을 보내는 IP 자동 차단
패턴 기반 규칙 특정 URI, Header, QueryString 기반 차단 가능

http/s 요청이 오는 곳에 사용

속도 기반 규칙(Rate-based rule)이란

특정 IP가 지나치게 빠르게 요청을 보내면 자동으로 차단

  • DDoS 완화 (HTTP floor 도 같은 원리로 방)
  • 비정상적 사용제한

30.

  • 작업은 매일 1회 실행 → 예약작업 → 스케줄러 필요
  • 최대 2시간 동안 배치성 데이터 처리 작업 → 짧지 않음 → 람다 부적합
  • 작업이 중단되면 안됨 → 신뢰성 있
  • 비용효율적

작업이 중단되면 안된다가 왜 컨테이너환경과 이어지는가

컨테이너는 기본적으로 휘발성 하지만 Kubernetes, ECS, Fargate 같은 오케스트레이션 시스템이 안정성과 복구성을 제공

EC2가 더 위험한 이유

  • 수동 관리
  • OS 수준의 문제
  • 인스턴스 장애

A. EC2 예약 인스턴스 + cron

  • EC2 계속 켜져 있거나 중지를 해줘야함

❗중요: 예약 인스턴스가 몇 시 몇 분에 사용할게 하는 예약이 아닌 1년 2년 단위로 계속 빌리는 걸 예약 인스턴스라고 함

  • CRON으로 하는 것도 중간에 실패 시 다시 시작은 따로 해줘야함

B. 람다는 2시간 무리

C. Fargate + ECS 결합 후 이벤트 브릿지 사용 정답

  • 서버유지 필요없음
  • 예약 스케쥴링
  • 실패 시 ECS가 복구해서 완료시켜줌

D. EC2 + ECS

  • 운영복잡
  • EC2 인스턴스 크기에 따라 고정 발생
  • 스스로 워커노드를 등록하고 관리해야함

'공부일지 > SAA 합격하기' 카테고리의 다른 글

AWS SAA 자격증 3주 준비 후기  (0) 2025.05.21
SAA 모의고사 5차 오답노트  (2) 2025.05.19
SAA 모의고사 4차 오답노트  (0) 2025.05.19
SAA 모의고사 3차 오답노트  (0) 2025.05.18
SAA 문제 풀이 1~30  (0) 2025.05.13

Q1

회사는 여러 대륙의 도시에서 온도, 습도, 기압 데이터를 수집하고 있습니다. 각 사이트마다 하루 평균 500GB의 데이터를 수집하며, 모든 사이트는 고속 인터넷 연결을 가지고 있습니다.

회사는 이 모든 데이터를 가능한 한

빠르게 단일 Amazon S3 버킷에 집계하길 원하며,

운영 복잡성은 최소화해야 합니다.

이 요구 사항을 충족하는 최선의 방법은 무엇입니까?

포인트: S3 버킷 사용, 운영 복잡성은 낮게, 500GB 정도 생

S3 Transfer Acceleration

CloudFront 엣지 위치를 사용해 글로벌 사용자의 업로드 속도 향상하는 기술

멀티파트 업로드

대용량 파일을 쪼개 병렬 업로드해 전송 속도 및 복원력 향상

S3 교차 리전 복제

S3 객체를 다른 리전으로 자동 복사하는 기능(운영 복잡성 증가)

AWS Sonwball Edge Storage Optimized 디바이스 작업

테라바이트 급 데이터를 AWS로 물리적으로 이송 → 500기가는 불필요\

EBS Snapshot

EBS 볼륨 백업을 위한 스냅샷 기능. 복원 시간이 필요하고 S3랑은 무관

Q2

회사는 독점 애플리케이션의 로그 파일을 분석할 수 있는 기능이 필요합니다. 로그는 Amazon S3 버킷에 JSON 형식으로 저장되어 있습니다. 쿼리는 단순하고 필요할 때마다 실행됩니다. 솔루션 아키텍트는

기존 아키텍처에 최소한의 변경만으로 분석을 수행해야 합니다.

운영 오버헤드가 가장 적은 방법은 무엇입니까?

기존 아키텍처에 최소한의 변경만으로 → 운영 복잡성 증가 원하지 않음

 

A. Amazon Redshift를 사용해 모든 로그를 적재하고 SQL 쿼리 실행

데이터 적재 및 스키마 설계 필요, 비용 증가 운영 복잡

B. Amazon CloudWatch Logs에 로그 저장 후 콘솔에서 SQL 쿼리 실행

C. Amazon Athena를 사용해 S3의 데이터를 직접 쿼리

D. AWS Glue와 Amazon EMR을 활용한 Spark 클러스터에서 쿼리 실행

Redshift

완전관리형 데이터웨어하우스, 페타바이트 규모 데이터 분석

사용 예시: OLAP 분석, BI 툴 연동

장점

고성능 분석

S3, DynamoDB 연동 + S3 데이터 직접 쿼리 가능

단점

클러스터 프로비저닝 필요 → 서버리스 아님

비용이 비쌈

CloudWatch Logs

로그 수집, 모니터링, 실시간 스트리밍 처리까지 지원하는 중앙 로그 관리 서비스

장점

EC2, Lambda, VPC 등 다양한 서비스 로그 집계

Log Insights로 실시간 검색 및 시각

OpenSearch와 연동 가능

단점

오래된 로그 장기 보관에 비용 비효율적

S3의 로그를 CloudWatch로 이전해야 하므로 구조 변경 필수

Amazon Athena

S3의 데이터를 SQL로 분석하는 서버리스 쿼리 서비스

S3에 저장된 파일을 직접 SQL로 쿼리할 수 있는 것

기존 구조 변경없이 즉시 사용 가능 + 운영 오버헤드도 적다

JSON 형식도 지원하며, 복잡한 분석 없이 간단한 on-demand 분석

장점

인프라 관리 불필요, 쿼리 실행 수에 따라 비용청구

Parquet, ORC 등 압축 포맷 지원으로 비용 절감

Glue와 통합 가능

단점

복잡한 쿼리 및 대규모 처리 시 성능 한계

키워드: SQL 쿼리로 S3 분석, 온디멘드, S3 구조변경 필요없음, 운영 복잡성 비용 감소

AWS Glue

S3 및 다양한 데이터 소스로부터 ETL(추출 변환 적재) 수행 가능한 서버리스 데이터 통합 서비스

장점

크롤러를 통한 자동 스키마 인식

Athena와 통합 가능한 데이터 카탈로그 생성

JDBC로 RDS/Redshift 등 다양한 소스 지원

단점

작업 지연 발생 가능(즉시 보다 배치 지향)

운영/비용 증가

AWS EMR

Apache Hadoop, Spark, Hive, Presto 등을 AWS 상에서 실행하는 빅데이터 처리 플랫폼

장점

대규모 데이터 분석에 최적화

EC2 기반으로 커스텀 설정 가능

단점

클러스터 수동 운영 필요

서버리스 아님

운영/비용 증가

Q3

회사는 AWS Organizations를 사용하여 여러 부서의 여러 AWS 계정을 관리합니다. 관리 계정에는 프로젝트 보고서가 포함된 Amazon S3 버킷이 있습니다. 회사는 이 S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한하려고 합니다.

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. 조직 ID에 대한 참조와 함께 aws:PrincipalOrgID 전역 조건 키를 S3 버킷 정책에 추가합니다.

PrincipalOrgID 는 AWS Oraganization의 조직 ID를 기준으로 접근을 제한하는 조건 키

한 줄 정책으로 조직 내 모든 계정 사용자에 대한 접근을 허용할 수 있어 운영 오버헤드가 최소

B. 각 부서에 대한 조직 단위(OU)를 만듭니다. aws:PrincipalOrgPaths 전역 조건 키를 S3 버킷 정책에 추가합니다.

조직 단위를 만들어서 사용하지만, OU마다 따로 관리해야 하므로 오버헤드 증가

C. AWS CloudTrail을 사용하여 계정 이벤트를 모니터링하고 S3 버킷 정책을 업데이트합니다.

비효율적이며 자동화 되지 않음, → 운영 오버헤드 큼

D. 각 사용자에게 태그를 지정하고 aws:PrincipalTag 조건 키를 버킷 정책에 추가합니다.

매 사용자마다 태그 관리 필요, 정책도 복잡해지고 운영 오버헤드 큼

AWS CloudTrail

AWS 계정 내에서 발생하는 모든 API 호출을 기록하는 서비스

장점

API 호출 감사를 통한 보안 로그 추적

S3/CloudWatch Logs로 자동 연동 가능

조직 단위 설정 시 조직 전체 계정 추적 가능

단점

설정만으로는 리소스 변경 추적 불완전(AWS Config 병행 필요)

AWS Organizations

여러 AWS 계정을 통합 관리할 수 있는 서비스. 루트 계정, 조직 단위, 서비스 제어 정책

S3 버킷 정책

IAM 정책처럼 JSON 형식으로 작성되며, S3 리소스에 대한 접근 권한을 정의함

장점

특정 IP, 계정, 조건자 기반 제어 가능

교차 계정 액세스 허용 가능

단점

복잡한 로직이 많아질 경우 관리 어려움

IAM 정책과 충돌 시 디버기 어려움

aws:PrincipalOrgID

IAM 정책 조건에서 사용되는 전역 조건 키.

특정 조직 ID에 속한 사용자나 역할만 허용할 수 있음 → 한 번에 관리할수있음

aws:PrincipalOrgPaths

요청 주체가 속한 조직 경로 기반으로 접근 제어

이건 특정 OU또는 하위 OU만 선택적 제한 가능

Q4 애플리케이션은 VPC의 Amazon EC2 인스턴스에서 실행됩니다

한 애플리케이션이 VPC 내 EC2 인스턴스에서 실행 중이며, Amazon S3 버킷에 저장된 로그를 처리합니다.

EC2 인스턴스는 인터넷 연결 없이 해당 S3 버킷에 접근해야 합니다.

다음 중 Amazon S3에 프라이빗 네트워크 연결을 제공하는 것은 무엇입니까?

VPC 내부 EC2 인스턴스, 인터넷 연결 없이 S3 버킷 접근 → VPC Gateway

A. S3 버킷에 대한 게이트웨이 VPC 엔드포인트를 생성한다 B. Amazon CloudWatch Logs로 로그를 스트리밍하고 S3로 내보낸다

로그 스트리밍 경로를 바꾸는 것으로, 문제 요구사항이랑 다름 C. EC2 인스턴스에 인스턴스 프로파일을 생성하여 S3 접근을 허용한다

인스턴스 프로파일은 인증 권한만 제공, 네트워크는 아님 D. PrivateLink가 설정된 API Gateway를 사용해 S3 엔드포인트에 접근한다

PrivateLink는 Interface VPC Endpoint에 해당 S3는 Gateway Endpoint임

VPC Endpoint(가상 프라이빗 연결)

AWS 서비스와 인터넷을 거치지 않고 통신할 수 있는 VPC 내부 연결

Interface VPC Endpoint: 대부분의 AWS 서비스 지원(ENI로)

장점

PrivateLink 기반으로 대부분 서비스 연결 가능

REST API와 같은 애플리케이션 통신도 가능

단점

요금 발생

서브넷마다 ENI 생성 필요

Gateway VPC Endpoint: S3, DynamoDB 전용

장점

비용 효율적(무료)

NAT gateway 불필요

단점

S3와 DynamoDB 만 가능

privateLink

다른 VPC의 서비스에 프라이빗하게 연결하는 기술

장점

VPC 피어링 없이도 서비스 연결

접그을 서비스별로 제한 가능

단점

ENI 기반이라 복잡성 및 비용 있음

EC2 Instance Profile

EC2 인스턴스에 IAM 역할을 할당하여 코드에서 자격 증명 없이 AWS 서비스 접근 가능하게 함

IAM ROLE + Instance Profile

장점

앱에서 AWS 자격 증명 노출 없음

자동으로 임시 자격 증명 제공

단점

역할 변경 시 재시작 필요

“EC2 Instance Profile은 IAM Role을 인스턴스에 할당하여 자격 증명 없이 AWS API에 접근 가능하게 합니다”

Q5 사용자 업로드 문서를 EC2 + EBS 기반 웹 애플리케이션에서 관리 중

회사는 사용자 업로드 문서를 Amazon EBS 볼륨에 저장하는 단일 Amazon EC2 인스턴스에서 웹 애플리케이션을 호스팅하고 있습니다.

더 나은 확장성과 가용성을 위해 이 아키텍처를 복제하여 **다른 가용 영역(AZ)**에 두 번째 EC2 인스턴스와 EBS 볼륨을 생성하고 Application Load Balancer 뒤에 배치했습니다.

이 변경 이후, 사용자들은 웹사이트를 새로고침할 때마다 문서의 일부나 서로 다른 하위 집합만 보이지만, 모든 문서를 한 번에 보지 못하는 현상이 발생했습니다.

모든 사용자가 항상 모든 문서를 볼 수 있도록 하려면 무엇을 해야 합니까?

핵심

두 인스턴스의 EBS가 서로 독립된 스토리지

→ 파일 공유 시스템을 사용하는 것 EFS(Elastic File System) 존재

여러 인스턴스에서 동시에 마운트 할 수 있는 분산 네트워크 파일 시스템 가용성 확정성 모두 보장

여러 AZ에 존재하는 EC2도 안정적인 파일공유가능

A. 두 EBS 볼륨에 모든 문서를 복사합니다.

수동으로 데이터 복사는 동기화 어렵고 오버헤드 아주 크게 발생

B. 문서가 있는 서버로 사용자를 유도하도록 ALB를 구성합니다.

사용자를 특정 서버로 유도하는 건 로드밸런싱의 목적에 반함

C. 두 EBS 볼륨의 데이터를 Amazon EFS로 복사하고, 애플리케이션이 새 문서를 EFS에 저장하도록 수정합니다.

D. 두 서버 모두에 요청을 보내도록 ALB를 구성하고 올바른 서버에서 문서를 반환합니다.

양쪽 서버 모두에 요청하면 성능 저하

Amazon EFS

NFS 기반의 완전관리형 공유 파일 시스템, 다수의 EC2 인스턴스에서 동시에 마운트 가능

장점

멀티 AZ 지원: 가용성과 내구성 우수

리눅스 기반 다중 인스턴스에서 동시 마운트 가능

서버리스 + 확장성

단점

비용이 상대적으로 높음

윈도우에서는 FSx 사용 필요

EBS

EC2 전용 블록 스토리지. 한 AZ 내에서 EC2 인스턴스에 연결 가능

AZ 종속적인 블록 스토리

장점

고성능, 낮은 지연 시간 저장소 제공

스냅샷 기능으로 백업 가능

암호화 지원

단점

AZ 제한: 단일 AZ에서만 사용 가능

여러 EC2 간 공유 볼구

ALB(Application Load Balancer)

7계층 기반의 로드밸런서. 라우팅 및 WAF 연동 지원

장점

헤더, 경로 기반 라우팅 지원

상태 확인 통해 정상 인스턴스에만 트래픽 전달

AWS WAF, CloudFront 등과 통합 가능

단점

단순 TCP 수준 로드밸런싱은 NLB가 더 적합

멀티 AZ 아키텍쳐

동일 리전 내 2개 이상의 AZ에 리소스를 배치하여 가용성 확보

EC2, RDS, EFS 등 AZ 간 이중화 배치

Auto Scaling, ALB와 함께 사용 시 고가용성 극대

Q6. 대용량 비디오 파일을 최소한의 네트워크 대역폭으로 S3에 마이그레이션

회사는 **NFS(Network File System)**를 사용하여 온프레미스 NAS(Network Attached Storage)에 대용량 비디오 파일(1MB~500GB)을 저장하고 있으며, 총 스토리지는 70TB입니다.

이제 이 데이터를 Amazon S3로 마이그레이션하려고 합니다.

요구 사항은 다음과 같습니다:

  • 가능한 한 빠르게 마이그레이션
  • 최소한의 네트워크 대역폭 사용

어떤 솔루션이 가장 적합합니까?

A. IAM 역할과 AWS CLI를 사용해 로컬에서 S3로 파일을 직접 복사

일반적인 복사는 오래걸리고 대역폭도 많이 잡아먹음

B. Snowball Edge 장비를 주문해 오프라인으로 데이터 전송 후 AWS로 반납

70TB의 경우는 이게 맞음

C. S3 파일 게이트웨이를 배포해 NFS 공유로 연결 후 데이터 전송

S3 파일 게이트웨이는 지속적인 파일 공유용으로 적합, 대규모 마이그레이션은 부적합

D. Direct Connect 연결 후 S3 파일 게이트웨이를 통해 전송

Direct Connect는 고정된 네트워크 대역폭을 확보하는 데는 좋지만, 초기 설정 시간도 오래 걸리고 비용이 높음

S3 File Gateway 온프레미스 애플리케이션이 S3 객체 스토리지를 파일 시스템처럼 사용할 수 있도록 해주는 하이브리드 스토리지 서비스 장점

  • 로컬에서 자주 사용하는 데이터를 캐시에 저장하여 지연시간 최소화
  • SMB, NFS 프로토콜 지원
  • S3 Lifecycle 정책 연동 가능

단점

  • 온프레미스에 게이트웨이 어플라이언스를 배포해야 함
  • 고성능 IO에는 적합하지 않음

시험 포인트 문장

S3를 로컬 파일 공유처럼 지속적으로 자주 사용하려면? → S3 File Gateway

Direct Connect

온프레미스 데이터 센터와 AWS 간에 전용 네트워크 회선을 통해 연결하는 서비스

장점

  • 일관된 네트워크 성능 제공
  • 인터넷 거치지 않음
  • Direct Connect Gateway를 통해 다지역 VPC 연동 가능

단점

  • 설치 및 운영 비용 존재
  • 장애 복구를 위해 VPN 백업 권장

시험 포인트 문장:

  • “Direct Connect는 온프레미스와 AWS 간에 전용 고속 네트워크를 제공하며, Direct Connect Gateway로 여러 리전의 VPC를 연결할 수 있습니다
  • “인터넷 대역폭 부담을 줄이기 위해 백업 트래픽을 Direct Connect로 우회”

Q7. 회사는 대량 메시지를 수집 및 처리하는 아키텍처를 설계하려고 합니다

회사는 들어오는 메시지를 수집하는 애플리케이션을 운영하고 있으며,

수십 개의 애플리케이션과 마이크로서비스가 이 메시지를 빠르게 소비합니다.

메시지 수는 급격하게 변하며, 초당 최대 100,000개까지 증가할 수 있습니다.

회사는 아키텍처를 분리(Decoupling) 하고, 확장성(Scalability) 을 확보하길 원합니다.

어떤 솔루션이 가장 적합합니까?

핵심

대량 트래픽, 빠른 확장, 애플리케이션 분리(Decoupling)

Amazon SNS + 여러 SQS Queue 구독 구조

Producer와 Consumer를 완전히 분리할 수 있으며,

여러 소비자가 병렬적으로 메시지를 읽을 수 있어서 확장성이 뛰어남

SNS → 다수의 SQS 구독자 구조는 고성능 마이크로서비스 아키텍쳐에서 일반적으로 사용됨

A. Amazon Kinesis Data Analytics를 사용하여 메시지를 유지하고 처리하도록 구성

Kinesis Data Analytics는 스트리밍 SQL 분석에 적합. 메시지 브로커 아키텍처에는 부적합

B. EC2 Auto Scaling 그룹에 수집 애플리케이션을 배포하고 CPU 기반 스케일링 구성

EC2 + Auto Scaling만으로는 수신 메시지를 분리하지 못하므로 결합도 높음

C. Kinesis Data Stream에 단일 샤드를 사용하고 Lambda + DynamoDB로 처리

Kinesis 단일 샤드는 초당 처리량이 제한적(샤드당 최대 1MB/s 또는 1000레코드/s). 초당 10만건에는 부적합

D. SNS 주제에 메시지를 게시하고, 여러 SQS 구독을 통해 소비 애플리케이션이 처리하도록 구성

SNS

발행/구독 메시징 서비스

주체에 메시지를 게시하면 여러 구독자에게 동시에 전달

장점

  • 푸시 기반, 다수 구독자에 동시 전송
  • Email, SMS, Lambda, SQS 등 다양한 전송 지원

단점

  • 메시지 순서 보장 불가
  • 전송 실패 시 Dead-Letter Queue 직접 설정 필요

SQS

분산형 메시지 큐 서비스로, 생산자와 소비자 간 비동기 메시지 처리

장점

  • 표준/FIFO 큐 지원 → 순서 보장 필요 여부에 따라 선택 가능
  • 확장성 높고, 메시지 일시 저장 및 재시도 가능

단점

  • 소비자에서 직접 메시지 Pull 처리 필요(푸시 아님)

SNS + SQS 구조

SNS는 단일 메시지를 여러 구독자에게 전파

SQS를 구독자에 위치시킴

SQS의 소비자들에게 자신의 큐에 비동적으로 처리하게 함

SQS를 연결시켜 분리시킬 수 있음

Amazon Kinesis

Data Streams

고속, 실시간 데이터 스트리밍 수집 서비스

장점

  • 낮은 지연 시간, 실시간 처리
  • Shard 단위로 수평 확장 가능
  • Lambda, Firehose, Analytics와 통합

단점

  • 복잡한 샤드 구성 및 리소스 관리 필요

시험 문장:

  • “Kinesis Data Streams는 초당 수백 MB의 스트리밍 데이터를 수집하고 사용자 정의 애플리케이션으로 처리할 수 있습니다”

Data Firehose

수집된 데이터를 변환해 저장소로 자동 전송 시킴

서버리스 / 자동 배치 처리로 운영 부담 최소화

Data Analytics

SQL 기반으로 실시간 스트리밍 데이터 분석 가능한 서비스

장점

  • SQL 또는 Flink 사용
  • 자동 확장 및 내결함성 내장

단점

  • Apache Flink 등 고급 설정은 진입장벽 존

시험 문장:

  • “Kinesis Data Analytics는 SQL을 사용해 스트리밍 데이터를 실시간 분석할 수 있으며, Firehose와 함께 사용 시 운영 부담이 적습니다”

Q8. 회사는 레거시 분산 애플리케이션을 AWS로 마이그레이션하고자 합니다

회사는 다양한 워크로드를 처리하는 분산 애플리케이션을 AWS로 마이그레이션 중입니다.

기존 시스템은 여러 컴퓨팅 노드에서 작업을 조정하는 기본 서버(master server) 로 구성되어 있습니다.

회사는 이 애플리케이션을 탄력성(resiliency) 과 확장성(scalability) 을 극대화하는 형태로 현대화하고자 합니다.

솔루션 설계자는 이 요구 사항을 충족하기 위해 어떻게 아키텍처를 설계해야 합니까?

핵심

레거시 기반 기본 서버 의존 아키텍처 → 현대적 분산형 구조로 전환

작업 수요에 따라 탄력적으로 확장 및 축소

큐 기반으로 작업 분산

A. SQS 대기열을 구성하고, EC2 Auto Scaling 그룹을 설정한 뒤 **예약된 스케일링(Scheduled Scaling)**을 구성한다.

예약된 스케일링은 예측 가능한 트래픽에만 적합, 동적 탄력성 부족

B. SQS 대기열을 구성하고, EC2 Auto Scaling 그룹을 구성하여 대기열 크기에 따라 스케일링하도록 설정한다.

C. 기본 서버와 컴퓨팅 노드를 EC2 Auto Scaling 그룹으로 구성하고, 작업 대상으로 CloudTrail을 설정한다.

CloudTrail은 이벤트 로깅 도구이지 작업 디스패칭에 사용안됨

D. 기본 서버와 컴퓨팅 노드를 EC2 Auto Scaling 그룹으로 구성하고, 작업 대상으로 EventBridge를 설정한다.

EventBridge는 이벤트 중심 작업 트리거에 적합/ 지속적인 작업 큐 분산 처리에는 SQS가 더 적합

Auto Scaling 그룹

EC2 인스턴스를 그룹으로 관리하며, 수요에 따라 자동으로 인스턴스 수를 증가 또는 감소시키는 서비스

Target Tracking Scaling: CPU, RequestCount 등 특정 지표를 목표값으로 설정하여 자동 조정

Step Scaling: 지표 임계값을 단계별로 설정

Scheduled Scaling: 특정 시간에 스케일링

장점

  • 고가용성/ 비용 최적화 동시에 달성
  • 다양한 이벤트 및 지표 기반 확장 가능

단점

  • 워크로드에 맞는 지표 선택이 중요

Queue Length 기반 스케일링

SQS 메시지 수를 기분으로 Auto Scaling 그룹 인스턴스를 확장/축소하는 것

큐가 너무 많으면 소비자를 추가해 큐를 줄이려는것

EventBridge

다양한 AWS 서비스 또는 자체 애플리케이션 이벤트를 중앙에서 수집, 필터링, 라우팅하는 이벤트 버스 서비스(이벤트를 실시간으로 수집/필터/전송)

📌 핵심 목적: 이벤트 기반 자동화 및 서비스 간 decoupling

Q9. 데이터센터 SMB 파일 서버 스토리지 공간 부족 문제 해결

회사는 데이터 센터에서 SMB 파일 서버를 운영 중입니다.

  • 해당 서버는 파일 생성 후 처음 며칠간은 자주 접근,
  • 7일 이후에는 거의 접근이 없는 대용량 파일을 저장하고 있습니다.

현재 전체 스토리지 용량이 한계에 도달하고 있어,

솔루션 설계자는 다음 요건을 만족해야 합니다:

  • 가장 최근에 접근한 파일은 저지연으로 액세스 유지
  • 스토리지 공간 확장 필요
  • 향후 스토리지 문제 방지를 위한 파일 수명 주기 관리 필요

어떤 솔루션이 가장 적절한가요?

S3 File Gateway는 온프레미스에서 SMB 파일 시스템 처럼 작동하지만, S3에 저장됨

자주 접근되는 데이터는 로컬 캐시에 유지하므로 저지연 성능 유지

7일 지나면 자동으로 Glacier Depp Archive로 이동시켜 비용절감

A. AWS DataSync를 사용해 7일 이상 지난 데이터를 AWS로 복사

DataSync는 일회성/주기적 이동에 적합 / 지속적 하이브리드 통합에는 부적합 B. Amazon S3 File Gateway 생성 후 S3 수명 주기 정책으로 7일 후 Glacier Deep Archive로 전환 C. Amazon FSx for Windows File Server 생성

비용이 높고 수명 주기 정책없음 D. 사용자 PC에 유틸리티 설치 후 S3에 직접 접근하도록 설정, 7일 후 Glacier Flexible Retrieval로 전환

사용자 단에서 유틸리티 설치는 운영오버헤드 큼, 웅앙 집중형 관리에 부적합

Data Sync

온프레미스 ↔ AWS 또는 AWS ↔ AWS 간에 대규모 데이터 이동을 빠르고 안정적으로 수행하는 완전관리형 데이터 전송 서비

📌 목적: 데이터 이전, 백업, 복제, 실시간 동기화 작업을 자동화하고 가속화

온프레미스 → S3 이전: NFS, SMB 기반 파일 서버의 데이터를 S3로 이전 하는 것

S3 → EFS 복제할 때도 사용

Q10. 회사는 전자상거래 웹 애플리케이션을 AWS에 구축 중입니다

회사는 AWS에서 전자상거래 웹 애플리케이션을 구축하고 있으며,

해당 애플리케이션은 Amazon API Gateway REST API를 통해 새 주문 정보를 수신합니다.

회사는 다음 요구사항을 만족하고자 합니다:

  • 주문은 접수된 순서대로 처리되어야 함 (순서 보장)

핵심

순서 보장

SNS / SQS Standard 는 순서 보장 못함

SQS FIFO Queue는 순서 보장 + 중복 방지를 위해 설계된 큐

Lambda는 SQS FIFO Queue와 통합되어 정확한 순서로 메시지를 소비할 수 있음

A. API Gateway 통합으로 SNS에 메시지를 게시, SNS를 구독한 Lambda가 처리

SNS는 순서 보장 못함

B. API Gateway 통합으로 SQS FIFO 대기열에 메시지를 전송하고 Lambda가 처리

C. API Gateway 권한 부여자를 사용하여 모든 요청을 처리 중 차단

권한제어는 접근 제어 목적, 메시지 순서와 무관

D. API Gateway 통합으로 SQS 표준 대기열에 메시지를 전송하고 Lambda가 처리

SQS Standard는 순서 보장 못함

API Gateway

REST, HTTP, WebSocket API를 손쉽게 생성, 게시, 보호할 수 있는 완전관리형 서비스

Lambda, Kinesis, SQS, HTTP 백엔드 등과 통합 가능

예) 스프링 백엔드 앞단에서 모든 요청을 검사하고 라우팅을 해주거나 할 수 있음

[API Gateway] ↓ 인증/경로/속도 제한 [WAF] ↓ 공격 차단 [Spring 백엔드 (ECS/EKS/EC2 등)]

장점

인증/인가/요금제/키 관리 등 API 기능 완비

WAF, CloudFront와 통합 가능

캐싱, 사용량 제한, 로그 추적 지원

단점

지연시간이 상대적으로 큼

호출량 증가 시 요금 급증 우려

시험 포인트

  • “API Gateway는 REST/HTTP/WebSocket API를 제공하며 Lambda, SQS, Kinesis 등과 통합 가능합니다”
  • “API Gateway와 SQS FIFO 대기열을 함께 사용해 주문의 순차적 처리를 보장할 수 있습니다”

WAF

SQL Injection, XSS 등 웹 공격을 필터링하는 방화벽

API Gateway, ALB 앞단에 연결 가능

SQS FIFO Queue

엄격한 순서 보장과 중복 제거 기능 있음

하지만 처리량이 제한적임

AWS Lambda

서버 없이 코드를 실행하는 서비스

요청이 오면 Spring을 내부적으로 띄워서 실행

사용자는 람다에 맞게 조금 수정한 스프링 코드를 통해 사

API Gateway, SQS, SNS, DynamoDB 등 다양한 서비스와 직접 통합 가능

장점

  • 자동 확장(1 요청 = 1 인스턴스)
  • 이벤트 기반 자동 트리거
  • 과금: 실행 시간 + 리소스 사용량

단점

  • 실행 시간 제한 있음
  • 초기 Cold Start로 인한 지연 가능

Q11. EC2 인스턴스가 로컬 자격 증명을 사용해 Aurora에 연결 중

회사는 Amazon EC2 인스턴스에서 실행되는 애플리케이션과

Amazon Aurora 데이터베이스를 사용하고 있습니다.

현재 EC2 인스턴스는 로컬 파일에 저장된 사용자명과 비밀번호를 사용해 데이터베이스에 연결합니다.

회사는 자격 증명 관리의 운영 오버헤드를 줄이길 원합니다.

이 목표를 달성하기 위한 최적의 방법은 무엇입니까?

로컬 파일에 저장된 사용자명과 비밀번호로 DB 접근하는데 이걸 더 효율적으로 관리하려면

해당 정보를 AWS에 올려서 사용하면됨

이걸 해주는게 Secrets Manager → 로컬파일에 비번 저장할 필요 없음

운영 오버헤드 줄고 보안 수준도 높아짐

A. AWS Secrets Manager를 사용하고 자동 회전을 활성화한다. B. AWS Systems Manager Parameter Store를 사용하고 자동 회전을 활성화한다.

일반 매개변수 저장에는 좋지만, 데이터베이스 자격 증명 관리에는 기능이 부족하고 자동 회전 설정도 복잡함 C. AWS KMS로 암호화된 자격 증명 파일을 S3 버킷에 저장하고, 애플리케이션이 이를 참조하도록 한다.

자격 증명을 S3에 두는 것은 보안 위험이 있음. 접근 제어가 더 복잡하고 오버헤드가 큼 D. 암호화된 EBS 볼륨을 생성하고 자격 증명 파일을 그 위에 마이그레이션한 뒤 애플리케이션이 이를 참조하게 한다.

로컬 디스크에 파일을 옮기는 구조로 기존 방식과 유사하며, 여전히 수동 갱신 필요 → 오버헤드 큼

Amazon Aurora

클라우드 최적화 고성능 관계형 데이터베이스 서비스

MySQL / PostgreSQL과 호환됨

성능 확장성 고가용성 극대화한 DBMS

Standard / Serverless v2

RDS 기반 관리형 DB

특징

6개 복제본이 3개의 AZ에 자동 분산 저장

자동 증설

디스크 오류 자동 복구

Reader 인스턴스 다중 구성 가능

읽기 부하 분산

Aurora Serverless v2

사용량에 따라 자동으로 컴퓨팅 리소스를 늘리고 줄임

유휴 상태일 때는 과금 거의 없음

스케일링 단위가 작고 빠름

AWS Secrets Manager

DB 자격증명, API 키, 토큰 등 보안 비밀을 안전하게 저장하고 자동 교체(Rotation)를 지원하는 서비스

애플리케이션이 Secrets Manager에게 API 호출로 비밀을 조회하여 사용하는 것

장점

  • 보안 강화 (코드 하드코딩 제거)
  • 자동 회전으로 장기 키 리스크 감소
  • RDS, Redshift, DocumentDB와 자동 통합

단점

  • 비용 있음 (Parameter Store보다 비쌈)
  • Lambda를 활용한 Rotation은 복잡성 존재

Automatic Rotation

비밀번호, 토큰 등 보안 비밀을 자동으로 정해진 주기마다 교체

AWS는 Lambda를 호출하여 자동으로 새 비밀을 생성하고 업데이트

AWS Systems Manager Parameter Store

애플리케이션 설정, 구성값, 민감한 값들을 저장할 수 있는 키-값 저장소

일반 문자열과 암호화된 보안 문자열 지원

여기에 비밀번호 같은건 저장 안하는게 좋음

자동회전 설정이 어렵

차이점 vs Secrets Manager

항목 Secrets Manager Parameter Store

대상 비밀번호, API 키 구성값, 환경변수 등
자동 회전 지원 (자동) ❌ 직접 구성 필요
복제 다중 리전 지원 ❌
비용 유료 대부분 무료 (고급은 과금)

AWS KMS

키를 관리하는 서비스임 + AWS 리소스와 연동하여 자동 암호화함

CMK: 사용자가 만든 키

키 자동 회전 가능

CloudTrail로 로깅

Q12. 글로벌 회사의 웹 애플리케이션: 정적 + 동적 콘텐츠 성능 개선

글로벌 회사는 Amazon EC2 인스턴스 뒤에 ALB(Application Load Balancer) 를 두고

웹 애플리케이션을 호스팅하고 있습니다.

  • 정적 콘텐츠는 Amazon S3 버킷에 저장되어 있고,
  • 동적 콘텐츠는 EC2 인스턴스에서 제공됩니다.
  • 도메인은 Amazon Route 53에 등록되어 있습니다.

회사는 정적 데이터 및 동적 데이터의 성능을 개선하고

대기 시간(latency)을 줄이길 원합니다.

어떤 솔루션이 가장 적절합니까?

A. S3 버킷과 ALB를 오리진으로 포함하는 CloudFront 배포를 생성하고, Route 53이 CloudFront 배포로 트래픽을 라우팅하도록 구성한다.

B. ALB 오리진 기반 CloudFront 배포를 만들고, S3 버킷을 엔드포인트로 포함하는 Global Accelerator를 생성한다. Route 53은 CloudFront로 라우팅한다.

Global Accelerator는 S3에 직접 연결 불가

C. S3를 오리진으로 포함한 CloudFront 배포를 만들고, ALB 및 CloudFront를 포함하는 Global Accelerator를 생성한다. 사용자 지정 도메인을 Accelerator DNS로 매핑한다.

복잡한 구조, ALB + CloudFront 둘 다 Global Accelerator에 넣을 필요 없음

D. ALB 오리진 CloudFront 배포 생성, S3를 Global Accelerator에 포함. 동적 콘텐츠 전용 도메인을 별도로 만든다.

도메인 이중화는 관리 오버헤드 증가됨

Amazon CloudFront

CDN 서비스

전 세계에 분산된 엣지 로케이션을 통해 S3, EC2, ALB 등에서 제공하는 정적/동적 콘텐츠를 사용자에게 가장 가까운 위치에서 빠르게 제공

Route 53

고가용성 DNS 웹 서비스

정점

  • 지능적인 트래픽 분산 가능
  • CloudFront, ELB, S3와 연계 용이
  • 온프레미스 DNS와 연동 가능

Global Accelerator

원래는 IP는 리전에 국한됨 근데 이걸 여러 리전에 동일하게 두고 만약 해당 아이피로 접속되면 AWS 엣지서버로 들어가 빠르게 AWS 내부 백본망을 통해 빠르게 전송되다는 것

AWS 글로벌 네트워크를 활용해 전 세계 사용자 트래픽을 가장 빠르고 안정적인 AWS 엔드포인트로 라우팅

TCP, UDP 기반 애플리케이션에 대해 Anycast 고정 IP 제공

  1. 사용자는 전 세계 고용 IP로 접속
  2. 글로벌 네트워크 백본을 통해 지연 시간 최소화된 AWS 리전으로 트래픽 전송
  3. 최종적으로 EC2, ALB, NLB 등 엔드포인트로 도달

장점

  • TCP/UDP 지원
  • 상태 기반 라우팅 → 비정상 엔드포인트 제거
  • 고정 IP 제공
  • 빠른 장애 복구

단점

  • 웹 계층이 아닌 네트워크 계층에 작동
  • Route 53보다 비싼 경우 있다.

Q13. 여러 리전의 RDS MySQL 자격 증명을 주기적으로 교체해야 함

회사는 AWS 인프라에 대해 매월 유지 관리 작업을 수행합니다.

이 유지관리 중에는 여러 AWS 리전에 있는 Amazon RDS MySQL DB 인스턴스의 자격 증명(비밀번호)을 교체해야 합니다.

회사는 이를 운영 오버헤드 최소화 방식으로 자동화하길 원합니다.

가장 적절한 해결책은 무엇입니까?

AWS Secrets Manager는 데이터베이스 자격 증명 관리에 최적화된 서비스

다중 리전 복제 기능(Multi-Region Secret Replication)을 통해 한 번 정의한 자격 증명을 여러 리전의 RDS 인스턴스에서 공유할 수 있다

비밀번호 자동 회전으로 운영자가 수동 갱신 필요없음

→ 운영 오버헤드 최소화 + 보안성 강화

A. AWS Secrets Manager에 자격 증명을 저장하고, 다중 리전 복제를 활성화하며, 비밀번호를 자동으로 교체하도록 구성한다. B. Systems Manager Parameter Store에 자격 증명을 저장하고, 다중 리전 복제를 활성화한 뒤 자동으로 교체하도록 구성한다.

Parameter Store는 비밀번호 자동 회전 기능이 제한적 C. 암호화된 S3 버킷에 자격 증명을 저장하고 EventBridge를 사용해 Lambda 함수로 교체 작업을 자동화한다.

S3에 비밀번호를 저장하는 것은 보안상 권장 안됨 D. AWS KMS로 암호화한 자격 증명을 DynamoDB 글로벌 테이블에 저장하고 Lambda + RDS API로 교체한다.

너무 많은 서비스 → 운영부담 큼

다중 리전 복제 기능(Multi-Region Secret Replication)

하나의 시크릿을 기본 리전에 생성하고, 다른 리전으로 자동 복제하여 동기화하는것

읽기 전용으로 다른 리전에 복제본 만들어 줌(수정은 주 리전의 시크릿으로)

Q14. EC2 기반 전자상거래 애플리케이션의 데이터베이스 읽기 성능 저하 문제

회사는 Application Load Balancer 뒤 Amazon EC2 인스턴스에서

전자상거래 애플리케이션을 실행하고 있습니다.

  • 인스턴스는 **여러 가용 영역(AZ)**에 걸쳐 있는 Auto Scaling 그룹에서 실행되며,
  • CPU 사용률 기반으로 스케일 아웃됩니다.
  • 애플리케이션은 MySQL 8.0 데이터베이스를 사용하는데,
  • 해당 데이터베이스는 대규모 EC2 인스턴스에서 호스팅되고 있습니다.

문제: 애플리케이션 로드가 증가하면 데이터베이스 성능이 빠르게 저하됩니다.

읽기 요청이 쓰기보다 훨씬 많습니다.

요구사항: 고가용성 유지 + 예측 불가능한 읽기 트래픽에 따라 자동 확장 가능해야 함

고가용성 ⇒ 다중 AZ

Aurora는 기본이 다중 AZ에 복사본을 가지게 됨

A. 단일 노드 Amazon Redshift 사용

단일노드는 가용성 불만족/Redshift는 대용량 데이터 분석용 DB임 트랜잭션용도론 별로

B. RDS 단일 AZ 배포, 리더 인스턴스를 추가

단일az X, 리더 인스턴스도 수동 설정해야함

C.Amazon Aurora 다중 AZ 배포 + Aurora 복제본 + Auto Scaling 구성

D. EC2 스팟 인스턴스 + Memcached ElastiCache 사용

스팟이면 갑자기 종료, ElastiCache 이건 DB의 대체가 아

Q15. 회사는 AWS로 마이그레이션한 후 프로덕션 VPC의 트래픽을 보호하고자 합니다

회사는 최근 AWS로 마이그레이션을 완료했습니다.

프로덕션 VPC의 인바운드/아웃바운드 트래픽을 보호하는 솔루션을 구현하고자 합니다.

과거에는 온프레미스 데이터 센터에 검사 서버(Inspection Server) 를 두고

  • 트래픽 흐름 검사
  • 트래픽 필터링

과 같은 작업을 수행했습니다.

이제 회사는 AWS 클라우드 상에서 동일한 기능을 제공받기 원합니다.

어떤 솔루션이 이 요구 사항을 충족합니까?

VPC의 인바운드/아웃바운드 트래픽을 보호하는 솔루션 → 방화벽이 필요

→ AWS Network Firewall

온프레미스의 트래픽 검사 서버 기능을 대체할 수 있는 가장 유사한 클라우드 서비스

A. Amazon GuardDuty를 사용해 트래픽 검사 및 필터링

GuardDuty는 보안 위협 탐지 및 이상 징후 탐지 용도, 실시간 필터링 또는 트래픽 차단은 못함

B. VPC 트래픽을 미러링하여 검사 및 필터링

Traffic Mirroring 트래픽을 복사해서 별도 장비나 EC2에서 분석 가능. 실시간 차단/필더링 불가

C. AWS Network Firewall을 사용해 VPC 트래픽 검사 및 필터링 규칙 생성

D. AWS Firewall Manager를 사용해 검사 및 필터링 규칙 생성

여러 계정, 여러 VPC의 보안 규칙을 중앙 통제하는 도구, 단독으로 검사 필터링 기능은 없음

Network Firewall을 기본으로 써야 저걸 쓸 수 있음

AWS Network Firewall

  • VPC 레벨에서 트래픽 검사 및 필터링이 가능한 L3/4/7 네트워크 방화벽
  • Stateful & Stateless 룰 세트 구성 가능
  • NAT Gateway 또는 Internet Gateway를 통해 나가는 트래픽도 제어 가능
  • 라우팅이 필수
  • 사용예) 외부로 나가는 HTTP 요청에서 악성 도메인을 차단하고 싶다면 이걸 사용

VPC의 서브넷 경계

장점

  • VPC 내부에서 네트워크 기반 제어 가능
  • IDS/IPS와 유사한 기능 포함
  • 다중 AZ에 걸쳐 가용성 유지

시험포인트

“AWS Network Firewall은 VPC에 들어오고 나가는 트래픽을 검사하고 필터링할 수 있도록 도와줍니다”

인터넷 ↓ [VPC Network Firewall] ← 트래픽 경계 제어 (멀티AZ, IPS, 도메인 룰 등) ↓ [NACL] ← 서브넷 입구/출구에서 기본 허용/거부 판단 ↓ [보안 그룹] ← 각 EC2 인스턴스에서 포트 단위로 인바운드 필터링 ↓ [애플리케이션]

Firewall Manager

AWS Organizations 내 여러 계정과 리전의 WAF, Shield, Network Firewall, 보안 그룹 규칙을 중앙에서 통합 관리하는 보안 정책 서비

GuardDuty

계정, 네트워크, S3 접근 등의 비정상 활동을 탐지하는 AI 기반 위협 탐지 서비스

동작원리

  • CloudTrail 로그, VPC 흐름 로그, DNS 로그 분석
  • 이상행위 감지

장점

  • 완전 관리형(Agent 없이 사용 가능)
  • AWS Security Hub 와 연동 가능
  • 탐지 결과는 시각화/자동 대응 가능

VPC Traffic Mirroring

특정 ENI에서 실시간 네트워크 트래픽을 복제하여 보안 분석 도구로 전달

  • 트래픽 분석 및 보안 검사
  • 네트워크 부하 발생 가능
  • 추가 비용 및 설정 복잡도

Q16. 회사는 데이터 레이크를 운영 중이며 시각화된 리포트 솔루션을 원함

회사는 AWS에서 데이터 레이크(Data Lake) 를 운영하고 있습니다.

  • 데이터는 Amazon S3 및 Amazon RDS for PostgreSQL에 저장되어 있습니다.

회사는 다음과 같은 리포팅 솔루션이 필요합니다:

  • 데이터 시각화 기능 포함
  • 데이터 레이크의 모든 소스(S3, RDS) 포함
  • 경영진(Management Team) 은 전체 데이터에 대한 전체 액세스 권한
  • 다른 직원들은 제한된 액세스 권한만 가짐

어떤 솔루션이 요구 사항을 충족합니까?

시각화를 원함 → QuickSight: 시각화 BI(비지니스 인텔리전스)도구로 시각화 리포트 만듬

권한 설정도 가능함 사용자/그룹 기반의 공유 모델 채용

A. QuickSight 분석 생성 → 데이터 소스 연결 → 대시보드 게시 → IAM 역할로 공유

QuickSight는 IAM Role 기반 공유를 지원하지 않음 / 사용자 및 그룹 기반 공유만 가능 B. QuickSight 분석 생성 → 데이터 소스 연결 → 대시보드 게시 → 사용자 및 그룹과 공유 C. AWS Glue + ETL로 리포트 생성 후 S3에 저장, 버킷 정책으로 접근 제한

S3에 지정된 정적 리포트는 시각화 기능 부족 + 동적 대시보드 기능 없음 D. AWS Glue + Athena Federated Query로 분석 후, S3에 보고서 저장, 접근은 S3 정책으로 제한

Athena는 쿼리는 가능하나, 시각화 목적에는 적합하지 않음. 수동 작업 많음

Amazon QuickSight

AWS의 완전관리형 BI 및 데이터 시각화 서비스

SQL 없이도 대시보드, 차트 등을 생성 가능

  • 다양한 데이터 소스 연동: S3, Athena, RDS, Redshift, Salesforce 등
  • SPICE 엔진 기반 빠른 쿼리 처리
  • IAM 기반 사용자 접근 제어
  • 대시보드 공유 가능

AWS Data Lake

정형/비정형 데이터를 중앙에 통합 저장하여 분석 가능한 형태로 만든 저장소 구조

주로 Amazon S3 기반으로 구성

  • 모든 데이터를 원시 형태로 저장
  • Glue, Lake Formation, Athena, Redshift 등과 연동
  • 보안, 권한 제어는 IAM 또는 Lake Formation 사용

Lake Formation

데이터 레이크 생성을 단순화하며, 데이터 접근 제어를 세분화할 수 있다.

AWS Glue

서버리스 추출, 변환, 적재 서비스

S3나 데이터베이스에 흩어진 데이터를 수집하고, 변형, 분석 도구에서 쿼리 가능하도록 준비해주는 것

풀로 흩어진 데이터쪼가리를 붙여서 분석 가능하게 만드는

데이터를 정제, 구조화하여 Athena, Redshift에서 분석 가능하게 만듦

크롤러: 데이터 스캔 → 스키마 자동 인식

데이터 카탈로그: 테이블, 스키마 메타데이터 저장

ETL 작업

AWS Athena

S3의 데이터를 SQL로 직접 쿼리하는 서버리스 대화형 분석 서비스

데이터베이스 없이도 S3에 저장된 CSV, JSON, Parquet 등을 SQL로 분석

  • 표준 SQL 사용
  • Glue 데이터 카탈로그와 통합
  • 쿼리한 데이터 양만큼 비용 부과

시험 포인트

Athena는 서버리스로 동작하며, S3의 데이터를 SQL로 즉시 쿼리할 수 있습니다

Athena Federated Query

Athena가 S3뿐 아니라 RDS, Redshift, JDBS 등 외부 데이터 소스도 쿼리 가능하게 하는 기능

커넥터 기반으로 확장 가능

RDS, DynamoDB, Aurora 등 실시간 데이터도 조회 가능

데이터 이동 없이 분석 가능(데이터 가상화)

시험 포인트

Athena Federated Query를 사용하면 RDS 데이터도 Athena에서 직접 SQL로 분석 가능

Amazon RDS

MySQL, PostgreSQL, MariaDB, Oracle, SQL Server를 AWS에서 관리형으로 제공

인프라 설치/패치/백업 자동화

  • 멀티 AZ 배포 가능
  • Read Replica로 읽기 성능 확장 가능
  • 자동 백업, 모니터링, 스냅샷 지원
  • RDS Proxy로 연결 효율화 가능

DynamoDB

완전관리형 NoSQL 키-값 및 문서형 데이터베이스

무한에 가까운 확장성과 밀리초 단위 응답속도

  • 서버리스
  • DAX(DynamoDB Accelerator)로 캐시 성능 강화
  • Global Table로 멀티 리전 복제 가능
  • TTL, 스트림, PartiQL(SQL 유사 문법) 지원

읽기/쓰기 패턴이 빠르고 예측 불가한 워크로드에 적합

Aurora(Amazon RDS 기반 클라우드 네이티브 DB)

MySQL, PostgreSQL 호환 고성능 RDS

고가용성 고성능

ElastiCache(Redis / Memcached)

인메모리 캐시 DB

응답 시간 짧음

Redis: 영속성, 복제, Pub/Sub 지원

Memcashed: 단순 캐시용

DocumentDB(MongoDB 호환)

JSON 형식 문서를 저장하는 NoSQL DB

MongoDB API 호환

읽기 복제본 지원

Timestream

시계열 데이터 저장 및 분석에 최적화된 DB

QLDB(Quantum Ledger DB)

변조 불가능한 트랜잭션 로그 기록

회계/감사/공공 기록 시스템 용도

Neptune

그래프 DB(SNS 관계, 추천 시스템 등)

Q17. EC2 인스턴스에서 실행되는 새 비즈니스 애플리케이션이 S3에 접근해야 함

회사는 새로운 비즈니스 애플리케이션을 구현하고 있습니다.

  • 애플리케이션은 두 개의 Amazon EC2 인스턴스에서 실행됩니다.
  • 문서 저장을 위해 Amazon S3 버킷을 사용합니다.

요구사항:

솔루션 설계자는 EC2 인스턴스가 해당 S3 버킷에 정상적으로 액세스할 수 있는지 확인해야 합니다.

인스턴스에게 AWS 리소스에 대한 접근을 부여하는 방법은 IAM Role 역할을 부여하는 것이다.

무엇을 해야 합니까?

A. S3 버킷에 대한 액세스 권한을 부여하는 IAM 역할을 생성하고, 이를 EC2 인스턴스에 연결한다. B. S3 버킷에 대한 액세스 권한을 부여하는 IAM 정책을 생성하고, 이를 EC2 인스턴스에 연결한다.

정책 바로 붙일 수 없음 C. S3 버킷에 대한 액세스 권한을 부여하는 IAM 그룹을 생성하고, 그룹을 EC2 인스턴스에 연결한다.

그룹은 사용자용임 D. S3 버킷에 대한 액세스 권한을 부여하는 IAM 사용자를 생성하고, 이를 EC2 인스턴스에 연결한다.

IAM 사용자 계정을 EC2에 직접 연결하는 것은 보안상 취약

Q18. 이미지 압축 마이크로서비스 구성: 내구성 + 상태 비저장 구성 요구

애플리케이션 개발 팀은 큰 이미지를 작은 압축 이미지로 변환하는 마이크로서비스를 설계하고 있습니다.

사용자가 웹 인터페이스를 통해 이미지를 업로드하면:

  1. 이미지가 Amazon S3 버킷에 저장되고,
  2. AWS Lambda 함수가 이미지를 처리 및 압축하며,
  3. 다른 S3 버킷에 압축된 이미지를 저장합니다.

솔루션 설계자는 내구성(durability)이 있고 상태 비저장(stateless)인 구성 요소를 사용해

자동으로 이미지를 처리하는 솔루션을 설계해야 합니다.

어떤 조합의 작업이 요구사항을 충족합니까? (2개 선택)

내구성 + 상태 비저장 + 자동 처리

S3 + SQS + Lambda

A. Amazon SQS 대기열을 생성하고, S3 버킷에서 업로드 이벤트가 발생할 때 해당 SQS에 알림을 보낸다 B. Lambda 함수를 SQS 호출 소스로 구성하고, 처리 성공 시 메시지를 삭제하도록 설정한다 C. S3 버킷 이벤트를 감지하는 Lambda를 만들고, 파일 이름을 메모리 텍스트 파일로 관리한다

메모리 내 텍스트 파일로 상태추적 → 비내구성 + 람다의 stateless 원칙 위반 D. EC2 인스턴스를 띄워 SQS를 모니터링하고 파일명을 기록한 뒤 Lambda 호출

모니터링하는 것에 대한 운영 비용+유지보수 비용 증가, 람다 호출하는 것도 복잡 E. EventBridge로 S3 이벤트를 감지해 SNS로 이메일 알림 전송

SNS는 알림용/ 실제 처리 트리거로는 적합하지 않음 자동처리가아님

S3 Event Notification

S3 버킷에서 발생하는 특정 이벤트를 감지하여 다른 AWS 서비스로 알림을 전송할 수 있게 해주는 기능

SQS, SNS, Lambda, EventBridge

Q19. 3계층 웹 애플리케이션의 트래픽을 타사 방화벽 어플라이언스로 검사하고자 함

회사는 AWS에 3계층 웹 애플리케이션을 배포했습니다.

  • 웹 서버는 VPC의 퍼블릭 서브넷에
  • 애플리케이션 서버와 DB 서버는 프라이빗 서브넷에 배포되어 있습니다.

회사는 AWS Marketplace에서 구입한 타사 가상 방화벽 어플라이언스를

검사 VPC에 배포했으며, 해당 어플라이언스는 IP 패킷을 수신할 수 있는 인터페이스로 구성되어 있습니다.

요구사항: 웹 서버로 도달하는 모든 트래픽을 방화벽 어플라이언스로 먼저 통과시키고 싶음

운영 오버헤드를 최소화해야 합니다.

핵심

Gateway Load Balancer는 서드파티 네트워크 보안 어플라이언스와의 통합을 위한 정용 로드 밸런서

GWLB Endpoint를 통해 VPC 외부의 인스턴스 또는 다른 VPC의 보안 장비로 트래픽 전송할 수 있음

A. 애플리케이션 VPC의 퍼블릭 서브넷에 Network Load Balancer를 생성해 트래픽을 어플라이언스로 라우팅

L4 기반 트래픽 라우팅은 가능하나 보안 어플라이언스 연동이 복잡, 상태 저장 검사 어려움 B. 애플리케이션 VPC의 퍼블릭 서브넷에 Application Load Balancer를 생성해 트래픽을 어플라이언스로 라우팅

ALB는 l7 용 IP 패킷 단위 라우팅 불가 C. 검사 VPC에 Transit Gateway를 배포하고 라우팅 테이블 구성

다중 VPC 간 연결에는 좋지만 트래픽 검사 기능은 제공하지 않 D. 검사 VPC에 Gateway Load Balancer를 배포하고 Endpoint를 통해 어플라이언스로 트래픽 전달

Gateway Load Balancer(GWLB)

L3/L4 트래픽을 보안 가상 어플라이언스로 전달하고, 스케일링과 고가용성까지 제공하는 로드 밸런서

보안 어플라이언스를 중앙 집중식으로 배포, 확장, 관리하기 위한 전용 로드밸런서

GWLB Endpoint

GWLB를 각 VPC에 연결하기 위한 인터페이스 엔드포인트

VPC 내부에서 발생한 트래픽을 GWLB로 보내기 위한 연결 지점

타사 보안 어플라이언스

보안 업체의 가상 방화벽, IPS, IDS 제품

IDS(Intrusion Detection System)

침입 탐지 시스템 탐지만 함

IPS(Intrusion Prevention System)

침입 차단 시스템 탐지 후 자동으로 차단까지 수행

Q20. EC2 + EBS 기반 프로덕션 데이터를 테스트 환경으로 빠르게 복제

회사는 동일한 AWS 리전 내 테스트 환경에 대량의 프로덕션 데이터를 복제하는 기능을 개선하고자 합니다.

  • 데이터는 EC2 인스턴스의 EBS 볼륨에 저장되어 있으며,
  • 복제된 데이터를 수정하더라도 프로덕션에 영향을 주면 안 됩니다.
  • 해당 데이터를 사용하는 애플리케이션은 지속적으로 높은 I/O 성능을 요구합니다.

요구사항:

  • 복제 시간 최소화
  • 프로덕션 데이터는 유지되며, 테스트에서 수정 가능
  • 고성능 I/O 보장

핵심

EBS Fast Snapshot Restore(FSR) 기능을 사용하면 스냅샷에서 새 EBS 볼륨을 즉시 완전 성능 상태로 복원할 수 있음

이건 프로덕션과 격리되어 있음으로 수정해도 영향 없음

A. EBS 스냅샷 생성 후, 테스트 환경의 EC2 인스턴스 스토어 볼륨에 복원

EC2 인스턴스 스토어는 일시적 스토리지이며, 스냅샷에서 복원 불가

B. 프로덕션 EBS 볼륨을 다중 연결(EBS Multi-Attach)로 설정하고 테스트 환경에 연결

Multi-Attach는 EBS io1/io2에서만 사용가능하며, 읽기/쓰기 충돌 위험 + 프로덕션에 영향 가능 C. 스냅샷 → 새 EBS 볼륨 생성 → EC2에 연결

그냥 스냅샷으로 새볼륨 만들면 오래걸 D. 스냅샷 생성 후, EBS 빠른 스냅샷 복원(FSR)을 활성화하여 새 EBS 볼륨으로 복원 후 연결

Multi-Attach

하나의 EBS 볼륨을 여러 EC2 인스턴스에 동시에 연결하는것

읽기/쓰기 충돌 방지를 위해 클러스터형 파일 시스템 필요

EBS Snapshot

EBS 볼륨의 시점 복사본을 S3에 저장하는 백업 기능

변경된 블록만 저장하는 증분 스냅샷 방식

초기 지연이 발생함 → 성능저하

Fast Snapshot Restore(FSR)

스냅샷에서 새 EBS 볼륨을 복원할 때 초기 지연을 없애고, 즉시 높은 성능 제공

기본 스냅샷 복원은 lazy load 방식이라, 복원 직후에는 성능 저하 발생 가능

→ FSR은 사전에 준비된 풀을 만들어 두어 즉시 고성능으로 시작 가

Q21. 하루 1개 제품만 판매하는 전자상거래 사이트, 밀리초 응답과 수백만 요청 처리 필요

한 전자상거래 회사는 AWS에서 하루 1회 웹사이트를 시작하려고 합니다.

  • 매일 정확히 1개의 제품만 판매합니다.
  • 회사는 피크 시간 동안 밀리초 단위 응답 지연 시간으로
  • 시간당 수백만 건의 요청을 처리할 수 있어야 합니다.

운영 오버헤드가 최소인 솔루션이 요구됩니다.

핵심

정적 웹 콘텐츠 제공(빠른응답)

짧은 시간에 폭발적인 트래픽 대응(Auto Scaling or 서버리스)

운영 오버헤드 최소화 → 관리를 자동으로(완전관리형 or 서버리스)

S3 + CloudFront ⇒ 빠른 정적응답

Lambda + DynamoDB ⇒ 서버리스 백엔드 + 고성능 확장 + 관리 필요없음

A. Amazon S3에서 정적 웹사이트 호스팅 + CloudFront 배포 설정 + 주문 데이터도 S3에 저장

주문 데이터까지 S3에 저장? → S3는 객체 저장소라 DB로 적합하지 않음 B. EC2 Auto Scaling 그룹에 ALB 구성, RDS(MySQL) 사용

EC2와 ALB RDS는 모두 고정 인프라 필요해서 운영 오버헤드가 큼 C. 애플리케이션을 Amazon EKS에 마이그레이션, Kubernetes 클러스터 자동 확장 사용

쿠버네티스 학습난이도 높고 운영 복잡함 D. Amazon S3에서 정적 웹사이트 호스팅 + CloudFront 배포 + 백엔드 API는 Lambda + DynamoDB

Q22. S3를 사용하는 디지털 미디어 애플리케이션 스토리지 아키텍처 설계

솔루션 설계자는 Amazon S3를 사용하여 새로운 디지털 미디어 애플리케이션의 스토리지 아키텍처를 설계하고 있습니다.

  • 미디어 파일은 가용 영역 손실에 대한 복원력이 있어야 하며,
  • 일부 파일은 자주 액세스되며,
  • 다른 파일은 예측할 수 없는 패턴으로 거의 액세스되지 않습니다.

스토리지 및 검색 비용을 최소화해야 합니다.

어떤 스토리지 옵션이 가장 적합합니까?

A. S3 Standard

자주 접속되는 거에 맞는 거

B. S3 Intelligent-Tiering

자동으로 이동시켜줌

C. S3 Standard-IA

저렴하지만 30일 이상 보관 + 예측 가능한 패턴이 있어야 함

D. S3 One Zone-IA

단일 AZ 이기 때문에 복원력 없음

S3 스토리지 클래스 전체 요약

클래스 특징 가용성 내구성 최소 저장 기간 삭제 수수료 주요 사용처

S3 Standard 기본, 자주 액세스 99.99% 11 9’s 없음 없음 자주 읽고 쓰는 일반 데이터
S3 Intelligent-Tiering 액세스 패턴에 따라 자동 계층화 99.9% 11 9’s 없음 일부 계층에 존재 액세스 패턴이 불확실한 경우
S3 Standard-IA 적게 읽고 자주 저장 99.9% 11 9’s 30일 있음 백업, 로그
S3 One Zone-IA IA보다 저렴, AZ 1개 99.5% 11 9’s 30일 있음 복구 가능 백업, 2차 데이터
S3 Glacier Instant Retrieval 저비용, 즉시 복원 99.9% 11 9’s 90일 있음 자주 접근 안 하지만 즉시 복구해야 하는 데이터
S3 Glacier Flexible Retrieval (이전: Glacier) 장기 보관, 느린 복원 99.99% 11 9’s 90일 있음 장기 백업, 보관 의무 데이터
S3 Glacier Deep Archive 최저비용, 가장 느림 99.99% 11 9’s 180일 있음 규제 목적 장기 보관, 1년에 1~2회 접근

사용 시점 정리

상황 추천 클래스 이유

실시간 웹 이미지, 동영상, 앱 콘텐츠 S3 Standard 빠른 응답, 높은 가용성
사용자 업로드 파일 (패턴 모름) Intelligent-Tiering 자동 계층 최적화
백업 데이터 (가끔 복원) S3 Standard-IA 읽기 적고 저장 위주
덤프 파일/로그, 복구용 복제본 S3 One Zone-IA 1개 AZ만 필요, 저렴
드물지만 즉시 복구해야 하는 기록 Glacier Instant Retrieval 빠른 복원 + 저렴
오랜 기간 법적 보관 Glacier Deep Archive 최저가, 12~48시간 복원
1년에 1~2회 볼까 말까한 데이터 Glacier Flexible Retrieval 스토리지 비용 절감 극대화

✅ 시험 포인트 문장

  • “S3 Intelligent-Tiering은 액세스 패턴이 불확실한 경우 자동으로 비용 최적화 계층으로 전환합니다.”
  • “S3 Glacier Deep Archive는 가장 저렴한 스토리지로, 복원 시간은 수 시간 이상이 소요됩니다.”
  • “S3 Standard-IA는 적은 빈도의 액세스를 위한 비용 최적화 스토리지로, 최소 저장 기간 30일이 있습니다.”
  • “S3 One Zone-IA는 단일 AZ에 저장되며, 복구 가능한 데이터에 적합합니다.”

Q24. EC2 비용 증가 → 인스턴스 유형의 수직적 확장 원인 분석

회사는 최근 청구서에서 EC2 비용이 증가한 것을 확인했습니다.

  • 청구 팀은 일부 EC2 인스턴스에서 예상치 않은 수직적 확장(인스턴스 유형 변경) 을 발견했습니다.

솔루션 설계자는 지난 2개월간 EC2 비용을 비교하는 그래프를 생성하고

비용 증가의 원인을 심층 분석하려고 합니다.

운영 오버헤드가 가장 적은 방식은 무엇입니까?

A. AWS Budgets를 사용하여 예산 보고서를 생성하고 인스턴스 유형별로 비용 비교

AWS Budgets는 비용 예측과 경보용임 원인분석에는 부적합

B.AWS Cost Explorer의 세분화된 필터링 기능을 사용하여 인스턴스 유형 기반 비용 분석

C. AWS Billing and Cost Management 대시보드의 그래프 사용

Billing 대시보드는 개요만 보여주며, 세분화된 필터링 불가함

D. AWS 비용 및 사용 보고서(CUR)를 S3로 내보내고 QuickSight에서 시각화

CUR + QuickSight는 강력하지만 구성 복잡하고 시각화 작업 필요 → 오버헤드 큼

AWS Cost Explorer

AWS 사용 비용과 사용량 데이터를 시각적으로 탐색하고 분석하는 도구

  • 비용/사용량 추세, 패턴 및 예측 분석이 가능
  • 여러기간 동안의 비용 데이터를 시각화
  • 필터 및 그룹화를 사용하여 서비스, 리전, 태그별 비용 분석 가능

비용 추세와 변동 원인을 파악하고, 비용 최적화 기회를 식별할 때

AWS Budgets

비용, 사용량 등을 목표로 하는 예산을 설정하고 모니터링

  • 예산 한도 초과, 예상 초과분 발생 시 알림 기능 제공
  • 비용, 사용량 및 예약 인스턴스 또는 Saving Plans 활용도에 대해 예산 설정 가능

비용 초과나 사용량 급증 등 예산 한도 준수를 실시간으로 모니터링하여 대응할 때

AWS Billing and Cost Management

AWS 비용 청구, 결제, 계정 관리 전반을 위한 대시보드 및 기능 제공

  • 월별 청구 내역 확인, 결제 방식 및 청구서 다운로드

AWS 청구서를 검토하여 비용 내역, 청구 세부사항, 결제 방식 등을 확인할 때

CUR + QuickSight

CUR(Cost and Usage Report)

매우 상세한 AWS 사용량 및 비용 데이터를 CSV, Parquet, ORC 등 다양한 형식으로 제공

  • AWS 서비스별, 리전별, 태그별로 원시 데이터를 집계하며 세부 분석 가능

상세한 정보가 필요하고 커스텀 보고서를 만들때

이러한 데이터를 시각화해 보고서를 만들기 위해 QuickSight와 연계해서 만들 수 있음

Q25. Lambda + Aurora 아키텍처에서 대량 데이터 처리 → 확장성과 구성 간소화

회사는 다음 구성의 애플리케이션을 설계하고 있습니다:

  • Amazon API Gateway → AWS Lambda 함수
  • Lambda는 Amazon Aurora PostgreSQL 데이터베이스에 정보를 저장합니다.

초기 개념 증명(PoC)에서는 데이터베이스에 대량의 데이터를 로드하려면 Lambda의 할당량을 크게 증가시켜야 했습니다.

→ 솔루션 설계자는 확장성 개선 + 구성 간소화를 목표로 새로운 아키텍처 설계를 추천해야 합니다.

A. Lambda 코드를 EC2에서 실행되는 Tomcat 애플리케이션으로 리팩터링. JDBC로 Aurora 연결

EC2는 서버 관리 필요 + 람다의 서버리스 이점 상실

B. Aurora를 DynamoDB로 변경하고 DAX 클러스터를 구성하여 호출 성능 개선

DynamoDB는 완전 다른 DB

C. Lambda 2개 구성. SNS를 통해 한 함수가 다른 함수를 호출해 Aurora에 데이터 로드

SNS는 푸시 기반 브로드캐스트에 적합함 대량처리에 비효율적

D. Lambda 2개 구성. SQS로 한 함수가 메시지를 전송하고, 다른 함수가 메시지를 받아 DB에 기록

SQS는 큐기반이기 때문에 대용량 처리에 유리

핵심

  • 대량 데이터 처리
  • Lambda 제한 완화
  • 구성 간소화 및 자동 확장

개념 증명 단계(PoC: Proof of Concept)

이 아이디어나 설계가 실제로 기술적으로 구현 가능한지를 소규모로 실험해보는 단계

SQS는 대용량 처리를 하기 좋음 큐에 담아두고 처리하면 되니까

Q26. S3 버킷의 무단 구성 변경 방지 및 감지

회사는 AWS 클라우드 배포를 검토하고 있으며,

Amazon S3 버킷이 무단으로 구성 변경되지 않도록 보호하고자 합니다.

솔루션 설계자는 이를 위해 무엇을 해야 합니까?

A. 적절한 규칙으로 AWS Config를 활성화한다. B. 적절한 검사를 통해 AWS Trusted Advisor를 활성화한다.

퍼포먼스, 보안, 비용 최적화 등에 대한 일반 가이드 제공만 함

→ 실시간 구성 변경 감지X C. 적절한 평가 템플릿으로 Amazon Inspector를 활성화한다.

주로 EC2, 컨테이너 취약점 스캔 등 보안 취약점 탐지 전용 D. Amazon S3 서버 액세스 로깅을 활성화하고, EventBridge를 구성한다.

변경 감지는 가능하나, 구체적 구성 변경의 정책 기반 평가/통제 기능은 부족 → Config가 더 정밀함

핵심

  • AWS Config는 AWS 리소스의 구성을 지속적으로 추적, 기록, 평가할 수 있는 서비스
  • S3 버킷 구성의 변경을 기록하고, 설정한 규칙과 다를 경우 자동으로 감지하고 경고를 생성
  • 또한 무단 변경에 대한 감사(Audit) 기능도 제공함

AWS Config

AWS 리소스 구성 변경을 기록하고, 규정 준수 여부를 평가할 수 있는 서비스

  • EC2, VPC, IAM, S3 등 리소스의 상태 변경 기록
  • 이전 구성과 현재 구성을 비교 가능
  • Config Rule을 설정하여 정책 위반 탐지 및 알림

시험 포인트

  • “AWS Config는 리소스의 구성 변경을 추적하고 규정 위반 여부를 자동 평가할 수 있습니다”

Amazon Inspector

EC2, 컨테이너, Lambda에 대한 취약점 및 보안 위험을 자동 스캔하는 서비스

  • 취약점 탐지
  • 자동 평가 보고서 생성

시험 포인트

  • “Amazon Inspector는 소프트웨어 취약성, 포트 오픈, 잘못된 접근성 등을 지속적으로 스캔합니다”

AWS Trusted Advisor

AWS 리소스 구성에 대해 5개 분야(비용, 보안, 고가용성, 성능, 서비스 할당량) 관점에서 최적화 권장 사항을 제공

  • 퍼블릭 S3 버킷 감지
  • 사용되지 않는 리소스 식별
  • 서비스 할당량 초과 알림
  • 예약 인스턴스 최적화 추천

간단한 권고 기반 리소스 점검 및 성능 튜닝

Q27 CloudWatch 대시보드를 AWS 계정 없는 외부 사용자에게 공유

회사는 새 애플리케이션을 시작했고, Amazon CloudWatch 대시보드에 애플리케이션 지표를 표시하고 있습니다.

**제품 관리자(Product Manager)**는 이 대시보드에 정기적으로 접근해야 합니다.

단, 제품 관리자에게는 AWS 계정이 없습니다.

솔루션 설계자는 **최소 권한 원칙(Least Privilege)**을 준수해야 합니다.

로그인 없이 제공하고 싶은 것

어떤 솔루션이 요구사항을 충족합니까?

A. CloudWatch 콘솔에서 대시보드를 공유하고, 이메일 주소 입력 후 공유 링크 제공

B. 제품 관리자용 IAM 사용자 생성, CloudWatchReadOnlyAccess 정책 연결, 로그인 정보 공유

계정만들어주는건 최소 권한 위배

C. ViewOnlyAccess IAM 사용자 생성, 콘솔로 대시보드 직접 찾아보게 안내

ViewOnlyAccesse도 AWS 로그인 필요.

D. 배스천 서버를 만들어 RDP 통해 대시보드 접근, 서버 내 캐시된 자격 증명 사용

베스천 서버 + RDP는 운영 오버헤드와 보안 리스크 큼 과도한 구성임

CloudWatch Dashboard Share

AWS 리소스의 모니터링 데이터를 시각화하여 보여주는 사용자 정의 대시보드

Share 기능을 통해 외부 사용자와 안전하게 공유할 수 있음(url)

배스천 서버

외부 인터넷과 내부 프라이빗 VPC를 안전하게 연결하는 중계 서버

보통 퍼블릭 서브넷에 위치하며, 프라이빗 서브넷의 EC2 인스턴스에 sSH 또는 RDP로 접근하기 위해 사용

RDP(Remote Desktop Protocol)(윈도우 계열의 ssh 같은 거)

윈도우 기반 서버/PC에 원경으로 접속할 수 있는 마이크로소프트의 원격 접속 프로토콜

Q28. 다계정 환경에서 온프레미스 AD 기반 SSO 설정 요구

회사는 AWS로 애플리케이션을 마이그레이션하고 있으며, 애플리케이션은 다양한 AWS 계정에 배포됩니다.

회사는 AWS Organizations를 사용해 이 계정들을 중앙에서 관리합니다.

보안 팀은 다음과 같은 요구사항을 갖고 있습니다:

  • 모든 계정에 대해 단일 로그인(SSO) 솔루션을 제공해야 하며,
  • 사용자 및 그룹 관리는 온프레미스에서 운영 중인 Microsoft Active Directory에서 유지해야 합니다.

어떤 솔루션이 이 요구사항을 충족합니까?

  • AWS Organizations ⇒ 다계정 환경
  • 온프레미스 Microsoft AD 사용자 관리 유지
  • AWS 리소스 접근에 대한 단일 로그인 제공

A. AWS SSO 콘솔에서 SSO를 활성화하고, AWS Managed Microsoft AD를 통해 온프레미스 AD와 단방향 트러스트(One-way trust) 구성

단방향 트러스트는 AWS에서 온프레미스 AD를 조회할 수 없어 사용자 인증 불가 B. AWS SSO 콘솔에서 SSO를 활성화하고, AWS Managed Microsoft AD와 온프레미스 AD 간에 양방향 트러스트(Two-way trust) 구성 C. AWS Directory Service에서 두 개의 트러스트를 포함한 Microsoft AD 디렉터리 구성

Directory Service 자체만으로는 SSO 구성 부족. IAM Identity Center와 통합되어야 함 D. 온프레미스에 IdP를 구축하고, SSO 콘솔에서 AWS SSO를 활성화

온프레미스에 IdP 구축은 관리 복잡성 증가, 별도 연동 설정 필요 → 운영 오버헤드 큼

SSO(Single Sign-On)

한 번 로그인하면 여러 시스템에 별도 인증 없이 접근 가능하게 하는 인증 방식

  • AWS SSO → AWS IAM Identity Center로 명칭 변경
  • 기업 내부의 Active Directory 또는 외부 IdP와 연동 가능
  • SAML 2.0, OIDC 기반 연동 가능

Microsoft Active Directory

사용자 계정, 그룹, 컴퓨터 등을 중앙에서 관리하는 Windows 기반 디렉터리 서비스

AWS Directory Service

AWS에서 마소 AD를 관리할 수 있도록 제공하는 서비스

AWS Managed Microsoft Active Directory: MAD 완전관리형

AD Connector: 온프레미스 AD에 연결하는 프록시 역할

트러스트

한 디렉토리가 다른 디렉터리의 사용자 인증을 신뢰할 수 있도록 설정한 관계

  • 도메인 트러스트
    • AD 내 도메인 간 인증 관계
  • 포리스트 트러스트
    • AD 포리스트 전체 간 인증 허용
  • 단방향
    • A가 B 신뢰 하지만 B는 A를 신뢰하지 않음
  • 양방향
    • A가 신뢰하면 B도 신뢰

IdP

인증을 제공하는 시스템

사용자의 로그인 정보를 확인하고 토큰을 발급

키워드 설명

AWS IAM Identity Center (구 AWS SSO) 여러 AWS 계정에 대해 중앙화된 사용자 접근 제어 제공
AWS Managed Microsoft AD AWS에서 관리하는 Microsoft AD 서비스. Trust 설정 가능
Two-way Trust AWS AD와 온프레미스 AD가 서로 사용자 인증 정보 공유 가능
AWS Organizations 다계정 환경을 중앙에서 관리하는 조직 단위 관리 도구

Q29. UDP 기반 VoIP 서비스 → 최저 지연 리전 라우팅 + 리전 간 장애 조치

회사는 UDP 연결을 사용하는 VoIP (Voice over IP) 서비스를 운영하고 있으며,

Auto Scaling 그룹 기반 EC2 인스턴스에 배포되어 있습니다.

  • 서비스를 여러 AWS 리전에 걸쳐 배포했고,
  • 사용자는 가장 지연이 낮은 리전으로 라우팅되어야 합니다.
  • 또한 **리전 간 장애 조치(Failover)**도 필요합니다.

어떤 솔루션이 요구 사항을 충족합니까?

핵심

  • UDP 지원 → NLB
  • 지연 시간 기반 리전 라우팅 → Global Accelerator
  • 지역 간 자동 장애 조치 → Global Accelerator

A. 각 리전에 NLB(Network Load Balancer)를 배포하고, 이를 AWS Global Accelerator 엔드포인트로 구성

B. 각 리전에 ALB(Application Load Balancer)를 배포하고, 이를 AWS Global Accelerator 엔드포인트로 구성 → ALB는 UDP 적용 못함

C. 각 NLB의 별칭을 Route 53 지연 시간 레코드로 연결하고, 이를 오리진으로 하는 CloudFront 배포 생성

CloudFront는 UDP 지원 불가 HTTP/HTTPS 전용

D. 각 ALB의 별칭을 Route 53 가중치 레코드로 연결하고, 이를 오리진으로 하는 CloudFront 배포 생성

ALB/CloudFront는 UDP 지원 불가 HTTP/HTTPS 전용

AWS Global Accelerator

사용자를 가장 가까운 리전으로 라우팅, 리전 장애 시 자동 장애 조치

VoIP 서비스 요건

  1. 낮은 지연 시간
  2. UDP
  3. 고가용성

Route 53

도메인 기반 라우팅 제공하지만

Global Accelerator 만큼 빠른 전환성/지능적 라우팅은 없음

Q30. 월 1회, 48시간 동안만 사용하는 RDS MySQL 테스트 인스턴스 → 비용 최적화 방안

개발 팀은 범용 Amazon RDS for MySQL 인스턴스에서 월 1회 리소스 집약적 테스트를 실행합니다.

  • 테스트는 한 번에 48시간 동안 지속되며,
  • 이 시간 외에는 데이터베이스를 사용하지 않습니다.
  • 팀은 컴퓨팅 및 메모리 속성은 유지하되,
  • 테스트 실행 비용을 줄이길 원합니다.

가장 비용 효율적인 솔루션은 무엇입니까?

RDS를 사용안한면

A. 테스트 완료 후 DB 인스턴스를 중지하고, 필요 시 재시작

인스턴스가 중지 되어도 EBS 스토리지 요금 청구됨

B. DB 인스턴스에 Auto Scaling 정책을 설정하여 테스트 완료 후 자동 확장

인스턴스 안꺼지면 돈 왕창

C. 테스트 완료 후 스냅샷 생성 → 인스턴스 종료 → 필요 시 스냅샷 복원

인스턴스 종료 → 삭제라는 것 비용 안나옴

스냅샷을 저장하다가 필요할 떄 복원 가능

가장 비용 절약

D. 테스트 완료 후 저사양 인스턴스로 변경, 필요 시 원래 인스턴스로 수정

수정하지 말라고 했으니 안됨

EBS

인스턴스 중지 ⇒ 요금 나옴

인스턴스 종료 ⇒ 제거되므로 요금 안나옴

'공부일지 > SAA 합격하기' 카테고리의 다른 글

AWS SAA 자격증 3주 준비 후기  (0) 2025.05.21
SAA 모의고사 5차 오답노트  (2) 2025.05.19
SAA 모의고사 4차 오답노트  (0) 2025.05.19
SAA 모의고사 3차 오답노트  (0) 2025.05.18
SAA 모의고사 2차 오답노트  (0) 2025.05.17

+ Recent posts

티스토리툴바