비용 최적화와 대시보드

22장 ~ 26장에서 인프라 / DB / CI/CD / IaC / 모니터링까지 — 운영 가능한 시스템이 갖춰졌습니다. 마지막으로 남은 주제는 얼마나 들고 있는가, 그리고 그 비용을 어떻게 줄이는가입니다.

본 챕터는 4부 “콘솔에서 코드로"의 마지막입니다. 3장 비용 관리에서 결제 알림과 Cost Explorer의 기본을 잡았다면, 본 챕터는 그 위에서 운영 시스템의 비용을 실제로 줄이는 단계입니다. 그리고 챕터 끝에서 지금까지 쌓은 레이어를 한 번 정리하고, 5부 운영·보안·비용으로 넘어가는 다리를 놓습니다.

청구서가 어디서 새는가 #

전형적인 작은 운영 (ECS Fargate + RDS + ALB + CloudFront + Logs)의 월 청구서 비율은 다음과 같습니다.

이 표를 보고 “내 청구서랑 닮았다” 싶으면, 다음의 패턴이 통합니다.

1) Cost Explorer — 어디서 돈이 나가는지부터 #

Cost Explorer가 청구서를 슬라이스 / 다이스합니다. 콘솔에서 자주 쓰는 분석은 다음과 같습니다.

1) 서비스별        — Fargate vs RDS vs Logs (가장 큰 비용 항목)
2) 태그별          — env=prod vs env=dev (환경 분리 비용)
3) 사용 유형별      — DataTransfer-Out-Bytes vs BoxUsage 등
4) 리전별          — 잠자고 있는 다른 리전 자원 (1장 함정)
5) 시간 추세        — 어제부터 갑자기 오른 항목

CLI로도 #

aws ce get-cost-and-usage \
  --time-period Start=$(date -u +%Y-%m-01),End=$(date -u +%Y-%m-%d) \
  --granularity DAILY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

Cost Anomaly Detection #

ML 기반 이상치 감지입니다. 평소 패턴에서 벗어나면 자동으로 알립니다.

aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "blog-services",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE"
  }'

3장 비용 관리의 결제 알림이 “임계 넘으면"이라면, Cost Anomaly는 “평소와 다르면“입니다. 미묘한 누수를 잡는 도구입니다.

2) Compute 비용 — Fargate의 세 가지 포인트 #

A) Right Sizing — 진짜 필요한 만큼만 #

CloudWatch Container Insights (26장)의 평균 CPU / 메모리 사용률을 보고 task 크기를 조정합니다.

현재: cpu=1024, memory=2048
관찰: 평균 CPU 15%, p95 35%, 메모리 평균 30%
조정: cpu=512, memory=1024  → 비용 50% 절감

CPU 평균이 30~50% 영역에서 도는 게 건강한 수준입니다. 20% 미만이면 너무 큽니다 (그래도 burst 여유는 둡니다).

작은 환경에서는 Compute Optimizer가 자동으로 추천을 해줍니다. 콘솔에서 한 번 켜면 됩니다.

B) Fargate Spot — 70% 저렴 #

배치성 / 재시작 가능한 task는 Fargate Spot으로 돌립니다.

resource "aws_ecs_service" "this" {
  capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 1     # base on-demand
    base              = 2
  }

  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 4     # 추가는 Spot 우선
  }
}

위 패턴은 항상 2개는 on-demand, 그 이상은 4:1 비율로 Spot입니다. 부하가 줄면 Spot부터 정리합니다.

**중단 (interruption)**이 발생하면 ECS가 새 task를 띄우지만 ~120초 다운타임이 가능합니다. 운영 트래픽에서는 일부만 Spot으로 두며, 100% Spot은 큰 위험입니다.

C) Graviton (ARM) — 20% 저렴 + 20% 빠름 #

db.t4g.* (RDS), Fargate ARM 옵션, EC2 Graviton (m7g, c7g)은 AWS의 ARM 칩입니다. 컨테이너 이미지가 ARM 빌드가 가능하면 굳이 안 쓸 이유가 없습니다.

# 빌드
docker buildx build --platform linux/amd64,linux/arm64 \
  -t $REPO/blog-api:v1 --push .

resource "aws_ecs_task_definition" "this" {
  cpu          = "512"
  memory       = "1024"
  runtime_platform {
    cpu_architecture       = "ARM64"
    operating_system_family = "LINUX"
  }
}

전제는 사용 라이브러리가 모두 ARM 호환이어야 한다는 점입니다. 대부분의 Python / Node / Go 패키지는 OK입니다. 일부 native bindings는 검증이 필요합니다.

3) Savings Plans / Reserved Capacity #

Fargate / EC2 / Lambda의 약정 할인입니다.

Compute SP가 가장 유연합니다 (Fargate / EC2 / Lambda 모두 적용). 안정 운영에 들어간 시점부터 검토합니다. 처음에는 절대 약정하지 않습니다 (트래픽 / 아키텍처가 흔들릴 때).

운영 시작 ~ 3개월     : 약정 X (변화가 빠른 환경)
3개월 ~ 6개월         : 사용량 분석, 1년 SP 검토 시작
6개월 +              : 안정 사용량의 60~70% 만큼 1년 약정

전체 100%를 약정하면 트래픽이 줄 때 손해입니다. 항상 안전 마진을 둡니다.

4) Storage / Logs — 가장 자주 새는 항목 #

CloudWatch Logs #

26장에서 강조한 retention입니다. 모든 그룹에 적용합니다.

resource "aws_cloudwatch_log_group" "ecs" {
  for_each          = toset(["/ecs/blog-api", "/ecs/blog-api-migrate"])
  name              = each.key
  retention_in_days = 30
}

S3 #

오래된 객체를 자동으로 저렴한 클래스로 옮깁니다.

resource "aws_s3_bucket_lifecycle_configuration" "logs" {
  bucket = aws_s3_bucket.logs.id
  rule {
    id     = "to-ia-then-glacier"
    status = "Enabled"
    transition { days = 30,  storage_class = "STANDARD_IA" }
    transition { days = 90,  storage_class = "GLACIER" }
    expiration { days = 365 }
  }
}

ECR #

오래된 이미지를 자동으로 삭제합니다.

resource "aws_ecr_lifecycle_policy" "blog_api" {
  repository = aws_ecr_repository.blog_api.name
  policy = jsonencode({
    rules = [{
      rulePriority = 1
      description  = "최근 30개만 유지"
      selection    = { tagStatus = "any", countType = "imageCountMoreThan", countNumber = 30 }
      action       = { type = "expire" }
    }]
  })
}

5) Network — NAT와 Egress #

운영 청구서를 처음 보는 사람이 가장 놀라는 항목은 NAT Gateway와 Egress입니다.

시간당  $0.045
GB당    $0.045   (처리)
+ Egress $0.09/GB (인터넷으로)

작은 시스템에서도 NAT 한 개가 월 ~$32 + 트래픽입니다. 패턴별 절약은 다음과 같습니다.

Endpoint 한 줄 #

resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id              = aws_vpc.this.id
  service_name        = "com.amazonaws.${var.region}.ecr.api"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.endpoints.id]
  private_dns_enabled = true
}

ECS task가 ECR에서 이미지를 받을 때 NAT가 아니라 endpoint를 통해 받습니다. NAT 트래픽과 비용을 모두 절감합니다.

6) 태깅 — 비용을 분류 가능하게 #

태그가 없으면 청구서가 한 덩어리입니다. 태그가 있으면 환경 / 팀 / 프로젝트 별로 슬라이스 됩니다.

provider "aws" {
  default_tags {
    tags = {
      Environment = var.environment
      Project     = "blog-api"
      ManagedBy   = "terraform"
      CostCenter  = "product-blog"
    }
  }
}

provider의 default_tags는 모든 자원에 자동 적용됩니다. 운영의 핵심입니다.

Cost Allocation Tag 활성화 #

태그를 넣어도 콘솔의 Billing → Cost Allocation Tags에서 활성화하지 않으면 Cost Explorer가 분류해주지 않습니다. 설정 → 태그 활성 → ~24h 대기 → 사용 가능의 순서입니다.

태그 강제 (SCP / IAM Condition) #

태그 없는 자원 생성을 차단합니다. AWS Organizations의 SCP 또는 IAM 정책의 Condition으로 합니다.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
    "Resource": "*",
    "Condition": {
      "Null": { "aws:RequestTag/Environment": "true" }
    }
  }]
}

SCP와 Organizations 차원의 거버넌스는 29장 보안 거버넌스에서 본격적으로 다룹니다.

7) 운영 비용 대시보드 #

CloudWatch Dashboard에 비용 위젯 한 줄을 더합니다.

[1] 이번 달 누적 비용 (vs 지난달 같은 시점)
[2] 서비스별 (Fargate / RDS / Logs / NAT / ALB)
[3] 환경별 (env=prod vs env=staging vs env=dev)
[4] 일간 추세 (90일)
[5] Right Sizing 추천 수

매주 한 번 oncall 회의에서 30분이면 나빠지는 지표를 조기 발견 합니다.

분담 책임 — FinOps #

큰 조직은 FinOps라는 전담 영역이 따로 있어 비용을 봅니다. 작은 조직에서는 개발자 본인이 자기 모듈의 비용을 의식해야 합니다. 태그가 그래서 핵심입니다. 자기 코드의 청구서를 자기가 볼 수 있어야 의식이 생깁니다.

함정 — 비용에서 자주 만나는 함정 #

1) 잠자는 다른 리전 자원 #

1장 AWS 입문의 함정 그대로입니다. AWS Resource Explorer 또는 Cost Explorer의 리전별 비용에서 0이 아닌 리전을 점검합니다.

2) terraform destroy 안 한 PoC #

스택 / 환경을 만들고 잊는 실수입니다. 태그 + 자동 청소 람다 패턴으로 막습니다.

EventBridge schedule (매일 오전 9시)
    │
    ▼
Lambda
   - tag Project=PoC AND CreatedAt < 7 days ago
   - 자원 삭제 / 알림

3) Free Tier 만료 모름 #

3장 비용 관리의 결제 알림이 첫 방어선이고, Cost Anomaly Detection이 두 번째입니다.

4) 100% Spot으로 운영 다운타임 #

Spot interruption이 한 번에 여러 task에 걸리면 service가 desired count를 못 채워 5xx가 폭주합니다. 항상 base on-demand를 둡니다.

5) Multi-AZ RDS 두 배 #

작은 시스템엔 Multi-AZ가 비용 부담입니다. 그렇다고 단일 AZ도 곤란합니다. 절충은 dev/staging 단일 AZ + prod Multi-AZ입니다.

6) VPC Endpoint 미사용 #

NAT만 쓰는 단순 셋업이면 트래픽 큰 자원 (Logs, S3)이 NAT를 거쳐 비용이 폭주합니다. 운영에 들어가는 시점에 반드시 검토 합니다.

7) 약정 후 아키텍처 변경 #

3년 SP를 산 직후 ARM / Lambda로 옮기면 약정은 그대로 청구됩니다. 짧은 (1년) 약정부터, 안정적인 환경에서만 합니다.

4부에서 쌓은 레이어 #

여기까지가 4부 “콘솔에서 코드로"입니다. 1~3부에서 익힌 도구들이, 4부에서 한 시스템으로 쌓였습니다.

        ┌─────────────────────────────────────┐
        │ FinOps                              │   ← 27장
        │ 비용 / 태깅 / 약정                   │
        ├─────────────────────────────────────┤
        │ 관찰 가능성                          │   ← 26장
        │ Logs / Metrics / Traces             │
        ├─────────────────────────────────────┤
        │ 자동화                                │   ← 24, 25장
        │ CI/CD / IaC                         │
        ├─────────────────────────────────────┤
        │ 데이터                                │   ← 23장 + 11장
        │ RDS / Secrets                       │
        ├─────────────────────────────────────┤
        │ 컴퓨팅                                │   ← 22장 + 15~21장
        │ ECS / Lambda                        │
        ├─────────────────────────────────────┤
        │ 네트워크                              │   ← 8, 13, 14장
        │ VPC / ALB / CloudFront              │
        ├─────────────────────────────────────┤
        │ 컨트롤 평면                           │   ← 1~7장
        │ 계정 / IAM / 비용 / 보안              │
        └─────────────────────────────────────┘

위 레이어를 거꾸로 — 컨트롤 → 네트워크 → 컴퓨팅 → 데이터 → 자동화 → 관찰 → FinOps — 가 운영의 자연스러운 진화 순서입니다. 새 시스템을 만들 때마다 이 흐름을 다시 거치게 됩니다.

4부까지 따라온 분이라면, 작은 백엔드를 ECS Fargate 위에 운영 가능한 형태로 올리고, 코드로 재현하고, 자동으로 배포하고, 관찰하고, 비용을 통제하는 한 바퀴를 손에 넣은 셈입니다. 다음 5부는 이 시스템이 더 커졌을 때 — 네트워크를 더 깊이 설계하고, 멀티 어카운트로 거버넌스를 세우고, 장애에 대비하는 — 운영·보안·비용의 이야기로 이어집니다.

연습문제 #

1. §“청구서가 어디서 새는가"의 비율 표에서 자주 잊히는 비용 항목 두 가지(NAT/Egress, Logs retention)를 고르고, 본 챕터의 어느 절이 각각을 어떻게 줄이는지 짝지어 보세요.
2. Fargate compute 비용을 줄이는 세 가지 포인트(Right Sizing / Spot / Graviton)를 §2에서 정리하고, 각각의 위험 또는 전제 조건을 한 줄씩 적어 보세요. 100% Spot이 왜 위험한지 §“함정 4"와 연결해 설명해 보세요.
3. provider의 default_tags가 비용 관리에서 왜 핵심인지 한 단락으로 설명하고, 25장 Terraform 입문의 모듈 구조에서 이 태그가 어디에 들어가면 모든 환경에 일관되게 적용될지 메모해 두세요.

한 줄 요약: 작은 운영 청구서는 Fargate와 RDS가 절반 이상이고, NAT/Egress와 Logs retention이 자주 잊힌다. Cost Explorer와 Anomaly Detection으로 누수를 찾고, Right Sizing / Spot / Graviton / Savings Plans로 compute를 줄이며, Logs · S3 · ECR lifecycle과 VPC Endpoint로 storage와 network를 줄인다. default_tags로 모든 자원을 분류 가능하게 만들면 개발자 본인이 자기 비용을 의식하는 FinOps가 작동한다.

다음 챕터 #

4부까지 한 시스템이 운영 가능한 형태로 모였습니다. 여기서부터는 5부 운영·보안·비용으로 이어집니다. 다음 28장 VPC 심화에서는 지금까지 default VPC와 간이 셋업으로 빠르게 지나온 네트워크를, 운영 규모에서 다시 깊이 설계합니다 — 서브넷 라우팅, NAT와 VPC Endpoint, 보안 그룹과 NACL, 그리고 멀티 AZ 네트워크 구조까지.