모의고사 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로 손쉽게 연결할 수 있도록 설계되었음
- AWS Transfer Family
- 작은 파일 다수, 주기적 수신 → 이벤트 기반 수신으로 자동 처리
- 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 글로벌 네트워크로 전달
- 사용자와 가장 가까운 엣지 로케이션으로 트래픽 유도
- 그 후 엣지로케이션에서 연결된 백본망을 통해 이동
→ 백본망이라 빠름 그래서 지연 낮아짐
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 |