테마
AWS Elastic Beanstalk과 Lightsail: 간편한 인프라 구축
소스 코드만 업로드하면 인프라를 자동으로 구성해주는 Elastic Beanstalk과, 복잡한 설정 없이 빠르게 서버를 구축할 수 있는 Lightsail을 이해한다.
실제 배포 흐름은 11장에서 이어집니다
이 문서는 Beanstalk과 Lightsail의 서비스 개요를 설명합니다. Static IP, Load Balancer, HTTPS, PM2, GitHub Actions까지 포함한 Lightsail 실전 배포는 11. VM 배포 실전: Lightsail에서 별도로 다룹니다.
학습 목표
- Elastic Beanstalk의 개념과 자동 구성 원리를 이해한다
- Beanstalk가 자동으로 생성하는 AWS 리소스의 종류와 역할을 파악한다
- DevOps 관점에서 Beanstalk의 가치를 설명할 수 있다
- Beanstalk 환경 생성/삭제 시 리소스 정리 흐름을 이해한다
- Lightsail의 개념과 EC2와의 차이점을 설명할 수 있다
- Lightsail로 WordPress 블로그를 구축하는 전체 흐름을 파악한다
- 각 서비스의 비용 구조와 삭제 시 주의사항을 숙지한다
Part 1: Elastic Beanstalk
1. Elastic Beanstalk란?
Elastic Beanstalk(일래스틱 빈스톡)은 개발자가 소스 코드만 업로드하면 인프라를 자동으로 구성해주는 AWS 서비스다. 개발자는 애플리케이션 코드에만 집중하고, 서버 프로비저닝, 로드 밸런싱, 오토 스케일링, 모니터링 같은 인프라 운영은 Beanstalk이 대신 처리해준다.
1.1 레스토랑 비유로 이해하기
Beanstalk을 이해하는 가장 쉬운 방법은 레스토랑 비유다.
| 일반 식당 (직접 인프라 구축) | Beanstalk 식당 (자동 인프라 구축) |
|---|---|
| 재료를 직접 구매한다 | 재료(소스 코드)만 가져간다 |
| 주방 설비를 직접 설치한다 | 요리사가 알아서 조리한다 |
| 요리사를 직접 고용한다 | 서빙도 알아서 해준다 |
| 서빙도 직접 한다 | 손님이 많으면 자동으로 테이블을 늘린다 |
| 손님이 많으면 직접 테이블을 추가한다 | 위생 점검(모니터링)도 자동이다 |
즉, 개발자는 재료(소스 코드)만 제출하면 나머지 모든 과정을 Beanstalk이 알아서 처리해주는 것이다.
1.2 지원 언어 및 플랫폼
Beanstalk은 대부분의 주요 프로그래밍 언어와 플랫폼을 지원한다.
| 언어/플랫폼 | 설명 |
|---|---|
| Go | Go 언어 애플리케이션 |
| Java | Java SE, Tomcat 기반 웹 애플리케이션 |
| .NET | .NET Core on Linux, .NET on Windows Server |
| Node.js | Express, Koa 등 Node.js 기반 웹 앱 |
| PHP | Laravel, WordPress 등 PHP 애플리케이션 |
| Python | Django, Flask 등 Python 웹 프레임워크 |
| Ruby | Rails, Sinatra 등 Ruby 애플리케이션 |
| Docker | 단일 컨테이너 또는 멀티 컨테이너 Docker 환경 |
Docker를 지원하기 때문에 사실상 어떤 언어로 작성된 애플리케이션이든 컨테이너화하면 Beanstalk에서 실행할 수 있다.
1.3 Beanstalk의 핵심 개념
Beanstalk을 사용할 때 알아야 할 핵심 개념은 세 가지다.
| 개념 | 설명 | 비유 |
|---|---|---|
| Application(애플리케이션) | Beanstalk 프로젝트의 최상위 컨테이너. 코드, 환경, 버전 등을 포함한다 | 레스토랑 브랜드 |
| Environment(환경) | 실제로 코드가 실행되는 인프라 환경. 하나의 Application 안에 여러 환경(개발, 스테이징, 운영)을 만들 수 있다 | 각 매장(본점, 강남점, 판교점) |
| Application Version(버전) | 업로드된 소스 코드의 특정 버전. S3에 저장된다 | 메뉴판 버전 (v1, v2, v3) |
2. Beanstalk가 자동으로 해주는 것
개발자가 소스 코드를 업로드하면, Beanstalk은 백그라운드에서 다음 리소스들을 자동으로 생성하고 연결한다. 이것이 Beanstalk의 가장 큰 가치다.
각 리소스의 역할을 자세히 살펴보자.
2.1 EC2 인스턴스 (Elastic Compute Cloud)
EC2 인스턴스는 애플리케이션이 실제로 실행되는 가상 서버다. Beanstalk은 선택한 플랫폼(Python, Node.js 등)에 맞는 AMI(Amazon Machine Image)를 사용하여 인스턴스를 자동으로 생성한다.
- 선택한 플랫폼에 맞는 런타임이 미리 설치되어 있다
- 인스턴스 타입(t2.micro, t3.small 등)은 환경 설정에서 변경할 수 있다
- Beanstalk 에이전트가 설치되어 상태 보고 및 배포 관리를 수행한다
2.2 Auto Scaling Group (ASG)
Auto Scaling Group은 트래픽 변화에 따라 EC2 인스턴스의 수를 자동으로 조절하는 그룹이다.
- 트래픽이 증가하면 인스턴스를 추가(Scale Out)한다
- 트래픽이 감소하면 인스턴스를 제거(Scale In)한다
- 최소/최대 인스턴스 수를 설정할 수 있다
- CPU 사용률, 네트워크 트래픽 등을 기준으로 스케일링 정책을 설정한다
2.3 Elastic Load Balancer (ELB)
ELB는 들어오는 트래픽을 여러 EC2 인스턴스에 균등하게 분배하는 로드 밸런서다.
- 사용자의 요청을 여러 서버로 분산시켜 부하를 줄인다
- Health Check(헬스 체크)를 통해 비정상 인스턴스를 자동으로 제외한다
- HTTPS 종료(SSL Termination)를 지원한다
- 환경 URL(예:
myapp-env.region.elasticbeanstalk.com)을 제공한다
2.4 CloudWatch 모니터링
CloudWatch는 AWS 리소스의 상태를 실시간으로 모니터링하는 서비스다. Beanstalk은 자동으로 다음 항목을 감시한다.
- CPU 사용률 (CPUUtilization)
- 네트워크 입출력 (NetworkIn/NetworkOut)
- 요청 수 (RequestCount)
- HTTP 상태 코드별 응답 수 (2xx, 3xx, 4xx, 5xx)
- 응답 지연 시간 (Latency)
- 환경 상태 (Health Status)
임계값을 초과하면 SNS를 통해 이메일 알림을 보내도록 자동 설정된다.
2.5 S3 백업 버킷
Beanstalk은 업로드된 소스 코드의 모든 버전을 S3 버킷에 저장한다.
- 버킷 이름은
elasticbeanstalk-<리전>-<계정ID>형식이다 - 각 애플리케이션 버전이 ZIP 파일로 저장된다
- 이전 버전으로 롤백할 때 이 저장소에서 가져온다
- 중요: Beanstalk 환경을 삭제해도 이 S3 버킷은 자동으로 삭제되지 않는다
2.6 Security Group (보안 그룹)
보안 그룹은 EC2 인스턴스와 ELB에 대한 네트워크 접근을 제어하는 방화벽 규칙이다.
- ELB용 보안 그룹: HTTP(80), HTTPS(443) 포트를 외부에 개방
- EC2용 보안 그룹: ELB에서 오는 트래픽만 허용 (직접 외부 접근 차단)
3. DevOps 관점에서의 Beanstalk
3.1 DevOps란?
DevOps(데브옵스)는 개발(Development)과 운영(Operations)을 결합한 문화이자 방법론이다. 전통적으로 개발 팀과 운영 팀은 분리되어 있었고, 이로 인해 다음과 같은 문제가 발생했다.
| 문제 | 설명 |
|---|---|
| 배포 지연 | 개발 팀이 코드를 완성해도 운영 팀의 인프라 준비가 늦어진다 |
| 책임 전가 | "코드 문제 아닌데요" vs "인프라 문제 아닌데요" |
| 환경 불일치 | 개발 환경에서는 되는데 운영 환경에서는 안 된다 |
| 느린 피드백 | 문제 발견부터 해결까지 시간이 오래 걸린다 |
DevOps는 이러한 벽을 허물고 개발과 운영을 하나의 흐름으로 통합하는 것을 목표로 한다.
3.2 Beanstalk = Ops 자동화
Beanstalk은 DevOps에서 Ops(운영) 부분을 자동화해주는 서비스다. 개발자가 직접 서버를 구축하고, 로드 밸런서를 설정하고, 모니터링을 구성할 필요 없이, 코드를 업로드하는 것만으로 전체 운영 인프라가 자동으로 갖춰진다.
수동으로 구성하면 7단계 이상의 복잡한 작업이 필요하지만, Beanstalk을 사용하면 소스 코드 업로드 한 번으로 끝난다. 개발자는 인프라 걱정 없이 애플리케이션 개발에만 집중할 수 있다.
3.3 Beanstalk vs 직접 구축 vs 다른 서비스 비교
| 항목 | EC2 직접 구축 | Elastic Beanstalk | AWS Lambda (서버리스) |
|---|---|---|---|
| 인프라 제어 | 완전한 제어 | 부분적 제어 (커스터마이즈 가능) | 제어 불가 |
| 설정 난이도 | 높음 | 낮음 | 매우 낮음 |
| 운영 부담 | 높음 | 낮음 | 거의 없음 |
| 적합한 대상 | 인프라 전문가 | 애플리케이션 개발자 | 이벤트 기반 함수 |
| 확장성 | 수동 또는 ASG 직접 설정 | 자동 (Beanstalk 관리) | 자동 (AWS 관리) |
| 비용 | 사용한 리소스만큼 | 사용한 리소스만큼 (Beanstalk 자체 무료) | 실행 시간만큼 |
4. 실습 흐름: Python(Django) 애플리케이션 배포
Beanstalk로 Python Django 애플리케이션을 배포하는 전체 실습 흐름을 단계별로 살펴보자.
4.1 Step 1: Beanstalk 환경 생성
- AWS 콘솔(Console)에서 Elastic Beanstalk 서비스로 이동한다
- Create Application을 클릭한다
- 다음 설정을 입력한다:
| 설정 항목 | 입력 값 | 설명 |
|---|---|---|
| Application name | my-django-app | 애플리케이션 이름 |
| Platform | Python | 언어/플랫폼 선택 |
| Platform branch | Python 3.x running on 64bit Amazon Linux 2023 | 최신 버전 선택 |
| Application code | Sample Application | 샘플 코드로 테스트 |
- Create application을 클릭하면 Beanstalk이 인프라 구축을 시작한다
4.2 Step 2: 자동 생성 과정 관찰
환경 생성을 시작하면 Beanstalk의 이벤트 로그에서 다음과 같은 과정이 순서대로 진행되는 것을 확인할 수 있다:
[INFO] createEnvironment is starting.
[INFO] Using elasticbeanstalk-ap-northeast-2-123456789012 as Amazon S3 storage bucket for environment data.
[INFO] Created security group named: sg-0abcdef1234567890
[INFO] Created load balancer named: awseb-e-xxxxxxxxxx-stack-AWSEBLoadBalancer-XXXX
[INFO] Created Auto Scaling launch configuration named: awseb-e-xxxxxxxxxx-stack-...
[INFO] Created Auto Scaling group named: awseb-e-xxxxxxxxxx-stack-AWSEBAutoScalingGroup-XXXX
[INFO] Created CloudWatch alarm named: awseb-e-xxxxxxxxxx-stack-...
[INFO] Successfully launched environment: my-django-app-env이 로그를 통해 S3 버킷, 보안 그룹, ELB, ASG, CloudWatch 알람이 순서대로 생성되는 것을 직접 확인할 수 있다.
4.3 Step 3: 자동 생성된 리소스 확인
환경 생성이 완료되면 AWS 콘솔에서 다음 리소스들이 생성된 것을 확인한다:
EC2 콘솔에서 확인:
- Instances(인스턴스): Beanstalk이 생성한 EC2 인스턴스가 Running 상태
- Name 태그에
my-django-app-env가 표시된다
EC2 > Auto Scaling Groups에서 확인:
awseb-e-xxxxxxxxxx-stack-AWSEBAutoScalingGroup-XXXX이름의 ASG가 생성- 최소 1개, 최대 4개(기본값) 인스턴스 설정
EC2 > Load Balancers에서 확인:
- Classic Load Balancer 또는 Application Load Balancer가 생성
- Health Check가 활성화되어 인스턴스 상태를 감시
CloudWatch 콘솔에서 확인:
- Beanstalk 환경 관련 알람이 자동 생성
- CPU, 네트워크, 상태 코드 등 기본 메트릭이 수집 중
S3 콘솔에서 확인:
elasticbeanstalk-<리전>-<계정ID>버킷이 생성- 업로드한 소스 코드(Sample Application)가 ZIP 형태로 저장
4.4 Step 4: Django 샘플 페이지 확인
환경이 정상적으로 생성되면 Beanstalk 콘솔에 환경 URL이 표시된다:
http://my-django-app-env.ap-northeast-2.elasticbeanstalk.com이 URL로 접속하면 Django 샘플 애플리케이션의 Welcome 페이지가 표시된다. 이 페이지가 보이면 소스 코드 업로드부터 서버 배포, 로드 밸런서 연결, DNS 설정까지 모든 과정이 자동으로 완료된 것이다.
4.5 환경 관리 기능
Beanstalk 콘솔에서는 다음과 같은 환경 관리 기능을 제공한다:
| 기능 | 설명 |
|---|---|
| Dashboard | 환경 상태(Health) 한눈에 확인. 초록색=정상, 빨간색=문제 |
| Configuration | 인스턴스 타입, ASG 설정, 환경 변수 변경 |
| Logs | 애플리케이션 로그 조회 및 다운로드 |
| Health | 각 인스턴스의 개별 상태, 요청 수, 응답 시간 확인 |
| Monitoring | CloudWatch 메트릭 그래프 시각화 |
| Events | 환경 변경 이력, 배포 로그, 오류 기록 |
| Upload and deploy | 새 버전 소스 코드 업로드 및 배포 |
5. Beanstalk 삭제: 리소스 정리 주의사항
Beanstalk 환경과 애플리케이션을 삭제할 때 가장 중요한 것은 모든 리소스가 완전히 정리되었는지 확인하는 것이다. 그렇지 않으면 의도치 않게 과금이 계속 발생할 수 있다.
5.1 삭제 순서
- Environment(환경) 삭제: Beanstalk 콘솔에서 환경을 Terminate한다
- Application(애플리케이션) 삭제: 환경 삭제 후 애플리케이션도 삭제한다
5.2 자동 삭제 vs 수동 삭제
5.3 S3 버킷 수동 삭제 절차
Beanstalk이 생성한 S3 버킷은 자동으로 삭제되지 않으므로, 다음 절차를 통해 수동으로 삭제해야 한다.
문제 상황: S3 버킷을 바로 삭제하려고 하면 "Access Denied" 오류가 발생할 수 있다. 이는 Beanstalk이 생성한 버킷 정책(Bucket Policy)에 삭제를 막는 Deny 규칙이 포함되어 있기 때문이다.
해결 절차:
- S3 콘솔로 이동:
elasticbeanstalk-<리전>-<계정ID>버킷을 찾는다 - 버킷 정책 확인: Permissions(권한) 탭에서 Bucket Policy를 확인한다
- Deny 정책 수정: 버킷 정책에서
Deny규칙을 제거하거나Allow로 변경한다
json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "eb-xxx",
"Effect": "Deny", // <-- 이 부분을 "Allow"로 변경
"Principal": "*",
"Action": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::elasticbeanstalk-ap-northeast-2-123456789012"
}
]
}- 버킷 비우기(Empty): 버킷 내 모든 객체를 삭제한다
- 버킷 삭제(Delete): 비어 있는 버킷을 삭제한다
주의: S3 버킷 삭제를 잊으면 저장된 객체 용량만큼 지속적으로 과금이 발생한다. Beanstalk 환경을 삭제한 후에는 반드시 S3 콘솔에서 관련 버킷을 확인하고 정리하자.
5.4 삭제 후 확인 체크리스트
| 확인 항목 | 콘솔 위치 | 상태 확인 |
|---|---|---|
| EC2 인스턴스 | EC2 > Instances | Terminated 상태인지 확인 |
| Auto Scaling Group | EC2 > Auto Scaling Groups | 삭제되었는지 확인 |
| Load Balancer | EC2 > Load Balancers | 삭제되었는지 확인 |
| Security Group | EC2 > Security Groups | Beanstalk 관련 SG 삭제 확인 |
| CloudWatch 알람 | CloudWatch > Alarms | 관련 알람 삭제 확인 |
| S3 버킷 | S3 > Buckets | 수동 삭제 완료 확인 (가장 중요!) |
Part 2: Amazon Lightsail
6. Lightsail이란?
Amazon Lightsail(아마존 라이트세일)은 웹사이트와 애플리케이션 구축에 필요한 모든 것을 제공하는 가상 프라이빗 서버(VPS, Virtual Private Server) 서비스다. EC2의 복잡한 설정 과정 없이, 몇 번의 클릭만으로 빠르게 서버를 구축할 수 있다.
6.1 EC2의 간편 버전
Lightsail을 가장 쉽게 이해하는 방법은 EC2의 간편 버전으로 생각하는 것이다.
| 비교 항목 | EC2 | Lightsail |
|---|---|---|
| 설정 복잡도 | 높음 (VPC, 서브넷, 보안 그룹, IAM 역할 등 직접 설정) | 낮음 (클릭 몇 번으로 완료) |
| 요금 체계 | 종량제 (사용한 만큼 과금, 예측 어려움) | 월정액제 (예: 월 $3.50, $5, $10) |
| 포함 사항 | 컴퓨트만 (스토리지, 네트워크 별도) | 컴퓨트 + 스토리지 + 네트워크 + 고정 IP 번들 |
| 대상 사용자 | 인프라 전문가, 대규모 시스템 | 개인 개발자, 소규모 프로젝트, 블로거 |
| 커스터마이징 | 매우 자유로움 | 제한적 (간편함과 트레이드오프) |
| 스케일링 | Auto Scaling, ELB 등 고급 옵션 | 제한적 (인스턴스 플랜 업그레이드) |
6.2 Lightsail의 주요 용도
Lightsail은 다음과 같은 용도에 특히 적합하다:
- WordPress 블로그/웹사이트: 가장 대표적인 사용 사례. 원클릭 WordPress 설치 지원
- 개인 포트폴리오 사이트: 간단한 정적/동적 웹사이트
- 소규모 웹 애플리케이션: 트래픽이 적은 소규모 서비스
- 개발/테스트 환경: 빠르게 서버를 띄워서 테스트
- 게임 서버: Minecraft 같은 소규모 게임 서버
- VPN 서버: 개인용 VPN 서버 구축
6.3 Lightsail 요금 플랜 (서울 리전 기준)
| 플랜 | 메모리 | vCPU | SSD | 전송량 | 월 요금 | 비고 |
|---|---|---|---|---|---|---|
| $3.50 | 512MB | 1 | 20GB | 1TB | $3.50 | 3개월 무료 |
| $5 | 1GB | 1 | 40GB | 2TB | $5 | 3개월 무료 |
| $10 | 2GB | 1 | 60GB | 3TB | $10 | 3개월 무료 |
| $20 | 4GB | 2 | 80GB | 4TB | $20 | |
| $40 | 8GB | 2 | 160GB | 5TB | $40 | |
| $80 | 16GB | 4 | 320GB | 6TB | $80 | |
| $160 | 32GB | 8 | 640GB | 7TB | $160 |
참고: 저사양 플랜($3.50, $5, $10)은 첫 3개월 무료다. 무료 기간이 끝나면 자동으로 월정액이 청구되므로, 학습 목적이라면 무료 기간 내에 삭제하는 것이 좋다.
7. WordPress 블로그 구축 실습
Lightsail의 가장 대표적인 사용 사례인 WordPress 블로그 구축을 단계별로 살펴보자.
7.1 Step 1: Lightsail 인스턴스 생성
- AWS 콘솔에서 Lightsail 서비스로 이동한다
- Create instance를 클릭한다
- 다음 설정을 선택한다:
| 설정 항목 | 선택 값 | 설명 |
|---|---|---|
| Instance location | Seoul, Zone A (ap-northeast-2a) | 서울 리전 선택 (한국 사용자에게 가장 빠른 응답) |
| Platform | Linux/Unix | 운영 체제 선택 |
| Blueprint | WordPress | Apps + OS 카테고리에서 WordPress 선택 |
| Instance plan | $3.50 USD (512MB, 1 vCPU) | 3개월 무료 플랜 |
| Instance name | WordPress-1 | 인스턴스 이름 지정 |
- Create instance를 클릭하면 약 2-3분 후 인스턴스가 생성된다
7.2 Step 2: WordPress 블로그 접속
인스턴스가 Running 상태가 되면 Public IP 주소가 할당된다.
- Lightsail 콘솔에서 인스턴스의 Public IP를 확인한다 (예:
3.36.xx.xx) - 웹 브라우저에서
http://3.36.xx.xx로 접속한다 - WordPress 기본 블로그 페이지가 표시된다
이 시점에서 이미 WordPress가 설치되고, Apache 웹 서버가 실행 중이며, MySQL 데이터베이스가 구성된 상태다. Lightsail이 Bitnami WordPress 스택을 자동으로 설치해준 것이다.
7.3 Step 3: 관리자 비밀번호 확인 (SSH)
WordPress 관리자 페이지에 로그인하려면 비밀번호가 필요하다. 이 비밀번호는 인스턴스 내부에 저장되어 있다.
- Lightsail 콘솔에서 인스턴스를 클릭한다
- Connect using SSH 버튼을 클릭하여 브라우저 기반 SSH 터미널을 연다
- 터미널에서 다음 명령어를 실행한다:
bash
cat bitnami_application_password- 출력된 문자열이 WordPress 관리자 비밀번호다. 이 비밀번호를 복사해둔다
예시 출력: a1B2c3D4e5F6참고:
bitnami_application_password파일은 홈 디렉토리(/home/bitnami/)에 위치한다. 인스턴스가 처음 생성될 때 Bitnami가 자동으로 랜덤 비밀번호를 생성하여 이 파일에 저장한다.
7.4 Step 4: WordPress 관리자 로그인
- 웹 브라우저에서
http://<Public-IP>/login또는http://<Public-IP>/wp-admin으로 접속한다 - 로그인 정보를 입력한다:
| 항목 | 값 |
|---|---|
| Username | user |
| Password | SSH에서 확인한 비밀번호 |
- Log In을 클릭하면 WordPress 관리자 대시보드에 진입한다
7.5 Step 5: WordPress 관리 및 포스트 수정
관리자 대시보드에서 다음 작업을 수행할 수 있다:
| 메뉴 | 기능 |
|---|---|
| Posts | 블로그 포스트 작성, 수정, 삭제 |
| Pages | 정적 페이지 관리 (About, Contact 등) |
| Appearance > Themes | 블로그 테마(디자인) 변경 |
| Plugins | 기능 확장 플러그인 설치/관리 |
| Settings | 사이트 제목, 언어, 퍼머링크 등 설정 |
| Users | 사용자 관리, 비밀번호 변경 |
포스트 수정 실습:
- 좌측 메뉴에서 Posts > All Posts를 클릭한다
- 기본으로 생성된 "Hello world!" 포스트를 클릭한다
- 제목과 내용을 원하는 대로 수정한다
- Update를 클릭하여 변경사항을 저장한다
- 블로그 메인 페이지(
http://<Public-IP>)에서 수정된 내용을 확인한다
8. Lightsail 인스턴스 삭제
학습이 끝나면 과금을 방지하기 위해 Lightsail 인스턴스를 삭제해야 한다.
8.1 삭제 절차
- Lightsail 콘솔에서 삭제할 인스턴스를 선택한다
- 인스턴스 상세 페이지 또는 인스턴스 카드의 점 세 개(...) 메뉴를 클릭한다
- Delete를 클릭한다
- 확인 대화상자에서 Yes, delete를 클릭한다
8.2 Lightsail 삭제 시 확인 사항
| 항목 | 자동 삭제 여부 | 비고 |
|---|---|---|
| 인스턴스 | 삭제됨 | 즉시 삭제 |
| 인스턴스의 SSD | 삭제됨 | 인스턴스와 함께 삭제 |
| 자동 스냅샷 | 삭제됨 | 인스턴스와 함께 삭제 |
| 수동 스냅샷 | 삭제 안 됨 | 별도로 삭제 필요 |
| Static IP | 삭제 안 됨 | 할당 해제 후 별도 삭제 (미사용 시 과금) |
| DNS Zone | 삭제 안 됨 | 별도로 삭제 필요 |
주의: Static IP(고정 IP)를 생성했다면 인스턴스 삭제와 별개로 Static IP도 삭제해야 한다. 인스턴스에 연결되지 않은 Static IP는 과금이 발생한다.
9. Beanstalk vs Lightsail 비교 정리
| 비교 항목 | Elastic Beanstalk | Lightsail |
|---|---|---|
| 핵심 용도 | 웹 애플리케이션 자동 배포/운영 | 간편한 가상 서버(VPS) |
| 대상 사용자 | 애플리케이션 개발자 | 개인 개발자, 블로거, 소규모 프로젝트 |
| 인프라 구성 | 자동 (EC2 + ASG + ELB + CloudWatch + S3) | 단일 인스턴스 (컴퓨트 + 스토리지 + 네트워크 번들) |
| 스케일링 | Auto Scaling 자동 지원 | 수동 (플랜 업그레이드) |
| 배포 방식 | 소스 코드 업로드 | SSH 접속 또는 블루프린트 |
| 요금 체계 | Beanstalk 무료 + 생성된 리소스 비용 | 월정액 (3개월 무료 플랜 있음) |
| 삭제 시 주의 | S3 버킷 수동 삭제 필요 | Static IP, 수동 스냅샷 별도 삭제 |
| 적합한 시나리오 | 프로덕션 웹 앱 운영, CI/CD 파이프라인 | WordPress 블로그, 개인 웹사이트, 테스트 서버 |
10. 비용 주의사항 총정리
AWS 서비스를 학습 목적으로 사용할 때 가장 중요한 것은 의도치 않은 과금 방지다.
10.1 Elastic Beanstalk 비용
| 항목 | 비용 |
|---|---|
| Beanstalk 서비스 자체 | 무료 |
| EC2 인스턴스 | t2.micro 프리 티어(Free Tier) 내 무료, 초과 시 과금 |
| Elastic Load Balancer | 프리 티어 없음, 사용 즉시 과금 시작 |
| S3 스토리지 | 5GB까지 프리 티어 무료 |
| CloudWatch | 기본 모니터링 무료, 상세 모니터링 과금 |
| 데이터 전송 | 월 1GB까지 무료 |
핵심: Beanstalk 자체는 무료이지만, Beanstalk이 생성하는 리소스(특히 ELB)에 비용이 발생한다. 학습 후 반드시 환경을 삭제하고 S3 버킷도 수동으로 정리해야 한다.
10.2 Lightsail 비용
| 항목 | 비용 |
|---|---|
| 저사양 플랜 ($3.50, $5, $10) | 첫 3개월 무료 |
| 무료 기간 이후 | 선택한 플랜의 월정액 자동 청구 |
| 미사용 Static IP | 과금 발생 ($0.005/시간, 약 $3.60/월) |
| 수동 스냅샷 | 저장 용량에 따라 과금 ($0.05/GB/월) |
핵심: 3개월 무료 기간이 끝나기 전에 인스턴스를 삭제하고, Static IP와 수동 스냅샷도 함께 정리해야 한다.
10.3 비용 방지 체크리스트
- [ ] Beanstalk: Application 삭제 완료
- [ ] Beanstalk: EC2 인스턴스 Terminated 상태 확인
- [ ] Beanstalk: ELB 삭제 확인
- [ ] Beanstalk: S3 버킷 수동 삭제 완료
- [ ] Lightsail: 인스턴스 Delete 완료
- [ ] Lightsail: Static IP 삭제 확인 (생성한 경우)
- [ ] Lightsail: 수동 스냅샷 삭제 확인 (생성한 경우)
- [ ] AWS Billing 콘솔에서 예상치 못한 청구 내역 없는지 확인
핵심 정리
| 핵심 개념 | 요약 |
|---|---|
| Elastic Beanstalk | 소스 코드만 업로드하면 EC2, ASG, ELB, CloudWatch, S3 등 인프라를 자동 구성해주는 PaaS(Platform as a Service) |
| Beanstalk 자동 구성 | EC2 인스턴스, Auto Scaling Group, Elastic Load Balancer, CloudWatch 알람, S3 버킷, Security Group을 자동 생성 |
| DevOps와 Beanstalk | DevOps의 Ops(운영) 부분을 자동화하여 개발자가 코드에만 집중하게 해준다 |
| Beanstalk 삭제 주의 | Application 삭제 시 대부분의 리소스는 자동 삭제되지만, S3 버킷은 수동으로 삭제해야 한다 |
| Lightsail | EC2의 간편 버전. 월정액으로 컴퓨트+스토리지+네트워크 번들을 제공하는 VPS 서비스 |
| Lightsail 주 용도 | WordPress 같은 설치형 블로그/웹사이트를 복잡한 설정 없이 빠르게 구축 |
| Lightsail 삭제 주의 | 인스턴스 삭제 외에 Static IP, 수동 스냅샷도 별도로 삭제해야 과금을 방지할 수 있다 |
| 비용 핵심 | Beanstalk 자체는 무료(생성 리소스 과금), Lightsail은 저사양 3개월 무료 후 월정액 |