[week2] RDS, Aurora & ElastiCache + Route 53

HyeGyeong/EC2 Instance Storage/AMI(Amazon Machine Image).md

@@ -0,0 +1,32 @@
+
+EC2 인스턴스를 기반으로 만든 **머신 이미지**다. EBS Snapshot 처럼 볼륨의 데이터 백업하는게 아닌, 루트 EBS 볼륨과 추가 볼륨을 모두 포함해서 OS, 설정 등 EC2 인스턴스를 통째로 백업한다.
+
+## AMI의 종류
+
+| 종류                  | 설명                                   |
+| ------------------- | ------------------------------------ |
+| **Public AMI**      | AWS가 기본 제공하는 이미지 (예: Amazon Linux 2) |
+| **Custom AMI**      | 사용자가 직접 구성한 이미지, 유지보수도 직접            |
+| **Marketplace AMI** | 다른 사용자가 구성하여 판매하는 이미지, 시간 절약 가능      |
+
+## 장점
+
+- **커스터마이징 가능**
+	- 원하는 소프트웨어, 설정 파일, 운영체제, 모니터링 툴 등을 미리 포함 가능
+- **글로벌 인프라 활용**
+	- AMI를 한 리전에 만든 뒤 **다른 리전으로 복사 가능**
+- **EC2 인스턴스 실행 시 활용**
+	- 기존 EC2를 중지 후, 이를 기반으로 AMI 생성 → 다른 AZ에서 복제 실행 가능
+
+## AMI 생성 절차
+
+1. EC2 인스턴스를 원하는 대로 설정
+2. 인스턴스를 **중지(stop)** (데이터 무결성 확보)
+3. 해당 인스턴스로부터 **AMI 생성**
+4. AMI를 활용해 **다른 가용영역(AZ)이나 리전에서 인스턴스 실행**
+
+## 예시 흐름
+
+- `us-east-1a`에서 EC2 인스턴스 설정 → AMI 생성  
+→ `us-east-1b`에서 이 AMI로 EC2 인스턴스 실행  
+→ 기존 인스턴스의 **복사본 생성**

HyeGyeong/EC2 Instance Storage/EBS VS EFS.md

@@ -0,0 +1,29 @@
+### 1. **연결 방식**
+
+- **EBS**:
+    - EBS 볼륨은 **하나의 EC2 인스턴스에만 연결**가능. 하지만, io1과 io2 볼륨에서는 Multi-Attach 기능을 활용하여 여러 인스턴스에 연결 가능
+    - **같은 Availability Zone** 내에서만 사용할 수 있으며, **다른 AZ로 이동하려면 스냅샷을 사용**해야함
+- **EFS**:
+    - **네트워크 파일 시스템**으로, **Availability Zone**에 상관없이 여러 인스턴스에 연결 가능
+
+### 2. **백업 및 성능**
+
+- **EBS**:
+    - **EBS 백업은 I/O를 사용**하므로 **애플리케이션의 성능에 영향을 미칠 수 있다.
+    - **EC2 인스턴스 종료 시 EBS 볼륨도 함께 종료 되는 것이 디폴트 값** (변경 가능)
+- **EFS**:
+    - **네트워크 파일 시스템**이므로 **백업에 I/O가 거의 영향을 미치지 않음**.
+
+### 4. **가격**
+
+- **EBS**:
+    - EBS는 **가격이 EFS보다 저렴**하며, **디스크 크기와 IOPS**에 따라 가격이 달라짐.
+- **EFS**:
+    - **EBS보다 약 3배 더 비쌈**. 하지만 **스토리지 계층**을 사용하여 **비용 절감 가능**
+
+### 5. **호환성**
+
+- **EBS**:
+    - EBS는 **Linux 및 Windows 인스턴스**에서 모두 사용 가능
+- **EFS**:
+    - EFS는 **POSIX 시스템**을 지원하며, **Linux 기반** 인스턴스에서만 사용 가능

HyeGyeong/EC2 Instance Storage/EBS(Elastic Block Store).md

@@ -0,0 +1,168 @@
+## EBS 볼륨이란?
+
+EC2에 연결하는 네트워크 기반의 USB라고 생각하면 된다. 네트워크로 연결되니 지연이 있고, 인스턴스가 종료되어도 데이터가 유지된다. USB처럼 연결(Attach)과 분리(Detach)가 자유롭다.
+
+## 연결
+
+컴퓨터(EC2)와 USB(EBS)의 관계를 생각하면 편하다.
+
+![[Pasted image 20250430221331.png]]
+
+- **하나의 EBS는 하나의 인스턴스에만 연결 가능**
+- **둘의 availability Zone이 다르면 연결 불가
+	- `us-east-1a`에서 생성된 EBS는 `us-east-1b`와 연결 불가
+	- 단, 스냅샷 활용시 이동 가능
+- **EBS는 인스턴스 없이도 존재 가능**
+- **하나의 인스턴스에 여러개의 EBS를 동시에 연결 가능**
+
+## 활용
+
+- **인스턴스 재생성 후에도 데이터 유지**
+- **빠르게 다른 인스턴스에 재마운트 가능**
+- **백업 및 복원용으로 스냅샷 기능 활용 가능**
+
+## 요금
+
+아래 요소에 따라 요금이 결정되며, 나중에 조정이 가능
+- 용량 (GB)
+- IOPS (Input/Output Operations per Second)
+
+## 종료 시 삭제 옵션
+
+![[Pasted image 20250501185228.png]]
+
+EC2 인스턴스를 생성하면서 EBS를 생성하면 종료 시 삭제(Delete on Termination) 옵션이 있다. 디폴트 값은 아래와 같지만, 생성시에 옵션을 변경할 수 있다.
+- **루트 볼륨**: 기본으로 체크되어 있어 인스턴스 종료 시 삭제됨
+- **추가 볼륨**: 기본으로 비활성화되어 삭제되지 않음
+
+---
+
+# EBS Snapshot
+
+EBS 스냅샷은 **EBS 볼륨의 백업본**이다. 볼륨의 특정 시점을 사진찍듯이 백업본으로 만들고, 그 백업본을 다시 볼륨으로 복구할 수도 있다.
+
+## 연결 & 복원
+
+![[Pasted image 20250501174300.png]]
+
+스냅샷은 **다른 가용 영역 혹은 리전으로 복사 가능**
+- 예: `us-east-1a`의 EBS → 스냅샷 생성 → `us-east-1b`에서 볼륨으로 복원
+
+## 스냅샷을 어디에 보관 할 것인가?
+
+디폴트는 Standard Tier에 보관된다. 하지만 아래와 같이 3가지 옵션을 더 선택할 수 있다.
+1. 아카이브 티어
+2. 휴지통
+3. FSR(Fast Snapshot Restore)
+
+### 아카이브 티어 (Archive Tier)
+- **최대 75% 저렴한 비용**으로 저장가능. 단, **복원까지 24~72시간 소요**
+- **즉시 복원이 필요 없는 장기 보관용**에 적합
+- 다른 클라우드에서 콜드 스토리지라고 부르는 그것!
+
+### 휴지통 (Recycle Bin)
+- 실수로 삭제한 스냅샷을 **일정 기간 복원 가능**
+- **보관 기간 설정 가능**: 1일 ~ 1년
+- 기본 삭제 → 휴지통 이동 → 복원 가능
+
+### FSR(Fast Snapshot Restore)
+- **볼륨으로 복원하는데 필요한 시간을 줄이기 위해 미리 준비된 스냅샷**
+- 성능은 뛰어나나 **비용이 높으므로 신중히 사용**
+
+![[Pasted image 20250501185405.png]]
+
+---
+
+# EBS 볼륨 유형
+
+EBS에는 현재 **6가지 볼륨 유형**이 있다. 아래 나오는 정보들의 **숫자는 중요하지 않습니다.** 대략적인 특징과 비교가 가능하면 됩니다.
+
+## SSD 볼륨
+
+### GP3
+- **범용 SSD (최신 세대)**
+- **IOPS와 Throughput을 독립적으로 설정 가능**
+  - 기본: 3,000 IOPS / 125MB/s
+  - 최대: 16,000 IOPS / 1,000MB/s
+- **GP2 대비 성능과 가격 효율성 모두 우수**
+- **시험에서 중요**
+
+### GP2
+- **범용 SSD (이전 세대)**
+- **IOPS와 용량이 비례** (1GB당 3IOPS, 최대 16,000 IOPS)
+- 최대 16TB까지 가능
+- **버스트 성능** 제공 (작은 볼륨일 경우)
+- 저비용 & 낮은 지연시간 → **테스트/개발, 부팅 볼륨 등에 적합**
+
+### io1 /  io2 Block Express
+- **고성능 SSD 볼륨**
+- 일관된 IOPS가 필요한 **데이터베이스용**
+- **스토리지와 IOPS 비례하지 않음 → 별도 설정 가능**
+-> 비싸고 성능이 좋음
+
+## HDD 계열 볼륨
+
+### ST1 (Throughput Optimized HDD)
+- **빅데이터, 로그 처리, 데이터 웨어하우스에 적합**
+- 처리량 최적화 → 최대 500MB/s, 최대 500 IOPS
+- **부팅 볼륨 불가**
+- 최대 16TB
+
+### SC1 (Cold HDD)
+- **자주 접근하지 않는 데이터 (아카이브)에 적합**
+- 초저가 스토리지
+- 최대 250MB/s, 최대 250 IOPS
+- **부팅 볼륨 불가**
+
+## 부팅 볼륨으로 사용 가능한 유형
+
+- GP2, GP3, io1, io2 ✅
+- ST1 / SC1 ❌
+**-> SSD 계열만 부팅 볼륨으로 활용할 수 있다!**
+
+---
+
+# EBS Multi-Attach
+
+마치 초등학교 때 처럼.. EBS는 하나의 EC2에만 연결 된다고 했지만, 짜잔~ 사실은 여러개의 인스턴스에 연결할 수 있는 EBS도 있답니다!
+
+- 이 기능은 **io1과 io2** 제품군에서만 사용 가능하며, 동일한 **Availability Zone** 내에서만 작동.
+- 여러 인스턴스가 하나의 EBS 볼륨에 **동시에 읽고 쓸 수 있다**.
+
+### 제한 사항
+
+- 연결 가능한 EC2 인스턴스의 수는 **최대 16개**로 제한. (중요!!)
+- **다른 Availability Zone 간의 연결 불가. (예: `us-east-1a`에서 `us-east-1b`로 연결 불가)
+- **클러스터 인식 파일 시스템**만 지원.
+
+### 사용 사례
+
+- **애플리케이션 가용성**을 높이기 위해 사용.
+- **동시 쓰기 작업을 관리해야 하는 애플리케이션**에 유용.
+- **Teradata와 같은 클러스터링된 Linux 애플리케이션**에서 활용 가능.
+
+---
+
+## EBS 볼륨 암호화
+
+- **저장 데이터**와 **인스턴스와 볼륨 간의 전송 데이터**가 자동으로 암호화됨.
+- **스냅샷**과 **스냅샷으로 생성한 볼륨**도 자동으로 암호화됨.
+- 암호화 및 복호화 과정은 백그라운드에서 자동으로 처리되며, 사용자는 아무것도 하지 않음.
+	- 볼륨이나 스냅샷 생성시에 `Encrypt` 옵션만 체크
+- 암호화에는 **AES-256** 표준을 사용하며, **KMS(Key Management Service)**에서 암호화 키가 관리됨.
+
+### 장점
+
+- **지연 시간**에 미치는 영향은 거의 없으며, 백그라운드에서 암호화 및 복호화가 이루어짐.
+- **KMS**에서 암호화 키를 생성하고 관리하여 **AES-256** 표준을 사용한 강력한 암호화 지원.
+
+### 스냅샷을 만들때는?
+
+- 암호화 된 스냅샷 -> 암호화 된 볼륨 생성
+- 암호화 된 볼륨 -> 암호화 된 스냅샷 생성
+
+그래서 이런 흐름도 가능합니다.
+1. 암호화 되지 않은 볼륨 생성
+2. 볼륨으로 암호화 되지 않은 스냅샷 생성
+3. 스냅샷을 복사하면서 암호화 -> 암호화 된 스냅샷 생성
+4. 암호화 된 스냅샷을 복원하면 암호화 된 볼륨이 됨.

HyeGyeong/EC2 Instance Storage/EC2 Instance Store.md

@@ -0,0 +1,15 @@
+
+네트워크 기반으로 연결 된 볼륨인 EBS와 달리 **EC2 인스턴스가 위치한 하드웨어에 물리적으로 연결된 디스크**를 사용하는 스토리지다.  
+
+### 특징
+
+- 인스턴스 중지/종료 시 **데이터 소실**
+- 흔히 **임시 스토리지 (Ephemeral Storage)** 라고 부름
+- **높은 처리량(Throughput)** 및 IOPS 제공
+
+### 활용 시점
+
+- **임시 데이터**에 적합
+	- 버퍼나 캐시처럼 빠른 IO를 요구하지만 임시 데이터일 때 유용함
+- **장기 보관 목적에는 부적합**
+	- → **EBS 사용 권장**

HyeGyeong/EC2 Instance Storage/EFS(Elastic File System).md

@@ -0,0 +1,38 @@
+
+**EFS는 Availability Zone에 상관없이 여러 EC2 인스턴스에서 동시에 마운트할 수 있는 네트워크 파일 시스템**이다. **고가용성**과 **확장성**이 뛰어난 대신, **비용은 GP2 EBS 볼륨의 약 3배** 정도이다.
+
+![[Pasted image 20250501174141.png]]
+
+### 비용 및 확장성
+
+- **EFS**는 사용량에 따라 비용이 청구되며, **미리 용량을 정할 필요가 없다.**
+- 파일 시스템은 자동으로 **확장**된다.
+-> 편리하다는 것은 장점이지만 요금 측면에서는 좀 무섭군요..
+
+### EFS의 주요 구성 요소
+
+- **보안 그룹**을 사용하여 EFS에 대한 액세스를 제어.
+- **Linux 기반 AMI**와만 호환되며, **NFS 프로토콜**을 사용하여 데이터를 전송.
+### Throughput Mode
+
+- **Bursting**: 기본적으로 1TB에 대해 초당 50MiB ~ 100MiB의 버스트 성능을 제공.
+- **Provisioned**: 스토리지와 처리량을 독립적으로 설정 가능.
+- **Elastic**: 작업에 따라 **자동으로 처리량을 조정**할 수 있는 옵션.
+### Performance Mode
+
+- **General Purpose**(default): **지연 시간**에 민감한 일반 웹서버 등
+- **Max I/O**: **지연 시간이 더 길지만** 높은 **처리량**과 **병렬성**이 필요한 **빅 데이터** 애플리케이션이나 **미디어 처리**에 적합. (Bursting일때는 선택 불가능)
+
+### EFS 스토리지 클래스
+
+- **Standard**: 기본계층이며, 자주 액세스하는 파일에 적합한 위치
+- **EFS-IA (Infrequent Access)**: 자주 액세스하지 않는 파일에 적합하며, 파일을 저장하면 **비용이 감소**, 검색 시 **비용 발생**.
+- **아카이브 스토리지 계층**: 거의 액세스하지 않는 데이터
+
+### 수명 주기 정책
+
+- **수명 주기 정책**을 설정하여 **파일을 자동으로 다른 계층으로 이동**할 수 있습니다.
+	- 예: 60일 동안 액세스하지 않은 파일을 **EFS IA**로 이동.
+
+### One Zone EFS
+- EFS가 하나의 AZ에만 배치되게 해서, **저렴한 비용**으로 사용 가능. 

HyeongKyu/ELB & ASG/ASG.md

@@ -0,0 +1,101 @@
+
+## 🔄 오토 스케일링 그룹(Auto Scaling Group)이란?
+
+실제 상황에서 웹사이트와 애플리케이션의 부하는 변할 수 있다.
+
+클라우드에서는 서버를 매우 빠르게 생성하고 제거할 수 있는 것이 클라우드의 장점이다.
+
+오토 스케일링 그룹(ASG)의 목표는 다음과 같아요:
+
+- 증가된 부하에 맞게 스케일 아웃(EC2 인스턴스 추가)
+- 감소된 부하에 맞게 스케일 인(EC2 인스턴스 제거)
+- 실행 중인 EC2 인스턴스의 최소 및 최대 수를 확보
+- 새 인스턴스를 로드 밸런서에 자동으로 등록 (ASG에 속한 인스턴스는 로드 밸런서에 연결되기 때문이다)
+- 이전 인스턴스가 종료된 경우 EC2 인스턴스 재생성 (예: 비정상인 경우)
+
+ASG는 무료이다 (기본 EC2 인스턴스에 대해서만 비용을 지불)
+![[스크린샷 2025-05-03 오후 10.59.33.png]]
+
+이 예시의 경우 용량은 7이다. 
+
+## 🏭 로드 밸런서가 있는 AWS의 오토 스케일링 그룹
+
+ELB는 EC2 인스턴스의 상태를 확인할 수 있어요!
+
+비정상 인스턴스를 감지하고 새 인스턴스로 대체한다.
+
+## 📋 오토 스케일링 그룹 속성
+
+ASG에는 다음과 같은 구성 요소가 필요하다:
+
+**시작 템플릿(Template)** (이전의 "시작 구성"은 더 이상 사용되지 않음):
+
+- AMI + 인스턴스 유형
+- EC2 사용자 데이터
+- EBS 볼륨
+- 보안 그룹
+- SSH 키 페어
+- EC2 인스턴스용 IAM 역할
+- 네트워크 + 서브넷 정보
+- 로드 밸런서 정보
+
+아래는 추가적인 필요 설정이다.:
+
+- 최소 크기 / 최대 크기 / 초기 용량
+- 스케일링 정책
+
+## 📊 오토 스케일링 - CloudWatch 경보 & 스케일링
+
+CloudWatch 경보를 기반으로 ASG를 스케일링할 수 있다.
+
+
+경보는 메트릭(예: **평균 CPU** 또는 **사용자 지정 메트릭**)을 모니터링한다.
+평균 CPU와 같은 메트릭은 전체 ASG 인스턴스로 계산 하는 것이다.!
+
+% 메트릭은 데이터 지표라고 생각하면 된다. 
+
+경보를 기반으로 다음과 같은 작업을 수행한다.
+
+- 스케일 아웃 정책 생성 (인스턴스 수 증가)
+- 스케일 인 정책 생성 (인스턴스 수 감소)
+
+## 📈 오토 스케일링 그룹 - 스케일링 정책
+
+**동적 스케일링**:
+
+- **대상 추적 스케일링**:
+    - 설정이 간단하다
+    - 예: 평균 ASG CPU를 약 40%로 유지
+- **단순/단계 스케일링**:
+    - CloudWatch 경보가 트리거될 때 (예: CPU > 70%), 2개 단위 추가
+    - CloudWatch 경보가 트리거될 때 (예: CPU < 30%), 1개 단위 제거
+
+**예약 스케일링**:
+
+- 알려진 사용 패턴에 기반한 스케일링 예상
+- 예: 금요일 오후 5시에 최소 용량을 10으로 증가
+
+**예측 스케일링**:
+
+- 부하를 지속적으로 예측하고 미리 스케일링 일정을 잡는다.
+
+## 📉 스케일링에 좋은 메트릭
+
+- **CPUUtilization**: 인스턴스 전체의 평균 CPU 사용률
+- **RequestCountPerTarget**: EC2 인스턴스당 요청 수가 안정적인지 확인하기 위해
+- **평균 네트워크 입/출력**: 애플리케이션이 네트워크 바인딩된 경우
+- **사용자 지정 메트릭**: CloudWatch를 사용하여 푸시하는 모든 메트릭
+
+
+# 🔄 오토 스케일링 그룹 - 스케일링 쿨다운
+
+스케일링 활동이 발생한 후, **쿨다운 기간**(기본값 300초)이 있다. 운동 후 휴식 시간 같은거라 생각하면 된다 🏃‍♀️
+
+쿨다운 기간 동안, ASG는 메트릭이 안정화될 시간을 주기 위해 추가 인스턴스를 시작하거나 종료하지 않는 것이 특징이다.
+
+**TIP**: 구성 시간을 줄이기 위해 바로 사용 가능한 AMI를 사용하면 요청을 더 빨리 처리하고 쿨다운 기간을 줄일 수 있어요!
+
+```
+스케일링 활동 발생 → 기본 쿨다운 적용 중? → 예: 작업 무시 / 아니오: 인스턴스 시작 또는 종료
+```
+