작은 서비스가 서버 비용을 줄이려고 먼저 할 일은 네 가지입니다. 안 쓰는 리소스(빌려 쓰는 서버·저장 공간 같은 자원)를 끄고, 서비스 크기에 맞는 사양을 고르고, 예산 알림을 걸고, 약정 할인은 쓰는 양이 보인 뒤에 검토하는 것입니다.
2026년 11월 5일 AWS의 공식 설계 지침인 Well-Architected Framework의 비용 최적화(Cost Optimization) 문서를 읽고, 작은 서비스에 맞게 추렸습니다. 네 가지의 순서는 문서가 정한 것이 아니라 이 글의 정리입니다.
1. 서버 비용 절감, 무엇부터 해야 하나요?
안 쓰는 리소스를 끄는 일부터입니다. 쓰지 않는 서버는 서비스에 아무것도 더하지 않고 비용만 만들기 때문입니다. 다음이 사양을 맞추는 일이고, 그다음이 알림과 약정 할인입니다.
공식 문서는 비용 최적화가 된 워크로드(서비스 한 벌)를 이렇게 정의합니다. 아래는 영어 원문이고, 우리말로 옮겼습니다. 자원을 빠짐없이 쓰고, 가능한 한 낮은 가격으로 결과를 내고, 필요한 기능을 만족하는 상태입니다.
A cost-optimized workload fully utilizes all resources, achieves an outcome at the lowest possible price point, and meets your functional requirements.
이 문서는 구현 세부 사항이나 아키텍처 패턴은 주지 않고 관련 자료를 안내한다고 스스로 밝혔습니다. 그래서 아래 네 가지는 원칙을 작은 서비스 눈높이로 옮긴 것이고, 실제 설정은 각 서비스 문서와 앞선 글을 따라가면 됩니다.
2. 안 쓰는 리소스부터 끕니다
공식 문서의 설계 원칙 중 하나는 소비 모델(consumption model)입니다. 쓰는 만큼만 내고, 사업 요구에 따라 사용량을 늘리거나 줄이라는 뜻입니다. 개발·테스트용 환경은 보통 평일 하루 8시간만 쓰이므로, 안 쓸 때 멈추면 75%의 잠재적 절감이 있다고 예를 듭니다.
75%는 주 40시간과 168시간을 비교한 계산이고, 문서도 「잠재적 절감(potential cost savings)」이라고 적었습니다. 모든 서버에 해당하는 숫자가 아니라 평일 낮에만 쓰는 환경 같은 경우의 예입니다.
서버(EC2)와 데이터베이스(RDS)를 퇴근 뒤와 주말에 꺼도 되는지 따져 보라는 안내도 있습니다. 멈춘 동안은 서버(컴퓨팅) 요금이 멈추고 저장 공간 요금만 남는다고 적혀 있습니다. 완전히 지우는 방법과 주의점은 aws 비용 환불, 요청할 수 있을까?에서 다뤘습니다.
얼마나 자주 찾아볼지에 대한 문장이 작은 서비스에게는 위로가 됩니다. 공식 문서는 안 쓰는 리소스를 찾는 수고도 절감액에 맞추라고 하며, 비용이 작은 계정은 큰 계정보다 덜 자주 분석하는 것이 맞다고 적었습니다. 끄기 전에는 스냅샷(저장 공간의 백업본)이나 백업 같은 마지막 점검을 하라는 안내도 있습니다.
3. 사양은 쓰는 양에 맞춥니다
사양은 서버의 크기와 종류입니다. 공식 문서는 서버 종류와 크기를 일의 특성(계산·메모리·처리량·쓰기 중심 등)에 맞춰 고르라고 합니다. 필요한 사양은 쓰려는 소프트웨어의 요구 사항을 모아 알아냅니다.
모을 정보로는 운영체제, CPU 코어 수, 메모리, 저장 공간과 종류, 네트워크 대역폭 등이 나옵니다. 비용 모델링이나 가격 계산기로 숫자를 미리 보면 결정에 도움이 된다고도 적었습니다. 계산기 쓰는 법은 aws 비용 계산기, 처음 쓰는 법에 있습니다.
이미 서버를 돌리고 있다면 AWS Cost Optimization Hub가 도움이 됩니다. 처음 열 때 한 번 가입(opt in)해야 하고, 사양 조정(rightsizing)과 Savings Plans 추천 등을 모아 보여 줍니다.
비용 관리 콘솔 홈의 Savings opportunities 위젯에도 같은 추천이 나옵니다.
4. 예산 알림은 서비스를 올릴 때 함께 겁니다
공식 문서는 계정마다 AWS Budgets를 설정하라고 권합니다. 계정 전체 지출의 예산을 세우고, 예산을 넘었거나 예상 비용이 예산을 넘을 때 알림을 받도록 합니다. 비용 이상 탐지(Cost Anomaly Detection)도 함께 쓰라고 적었습니다.
알림에는 실제 비용 기준과 예상 비용 기준이 있습니다. 문서는 실제 비용 알림은 사후 대응이고, 예상 비용 알림은 초과를 막을 대응 시간을 준다고 설명합니다. 설정 순서와 알림이 늦을 수 있다는 한계는 aws 비용 폭탄, 미리 막는 설정에 정리했습니다.
5. 약정 할인은 쓰는 양을 본 뒤에 검토합니다
약정 할인은 오래 쓰겠다고 약속하는 대신 단가를 낮추는 방식입니다. 공식 문서는 먼저 서비스 부품이 오래 켜져 있을지, 짧고 들쭉날쭉하게 쓰일지를 구분하라고 합니다. 오래 켜질 것은 약정 할인, 짧고 변동이 큰 것은 스팟이나 온디맨드가 맞는다는 설명입니다.
약정 할인은 한동안 일정하게 쓰는 서버에 맞는 방법이고, 쓰는 양이 아직 불확실하다면 온디맨드로 시작해 보는 편이 안전합니다. 앞의 문장은 문서의 구분이고, 뒤의 문장은 이 글의 제안입니다.
문서에 나온 가격 방식은 네 가지입니다. 온디맨드(On-Demand)는 약정이나 선결제 없이 시간·초 단위로 냅니다.
Savings Plans는 EC2·Lambda·Fargate 사용에 대해 1년이나 3년 동안 시간당 일정 금액을 쓰겠다고 약속하는 대신 낮은 가격을 받습니다. 예약 인스턴스(Reserved Instances)는 선결제로 용량을 예약해 최대 75% 할인을 받는다고 이 문서는 적었습니다.
스팟(Spot)은 남는 용량을 최대 90% 할인된 시간당 요금으로 쓰며 약정은 없고, 장애에 견디는 유연한 작업에 쓰는 방식입니다.
이 문서가 쓴 예약 인스턴스 75%와 스팟 90%는 모두 「최대(up to)」이니 상한으로 읽어야 하고, 앞에서 본 75%(정지 시간 계산)와는 다른 숫자입니다.
2026년 11월 5일 EC2 예약 인스턴스 요금 페이지는 표준형을 최대 72%로 적어 상한이 문서마다 다르니, 실제 값은 요금 페이지와 계산기로 확인합니다. 약정은 계정을 닫아도 기간이 끝날 때까지 청구가 이어질 수 있다고 Billing 문서가 적었습니다.
어떤 약정이 맞는지는 Cost Explorer의 Savings Plans와 예약 인스턴스 추천에서 볼 수 있습니다. 비용 확인 화면은 aws 비용 확인, 어디서 보나?에서 안내했습니다.
6. 서버를 직접 두지 않는 길도 있습니다
공식 문서의 설계 원칙에는 데이터센터 운영의 무거운 일은 AWS가 맡고, 관리형 서비스는 운영체제와 애플리케이션을 직접 관리하는 부담도 덜어 준다는 내용이 있습니다. 서버를 직접 두지 않는 서비스를 고르는 것도 비슷한 방향으로 볼 수 있습니다.
그 길의 요금은 서비스마다 따로 정해집니다. firebase 비용, 무료 한도 넘으면? · supabase 비용, 무료와 pro 차이 · vercel 비용, 무료 hobby로 충분할까?에 각각 정리했습니다.
정리하면 작은 서비스가 먼저 할 일은 네 가지입니다.
- 안 쓰는 리소스를 찾아 끕니다(끄기 전 스냅샷·백업)
- 서비스에 필요한 만큼으로 서버 사양을 고릅니다
- 예산 알림과 비용 이상 탐지를 걸어 둡니다
- 쓰는 양이 일정한 것만 약정 할인(Savings Plans·예약 인스턴스)을 검토합니다
서버를 직접 고르고 관리하는 대신 홈페이지·예약 화면을 만들어 바로 공개하고 싶다면, 이 블로그를 운영하는 AiApp에서는 업종별 템플릿에서 시작해 대화로 바꾸고 클릭 한 번으로 실제 주소에 공개할 수 있습니다(호스팅 포함).
무료로 프로젝트 하나를 만들어 배포까지 해 볼 수 있습니다. 무료는 배포 후 14일 공개이고, 백엔드 기능과 문자 발송은 유료부터입니다. 직접 만들기 어렵다면 견적 페이지에서 AI로 견적을 내 보고 맡길 때 비용을 먼저 볼 수 있습니다. 요금은 요금제 페이지에 있습니다.
세 회사 클라우드 비용의 전체 지도는 클라우드 비용 비교 총정리, AWS·GCP·Azure에, 호스팅을 고르는 기준은 웹호스팅 추천 총정리, 고르는 기준에 있습니다.
참고자료 (모두 2026년 11월 5일 확인)
- AWS Well-Architected Framework, Cost Optimization Pillar 「Abstract and introduction」 — docs.aws.amazon.com/wellarchitected/…/welcome.html
- Cost Optimization Pillar 「Design principles」 — docs.aws.amazon.com/wellarchitected/…/design-principles.html
- Cost Optimization Pillar 「COST04-BP03 Decommission resources」 — docs.aws.amazon.com/wellarchitected/…/cost_decomissioning_resources_decommission.html
- Cost Optimization Pillar 「COST06-BP02 Select resource type, size, and number based on data」 — docs.aws.amazon.com/wellarchitected/…/cost_type_size_number_resources_data.html
- Cost Optimization Pillar 「COST07-BP01 Perform pricing model analysis」 — docs.aws.amazon.com/wellarchitected/…/cost_pricing_model_analysis.html
- Cost Optimization Pillar 「COST01-BP03 Establish cloud budgets and forecasts」·「COST03-BP05 Configure billing and cost management tools」 — docs.aws.amazon.com/wellarchitected/…/cost_monitor_usage_config_tools.html
- AWS Cost Management User Guide 「Getting started with Cost Optimization Hub」 — docs.aws.amazon.com/…/coh-getting-started.html
- AWS Billing User Guide 「Understanding unexpected charges」 — docs.aws.amazon.com/…/checklistforunwantedcharges.html
- AWS 「Amazon EC2 예약 인스턴스」 요금 페이지 — aws.amazon.com/ec2/pricing/reserved-instances
#서버비용절감 #AWS비용최적화 #WellArchitected #클라우드비용 #작은서비스
