[AWS] SAA 자격증 시험, 이 글 하나로 감 잡기 (1)

시험 후기 보기

2024.09.01 - [자격증] - [AWS] SAA 자격증 합격 후기, 합격 팁 공유 - Solutions Architect Associate (4주 소요)

[AWS] SAA 자격증 합격 후기, 합격 팁 공유 - Solutions Architect Associate (4주 소요)

 

 

안녕하세요,  올해 취업 후 아주 오랜만에 글을 작성하고 있습니다. 지난 방문 유입 통계를 보니 자격증 관련 글이 인기가 많더라고요. 그래서 제가 SAA 자격증을 공부하면 기록해 놓은 시험 정리본을 공유하고자 합니다. 저의 시험 후기는 위 게시물을 참고하면 좋을 것 같습니다. 

 

 

유데미에서 가장 유명한 SAA 자격증 강의입니다. 이 강의를 들으며 제가 한국어로 작성한 정리본입니다.

아예 AWS 서비스에 대한 이해가 없는 분이라면 이해가 어려울 수 있을 것 같습니다.

 

 

바로 시작하겠습니다.

 

 

정리본 공유 START

 

📕 IAM

• IAM은 권한 정책이다. 전체 서비스(글로벌)이기 때문에 리전을 선택하지 않아도 된다.
• IAM을 적용할 때, JSON 문서를 이용한다. → 최소 권한의 원칙을 적용한다.

 

🔎 (예시) IAM을 적용하는 법

{
	"Version" : "2012-10-17",
    "Id" : "S3-Account-Permissions",
    "Statement" : [
    	{
            "Sid" : "1",
            "Effect" : "Allow",
            "Principal" : {
            	"AWS" : ["arn:aws:iam:123456789:root"]
            },
            "Action" : [
            	"s3:GetObject",
                "s3:PutObject"
            ]
            "Resource" : ["arn:aws:s3:::your-bucket-name/*"]
        }
    ]
}

 

✅ 이렇게 코드를 작성하면 계정 123456789의 루트 사용자가
버킷 your-bucket-name 안의 객체를 읽기(GetObject)와 쓰기(PutObject) 할 수 있다.

 

 

Statement 구성요소

• Effect(효과) : Allow / Deny
• Principal(원칙) : 누구에게 이 권한을 줄 것인지? (사용자/계정/역할)
• Action(조치) : 어떤 행동을 허용/차단할 것인지? -> 허용/차단할 S3작업(API) 목록
• Resource(리소스) : 어떤 리소스에 적용할 것인지? -> 권한이 적용되는 대상(S3 버킷이나 객체)

 

Quiz)
Statement의 구성 요소가 아닌 것은?  -> Version(버전)

IAM 역할의 올바른 정의는?
→ AWS 서비스에 요청을 생성하기 위한 일련의 권한을 정의하고, AWS 서비스에 의해 사용될 IAM 객체

IAM 보안 도구에 해당되는 것은?
→ IAM 자격 증명 보고서

IAM 사용자 그룹은 IAM 사용자만 포함할 수 있다. (기타 그룹 포함 불가)

IAM 모범 사례는,
→ 루트 사용자 계정을 사용하지 않는다.

 

 

📕 EC2

• EC2는 AWS에서 가상 서버를 빌려 쓰는 서비스다.
• IaaS(Infrastructure as a Service)
• CPU, RAM, 스토리지(EBS/EFS), 네트워크를 원하는 대로 설정 가능하다.

💬 EC2의 핵심 구성요소

• EBS(Elastic Block Store) : 네트워크 기반 블록 스토리지
• ELB(Elastic Load Balancer) : 트래픽 분산
• ASG(Auto Scaling Group) : 트래픽/부하에 따라 EC2 자동 증감
• AMI(Amazon Machine Imange) : OS + 패키지 템플릿

 

📌 EC2 인스턴스

인스턴스 타입에는 t2.micro(무료), m5.2xlarge 등이 있다.

 

🔎 (예시) m5.2xlarge 해석

• m : 인스턴스 클래스
• 5 : 세대
• 2xlarge : 인스턴스 클래스의 사이즈

 

💬 인스턴스 유형

 

1️⃣ 범용 인스턴스 (General Purpose)

• 웹 서버나 코드 저장소와 같은 다양한 작업에 적합하다
• 균형 : 컴퓨팅, 메모리, 네트워킹

2️⃣ 컴퓨팅 최적화 인스턴스 (Compute Optimized)

• 컴퓨터의 집약적인 작업에 최적화된 인스턴스(고성능)
• CPU와 컴퓨팅을 요구하는 작업을 수행
• 모두 C로 시작하는 이름을 가지고 있다.

3️⃣ 메모리 최적화 인스턴스 (Memory Optimized)

• 메모리에서 대규모 데이터셋을 처리하는 유형의 작업에 빠른 성능을 제공한다.
• 인 메모리 데이터베이스가 되는 고성능의 관계형 또는 비관계형의 데이터베이스에 사용
• 분산 웹스케일 캐시 저장소
• BI에 최적화된 데이터베이스

4️⃣ 스토리지 최적화 인스턴스 (Storage Optimized)

• 로컬 스토리지에서 대규모 데이터셋에 접근할 때
• OLTP(온라인 트랜잭션 처리)
• 관계형 비관계형 NoSql
• Redis
• 분산 파일 시스템

 

📌 EC2의 네트워킹 & 보안

💬 보안 그룹 (Security Group)

• EC2의 방화벽 역할을 한다. (인바운드/아웃바운드 통제)
• 허용 규칙만 존재한다. 즉, 규칙에 없는 트래픽을 차단.
• 보안 그룹은 서로 참조할 수 있다.
• IP를 기준으로 설정할 수 있다.

💬 퍼블릭 IP vs 프라이빗 IP vs 탄력적 IP

• 퍼블릭 IP: 인터넷 접근용
• 프라이빗 IP: 내부 VPC 통신용
• 탄력적 IP: 고정 퍼블릭 IP

💬 포트 번호

• 22 : SSH (Secure Shell) - 리눅스 인스턴스 용
• 21 : FTP (File Transfer Protocol)
• 22 : SFTP (Security File Transfer Protocol)
• 80 : HTTP
• 443 : HTTPS
• 3389 : RDP (Remote Desktop Protocol) - 윈도우 인스턴스용

 

📌 EC2 구매 옵션

💡 TIP
이러한 상황에는 어떤 구매 옵션을 선택해야 할까?라는 문제가 출제된다.

 

1️⃣ EC2 On Demand(온디맨드)

• 필요할 때 바로 쓰고, 사용한 만큼 요금을 지불한다.
• 유연하지만 비싸다.

2️⃣ EC2 Reserved Instances(에약 인스턴스)

• 예약하여 사용하며 온디맨드보다 72% 정도 저렴하게 이용할 수 있다.
• 1년 또는 3년 약정 계약이다.

3️⃣ EC2 Savings Plans(절약 플랜)

• 2번 예약 인스턴스와 비슷하지만, 차이점은 특정 인스턴스를 예약하는 것이 아닌 시간당 사용량을 예약한다.
• 1년 또는 3년 약정 계약이다.

4️⃣ EC2 Spot Instances(스팟 인스턴스)

• AWS에서 남는 컴퓨팅 자원을 싸게 빌려주며 할인 폭이 제일 크다.
• 하지만 AWS가 자원을 회수한다면 인스턴스는 종료되고 그 자원은 손실된다.
• 아주 중요한 작업이나 데이터베이스에서는 적절하지 않다.
• 중단되어도 괜찮은 작업(데이터 분석, 머신러닝 학습, 배치작업)에 사용한다.

5️⃣ EC2 Dedicated Hosts(전용 호스트)

• 실제 물리적 서버를 내 계정 전용으로 할당받는다. (가장 비싼 모델)
• 온디맨드로 지불하거나 1년 또는 3년 동안 예약할 수 있다.
• 라이선스가 있는 회사에서 주로 사용한다.

6️⃣ EC2 Dedicated Instances(전용 인스턴스)

• AWS가 내 전용 물리서버에 EC2 인스턴스를 띄워준다. 하지만 서버 자체(하드웨어)는 보이지 않는다.
• "내 인스턴스가 다른 사람 인스턴스와 같은 물리 서버에 올라가지 않는다." 정도를 보장해 주는 것이다.
• 보안 및 규제 때문에 물리적 서버 공유를 피해야 할 때 사용한다.

🙋🏻‍♀️ Hosts vs Instances 차이점

전용 호스트는 물리 서버 그 자체를 내가 소유/관리하듯 쓸 수 있다.

전용 인스턴스는 내 인스턴스 전용 물리 서버에 올라가지만, 서버 자체는 보이지 않는다.

 

7️⃣ EC2 Capacity Reservations(용량 예약)

• 특정 가용영역(AZ)에 EC2 인스턴스를 띄울 용량을 미리 확보하는 기능이다.
• 온디맨드 요금이 부과된다.
• 필요할 때 용량이 반드시 확보되어야 하는 상황에 적합하다. (이벤트, 세일시즌, 금융 서비스, 의료 서비스)

9️⃣ Spot Fleets (요금을 절감하는 가장 효과적인 방법)

• 여러 개의 스팟 인스턴스 + 필요하다면 온디맨드 인스턴스까지 묶어서 가장 저렴한 조합으로 자동/실행 관리해 주는 서비스다.
• 쉽게 설명한다면, AWS에게 내가 원하는 성능을 이 예산 안에서 맞춰줘!라고 하는 것이다.
• 동작 방식 :
  • 사용자가 목표(capacity)를 정한다. (예: vCPU 100개, GPU 4개 등)
  • 여러 인스턴스 유형 / 여러 AZ 조합을 제시해 놓음
  • Spot Fleet이 자동으로 가장 싼 조합을 찾아서 인스턴스를 띄운다.
  • 인스턴스가 회수되면 다른 스팟/온디맨드로 다시 채워 넣는다.
• 비용을 극단적으로 줄이고 싶을 때 사용한다.
• 대규모 분산 작업에 사용한다. (빅데이터 분석, 대량배치 작업, 머신러닝 학습)

 

📌 EC2 배치그룹(Placement Group)

• EC2 인스턴스가 AWS 인프라에서 어떤 방식으로 배치될지 지정하는 서비스다.
• 내 인스턴스들을 어떤 위치(서버, AZ, 랙)에 놓을지 AWS에게 알려주는 옵션이다.
• 배치그룹을 선택하는 3가지 방식이 있다.

💡 TIP
이러한 상황에는 어떤 배치 옵션을 선택해야 할까?라는 문제가 출제된다.

 

1️⃣ Cluster

• 모든 인스턴스가 같은 물리적 랙에 배치된다.
• 장점 : 고속 네트워크, 낮은 지연, 높은 처리량
• 단점 : 가용영역에 장애가 발생하면 모든 인스턴스가 동시에 장애를 일으킨다.
• 빅데이터 작업, 처리량이 많은 작업(HPC)에 적합

2️⃣ Spread

• 여러 가용 영역에 분산시킨다.
• 장점 : 동시 실패의 위험이 감소한다.
• 단점 : 하나의 AZ당 최대 7개의 인스턴스로 제한이 된다. 배치 그룹 규모에 제한이 있다.
• 중용한 서버 거나 가용성을 극대화하고 싶을 때 사용한다.

3️⃣ Partition

• 여러 AZ의 파티션 단위로 인스턴스를 분산시킨다.
• 장점 : 서로의 랙 실패로부터 안전하다.
• HDFS, HBase, Cassandra, Apached Kafka 같은 대규모 분산 시스템에 사용한다.

 

📌 EC2 ENI(Elastic Network Interfaces)

• 가상 네트워크 인터페이스로, EC2 인스턴스에 부착할 수 있는 네트워크 어댑터다.
• IP주소, 서브넷, 보안그룹, MAC 주소 등의 네트워크 속성을 부착할 수 있다.
• 하나 이상의 보안그룹을 연결할 수 있다.
• EC2 인스턴스와 독립적으로 생성/이동 가능하다.
• AZ 단위로 고정이므로, 다른 AZ에 있는 EC2 인스턴스와 연결될 수 없다.
• 보조 ENI는 고가용성/이중화에 활용된다.

 

📌 EC2 Hibernate mode (절전 모드)

• EC2 인스턴스가 RAM 상태를 EBS에 저장하고, 종료 후 다시 켜면 그대로 이어서 부팅한다.
• 최대 60일 동안 이용할 수 있다.
• EC2 인스턴스 RAM은 150GB 미만이어야 한다.
• 온디맨드 및 예약 인스턴스를 지원한다.
• 루트 볼륨 유형은 EBS 볼륨이어야 한다. (인스턴스 스토어 볼륨 X)

1. 절전모드를 켠다.
2. 실행 중인 인스턴스는 중지 상태로 전환되고 RAM의 내용은 EBS 볼륨에 저장된다.
3. 인스턴스를 종료하면 RAM이 사라진다.
4. 하지만 볼륨에 여전히 존재하기 때문에 인스턴스를 재시작하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.
5. 인스턴스를 중지한 적이 없는 효과를 볼 수 있다.

 

📌 EC2 인스턴스 스토리지

🎯 시험 포인트
EBS = 블록 스토리지, AZ 단위, 스냅샷으로 백업/이동
AMI = 미리 설치된 이미지 → 빠른 배포
Instance Store = 임시 로컬 디스크, EC2 종료 시 데이터 손실
EFS = 여러 AZ/EC2 공유 가능, NFS 기반

 

1️⃣ EBS 볼륨 (Elastic Block Volume)

• EC2 인스턴스에 연결 가능한 블록 스토리지다.
• 인스턴스를 재생성하고 EBS 볼륨을 마운트 하면 데이터를 다시 받을 수 있다.
• 인스턴스는 여러 개의 볼륨을 가질 수 있지만, 볼륨은 하나의 인스턴스에만 연결될 수 있다. 
• 하나의 가용 영역에 한정된다. (us-east-1a에서 생성된 볼륨은 us-east-1b로 연결이 불가능하다.)

💬 종료 시 삭제 옵션 설정이 가능하다. (Delete on Termination)

• 기본 설정으로는 루트 볼륨에 체크되어 있다. 이 경우에 종료 시 볼륨이 삭제된다.
• 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 삭제 속성을 비활성하면 된다.
• EC2 인스턴스를 종료하면, 루트 볼륨 유형은 삭제되고 EBS 볼륨 유형은 삭제되지 않는다.

💬 EBS 볼륨 유형은 다음과 같다.

유형	저장 매체	특징	용도
gp2 / gp3	범용 SSD	낮은 대기시간, 비용 효율	부팅 볼륨, 가상 데스크톱, 개발/테스트 환경
io 1 / io 2	SSD (Provisioned IOPS 볼륨)	지속적인 고성능 IOPS 제공, 16,000 IOPS 이상 가능	DB, I/O 민감 애플리케이션
st 1	HDD	높은 처리량, 저비용	빅데이터, 로그, 스트리밍
sc 1	HDD	매우 저비용, 낮은 성능	장기보관, 백업, 데이터 아카이브

 

io1과 io2 제품군에 한해서만, 하나의 볼륨이 여러 개의 인스턴스와 연결될 수 있다. (한 번에 16개만 가능)

 

💬 EBS 스냅샷은 EBS 볼륨의 특정 시점에 대한 백업이다. AZ 간 이동이 가능하므로 us-east-1A의 EBS의 스냅샷을 찍고 us-east-1B에 연결하면 한 AZ에서 다른 AZ로 전송이 가능하다.

• EBS Snapshot Archive
  • 75% 저렴하게 스냅샷을 옮기는 방법
  • 복원하는데 24시간~72시간 걸림
• Recycle Bin for EBS Snapshots
  • EBS 스냅샷을 삭제하는 경우 영구 삭제하는 대신에 휴지통에 넣을 수 있다.
  • 1일에서 1년 사이로 보존 기간을 설정할 수 있다.
• Fast Snapshot Restore(FSR)
  • 빠른 스냅샷 복원, 스냅샷을 완전 초기화해 지연 시간을 줄임
  • 비용이 많이 든다.

 

2️⃣ AMI (Amazon Machine Image)

• EC2 인스턴스를 통해 만든 이미지를 통칭
• 인스턴스에 설치하고자 하는 모든 소프트웨어를 AMI가 미리 패키징 해준다.
• 특정 AWS 리전에 국한되며 각 AWS 리전에는 고유한 AMI가 있다.

💬 Golden AMI

• EC2 인스턴스에 필요한 OS+소프트웨어+종속성을 미리 설치하고 설정한 표준 이미지
• 즉, 언제든 바로 쓰는 준비된 EC2 이미지

Quiz)
솔루션 아키텍트로서, 여러분은 복잡한 ERP 소프트웨어 스위트를 AWS Cloud로 이전하려 합니다. 오토 스케일링 그룹이 관리하는 한 세트의 Linux EC2 인스턴스에 소프트웨어를 호스팅 할 계획입니다. 소프트웨어가 Linux 기기를 준비하는 데에는 보통 한 시간 이상이 걸립니다. 스케일 아웃이 발생할 경우, 설치 과정을 빠르게 만들기 위해서는 어떤 방법을 추천할 수 있을까요?
→ Golden AMI 사용

애플리케이션을 Elastic Beanstalk으로 배포하던 도중, 배포 프로세스가 극도로 느리다는 것을 알게 되었습니다. 로그를 검토한 결과, 종속성이 매 배포 당 각 EC2 인스턴스로 리졸브 된다는 사실을 발견했습니다. 영향을 최소화하면서 배포 프로세스를 빠르게 하려면 어떻게 해야 할까요?
→ 종속성을 포함하는 Golden AMI를 생성해 그 이미지를 EC2 인스턴스 실행에 사용

 

 

3️⃣ EC2 인스턴스 스토어

• EC2 인스턴스와 물리적으로 연결된 임시 디스크다.
• 고성능의 하드웨어 디스크가 필요할 때 사용한다.
• 인스턴스 스토어를 종료하면 해당 스토리지 또한 손실되므로 임시 저장용이다.
• EC2 종료 시 캐시 손실이 괜찮고, IOPS 높은 데이터베이스를 사용할 때 적합하다.

Quiz)
310,000의 IOPS를 요구하는 고성능 데이터베이스가 있다. 다음 중 무엇을 추천해야 할까?
→ EC2 인스턴스 스토어 사용

 

 

4️⃣ Amazon EFS(Elastic File System)

• NFS 기반 네트워크 파일 시스템이다.
• 여러 개의 EC2 인스턴스에 마운트 될 수 있고 다른 가용 영역에서도 가능하다.
• 내부적으로 NFS protocol을 사용한다. 액세스 제어를 위해 보안 그룹을 설정해야 한다.
• 윈도우가 아닌 Linux 기반 AMI(Amazon Machine Image)와만 호환된다는 점이다.
• 다수 AZ 인스턴스에서 공유 데이터 필요하거나 대규모 파일 시스템을 구축할 때 적합하다.

Quiz)
대량의 데이터 세트를 처리하는, 다수의 AZ에 걸친 EC2 인스턴스 플릿이 있다. 동일한 데이터가 NFS 드라이브로서 모든 EC2 인스턴스에서 액세스 할 수 있게 만들기 위해서는 어떤 방법을 추천할 수 있을까?
→ EFS

EC2 인스턴스에 호스팅 된 애플리케이션에 고성능 로컬 캐시를 포함시키려 한다. EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황이다. 이런 경우, 솔루션 아키텍트로서 어떤 스토리지 메커니즘을 추천할 수 있을까?
→ 인스턴스 스토어

기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있다. 어떤 방법을 추천할 수 있을까?
→ EC2 인스턴스 스토어

 

 

 

📕 고가용성 및 스케일링성

💬 수직확장성 : t2.micro → t2.large

• 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용된다.
• ex) 신입직원을 경력직원으로 교체
• RDS

💬 수평확장성

• 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법이다.
• ex) 신입직원을 더 뽑는다.
• EC2

💬 고가용성

• 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에 가동 중이라는 것을 의미한다.
• 센터가 하나 멈춰도 계속 작동하도록 한다.

💬 인스턴스의 수가 늘어나면 스케일 아웃, 줄어들면 스케일 인

 

📌 ELB & 로드밸런서

로드밸런서란 트래픽을 여러 EC2인스턴스나 서버로 분산하는 것이다.

ELB는 Elastic Load Balancer를 가리키는데, AWS가 관리해주는 로드밸런서를 말한다. 알아서 EC2의 상태를 확인하고 정상적으로 작동하는 인스턴스에만 트래픽을 전송한다.

 

1️⃣ ALB(Application Load Balancer)

• HTTP/2, WebSocket을 지원한다.
• 여러 대상 그룹으로 라우팅할 수 있다. 
  • EC2 인스턴스
  • Private IP 주소
  • Lambda 함수

2️⃣ NLB(Network Load Balancer)

• 성능이 매우 좋다. (고성능 TCP/UDP 처리)
• AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있다.
• 상태 확인에 3가지 프로토콜을 지원한다.
  • TCP 프로토콜
  • HTTP 프로토콜
  • HTTPS 프로토콜

Quiz)
규정 준수를 위해, 고정된 정적 IP 주소를 최종 사용자에게 노출하여 사용자들이 안정적이고, 규제 기관의 승인을 받은 방화벽 규칙을 작성할 수 있도록 하려 한다. 이런 경우, 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까?
→ NLB

 

3️⃣ GWLB(Gateway Load Balancer)

• 네트워크 전체 트래픽을 분석한다.
• IDPS, 패킷 분석용
• 6081번 포트의 GENEVE 프로토콜을 사용하여 네트워크 트래픽을 캡슐화하여 보안장치(방화벽)으로 전달한다. 

 

4️⃣ Sticky Sessions(고정 세션)

• 클라이언트의 요청이 항상 같은 백엔드 인스턴스로 전달되도록 만드는 기능이다. (쿠키)
• 예를 들어, 사용자의 로그인 상태를 유지하기 위해 같은 사용자 요청은 계속 같은 서버로만 보내지도록 하여 로그인을 유지한다.

2가지 유형의 쿠키 전략을 사용한다.

1. 애플리케이션 기반 : 쿠키 이름은 `AWSALB`, `AWSALBAPP`이다.
2. 기간 기반 : 쿠키 이름은 `AWSALB`, `AWSELB`이다.

 

5️⃣ Cross-Zone Load Balancing

• 로드밸런서가 모든 AZ 인스턴스에 트래픽을 균등하게 분배한다.
• ALB는 자동 활성화 되며, 추가 비용은 없다.
• NLB/GWLB은 수동 설정이 필요하고, 비용이 발생할 수 있다.

 

6️⃣ SSL/TLS & ACM & SNI(Server Name Indication)

• SSL/TLS은 클라이언트와 로드밸러서 간의 트래픽을 암호화한다.
• ACM은 AWS 인증서를 관리한다.
• SNI는 하나의 로드밸러서에 여러 SSL 인증서 사용이 가능하도록 해준다.

Quiz)
다음과 같은 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅 하도록 구성된 Application Load Balancer가 있다: users.example.com, api.external.example.com, checkout.example.com. 이 각각의 호스트 이름에 HTTPS를 구성하려 한다. 이런 작업을 위해서는 ALB를 어떻게 구성해야 할까?
→ SNI

 

7️⃣ Connection Draining

• 인스턴스가 종료/등록 해제 되더라도 기존 연결 요청을 끝까지 처리하도록 한다.

 

📌 Auto Scaling Group(ASG)

• AWS에서 EC2 인스턴스의 수를 자동으로 조절할 수 있는 기능을 제공한다.
• ASG는 사용자가 정의한 조건에 따라 인스턴스 수를 자동으로 늘리거나 줄여서, 애플리케이션이 일정한 성능과 가용성을 유지하도록 돕는다.

💬 스케일링 정책

• 동적 정책 : CloudWatch 알림 기반으로 자동 확장/축소한다.
• 스케쥴 정책 : 시간 기반으로 확장/축소한다.
• 예측 정책 : 부하를 예측하여 인스턴스를 미리 확보한다.

정책	특징	사용 사례
대상 추적(Target Tracking)	목표값 유지 (자동 온도조절기)	CPU 50% 유지, ALB 연결 1,000개 유지
단계 조정(Step Scaling)	임계 초과 정도에 따라 단계적 스케일링	CPU 70% → +1, CPU 90% → +3
단순 조정(Simple Scaling)	조건 발생 시 정해진 개수만 조정	CPU 70% → 인스턴스 1개 추가
예측 조정(Predictive Scaling)	과거 패턴 학습 후 미래 수요 대비	매일 9시 트래픽 폭주 대비

 

💬 주요 Metric

• CPU 사용률
• 타겟당 요청 수
• 네트워크 사용량
• 커스텀 Metric 가능

Quiz)
한 애플리케이션이 ALB(Application Load Balancer)와 ASG(Auto Scaling Group)를 통해 배포되었다. 이 상태에서
ASG의 크기를 수동으로 조정해, EC2 인스턴스의 평균 연결 개수가 약 1,000개가 되도록 조정 정책을 정의하려고 한다. 어떤 조정 정책을 사용해야 할까?
→ 대상 추적 조정 정책(Target Tracking Scaling Policy)

 

📕 RDS(Relational Database Service)

📌 Amazon RDS

• RDS가 지원하는 엔진은 여러 개다.(Aurora, PostgreSQL, MySQL, MariaDB, Oracle, ...)
• AWS가 관리하는 DB이기 때문에 자동 백업, Multi-AZ, 읽기 전용 복제본, IAM인증, 보안그룹, 암호화 등을 지원한다.
• 단, RDS 인스턴스에 SSH 접근은 불가하다.

📌 Aurora

• MySQL, PostgreSQL 호환된다.
• 성능 ↑ (MySQL 대비 5배, PostgreSQL 대비 3배)
• 스토리지를 자동 확장한다.

💬 고가용성 & 확장성

• 3개의 리전에 총 6개(2*3)의 복제본이 생긴다.
• 손상이 있으면 백엔드에서 P2P 복제를 통한 자가 복구가 진행된다.
• 단일 볼륨이 아닌 수 백 개의 볼륨을 사용한다.
• 쓰기가 가능한 마스터는 단 한 개이며 읽기는 16개까지 둘 수 있다.

💬 Aurora 클러스터 엔드포인트

• Writer 엔드포인트는 DNS 이름으로 항상 마스터를 가리킨다.
• Reader 엔드포인트는 자동 로드밸런싱된 읽기 복제본을 연결한다.
• Custom Endpoint는 특정 읽기 복제본 그룹에 연결할 수 있다.

💬 Aurora 고급 기능

 

1. 오토 스케일링
   • 읽기 복제본 자동 추가/삭제
   • 특정 복제본에 특정 쿼리를 보내도록 Custom Endpoint 사용
2. Aurora Serverless
   • 사용량 기반 자동 확장
   • 예측 불가능/간헐적 워크로드에 적합
3. Global Aurora (글로벌 DB)
   • 1차 리전 (RW) + 최대 5개 보조 리전 (RO)
   • 보조 리전당 최대 16개 읽기 복제본
   • 복제 지연 < 1초, 리전 장애 시 1분 이내 복구
4. Aurora DB Cloning
   • Copy-on-write 방식 → 빠른 복제
   • 테스트/스테이징 환경 구축에 적합
5. Aurora + ML 통합
   • DB 쿼리에서 바로 AI/ML 모델 호출 가능

Quiz)
주 AWS 리전에 재해가 발생했을 때에 대비하여 다른 AWS 리전에 데이터베이스의 복제본을 만들어 두려 한다. 이런 작업을 쉽게 구현하기 위해서는 어떤 데이터베이스의 사용을 추천할 수 있을까?
→ Aurora 글로벌 데이터베이스(Aurora 글로벌 데이터베이스를 사용하면 최대 5개의 2차 리전까지 Aurora 복제본을 가질 수 있다.)

 

📌 RDS & Aurora 백업

💬 RDS 백업

• 비용을 절감하고 싶을 때도 RDS를 백업한다. 하루에 두 시간만 사용한다면 두시간 사용 후 스냅숏을 만든 다음 원본 데이터베이스를 삭제하면 된다. 그리고 다시 스냅샷을 복원하여 사용한다.
• RDS에는 Amazon S3에서 백업 파일을 복원하는 옵션이 있다.

💬 Aurora 백업

• Aurora는 자동 백업을 비활성화할 수 없다.
• RDS MySQL로 복원할 때는 데이터베이스의 백업만 있으면 되었지만, Aurora MySQL은 Percona ZtraBackup으로 백업을 한 다음, S3에서 Aurora DB Cluster로 백업을 하면 된다.

 

📌 RDS Proxy

 

• DB 연결 풀링 제공
• Lambda, 서버리스 환경에서 DB 연결 효율 ↑
• 장애 조치 시간 66% 감소
• IAM 인증 강제 가능 (자격 증명은 Secrets Manager에 저장)
• 지원 엔진: RDS MySQL, PostgreSQL, MariaDB / Aurora MySQL, PostgreSQL
• 보안: 퍼블릭 액세스 ❌, 오직 VPC 내부 연결만 가능

 

📌 Amazon ElastiCache

• Redis / Memcached를 지원한다.
• 읽기 집약적 워크로드에서 DB 부하가 감소된다.
• 캐시를 먼저 조회하도록 애플리케이션 코드 수정이 필요하다.(코드 변경이 필요 없는 캐싱 솔루션을 물어본다면 ElastiCache는 답이 될 수 없다.)

특징	Redis(복제되는 캐시)	Memcached(분산되어 있는 캐시)
복제	지원 (Multi-AZ, HA)	❌
백업/복원	지원	❌
데이터 구조	String, Hash, List, Set, Sorted Set	Key-Value
인증	Redis AUTH, IAM 인증	SASL
용도	세션 저장, 리더보드, 복잡한 데이터 캐시	단순 캐시, 샤딩