이번 달 결제 예정비용이 56달러...
불필요한 cloudfront 로그 삭제하고 , 엇그제 서울 리전에서 오사카 리전으로 마이그레이션한 DB 스냅샷도 삭제하고, 인스턴스 관련 비용 절감이 가능하다면 진행해보려고 한다.
🚀 현재 AWS 결제 예정 요금 요약표
좀더 보기 쉽게 표로 정리하면,
| 항목 | 리전 | 세부 정보 | 사용량 | 단가 | 월 예상 비용 (USD) |
|---|---|---|---|---|---|
| EC2 - t2.micro | 오사카 | 프리티어 무료 | 215.93 시간 | $0.00 | $0.00 |
| EC2 - t2.small | 오사카 | On-Demand | 697.24 시간 | $0.0304/hr | $21.20 |
| EBS (gp2) | 오사카 | 유료 구간 7.831GB | - | $0.12/GB-Mo | $0.94 |
| 총합 | $22.14 |
🔧 비용 절감을 위한 우선순위 정리표
| 절감 대상 | 현재 비용 | 절감 가능액 | 절감 방법 | 비고 |
|---|---|---|---|---|
| EC2 - t2.small | $21.20 | 최대 $21.20 | t3a.small로 다운그레이드 또는 중지 스케줄링 설정 | 월 사용량이 많을 경우 가장 효과적 |
| EC2 자동 중지 설정 | 포함 | 수 달러~최대 $21.20 | 사용하지 않는 시간대에 자동 중지 스케줄링 | Lambda + EventBridge or AWS Instance Scheduler |
| EBS 용량 축소 (30GB → 15GB) | $0.94 | 최대 $0.94 | AMI 생성 후 작은 볼륨으로 새 인스턴스 생성 | 현재 EBS 용량 사용률이 10% 수준 |
| EC2 Spot 인스턴스 사용 | N/A | 최대 70% 절감 | t2.small → Spot 인스턴스로 대체 | 비즈니스 중요도 낮을 때 추천 |
EC2 다운그레이드 시도
memory가 2GB는 최소 되어야하기 때문에, 비용 메리트가 있는 t3a.small 로 변경하고자 한다.
| 항목 | t2.small | t3a.small | 차이점 |
|---|---|---|---|
| vCPU | 1 | 2 | 🔺 t3a는 2 vCPU로 병렬 처리 성능 향상 |
| 메모리 | 2 GB | 2 GB | 동일 |
| CPU 성능 모델 | Intel Xeon (Haswell) | AMD EPYC (2nd Gen) | t3a는 더 최신 아키텍처 |
| 베이스 성능 | CPU 크레딧 기반 (burstable) | CPU 크레딧 기반 (burstable) | 비슷하나 t3a가 더 효율적 |
| 크레딧 초과 시 성능 | 제한됨 | Unlimited 모드 가능 (기본은 제한) | t3a는 유연하게 무제한 설정 가능 |
| 요금 (오사카 기준) | $0.0304/hr | $0.0208/hr | 💰 약 31.5% 저렴 |
| 지원 기능 | IPv6, ENA, T2 전용 | IPv6, ENA, 최신 Nitro 기반 | t3a는 더 최신 네트워크 및 Nitro 하드웨어 지원 |
BUT...
오사카를 포함한 일부 리전에는 t2a.small 이 없네...
그왕 이렇게 된거 확 비용을 낮추기 위해 스팟 인스턴스 로 바꿔야겠다!!
🚀 액션 플랜 for spot instance
- 인스턴스 비용 최적화
변경 내용: 온디맨드 인스턴스(t2.small) → 스팟 인스턴스(t2.small)
기대 효과: 약 ~70% 비용 절감
- 자동 스케줄링 도입 (추후)
목표: 야간/새벽 시간대 인스턴스 자동 중지 및 재시작
방법 예시: AWS Lambda + EventBridge를 활용한 스케줄링 자동화
cf. 스팟 인스턴스는 "AWS의 남는 컴퓨팅 자원을 임시로 빌려 쓰는 구조이기 때문에 언제든지 종료될 수 있다.
스팟 인스턴스가 갑자기 종료된 경우 ASG 최소인스턴스 수가 1개이기 때문에 중간에 잠시 중단은 되겠지만 웬만하면 새 인스턴스가 생성될 것 이다. 우리는 개발서버이므로 이 정도로 만족하는 것으로..
온디맨드 -> 스팟 인스턴스로 변경
1. ECS service 의 컵퓨팅 옵션 수정하기 (시작유형 EC2 -> 용량 공급자 전략 ASG로 )
🔥 왜 그래야 하냐면:
🚫 "시작 유형 > EC2" 선택 시:
ECS는 단순히 EC2 인스턴스가 이미 떠 있다고 가정하고 그 위에 태스크를 배치하려고만 시도한다. 기존의 온디멘드는 이 구조였으나,
스팟 인스턴스는 Auto Scaling Group (ASG) 이 자동으로 인스턴스를 띄워야 하고,
이걸 ECS가 인식하려면 ASG 기반 Capacity Provider 가 필요하다.
즉, EC2 시작 유형은 "수동 인스턴스 관리" 에 가까워서, 인스턴스가 미리 떠 있지 않으면 ECS는 아무것도 실행하지 못한다.
🚀 해결 방법
Capacity Provider 생성 (ASG를 기반으로)
ECS 콘솔 > 클러스터 > Capacity Providers 탭
새 용량 공급자 생성 > 기존 ASG 선택 > managed scaling 및 managed termination 사용
클러스터에 해당 Capacity Provider 연결
ECS 서비스 수정 > 컴퓨팅 옵션 > 용량 공급자 전략 선택
예: capacity-provider-name: 1 (가중치 1)
(에러) 2. ASG의 활동 로그 확인하기
1번으로 ECS 서비스 수정 후 업데이트 배포해도 문제가 발생한다면 ASG에서 인스턴스가 잘 실행은 되었는지 로그 확인하기
2가지 에러로그 발견
1. 루트 볼륨 암호화 문제 (Hibernate 관련)
Status Reason: For hibernation, the root device volume must be encrypted.
🔍 원인:
시작 템플릿에서 Hibernate(절전) 옵션이 켜져 있는데, 루트 EBS 볼륨이 암호화되지 않아 스팟 인스턴스를 시작할 수 없음.
🚀 해결 방법:
Hibernate 옵션 끄고 시작템플릿에 포함하지않음으로 변경
EC2 > 시작 템플릿 수정 > 고급 설정에서 Hibernate 체크 해제
또는 루트 볼륨 암호화 설정을 추가 (추천하지 않음 — 복잡하고 필요 없음)
2. 용량 부족 (AZ 가용성 문제)
Status Reason: We currently do not have sufficient t3.small capacity in the Availability Zone you requested (ap-northeast-3b).
🔍 원인:
ap-northeast-3b 가용 영역에서 t3.small 스팟 인스턴스의 재고가 없음.
스팟은 온디맨드보다 가용성 낮고, AZ별로 재고가 다름.
🚀 해결 방법:
Auto Scaling Group 또는 시작 템플릿에서 특정 AZ를 지정하지 말고, ap-northeast-3a, 3b, 3c 중 모든 AZ에 배포 가능하도록 설정.
서비스 업데이트 배포하니 스팟 인스턴스로 ECS 배포 성공~
