AWS 비용 최적화 및 FinOps 전략 완벽 가이드

AWS 클라우드 비용을 효과적으로 관리하고 최적화하는 방법을 알아봅니다. Reserved Instance, Spot Instance, Savings Plans 등 다양한 비용 절감 전략과 FinOps 사고방식을 초급 개발자도 쉽게 이해할 수 있도록 설명합니다.

1. AWS 비용 구조 이해하기

김개발 씨는 스타트업에 입사한 지 6개월 된 주니어 개발자입니다. 어느 날 팀장님이 다급하게 달려왔습니다.

"이번 달 AWS 청구서가 예상보다 3배나 나왔어요. 뭐가 문제인지 파악해 볼 수 있어요?" 김개발 씨는 당혹스러웠습니다.

서버가 잘 돌아가는 것만 확인했지, 비용이 어떻게 청구되는지는 한 번도 생각해 본 적이 없었기 때문입니다.

AWS 비용 구조는 크게 컴퓨팅, 스토리지, 네트워크 세 가지 축으로 이루어져 있습니다. 마치 집에서 전기세, 수도세, 가스비를 따로 내는 것처럼, AWS도 사용한 리소스별로 각각 비용이 청구됩니다.

이 구조를 이해하면 어디서 비용이 새고 있는지 파악할 수 있고, 효과적인 절감 전략을 세울 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# AWS Cost Explorer 클라이언트 생성
ce_client = boto3.client('ce', region_name='us-east-1')

# 지난 달 비용을 서비스별로 조회
response = ce_client.get_cost_and_usage(
    TimePeriod={
        'Start': '2024-01-01',
        'End': '2024-01-31'
    },
    Granularity='MONTHLY',
    Metrics=['UnblendedCost'],
    # 서비스별로 그룹화하여 비용 분석
    GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
)

# 결과 출력: 어떤 서비스가 얼마나 비용을 차지하는지 확인
for group in response['ResultsByTime'][0]['Groups']:
    service = group['Keys'][0]
    cost = group['Metrics']['UnblendedCost']['Amount']
    print(f"{service}: ${float(cost):.2f}")

김개발 씨는 AWS 콘솔에 로그인해서 청구서를 열어보았습니다. 숫자들이 빼곡히 적혀 있었지만, 도대체 뭐가 뭔지 알 수가 없었습니다.

EC2, S3, RDS, CloudFront... 각각이 얼마씩 나온 건지, 왜 이렇게 많이 나온 건지 감이 잡히지 않았습니다.

그때 옆자리 박시니어 씨가 다가왔습니다. "AWS 비용 구조부터 이해해야 해요.

일단 큰 그림부터 봅시다." AWS 비용 구조는 마치 아파트 관리비와 비슷합니다. 아파트 관리비를 보면 전기료, 수도료, 난방비, 청소비 등 항목별로 나뉘어 있습니다.

AWS도 마찬가지입니다. 크게 세 가지 축으로 비용이 발생합니다.

첫 번째는 컴퓨팅 비용입니다. EC2 인스턴스를 띄워두면 시간당 비용이 청구됩니다.

마치 전기를 켜두면 전기세가 나가는 것과 같습니다. 인스턴스 타입에 따라 시간당 요금이 다르고, 24시간 365일 켜두면 그만큼 비용이 누적됩니다.

두 번째는 스토리지 비용입니다. S3에 파일을 저장하거나 EBS 볼륨을 사용하면 GB당 월 비용이 발생합니다.

창고 임대료라고 생각하면 됩니다. 물건을 많이 쌓아둘수록 창고비가 올라가는 것처럼, 데이터를 많이 저장할수록 비용이 증가합니다.

세 번째는 네트워크 비용입니다. 이 부분이 초보자들이 가장 간과하는 영역입니다.

AWS 밖으로 데이터를 전송할 때마다 비용이 발생합니다. 택배비라고 생각하면 됩니다.

고객에게 이미지나 동영상을 전송할 때마다 조금씩 비용이 쌓입니다. 위의 코드를 살펴보겠습니다.

Cost Explorer API를 사용해서 지난 달 비용을 서비스별로 조회하고 있습니다. TimePeriod로 기간을 지정하고, GroupBy로 SERVICE 기준으로 그룹화합니다.

이렇게 하면 EC2가 얼마, S3가 얼마, RDS가 얼마인지 한눈에 파악할 수 있습니다. 실제로 코드를 실행해보면 깜짝 놀랄 수 있습니다.

생각지도 못한 서비스에서 비용이 새고 있는 경우가 많기 때문입니다. 개발하다가 테스트용으로 띄워둔 인스턴스, 삭제하지 않은 스냅샷, 연결되지 않은 Elastic IP 같은 것들이 좀비처럼 비용을 먹어치우고 있을 수 있습니다.

한 가지 주의할 점이 있습니다. AWS 비용은 리전별로 다릅니다.

서울 리전이 버지니아 리전보다 약 10-20% 비쌉니다. 그렇다고 무조건 싼 리전을 선택하면 네트워크 지연 때문에 사용자 경험이 나빠질 수 있습니다.

비용과 성능 사이에서 균형을 찾아야 합니다. 김개발 씨는 Cost Explorer를 통해 문제를 발견했습니다.

개발 환경 EC2 인스턴스들이 밤새 켜져 있었던 것입니다. 퇴근 후에는 끄고, 출근하면 켜는 자동화 스크립트만 추가해도 비용을 상당히 절감할 수 있었습니다.

비용 구조를 이해하는 것은 FinOps의 첫걸음입니다. 문제를 알아야 해결할 수 있으니까요.

이제 구체적인 절감 전략으로 넘어가 봅시다.

실전 팁

💡 - Cost Explorer에서 일별 비용 추이를 확인하면 갑자기 비용이 튄 날을 쉽게 찾을 수 있습니다

AWS 프리 티어 한도를 넘으면 바로 과금이 시작되니 CloudWatch 알람을 설정해두세요
태그(Tag)를 잘 붙여두면 프로젝트별, 팀별 비용 분석이 가능합니다

2. Reserved Instance 구매 전략

김개발 씨의 스타트업이 성장하면서 서버도 늘어났습니다. 매달 AWS 청구서를 보며 한숨을 쉬던 박시니어 씨가 어느 날 제안했습니다.

"우리 이제 Reserved Instance 좀 검토해볼까요? 1년 넘게 계속 쓰는 서버들이 있잖아요." 김개발 씨는 고개를 갸웃했습니다.

예약 인스턴스라니, 호텔 예약처럼 미리 서버를 예약해두는 건가요?

**Reserved Instance(RI)**는 1년 또는 3년 동안 특정 인스턴스 타입을 사용하겠다고 약정하는 대신 최대 72%까지 할인받는 방식입니다. 마치 헬스장 연간 회원권과 같습니다.

매달 끊으면 비싸지만, 1년치를 한 번에 결제하면 훨씬 저렴해지는 원리입니다. 24시간 365일 돌아가야 하는 프로덕션 서버에 적용하면 큰 비용 절감 효과를 볼 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# EC2 클라이언트 생성
ec2_client = boto3.client('ec2', region_name='ap-northeast-2')

# 현재 사용 중인 Reserved Instance 목록 조회
ri_response = ec2_client.describe_reserved_instances(
    Filters=[
        {'Name': 'state', 'Values': ['active']}
    ]
)

# RI 활용 현황 분석
for ri in ri_response['ReservedInstances']:
    instance_type = ri['InstanceType']
    instance_count = ri['InstanceCount']
    end_date = ri['End']

    # 만료일이 가까운 RI 알림
    print(f"인스턴스 타입: {instance_type}")
    print(f"수량: {instance_count}개")
    print(f"만료일: {end_date}")
    print(f"---")

# On-Demand 대비 절감액 계산 예시
on_demand_hourly = 0.1  # 시간당 $0.1
ri_hourly = 0.06        # RI 적용 시 시간당 $0.06
monthly_hours = 730     # 한 달 약 730시간
monthly_savings = (on_demand_hourly - ri_hourly) * monthly_hours
print(f"월간 절감액: ${monthly_savings:.2f}")

Reserved Instance를 이해하려면 먼저 On-Demand 방식을 알아야 합니다. On-Demand는 말 그대로 필요할 때 서버를 켜고, 사용한 만큼만 지불하는 방식입니다.

편리하지만 비쌉니다. 마치 택시를 타는 것과 같습니다.

반면 Reserved Instance는 장기 계약입니다. 1년 또는 3년 동안 특정 사양의 서버를 사용하겠다고 약속하면, AWS가 큰 폭의 할인을 해줍니다.

마치 리스 차량이나 헬스장 연간 회원권과 같은 개념입니다. 박시니어 씨가 화이트보드에 숫자를 적기 시작했습니다.

"자, 우리 메인 API 서버는 t3.large를 쓰고 있어요. On-Demand로 1년 쓰면 대략 $730 정도 나와요.

그런데 1년 RI를 사면 $456밖에 안 들어요. 거의 40% 절감이죠." 김개발 씨가 질문했습니다.

"그럼 무조건 RI를 사는 게 좋은 거 아닌가요?" 박시니어 씨가 고개를 저었습니다. "그게 그렇게 단순하지 않아요.

RI에는 세 가지 결제 옵션이 있거든요." 첫 번째는 **전액 선결제(All Upfront)**입니다. 1년치 또는 3년치 비용을 한 번에 내는 방식입니다.

할인율이 가장 높지만, 목돈이 필요합니다. 3년 전액 선결제 시 최대 72%까지 할인받을 수 있습니다.

두 번째는 **부분 선결제(Partial Upfront)**입니다. 일부는 선결제하고, 나머지는 월별로 나눠 내는 방식입니다.

할인율은 중간 수준이지만, 현금 흐름 관리가 수월합니다. 세 번째는 **선결제 없음(No Upfront)**입니다.

선결제 없이 월별로 나눠 내는 방식입니다. 할인율은 가장 낮지만, 초기 부담이 없습니다.

그렇다면 어떤 서버에 RI를 적용해야 할까요? 핵심은 사용률입니다.

24시간 365일 돌아가야 하는 프로덕션 데이터베이스나 API 서버는 RI의 좋은 후보입니다. 반면, 개발 서버처럼 업무 시간에만 켜는 서버는 RI를 사면 오히려 손해입니다.

AWS에서는 RI 구매 권장 사항을 제공합니다. Cost Explorer에서 RI 권장 사항 메뉴를 보면, 지난 사용 패턴을 분석해서 어떤 인스턴스에 RI를 적용하면 좋을지 추천해줍니다.

이 기능을 활용하면 분석 시간을 크게 줄일 수 있습니다. 한 가지 더 알아둘 것이 있습니다.

RI에는 **표준(Standard)**과 컨버터블(Convertible) 두 종류가 있습니다. 표준 RI는 할인율이 높지만 인스턴스 타입을 변경할 수 없습니다.

컨버터블 RI는 할인율은 조금 낮지만, 필요하면 다른 인스턴스 타입으로 교환할 수 있습니다. 스타트업처럼 빠르게 변화하는 환경에서는 컨버터블 RI가 더 안전한 선택일 수 있습니다.

1년 후에 어떤 사양이 필요할지 정확히 예측하기 어렵기 때문입니다. 김개발 씨의 회사는 결국 프로덕션 데이터베이스 서버에 3년 부분 선결제 RI를 적용하기로 했습니다.

연간 수백만 원을 절감할 수 있게 되었습니다.

실전 팁

💡 - RI 구매 전 최소 1-2개월간 사용 패턴을 분석하세요

컨버터블 RI는 인스턴스 패밀리까지 변경 가능하니 불확실성이 높을 때 고려하세요
RI Marketplace에서 남은 RI를 사고팔 수 있습니다

3. Spot Instance로 최대 90% 절감

어느 날 박시니어 씨가 흥분한 표정으로 달려왔습니다. "김개발 씨, 우리 배치 작업 서버 비용을 90% 줄일 수 있는 방법을 찾았어요!" 김개발 씨는 믿기지 않았습니다.

90%라니, 그게 가능한 건가요? 박시니어 씨가 화면에 띄운 것은 Spot Instance라는 생소한 개념이었습니다.

Spot Instance는 AWS의 여유 컴퓨팅 자원을 경매 방식으로 저렴하게 사용하는 방식입니다. 마치 비행기 빈 좌석을 막판에 싸게 파는 땡처리 항공권과 같습니다.

On-Demand 대비 최대 90%까지 저렴하지만, AWS가 자원을 회수해야 할 때 2분 전 통보 후 인스턴스가 종료될 수 있습니다. 따라서 중단되어도 괜찮은 작업에만 사용해야 합니다.

다음 코드를 살펴봅시다.

import boto3

ec2_client = boto3.client('ec2', region_name='ap-northeast-2')

# Spot Instance 가격 히스토리 조회
spot_prices = ec2_client.describe_spot_price_history(
    InstanceTypes=['m5.large'],
    ProductDescriptions=['Linux/UNIX'],
    MaxResults=10
)

# 현재 Spot 가격 확인
for price in spot_prices['SpotPriceHistory']:
    az = price['AvailabilityZone']
    spot_price = price['SpotPrice']
    timestamp = price['Timestamp']
    print(f"AZ: {az}, 가격: ${spot_price}/시간, 시간: {timestamp}")

# Spot Instance 요청 생성 예시
spot_request = ec2_client.request_spot_instances(
    SpotPrice='0.05',  # 최대 지불 의사 가격
    InstanceCount=1,
    Type='one-time',
    LaunchSpecification={
        'ImageId': 'ami-0c55b159cbfafe1f0',
        'InstanceType': 'm5.large',
        'KeyName': 'my-key-pair'
    }
)

print(f"Spot 요청 ID: {spot_request['SpotInstanceRequests'][0]['SpotInstanceRequestId']}")

Spot Instance를 이해하려면 AWS 데이터센터의 상황을 상상해보면 됩니다. AWS는 전 세계에 거대한 데이터센터를 운영합니다.

수많은 서버가 있지만, 항상 100% 가동되는 것은 아닙니다. 특정 시간대나 계절에 따라 사용량이 달라지기 때문에 항상 여유 자원이 존재합니다.

AWS는 이 여유 자원을 놀리는 대신, 아주 저렴한 가격에 내놓기로 했습니다. 이것이 바로 Spot Instance입니다.

마치 호텔이 빈 방을 막판에 할인해서 파는 것과 같습니다. 어차피 비어있을 방이라면, 조금이라도 받는 게 낫기 때문입니다.

박시니어 씨가 가격표를 보여줬습니다. "m5.large On-Demand가 시간당 $0.096인데, Spot은 지금 $0.029밖에 안 해요.

70% 할인이에요." 김개발 씨가 물었습니다. "이렇게 싼데 왜 다들 안 쓰는 거예요?" 박시니어 씨가 웃으며 대답했습니다.

"리스크가 있거든요. Spot 인스턴스는 언제든 종료될 수 있어요." 이것이 Spot Instance의 가장 중요한 특징입니다.

AWS가 여유 자원을 On-Demand 고객에게 할당해야 할 때, Spot 인스턴스는 2분 전 통보 후 강제 종료됩니다. 따라서 Spot Instance는 중단되어도 괜찮은 작업에만 사용해야 합니다.

어떤 작업이 적합할까요? 배치 작업이 대표적입니다.

데이터 분석, 이미지 처리, 로그 분석 같은 작업은 중간에 중단되더라도 나중에 이어서 하면 됩니다. CI/CD 파이프라인도 좋은 후보입니다.

빌드가 중단되면 그냥 다시 시작하면 됩니다. 개발 및 테스트 환경도 마찬가지입니다.

반면 적합하지 않은 작업도 있습니다. 실시간 API 서버, 데이터베이스, 중요한 트랜잭션 처리 시스템은 Spot Instance에 올리면 안 됩니다.

갑자기 종료되면 서비스 장애로 이어질 수 있기 때문입니다. Spot Instance를 더 안정적으로 사용하는 방법도 있습니다.

Spot Fleet을 사용하면 여러 인스턴스 타입과 가용 영역에 걸쳐 Spot 인스턴스를 분산 배치할 수 있습니다. 하나가 종료되어도 다른 것이 이어받아 작업을 계속할 수 있습니다.

또한 Spot 중단 알림을 활용할 수 있습니다. 인스턴스 메타데이터 서비스를 통해 2분 전에 종료 알림을 받을 수 있습니다.

이 시간 동안 현재 상태를 저장하고 우아하게 종료할 수 있습니다. 김개발 씨의 회사는 매일 밤 실행되는 데이터 분석 배치 작업을 Spot Instance로 전환했습니다.

같은 작업을 10분의 1 비용으로 처리할 수 있게 되었습니다.

실전 팁

💡 - 여러 인스턴스 타입을 후보로 지정하면 Spot 가용성이 높아집니다

Spot 가격은 수요에 따라 변동하니, 가격 히스토리를 확인해서 안정적인 타입을 선택하세요
Spot과 On-Demand를 혼합하는 전략도 고려해보세요

4. Savings Plans 활용

Reserved Instance를 도입한 지 6개월이 지났습니다. 그런데 새로운 고민이 생겼습니다.

회사가 컨테이너와 서버리스를 도입하면서 EC2만 쓰던 시절이 끝났기 때문입니다. ECS, Fargate, Lambda 비용도 줄이고 싶은데, RI로는 불가능했습니다.

박시니어 씨가 새로운 카드를 꺼내들었습니다. "Savings Plans 들어보셨어요?"

Savings Plans는 특정 인스턴스가 아닌 시간당 사용량($/시간)을 약정하는 새로운 할인 모델입니다. 마치 통신사 요금제처럼 월 일정 금액을 약정하면 그만큼의 사용량에 할인이 적용됩니다.

RI보다 유연하며, EC2뿐 아니라 Fargate와 Lambda까지 할인받을 수 있다는 장점이 있습니다.

다음 코드를 살펴봅시다.

import boto3

# Savings Plans 클라이언트 생성
sp_client = boto3.client('savingsplans', region_name='us-east-1')

# 현재 활성화된 Savings Plans 조회
active_plans = sp_client.describe_savings_plans(
    states=['active']
)

for plan in active_plans['savingsPlans']:
    commitment = plan['commitment']
    savings_plan_type = plan['savingsPlanType']
    term = plan['termDurationInSeconds'] / (365 * 24 * 3600)

    print(f"타입: {savings_plan_type}")
    print(f"약정 금액: ${commitment}/시간")
    print(f"기간: {term:.0f}년")
    print(f"---")

# Cost Explorer에서 Savings Plans 권장사항 조회
ce_client = boto3.client('ce', region_name='us-east-1')

recommendations = ce_client.get_savings_plans_purchase_recommendation(
    SavingsPlansType='COMPUTE_SP',
    TermInYears='ONE_YEAR',
    PaymentOption='NO_UPFRONT',
    LookbackPeriodInDays='THIRTY_DAYS'
)

# 권장사항 출력
if recommendations.get('SavingsPlansPurchaseRecommendation'):
    rec = recommendations['SavingsPlansPurchaseRecommendation']
    print(f"권장 약정액: ${rec.get('SavingsPlansPurchaseRecommendationDetails', [{}])[0].get('HourlyCommitment', 'N/A')}/시간")

Savings Plans가 등장하기 전, AWS 할인을 받으려면 Reserved Instance를 사야 했습니다. 하지만 RI에는 한계가 있었습니다.

특정 인스턴스 타입에 묶여 있어서, 기술 스택이 바뀌면 할인 혜택을 못 받는 경우가 생겼습니다. 박시니어 씨가 예를 들어 설명했습니다.

"우리가 m5.large에 RI를 샀다고 해봐요. 그런데 나중에 컨테이너로 전환해서 Fargate를 쓰게 되면요?

RI는 Fargate에 적용이 안 돼요. 결국 RI 할인은 못 받고, Fargate는 On-Demand로 내야 해요." Savings Plans는 이 문제를 해결합니다.

특정 인스턴스가 아니라 시간당 사용 금액을 약정하기 때문입니다. 예를 들어 "$10/시간"을 약정했다고 합시다.

이 $10 내에서 EC2를 쓰든, Fargate를 쓰든, Lambda를 쓰든 상관없이 할인이 적용됩니다. 마치 통신사 데이터 무제한 요금제처럼, 약정 범위 내에서는 자유롭게 사용할 수 있습니다.

Savings Plans에는 두 가지 종류가 있습니다. 첫 번째는 Compute Savings Plans입니다.

가장 유연한 옵션입니다. EC2, Fargate, Lambda 어디에든 적용됩니다.

리전도 자유롭게 바꿀 수 있고, 인스턴스 패밀리도 제한이 없습니다. 할인율은 RI보다 조금 낮지만, 유연성이 뛰어납니다.

두 번째는 EC2 Instance Savings Plans입니다. 특정 리전과 인스턴스 패밀리(예: 서울 리전의 m5 시리즈)를 지정합니다.

유연성은 낮지만, 할인율이 더 높습니다. 컴퓨팅 환경이 안정적이라면 이 옵션이 더 유리합니다.

김개발 씨가 질문했습니다. "그럼 RI랑 Savings Plans 중에 뭘 선택해야 해요?" 박시니어 씨가 정리해줬습니다.

"EC2만 쓰고 인스턴스 타입이 고정되어 있다면 RI가 조금 더 저렴해요. 하지만 Fargate나 Lambda도 쓰거나, 인스턴스 타입을 바꿀 가능성이 있다면 Savings Plans가 낫습니다.

요즘 추세는 Savings Plans 쪽이에요." Cost Explorer에서 Savings Plans 권장사항을 확인할 수 있습니다. 지난 30일간 사용 패턴을 분석해서 얼마를 약정하면 좋을지 추천해줍니다.

처음에는 이 권장사항을 참고하는 것이 좋습니다. 한 가지 팁을 드리자면, 약정액은 보수적으로 시작하세요.

항상 사용하는 최소 금액으로 약정하고, 초과분은 On-Demand로 처리하는 게 안전합니다. 나중에 사용량이 늘면 추가로 Savings Plans를 구매하면 됩니다.

김개발 씨의 회사는 Compute Savings Plans를 도입해서 EC2와 Lambda 비용을 동시에 절감할 수 있게 되었습니다.

실전 팁

💡 - Compute Savings Plans는 가장 유연하므로 첫 도입 시 추천됩니다

약정액은 최소 사용량 기준으로 보수적으로 설정하세요
기존 RI와 Savings Plans는 동시에 적용될 수 있으며, RI가 먼저 적용됩니다

5. S3 스토리지 클래스 최적화

어느 날 청구서를 보던 김개발 씨가 이상한 점을 발견했습니다. "S3 비용이 왜 이렇게 많이 나오지?

우리 그렇게 많은 파일을 저장하나요?" 분석해보니 3년 전 프로젝트 백업 파일, 오래된 로그, 한 번도 조회되지 않은 데이터들이 S3에 쌓여 있었습니다. 모두 가장 비싼 Standard 클래스에 저장되어 있었습니다.

S3는 데이터 접근 빈도에 따라 여러 스토리지 클래스를 제공합니다. 마치 물건 보관 서비스에도 즉시 찾을 수 있는 보관함과 창고 깊숙이 보관하는 옵션이 있는 것처럼, S3도 자주 쓰는 데이터와 가끔 쓰는 데이터를 다르게 저장할 수 있습니다.

적절한 스토리지 클래스를 선택하면 최대 95%까지 비용을 절감할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

s3_client = boto3.client('s3', region_name='ap-northeast-2')

# 버킷의 스토리지 클래스별 용량 분석
bucket_name = 'my-data-bucket'

# S3 Inventory나 CloudWatch 지표로 분석하는 대신
# 수명 주기 정책 설정 예시
lifecycle_policy = {
    'Rules': [
        {
            'ID': 'MoveToIA',
            'Status': 'Enabled',
            'Filter': {'Prefix': 'logs/'},
            # 30일 후 Infrequent Access로 전환
            'Transitions': [
                {
                    'Days': 30,
                    'StorageClass': 'STANDARD_IA'
                },
                # 90일 후 Glacier로 전환
                {
                    'Days': 90,
                    'StorageClass': 'GLACIER'
                }
            ],
            # 365일 후 삭제
            'Expiration': {'Days': 365}
        },
        {
            'ID': 'IntelligentTiering',
            'Status': 'Enabled',
            'Filter': {'Prefix': 'user-uploads/'},
            # 업로드 시 Intelligent-Tiering 적용
            'Transitions': [
                {
                    'Days': 0,
                    'StorageClass': 'INTELLIGENT_TIERING'
                }
            ]
        }
    ]
}

# 수명 주기 정책 적용
s3_client.put_bucket_lifecycle_configuration(
    Bucket=bucket_name,
    LifecycleConfiguration=lifecycle_policy
)

print(f"버킷 {bucket_name}에 수명 주기 정책이 적용되었습니다.")

S3 스토리지 클래스를 이해하려면 물건 보관 서비스를 생각해보면 됩니다. 자주 쓰는 물건은 집 앞 락커에 보관하면 편합니다.

빠르게 꺼낼 수 있으니까요. 하지만 비쌉니다.

반면 1년에 한 번 볼까 말까 한 물건은 외곽의 큰 창고에 보관해도 됩니다. 훨씬 저렴하지만 꺼내려면 며칠이 걸립니다.

S3도 마찬가지입니다. 데이터 접근 빈도에 따라 다양한 스토리지 클래스를 제공합니다.

S3 Standard는 가장 기본적인 클래스입니다. 즉시 접근 가능하고, 가용성과 내구성이 최고입니다.

하지만 가격도 가장 비쌉니다. 자주 읽고 쓰는 활성 데이터에 적합합니다.

**S3 Standard-IA(Infrequent Access)**는 한 달에 한 번 정도 접근하는 데이터에 적합합니다. 저장 비용은 Standard의 약 절반이지만, 데이터를 읽을 때마다 조회 비용이 발생합니다.

백업이나 재해 복구용 데이터에 좋습니다. S3 Glacier는 거의 접근하지 않는 아카이브 데이터용입니다.

저장 비용이 Standard의 약 1/5 수준으로 매우 저렴합니다. 하지만 데이터를 꺼내려면 몇 분에서 몇 시간이 걸립니다.

법적으로 보관해야 하는 오래된 기록이나 로그에 적합합니다. S3 Glacier Deep Archive는 가장 저렴한 클래스입니다.

Standard의 약 1/20 가격입니다. 하지만 데이터 복원에 12시간 이상 걸릴 수 있습니다.

7년, 10년 보관이 필요한 규제 준수용 데이터에 사용합니다. 박시니어 씨가 핵심을 짚었습니다.

"문제는 사람들이 데이터를 올릴 때는 Standard를 쓰고, 그 후로 신경을 안 써요. 3년 전 로그가 아직도 Standard에 있는 거죠.

이걸 자동화해야 해요." 바로 **수명 주기 정책(Lifecycle Policy)**입니다. 위의 코드처럼 규칙을 설정하면, 데이터가 자동으로 저렴한 클래스로 이동합니다.

30일이 지나면 Standard-IA로, 90일이 지나면 Glacier로, 365일이 지나면 삭제되도록 설정할 수 있습니다. 접근 패턴을 예측하기 어려운 경우에는 S3 Intelligent-Tiering을 고려해보세요.

AWS가 자동으로 접근 패턴을 분석해서 적절한 티어로 데이터를 옮겨줍니다. 약간의 모니터링 비용이 들지만, 직접 관리하는 것보다 편리합니다.

김개발 씨는 S3 Storage Lens를 사용해서 버킷별 스토리지 현황을 분석했습니다. 3년간 한 번도 접근하지 않은 데이터가 전체의 60%를 차지하고 있었습니다.

수명 주기 정책을 적용하자 S3 비용이 한 달 만에 절반으로 줄었습니다.

실전 팁

💡 - S3 Storage Lens로 버킷별 사용 현황을 먼저 분석하세요

접근 패턴이 불확실하면 Intelligent-Tiering을 사용하세요
Glacier에서 데이터를 자주 복원하면 오히려 비용이 증가하니 주의하세요

6. Trusted Advisor 권장 사항 적용

여러 최적화를 진행한 후, 김개발 씨는 뿌듯했습니다. 하지만 박시니어 씨가 물었습니다.

"혹시 놓친 게 있을 수도 있지 않을까요? AWS가 알려주는 권장사항을 확인해본 적 있어요?" 김개발 씨는 고개를 저었습니다.

AWS가 직접 조언을 해준다고요? 박시니어 씨가 Trusted Advisor라는 서비스를 소개해주었습니다.

AWS Trusted Advisor는 AWS 계정을 자동으로 분석해서 비용 최적화, 보안, 성능, 가용성 측면에서 개선점을 알려주는 서비스입니다. 마치 건강검진처럼 AWS 인프라의 문제점을 진단해줍니다.

무료 플랜에서도 핵심 점검 항목을 사용할 수 있으며, Business 이상 지원 플랜에서는 모든 점검 항목을 활용할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# Support 클라이언트 생성 (Trusted Advisor API)
support_client = boto3.client('support', region_name='us-east-1')

# Trusted Advisor 점검 항목 목록 조회
checks = support_client.describe_trusted_advisor_checks(
    language='en'
)

# 비용 최적화 카테고리 점검 항목 필터링
cost_checks = [
    check for check in checks['checks']
    if check['category'] == 'cost_optimizing'
]

print("=== 비용 최적화 점검 항목 ===")
for check in cost_checks[:5]:  # 상위 5개만 출력
    print(f"- {check['name']}")

# 특정 점검 항목 결과 조회 (예: 저사용 EC2 인스턴스)
check_id = 'Qch7DwouX1'  # Low Utilization EC2 Instances

result = support_client.describe_trusted_advisor_check_result(
    checkId=check_id,
    language='en'
)

# 경고 수준별 요약
status = result['result']['status']
resources_flagged = len(result['result'].get('flaggedResources', []))

print(f"\n점검 상태: {status}")
print(f"개선이 필요한 리소스 수: {resources_flagged}개")

# 절감 가능 금액이 있다면 출력
for resource in result['result'].get('flaggedResources', [])[:3]:
    metadata = resource.get('metadata', [])
    if len(metadata) > 4:
        print(f"인스턴스: {metadata[1]}, 평균 CPU: {metadata[4]}%")

Trusted Advisor는 마치 AWS 전문 컨설턴트가 여러분의 계정을 무료로 점검해주는 것과 같습니다. 수많은 AWS 고객의 사례를 바탕으로 모범 사례(Best Practice)를 정리해놓고, 여러분의 계정이 이를 따르고 있는지 자동으로 확인해줍니다.

박시니어 씨가 Trusted Advisor 대시보드를 열었습니다. 화면에는 다섯 가지 카테고리가 표시되어 있었습니다.

첫 번째는 **비용 최적화(Cost Optimization)**입니다. 이 카테고리에서 가장 유용한 점검 항목들을 찾을 수 있습니다.

저사용 EC2 인스턴스, 유휴 로드밸런서, 사용하지 않는 Elastic IP, 연결되지 않은 EBS 볼륨 등을 찾아줍니다. 김개발 씨가 깜짝 놀랐습니다.

"이 EC2 인스턴스는 테스트하고 껐다고 생각했는데, 3개월째 켜져 있었네요!" 두 번째는 **보안(Security)**입니다. 공개된 S3 버킷, MFA가 활성화되지 않은 루트 계정, 과도하게 열린 보안 그룹 등 보안 취약점을 알려줍니다.

비용 최적화만큼이나 중요한 영역입니다. 세 번째는 **가용성(Fault Tolerance)**입니다.

단일 가용 영역에만 배포된 리소스, 백업이 설정되지 않은 데이터베이스 등 가용성 관련 위험을 알려줍니다. 네 번째는 **성능(Performance)**입니다.

EC2 인스턴스 타입이 너무 작거나, CloudFront 설정이 최적화되지 않은 경우 등을 찾아줍니다. 다섯 번째는 **서비스 한도(Service Limits)**입니다.

AWS 서비스별 한도에 근접하고 있을 때 미리 알려줍니다. 갑자기 한도에 막혀서 장애가 발생하는 것을 예방할 수 있습니다.

다만 주의할 점이 있습니다. **무료 플랜(Basic 또는 Developer)**에서는 핵심 점검 항목 7개만 사용할 수 있습니다.

모든 점검 항목(115개 이상)을 사용하려면 Business 이상의 지원 플랜이 필요합니다. 하지만 무료 점검 항목만으로도 상당한 비용 절감 기회를 찾을 수 있습니다.

위 코드에서 Low Utilization EC2 Instances 점검을 실행하면, 평균 CPU 사용률이 낮은 인스턴스 목록이 나옵니다. 이런 인스턴스는 더 작은 사양으로 변경하거나, 필요 없다면 종료해야 합니다.

Trusted Advisor 권장사항을 한 번 확인하고 끝내면 안 됩니다. 리소스는 계속 변하기 때문입니다.

정기적으로, 적어도 월 1회는 점검하는 습관을 들이는 것이 좋습니다. AWS에서 제공하는 주간 이메일 알림을 활성화해두면 놓치지 않을 수 있습니다.

김개발 씨는 Trusted Advisor 권장사항을 따라 유휴 리소스들을 정리했습니다. 연결되지 않은 EBS 볼륨 5개, 사용하지 않는 Elastic IP 3개, 저사용 EC2 인스턴스 2개를 발견했습니다.

정리하니 월 $200 이상을 절감할 수 있었습니다.

실전 팁

💡 - Trusted Advisor 점검은 최소 월 1회 정기적으로 수행하세요

무료 플랜에서도 핵심 점검 7개는 사용 가능합니다
주간 알림 이메일을 활성화해서 권장사항을 놓치지 마세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#CostOptimization#FinOps#ReservedInstance#SpotInstance#AWS,Cost Optimization,FinOps

AWS 비용 최적화 및 FinOps 전략 완벽 가이드

# AWS 비용 최적화 및 FinOps 전략 완벽 가이드 AWS 클라우드 비용을 효과적으로 관리하고 최적화하는 방법을 알아봅니다. Reserved Instance, Spot Instance, Savings Plans 등 다양한 비용 절감 전략과 FinOps 사고방식을 초급 개발자도 쉽게 이해할 수 있도록 설명합니다. --- ## 목차 1. [AWS_비용_구조_이해하기](#aws-비용-구조-이해하기) 2. [Reserved_Instance_구매_전략](#reserved-instance-구매-전략) 3. [Spot_Instance로_최대_90%_절감](#spot-instance로-최대-90%-절감) 4. [Savings_Plans_활용](#savings-plans-활용) 5. [S3_스토리지_클래스_최적화](#s3-스토리지-클래스-최적화) 6. [Trusted_Advisor_권장_사항_적용](#trusted-advisor-권장-사항-적용) --- ## 1. AWS_비용_구조_이해하기 김개발 씨는 스타트업에 입사한 지 6개월 된 주니어 개발자입니다. 어느 날 팀장님이 다급하게 달려왔습니다. "이번 달 AWS 청구서가 예상보다 3배나 나왔어요. 뭐가 문제인지 파악해 볼 수 있어요?" 김개발 씨는 당혹스러웠습니다. 서버가 잘 돌아가는 것만 확인했지, 비용이 어떻게 청구되는지는 한 번도 생각해 본 적이 없었기 때문입니다. AWS 비용 구조는 크게 **컴퓨팅**, **스토리지**, **네트워크** 세 가지 축으로 이루어져 있습니다. 마치 집에서 전기세, 수도세, 가스비를 따로 내는 것처럼, AWS도 사용한 리소스별로 각각 비용이 청구됩니다. 이 구조를 이해하면 어디서 비용이 새고 있는지 파악할 수 있고, 효과적인 절감 전략을 세울 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # AWS Cost Explorer 클라이언트 생성 ce_client = boto3.client('ce', region_name='us-east-1') # 지난 달 비용을 서비스별로 조회 response = ce_client.get_cost_and_usage( TimePeriod={ 'Start': '2024-01-01', 'End': '2024-01-31' }, Granularity='MONTHLY', Metrics=['UnblendedCost'], # 서비스별로 그룹화하여 비용 분석 GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}] ) # 결과 출력: 어떤 서비스가 얼마나 비용을 차지하는지 확인 for group in response['ResultsByTime'][0]['Groups']: service = group['Keys'][0] cost = group['Metrics']['UnblendedCost']['Amount'] print(f"{service}: ${float(cost):.2f}") ``` 김개발 씨는 AWS 콘솔에 로그인해서 청구서를 열어보았습니다. 숫자들이 빼곡히 적혀 있었지만, 도대체 뭐가 뭔지 알 수가 없었습니다. EC2, S3, RDS, CloudFront... 각각이 얼마씩 나온 건지, 왜 이렇게 많이 나온 건지 감이 잡히지 않았습니다. 그때 옆자리 박시니어 씨가 다가왔습니다. "AWS 비용 구조부터 이해해야 해요. 일단 큰 그림부터 봅시다." AWS 비용 구조는 마치 아파트 관리비와 비슷합니다. 아파트 관리비를 보면 전기료, 수도료, 난방비, 청소비 등 항목별로 나뉘어 있습니다. AWS도 마찬가지입니다. 크게 세 가지 축으로 비용이 발생합니다. 첫 번째는 **컴퓨팅 비용**입니다. EC2 인스턴스를 띄워두면 시간당 비용이 청구됩니다. 마치 전기를 켜두면 전기세가 나가는 것과 같습니다. 인스턴스 타입에 따라 시간당 요금이 다르고, 24시간 365일 켜두면 그만큼 비용이 누적됩니다. 두 번째는 **스토리지 비용**입니다. S3에 파일을 저장하거나 EBS 볼륨을 사용하면 GB당 월 비용이 발생합니다. 창고 임대료라고 생각하면 됩니다. 물건을 많이 쌓아둘수록 창고비가 올라가는 것처럼, 데이터를 많이 저장할수록 비용이 증가합니다. 세 번째는 **네트워크 비용**입니다. 이 부분이 초보자들이 가장 간과하는 영역입니다. AWS 밖으로 데이터를 전송할 때마다 비용이 발생합니다. 택배비라고 생각하면 됩니다. 고객에게 이미지나 동영상을 전송할 때마다 조금씩 비용이 쌓입니다. 위의 코드를 살펴보겠습니다. **Cost Explorer API**를 사용해서 지난 달 비용을 서비스별로 조회하고 있습니다. TimePeriod로 기간을 지정하고, GroupBy로 SERVICE 기준으로 그룹화합니다. 이렇게 하면 EC2가 얼마, S3가 얼마, RDS가 얼마인지 한눈에 파악할 수 있습니다. 실제로 코드를 실행해보면 깜짝 놀랄 수 있습니다. 생각지도 못한 서비스에서 비용이 새고 있는 경우가 많기 때문입니다. 개발하다가 테스트용으로 띄워둔 인스턴스, 삭제하지 않은 스냅샷, 연결되지 않은 Elastic IP 같은 것들이 좀비처럼 비용을 먹어치우고 있을 수 있습니다. 한 가지 주의할 점이 있습니다. AWS 비용은 리전별로 다릅니다. 서울 리전이 버지니아 리전보다 약 10-20% 비쌉니다. 그렇다고 무조건 싼 리전을 선택하면 네트워크 지연 때문에 사용자 경험이 나빠질 수 있습니다. 비용과 성능 사이에서 균형을 찾아야 합니다. 김개발 씨는 Cost Explorer를 통해 문제를 발견했습니다. 개발 환경 EC2 인스턴스들이 밤새 켜져 있었던 것입니다. 퇴근 후에는 끄고, 출근하면 켜는 자동화 스크립트만 추가해도 비용을 상당히 절감할 수 있었습니다. 비용 구조를 이해하는 것은 FinOps의 첫걸음입니다. 문제를 알아야 해결할 수 있으니까요. 이제 구체적인 절감 전략으로 넘어가 봅시다. **실전 팁** 💡 - Cost Explorer에서 일별 비용 추이를 확인하면 갑자기 비용이 튄 날을 쉽게 찾을 수 있습니다 - AWS 프리 티어 한도를 넘으면 바로 과금이 시작되니 CloudWatch 알람을 설정해두세요 - 태그(Tag)를 잘 붙여두면 프로젝트별, 팀별 비용 분석이 가능합니다 --- ## 2. Reserved_Instance_구매_전략 김개발 씨의 스타트업이 성장하면서 서버도 늘어났습니다. 매달 AWS 청구서를 보며 한숨을 쉬던 박시니어 씨가 어느 날 제안했습니다. "우리 이제 Reserved Instance 좀 검토해볼까요? 1년 넘게 계속 쓰는 서버들이 있잖아요." 김개발 씨는 고개를 갸웃했습니다. 예약 인스턴스라니, 호텔 예약처럼 미리 서버를 예약해두는 건가요? **Reserved Instance(RI)**는 1년 또는 3년 동안 특정 인스턴스 타입을 사용하겠다고 약정하는 대신 최대 72%까지 할인받는 방식입니다. 마치 헬스장 연간 회원권과 같습니다. 매달 끊으면 비싸지만, 1년치를 한 번에 결제하면 훨씬 저렴해지는 원리입니다. 24시간 365일 돌아가야 하는 프로덕션 서버에 적용하면 큰 비용 절감 효과를 볼 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # EC2 클라이언트 생성 ec2_client = boto3.client('ec2', region_name='ap-northeast-2') # 현재 사용 중인 Reserved Instance 목록 조회 ri_response = ec2_client.describe_reserved_instances( Filters=[ {'Name': 'state', 'Values': ['active']} ] ) # RI 활용 현황 분석 for ri in ri_response['ReservedInstances']: instance_type = ri['InstanceType'] instance_count = ri['InstanceCount'] end_date = ri['End'] # 만료일이 가까운 RI 알림 print(f"인스턴스 타입: {instance_type}") print(f"수량: {instance_count}개") print(f"만료일: {end_date}") print(f"---") # On-Demand 대비 절감액 계산 예시 on_demand_hourly = 0.1 # 시간당 $0.1 ri_hourly = 0.06 # RI 적용 시 시간당 $0.06 monthly_hours = 730 # 한 달 약 730시간 monthly_savings = (on_demand_hourly - ri_hourly) * monthly_hours print(f"월간 절감액: ${monthly_savings:.2f}") ``` Reserved Instance를 이해하려면 먼저 On-Demand 방식을 알아야 합니다. On-Demand는 말 그대로 필요할 때 서버를 켜고, 사용한 만큼만 지불하는 방식입니다. 편리하지만 비쌉니다. 마치 택시를 타는 것과 같습니다. 반면 Reserved Instance는 장기 계약입니다. 1년 또는 3년 동안 특정 사양의 서버를 사용하겠다고 약속하면, AWS가 큰 폭의 할인을 해줍니다. 마치 리스 차량이나 헬스장 연간 회원권과 같은 개념입니다. 박시니어 씨가 화이트보드에 숫자를 적기 시작했습니다. "자, 우리 메인 API 서버는 t3.large를 쓰고 있어요. On-Demand로 1년 쓰면 대략 $730 정도 나와요. 그런데 1년 RI를 사면 $456밖에 안 들어요. 거의 40% 절감이죠." 김개발 씨가 질문했습니다. "그럼 무조건 RI를 사는 게 좋은 거 아닌가요?" 박시니어 씨가 고개를 저었습니다. "그게 그렇게 단순하지 않아요. RI에는 세 가지 결제 옵션이 있거든요." 첫 번째는 **전액 선결제(All Upfront)**입니다. 1년치 또는 3년치 비용을 한 번에 내는 방식입니다. 할인율이 가장 높지만, 목돈이 필요합니다. 3년 전액 선결제 시 최대 72%까지 할인받을 수 있습니다. 두 번째는 **부분 선결제(Partial Upfront)**입니다. 일부는 선결제하고, 나머지는 월별로 나눠 내는 방식입니다. 할인율은 중간 수준이지만, 현금 흐름 관리가 수월합니다. 세 번째는 **선결제 없음(No Upfront)**입니다. 선결제 없이 월별로 나눠 내는 방식입니다. 할인율은 가장 낮지만, 초기 부담이 없습니다. 그렇다면 어떤 서버에 RI를 적용해야 할까요? 핵심은 **사용률**입니다. 24시간 365일 돌아가야 하는 프로덕션 데이터베이스나 API 서버는 RI의 좋은 후보입니다. 반면, 개발 서버처럼 업무 시간에만 켜는 서버는 RI를 사면 오히려 손해입니다. AWS에서는 **RI 구매 권장 사항**을 제공합니다. Cost Explorer에서 RI 권장 사항 메뉴를 보면, 지난 사용 패턴을 분석해서 어떤 인스턴스에 RI를 적용하면 좋을지 추천해줍니다. 이 기능을 활용하면 분석 시간을 크게 줄일 수 있습니다. 한 가지 더 알아둘 것이 있습니다. RI에는 **표준(Standard)**과 **컨버터블(Convertible)** 두 종류가 있습니다. 표준 RI는 할인율이 높지만 인스턴스 타입을 변경할 수 없습니다. 컨버터블 RI는 할인율은 조금 낮지만, 필요하면 다른 인스턴스 타입으로 교환할 수 있습니다. 스타트업처럼 빠르게 변화하는 환경에서는 컨버터블 RI가 더 안전한 선택일 수 있습니다. 1년 후에 어떤 사양이 필요할지 정확히 예측하기 어렵기 때문입니다. 김개발 씨의 회사는 결국 프로덕션 데이터베이스 서버에 3년 부분 선결제 RI를 적용하기로 했습니다. 연간 수백만 원을 절감할 수 있게 되었습니다. **실전 팁** 💡 - RI 구매 전 최소 1-2개월간 사용 패턴을 분석하세요 - 컨버터블 RI는 인스턴스 패밀리까지 변경 가능하니 불확실성이 높을 때 고려하세요 - RI Marketplace에서 남은 RI를 사고팔 수 있습니다 --- ## 3. Spot_Instance로_최대_90%_절감 어느 날 박시니어 씨가 흥분한 표정으로 달려왔습니다. "김개발 씨, 우리 배치 작업 서버 비용을 90% 줄일 수 있는 방법을 찾았어요!" 김개발 씨는 믿기지 않았습니다. 90%라니, 그게 가능한 건가요? 박시니어 씨가 화면에 띄운 것은 Spot Instance라는 생소한 개념이었습니다. **Spot Instance**는 AWS의 여유 컴퓨팅 자원을 경매 방식으로 저렴하게 사용하는 방식입니다. 마치 비행기 빈 좌석을 막판에 싸게 파는 땡처리 항공권과 같습니다. On-Demand 대비 최대 90%까지 저렴하지만, AWS가 자원을 회수해야 할 때 2분 전 통보 후 인스턴스가 종료될 수 있습니다. 따라서 중단되어도 괜찮은 작업에만 사용해야 합니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2_client = boto3.client('ec2', region_name='ap-northeast-2') # Spot Instance 가격 히스토리 조회 spot_prices = ec2_client.describe_spot_price_history( InstanceTypes=['m5.large'], ProductDescriptions=['Linux/UNIX'], MaxResults=10 ) # 현재 Spot 가격 확인 for price in spot_prices['SpotPriceHistory']: az = price['AvailabilityZone'] spot_price = price['SpotPrice'] timestamp = price['Timestamp'] print(f"AZ: {az}, 가격: ${spot_price}/시간, 시간: {timestamp}") # Spot Instance 요청 생성 예시 spot_request = ec2_client.request_spot_instances( SpotPrice='0.05', # 최대 지불 의사 가격 InstanceCount=1, Type='one-time', LaunchSpecification={ 'ImageId': 'ami-0c55b159cbfafe1f0', 'InstanceType': 'm5.large', 'KeyName': 'my-key-pair' } ) print(f"Spot 요청 ID: {spot_request['SpotInstanceRequests'][0]['SpotInstanceRequestId']}") ``` Spot Instance를 이해하려면 AWS 데이터센터의 상황을 상상해보면 됩니다. AWS는 전 세계에 거대한 데이터센터를 운영합니다. 수많은 서버가 있지만, 항상 100% 가동되는 것은 아닙니다. 특정 시간대나 계절에 따라 사용량이 달라지기 때문에 항상 여유 자원이 존재합니다. AWS는 이 여유 자원을 놀리는 대신, 아주 저렴한 가격에 내놓기로 했습니다. 이것이 바로 Spot Instance입니다. 마치 호텔이 빈 방을 막판에 할인해서 파는 것과 같습니다. 어차피 비어있을 방이라면, 조금이라도 받는 게 낫기 때문입니다. 박시니어 씨가 가격표를 보여줬습니다. "m5.large On-Demand가 시간당 $0.096인데, Spot은 지금 $0.029밖에 안 해요. 70% 할인이에요." 김개발 씨가 물었습니다. "이렇게 싼데 왜 다들 안 쓰는 거예요?" 박시니어 씨가 웃으며 대답했습니다. "리스크가 있거든요. **Spot 인스턴스는 언제든 종료될 수 있어요**." 이것이 Spot Instance의 가장 중요한 특징입니다. AWS가 여유 자원을 On-Demand 고객에게 할당해야 할 때, Spot 인스턴스는 2분 전 통보 후 강제 종료됩니다. 따라서 Spot Instance는 중단되어도 괜찮은 작업에만 사용해야 합니다. 어떤 작업이 적합할까요? **배치 작업**이 대표적입니다. 데이터 분석, 이미지 처리, 로그 분석 같은 작업은 중간에 중단되더라도 나중에 이어서 하면 됩니다. **CI/CD 파이프라인**도 좋은 후보입니다. 빌드가 중단되면 그냥 다시 시작하면 됩니다. **개발 및 테스트 환경**도 마찬가지입니다. 반면 적합하지 않은 작업도 있습니다. 실시간 API 서버, 데이터베이스, 중요한 트랜잭션 처리 시스템은 Spot Instance에 올리면 안 됩니다. 갑자기 종료되면 서비스 장애로 이어질 수 있기 때문입니다. Spot Instance를 더 안정적으로 사용하는 방법도 있습니다. **Spot Fleet**을 사용하면 여러 인스턴스 타입과 가용 영역에 걸쳐 Spot 인스턴스를 분산 배치할 수 있습니다. 하나가 종료되어도 다른 것이 이어받아 작업을 계속할 수 있습니다. 또한 **Spot 중단 알림**을 활용할 수 있습니다. 인스턴스 메타데이터 서비스를 통해 2분 전에 종료 알림을 받을 수 있습니다. 이 시간 동안 현재 상태를 저장하고 우아하게 종료할 수 있습니다. 김개발 씨의 회사는 매일 밤 실행되는 데이터 분석 배치 작업을 Spot Instance로 전환했습니다. 같은 작업을 10분의 1 비용으로 처리할 수 있게 되었습니다. **실전 팁** 💡 - 여러 인스턴스 타입을 후보로 지정하면 Spot 가용성이 높아집니다 - Spot 가격은 수요에 따라 변동하니, 가격 히스토리를 확인해서 안정적인 타입을 선택하세요 - Spot과 On-Demand를 혼합하는 전략도 고려해보세요 --- ## 4. Savings_Plans_활용 Reserved Instance를 도입한 지 6개월이 지났습니다. 그런데 새로운 고민이 생겼습니다. 회사가 컨테이너와 서버리스를 도입하면서 EC2만 쓰던 시절이 끝났기 때문입니다. ECS, Fargate, Lambda 비용도 줄이고 싶은데, RI로는 불가능했습니다. 박시니어 씨가 새로운 카드를 꺼내들었습니다. "Savings Plans 들어보셨어요?" **Savings Plans**는 특정 인스턴스가 아닌 시간당 사용량($/시간)을 약정하는 새로운 할인 모델입니다. 마치 통신사 요금제처럼 월 일정 금액을 약정하면 그만큼의 사용량에 할인이 적용됩니다. RI보다 유연하며, EC2뿐 아니라 Fargate와 Lambda까지 할인받을 수 있다는 장점이 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # Savings Plans 클라이언트 생성 sp_client = boto3.client('savingsplans', region_name='us-east-1') # 현재 활성화된 Savings Plans 조회 active_plans = sp_client.describe_savings_plans( states=['active'] ) for plan in active_plans['savingsPlans']: commitment = plan['commitment'] savings_plan_type = plan['savingsPlanType'] term = plan['termDurationInSeconds'] / (365 * 24 * 3600) print(f"타입: {savings_plan_type}") print(f"약정 금액: ${commitment}/시간") print(f"기간: {term:.0f}년") print(f"---") # Cost Explorer에서 Savings Plans 권장사항 조회 ce_client = boto3.client('ce', region_name='us-east-1') recommendations = ce_client.get_savings_plans_purchase_recommendation( SavingsPlansType='COMPUTE_SP', TermInYears='ONE_YEAR', PaymentOption='NO_UPFRONT', LookbackPeriodInDays='THIRTY_DAYS' ) # 권장사항 출력 if recommendations.get('SavingsPlansPurchaseRecommendation'): rec = recommendations['SavingsPlansPurchaseRecommendation'] print(f"권장 약정액: ${rec.get('SavingsPlansPurchaseRecommendationDetails', [{}])[0].get('HourlyCommitment', 'N/A')}/시간") ``` Savings Plans가 등장하기 전, AWS 할인을 받으려면 Reserved Instance를 사야 했습니다. 하지만 RI에는 한계가 있었습니다. 특정 인스턴스 타입에 묶여 있어서, 기술 스택이 바뀌면 할인 혜택을 못 받는 경우가 생겼습니다. 박시니어 씨가 예를 들어 설명했습니다. "우리가 m5.large에 RI를 샀다고 해봐요. 그런데 나중에 컨테이너로 전환해서 Fargate를 쓰게 되면요? RI는 Fargate에 적용이 안 돼요. 결국 RI 할인은 못 받고, Fargate는 On-Demand로 내야 해요." Savings Plans는 이 문제를 해결합니다. 특정 인스턴스가 아니라 **시간당 사용 금액**을 약정하기 때문입니다. 예를 들어 "$10/시간"을 약정했다고 합시다. 이 $10 내에서 EC2를 쓰든, Fargate를 쓰든, Lambda를 쓰든 상관없이 할인이 적용됩니다. 마치 통신사 데이터 무제한 요금제처럼, 약정 범위 내에서는 자유롭게 사용할 수 있습니다. Savings Plans에는 두 가지 종류가 있습니다. 첫 번째는 **Compute Savings Plans**입니다. 가장 유연한 옵션입니다. EC2, Fargate, Lambda 어디에든 적용됩니다. 리전도 자유롭게 바꿀 수 있고, 인스턴스 패밀리도 제한이 없습니다. 할인율은 RI보다 조금 낮지만, 유연성이 뛰어납니다. 두 번째는 **EC2 Instance Savings Plans**입니다. 특정 리전과 인스턴스 패밀리(예: 서울 리전의 m5 시리즈)를 지정합니다. 유연성은 낮지만, 할인율이 더 높습니다. 컴퓨팅 환경이 안정적이라면 이 옵션이 더 유리합니다. 김개발 씨가 질문했습니다. "그럼 RI랑 Savings Plans 중에 뭘 선택해야 해요?" 박시니어 씨가 정리해줬습니다. "EC2만 쓰고 인스턴스 타입이 고정되어 있다면 RI가 조금 더 저렴해요. 하지만 Fargate나 Lambda도 쓰거나, 인스턴스 타입을 바꿀 가능성이 있다면 Savings Plans가 낫습니다. 요즘 추세는 Savings Plans 쪽이에요." Cost Explorer에서 Savings Plans 권장사항을 확인할 수 있습니다. 지난 30일간 사용 패턴을 분석해서 얼마를 약정하면 좋을지 추천해줍니다. 처음에는 이 권장사항을 참고하는 것이 좋습니다. 한 가지 팁을 드리자면, 약정액은 보수적으로 시작하세요. 항상 사용하는 최소 금액으로 약정하고, 초과분은 On-Demand로 처리하는 게 안전합니다. 나중에 사용량이 늘면 추가로 Savings Plans를 구매하면 됩니다. 김개발 씨의 회사는 Compute Savings Plans를 도입해서 EC2와 Lambda 비용을 동시에 절감할 수 있게 되었습니다. **실전 팁** 💡 - Compute Savings Plans는 가장 유연하므로 첫 도입 시 추천됩니다 - 약정액은 최소 사용량 기준으로 보수적으로 설정하세요 - 기존 RI와 Savings Plans는 동시에 적용될 수 있으며, RI가 먼저 적용됩니다 --- ## 5. S3_스토리지_클래스_최적화 어느 날 청구서를 보던 김개발 씨가 이상한 점을 발견했습니다. "S3 비용이 왜 이렇게 많이 나오지? 우리 그렇게 많은 파일을 저장하나요?" 분석해보니 3년 전 프로젝트 백업 파일, 오래된 로그, 한 번도 조회되지 않은 데이터들이 S3에 쌓여 있었습니다. 모두 가장 비싼 Standard 클래스에 저장되어 있었습니다. S3는 데이터 접근 빈도에 따라 여러 **스토리지 클래스**를 제공합니다. 마치 물건 보관 서비스에도 즉시 찾을 수 있는 보관함과 창고 깊숙이 보관하는 옵션이 있는 것처럼, S3도 자주 쓰는 데이터와 가끔 쓰는 데이터를 다르게 저장할 수 있습니다. 적절한 스토리지 클래스를 선택하면 최대 95%까지 비용을 절감할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 s3_client = boto3.client('s3', region_name='ap-northeast-2') # 버킷의 스토리지 클래스별 용량 분석 bucket_name = 'my-data-bucket' # S3 Inventory나 CloudWatch 지표로 분석하는 대신 # 수명 주기 정책 설정 예시 lifecycle_policy = { 'Rules': [ { 'ID': 'MoveToIA', 'Status': 'Enabled', 'Filter': {'Prefix': 'logs/'}, # 30일 후 Infrequent Access로 전환 'Transitions': [ { 'Days': 30, 'StorageClass': 'STANDARD_IA' }, # 90일 후 Glacier로 전환 { 'Days': 90, 'StorageClass': 'GLACIER' } ], # 365일 후 삭제 'Expiration': {'Days': 365} }, { 'ID': 'IntelligentTiering', 'Status': 'Enabled', 'Filter': {'Prefix': 'user-uploads/'}, # 업로드 시 Intelligent-Tiering 적용 'Transitions': [ { 'Days': 0, 'StorageClass': 'INTELLIGENT_TIERING' } ] } ] } # 수명 주기 정책 적용 s3_client.put_bucket_lifecycle_configuration( Bucket=bucket_name, LifecycleConfiguration=lifecycle_policy ) print(f"버킷 {bucket_name}에 수명 주기 정책이 적용되었습니다.") ``` S3 스토리지 클래스를 이해하려면 물건 보관 서비스를 생각해보면 됩니다. 자주 쓰는 물건은 집 앞 락커에 보관하면 편합니다. 빠르게 꺼낼 수 있으니까요. 하지만 비쌉니다. 반면 1년에 한 번 볼까 말까 한 물건은 외곽의 큰 창고에 보관해도 됩니다. 훨씬 저렴하지만 꺼내려면 며칠이 걸립니다. S3도 마찬가지입니다. 데이터 접근 빈도에 따라 다양한 스토리지 클래스를 제공합니다. **S3 Standard**는 가장 기본적인 클래스입니다. 즉시 접근 가능하고, 가용성과 내구성이 최고입니다. 하지만 가격도 가장 비쌉니다. 자주 읽고 쓰는 활성 데이터에 적합합니다. **S3 Standard-IA(Infrequent Access)**는 한 달에 한 번 정도 접근하는 데이터에 적합합니다. 저장 비용은 Standard의 약 절반이지만, 데이터를 읽을 때마다 조회 비용이 발생합니다. 백업이나 재해 복구용 데이터에 좋습니다. **S3 Glacier**는 거의 접근하지 않는 아카이브 데이터용입니다. 저장 비용이 Standard의 약 1/5 수준으로 매우 저렴합니다. 하지만 데이터를 꺼내려면 몇 분에서 몇 시간이 걸립니다. 법적으로 보관해야 하는 오래된 기록이나 로그에 적합합니다. **S3 Glacier Deep Archive**는 가장 저렴한 클래스입니다. Standard의 약 1/20 가격입니다. 하지만 데이터 복원에 12시간 이상 걸릴 수 있습니다. 7년, 10년 보관이 필요한 규제 준수용 데이터에 사용합니다. 박시니어 씨가 핵심을 짚었습니다. "문제는 사람들이 데이터를 올릴 때는 Standard를 쓰고, 그 후로 신경을 안 써요. 3년 전 로그가 아직도 Standard에 있는 거죠. 이걸 자동화해야 해요." 바로 **수명 주기 정책(Lifecycle Policy)**입니다. 위의 코드처럼 규칙을 설정하면, 데이터가 자동으로 저렴한 클래스로 이동합니다. 30일이 지나면 Standard-IA로, 90일이 지나면 Glacier로, 365일이 지나면 삭제되도록 설정할 수 있습니다. 접근 패턴을 예측하기 어려운 경우에는 **S3 Intelligent-Tiering**을 고려해보세요. AWS가 자동으로 접근 패턴을 분석해서 적절한 티어로 데이터를 옮겨줍니다. 약간의 모니터링 비용이 들지만, 직접 관리하는 것보다 편리합니다. 김개발 씨는 S3 Storage Lens를 사용해서 버킷별 스토리지 현황을 분석했습니다. 3년간 한 번도 접근하지 않은 데이터가 전체의 60%를 차지하고 있었습니다. 수명 주기 정책을 적용하자 S3 비용이 한 달 만에 절반으로 줄었습니다. **실전 팁** 💡 - S3 Storage Lens로 버킷별 사용 현황을 먼저 분석하세요 - 접근 패턴이 불확실하면 Intelligent-Tiering을 사용하세요 - Glacier에서 데이터를 자주 복원하면 오히려 비용이 증가하니 주의하세요 --- ## 6. Trusted_Advisor_권장_사항_적용 여러 최적화를 진행한 후, 김개발 씨는 뿌듯했습니다. 하지만 박시니어 씨가 물었습니다. "혹시 놓친 게 있을 수도 있지 않을까요? AWS가 알려주는 권장사항을 확인해본 적 있어요?" 김개발 씨는 고개를 저었습니다. AWS가 직접 조언을 해준다고요? 박시니어 씨가 Trusted Advisor라는 서비스를 소개해주었습니다. **AWS Trusted Advisor**는 AWS 계정을 자동으로 분석해서 비용 최적화, 보안, 성능, 가용성 측면에서 개선점을 알려주는 서비스입니다. 마치 건강검진처럼 AWS 인프라의 문제점을 진단해줍니다. 무료 플랜에서도 핵심 점검 항목을 사용할 수 있으며, Business 이상 지원 플랜에서는 모든 점검 항목을 활용할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # Support 클라이언트 생성 (Trusted Advisor API) support_client = boto3.client('support', region_name='us-east-1') # Trusted Advisor 점검 항목 목록 조회 checks = support_client.describe_trusted_advisor_checks( language='en' ) # 비용 최적화 카테고리 점검 항목 필터링 cost_checks = [ check for check in checks['checks'] if check['category'] == 'cost_optimizing' ] print("=== 비용 최적화 점검 항목 ===") for check in cost_checks[:5]: # 상위 5개만 출력 print(f"- {check['name']}") # 특정 점검 항목 결과 조회 (예: 저사용 EC2 인스턴스) check_id = 'Qch7DwouX1' # Low Utilization EC2 Instances result = support_client.describe_trusted_advisor_check_result( checkId=check_id, language='en' ) # 경고 수준별 요약 status = result['result']['status'] resources_flagged = len(result['result'].get('flaggedResources', [])) print(f"\n점검 상태: {status}") print(f"개선이 필요한 리소스 수: {resources_flagged}개") # 절감 가능 금액이 있다면 출력 for resource in result['result'].get('flaggedResources', [])[:3]: metadata = resource.get('metadata', []) if len(metadata) > 4: print(f"인스턴스: {metadata[1]}, 평균 CPU: {metadata[4]}%") ``` Trusted Advisor는 마치 AWS 전문 컨설턴트가 여러분의 계정을 무료로 점검해주는 것과 같습니다. 수많은 AWS 고객의 사례를 바탕으로 모범 사례(Best Practice)를 정리해놓고, 여러분의 계정이 이를 따르고 있는지 자동으로 확인해줍니다. 박시니어 씨가 Trusted Advisor 대시보드를 열었습니다. 화면에는 다섯 가지 카테고리가 표시되어 있었습니다. 첫 번째는 **비용 최적화(Cost Optimization)**입니다. 이 카테고리에서 가장 유용한 점검 항목들을 찾을 수 있습니다. 저사용 EC2 인스턴스, 유휴 로드밸런서, 사용하지 않는 Elastic IP, 연결되지 않은 EBS 볼륨 등을 찾아줍니다. 김개발 씨가 깜짝 놀랐습니다. "이 EC2 인스턴스는 테스트하고 껐다고 생각했는데, 3개월째 켜져 있었네요!" 두 번째는 **보안(Security)**입니다. 공개된 S3 버킷, MFA가 활성화되지 않은 루트 계정, 과도하게 열린 보안 그룹 등 보안 취약점을 알려줍니다. 비용 최적화만큼이나 중요한 영역입니다. 세 번째는 **가용성(Fault Tolerance)**입니다. 단일 가용 영역에만 배포된 리소스, 백업이 설정되지 않은 데이터베이스 등 가용성 관련 위험을 알려줍니다. 네 번째는 **성능(Performance)**입니다. EC2 인스턴스 타입이 너무 작거나, CloudFront 설정이 최적화되지 않은 경우 등을 찾아줍니다. 다섯 번째는 **서비스 한도(Service Limits)**입니다. AWS 서비스별 한도에 근접하고 있을 때 미리 알려줍니다. 갑자기 한도에 막혀서 장애가 발생하는 것을 예방할 수 있습니다. 다만 주의할 점이 있습니다. **무료 플랜(Basic 또는 Developer)**에서는 핵심 점검 항목 7개만 사용할 수 있습니다. 모든 점검 항목(115개 이상)을 사용하려면 Business 이상의 지원 플랜이 필요합니다. 하지만 무료 점검 항목만으로도 상당한 비용 절감 기회를 찾을 수 있습니다. 위 코드에서 **Low Utilization EC2 Instances** 점검을 실행하면, 평균 CPU 사용률이 낮은 인스턴스 목록이 나옵니다. 이런 인스턴스는 더 작은 사양으로 변경하거나, 필요 없다면 종료해야 합니다. Trusted Advisor 권장사항을 한 번 확인하고 끝내면 안 됩니다. 리소스는 계속 변하기 때문입니다. 정기적으로, 적어도 월 1회는 점검하는 습관을 들이는 것이 좋습니다. AWS에서 제공하는 주간 이메일 알림을 활성화해두면 놓치지 않을 수 있습니다. 김개발 씨는 Trusted Advisor 권장사항을 따라 유휴 리소스들을 정리했습니다. 연결되지 않은 EBS 볼륨 5개, 사용하지 않는 Elastic IP 3개, 저사용 EC2 인스턴스 2개를 발견했습니다. 정리하니 월 $200 이상을 절감할 수 있었습니다. **실전 팁** 💡 - Trusted Advisor 점검은 최소 월 1회 정기적으로 수행하세요 - 무료 플랜에서도 핵심 점검 7개는 사용 가능합니다 - 주간 알림 이메일을 활성화해서 권장사항을 놓치지 마세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,Cost Optimization,FinOps

언어: Python

태그: AWS, CostOptimization, FinOps, ReservedInstance, SpotInstance, AWS,Cost Optimization,FinOps

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS 비용 최적화 및 FinOps 전략 완벽 가이드

목차

1. AWS 비용 구조 이해하기

2. Reserved Instance 구매 전략

3. Spot Instance로 최대 90% 절감

4. Savings Plans 활용

5. S3 스토리지 클래스 최적화

6. Trusted Advisor 권장 사항 적용

댓글 (0)

함께 보면 좋은 카드 뉴스

Blender 기초 조작법 완벽 가이드

실전 프로젝트 글로벌 엔터프라이즈급 AWS 아키텍처

CodePipeline으로 완전 자동화된 CI/CD 구축

ECS와 EKS로 컨테이너 오케스트레이션 완벽 가이드

대규모 트래픽을 위한 확장 가능한 아키텍처 완벽 가이드