[SAA-C03] 문제 유형 71-80정리

Q71)

동일 AWS 리전

S3에 사진 자주 업로드/다운로드

데이터 전송 비용 증가

비용 줄여야 함

-> S3 트래픽이 인터넷을 통해 나가고 있을 가능성

(NAT gateway // 처리비용 발생)

 

-> 해결 S3로 가는 트래픽을 VPC 내부 경로로 보내기

S3 VPC Gateway Endpoint
-> VPC에서 S3로 직접 연결하는 내부 전용 통로

(인터넷 안 감, 데이터 전송 비용 줄어듦. 고성능)

 

 

#시험 포인트

S3 트래픽은 NAT 말고 VPC Endpoint로

---

Q72)

사내 네트워크에서 Bastion 접속 가능해야 함

Bastion을 통해 Private EC2 접속 가능해야 함
모든 EC2 보안 그룹이 이 흐름 허용해야 함

 

Bastion Host

-> 외부에서 내부 네트워크로 안전하게 들어올 수 있는 유일한 통로 

 

회사 안 직원이 AWS에 있는 서버에 접속해야 함
AWS에는 서버가 두 종류 있음
Bastion 서버 (퍼블릭 서브넷, 인터넷에서 접근 가능)
Application 서버 (프라이빗 서브넷, 인터넷에서 직접 접근 불가 //보안상)

흐름 : 회사 PC → 인터넷 → Bastion → Application 서버
// 보안 그룹을 어떻게 설정해야 이 흐름이 가능?

1. 회사 → Bastion
회사에서 인터넷 통해 Bastion에 SSH 접속

2. Bastion → Application 서버
Bastion을 통해서만 접근 가능

즉, 회사 안에서 접속해도 AWS 입장에서 보면
그 트래픽은 인터넷을 통해 들어오는 외부 트래픽
(직원 pc에서 인터넷 통해 나갈때는 공인 IP로 NAT 됨)
-> 회사의 외부 IP 범위에서만 인바운드 액세스를 허용하는 보안 그룹

Bastion이 Application 서버에 접속할 때는:
같은 VPC 안, 내부 네트워크로 통신
(같은 VPC 내부 통신은 Private IP로 이루어짐)
-> Bastion 서버의 Private IP에서 오는 SSH만 허용

 

#시험 포인트

Bastion은 외부 IP 허용, App은 Bastion Private IP만 허용

---

Q73)

구조 

Internet
   ↓
Web Tier (Public Subnet, EC2)
   ↓
Database Tier (Private Subnet, EC2 - SQL Server)

 

Web Tier는 외부에서 HTTPS(443) 받아야 함 
DB Tier는 외부에서 직접 접근하면 안 됨
Web Tier만 DB에 접근 가능해야 함
SQL Server 포트는 1433

 

0.0.0.0/0 에서 443 인바운드 허용 (Web Tier)
-> 웹 서버는 공개 서비스, HTTPS 433은 전세계 접근 가능

(보안그룹은 기본적으로 아웃바운드 모두 허용)

DB SG에서 1433 인바운드를 Web SG로부터 허용
-> DB는 외부 접근 X, Web Tier만 접근 허용
(데이터베이스는 보안상 인터넷에 직접 노출되면 안됨
-> 프라이빗 서브넷에 배치)

보안그룹 -> Security Group(SG)

 

 

#시험 포인트
Web은 443 공개, DB는 1433을 Web SG에서만 허용

---

Q74)

다계층 애플리케이션(온프레 -> AWS클라우드)

RESTful 서비스 통신

한 계층 오버로드시 트랙잭션 삭제 됨

문제해결, 현대화, 효율적 운영

 

한 계층 과부화되면 트랜잭션 유실

-> 동기식 구조고,  버퍼 없음

 

SQS로 디커플링

// 버퍼, 과부하 대기, 유실 방지

Lambda
// 자동확장, 현대화(서버리스)
API Gateway
// RESTful 구조 유지

RESTful 서비스

-> HTTP 기반으로 서로 직접 요청/응답하는 구조

(동기식 구조 -순차적처리, 바로 응답 기다림, 상대 서비스 죽으면 실패)

 

Service A -> SQS (메시지 저장) -> Service B (나중에 처리)

(비동기식 구조)

 

API Gateway → Lambda (REST 유지)
SQS를 통신 계층으로 사용
-> REST 구조 유지, 계층 간 통신은 비동기 변경

API Gateway 

-> HTTP 요청을 받아 Lambda 같은 백엔드 서비스로 전달하는 API 관문

 (즉, Lambda를 REST API로 “포장”해주는 역할)

 

 

#시험 포인트

RESTful API = API Gateway 사용
트랜잭션 삭제되는 문제 = SQS

---

Q75)

매일 10TB 데이터 수신

JSON 파일을 SAN 저장

S3 전송

near real-time 시스템에서 액세스

민감 데이터 안정적 전송

 

안정성,민감데이터,대량전송

-> Direct Connect가 기본 (+ AWS DataSync)

 

AWS DataSync
-> 온프레 파일 스토리지(NFS, SMB, SAN 등)를 

AWS 스토리지(S3, EFS 등)로 빠르게 전송하는 서비스

(파일 기반, 대량 데이터, 암호화, 거의 실시간 가까운 동기화)

SAN(Storage Area Network)

-> 스토리지 장치들을 고속 네트워크로 연결하여 서버들이

로컬 디스크처럼 접근할 수 있도록 하는 네트워크 환경

 

참고)  AWS DMS란?
데이터베이스를 다른 데이터베이스로 마이그레이션하는 서비스

 

 

#시험 포인트

파일(데이터) 전송은 DataSync, DB 전송은 DMS

---

Q76)

실시간 데이터 수집

스트리밍될 때 데이터 변환 필요(변환 프로세스 API)

저장 필요(데이터 스토리지 솔루션)

최소 운영 오버헤드

 

최소 운영  오버헤드 나오면 -> EC2는 의심

// 서버관리 필요, 패치/스케일링 관리 필요

 

API Gateway → Kinesis Data Streams -> Firehose -> Lambda (변환) -> S3

 

API Gateway
서버 없이 API 제공, 자동 확장
Kinesis Data Streams
실시간 스트리밍 수집
Firehose
관리형 전송 서비스, 자동 배치 처리
Lambda 
변환 로직, 서버리스

참고. API Gateway가 맨 앞에 오는 이유
-> 외부 요청을 받는 “입구” 역할(접수창구)
(외부에서 HTTP로 데이터 받아야 함)

없으면?
EC2 서버 만들어야 함 
직접 HTTP 서버 운영해야 함

 

 

#시험 포인트

실시간 스트리밍 수집은 API Gateway + Kinesis, 

변환은 Lambda, 저장은 S3

---

Q77)

트랜잭션 데이터를 DynamoDB 테이블에 보관

데이터를 7년간 보관 + 운영효율성

 

7년간 효율적으로 보관? -> 자동화

 

AWS Backup
-> AWS 서비스의 데이터를 중앙에서 자동 백업하고 보존 기간을 정책으로 관리하는 '관리형 백업 서비스'

 

중앙 백업 관리
백업 스케줄 자동화
보존 기간 설정 가능 (예: 7년)
여러 서비스 통합 관리
정책 기반 운영

 

 

#시험 포인트

DynamoDB 장기 보존은 AWS Backup

---

Q78)

데이터 저장 위해 DynamoDB 테이블 사용

비용 최적화 우려. 아침에 사용 거의 안함

저녁에는 트래픽 예측 못하는 경우 많음(트래픽 급증 빠름)

 

용량모드.

Provisioned 미리 용량 설정

On-Demand 요청 수에 따라 자동 확장
-> 자동 확장 / 트래픽 급증 대응 /

사용한 만큼만 과금 / 트래픽 예측 불필요

 

 

#시험 포인트

트래픽 예측 불가면 DynamoDB On-Demand

---

Q79)

앱 마이그레이션 이니셔티브에 대한 지원을 위한

MSP와 파트너 계약 체결

AMI(Amazon Machine Image)를 MSP AWS 계정과 공유

AMI는 EBS Snapshot의 지원 받음

KMS 고객 관리 키(CMK)로 스냅샷 암호화

공유하는 가장 안전한 방법

 

AMI(Amazon Machine Image)

-> EC2 인스턴스를 생성하기 위한 템플릿 (서버 복사본)

 

EBS란 EC2에 붙는 디스크고, Snapshopt은 디스크 백업 이미지

(AMI는 EBS 스냅샷을 기반으로 만들어진 EC2 템플릿)

 

AMI가 KMS로 암호화되어 있음

// AMI 뿐만 아니라 KMS 키 사용 권한도 공유해야함

 

-> AMI launchPermission을 MSP 계정으로만 제한
-> KMS 키 정책에서 MSP 계정에 사용 권한 부여 

(최소 권한, 특정 계정만 공유, 기존 키 유지 // 가장 안전)

(다른 키로는 자동 신뢰 불가 // 새로운 키 신뢰하도록 수정 X) 

 

launchPermission -> AMI를 실행할 수 있는 계정을 지정하는 권한

 

 

#시험 포인트

암호화된 AMI를 공유하려면 AMI 권한 + KMS 키 정책을 함께 수정

---

Q80) 자세히 읽으면 쉬운 문제

run in parallel (병렬 처리)
stateless (상태 없음)
loosely coupled (느슨한 결합)
job items durably stored (작업이 안전하게 저장됨)
scale based on number of jobs(작업 수에 따른 스케일)

 

안전한 저장과 느슨한 결합 나오면 -> SQS

 

add and remove nodes as needed based on the number of jobs

큐에 쌓인 작업 수 기준으로 스케일 -> SQS 메시지수
Launch Template을 권장. (Launch Configuration은 구식)

 

 

#시험 포인트

느슨한 결합 + 작업 보존 → SQS
작업 수 기준 확장 → SQS queue length 기반 Auto Scaling