Aurora Serverless v2: 'I/O Optimized'가 실제로 비용을 더 많이 들게 할 때

Source: Dev.to

번역을 진행하려면 번역이 필요한 전체 텍스트를 제공해 주시겠어요?
텍스트를 주시면 원본 형식과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

Source: …

요청

우리 매니저에게서 온 간단한 Slack 메시지에서 시작되었습니다:

“우리는 몇 달 동안 Aurora I/O Optimized를 사용해 왔습니다. Standard로 다시 전환하면 비용을 절감할 수 있을까요?”

우리는 고 트래픽 워크로드에 “Free IOPS”라는 약속이 완벽하게 들려 I/O Optimized를 활성화했습니다. 최근 검증이 없었기 때문에 우리는 눈앞이 어두웠습니다.

첫 번째 단계는 되돌리는 것이 성능에 영향을 미치는지 확인하는 것이었습니다. AWS 문서를 살펴보니 Standard와 I/O Optimized 사이를 전환해도 하드웨어는 변경되지 않으며, 순전히 청구 설정에만 영향을 미친다는 것을 확인했습니다.

가격 비교 (eu‑west‑1)

수학은 간단해 보입니다: 실제로 우리가 충분한 IOPS를 사용하고 있었는지, 컴퓨팅 및 스토리지에 대한 프리미엄을 정당화할 수 있었는지요?

Source: …

CloudWatch 함정

I wrote a quick Python script (using boto3) to pull metrics from CloudWatch and calculate the ServerlessDatabaseCapacity (ACUs) using the “Average” statistic over 30 days.

# Example snippet – not the full script
import boto3

client = boto3.client('cloudwatch')
response = client.get_metric_statistics(
    Namespace='AWS/RDS',
    MetricName='ServerlessDatabaseCapacity',
    Dimensions=[{'Name': 'DBClusterIdentifier', 'Value': 'my-cluster'}],
    StartTime=datetime.utcnow() - timedelta(days=30),
    EndTime=datetime.utcnow(),
    Period=300,
    Statistics=['Average']
)

결과: 계산이 부정확했습니다. Aurora Serverless는 초 단위로 스케일링됩니다. 데이터베이스가 30초 동안 60 ACU로 급증했다가 다시 감소하면, AWS 청구 엔진은 그 비용을 정확히 기록합니다. 그러나 CloudWatch는 해당 급증을 주변 1‑5 분 구간에 평균화하여 데이터를 부드럽게 만들기 때문에 실제 사용량보다 낮게(그리고 더 저렴하게) 보이게 됩니다.

교훈: 회계 목적으로 CloudWatch 평균값을 사용하지 마세요. CloudWatch는 모니터링 도구이며, 청구 도구가 아닙니다.

Hybrid Approach: The 10‑Day Snapshot

Because CloudWatch averages were unreliable and AWS Cost Explorer only provides 14 days of granular data, I devised a “10‑Day Snapshot” method:

1. Identify a representative 10‑day window (e.g., Dec 11 – Dec 20).
2. Use Cost Explorer to get the exact billed amount for Compute (ACUs) for that window.
   • Filter by Usage Type: EU-Aurora:ServerlessV2IOOptimizedUsage (ACU‑Hr) (since we were on Optimized).
   • Select the specific DB cluster as the resource.
3. Gather Storage and I/O data from CloudWatch for the same window.

Steps to Pull Storage & I/O from CloudWatch

1. Navigate to Metrics → AWS/RDS → DBClusterIdentifier.
2. Select the cluster (e.g., client-db-01).
3. Choose the metrics:
   • VolumeBytesUsed (Storage)
   • VolumeReadIOPS (Read I/O)
   • VolumeWriteIOPS (Write I/O)
4. Set the timeframe to the exact 10‑day window (Custom → Absolute).
5. Configure calculations:
   • Storage: Statistic = Average; apply expression m1/1024/1024/1024 to convert bytes to GB.
   • I/O: Statistic = Sum; apply expression m2 + m3 to combine read and write IOPS.
6. Period: Set to a single value covering the whole window (e.g., 864000 seconds ≈ 10 days) so CloudWatch returns one number instead of a line graph.

Now we have the exact numbers for total I/O, storage, and consumed ACUs for the 10‑day period.

비용 시나리오

모든 계산은 10일 스냅샷을 기준으로 하며, (10/30) 요인은 월별 스토리지 요금을 10일 기간에 맞게 조정합니다.

결론

The results were eye‑opening: we were overpaying on every single cluster. We immediately scheduled maintenance windows and converted all clusters back to Aurora Standard.

The validation proved that while “Optimized” sounds better, sometimes the “Standard” option is the true hero for your budget. If you are currently running on I/O Optimized, take a 10‑day snapshot and check your storage costs—you might be surprised by what you find.