AWS 비용 절감 완벽 가이드: 리소스 최적화 전략

AWS 비용 절감은 일반적으로 간단한 문제에서 시작합니다: 아무도 소유하지 않거나, 사용하지 않거나, 시작 후 크기를 조정하지 않은 리소스에 비용을 지불하고 있는 경우입니다. 리소스 최적화는 추측 없이 이러한 낭비를 찾을 수 있는 반복 가능한 방법을 제공합니다.

이 가이드는 실용적인 AWS 리소스 최적화에 초점을 맞춥니다: 태깅, 비용 및 사용량 보고서, 적정 규모 조정, 인스턴스 스케줄링, 스팟 인스턴스, S3 수명 주기 규칙, 그리고 약정 할인.

AWS 비용 최적화의 기본 기둥

AWS에서 효과적인 비용 관리는 세 가지 핵심 원칙에 기반합니다: 가시성, 책임성, 최적화. 리소스 사용량과 관련 비용에 대한 명확한 가시성 없이는 책임성을 확보할 수 없으며, 최적화 노력은 분산되고 비효율적일 것입니다.

1. 포괄적인 태깅을 통한 가시성 확보

태그는 AWS 리소스에 첨부하는 키-값 쌍입니다. 비용을 조직화, 추적 및 관리하는 데 중요합니다. 일관된 태깅 전략을 구현하는 것은 세분화된 비용 분석을 위해 필수적입니다.

실행 가능한 태깅 전략:

• 필수 태그: Environment(예: Prod, Staging, Dev), Owner, Project와 같은 필수 태그를 구현합니다. 이를 통해 AWS 비용 및 사용량 보고서(CUR)를 필터링하여 어떤 팀이나 애플리케이션이 비용을 발생시키는지 정확히 파악할 수 있습니다.
• 비용 할당 태그: 청구 콘솔에서 특정 태그를 활성화하여 비용 할당 태그로 사용합니다. 이렇게 하면 비용 보고서에 태그가 표시됩니다.

태깅 구현 예시(개념):

리소스	태그 키	태그 값
EC2 인스턴스	Environment	Production
RDS 데이터베이스	Project	CustomerPortalV2
S3 버킷	Owner	security-team

모범 사례: 지원되는 경우 요청 태그를 요구하는 서비스 제어 정책과 같은 예방적 제어와 후속 조정이 필요한 리소스에 대한 AWS Config 규칙과 같은 탐지적 제어를 통해 태깅을 강제합니다.

2. 비용 및 사용량 보고서(CUR)를 통한 책임성 확보

AWS Cost Explorer는 훌륭한 시각화를 제공하지만, 비용 및 사용량 보고서(CUR)는 가장 상세한 라인 항목 수준의 데이터를 제공합니다. S3 버킷으로 내보내고 Amazon Athena와 같은 서비스로 분석하는 CUR 데이터를 정기적으로 분석하는 것은 이상치를 찾는 데 핵심적입니다.

적정 규모 조정: 수요에 맞는 리소스 매칭

클라우드 낭비의 가장 큰 원인 중 하나는 과잉 프로비저닝, 즉 실제 워크로드에 필요한 것보다 더 큰 인스턴스나 데이터베이스를 실행하는 것입니다.

AWS Compute Optimizer 활용

AWS Compute Optimizer는 지원되는 리소스 구성 및 사용률 메트릭을 분석하여 적정 규모 조정 권장 사항을 제공합니다. EC2의 경우 CloudWatch 에이전트 또는 지원되는 통합을 통해 메모리 메트릭을 사용할 수 있을 때 CPU, 네트워크, 디스크 및 메모리 메트릭을 사용할 수 있습니다.

Compute Optimizer가 적정 규모 조정에 도움이 되는 방법:

• EC2 권장 사항: 사용률이 지속적으로 낮은 경우 더 낮은 인스턴스 유형 또는 제품군(예: M5.xlarge에서 M5.large로 이동)을 제안합니다.
• 메모리 인식 권장 사항: CPU 사용률은 낮지만 메모리 사용률이 높은 워크로드의 경우 메모리 메트릭을 사용할 수 있을 때 더 적합한 제품군을 권장할 수 있습니다.

적정 규모 조정 시 주의 사항: 항상 성능 여유를 고려하십시오. 인스턴스 사용률이 지속적으로 80% 이상인 경우 규모를 축소하면 피크 부하 시 성능 병목 현상이 발생할 수 있습니다. 적절한 버퍼를 남겨두는 목표 사용률을 목표로 하십시오.

EBS 볼륨 적정 규모 조정

인스턴스와 유사하게, EBS 볼륨은 더 낮은 계층으로 충분할 때 높은 크기 또는 프로비저닝된 IOPS(io2/gp3)로 프로비저닝된 상태로 남아 있는 경우가 많습니다. CloudWatch에서 VolumeReadOps, VolumeWriteOps 및 VolumeQueueLength 메트릭을 검토하여 더 작은 볼륨 크기로 안전하게 다운그레이드하거나 프로비저닝된 IOPS(io2)에서 분리된 성능 확장을 허용하는 범용 SSD(gp3)로 전환할 수 있는지 확인하십시오.

스케줄링 및 수명 주기 관리를 통한 컴퓨팅 비용 최적화

비프로덕션 환경(Dev, Test, QA)이 업무 시간에만 실행되는 경우 24/7 비용을 지불하는 것은 불필요한 낭비입니다.

인스턴스 스케줄링

AWS Instance Scheduler 또는 Amazon EventBridge(CloudWatch Events)에 의해 트리거되는 사용자 지정 Lambda 함수를 사용하여 정의된 일정(예: 오전 9:00 시작, 오후 7:00 중지, 월요일-금요일)에 따라 EC2 인스턴스를 자동으로 중지 및 시작합니다.

예시: 야간 개발 서버 중지(EventBridge/Lambda 사용 개념):

1. EventBridge 규칙: 매일 19:00 UTC에 트리거되는 반복 이벤트를 예약합니다.
2. 대상 작업: Lambda 함수를 호출합니다.
3. Lambda 로직(Python 코드 조각): boto3 EC2 클라이언트를 사용하여 Environment: Dev 태그로 인스턴스를 필터링하고 stop_instances()를 호출합니다.

import boto3

def lambda_handler(event, context):
    ec2_client = boto3.client('ec2')
    instance_ids = []
    
    # 자동 종료 태그가 지정된 인스턴스 필터링
    response = ec2_client.describe_instances(
        Filters=[
            {'Name': 'tag:Environment', 'Values': ['Dev', 'Test']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )
    
    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            instance_ids.append(instance['InstanceId'])
            
    if instance_ids:
        print(f"인스턴스 중지 중: {instance_ids}")
        ec2_client.stop_instances(InstanceIds=instance_ids)
    else:
        print("중지할 일치하는 인스턴스가 없습니다.")

내결함성 워크로드를 위한 스팟 인스턴스 활용

무상태, 내결함성 워크로드(예: 배치 처리, 컨테이너화된 마이크로서비스 또는 CI/CD 러너)의 경우 EC2 스팟 인스턴스를 활용하십시오. 스팟 인스턴스는 온디맨드 가격 대비 최대 90% 할인된 가격으로 사용되지 않는 EC2 용량을 제공합니다. 2분 경고와 함께 중단될 수 있지만, EC2 Fleet으로 구성된 Auto Scaling 그룹 또는 Amazon EKS/ECS와 같은 관리형 서비스는 용량을 드레이닝하고 교체 인스턴스를 시작하여 중단을 자동으로 처리할 수 있습니다.

스토리지 및 데이터 전송 비용 최적화

스토리지는 종종 조용히 누적됩니다. S3 수명 주기 정책을 관리하고 올바른 스토리지 클래스를 선택하는 것이 중요합니다.

S3 수명 주기 관리

오래되고 자주 액세스하지 않는 데이터를 비싼 스토리지 계층에 두지 마십시오.

• 전환 규칙: 30일 후에 데이터를 S3 Standard에서 S3 Standard-IA(Infrequent Access) 또는 S3 Glacier Flexible Retrieval로 자동 이동합니다.
• 만료 규칙: 지정된 보존 기간 후에 로그 또는 임시 파일을 영구 삭제합니다(예: 3년 이상 된 백업 삭제).

데이터베이스 최적화

Amazon RDS를 사용하는 경우 기본 스토리지 유형을 검토하십시오:

• IOPS 확장: 이전 프로비저닝된 스토리지(Standard 또는 io1)를 사용하는 경우 gp3로 마이그레이션하는 것을 평가하십시오. gp3를 사용하면 스토리지 크기와 독립적으로 기준 IOPS를 프로비저닝할 수 있어 높은 스토리지가 필요하지만 낮은 기준 IOPS가 필요한 경우 상당한 비용 절감 효과를 얻을 수 있습니다.

약정 기반 절감: 예약 인스턴스 및 세이빙스 플랜

안정적인 기준 인프라의 적정 규모를 조정한 후에는 사용량을 약정하여 볼륨 할인을 확보하십시오.

AWS 세이빙스 플랜(권장)

세이빙스 플랜은 기존 예약 인스턴스(RI)에 비해 최대 72%의 상당한 할인을 받을 수 있는 더 간단하고 유연한 방법을 제공합니다.

• 컴퓨트 세이빙스 플랜: 인스턴스 제품군, 크기, 리전 또는 운영 체제에 관계없이 EC2, Fargate 및 Lambda 사용량에 자동으로 적용됩니다. 동적 환경에 선호되는 선택입니다.
• EC2 인스턴스 세이빙스 플랜: 특정 인스턴스 제품군 및 리전에 연결된 고정 할인 약정을 제공합니다. 컴퓨트 세이빙스 플랜보다 더 제한적이지만 안정적인 기본 부하에 여전히 매우 유용합니다.

실행 단계: Cost Explorer에서 1년 및 3년 약정 가능성을 분석하십시오. 일반적인 지침은 안정적인 상태(항상 켜져 있는) 사용량의 100%를 세이빙스 플랜으로 커버하는 것입니다.

지속적인 최적화

비용 최적화는 일회성 정리가 아닙니다. Compute Optimizer와 Cost Explorer를 정기적으로 검토하고, 비용 할당 태그를 건강하게 유지하며, 비프로덕션 리소스가 유휴 상태일 때 중지하고, 안정적인 기준 사용량을 이해한 후에만 약정을 구매하십시오. 다음 유용한 단계는 하나의 계정 또는 워크로드를 선택하고, 깔끔하게 태그를 지정한 후, 광범위한 변경을 하기 전에 상위 3개 비용 동인을 검토하는 것입니다.