West_Cold

Availability(고가용성) & Scalability(확장성) 정리

Availability(고가용성)

• 정의: 시스템 또는 애플리케이션이 항상 작동 가능하고, 장애 발생 시에도 지속적으로 서비스가 제공될 수 있는 능력.
• 특징
  • 일반적으로 **수평 확장(horizontal scaling)**과 함께 적용됨.
  • **다중 가용 영역(Multi-AZ)**을 활용하여 최소 2개 이상의 데이터 센터에서 운영함.
  • RDS Multi-AZ 배포는 패시브 방식(장애 발생 시 자동으로 다른 AZ로 전환).
  • EC2 Auto Scaling Group과 로드 밸런서를 사용하여 여러 AZ에 걸쳐 애플리케이션을 실행함​.

Scalability(확장성)

• 정의: 시스템이 증가하는 부하를 처리하기 위해 적절하게 확장될 수 있는 능력.
• 종류
  • 수직 확장(Vertical Scaling)
    • 단일 인스턴스의 크기를 증가시켜 성능을 향상시키는 방법.
    • 예: t2.micro → t2.large 업그레이드.
    • RDS, ElastiCache 같은 AWS 서비스에서 사용됨.
    • 하드웨어 한계로 인해 확장 가능 범위가 제한됨​.
  • 수평 확장(Horizontal Scaling)
    • 애플리케이션 인스턴스를 여러 개 추가하여 성능을 향상시키는 방법.
    • 분산 시스템 환경에서 자주 사용되며, AWS EC2 Auto Scaling Group과 로드 밸런서로 구현 가능.
    • 클라우드 환경에서 매우 일반적인 방식​.

고가용성과 확장성의 차이점

• 고가용성: 장애 발생 시에도 시스템이 지속적으로 운영될 수 있도록 설계.
• 확장성: 부하 증가에 대응하여 시스템을 확장할 수 있도록 설계.
• 예를 들어 콜센터를 운영할 때:
  • 고가용성: 뉴욕과 샌프란시스코 두 개의 센터를 운영하여 한 곳에 장애가 발생해도 계속 운영 가능.
  • 확장성:
    • 수직 확장: 기존 직원(오퍼레이터)에게 더 많은 콜을 받을 수 있도록 장비를 업그레이드.
    • 수평 확장: 더 많은 직원을 추가하여 콜을 처리​.

 AWS에서의 적용 예시

• EC2 고가용성 & 확장성
  • 수직 확장: 인스턴스 크기 조정 (예: t2.nano → u-12tb1.metal).
  • 수평 확장: Auto Scaling Group & Load Balancer 사용.
  • 고가용성: Multi-AZ Auto Scaling Group & Load Balancer 적용​.
• RDS 고가용성 & 확장성
  • 고가용성: RDS Multi-AZ 배포로 장애 발생 시 자동 전환.
  • 읽기 확장성(Read Scalability): RDS Read Replica를 사용하여 읽기 성능 향상​.
• EFS(Elastic File System)
  • 다중 AZ 지원으로 고가용성 보장.
  • 자동 크기 조정으로 확장성 제공​.

로드 밸런싱 (Load Balancing) 정리

로드 밸런서란?
로드 밸런서는 트래픽을 여러 서버(EC2 인스턴스)로 분산하여 부하를 관리하는 서비스이다. AWS에서는 Elastic Load Balancer(ELB)를 제공하며, 여러 유형이 존재한다.

로드 밸런서를 사용하는 이유

• 부하 분산 → 여러 서버에 트래픽을 분산하여 과부하 방지
• 단일 접속 지점 제공 → DNS를 통해 접근 가능
• 자동 장애 감지 및 복구 → 인스턴스 장애 발생 시 정상 인스턴스로 트래픽 우회
• 정기적인 헬스 체크 수행 → 인스턴스의 정상 상태 여부를 모니터링
• SSL 종료 (HTTPS 처리) → 보안 강화를 위해 HTTPS 트래픽을 ELB에서 처리
• 세션 유지(Stickiness) 지원 → 사용자가 동일한 인스턴스로 연결될 수 있도록 설정 가능
• 고가용성 지원 → 여러 가용 영역(AZ)에서 트래픽을 분산하여 가용성을 높임
• 퍼블릭 트래픽과 프라이빗 트래픽을 분리 가능

헬스 체크란?

• 헬스 체크(Health Check)는 로드 밸런서가 백엔드 EC2 인스턴스의 정상 상태를 확인하는 기능이다. 헬스 체크를 통해 비정상적인 인스턴스를 감지하고, 트래픽을 정상 인스턴스로 우회할 수 있다.

헬스 체크가 필요한 이유

• • 문제가 있는 인스턴스를 자동 감지하여 트래픽을 차단
  • Auto Scaling과 연동하여 비정상 인스턴스를 자동 교체 가능
  • 웹 애플리케이션, API 서버, 데이터베이스 등의 가용성을 높이는 핵심 기능

헬스 체크의 동작 방식

• 1. 로드 밸런서가 정해진 주기(Interval)마다 헬스 체크 요청을 보냄
  2. 지정된 포트와 엔드포인트(/health 등)에 접속하여 상태 확인
  3. 응답 코드가 200(OK)이면 정상(Healthy), 다른 응답이거나 응답이 없으면 비정상(Unhealthy)으로 판단
  4. 비정상 상태가 연속적으로 감지되면, 해당 인스턴스를 트래픽 분배 대상에서 제외
  5. 다시 정상 상태로 감지되면, 트래픽을 다시 전달

헬스 체크 설정 항목

• • 프로토콜(Protocol) → HTTP, HTTPS, TCP
  • 포트(Port) → EC2 인스턴스에서 헬스 체크를 받을 포트 (예: 80, 443, 8080)
  • 헬스 체크 경로(Path) → /health, /status 같은 엔드포인트 설정
  • 정상/비정상 임계값
    • Healthy Threshold → 정상 상태로 판단할 요청 성공 횟수
    • Unhealthy Threshold → 비정상 상태로 판단할 요청 실패 횟수
  • 체크 주기(Interval) → 헬스 체크 요청 간격 (초 단위)
  • 타임아웃(Timeout) → 인스턴스가 응답을 반환해야 하는 최대 시간

Elastic Load Balancer(ELB) 유형

Classic Load Balancer (CLB)   (시험x)

• 2009년 출시된 1세대 로드 밸런서
• L4 (TCP, SSL) & L7 (HTTP, HTTPS) 지원
• 고정된 DNS 이름 제공 (xxx.region.elb.amazonaws.com)
• 현재는 ALB/NLB 사용이 권장됨

Application Load Balancer (ALB)

• 2016년 출시된 2세대 로드 밸런서
• OSI 7계층 (Layer 7)에서 동작 → HTTP, HTTPS, WebSocket 트래픽 처리
• 고급 라우팅 기능 지원
  • 경로 기반 라우팅 (example.com/users → 사용자 서버, example.com/posts → 게시글 서버)
  • 호스트 기반 라우팅 (one.example.com → 서버 A, two.example.com → 서버 B)
  • 쿼리 문자열 및 헤더 기반 라우팅
• 마이크로서비스 및 컨테이너 환경(Amazon ECS)에서 적합
• 포트 매핑 기능 제공 → Amazon ECS에서 동적 포트로 트래픽을 라우팅 가능

Network Load Balancer (NLB)

• 2017년 출시된 2세대 로드 밸런서
• OSI 4계층 (Layer 4)에서 동작 → TCP, UDP 트래픽 처리
• 고성능, 초저지연 (millions of requests per second)
• 고정된 IP 할당 지원 → 특정 IP를 화이트리스트(허용 목록)로 등록 가능
• DNS 이름 및 Elastic IP 할당 가능
• 금융 서비스, VoIP, 게임 서버 등 실시간 연결이 필요한 애플리케이션에 적합

Gateway Load Balancer (GWLB)

• 2020년 출시된 3세대 로드 밸런서
• OSI 3계층 (Layer 3)에서 동작 → IP 패킷 기반 트래픽 처리
• 보안 장비(Firewall, IDS/IPS, Deep Packet Inspection 등)와 함께 사용
• Transparent Network Gateway 역할 수행 → 보안 어플라이언스와 트래픽을 연결

ELB와 보안 (Security Groups)

• 로드 밸런서는 보안 그룹을 활용하여 트래픽을 제어할 수 있음
• Load Balancer Security Group → 외부에서 오는 HTTP/HTTPS 트래픽을 허용
• Application Security Group → 로드 밸런서에서만 허용된 트래픽만 받도록 설정

Sticky Sessions (Session Affinity)

• 클라이언트가 항상 동일한 백엔드 인스턴스로 연결되도록 설정하는 기능
• CLB, ALB, NLB에서 지원됨
• 쿠키 기반 세션 유지
  • 커스텀 쿠키 (애플리케이션에서 설정 가능)
  • 로드 밸런서에서 자동 생성하는 쿠키 (AWSALB, AWSELB)
• 사용 사례 → 로그인 세션 유지가 필요한 애플리케이션 (예: 전자상거래, 채팅 앱)
• 단점 → 특정 인스턴스에 부하가 집중될 수 있음

Cross-Zone Load Balancing (AZ 간 부하 분산)

• 여러 가용 영역(AZ)에 걸쳐 트래픽을 균등하게 분산하는 기능
• ALB → 기본적으로 활성화 (비활성화 가능)
• NLB, GWLB → 기본적으로 비활성화 (활성화 시 추가 요금 발생)
• CLB → 기본적으로 비활성화 (활성화 가능, 추가 요금 없음)

로드 밸런서 활용 예시

• 웹 서버 여러 대를 운영하는 경우, 트래픽을 균등하게 분산
• 마이크로서비스 아키텍처에서 API 요청을 특정 서비스로 라우팅
• TCP/UDP 기반의 금융 거래 시스템에서 빠른 트래픽 분산이 필요할 때
• EC2 Auto Scaling과 함께 사용하여 트래픽 증가 시 자동으로 인스턴스를 추가/제거

SSL/TLS (보안 및 암호화) 정리

SSL/TLS란?
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 클라이언트와 로드 밸런서 간의 트래픽을 암호화하여 보안을 강화하는 프로토콜이다.

• SSL은 이전 버전이며, 현재는 TLS가 표준이지만 여전히 "SSL 인증서"라는 용어가 널리 사용됨.
• 공인된 **인증 기관(CA, Certificate Authority)**에서 발급한 인증서를 사용해야 함.
  • 예: Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Let's Encrypt

AWS에서 SSL/TLS 관리

• AWS **Certificate Manager(ACM)**를 사용하여 인증서를 관리 가능
• 사용자가 직접 인증서를 업로드할 수도 있음
• HTTPS 리스너를 설정하면 기본적으로 하나의 인증서를 지정해야 하며, 여러 개의 인증서 추가 가능
• SNI(Server Name Indication) 기능을 활용하여 여러 도메인에 대한 SSL 인증서 적용 가능

Server Name Indication (SNI)

• 하나의 로드 밸런서에서 여러 개의 SSL 인증서를 사용할 수 있도록 지원하는 프로토콜
• 클라이언트가 SSL 핸드셰이크 시 접속하려는 도메인(hostname)을 전달하면, 서버가 해당 도메인에 맞는 인증서를 제공
• ALB, NLB, CloudFront에서 지원 (CLB에서는 지원되지 않음)

ELB와 SSL 인증서

로드 밸런서 유형SSL 인증서 지원SNI 지원

• CLB → 여러 개의 SSL 인증서를 사용하려면 여러 개의 CLB를 생성해야 함
• ALB, NLB → SNI를 사용하여 여러 SSL 인증서를 적용 가능

Connection Draining (Deregistration Delay)

로드 밸런서에서 연결 해제 중인 인스턴스가 진행 중인 요청을 마칠 수 있도록 대기하는 기능

• CLB → "Connection Draining"
• ALB & NLB → "Deregistration Delay"
• 기본값은 **300초(5분)**이며, 1~3600초(1시간)까지 설정 가능
• 짧은 요청이 많은 서비스의 경우, 대기 시간을 낮게 설정하는 것이 유리함

Auto Scaling Group (ASG) & Load Balancer 연동

**Auto Scaling Group(ASG)**은 트래픽 변화에 따라 EC2 인스턴스 수를 자동으로 조정하는 기능

• 트래픽 증가 시 → EC2 인스턴스를 자동으로 추가 (Scale Out)
• 트래픽 감소 시 → EC2 인스턴스를 자동으로 제거 (Scale In)
• 최소/최대 인스턴스 개수를 지정 가능
• 비정상 인스턴스가 감지되면 자동으로 교체

  

Auto Scaling Group (ASG) 주요 속성

• Launch Template → 인스턴스 유형, AMI, EBS 볼륨, 보안 그룹, IAM 역할 포함
• Scaling Policies (확장 정책)
  • Target Tracking Scaling → 예: 평균 CPU 사용률을 40%로 유지
  • Simple/Step Scaling → 예: CPU가 70% 이상이면 2개 추가, 30% 미만이면 1개 제거
  • Scheduled Scaling → 예: 매주 금요일 오후 5시에 최소 인스턴스를 10개로 증가
  • Predictive Scaling → AI 기반 트래픽 예측 후 사전 확장

CloudWatch Alarms와 Auto Scaling 연동

• CloudWatch 알람을 활용하여 ASG 확장 가능
• CPUUtilization(평균 CPU 사용률), RequestCountPerTarget(요청 수), 네트워크 트래픽(In/Out) 등을 기준으로 확장

Auto Scaling에서 고려할 좋은 메트릭(Good metrics to scale on)

1. CPUUtilization (CPU 사용률)
   • EC2 인스턴스들의 평균 CPU 사용률이 일정 임계값을 초과하면 인스턴스를 추가하고, 낮아지면 제거.
   • 예: 평균 CPU 사용률이 70%를 초과하면 2개 추가, 30% 미만이면 1개 제거
2. RequestCountPerTarget (타겟당 평균 요청 수)
   • 로드 밸런서(ALB, NLB)에서 각 백엔드 인스턴스가 처리하는 요청 수를 기준으로 확장.
   • 예: EC2 한 대당 평균 요청 수가 1000건을 초과하면 확장, 500건 미만이면 축소
3. Network In/Out (네트워크 트래픽)
   • 애플리케이션이 CPU가 아닌 네트워크 사용량이 많은 경우 트래픽 양을 기준으로 확장.
   • 예: EC2 한 대당 초당 500MB 이상의 네트워크 트래픽이 발생하면 확장
4. Custom Metrics (사용자 정의 메트릭)
   • CloudWatch를 통해 애플리케이션 맞춤형 지표를 추가하고 이를 기준으로 확장 가능.
   • 예: 웹사이트의 활성 사용자 수, DB 쿼리 응답 시간, 메시지 대기열(SQS) 길이 등을 기준으로 확장.

Auto Scaling Cooldown (확장 안정화)

• 새로운 인스턴스가 추가된 후 일정 시간 동안 추가 확장을 방지하는 기능
• 기본값은 300초(5분)이며, AMI 최적화로 부팅 시간을 단축하면 대기 시간도 줄일 수 있음

1. EBS (Elastic Block Store) - 네트워크 연결 스토리지

✅ EBS란?

EBS는 EC2 인스턴스에 네트워크를 통해 연결되는 저장 장치이다.
즉, EC2 인스턴스가 실행 중일 때, 하드디스크처럼 사용할 수 있는 AWS의 클라우드 기반 스토리지라고 보면 된다.

✅ EBS의 특징

• EC2와 독립적인 네트워크 저장소 → 인스턴스를 중지하거나 종료해도 데이터가 유지된다.
• AZ(가용 영역, Availability Zone) 종속적 → 한 AZ에서 생성한 EBS는 다른 AZ에서 사용할 수 없다.
• 하나의 EBS는 한 개의 인스턴스에만 연결 가능 → 다중 인스턴스 공유 불가 (다만 io1/io2 볼륨의 경우 멀티-어태치 기능을 제공).

✅ EBS의 활용 사례

• OS 및 애플리케이션 설치 공간
• 데이터베이스 저장소 (MySQL, PostgreSQL, Oracle 등)
• 지속적인 데이터 보관이 필요한 서비스

✅ EBS 삭제 정책

• 기본적으로 EC2 인스턴스를 삭제하면 루트 볼륨(EBS)도 삭제됨.
• 추가로 연결한 EBS는 삭제되지 않음(설정 변경 가능).

✅ EBS 스냅샷 (백업)

• 특정 시점의 데이터를 스냅샷(Snapshot) 형태로 백업 가능.
• 스냅샷을 활용하면 AZ나 리전 간 이동 가능 → 다른 리전에 복사하여 DR(재해 복구) 환경 구축 가능.

✅ EBS를 선택해야 하는 경우

• EC2에 일반적인 데이터 저장 공간이 필요할 때
• 인스턴스를 재시작해도 데이터가 유지되어야 할 때
• 데이터베이스 저장 공간이 필요할 때 (MySQL, PostgreSQL 등)

2. Instance Store - 로컬 디스크

✅ Instance Store란?

Instance Store는 EC2 인스턴스 내부에 직접 연결된 하드디스크 같은 저장소이다.
EBS와의 차이점은?

• 네트워크 스토리지(EBS)와 달리, 로컬 디스크이므로 속도가 매우 빠름.
• 하지만 인스턴스를 중지하거나 종료하면 데이터가 사라짐(휘발성).
• EC2가 새롭게 시작되면, Instance Store에 있던 데이터는 초기화됨.

✅ Instance Store의 특징

• 고속 데이터 처리 가능 (IOPS 성능 우수)
• EBS보다 지연시간이 짧고 성능이 뛰어남
• 데이터 유실 가능성이 있음 → 지속적인 저장이 필요한 데이터에는 적합하지 않음.

✅ Instance Store의 활용 사례

• 임시 파일 저장소 (캐시, 로그, 세션 데이터)
• 데이터베이스의 임시 저장 공간 (예: Redis, Memcached)
• 비디오 렌더링, 머신러닝 학습 데이터 저장

✅ Instance Store를 선택해야 하는 경우

• 고속 데이터 처리가 필요한 경우 (로깅, 캐시, 일시적인 데이터 저장)
• 데이터가 사라져도 상관없는 경우 (예: 웹서버의 캐시, 비디오 렌더링)

3.AMI (Amazon Machine Image)- EC2 인스턴스 템플릿

✅ AMI (Amazon Machine Image)란?

AMI(Amazon Machine Image)는 **EC2 인스턴스를 생성할 때 사용할 수 있는 "미리 구성된 템플릿"이다.
즉, 운영체제(OS), 애플리케이션, 설정 등을 포함한 EC2의 복제본으로, 동일한 환경을 여러 개의 인스턴스로 빠르게 배포할 수 있다.

✅ AMI의 특징

• EC2 인스턴스를 쉽게 복제 가능 → 동일한 설정을 가진 인스턴스를 여러 개 배포 가능.
• 운영체제(OS), 애플리케이션, 설정 포함 → 미리 패키징된 환경으로 빠른 배포 가능.
• 부팅 및 구성 시간 단축 → 소프트웨어가 사전 설치되어 있어 즉시 실행 가능.
• 리전에 종속됨 → 특정 리전에서 만든 AMI는 다른 리전에서 바로 사용 불가 (하지만 복사 가능).

✅ AMI의 유형

✅ AMI 생성 및 사용 프로세스

1. EC2 인스턴스를 실행하고 환경을 커스터마이징
   • 운영체제(OS) 설정
   • 애플리케이션 설치
   • 보안 및 네트워크 설정
2. EC2 인스턴스를 중지 (데이터 무결성 유지)
   • 실행 중인 상태에서 스냅샷을 찍으면 데이터 손상 가능성이 있으므로 중지한 후 진행.
3. AMI 생성 (EBS 스냅샷 포함)
   • AMI를 생성하면 루트 볼륨을 포함한 모든 데이터가 이미지로 저장됨.
4. 다른 인스턴스에서 해당 AMI를 사용하여 새로운 EC2 인스턴스 실행
   • 동일한 설정을 가진 여러 개의 인스턴스를 빠르게 배포 가능.

     

4. EFS (Elastic File System) - 공유 파일 시스템

✅ EFS란?

EFS는 여러 개의 EC2 인스턴스에서 동시에 접근할 수 있는 네트워크 파일 시스템(NFS)이다.
즉, 여러 서버가 하나의 파일 시스템을 공유할 수 있게 해준다.

✅ EFS의 특징

• 멀티 AZ 지원 → 한 리전 내 여러 가용 영역(AZ)에서 동시에 접근 가능.
• 자동 확장 → 저장 용량을 직접 설정할 필요 없이, 데이터 증가에 따라 자동 확장됨.
• POSIX 호환 (리눅스 지원) → 리눅스 기반의 파일 시스템을 사용.
• 비용이 EBS보다 비쌈 → 하지만, Infrequent Access(EFS-IA) 같은 티어를 사용하면 비용 절감 가능.

✅ EFS의 활용 사례

• 웹 서버의 정적 파일 저장소 (예: Wordpress, Drupal, Joomla)
• 다수의 서버에서 공유해야 하는 파일 시스템 (예: 개발 환경, 빅데이터 분석)
• 머신러닝 모델 및 로그 파일 저장

✅ EFS 성능 모드

• General Purpose(일반적인 웹/애플리케이션 서버용)
• Max I/O(빅데이터, 고성능 병렬 처리 작업용)

✅ EFS 저장소 티어

• Standard (기본값) → 자주 접근하는 데이터 저장
• Infrequent Access (EFS-IA) → 가끔 접근하는 데이터 (비용 절감)
• Archive → 거의 사용하지 않는 데이터 (저장 비용 50% 절감 가능)

✅ EFS를 선택해야 하는 경우

• 여러 개의 EC2 인스턴스가 동일한 데이터에 접근해야 할 때
• 웹 서버(Wordpress, Django, Flask 등)에서 공유 파일을 저장해야 할 때
• 데이터를 자동으로 확장하고 싶을 때

5. EBS vs EFS 비교 정리

1. Amazon EC2 개요

• AWS에서 가상 서버(VM)를 제공하는 서비스로, IaaS(Infrastructure as a Service) 모델.
• 주요 기능:
  • VM 임대: 원하는 사양의 EC2 인스턴스 생성 가능.
  • 스토리지 사용: EBS(Elastic Block Store) 및 EC2 인스턴스 스토리지 제공.
  • 로드 밸런싱(ELB): 트래픽을 여러 인스턴스로 분산 가능.
  • 오토 스케일링(ASG): 수요에 따라 자동 확장 가능.

2. EC2 인스턴스 설정 옵션

• 운영 체제(OS): Linux, Windows, Mac OS 지원.
• CPU 및 메모리: 다양한 성능 옵션 제공.
• 스토리지:
  • EBS(Elastic Block Store): 네트워크 연결된 스토리지, 인스턴스 종료 후에도 데이터 유지.
  • 인스턴스 스토리지(Instance Store): 물리적 디스크, 인스턴스 종료 시 데이터 삭제됨.
• 네트워크:
  • 퍼블릭 IP, 프라이빗 IP 설정 가능.
  • 보안 그룹(Security Group)으로 접근 제어 가능.
• EC2 User Data: 부팅 시 실행할 초기 설정 스크립트 적용 가능.

3. EC2 인스턴스 유형

• 일반 용도(General Purpose): 균형 잡힌 성능 (예: t2.micro, m5.large)
• 컴퓨팅 최적화(Compute Optimized): CPU 성능이 중요한 작업 (예: c5.large)
• 메모리 최적화(Memory Optimized): 대규모 데이터 처리 (예: r5.large//메모리ram//)
• 스토리지 최적화(Storage Optimized): 고속 읽기/쓰기 작업 (예: i3.large//로컬 저장소 접근에 유용)

4. 보안 그룹(Security Groups)

• AWS 내에서 EC2 인스턴스의 방화벽 역할 수행.
• 인바운드/아웃바운드 트래픽 제어:
  • 기본적으로 모든 인바운드 트래픽 차단, 아웃바운드 트래픽 허용.
  • 특정 IP나 포트만 허용하도록 설정 가능.
• SSH 연결 문제 해결:
  • 타임아웃 발생 → 보안 그룹에서 SSH(22번 포트) 허용 필요.
  • 연결 거부 → EC2 인스턴스에서 SSH 서비스가 실행되지 않았을 가능성.

5. EC2 접속 방법

• AWS Management Console: 웹 UI로 관리 가능.
• AWS CLI(Command Line Interface): 터미널에서 AWS 서비스 제어.
• SSH를 이용한 접속:
  • Linux/Mac: ssh -i 키파일.pem ec2-user@퍼블릭IP
  • Windows: Putty 또는 EC2 Instance Connect 사용.

6. EC2 구매 옵션

• 온디맨드(On-Demand): 사용한 만큼 비용 지불, 단기 사용에 적합.
• 예약 인스턴스(Reserved Instances): 1년 또는 3년 약정으로 최대 72% 할인.
• 세이빙 플랜(Savings Plans): 유연한 요금제, 장기 사용 시 비용 절감.
• 스팟 인스턴스(Spot Instances):
  • AWS에서 남는 리소스를 경매 방식으로 저렴하게 제공(최대 90% 할인).
  • 하지만 필요할 경우 AWS가 사전 예고 없이 인스턴스를 회수 가능.
  • 비용 절감이 중요한 작업(배치 작업, 데이터 분석, AI 학습 등)에 적합.
  • 스팟 블록(Spot Block): 1~6시간 동안 중단 없이 스팟 인스턴스 사용 가능.
  • 스팟 플릿(Spot Fleet): 여러 개의 스팟 인스턴스와(옵션으로) On-Demand 인스턴스를 포함하는 집합체. 타겟 용량을 충족시키기 위해 여러 풀에서 인스턴스를 자동으로 선택합니다.
• 전용 호스트(Dedicated Hosts): 특정 서버를 단독으로 사용 가능.

7. associate

VPC (Virtual Private Cloud)

• AWS에서 제공하는 가상 네트워크 환경
• 사용자가 정의한 IP 범위 내에서 리소스 배치 가능
• 인터넷 게이트웨이, 서브넷, 라우트 테이블 등을 구성하여 네트워크 설계 가능

Private vs Public IP (IPv4)

• Public IP: 인터넷에서 접근 가능, 고유해야 함
• Private IP: 내부 네트워크에서만 사용, 중복 가능 (NAT 통해 인터넷 접근)
• EC2 인스턴스는 기본적으로 Private & Public IP 모두 제공

Elastic IP

• EC2 인스턴스의 공인 IP가 변경되는 것을 방지
• 5개까지만 무료 할당 가능 (추가 요청 가능)
• 고정 IP가 필요한 경우 사용하지만, 가급적 도메인(DNS) 사용 권장

Placement Groups

• EC2 인스턴스의 배치 전략
  • Cluster: 단일 AZ 내에서 저지연 고속 네트워크 제공 (빅데이터, HPC)
  • Spread: 서로 다른 물리적 하드웨어에 배치 (고가용성 중요)
  • Partition: 다수의 파티션으로 나누어 장애 격리 (Hadoop, Kafka)

Elastic Network Interfaces (ENI)

• 가상 네트워크 카드 개념
• 하나의 EC2 인스턴스에 여러 개 부착 가능
• 특정 AZ에 종속되며, 인스턴스 간 이동 가능

EC2 Hibernate

• 인스턴스 메모리(RAM) 상태를 유지한 채 절전 모드로 전환
• 재부팅 시 기존 실행 상태 복원 → 부팅 시간 단축
• 조건:
  • RAM 150GB 이하
  • 지원되는 인스턴스 타입 (C3, C4, C5, M3, M4, R3, R4, T2, T3 등)
  • 루트 볼륨이 암호화된 EBS여야 함
  • 최대 60일까지 Hibernate 가능

EC2 인스턴스 상태

• Start: 부팅 후 실행됨
• Stop: 중지 (EBS 데이터 유지)
• Terminate: 인스턴스 삭제 (EBS도 삭제될 수 있음)
• Hibernate: RAM 상태 저장 후 절전 (빠른 부팅 가능)

+AZ는 리전 내에서 물리적으로 분리된 데이터 센터를 의미하며, 고가용성과 장애 격리를 제공.

+파티션은 AZ 내에서 EC2 인스턴스를 분배하는 전략으로, 하드웨어 격리와 장애 격리를 통해 대규모 분산 시스템에서 안정성을 높이는 데 사용

AWS IAM 정리

IAM: 사용자 및 그룹

• IAM(Identity and Access Management): AWS 계정 내 사용자, 그룹, 역할, 정책 등을 관리하는 글로벌 서비스.
• Root 계정: 기본적으로 생성되며, 사용하거나 공유하지 않아야 함
• 사용자(User): 조직 내 개별 계정, 그룹에 속할 수 있음
• 그룹(Group): 사용자만 포함 가능, 다른 그룹을 포함할 수 없음
• 사용자는 그룹에 속하지 않아도 되며, 여러 그룹에 속할 수도 있음

✅ AWS 계정 운영 방식

1️⃣ 회사가 AWS 루트 계정을 생성 (회사 = AWS 계정 소유)
2️⃣ 루트 계정에서 IAM 사용자들을 생성
3️⃣ 각 사용자에게 필요한 권한을 부여
4️⃣ 필요하면 IAM 사용자를 그룹으로 묶어서 관리

✔ 직원들이 개별적으로 AWS 가입하는 게 아니라, 회사 계정 내에서 IAM 사용자 계정을 부여받는 것!

*예시

IAM: 권한 (Permissions)

• 사용자 또는 그룹에 JSON 정책(Policy)을 할당 가능
• 정책은 사용자의 권한을 정의함
• 최소 권한 원칙(Least Privilege Principle) 적용
  → 필요한 권한만 부여

예제 정책 (사용자에게 특정 서비스 조회 권한 부여)

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": "ec2:Describe*",
   "Resource": "*"
  },
  {
   "Effect": "Allow",
   "Action": "elasticloadbalancing:Describe*",
   "Resource": "*"
  },
  {
   "Effect": "Allow",
   "Action": [
     "cloudwatch:ListMetrics",
     "cloudwatch:GetMetricStatistics",
     "cloudwatch:Describe*"
   ],
   "Resource": "*"
  }
 ]
}

IAM 정책 상속 (Policies Inheritance)

• 정책은 사용자와 그룹에 할당됨
• 그룹에 속한 사용자는 해당 그룹의 정책을 상속받음
• Inline 정책: 특정 사용자에게 직접 적용 가능

IAM 정책 구조

• Version: 정책 언어 버전 (항상 "2012-10-17" 포함)
• Id: 정책 식별자 (선택 사항)
• Statement (필수)
  • Sid: 문서 내 정책의 식별자 (선택 사항)
  • Effect: "Allow" 또는 "Deny" 설정
  • Principal: 정책이 적용될 계정/사용자/역할(Role)
  • Action: 허용 또는 거부할 액션 목록
  • Resource: 적용될 리소스
  • Condition: 특정 조건이 충족될 때만 정책이 적용됨 (선택 사항)

IAM 비밀번호 정책

• 강력한 비밀번호 요구
• 설정 가능 항목
  • 최소 길이 지정
  • 대문자, 소문자, 숫자, 특수 문자 포함
  • 사용자가 자신의 비밀번호를 변경하도록 허용
  • 일정 기간 후 비밀번호 변경 요구 (비밀번호 만료)
  • 이전 비밀번호 재사용 방지

MFA (Multi-Factor Authentication)

• AWS 계정 보호를 위한 보안 기능
• 비밀번호 + 보안 장치(2차 인증) 필요
• MFA 사용 시 계정이 해킹당해도 접근 불가

MFA 장치 옵션

1. 가상 MFA 디바이스
   • Google Authenticator (모바일)
   • Authy (모바일)
2. Universal 2nd Factor (U2F) 보안 키
   • YubiKey (3rd Party)
3. 하드웨어 키 FOB
   • Gemalto (3rd Party)
   • AWS GovCloud용 SurePassID (3rd Party)

AWS 접근 방법

1. AWS 관리 콘솔 (비밀번호 + MFA)
2. AWS CLI (Command Line Interface) (Access Key 필요)
3. AWS SDK (Software Development Kit) (Access Key 필요)

• Access Key
  • Access Key ID ≈ 사용자명
  • Secret Access Key ≈ 비밀번호
  • 외부 공유 금지

AWS CLI & SDK

• AWS CLI
  • 명령어를 통해 AWS 서비스와 상호작용 가능
  • AWS 서비스의 API 직접 접근 가능
  • 스크립트를 작성하여 자동화 가능
• AWS SDK
  • AWS 서비스에 프로그램적으로 접근할 수 있는 라이브러리
  • 여러 프로그래밍 언어 지원 (JavaScript, Python, Java, C++, Go 등)
  • 모바일 및 IoT SDK 지원
  • AWS CLI는 AWS SDK for Python(Boto3)을 기반으로 동작

IAM 역할 (IAM Roles)

• 특정 AWS 서비스가 사용자의 대신 작업을 수행해야 할 경우 사용
• AWS 서비스에 권한을 부여하는 방식
• 대표적인 IAM 역할
  • EC2 인스턴스 역할
  • Lambda 함수 역할
  • CloudFormation 역할

IAM 보안 도구

• IAM Credentials Report (계정 수준)
  • 계정의 모든 사용자 및 자격 증명 상태를 보고함
• IAM Access Advisor (사용자 수준)
  • 사용자가 부여받은 권한과 마지막 사용 날짜 확인 가능
  • 불필요한 권한 제거에 활용 가능

IAM 모범 사례

✅ Root 계정 사용 최소화
✅ 하나의 물리적 사용자 = 하나의 AWS 사용자
✅ 그룹을 활용하여 권한 관리
✅ 강력한 비밀번호 정책 설정
✅ MFA 활성화 및 강제 적용
✅ AWS 서비스에 권한을 부여할 때 역할(Role) 사용
✅ CLI / SDK 사용 시 Access Key 사용
✅ IAM Credentials Report 및 Access Advisor로 정기적인 감사 수행
✅ IAM 사용자 및 Access Key 공유 금지

IAM 요약

• 사용자(User): 개별 AWS 계정, AWS 콘솔 로그인 가능
• 그룹(Group): 사용자만 포함 가능, 권한 관리 용이
• 정책(Policy): JSON 형식으로 사용자의 권한을 정의
• 역할(Role): EC2, Lambda 등 AWS 서비스에 권한 부여
• 보안(Security): MFA 및 비밀번호 정책 활용
• CLI / SDK: 프로그램적으로 AWS 자원 관리 가능
• Access Key: CLI 및 SDK를 사용한 AWS 접근 방법
• 감사(Audit): IAM Credential Report & Access Advisor 활용