본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
본 콘텐츠의 이미지 및 내용을 무단으로 복제, 배포, 수정하여 사용할 경우 저작권법에 의해 법적 제재를 받을 수 있습니다.
이미지 로딩 중...
AI Generated
2025. 12. 19. · 9 Views
AWS 비용 관리 기초 완벽 가이드
AWS를 처음 사용하는 개발자를 위한 비용 관리 입문서입니다. 요금 구조부터 청구서 확인, 예산 알람 설정까지 실무에 필요한 모든 것을 담았습니다. 프리티어를 최대한 활용하고 비용을 효율적으로 관리하는 방법을 배워보세요.
목차
1. AWS 요금 구조
신입 개발자 최민수 씨는 회사에서 처음으로 AWS 프로젝트를 맡게 되었습니다. 설레는 마음으로 EC2 인스턴스를 띄우고, S3 버킷도 만들었습니다.
그런데 한 달 후, 예상치 못한 청구서를 받고 깜짝 놀랐습니다. "분명 프리티어라고 했는데, 왜 요금이 나온 거지?"
AWS 요금 구조는 사용한 만큼만 지불하는 종량제 방식입니다. 마치 전기 요금처럼 실제 사용한 리소스에 대해서만 비용이 발생합니다.
각 서비스마다 과금 기준이 다르며, 리전, 사용량, 데이터 전송량 등 여러 요소가 복합적으로 작용합니다. 이를 제대로 이해하면 예상치 못한 비용 청구를 방지할 수 있습니다.
다음 코드를 살펴봅시다.
// AWS SDK로 현재 사용 중인 리소스 조회 예제
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });
// 실행 중인 EC2 인스턴스 목록 조회
ec2.describeInstances({}, (err, data) => {
if (err) console.log(err);
else {
data.Reservations.forEach(reservation => {
reservation.Instances.forEach(instance => {
// 인스턴스 타입과 상태 확인 - 비용 발생 여부 체크
console.log(`인스턴스: ${instance.InstanceId}`);
console.log(`타입: ${instance.InstanceType}, 상태: ${instance.State.Name}`);
});
});
}
});
최민수 씨는 팀장님께 조심스럽게 물어봤습니다. "팀장님, 제가 뭔가 잘못한 건가요?" 팀장 김현우 씨는 웃으며 말했습니다.
"아니에요. AWS 요금 구조를 아직 이해하지 못해서 그래요.
같이 한번 살펴볼까요?" AWS의 요금 구조는 처음 접하는 사람에게는 다소 복잡하게 느껴질 수 있습니다. 하지만 기본 원리만 이해하면 생각보다 단순합니다.
가장 기본이 되는 원칙은 종량제입니다. 쉽게 비유하자면, AWS는 마치 편의점과 같습니다.
필요한 물건을 그때그때 사서 쓰고, 사용한 만큼만 계산하면 됩니다. 미리 큰 금액을 내고 계약할 필요가 없습니다.
그렇다면 어떤 기준으로 요금이 책정될까요? EC2 인스턴스의 경우 실행 시간을 기준으로 합니다.
인스턴스가 켜져 있는 시간만큼 비용이 발생합니다. t2.micro는 시간당 약 0.0116달러, t2.small은 시간당 약 0.023달러입니다.
작은 차이처럼 보이지만, 한 달 내내 켜두면 두 배의 비용 차이가 납니다. S3는 조금 다릅니다.
저장 용량과 데이터 전송량으로 요금이 결정됩니다. 파일을 S3에 저장해두는 것만으로도 비용이 발생하고, 외부에서 파일을 다운로드할 때도 추가 비용이 붙습니다.
마치 창고 임대료와 택배비를 따로 내는 것과 같습니다. RDS 데이터베이스는 인스턴스 실행 시간과 스토리지 용량이 모두 과금됩니다.
데이터베이스는 항상 켜져 있어야 하는 경우가 많아서, 개발 환경에서는 비용이 빠르게 증가할 수 있습니다. 가장 많은 초보자들이 놓치는 부분은 데이터 전송 비용입니다.
AWS 안에서 같은 리전 내 데이터 전송은 대부분 무료입니다. 하지만 인터넷으로 데이터를 내보낼 때는 비용이 발생합니다.
처음 1GB는 무료지만, 그 이후부터는 GB당 약 0.09달러가 부과됩니다. 동영상이나 큰 파일을 서비스한다면 이 비용이 생각보다 클 수 있습니다.
리전도 중요한 요소입니다. 같은 서비스라도 미국 버지니아 리전이 서울 리전보다 저렴합니다.
하지만 한국 사용자를 대상으로 하는 서비스라면, 속도를 위해 서울 리전을 선택하는 것이 일반적입니다. 위의 코드를 살펴보면, AWS SDK를 사용해 현재 실행 중인 EC2 인스턴스를 조회하는 방법을 알 수 있습니다.
describeInstances 메서드로 인스턴스 목록을 가져오고, 각 인스턴스의 타입과 상태를 확인합니다. 이렇게 주기적으로 리소스를 점검하면 불필요한 비용 발생을 막을 수 있습니다.
실제 현업에서는 어떻게 관리할까요? 대부분의 스타트업은 개발 환경과 운영 환경을 분리합니다.
개발 환경은 업무 시간에만 켜두고, 퇴근 시간에는 자동으로 종료되도록 설정합니다. 주말에는 완전히 꺼둡니다.
이렇게만 해도 개발 환경 비용을 70% 이상 절감할 수 있습니다. 주의할 점도 있습니다.
프리티어라고 해서 완전 무료는 아닙니다. 프리티어는 일정 사용량까지만 무료입니다.
EC2 t2.micro는 월 750시간까지 무료인데, 이는 인스턴스 1대를 한 달 내내 켜두는 것과 같습니다. 2대를 켜두면 프리티어를 초과하게 됩니다.
최민수 씨는 팀장님의 설명을 듣고 자신의 실수를 깨달았습니다. 테스트용으로 여러 대의 인스턴스를 켜두고 잊어버렸던 것입니다.
"앞으로는 사용하지 않는 리소스는 바로 종료해야겠어요." AWS 요금 구조를 제대로 이해하면 합리적인 비용으로 클라우드 서비스를 활용할 수 있습니다. 처음에는 복잡하게 느껴지지만, 각 서비스의 과금 기준만 파악하면 충분히 관리 가능합니다.
실전 팁
💡 - 사용하지 않는 리소스는 즉시 종료하거나 삭제하세요
- 개발 환경은 업무 시간에만 켜두고 자동화 스크립트로 관리하세요
- 각 서비스의 프리티어 한도를 미리 확인하고 초과하지 않도록 주의하세요
2. Cost Explorer 사용
입사 6개월 차 개발자 이지은 씨는 매달 AWS 청구서를 확인할 때마다 답답했습니다. "도대체 어떤 서비스에서 비용이 많이 나가는 거지?
숫자만 보여줘서 알 수가 없네." 그때 선배 개발자 박준혁 씨가 다가와 말했습니다. "Cost Explorer 써봤어요?
거기 들어가면 비용을 한눈에 볼 수 있어요."
Cost Explorer는 AWS 비용을 시각화해서 보여주는 강력한 도구입니다. 마치 가계부 앱처럼 어디에 돈을 많이 썼는지 그래프와 차트로 확인할 수 있습니다.
서비스별, 리전별, 시간대별로 비용을 분석하고, 미래 비용을 예측할 수도 있습니다. 비용 관리의 출발점이라고 할 수 있습니다.
다음 코드를 살펴봅시다.
// AWS Cost Explorer API를 사용한 비용 조회 예제
const AWS = require('aws-sdk');
const costExplorer = new AWS.CostExplorer({ region: 'us-east-1' });
const params = {
TimePeriod: {
Start: '2025-11-01', // 조회 시작일
End: '2025-12-01' // 조회 종료일
},
Granularity: 'MONTHLY', // 월별 조회
Metrics: ['UnblendedCost'], // 실제 지불 비용
GroupBy: [{
Type: 'DIMENSION',
Key: 'SERVICE' // 서비스별로 그룹화
}]
};
// 비용 데이터 가져오기
costExplorer.getCostAndUsage(params, (err, data) => {
if (err) console.log(err);
else {
console.log('서비스별 비용:');
console.log(JSON.stringify(data, null, 2));
}
});
이지은 씨는 박준혁 씨를 따라 AWS 콘솔에 접속했습니다. 왼쪽 메뉴에서 Billing and Cost Management를 찾아 들어가니, Cost Explorer라는 메뉴가 보였습니다.
Cost Explorer를 처음 열면 화려한 그래프가 나타납니다. 처음에는 복잡해 보이지만, 사실은 아주 직관적입니다.
쉽게 비유하자면, Cost Explorer는 마치 은행 앱의 소비 분석 기능과 같습니다. 카드 사용 내역을 카테고리별로 보여주고, 이번 달에 어디에 돈을 많이 썼는지 파이 차트로 보여주는 것처럼, Cost Explorer도 AWS 서비스별 지출을 시각적으로 보여줍니다.
기본 화면에서는 지난 6개월의 비용이 막대 그래프로 표시됩니다. 각 막대를 클릭하면 그 달의 상세 내역을 볼 수 있습니다.
갑자기 비용이 튄 달이 있다면, 그 달에 무슨 일이 있었는지 쉽게 파악할 수 있습니다. 가장 유용한 기능은 그룹화입니다.
서비스별로 그룹화하면 EC2에서 얼마, S3에서 얼마, RDS에서 얼마를 썼는지 한눈에 보입니다. 리전별로 그룹화하면 서울 리전과 미국 리전의 비용을 비교할 수 있습니다.
태그별로 그룹화하면 프로젝트별 비용도 추적 가능합니다. 이지은 씨는 서비스별로 그룹화해봤습니다.
그래프를 보니 예상외로 NAT Gateway에서 비용이 많이 나가고 있었습니다. "아, 이게 문제였구나.
우리가 NAT Gateway를 3개나 띄워놨네." 필터 기능도 강력합니다. 특정 서비스만 보고 싶다면 필터를 적용하면 됩니다.
EC2만 보고 싶다면 Service 필터에서 EC2를 선택합니다. 특정 태그가 붙은 리소스만 보고 싶다면 태그 필터를 사용합니다.
프로덕션 환경과 개발 환경의 비용을 분리해서 볼 수 있습니다. 예측 기능은 미래를 준비하는 데 도움을 줍니다.
현재 사용 패턴을 분석해서 다음 달 예상 비용을 보여줍니다. 만약 이번 달 사용량이 평소보다 많다면, 예측 비용도 높게 나옵니다.
이를 보고 미리 대응할 수 있습니다. 위의 코드는 Cost Explorer API를 프로그래밍 방식으로 사용하는 예제입니다.
getCostAndUsage 메서드로 특정 기간의 비용 데이터를 가져옵니다. TimePeriod로 조회 기간을 지정하고, GroupBy로 서비스별로 그룹화합니다.
이렇게 가져온 데이터를 자동화된 리포트나 슬랙 알림으로 활용할 수 있습니다. 실무에서는 어떻게 활용할까요?
많은 회사에서 매주 월요일 아침마다 지난주 비용 리포트를 자동으로 생성합니다. Cost Explorer API로 데이터를 가져와서 슬랙이나 이메일로 전송합니다.
팀원들이 비용 추이를 공유하고, 이상 징후가 있으면 즉시 대응합니다. 주의해야 할 점도 있습니다.
Cost Explorer의 데이터는 최대 24시간 지연될 수 있습니다. 오늘 아침에 EC2를 켰다고 해서 바로 그래프에 나타나지 않습니다.
하루 정도 기다려야 정확한 데이터를 볼 수 있습니다. 또한 Cost Explorer 자체도 유료입니다.
API 호출 1회당 0.01달러가 부과됩니다. 콘솔에서 보는 것은 무료이지만, API를 자주 호출하면 이것도 비용이 될 수 있습니다.
이지은 씨는 Cost Explorer로 비용 구조를 파악한 후, 불필요한 NAT Gateway를 정리했습니다. "이번 달부터는 비용이 30% 정도 줄어들 것 같아요!" 박준혁 씨가 웃으며 답했습니다.
"그래요. 이제 제대로 관리하고 있는 거예요." Cost Explorer를 정기적으로 확인하는 습관을 들이면, 비용이 갑자기 폭증하는 것을 막을 수 있습니다.
처음에는 그래프를 이해하는 데 시간이 걸리지만, 익숙해지면 몇 초 만에 문제를 발견할 수 있습니다.
실전 팁
💡 - 매주 월요일 아침 Cost Explorer를 확인하는 습관을 들이세요
- 서비스별, 리전별, 태그별로 그룹화해서 다양한 관점으로 분석하세요
- 예측 기능으로 다음 달 비용을 미리 확인하고 예산을 계획하세요
3. 청구서 확인하기
프리랜서 개발자 정수빈 씨는 매달 1일이 두려웠습니다. AWS 청구서가 발행되는 날이기 때문입니다.
어느 달은 50달러, 어느 달은 200달러. 금액이 들쭉날쭉해서 예산을 세우기가 어려웠습니다.
"정확히 무엇 때문에 이런 금액이 나온 건지 알 수 있으면 좋을 텐데..."
AWS 청구서는 매달 사용한 모든 서비스의 상세 내역을 담고 있는 문서입니다. 마치 통신사 요금 고지서처럼 서비스별 사용량과 비용이 항목별로 나열되어 있습니다.
청구서를 제대로 읽을 줄 알면 어디서 비용이 발생했는지 정확히 파악하고, 향후 비용을 예측할 수 있습니다. 비용 관리의 핵심 기술입니다.
다음 코드를 살펴봅시다.
// AWS SDK로 청구서 정보 조회하기
const AWS = require('aws-sdk');
const s3 = new AWS.S3();
// 청구서는 S3 버킷에 CSV 형태로 저장됩니다
const params = {
Bucket: 'my-billing-bucket', // 청구서 저장 버킷
Prefix: '2025-12/' // 2025년 12월 청구서
};
// 청구서 파일 목록 가져오기
s3.listObjectsV2(params, (err, data) => {
if (err) console.log(err);
else {
console.log('청구서 파일 목록:');
data.Contents.forEach(item => {
console.log(`- ${item.Key}`);
// 각 파일을 다운로드하여 상세 분석 가능
});
}
});
정수빈 씨는 AWS 콘솔의 Billing and Cost Management 메뉴로 들어갔습니다. 왼쪽에 Bills 메뉴를 클릭하자, 이번 달 청구서가 나타났습니다.
청구서는 크게 두 부분으로 나뉩니다. 상단에는 총액이 표시되고, 하단에는 서비스별 상세 내역이 나열됩니다.
쉽게 비유하자면, 청구서는 마치 마트 영수증과 같습니다. 맨 위에는 총 금액이 크게 적혀 있고, 아래로 내려가면 각 상품의 이름과 가격이 줄줄이 나열되어 있습니다.
AWS 청구서도 마찬가지입니다. 상단의 Summary 섹션을 먼저 봅니다.
여기에는 이번 달 총 비용과 지난달 대비 증감률이 표시됩니다. 만약 지난달보다 50% 증가했다면, 뭔가 변화가 있었다는 신호입니다.
새로운 서비스를 시작했거나, 사용량이 급증했을 가능성이 큽니다. 다음은 Charges by Service 섹션입니다.
여기서 각 서비스별 비용을 확인할 수 있습니다. Amazon EC2, Amazon S3, Amazon RDS 등 사용한 모든 서비스가 나열됩니다.
각 서비스를 클릭하면 더 상세한 내역이 펼쳐집니다. 정수빈 씨는 EC2 항목을 클릭해봤습니다.
그러자 인스턴스 타입별, 리전별 비용이 나타났습니다. t2.micro에서 10달러, t2.small에서 30달러.
리전은 서울에서 35달러, 도쿄에서 5달러. "아, 도쿄 리전에 테스트용 인스턴스를 하나 띄워놨었지.
그걸 잊고 있었네." 데이터 전송 비용도 주의 깊게 봐야 합니다. 많은 사람들이 놓치는 부분인데, EC2 항목 안에 Data Transfer라는 세부 항목이 있습니다.
인터넷으로 데이터를 내보낸 비용입니다. 이미지나 동영상을 많이 서비스한다면 이 비용이 클 수 있습니다.
S3도 마찬가지입니다. 저장 비용과 요청 비용, 데이터 전송 비용이 각각 따로 표시됩니다.
파일을 많이 업로드하고 다운로드했다면 요청 비용이 높게 나옵니다. 세금도 확인해야 합니다.
청구서 하단에 Tax라는 항목이 있습니다. 한국에서 사용하면 부가가치세 10%가 추가됩니다.
100달러를 썼다면 실제로는 110달러를 내야 합니다. 예산을 세울 때 이 부분을 놓치면 안 됩니다.
위의 코드는 청구서 파일을 프로그래밍 방식으로 가져오는 예제입니다. AWS는 청구서를 CSV 형태로 S3 버킷에 저장할 수 있는 기능을 제공합니다.
이 기능을 활성화하면 매달 자동으로 청구서 파일이 생성됩니다. listObjectsV2 메서드로 파일 목록을 가져오고, 각 파일을 다운로드해서 분석할 수 있습니다.
실무에서는 어떻게 활용할까요? 많은 기업에서 청구서 CSV 파일을 다운로드해서 엑셀이나 데이터베이스에 저장합니다.
그리고 자체 분석 도구나 BI 툴로 시각화합니다. 부서별, 프로젝트별로 비용을 배분하고, 월별 트렌드를 분석합니다.
주의할 점이 있습니다. 청구서는 매달 1일에 확정됩니다.
하지만 실제 청구는 며칠 후에 이뤄집니다. 신용카드나 은행 계좌에서 실제로 인출되는 시점은 3일에서 7일 정도 걸릴 수 있습니다.
잔액이 부족하면 결제 실패가 발생할 수 있으니 미리 확인해야 합니다. 또한 프리티어 사용량도 청구서에 표시됩니다.
비용이 0달러로 표시되어 있어도, 사용량은 기록됩니다. "Free tier"라는 표시가 있다면 프리티어로 처리된 것입니다.
하지만 사용량이 프리티어 한도를 넘으면 즉시 과금이 시작됩니다. 정수빈 씨는 청구서를 꼼꼼히 살펴본 후, 불필요한 리소스들을 정리했습니다.
잊고 있던 도쿄 리전의 인스턴스, 더 이상 사용하지 않는 S3 버킷, 오래된 스냅샷까지. "이번 달부터는 깔끔하게 관리해야겠어요." 청구서를 매달 확인하는 습관을 들이면, 비용의 흐름을 파악할 수 있습니다.
어떤 서비스가 주요 비용인지, 어떤 부분을 최적화할 수 있는지 보입니다. 처음에는 복잡해 보이지만, 몇 번 보다 보면 익숙해집니다.
실전 팁
💡 - 매달 1일에 청구서를 확인하고 지난달과 비교하세요
- 서비스별 상세 내역을 펼쳐서 어디서 비용이 많이 나왔는지 파악하세요
- 청구서 CSV 파일을 저장해두고 장기 트렌드를 분석하세요
4. 예산 알람 설정
스타트업 CTO 강민호 씨는 어느 날 아침 충격적인 이메일을 받았습니다. "AWS 청구 금액이 5,000달러를 초과했습니다." 평소 월 500달러 정도 나오던 비용이 갑자기 10배로 뛴 것입니다.
급히 확인해보니 누군가 실수로 대용량 인스턴스를 여러 개 띄워놓고 주말 내내 방치했던 것입니다. "이런 일이 다시는 없도록 미리 알림을 받을 수 있으면 좋을 텐데..."
AWS Budget은 비용이 특정 금액을 초과하기 전에 미리 알려주는 경보 시스템입니다. 마치 은행 앱의 소비 한도 알림처럼, 설정한 금액에 도달하면 이메일이나 SNS로 알림을 받습니다.
예산을 여러 개 만들어서 서비스별, 프로젝트별로 관리할 수 있습니다. 비용 폭증을 사전에 방지하는 가장 효과적인 방법입니다.
다음 코드를 살펴봅시다.
// AWS SDK로 예산 알람 생성하기
const AWS = require('aws-sdk');
const budgets = new AWS.Budgets({ region: 'us-east-1' });
const params = {
AccountId: '123456789012', // AWS 계정 ID
Budget: {
BudgetName: 'MonthlyBudget',
BudgetLimit: {
Amount: '100', // 예산 한도: 100달러
Unit: 'USD'
},
TimeUnit: 'MONTHLY', // 월별 예산
BudgetType: 'COST' // 비용 기준
},
NotificationsWithSubscribers: [{
Notification: {
NotificationType: 'ACTUAL', // 실제 비용 기준
ComparisonOperator: 'GREATER_THAN',
Threshold: 80 // 80% 도달 시 알림
},
Subscribers: [{
SubscriptionType: 'EMAIL',
Address: 'admin@example.com' // 알림 받을 이메일
}]
}]
};
// 예산 생성
budgets.createBudget(params, (err, data) => {
if (err) console.log('예산 생성 실패:', err);
else console.log('예산 생성 성공!');
});
강민호 씨는 다시는 이런 일이 없도록 AWS Budget을 설정하기로 했습니다. AWS 콘솔에서 Budgets 메뉴로 들어갔습니다.
Create budget 버튼을 클릭하면 여러 템플릿이 나타납니다. Zero spend budget, Monthly cost budget, Daily savings plans coverage budget 등 다양한 옵션이 있습니다.
쉽게 비유하자면, AWS Budget은 마치 휴대폰 데이터 한도 알림과 같습니다. 10GB 요금제를 쓰는데 8GB를 사용하면 "곧 한도에 도달합니다"라고 알려주는 것처럼, AWS도 설정한 예산의 일정 비율에 도달하면 미리 알려줍니다.
가장 기본적인 설정은 Monthly cost budget입니다. 먼저 예산 이름을 정합니다.
"Production Environment Budget" 또는 "Development Budget"처럼 용도에 맞게 짓습니다. 그다음 예산 금액을 입력합니다.
강민호 씨는 월 500달러로 설정했습니다. 다음은 알림 설정입니다.
여기가 가장 중요한 부분입니다. 언제 알림을 받을지 결정합니다.
대부분의 사람들은 여러 단계로 알림을 설정합니다. 예산의 50%, 80%, 100%, 120%에서 각각 알림을 받도록 합니다.
강민호 씨는 이렇게 설정했습니다. 50% 도달 시 첫 번째 알림, 80% 도달 시 두 번째 알림, 100% 초과 시 세 번째 알림.
각 알림마다 받을 사람의 이메일 주소를 입력했습니다. 자신의 이메일뿐만 아니라 팀원들의 이메일도 추가했습니다.
Forecasted budget도 유용합니다. 이것은 현재 사용 패턴을 분석해서 월말에 예상되는 금액을 기준으로 알림을 보냅니다.
예를 들어 월 중순인데 이미 300달러를 썼다면, 월말에는 600달러가 나올 것으로 예측합니다. 예산이 500달러라면 미리 경고를 보내줍니다.
태그 기반 예산도 만들 수 있습니다. 프로젝트별로 리소스에 태그를 붙여놨다면, 태그별로 예산을 설정할 수 있습니다.
"Project: Frontend"라는 태그가 붙은 리소스들의 비용만 추적하는 식입니다. 여러 프로젝트를 동시에 진행하는 팀에게 유용합니다.
위의 코드는 AWS SDK로 프로그래밍 방식으로 예산을 생성하는 예제입니다. createBudget 메서드로 예산을 만들고, NotificationsWithSubscribers 배열로 알림 설정을 추가합니다.
Threshold를 80으로 설정하면 예산의 80%에 도달했을 때 알림을 받습니다. 여러 조직에서 이런 방식으로 계정 생성 시 자동으로 예산을 설정합니다.
실무에서는 어떻게 활용할까요? 대부분의 회사는 프로덕션 환경과 개발 환경에 각각 다른 예산을 설정합니다.
프로덕션은 예산을 넉넉하게 잡고, 개발 환경은 타이트하게 관리합니다. 그리고 예산 알림을 슬랙과 연동해서 팀 전체가 실시간으로 볼 수 있도록 합니다.
주의해야 할 점도 있습니다. 예산 알림은 하루에 한 번만 발송됩니다.
아침에 알림을 받았는데 그날 오후에 비용이 더 증가해도 추가 알림은 오지 않습니다. 실시간 모니터링이 필요하다면 CloudWatch와 함께 사용해야 합니다.
또한 알림을 받았다고 해서 자동으로 리소스가 중지되는 것은 아닙니다. 알림만 받을 뿐, 조치는 직접 해야 합니다.
자동화가 필요하다면 Lambda 함수를 연결해서 예산 초과 시 특정 작업을 수행하도록 설정할 수 있습니다. 강민호 씨는 예산 알람을 설정한 후 안심했습니다.
이제 비용이 급증하면 즉시 알림을 받을 수 있습니다. "다음 주부터는 팀원들에게도 예산 의식을 교육해야겠어요.
그리고 주요 리소스에는 모두 태그를 붙여서 프로젝트별로 추적하도록 하겠습니다." 예산 알람은 설정하는 데 5분밖에 걸리지 않지만, 수천 달러를 절약할 수 있는 강력한 도구입니다. 모든 AWS 계정은 반드시 예산 알람을 설정해야 합니다.
실전 팁
💡 - 예산의 50%, 80%, 100% 단계별로 알림을 설정하세요
- 팀원 전체의 이메일을 추가해서 모두가 비용 상황을 인지하도록 하세요
- Forecasted budget을 함께 설정해서 월말 예상 비용을 미리 파악하세요
5. 프리티어 사용량 확인
대학생 개발자 윤서현 씨는 AWS 프리티어로 개인 프로젝트를 진행하고 있었습니다. "1년간 무료라고 했으니까 안심이야." 그런데 3개월째 되던 어느 날, 30달러짜리 청구서가 날아왔습니다.
"어? 무료 아니었어?
내가 뭘 잘못한 거지?" 당황한 윤서현 씨는 프리티어가 정확히 무엇인지, 어디까지 무료인지 확인할 필요를 느꼈습니다.
AWS 프리티어는 신규 사용자에게 12개월간 제한적으로 무료로 제공되는 서비스입니다. 하지만 모든 것이 무료는 아니며, 각 서비스마다 사용량 한도가 있습니다.
EC2 t2.micro는 월 750시간, S3는 5GB, RDS는 750시간 등 정해진 범위 내에서만 무료입니다. 프리티어 사용량을 정기적으로 확인하면 무료 범위를 초과하기 전에 대응할 수 있습니다.
다음 코드를 살펴봅시다.
// AWS SDK로 프리티어 사용량 확인하기
const AWS = require('aws-sdk');
const freetier = new AWS.FreeTier({ region: 'us-east-1' });
const params = {
// 프리티어 사용량 조회
filter: {
dimensions: {
Service: 'Amazon Elastic Compute Cloud' // EC2 프리티어 확인
}
}
};
// 프리티어 사용량 가져오기
freetier.getFreeTierUsage({}, (err, data) => {
if (err) console.log('조회 실패:', err);
else {
console.log('프리티어 사용 현황:');
data.freeTierUsages.forEach(usage => {
const percent = (usage.actualUsageAmount / usage.limit) * 100;
console.log(`서비스: ${usage.service}`);
console.log(`사용량: ${usage.actualUsageAmount} / ${usage.limit}`);
console.log(`사용률: ${percent.toFixed(2)}%`);
// 80% 이상이면 경고
if (percent >= 80) console.log('⚠️ 프리티어 한도 초과 주의!');
});
}
});
윤서현 씨는 AWS 콘솔에서 Billing and Cost Management로 들어가 Free Tier 메뉴를 찾았습니다. 클릭하자 현재 프리티어 사용 현황이 나타났습니다.
프리티어는 생각보다 복잡합니다. 단순히 "1년간 무료"가 아닙니다.
쉽게 비유하자면, 프리티어는 마치 통신사의 무제한 요금제와 같습니다. "무제한"이라고 하지만 사실은 일정량 이상 사용하면 속도가 제한됩니다.
AWS도 마찬가지로 "무료"라고 하지만 정해진 한도 내에서만 무료입니다. 프리티어는 크게 세 가지 유형이 있습니다.
첫 번째는 12개월 무료입니다. 계정 생성 후 12개월 동안만 무료로 제공됩니다.
EC2 t2.micro, RDS db.t2.micro, ELB 등이 여기에 해당합니다. 13개월째부터는 비용이 발생합니다.
두 번째는 항상 무료입니다. 계정 나이와 상관없이 영구적으로 무료입니다.
Lambda는 월 100만 건 요청, DynamoDB는 25GB 저장공간, SNS는 100만 건 알림까지 무료입니다. 이건 평생 유지됩니다.
세 번째는 단기 무료 체험입니다. 특정 서비스의 신규 사용자에게 3개월 또는 6개월간 제공됩니다.
Lightsail, SageMaker 등이 여기에 속합니다. 윤서현 씨는 자신의 사용량을 확인해봤습니다.
EC2 항목을 보니 "750 Hours of t2.micro usage"라고 적혀 있고, 현재 사용량이 표시됩니다. 750시간은 한 달 내내 인스턴스 1대를 켜두는 것과 같습니다.
문제는 윤서현 씨가 인스턴스를 2대 띄워놨다는 것입니다. 2대를 한 달 동안 켜두면 1,500시간이 됩니다.
750시간은 무료이지만, 나머지 750시간은 유료입니다. 그래서 비용이 청구된 것입니다.
S3도 확인해봤습니다. "5 GB of standard storage"까지 무료입니다.
현재 3GB를 사용 중이므로 아직 여유가 있습니다. 하지만 데이터 전송량도 체크해야 합니다.
GET 요청 2만 건, PUT 요청 2천 건까지 무료입니다. RDS는 더 복잡합니다.
db.t2.micro 인스턴스 750시간 무료인데, 여기에 20GB 스토리지까지 포함됩니다. 윤서현 씨는 25GB를 사용하고 있었습니다.
초과한 5GB에 대해 비용이 발생한 것입니다. 위의 코드는 프리티어 사용량을 프로그래밍 방식으로 조회하는 예제입니다.
getFreeTierUsage 메서드로 각 서비스의 현재 사용량과 한도를 가져옵니다. 사용률을 계산해서 80% 이상이면 경고를 표시합니다.
이런 스크립트를 매일 실행하면 한도 초과를 사전에 방지할 수 있습니다. 실무에서는 어떻게 활용할까요?
많은 스타트업이 초기에는 프리티어로 시작합니다. 프로토타입을 만들고 MVP를 테스트하는 동안은 프리티어만으로도 충분합니다.
하지만 사용자가 늘어나면 빠르게 한도를 초과하게 됩니다. 따라서 프리티어 사용량을 주기적으로 체크하고, 한도에 가까워지면 유료 플랜으로 전환할 준비를 합니다.
주의할 점이 있습니다. 프리티어는 리전별로 적용되지 않습니다.
전체 계정 기준입니다. 서울 리전에서 EC2 1대, 도쿄 리전에서 EC2 1대를 띄우면 총 2대로 계산됩니다.
각 리전에서 750시간씩 무료인 게 아닙니다. 또한 데이터 전송 비용은 프리티어에 포함되지 않는 경우가 많습니다.
EC2 인스턴스는 무료지만, 거기서 나가는 트래픽이 많으면 비용이 발생합니다. 특히 리전 간 데이터 전송은 비쌉니다.
윤서현 씨는 문제를 파악한 후 즉시 조치했습니다. 테스트용 두 번째 인스턴스를 종료하고, RDS 스토리지를 20GB로 줄였습니다.
"앞으로는 매주 프리티어 사용량을 확인해야겠어요. 그래야 갑작스러운 청구서를 받지 않겠죠." 프리티어는 AWS를 배우고 실험하는 데 아주 좋은 도구입니다.
하지만 한도를 제대로 이해하지 못하면 예상치 못한 비용이 발생할 수 있습니다. 정기적으로 사용량을 체크하는 습관을 들이세요.
실전 팁
💡 - 매주 프리티어 사용량을 확인하고 80% 이상이면 조치하세요
- 인스턴스를 여러 대 띄우면 프리티어 한도를 빠르게 초과합니다
- 12개월이 지나면 자동으로 유료로 전환되므로 계정 생성일을 기억하세요
6. 비용 최적화 팁
시리즈 A 투자를 받은 스타트업의 CTO 한지훈 씨는 매달 늘어나는 AWS 비용에 고민이 깊었습니다. "사용자는 3배 늘었는데 비용은 5배나 늘었어.
뭔가 잘못되고 있는 건데..." 투자자들에게 비용 효율성을 증명해야 하는 상황에서, 한지훈 씨는 AWS 비용을 최적화하는 방법을 찾기 시작했습니다.
비용 최적화는 서비스 품질을 유지하면서 AWS 비용을 줄이는 기술입니다. 불필요한 리소스를 제거하고, 적절한 인스턴스 타입을 선택하고, 예약 인스턴스를 활용하는 등 다양한 전략이 있습니다.
작은 최적화들이 모이면 월 비용을 30-50% 이상 절감할 수 있습니다. 효율적인 클라우드 운영의 핵심입니다.
다음 코드를 살펴봅시다.
// 사용하지 않는 EBS 볼륨 찾기 - 비용 최적화의 첫걸음
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });
// 모든 EBS 볼륨 조회
ec2.describeVolumes({}, (err, data) => {
if (err) console.log(err);
else {
console.log('사용하지 않는 볼륨 찾기:');
data.Volumes.forEach(volume => {
// 인스턴스에 연결되지 않은 볼륨 = 불필요한 비용
if (volume.State === 'available') {
const sizeGB = volume.Size;
const monthlyCost = sizeGB * 0.1; // GB당 약 0.1달러
console.log(`볼륨 ID: ${volume.VolumeId}`);
console.log(`크기: ${sizeGB}GB`);
console.log(`월 예상 비용: $${monthlyCost.toFixed(2)}`);
console.log('→ 삭제 대상입니다!');
}
});
}
});
한지훈 씨는 먼저 현재 상황을 파악했습니다. Cost Explorer를 열어서 어떤 서비스에서 비용이 많이 나가는지 확인했습니다.
비용 최적화는 마치 집안 정리와 같습니다. 사용하지 않는 물건을 버리고, 비싼 물건은 저렴한 대안으로 바꾸고, 자주 쓰는 물건은 대량 구매로 할인받는 것처럼, AWS도 비슷한 원리로 최적화할 수 있습니다.
첫 번째 단계는 좀비 리소스 제거입니다. 좀비 리소스란 사용하지 않지만 비용은 계속 발생하는 리소스입니다.
중지된 EC2 인스턴스의 EBS 볼륨, 삭제된 인스턴스의 스냅샷, 더 이상 사용하지 않는 Elastic IP 주소 등이 여기에 해당합니다. 한지훈 씨는 EBS 볼륨을 점검했습니다.
인스턴스를 삭제했는데 볼륨은 그대로 남아 있는 경우가 많았습니다. 100GB짜리 볼륨 하나가 월 10달러입니다.
10개만 정리해도 월 100달러를 절감할 수 있습니다. 스냅샷도 확인했습니다.
1년 전에 만든 스냅샷들이 여전히 남아 있었습니다. 스냅샷도 저장 비용이 발생합니다.
필요 없는 것들을 삭제하니 월 50달러가 줄었습니다. 두 번째는 인스턴스 크기 조정입니다.
많은 개발자들이 처음에는 넉넉하게 큰 인스턴스를 선택합니다. "혹시 모르니까 여유 있게." 하지만 실제로는 CPU 사용률이 10%밖에 안 되는 경우가 많습니다.
CloudWatch로 지난 한 달간 CPU와 메모리 사용률을 분석했습니다. t2.medium을 쓰는데 평균 CPU 사용률이 15%였습니다.
t2.small로 다운그레이드해도 충분합니다. 이것만으로 월 30달러를 절감할 수 있습니다.
세 번째는 예약 인스턴스와 Savings Plans 활용입니다. 1년 이상 계속 사용할 인스턴스라면 예약 인스턴스를 구매하는 것이 유리합니다.
온디맨드 대비 최대 72% 할인됩니다. t2.medium 온디맨드가 월 40달러라면, 1년 예약으로 구매하면 월 25달러로 줄어듭니다.
Savings Plans는 더 유연합니다. 특정 인스턴스가 아니라 시간당 사용 금액을 약정합니다.
"시간당 10달러 이상 사용하겠다"고 약속하면 할인을 받습니다. 인스턴스 타입을 바꿔도 할인이 유지됩니다.
네 번째는 오토스케일링과 스케줄링입니다. 개발 환경은 업무 시간에만 필요합니다.
평일 오전 9시에 켜고 오후 6시에 끄면 하루 9시간만 비용이 발생합니다. 24시간 대비 62% 절감입니다.
주말에는 완전히 끕니다. 프로덕션 환경은 오토스케일링을 설정합니다.
트래픽이 많을 때는 인스턴스를 추가하고, 새벽처럼 한적할 때는 최소한으로 줄입니다. 평균적으로 30% 정도 비용을 절감할 수 있습니다.
다섯 번째는 스토리지 클래스 최적화입니다. S3에 저장된 파일 중 자주 접근하지 않는 것들은 S3 Glacier로 이동합니다.
Standard 스토리지는 GB당 0.023달러인데, Glacier는 GB당 0.004달러입니다. 80% 이상 저렴합니다.
로그 파일이나 백업 파일은 Lifecycle Policy로 자동으로 Glacier로 이동하도록 설정합니다. 30일이 지나면 자동으로 저렴한 클래스로 옮겨집니다.
위의 코드는 사용하지 않는 EBS 볼륨을 찾는 예제입니다. describeVolumes로 모든 볼륨을 가져오고, State가 available인 것들을 찾습니다.
이것들은 인스턴스에 연결되지 않은 볼륨이므로 불필요한 비용입니다. 크기를 확인하고 월 예상 비용을 계산해서 삭제 우선순위를 정할 수 있습니다.
실무에서는 어떻게 활용할까요? 대부분의 기업은 분기마다 비용 최적화 스프린트를 진행합니다.
일주일 정도 시간을 내서 전체 AWS 환경을 점검합니다. 불필요한 리소스를 정리하고, 인스턴스 크기를 조정하고, 예약 구매를 검토합니다.
이것만으로도 연간 수천만 원을 절감하는 사례가 많습니다. 주의할 점도 있습니다.
무조건 비용만 줄이려다가 서비스 품질이 떨어지면 안 됩니다. 인스턴스를 너무 작게 설정하면 응답 속도가 느려지고, 백업을 너무 적게 하면 장애 시 복구가 어렵습니다.
비용과 성능의 균형을 찾는 것이 중요합니다. 또한 최적화는 지속적인 과정입니다.
한 번 정리했다고 끝이 아닙니다. 새로운 리소스가 계속 추가되고, 사용 패턴도 변합니다.
매월 정기적으로 점검해야 합니다. 한지훈 씨는 체계적으로 비용 최적화를 진행한 결과, 월 비용을 40% 절감했습니다.
"이제 투자자들에게 당당하게 보고할 수 있어요. 사용자는 늘었지만 비용 효율도 함께 개선되고 있다고요." 비용 최적화는 단순히 돈을 아끼는 것이 아니라, 리소스를 효율적으로 사용하는 엔지니어링 역량입니다.
작은 것부터 하나씩 실천해보세요.
실전 팁
💡 - 매월 사용하지 않는 리소스를 찾아 정리하세요
- CloudWatch로 실제 사용률을 분석하고 인스턴스 크기를 조정하세요
- 장기 사용 리소스는 예약 인스턴스나 Savings Plans로 구매하세요
- 개발 환경은 스케줄링으로 업무 시간에만 가동하세요
- S3 Lifecycle Policy로 오래된 데이터는 저렴한 스토리지로 이동하세요
이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!
댓글 (0)
함께 보면 좋은 카드 뉴스
서비스 메시 완벽 가이드
마이크로서비스 간 통신을 안전하고 효율적으로 관리하는 서비스 메시의 핵심 개념부터 실전 도입까지, 초급 개발자를 위한 완벽한 입문서입니다. Istio와 Linkerd 비교, 사이드카 패턴, 실무 적용 노하우를 담았습니다.
EFK 스택 로깅 완벽 가이드
마이크로서비스 환경에서 로그를 효과적으로 수집하고 분석하는 EFK 스택(Elasticsearch, Fluentd, Kibana)의 핵심 개념과 실전 활용법을 초급 개발자도 쉽게 이해할 수 있도록 정리한 가이드입니다.
Grafana 대시보드 완벽 가이드
실시간 모니터링의 핵심, Grafana 대시보드를 처음부터 끝까지 배워봅니다. Prometheus 연동부터 알람 설정까지, 초급 개발자도 쉽게 따라할 수 있는 실전 가이드입니다.
Prometheus 메트릭 수집 완벽 가이드
Spring Boot 애플리케이션의 메트릭을 Prometheus로 수집하고 모니터링하는 방법을 배웁니다. Actuator 설정부터 PromQL 쿼리까지 실무에 필요한 모든 내용을 다룹니다.
분산 추적 완벽 가이드
마이크로서비스 환경에서 요청의 전체 흐름을 추적하는 분산 추적 시스템의 핵심 개념을 배웁니다. Trace, Span, Trace ID 전파, 샘플링 전략까지 실무에 필요한 모든 것을 다룹니다.