AWS - 세 개의 아키텍처 예시 및 Beanstalk

WhatIsTheTime.com — 첫 번째 아키텍처 여정

1. 초기 단계 – 단일 EC2 인스턴스

• 단일 T2.micro EC2 인스턴스에서 웹 애플리케이션 실행
• 데이터베이스는 없음 (단순히 현재 시간만 제공)
• 탄력적 IP(Elastic IP) 연결 → 인스턴스 재시작 시에도 동일한 공인 IP 유지
• 장점: 간단하고 빠르게 배포 가능
• 단점: 인스턴스 다운 시 다운타임 발생

2. 수직 확장 (Vertical Scaling)

• 트래픽 증가로 인해 인스턴스 스펙을 업그레이드 (T2.micro → M5.large)
• EC2 인스턴스를 중지 → 인스턴스 유형 변경 → 재시작
• 탄력적 IP 덕분에 IP는 동일
• 장점: 더 많은 요청 처리 가능
• 단점: 업그레이드 시 서비스 중단 시간 존재

3. 수평 확장 (Horizontal Scaling)

• EC2 인스턴스를 여러 개 추가 (예: 3개 M5.large)
• 각 인스턴스에 개별 탄력적 IP 연결
• 장점: 병렬 처리로 부하 분산 가능
• 단점: 사용자가 어떤 IP로 요청해야 하는지 알아야 함, 관리 복잡도 증가, 탄력적 IP 제한(계정당 지역별 기본 값)

4. DNS 적용 – Route 53 도입

• 여러 인스턴스를 하나의 도메인 이름으로 묶음
• Route 53에서 A 레코드 설정 → 여러 IP 반환
• 사용자: whatisthetime.com 도메인으로 접근
• TTL(Time To Live) = 1시간 → DNS 캐싱 유지
• 문제: 인스턴스 중 하나가 다운되어도 TTL 동안 계속 캐시된 IP로 요청함 → 사용자 경험 악화

5. 로드 밸런서(ELB) 도입

• 각 EC2 인스턴스를 프라이빗 서브넷에 배치
• 외부 트래픽은 공개형 로드 밸런서(ELB)를 통해 분산
• ELB의 상태 확인(Health Check)으로 비정상 인스턴스 제외
• Route 53에서 별칭(Alias) 레코드로 ELB 연결 (ELB IP는 변경될 수 있으므로 A 레코드 대신 Alias 사용)
• 장점: 자동 부하 분산, 장애 인스턴스 자동 제외
• 단점: 인스턴스 수동 추가/삭제 필요(다음 단계에서 해결)

6. 오토 스케일링 그룹 (Auto Scaling Group, ASG)

• 트래픽에 따라 EC2 인스턴스 수 자동 조절
  • 낮에는 축소, 피크 시간대에는 확장
• ELB와 자동 연동 → 신규 인스턴스 자동 등록
• 장점: 자동 확장, 자동 복구, 다운타임 최소화
• 단점: 단일 가용 영역(AZ)에만 존재하면 AZ 장애에 취약

7. 멀티 AZ 아키텍처로 발전

• 오토 스케일링 그룹을 여러 가용 영역(AZ)에 걸쳐 구성
• ELB도 멀티 AZ로 구성
• 장애 발생 시 다른 AZ의 인스턴스가 트래픽 처리
• 장점: 고가용성 확보, 장애 복원력 향상

8. 비용 최적화 – 예약 인스턴스 & 스팟 인스턴스

• 항상 실행되는 최소 인스턴스는 예약 인스턴스(Reserved Instance) 사용 → 장기 할인
• 일시적 확장용 인스턴스는 스팟 인스턴스(Spot Instance) 활용 → 비용 절감
• 장점: 효율적인 비용 관리, 확장성과 고가용성 유지

전체 아키텍처 요약

단계	구성 요소	특징	문제점 / 개선점
1	단일 EC2 + Elastic IP	간단한 구조	다운타임 발생
2	수직 확장	성능 향상	중단 시간 존재
3	수평 확장	부하 분산 가능	IP 관리 복잡
4	Route 53 A 레코드	도메인 기반 접근	TTL 캐싱 문제
5	ELB + Alias 레코드	자동 부하 분산	인스턴스 수동 관리
6	Auto Scaling Group	자동 확장/축소	단일 AZ 장애 취약
7	Multi-AZ ELB & ASG	고가용성 확보	비용 증가
8	Reserved + Spot	비용 절감	관리 복잡성 증가

핵심 포인트 정리

• Elastic IP: 고정된 공인 IP 제공(단, 관리 복잡)
• Route 53 Alias: ELB 등 AWS 리소스와 연동 가능한 DNS 레코드
• ELB Health Check: 비정상 인스턴스로의 트래픽 방지
• Auto Scaling Group: 수요 기반 자동 확장 및 복구
• Multi-AZ 배포: 장애 복원력 향상
• Reserved/Spot Instance: 비용 효율화

1. 기존 구조 복습: WhatIsTheTime.com

• 단순한 무상태 웹 애플리케이션
• 데이터베이스 없이 현재 시간만 반환
• 확장이 쉬움 (EC2 인스턴스를 추가하면 됨)
• 문제: 상태(세션)가 없기 때문에 사용자별 정보 저장 불가

---

2. 새로운 목표: MyClothes.com

• 사용자가 온라인으로 옷을 구매할 수 있는 웹사이트
• 장바구니(Cart) 기능 존재 → 상태 유지 필요
• 동시에 수백 명의 사용자가 접속
• 목표:
  • 수평 확장성(Horizontal scalability) 유지
  • 웹 티어는 가능하면 무상태로 설계
  • 사용자가 인스턴스가 바뀌더라도 장바구니가 사라지지 않게

---

3. 문제 발생: 무상태 환경에서의 장바구니 손실

• ELB가 여러 EC2 인스턴스에 요청을 분산
• 사용자 A가 장바구니에 상품 추가 → EC2 인스턴스 #1에 저장
• 다음 요청이 EC2 인스턴스 #2로 가면 장바구니 정보 손실
• 사용자는 “장바구니가 사라졌다”고 인식 → 불만 유발

---

4. 해결 방법 ① ELB 고착도(Session Stickiness)

• ELB에서 세션 고착도(Sticky Session) 활성화
• 한 사용자의 요청이 항상 같은 EC2 인스턴스로 전달됨
• 장점: 장바구니 유지 가능
• 단점:
  • 특정 인스턴스에 트래픽 집중
  • 인스턴스 종료 시 세션 데이터 손실
  • 장애 복구에 불리함

---

5. 해결 방법 ② 클라이언트 쿠키 기반 저장

• 장바구니 데이터를 EC2 인스턴스가 아닌 사용자 브라우저 쿠키에 저장
• 서버는 쿠키 내용을 읽어 장바구니를 복원
• 장점: 모든 인스턴스에서 무상태 유지 가능
• 단점:
  • 쿠키 크기 제한 (4KB 이하)
  • HTTP 요청 크기 증가
  • 보안 위험 (클라이언트가 쿠키 수정 가능 → 검증 필요)

---

6. 해결 방법 ③ 세션 ID + ElastiCache

• 서버 측 세션 관리 도입
• 클라이언트는 장바구니 전체 데이터를 보내는 대신 세션 ID만 전송
• EC2 인스턴스는 세션 ID를 키로 ElastiCache(Redis/Memcached) 에 데이터 저장
• 이후 요청에서 어떤 인스턴스에 도착하더라도 ElastiCache에서 세션 복원 가능
• 장점:
  • 완전한 무상태 EC2 설계 가능
  • 빠른 접근 (밀리초 이하 응답 속도)
  • 높은 보안성 (ElastiCache는 외부에서 접근 불가)
• 단점: ElastiCache 관리 필요

---

7. 대안: DynamoDB 세션 스토리지

• 세션 정보를 영구적으로 저장해야 할 경우 ElastiCache 대신 DynamoDB 사용 가능
• ElastiCache보다 느리지만 지속성(persistence) 확보

---

8. 사용자 정보 저장 – RDS 도입

• 사용자 주소, 주문 정보 등 영구 데이터 저장 필요
• EC2 인스턴스가 RDS(MySQL, PostgreSQL 등) 와 직접 통신
• 장점: 구조화된 데이터, 안정적인 장기 저장
• RDS를 다중 AZ로 구성 → 장애 대비

---

9. 읽기 트래픽 증가 → 읽기 전용 복제본(Read Replica)

• RDS의 읽기 부하를 줄이기 위해 읽기 전용 복제본(Read Replica) 추가
• 최대 5개의 읽기 복제본 가능
• 쓰기 요청은 마스터 RDS로, 읽기 요청은 복제본으로 분산

---

10. 캐싱 패턴 도입 (ElastiCache + RDS)

• EC2 → ElastiCache → (미존재 시) RDS
• 데이터가 캐시에 있으면 바로 응답 (Cache Hit)
• 없으면 RDS에서 읽고 캐시에 저장 (Cache Miss)
• 장점:
  • DB 부하 감소
  • 응답 속도 향상
• 단점:
  • 캐시 동기화 및 만료 관리 필요

---

11. 재해 복구 및 고가용성 설계

• Route 53: 이미 고가용성 DNS 서비스
• ELB: 다중 AZ 구성
• Auto Scaling Group: 다중 AZ 배포로 EC2 복구
• RDS: 다중 AZ 및 대기 복제본(Standby Replica)
• ElastiCache: 다중 AZ 클러스터 가능

---

12. 보안 그룹 설계

• ELB: 외부 HTTP/HTTPS 요청 허용
• EC2 인스턴스: ELB로부터의 요청만 허용
• ElastiCache: EC2 보안 그룹으로부터의 트래픽만 허용
• RDS: EC2 보안 그룹으로부터의 트래픽만 허용
• 원칙: 최소 권한(least privilege) 기반의 네트워크 설계

---

13. 최종 아키텍처 요약

계층	구성 요소	역할	비고
클라이언트	브라우저	세션 ID 저장 및 요청 전송	쿠키 사용 가능
웹 티어	EC2 + ELB + Auto Scaling	무상태 웹 서버	다중 AZ 배포
캐시 티어	ElastiCache	세션/데이터 캐싱	초고속 접근
데이터베이스 티어	RDS (Multi-AZ + Read Replica)	영구 데이터 저장	읽기 확장
DNS	Route 53	도메인 및 트래픽 분산	Alias 레코드 사용
보안	Security Groups	티어 간 접근 제어	최소 권한 원칙

---

14. 요약

• 세션 문제 해결 방법
  1. ELB 고착도 (Stickiness)
  2. 클라이언트 쿠키
  3. ElastiCache 세션 스토어
  4. DynamoDB 세션 스토어 (대안)
• 영구 데이터는 RDS에 저장
• 읽기 부하를 위해 Read Replica 또는 ElastiCache 사용
• 재해 복구는 Multi-AZ 구조로 대응
• 세부 보안은 Security Group으로 제어
• 전체 구조는 3-Tier Architecture (Web, Cache, DB) 형태로 완성

1. WordPress 웹사이트 구조

• WordPress는 전 세계적으로 가장 많이 사용되는 웹사이트 프레임워크 중 하나.
• 사용자는 이미지를 업로드하고, 포스트를 작성하며, 데이터는 모두 MySQL 데이터베이스에 저장됨.
• 따라서 데이터 저장과 이미지 접근이 핵심 과제임.

---

2. 기본 아키텍처 구성

• 사용자 → 로드 밸런서(ELB) → EC2 인스턴스 → RDS(MySQL)
• EC2 인스턴스들은 로드 밸런서 뒤에서 웹 트래픽을 처리.
• 데이터베이스는 RDS에 저장되어 있음.
• 다중 AZ 구성으로 장애 복구 대비 가능.

---

3. RDS → Aurora로 확장

• WordPress의 데이터베이스 부하가 커지면 RDS MySQL 대신 Amazon Aurora MySQL 사용.
• Aurora의 장점:
  • 자동 복제 (다중 AZ)
  • 읽기 전용 복제본(Read Replica)
  • 글로벌 데이터베이스 지원 (여러 지역에서 접근 가능)
  • 더 높은 확장성, 낮은 관리 비용, 높은 성능

---

4. 이미지 저장 방식의 문제점

• WordPress는 업로드한 이미지를 EC2 인스턴스의 EBS 볼륨에 저장.
• 단일 EC2 인스턴스 + EBS 볼륨 환경에서는 문제 없음.
• 하지만 확장(멀티 인스턴스, 멀티 AZ) 시 문제가 발생:
  • 인스턴스 A에 저장된 이미지가 인스턴스 B에서는 안 보임.
  • 이유: 각 인스턴스는 자신만의 EBS 볼륨을 가지고 있기 때문.
  • 따라서 EBS는 단일 인스턴스 전용 저장소로 적합.

---

5. 해결책: EFS (Elastic File System)

• EFS는 네트워크 파일 시스템(NFS) 기반의 공유 스토리지.
• 여러 EC2 인스턴스가 동시에 같은 EFS를 마운트하여 접근 가능.
• 각 AZ에 ENI(Elastic Network Interface) 를 두어 연결.
• 모든 인스턴스가 동일한 파일(예: 이미지)에 접근 가능.
• EFS는 다중 AZ와 수평 확장 환경에서 매우 유용.

---

6. 비용과 선택

항목	특징	장점	단점
EBS	인스턴스 1개 전용 스토리지	빠르고 저렴	확장 불가, AZ 종속
EFS	여러 인스턴스 공유 스토리지	다중 AZ 지원, 확장성 높음	더 비쌈

• 따라서 소규모 단일 서버 환경 → EBS,
  확장형 다중 인스턴스 환경 → EFS 가 적합.

---

7. 정리

• RDS → Aurora 로 전환해 데이터베이스를 확장.
• EBS → EFS 로 전환해 이미지 저장소를 공유화.
• 이렇게 하면:
  • 다중 AZ에서 가용성이 높아지고,
  • 모든 인스턴스가 동일한 파일 시스템을 공유,
  • 웹사이트 트래픽이 늘어나도 안정적으로 작동.

1. 문제 상황

• EC2 인스턴스를 새로 시작하면
  • OS 설치
  • 애플리케이션 설치
  • 종속성 설정
  • 데이터 삽입 및 초기화
  • 환경 구성
    이 모든 과정 때문에 시작 속도가 느림.

→ 운영 환경에서 빠른 확장이 어렵고, 장애 복구 시에도 지연 발생.

---

2. 해결 방법 요약

AWS에서는 AMI, User Data, Snapshot을 활용해
애플리케이션을 “즉시 실행 가능한 상태”로 만들 수 있습니다.

---

3. Golden AMI (골든 AMI)

• AMI (Amazon Machine Image): EC2 인스턴스의 OS, 애플리케이션, 설정 등을 포함한 이미지.
• Golden AMI는 “완전히 설정된 상태”의 표준화된 이미지.

특징

• 필요한 애플리케이션, 라이브러리, 환경변수가 이미 설치되어 있음.
• 이후 인스턴스를 실행할 때 추가 설치 과정이 없음.
• 수 초 내에 동일한 환경의 인스턴스를 여러 개 실행 가능.

장점

• 인스턴스 시작 속도 대폭 향상.
• 환경 일관성 보장 (모든 인스턴스가 동일 상태로 시작).
• 반복 작업 제거 (매번 설치 불필요).

---

4. EC2 사용자 데이터(User Data)

• 인스턴스 시작 시 초기 스크립트 실행 기능.
• 보통 부트스트래핑(bootstrapping) 에 사용:
  • 패키지 설치 (yum install, apt-get install)
  • 설정 파일 다운로드
  • 애플리케이션 자동 시작 등

단점

• 인스턴스 시작 시마다 스크립트가 실행되므로 시간이 오래 걸림.
• 반복적인 설정에는 비효율적.

---

5. Golden AMI + User Data 하이브리드

• 두 방법을 조합하는 것이 가장 효과적.
• Golden AMI에 OS와 주요 앱을 미리 설치해두고,
  User Data로 동적 구성(예: DB 주소, 비밀번호, 환경변수 등)만 설정.
• Elastic Beanstalk, Auto Scaling 등도 이 원리를 내부적으로 활용함.

---

6. RDS와 EBS의 빠른 초기화

(1) RDS

• RDS는 대량의 데이터를 수동으로 삽입하면 느림.
• 스냅샷(snapshot) 을 사용하면,
  • 기존 데이터베이스의 구조와 데이터를 그대로 복구 가능.
  • 즉시 사용 가능한 DB 생성 가능.

(2) EBS

• 새 볼륨은 포맷이 필요하지만,
• EBS 스냅샷으로부터 복구하면 이미 포맷된 상태로, 데이터도 포함되어 있음.
• 즉시 연결 후 사용 가능.

---

7. 시험 대비 핵심 요약

항목	목적	가속 방법
EC2 인스턴스	애플리케이션 실행	Golden AMI + User Data
RDS	데이터베이스 초기화	스냅샷 복구
EBS 볼륨	디스크 데이터 복구	스냅샷 복구

---

8. 결론

• Golden AMI: 미리 구성된 애플리케이션 환경
• User Data: 동적 환경 설정
• RDS/EBS 스냅샷: 데이터 복구 시간 단축
• 이 세 가지를 결합하면
  → 클라우드 인프라의 부팅 및 배포 속도를 극대화할 수 있음.

1. 배경: 기존의 애플리케이션 배포 문제

이전까지는 웹 애플리케이션을 배포하려면 다음과 같은 과정을 직접 했습니다.

• 로드 밸런서(ELB) 설정
• 오토 스케일링 그룹(ASG) 설정
• 여러 가용 영역(AZ)에 EC2 인스턴스 배포
• RDS 데이터베이스 연결
• 캐시 서버(ElastiCache) 구성

즉, 인프라를 일일이 구성하고 관리해야 했기 때문에 매우 번거롭고 복잡했습니다.

---

2. Elastic Beanstalk의 등장

**Elastic Beanstalk(엘라스틱 빈스톡)**은 이런 과정을 자동화해주는 애플리케이션 배포용 관리형 서비스입니다.

즉,

“개발자는 코드만 신경 쓰고, AWS가 나머지 인프라를 대신 관리해주는 서비스”

라고 생각하면 됩니다.

---

3. Elastic Beanstalk의 역할

Beanstalk은 다음을 자동으로 처리합니다:

• EC2, ASG, ELB, RDS 등의 리소스 프로비저닝
• 로드 밸런서 구성
• 자동 확장 설정
• 모니터링 및 인스턴스 상태 관리

개발자는 오직 “코드 업로드”만 하면 됩니다.

하지만, 완전한 제어권도 여전히 있습니다.
즉, 원하면 EC2 설정, 오토스케일링 규칙, 보안그룹 등을 세부적으로 수정할 수도 있습니다.

---

4. Beanstalk의 기본 구조

Elastic Beanstalk은 다음 세 가지 구성 요소로 이루어집니다:

구성 요소	설명
Application (애플리케이션)	Beanstalk 프로젝트의 최상위 개념. 여러 환경(environment)과 버전(version)을 포함
Application Version (버전)	코드의 버전. 예: v1, v2, v3 등
Environment (환경)	실제로 코드가 실행되는 인프라 집합. 한 환경에는 한 번에 한 버전만 실행 가능

즉,

“하나의 애플리케이션 안에 여러 버전을 업로드하고, 각각의 버전을 다양한 환경(dev/test/prod)에서 실행할 수 있다.”

---

5. Beanstalk의 두 가지 티어 (Tier)

Elastic Beanstalk에는 두 가지 실행 모드가 있습니다.

티어설명

웹 서버 환경 (Web Server Tier)	일반적인 웹 애플리케이션용 환경. 로드 밸런서 → 오토스케일링 그룹 → EC2 인스턴스 구조
작업자 환경 (Worker Tier)	백그라운드 작업용 환경. 메시지 대기열(SQS)에서 메시지를 받아 EC2에서 처리

즉,

• 웹 티어는 사용자 요청을 직접 처리
• 작업자 티어는 비동기 작업(백엔드 처리) 담당
  → 예: 이메일 발송, 이미지 처리, 로그 정리 등

두 환경은 함께 동작할 수도 있습니다.
(웹 환경이 메시지를 SQS로 보내면, 작업자 환경이 그것을 받아 처리)

---

6. 배포 모드

Elastic Beanstalk은 다음 두 가지 방식으로 배포됩니다.

모드	설명
단일 인스턴스 배포	개발·테스트용. EC2 한 대만 사용하며 Elastic IP로 접속 가능
로드 밸런서 기반 배포 (고가용성)	실제 서비스(Production)용. ELB + 오토스케일링 그룹 + Multi-AZ 구조

---

7. 지원 언어

Beanstalk은 다양한 프로그래밍 언어를 지원합니다:

• Go
• Java (Tomcat 포함)
• .NET / .NET Core
• Node.js
• Python
• Ruby
• PHP
• Docker (단일 / 다중 컨테이너)

즉, 거의 모든 웹 프레임워크를 바로 배포할 수 있습니다.

---

8. 요약

항목내용

목적	인프라 자동화 + 코드 중심 배포
관리형 리소스	EC2, ASG, ELB, RDS
구성 요소	Application / Version / Environment
티어	웹 서버 티어, 작업자 티어
배포 모드	단일 인스턴스 / 고가용성
비용	Beanstalk 자체는 무료, 하지만 사용하는 리소스(EC2 등)는 유료

1. Elastic Beanstalk 실습 개요

이 강의에서는 AWS 콘솔에서 첫 번째 Elastic Beanstalk 애플리케이션을 만들어 Node.js 웹 애플리케이션을 배포하는 과정을 실습합니다.

Beanstalk이 하는 일은 다음과 같습니다:

• EC2 인스턴스 생성
• 로드 밸런서, 오토스케일링 그룹 구성
• Elastic IP 및 보안 그룹 생성
• CloudFormation을 통해 인프라 자동화
• 코드 배포 및 모니터링

---

2. 환경(Environment) 생성 단계

① Beanstalk Console 진입

AWS Management Console에서 Elastic Beanstalk 서비스로 이동합니다.

---

② 애플리케이션 생성

• Application name: MyApplication
• Environment type:
  • Web server environment → 웹사이트 요청 처리용
  • (참고: 백그라운드 작업용은 Worker environment)

---

③ 환경 정보 설정

• Environment name: 자동으로 생성됨 (예: MyApplication-dev)
• Domain: Beanstalk이 자동 생성 (예: myapplication-dev.ap-northeast-2.elasticbeanstalk.com)

이 도메인 주소로 웹 서버에 접근할 수 있습니다.

---

④ 플랫폼 선택

• Platform: Node.js 선택
• Platform branch/version: 기본값 유지
• Application code: Sample application 선택
  → AWS가 제공하는 기본 샘플 앱이 자동 배포됩니다.

---

⑤ 사전 설정(Presets)

• Single instance (무료 티어용)
  → 개발 및 테스트용 (EC2 한 대, Elastic IP 포함)
• 또는
  High availability (로드 밸런서 포함)
  → 실제 운영(Production) 환경용

지금은 Single instance로 진행.

---

⑥ Service Access (IAM 역할 설정)

Elastic Beanstalk이 AWS 리소스를 생성/관리하려면 IAM 권한이 필요합니다.

• Service role: aws-elasticbeanstalk-service-role 자동 생성 (없으면 새로 생성)
• EC2 instance profile:
  IAM Console → Roles → Create role
  • Trusted entity: EC2
  • Attach policies:
    • AWSElasticBeanstalkWebTier
    • AWSElasticBeanstalkWorkerTier
    • AWSElasticBeanstalkMulticontainerDocker
  • Role name: aws-elasticbeanstalk-ec2-role

생성 후 Beanstalk 콘솔에서 새로고침하면 자동 인식됩니다.

---

⑦ Review 및 생성

• 설정을 확인하고
• “Skip to review” → “Submit” 클릭

---

3. 백그라운드에서 일어나는 일

Beanstalk이 내부적으로 CloudFormation Stack을 생성합니다.

CloudFormation은 Beanstalk이 필요한 모든 인프라를 자동으로 구축합니다:

• Auto Scaling Group
• Launch Configuration
• Elastic IP
• Security Group
• EC2 Instance 등

CloudFormation Console → Stacks → Events 탭에서 생성 과정을 실시간으로 볼 수 있습니다.
완료되면 상태가 CREATE_COMPLETE로 변경됩니다.

---

4. 배포 확인

• Elastic Beanstalk Console → Environment → Events 탭
  → “Instance created”, “Environment health: OK” 등의 메시지 확인 가능
• EC2 Console → Instances 탭
  → Beanstalk이 생성한 t3.micro 인스턴스 확인
• Elastic IPs 탭
  → 인스턴스에 할당된 Elastic IP 확인

모두 정상이라면 Beanstalk 도메인 클릭 시

“Congratulations, your application is now running on AWS Elastic Beanstalk!”
이 문구가 뜹니다.

---

5. 환경 관리 기능

Elastic Beanstalk는 단순히 배포뿐 아니라, 환경을 손쉽게 관리·확장·업데이트할 수 있습니다.

기능	설명
Upload and deploy	새 애플리케이션 버전 업로드 및 즉시 배포
Health	모든 인스턴스의 상태 모니터링
Logs	애플리케이션 및 시스템 로그 확인
Monitoring	CPU, 메모리, 요청 수 등 메트릭 모니터링
Configuration	EC2 타입, 스케일링 규칙, 보안그룹, DB 연결 등 수정 가능
Alarms	상태 이상 시 알림 설정 가능

---

6. 여러 환경 관리

예를 들어:

• MyApplication-dev (개발용)
• MyApplication-prod (운영용)

이렇게 여러 환경을 같은 애플리케이션 안에서 분리 관리할 수 있습니다.
각 환경은 독립된 리소스 세트를 가집니다.

---

7. 실습 종료 및 정리

학습 후에는:

• Elastic Beanstalk Console → MyApplication → Actions → Delete application
  → EC2, Auto Scaling Group, Elastic IP 등 모든 리소스가 자동 삭제됩니다.

---

8. 요약

단계	설명
1. Beanstalk console 진입	AWS 콘솔에서 서비스 실행
2. 애플리케이션 생성	이름, 환경(Web) 지정
3. 플랫폼 선택	Node.js (Sample App)
4. IAM 역할 연결	Beanstalk 관리 권한 설정
5. 생성 및 배포	CloudFormation이 인프라 자동 생성
6. 확인	도메인으로 접속 → 정상 실행 확인
7. 관리 및 삭제	Health, Logs, Config, Delete 등 활용