TL;DR（結論）

2つのキャッシュ方式

ローカルキャッシュ

1
2
3
4

cache {
  type  = "LOCAL"
  modes = ["LOCAL_DOCKER_LAYER_CACHE"]
}

• コスト: 無料
• 制約: 同じビルドホストでのみ有効、privileged モード必須
• 用途: 頻繁にビルドする CI/CD 環境

S3 キャッシュ

1
2
3
4

cache {
  type     = "S3"
  location = "my-bucket/cache"
}

• コスト: ストレージ $0.023/GB/月 + 転送 $0.09/GB
• 利点: 全ビルドホスト間で共有可能
• 用途: ビルドホストが頻繁に変わる環境

料金体系（2026年）

CodeBuild

S3 キャッシュ

1

月額コスト = (0.023 × キャッシュGB) + (ビルド回数 × キャッシュGB × 0.09)

実際のコスト比較

典型的なプロジェクト（キャッシュ 1GB、ヒット率 70%）の場合：

月50回を超えるビルドでは、S3 コストが$3以上になります。

Docker レイヤーキャッシュの仕組み

Docker イメージは複数のレイヤーで構成され、上位レイヤーが変更されると以降のレイヤーが無効化されます。

典型的なレイヤー構成

1
2
3
4
5
6

FROM node:20-alpine              # 150MB（変更: 月1回）
RUN apk add python3              # 50MB（変更: 月1回）
COPY package*.json ./
RUN npm ci                       # 300MB（変更: 週1回）
COPY . .                         # 20MB（変更: 毎日）
RUN npm run build                # 100MB（変更: 毎日）

キャッシュ効率

平均実効キャッシュ: 600-900MB、ヒット率: 70-75%

Dockerfile 最適化のポイント

❌ 悪い例

1
2

COPY . .
RUN npm install  # コード変更のたびに実行される

✅ 良い例

1
2
3
4
5
6

# 依存関係を先にインストール
COPY package*.json ./
RUN npm ci --only=production

# コードは後でコピー
COPY . .

効果: キャッシュヒット率が 60% → 75% に向上

決定フローチャート

1
2
3
4
5
6

ビルドホストは毎回変わる？
├─ Yes → S3 キャッシュ（必須）
└─ No
   └─ ビルド頻度は？
      ├─ 週2回以上 → ローカルキャッシュ（推奨）
      └─ 週1回以下 → どちらでも可

実装例

ローカルキャッシュ（推奨）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

resource "aws_codebuild_project" "app" {
  name = "my-app"

  environment {
    compute_type    = "BUILD_GENERAL1_SMALL"
    image          = "aws/codebuild/standard:7.0"
    type           = "LINUX_CONTAINER"
    privileged_mode = true  # 必須
  }

  cache {
    type  = "LOCAL"
    modes = ["LOCAL_DOCKER_LAYER_CACHE"]
  }
}

S3 キャッシュ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

resource "aws_codebuild_project" "app" {
  name = "my-app"

  environment {
    compute_type = "BUILD_GENERAL1_SMALL"
    image       = "aws/codebuild/standard:7.0"
    type        = "LINUX_CONTAINER"
  }

  cache {
    type     = "S3"
    location = "${aws_s3_bucket.cache.bucket}/my-app"
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "cache" {
  bucket = aws_s3_bucket.cache.id

  rule {
    id     = "expire-cache"
    status = "Enabled"
    expiration {
      days = 7  # 7日後に自動削除
    }
  }
}

まとめ

一般的な推奨

ほとんどの CI/CD 環境ではローカルキャッシュが最適

• 転送コストがゼロ
• ネットワーク遅延なし
• 月$5-$30 のコスト削減

例外的に S3 を選ぶケース

1. ビルドホストが毎回異なる（スポットインスタンスなど）
2. VPC 環境で動作する必要がある
3. ビルド頻度が非常に低い（月4回以下）

チェックリスト

Dockerfile を最適化する:

• 変更頻度の低い命令を上に配置
• 依存関係ファイルを先にコピー
• .dockerignore で不要ファイルを除外

ローカルキャッシュを使う場合:

• privileged_mode = true を設定
• セキュリティ要件を確認

S3 キャッシュを使う場合:

• ライフサイクルポリシーで7日後に削除
• 動的キャッシュキーを設定（codebuild-hash-files）

参考リンク

• AWS CodeBuild Pricing
• CodeBuild Build Caching
• CodeBuild Local Caching
• CodeBuild S3 Caching

概要

コンテナイメージを ECR から取得する際、以下の2つのアプローチがあります：

1. NAT Gateway 経由: インターネット経由でパブリックエンドポイントにアクセス
2. VPC Endpoint 経由: AWS のプライベートネットワーク内でアクセス

本記事では、東京リージョン（ap-northeast-1）における料金体系を基に、どちらがコスト効率的かを分析します。

料金体系の比較

NAT Gateway 経由のコスト

東京リージョンにおける NAT Gateway の料金は以下の通りです：

月間コスト計算式：

1

NAT Gateway コスト = $45.26 + ($0.062 × データ転送量 GB)

VPC Interface Endpoint 経由のコスト

ECR への完全なプライベートアクセスには、以下の3つのエンドポイントが必要です：

データ処理料金: $0.01/GB（Interface Endpoint のみ）

月間コスト計算式（1 AZ あたり）：

1
2

VPC Endpoint コスト = ($0.01 × 2エンドポイント × 730時間) + ($0.01 × データ転送量 GB)
                   = $14.60 + ($0.01 × データ転送量 GB)

⚠️ 重要: S3 Gateway Endpoint を必ず設定してください。ECR のイメージレイヤーは S3 に保存されており、S3 Endpoint がない場合、大部分のデータが NAT Gateway 経由となり、コスト削減効果がほとんど得られません。

損益分岐点の計算

1 AZ 構成の場合

NAT Gateway コスト = VPC Endpoint コスト として計算します：

1
2
3

$45.26 + ($0.062 × GB) = $14.60 + ($0.01 × GB)
$30.66 = $0.052 × GB
GB = 590GB/月

損益分岐点: 約590GB/月

590GB/月を超える場合、VPC Endpoint の方がコスト効率が良くなります。

月間コスト比較表

マルチ AZ 構成の考慮点

3 AZ 構成の場合：

• NAT Gateway: 各 AZ に1つずつ必要 → $45.26 × 3 = $135.78/月（基本料金のみ）
• VPC Endpoint: 各 AZ に展開される → $14.60 × 3 = $43.80/月（基本料金のみ）

マルチ AZ 構成では、基本料金の差がさらに大きくなるため、データ転送量が少なくても VPC Endpoint が有利になる可能性があります。

3 AZ での損益分岐点：

1
2
3
4

($45.26 × 3) + ($0.062 × GB) = ($14.60 × 3) + ($0.01 × GB)
$135.78 + ($0.062 × GB) = $43.80 + ($0.01 × GB)
$91.98 = $0.052 × GB
GB = 1,769GB/月（約1.77TB）

⚠️ 注意: 上記は全 AZ で均等にトラフィックが発生する前提です。実際には、クロス AZ トラフィックコスト（$0.01/GB）も考慮する必要があります。

コスト以外のメリット

VPC Endpoint のメリット

1. セキュリティの向上

   • インターネットを経由しないため、攻撃対象領域を削減
   • VPC 内でのトラフィック制御が可能

2. パフォーマンスの向上

   • AWS のプライベートネットワーク経由のため、レイテンシが低い
   • NAT Gateway のボトルネックを回避

3. 帯域幅の安定性

   • インターネット経由のトラフィックに影響されない
   • より予測可能なパフォーマンス

4. コンプライアンス要件

   • データがパブリックインターネットを経由しないことを要求される環境に対応

NAT Gateway のメリット

1. シンプルな構成

   • 既存の NAT Gateway をそのまま利用可能
   • 追加のエンドポイント設定が不要

2. 少量のトラフィックではコスト効率が良い

   • 月間590GB未満の場合は NAT Gateway の方が安価

実装のベストプラクティス

VPC Endpoint 導入時のチェックリスト

✅ 必須設定：

1. ECR API Endpoint（com.amazonaws.ap-northeast-1.ecr.api）を作成
2. ECR Docker Endpoint（com.amazonaws.ap-northeast-1.ecr.dkr）を作成
3. S3 Gateway Endpoint（com.amazonaws.ap-northeast-1.s3）を作成
4. セキュリティグループで HTTPS（443）トラフィックを許可
5. プライベート DNS を有効化

✅ 推奨設定：

• VPC Endpoint Policy で最小権限の原則を適用
• CloudWatch Logs で VPC Endpoint のトラフィックを監視
• 複数の AZ に Endpoint を配置して可用性を確保

Terraform 実装例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

# ECR API Endpoint
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.ap-northeast-1.ecr.api"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoint.id]
  private_dns_enabled = true

  tags = {
    Name = "ecr-api-endpoint"
  }
}

# ECR Docker Endpoint
resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.ap-northeast-1.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoint.id]
  private_dns_enabled = true

  tags = {
    Name = "ecr-dkr-endpoint"
  }
}

# S3 Gateway Endpoint
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.ap-northeast-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id

  tags = {
    Name = "s3-gateway-endpoint"
  }
}

# VPC Endpoint 用セキュリティグループ
resource "aws_security_group" "vpc_endpoint" {
  name        = "vpc-endpoint-sg"
  description = "Security group for VPC endpoints"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "vpc-endpoint-sg"
  }
}

意思決定フローチャート

graph TD    Start[ECR へのアクセス方法を決定] --> Q1{月間データ転送量は?}    Q1 -->|590GB 未満| Q2{単一 AZ 構成?}    Q1 -->|590GB 以上| R1[VPC Endpoint を推奨]    Q2 -->|Yes| R2[NAT Gateway を推奨]    Q2 -->|No| R3[VPC Endpoint も検討]    Start --> Q3{セキュリティ要件は?}    Q3 -->|インターネット経由を避けたい| R4[VPC Endpoint を推奨]    Start --> Q4{パフォーマンス要件は?}    Q4 -->|低レイテンシ・高帯域幅が必要| R5[VPC Endpoint を推奨]    style R1 fill:#90EE90    style R2 fill:#FFB6C1    style R3 fill:#FFE4B5    style R4 fill:#90EE90    style R5 fill:#90EE90

モニタリングとコスト最適化

CloudWatch メトリクス

VPC Endpoint の主要メトリクス

VPC Endpoint を導入後、以下のメトリクスを監視してコスト効果を測定します：

データ転送量の確認コマンド：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# VPC Endpoint のバイト数を確認（ECR API）
aws cloudwatch get-metric-statistics \
  --namespace AWS/PrivateLink \
  --metric-name BytesProcessed \
  --dimensions Name=ServiceName,Value=com.amazonaws.ap-northeast-1.ecr.api \
  --start-time 2026-04-01T00:00:00Z \
  --end-time 2026-04-30T23:59:59Z \
  --period 86400 \
  --statistics Sum \
  --region ap-northeast-1

# VPC Endpoint のバイト数を確認（ECR Docker）
aws cloudwatch get-metric-statistics \
  --namespace AWS/PrivateLink \
  --metric-name BytesProcessed \
  --dimensions Name=ServiceName,Value=com.amazonaws.ap-northeast-1.ecr.dkr \
  --start-time 2026-04-01T00:00:00Z \
  --end-time 2026-04-30T23:59:59Z \
  --period 86400 \
  --statistics Sum \
  --region ap-northeast-1

NAT Gateway の主要メトリクス

NAT Gateway を使用している場合、以下のメトリクスを監視します：

NAT Gateway のデータ転送量確認コマンド：

1
2
3
4
5
6
7
8
9
10

# NAT Gateway の送信バイト数を確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-xxxxxxxxxxxxxxxxx \
  --start-time 2026-04-01T00:00:00Z \
  --end-time 2026-04-30T23:59:59Z \
  --period 86400 \
  --statistics Sum \
  --region ap-northeast-1

CloudWatch Insights クエリ例

VPC Endpoint と NAT Gateway のトラフィックを比較分析するための Insights クエリ：

1
2
3
4
5

# VPC Endpoint の日次データ転送量
fields @timestamp, BytesProcessed
| filter ServiceName = "com.amazonaws.ap-northeast-1.ecr.api"
| stats sum(BytesProcessed) as TotalBytes by bin(1d)
| sort @timestamp desc

CloudWatch Alarms の設定推奨

コスト管理のために以下のアラームを設定することを推奨します：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# VPC Endpoint の月次データ転送量が閾値を超えた場合のアラーム
aws cloudwatch put-metric-alarm \
  --alarm-name "ecr-vpc-endpoint-monthly-data-transfer" \
  --alarm-description "VPC Endpoint monthly data transfer exceeds threshold" \
  --metric-name BytesProcessed \
  --namespace AWS/PrivateLink \
  --statistic Sum \
  --period 2592000 \
  --evaluation-periods 1 \
  --threshold 1099511627776 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=ServiceName,Value=com.amazonaws.ap-northeast-1.ecr.api \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:cost-alerts \
  --region ap-northeast-1

# NAT Gateway のポート割り当てエラー検知
aws cloudwatch put-metric-alarm \
  --alarm-name "nat-gateway-port-allocation-errors" \
  --alarm-description "NAT Gateway port allocation errors detected" \
  --metric-name ErrorPortAllocation \
  --namespace AWS/NATGateway \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=NatGatewayId,Value=nat-xxxxxxxxxxxxxxxxx \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:infrastructure-alerts \
  --region ap-northeast-1

Cost Explorer でのコスト追跡

AWS Cost Explorer で以下をフィルタリングして、実際のコスト削減効果を確認します：

• サービス: Amazon EC2（VPC Endpoint）
• 使用タイプ: 「VpcEndpoint」を含む
• リージョン: ap-northeast-1

よくある質問（FAQ）

Q: 既存の NAT Gateway から VPC Endpoint に切り替える際、ダウンタイムは発生しますか？

A: 適切に実装すれば、ダウンタイムなしで移行可能です。VPC Endpoint を作成し、プライベート DNS を有効化することで、アプリケーション側の変更なしに自動的に VPC Endpoint 経由になります。

Q: VPC Endpoint を作成しても NAT Gateway が必要ですか？

A: ECR へのアクセスのみであれば NAT Gateway は不要です。ただし、他のインターネット向けトラフィック（パッケージのダウンロード、外部 API へのアクセスなど）がある場合は、NAT Gateway または代替手段が必要です。

Q: S3 Gateway Endpoint は本当に無料ですか？

A: はい、S3 Gateway Endpoint 自体に料金はかかりません。ただし、S3 のデータ転送料金やリクエスト料金は別途発生します。

Q: マルチリージョン構成の場合は？

A: VPC Endpoint はリージョン固有のリソースです。複数リージョンで ECR を使用する場合、各リージョンで VPC Endpoint を作成する必要があります。

まとめ

ECR 用 VPC Interface Endpoint の損益分岐点は月間約590GBです。

推奨事項：

✅ VPC Endpoint を推奨する場合：

• 月間 ECR データ転送量が 590GB 以上
• マルチ AZ 構成で高トラフィック
• セキュリティ要件でインターネット経由を避けたい
• 低レイテンシ・高パフォーマンスが求められる

✅ NAT Gateway を継続する場合：

• 月間 ECR データ転送量が 590GB 未満
• 単一 AZ 構成で低トラフィック
• シンプルな構成を維持したい

重要なポイント：

1. ECR 用には 3つのエンドポイント（ecr.api、ecr.dkr、s3）すべてが必要
2. S3 Gateway Endpoint を忘れると、コスト削減効果がほとんど得られない
3. マルチ AZ 構成では基本料金の差が大きいため、より早く損益分岐点に達する

コスト最適化は継続的なプロセスです。AWS Cost Explorer や CloudWatch メトリクスを活用して、実際の使用状況を定期的に確認し、最適な構成を維持することが重要です。

参考リンク

• AWS PrivateLink Pricing
• Amazon VPC Pricing
• NAT Gateway Pricing Documentation
• NAT Gateways Killing Your Container Costs?
• VPC Endpoints Cost Comparison Guide
• AWS NAT Gateway Pricing Guide
• VPC Endpoint for ECR - AWS Documentation

この記事は AWS 公式ドキュメントおよび複数のコスト分析記事に基づいて作成されています。料金は 2026年4月時点のものであり、最新の情報については AWS 公式サイトをご確認ください。

はじめに

個人開発やスタートアップの初期段階では、インフラコストを抑えつつも信頼性の高いデータベースが必要です。本記事では、2026年時点で利用可能な完全無料のデータベースサービスを、公式ドキュメントをもとに徹底比較します。

選定基準

本記事では以下の条件を満たすサービスを対象としました：

• 24時間365日常時稼働: スリープや自動停止がない
• セキュリティ: SSL/TLS、認証機能、アクセス制御が利用可能
• 完全無料: クレジットカード不要、永続的に無料で利用可能
• 小規模サービス向け: プロトタイプや個人開発に十分なスペック

サービス詳細比較

Supabase

PostgreSQLベースのオープンソースFirebase代替サービスです。

無料プランスペック

• データベース: 500MB PostgreSQL
• ストレージ: 1GB
• プロジェクト数: 2つまで
• 月間アクティブユーザー: 50,000
• Edge Function: 500,000回/月
• 帯域幅: 5GB/月

セキュリティ機能

• SSL/TLS接続
• Row Level Security (RLS)
• 認証機能組み込み（Email、OAuth、Magic Link）
• APIキー管理

⚠️ 重要な制限事項

• プロジェクトは7日間非アクティブで自動停止
• バックアップなし
• SLAなし

参考: Supabase Pricing

Turso

SQLiteベースのエッジデータベースサービスです。

無料プランスペック

• ストレージ: 9GB（旧5GBから増量）
• データベース数: 500（2025年に大幅増量）
• 月間アクティブDB: 100
• 行読み込み: 5億行/月
• 行書き込み: 1,000万行/月

セキュリティ機能

• TLS暗号化
• トークンベース認証
• エッジでの分散実行

特徴

• SQLite互換で軽量
• グローバル分散による低レイテンシ
• 常時稼働、自動停止なし

参考: Turso Pricing, Database Freedom Day

MongoDB Atlas

NoSQLドキュメント指向データベースサービスです。

M0 無料プランスペック

• ストレージ: 512MB
• メモリ: 32MB ソート用
• 接続数: 最大500
• スループット: 最大100オペレーション/秒
• プロジェクト毎: 1クラスターまで

セキュリティ機能

• TLS/SSL接続
• IPホワイトリスト
• ユーザー認証・権限管理（RBAC）
• データ暗号化

特徴

• 常時稼働、期限なし
• Atlas Search利用可能（制限付き）
• Triggers、Charts利用可能
• 自動バックアップなし

参考: MongoDB Pricing, Atlas Free Cluster Limits

Firebase Firestore

GoogleのNoSQLドキュメントデータベースサービスです。

無料プランスペック（1日あたり）

• ストレージ: 1GB
• ドキュメント読み込み: 50,000回/日
• ドキュメント書き込み: 20,000回/日
• ドキュメント削除: 20,000回/日
• ネットワーク転送: 10GB/月

セキュリティ機能

• セキュリティルール
• Firebase Authentication連携
• SSL/TLS接続
• Googleのセキュリティ基盤

特徴

• 常時稼働（Googleインフラ）
• リアルタイム同期
• オフライン対応
• 認証機能も無料

参考: Firebase Pricing, Firestore Quotas

CockroachDB Serverless

PostgreSQL互換の分散SQLデータベースサービスです。

無料プランスペック

• ストレージ: 10GB/月（※公式情報に若干のばらつきあり）
• リクエストユニット: 5,000万RU/月
• SLA: 99.99%稼働保証

セキュリティ機能

• TLS接続必須
• 組織・ユーザー管理
• 監査ログ
• データ暗号化

特徴

• 常時稼働、自動スケール
• PostgreSQL互換
• 高可用性
• クレジットカード不要で開始可能

参考: CockroachDB Pricing, CockroachDB Serverless: Free. Seriously.

比較表

ユースケース別推奨

個人開発・プロトタイプ（データ量少）

おすすめ: Supabase (⚠️ 定期的なアクセスが必要)

• 認証、ストレージ、リアルタイム機能が統合
• PostgreSQLで扱いやすい
• 7日間アクティビティがないと停止するため、cron等で定期的なヘルスチェックが必要

個人開発・プロトタイプ（常時稼働重視）

おすすめ: Turso

• 9GBと大容量
• SQLite互換で軽量
• エッジ配信で高速
• 完全に常時稼働

グローバル展開を見据えた開発

おすすめ: Firebase Firestore

• Googleのグローバルインフラ
• リアルタイム同期
• オフライン対応
• 認証機能も統合

将来的なスケールを見据えた開発

おすすめ: CockroachDB Serverless

• 99.99%のSLA
• PostgreSQL互換で移行が容易
• 分散アーキテクチャで高可用性
• 有料プランへの移行がスムーズ

NoSQLでの開発

おすすめ: MongoDB Atlas

• 業界標準のNoSQL
• ドキュメント指向で柔軟
• 豊富なツール・ドライバ
• 常時稼働

セキュリティ面での考慮事項

SSL/TLS接続

全サービスで標準サポートされています。

アクセス制御

データ暗号化

全サービスで転送時の暗号化（TLS）が有効です。保管時の暗号化については、各サービスの公式ドキュメントを確認してください。

推奨ランキング（小規模サービス向け）

1. Turso - 大容量（9GB）、常時稼働、エッジ配信
2. CockroachDB - SLA保証、PostgreSQL互換、高可用性
3. Firebase - Googleインフラ、リアルタイム機能
4. MongoDB Atlas - NoSQL標準、豊富なエコシステム
5. Supabase - 機能豊富だが7日で自動停止に注意

まとめ

2026年現在、完全無料で常時稼働可能なデータベースサービスは複数の選択肢があります。

Tursoは9GBの大容量と常時稼働で個人開発に最適です。CockroachDB Serverlessは99.99%のSLA保証があり、本番レベルの信頼性が必要な場合に適しています。Firebase FirestoreはGoogleのインフラを活用でき、リアルタイム機能が必要な場合に最適です。

Supabaseは機能が豊富ですが、7日間の非アクティブで自動停止するため、常時稼働が必要な場合は定期的なアクセスの仕組みを用意する必要があります。

プロジェクトの要件に応じて最適なサービスを選択してください。

以上

参考になれば幸いです。

Application Signalsシグナル料金

階層型の従量課金制

• 最初の1億シグナル: $1.50 / 100万シグナル
• 次の9億シグナル（1億～10億）: $0.75 / 100万シグナル
• 10億シグナル超過分: $0.30 / 100万シグナル

Application Signals Bytesデータ取り込み料金

データ量に基づく階層型課金

• 最初の10TB: $0.35 / GB
• 次の20TB（10TB～30TB）: $0.20 / GB
• 30TB超過分: $0.15 / GB

料金体系の特徴

1. 完全従量課金制

• 使用した分だけ課金
• 最小利用料金なし

2. 階層型割引

• 使用量が増加するにつれて単価が下がる
• 大規模利用時のコスト効率が向上

3. リージョン別料金

• 東京リージョン（ap-northeast-1）の価格
• 他リージョンでは若干異なる場合あり

コスト例（月間利用）

関連コスト

Application Signalsを使用する際の追加的なコスト要因

• CloudWatchメトリクス料金
• X-Rayトレース料金（有効化している場合）
• Lambda、ECS、EKS等の関連サービス料金
• 他リージョンへのデータ転送料金

Application Signalsは比較的新しいサービスで、アプリケーションの可観測性を向上させる強力な機能を提供しますが、利用量に応じてコストが積み上がる点に注意が必要です。

以上

参考になれば幸いです。

Application Signals MCP でどんなことができるのか AWS ドキュメント 記載の内容そのままに以下の問い合わせをしました。

What questions can I ask about CloudWatch or Application Signals MCP Servers?

すると以下のような回答を頂いたので備忘録として残しておきます。

⏺ 素晴らしい！AWS Application SignalsのMCPサーバーが利用可能になりました。

以下のような質問ができます：

🎯 サービス監査・ヘルスチェック関連

基本的なサービス監査

• 全サービスの健全性を監査してください
• payment関連サービスの状態を確認してください
• EKSクラスター上のサービスをすべて監査してください
• 昨夜のサービス状況を確認してください

オペレーション別の詳細分析

• payment サービスのGETオペレーションのレイテンシーを監査してください
• 特定のAPIエンドポイントのパフォーマンスを調査してください
• エラー率の高いオペレーションを特定してください

📊 SLO（Service Level Objective）関連

SLO管理

• 設定されているSLOをすべて一覧表示してください
• SLOの違反状況を確認してください
• 特定のSLOの詳細設定を教えてください
• payment関連のSLO違反を根本原因分析してください

🔍 トレース・ログ分析

問題調査

• 特定のサービスでエラーが発生している原因を調査してください
• レイテンシーが高い原因をトレースで分析してください
• 依存関係の問題を特定してください
• 外れ値ホストを見つけてください

ログ検索

• 特定の時間帯のエラーログを検索してください
• サービス間の通信エラーを調査してください

📈 メトリクス・パフォーマンス分析

サービスメトリクス

• 特定のサービスのレイテンシーメトリクスを取得してください
• エラー率の推移を確認してください
• 過去1週間のパフォーマンス傾向を分析してください

🚨 障害分析・根本原因調査

インシデント対応

• デプロイ後の新しいエラーを調査してください
• サービス間依存関係の問題を特定してください
• S3への依存関係を監査してください
• Tier1サービスのクォータ使用量を確認してください

🕸️ Syntheticsカナリア分析

カナリア監視

• [カナリア名]のカナリア障害を分析してください
• カナリアの失敗パターンを調査してください

実際の質問例

• サービス全体の健全性チェック
  “すべてのサービスの健全性を監査してください”

• 特定サービスの詳細分析
  “payment-serviceのGETオペレーションのレイテンシー問題を根本原因分析してください”

• SLO違反の調査
  “昨日からのSLO違反を調査して根本原因を分析してください”

• パフォーマンス問題の特定
  “レスポンスタイムが遅いサービスを特定してエラーログを確認してください”

• 依存関係の問題調査
  “S3への接続問題があるサービスを特定してください”

以上

参考になれば幸いです。

本記事では、AWS VPC Lattice の Resource Gateway と、従来の Network Load Balancer (NLB) + VPC Endpoint Service + VPC Endpoint 構成について、コスト・セキュリティ・パフォーマンスの観点から詳細な比較分析を行います。

AWS Documentation MCP を利用し調査した結果です。

比較する構成

構成1: NLB + VPC Endpoint Service + VPC Endpoint

• Network Load Balancer
• VPC Endpoint Service
• VPC Endpoint

構成2: VPC Lattice Resource Gateway

• VPC Lattice Service
• Resource Gateway
• Resource Configuration

コスト比較

AWS Pricing APIを用いた2025年12月時点の料金調査結果に基づく比較です。

NLB + VPC Endpoint Service + VPC Endpoint

月額基本料金合計: 約 $59.40 + 使用量ベース料金

VPC Lattice Resource Gateway

月額基本料金合計: 約 $32.40 + データ処理費

コスト分析結果

• VPC Lattice の基本料金は約 45%安い
• データ処理費は VPC Lattice の方が2.5倍高い
• 低〜中程度のデータ転送量であれば VPC Lattice が有利

セキュリティ比較

セキュリティ分析結果

VPC Lattice は IAM統合による細かなアクセス制御 と 統合された監査ログ でセキュリティ面において優位性があります。

パフォーマンス比較

パフォーマンス分析結果

• レイテンシ: VPC Lattice が優位
• 柔軟性: NLB が多様なロードバランシングオプションで優位
• 総合: 用途により優位性が変わる

運用・管理比較

総合比較とメリット・デメリット

NLB + VPC Endpoint Service + VPC Endpoint

メリット

• ✅ 成熟した技術: 長期間の運用実績と安定性
• ✅ 既存インフラとの親和性: VPCベースの既存構成と自然に統合
• ✅ 豊富なロードバランシング機能: 複数のアルゴリズムとヘルスチェックオプション
• ✅ 詳細なネットワーク制御: セキュリティグループ、NACLによる細かな制御
• ✅ 豊富なドキュメント: 多くの事例と解決策が存在

デメリット

• 🤔 高い初期コスト: 基本料金が月額約$59.40
• 🤔 複雑な設定・管理: 複数コンポーネントの個別管理が必要
• 🤔 運用負荷: 複数サービスの監視・トラブルシューティング
• 🤔 レイテンシ: 複数ホップによる若干の遅延

VPC Lattice Resource Gateway

メリット

• ✅ 低い初期コスト: 基本料金が月額約$32.40（45%安い）
• ✅ シンプルな管理: 統合されたサービスによる一元管理
• ✅ 優れたIAM統合: サービス・リソースレベルでの細かなアクセス制御
• ✅ 統合監視: 一元化されたメトリクスとログ
• ✅ 低レイテンシ: 直接ルーティングによる高速通信
• ✅ マルチリージョン対応: Service Network での統一管理

デメリット

• 🤔 データ処理費: 高トラフィック時の従量課金（$0.025/GB）
• 🤔 機能制約: NLBほど柔軟なロードバランシングオプションがない

推奨シナリオ

VPC Lattice Resource Gateway を推奨する場合

🎯 以下の条件に当てはまる場合に最適:

• 新規システム構築
• シンプルな管理・運用を重視
• IAMによる細かなアクセス制御が重要
• データ転送量が中程度以下（月数TB程度）
• 運用コストを重視
• マルチリージョン展開を予定

NLB + VPC Endpoint を推奨する場合

🎯 以下の条件に当てはまる場合に最適:

• 既存VPCインフラとの整合性重視
• 高度なロードバランシング機能が必要
• 運用実績・安定性を最重視
• 非常に高いデータ転送量（月数十TB以上）
• 既存チームのNLB運用スキルを活用したい

実装時の考慮事項

移行戦略

• 段階的移行: 重要度の低いサービスから VPC Lattice へ段階的に移行
• ハイブリッド運用: 要件に応じて両方式を使い分け
• コスト監視: データ転送量の実測値に基づく定期的なコスト見直し

技術的考慮事項

• モニタリング設計: VPC Lattice の新しいメトリクスに対応した監視設計
• セキュリティポリシー: IAMポリシーベースのアクセス制御設計
• ディザスタリカバリ: Service Network の冗長性設計

まとめ

AWS VPC Lattice Resource Gateway は、従来のNLB+VPC Endpoint構成と比較して、コスト効率性・運用性・セキュリティ機能において優位性を持つ新しいソリューションです。

特に 新規システム構築 や シンプルな運用 を重視する場合には、VPC Lattice の採用を強く推奨します。一方、既存インフラとの整合性 や 運用実績 を重視する場合には、従来のNLB+VPC Endpoint構成も依然として有効な選択肢です。

最終的な選択は、システムの要件・制約・チームのスキルレベルを総合的に評価して決定することが重要です。

参考

AWS 公式ドキュメント

• Amazon VPC Lattice User Guide
• Elastic Load Balancing - Network Load Balancer
• VPC Endpoints - AWS PrivateLink
• AWS Pricing - VPC Lattice
• AWS Pricing - Elastic Load Balancing

AWS ブログ・技術記事

• Introducing Amazon VPC Lattice – Simplify Networking for Service-to-Service Communication
• Amazon VPC Lattice でマイクロサービス間の通信を簡単に

価格情報ソース

• AWS Price List API - 本分析で使用した料金データの取得元

本分析は2025年12月時点のAWS Pricing APIデータに基づいています。料金は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。

以上

参考になれば幸いです。

Performance Insights は 2026年6月30日にデプリケートされる予定です。

AWS has announced the end-of-life date for Performance Insights: June 30, 2026.

継続してパフォーマンスインサイト相当の機能を利用するには Performance Insights から CloudWatch Database Insights への移行する必要があります。

それぞれの機能差やコストについてまとめました。

モード比較

Database Insights には Standard と Advanced モードがあります。

Database Insights Standard VS Advanced モード機能比較表

共通機能（Standard & Advanced）

• ✅ DB Load の次元別分析
• ✅ データベースメトリクスのクエリ・グラフ化・アラート（7日間保持）
• ✅ SQL テキストなどの機密ディメンションへのアクセス制御

Advanced Mode 専用機能

重要な制限事項

エンジン依存機能

• SQLロック分析: Aurora PostgreSQL のみ
• 実行プラン分析: Aurora PostgreSQL、RDS Oracle、RDS SQL Server のみ
• オンデマンド分析: MySQL系、PostgreSQL系、Oracle のみ（SQL Server除く）

前提条件

1. Advanced Mode有効化: Performance Insights の有効化が必須
2. スロークエリ分析: CloudWatch Logs への出力設定が必要
3. 統合ダッシュボード: ログ出力設定が必要（ログ表示のため）
4. OSプロセス監視: Enhanced Monitoring の有効化が必要

地域制限

• すべてのAWSリージョンでAdvanced Mode機能が利用可能ではない

選択指針

Standard Mode が適している場合

• 基本的なDB監視で十分
• コストを抑えたい
• 7日間のデータ保持で十分

Advanced Mode が必要な場合

• フリート全体の一元監視が必要
• 長期的なトレンド分析（15ヶ月）が必要
• SQL実行プランやロック分析が必要
• アプリケーションとの統合監視が必要

まとめ

• Advanced Mode は高機能ですが、エンジン依存や前提条件があります。
• 最初は Standard モードで利用し、より詳細なボトルネック調査したい場合は Advanced に切り替えはアリ

組織の監視要件と対象エンジンを確認した上で適切なモードを選択してください。

参考

Database Insights

• CloudWatch Database Insights
• Monitoring Amazon RDS databases with CloudWatch Database Insights
• Considerations for Database Insights for Amazon RDS

料金情報

• Amazon CloudWatch Pricing
• Performance Insights Pricing

移行・比較情報 - AWS re:Post

• Transitioning from RDS Performance Insights to CloudWatch Database Insights
• Performance Insights to CloudWatch Database Insights

サードパーティ解説

• AWS Performance Insights has been deprecated: What to know about CloudWatch Database Insights - pganalyze
• Transitioning from RDS Performance Insights to CloudWatch Database Insights - DoiT

技術仕様 - パフォーマンス監視

• Performance Insights counter metrics
• Amazon CloudWatch metrics for Amazon RDS Performance Insights

Enhanced Monitoring

• Enhanced Monitoring for Amazon RDS

Aurora Serverless v2 を導入検討する際に Aurora RDS Cluster Instance の最低インスタンスクラスである db.t4g.medium がどの程度のキャパシティに相当するのか調査した内容をまとめます。

キャパシティ計算

db.t4g.medium スペック

• vCPU: 2
• メモリ: 4 GiB
• ACU相当: 2 ACU 👀✨

コスト比較 （ap-northeast-1、2025年12月1日現在）

利用料金の安い Aurora PostgreSQL Standard を前提とします。

RI は安いですが、スケーリングの管理は CloudWatch Alarm などで構成する必要があります。

Aurora PostgreSQL プロビジョンドインスタンス db.t4g.medium

• Aurora Standard: 0.113 USD / hour
• Aurora I/O 最適化: 0.147 USD / hour

Aurora Standard を 1年利用した場合

1
2

989.88 USD
= 0.113 USD / hour x 24 hour x 365 days

Reserved Instance を利用した場合

1

710 USD

Aurora PostgreSQL Serverless v2

• Aurora Standard: 0.15 USD / ACU / hour
• Aurora I/O 最適化: 0.20 USD / ACU / hour

Aurora Standard を 1年利用した場合

1
2

2,628 USD
= 2 ACU x 0.15 USD / ACU x 24 hours x 365 days / hour

以下時間をゼロキャパシティとなる見込みの場合 (3,920 時間/年間)

• 平日 23:00 - 07:00
• 土日祝

1
2

1,176 USD
= 2 ACU x 0.15 USD / ACU / hour x 3,920 hours

総評

Aurora Serverless を利用する際の一番のデメリットは実際のワークロードが読めず、意図せぬコスト増となり得ることが一つ要因としてあるかと思います。
その場合は実際のワークロードを想定した検証した上でコストメリットを計算できます。

スケーリングの管理に対する運用負荷が軽減されるメリットは非常に大きいのでこの点は採用するメリットとしては大きいのではないかと思います。

いずれにしても検証大事！

参考文献

• Using Aurora Serverless v2 - Amazon Aurora
• Hardware specifications for DB instance classes for Aurora
• Amazon Aurora Pricing

概要

AWS NAT Gatewayには従来のゾーナル（Zonal）モードに加えて、新しくリージョナル（Regional）モードが提供されました。

本記事では、AWS公式ドキュメントに基づいて両者の特徴、コスト比較、およびIPアドレス管理についてまとめます。

⚠️ 重要な注意事項

2025.11.26現在、 terraform-provider-aws はリージョナル NAT Gateway をサポートしていません。
issue: https://github.com/hashicorp/terraform-provider-aws/issues/45151

v6.24.0 でサポートされました🎉

リージョナル NAT Gateway のコスト優位性

基本的な料金体系はリージョナル、ゾーナルと同じ料金構造です。

• 時間単位料金: NAT Gatewayが利用可能な時間ごと
• データ処理料金: 処理されるデータ量（GB単位）

コスト削減のメカニズム

リージョナル NAT Gateway の方が、クロスAZ転送がない分、コスト削減できる可能性が高いです。

• ゾーナル設定の問題

  1 2 3

  AZ-1a: Private Subnet → NAT Gateway (AZ-1b) → Internet ↑ クロスAZデータ転送料金が発生

• リージョナル設定の利点

  1 2 3 4

  AZ-1a: Private Subnet → Regional NAT Gateway (自動的にAZ-1aに展開) AZ-1b: Private Subnet → Regional NAT Gateway (自動的にAZ-1bに展開) ↑ 各AZで処理され、クロスAZ転送を削減

運用コストの削減

ゾーナル設定：

• パブリックサブネットの作成・管理が必要
• 各AZ毎のルートテーブル設定
• 手動でのAZ拡張作業

リージョナル設定：

• パブリックサブネット不要
• 単一のルートテーブル設定
• 自動的なAZ拡張・縮小

⚠️ vpc module を利用している場合、パブリックサブネットを作成しない設定にすると Intenet Gateway が作成されません。

CloudFront VPC Origin を利用する場合、 Internet Gateway が必要なので注意が必要です。

コスト削減が期待できるケース

1. マルチAZ展開が頻繁な環境
2. クロスAZ通信が多い現在の設定
3. 複数のゾーナルNAT Gatewayを運用している場合
4. 運用の自動化によるオペレーショナルコスト削減を重視する場合

IPアドレス管理：固定IPの実現方法

外部サービス連携する際、外部サービス側でIP許可する為にこちらの出口IPを固定したい、という要件が時にあります。

リージョナル NAT Gateway でIPを固定する方法が2つあるので注意が必要です。

• 自動: IPが自動で割り当てられ、スケールする毎に変更する可能性があります。
• マニュアル: Elastic IP を固定で指定します。

既存IPアドレスの継承方法

AWS公式ドキュメントでは、既存のゾーナルNAT GatewayからIPアドレスを継承する方法も提供されています：

1
2
3
4
5
6
7

既存IPアドレスを再利用する手順:
1. 既存のゾーナルNAT Gatewayを削除してIPアドレスを解放
2. 解放されたIPアドレスを使用してリージョナルNAT Gatewayを作成
3. ルートテーブルをリージョナルNAT Gatewayに更新

注意: この方法では一時的にトラフィック断絶が発生するため、
      メンテナンスウィンドウでの実施を推奨

パフォーマンスと可用性の向上

自動高可用性

従来のゾーナル：

• 各AZで手動設定が必要
• 新AZ展開時に手動でNAT Gateway追加

リージョナル：

• ワークロードを検知して自動的にAZに展開
• 最大60分で新しいAZに展開完了
• 使用していないAZからは自動撤退

スケーラビリティの向上

今後、リージョナル NAT Gateway の優位性が高まっていきそうです♪

移行時の考慮事項

接続のリセット

重要な注意点：

AWS公式ドキュメントより：
これにより既存の接続がリセットされます。メンテナンスウィンドウ内でこれらの手順を完了することをお勧めします。

移行戦略

戦略A: 新しいIPアドレスでの移行

1
2
3
4
5
6

1. 新しいリージョナルNAT Gateway作成
2. ルートテーブル更新
3. 古いゾーナルNAT Gateway削除

メリット: シンプル
デメリット: IPアドレス変更

戦略B: 既存IPアドレス保持移行

1
2
3
4
5
6

1. 既存ゾーナルNAT Gateway削除（IP解放）
2. 解放されたIPでリージョナルNAT Gateway作成
3. ルートテーブル更新

メリット: IPアドレス保持
デメリット: 一時的な通信断絶

監視と運用

CloudWatchメトリクス

リージョナルNAT Gatewayでは従来のメトリクスに加えて：

• AZ別のトラフィック分析
• 自動拡張イベントの監視
• ポート枯渇の早期検知

推奨事項とベストプラクティス

リージョナルNAT Gatewayが推奨されるケース

✅ 推奨

• マルチAZ環境での新規構築
• 複数のゾーナルNAT Gatewayを運用中
• 運用自動化を重視
• クロスAZ通信が多い環境

❌ 非推奨

• プライベートNAT Gateway機能が必要
• 単一AZでの小規模システム

IPアドレス管理の選択指針

まとめ

リージョナルNAT Gatewayは、従来のゾーナルNAT Gatewayと比較して：

コスト面：

• クロスAZデータ転送料金の削減
• 運用コストの削減
• 複数NAT Gateway統合によるコスト最適化

運用面：

• 自動的な高可用性
• 管理の簡素化
• AZ拡張の自動化

IPアドレス管理：

• Manualモードで固定IP実現可能
• 既存IPアドレスの継承も可能
• セキュリティ要件にも対応

特に、複数のゾーナルNAT Gatewayを運用している環境では、リージョナルNAT Gatewayへの移行により大幅なコスト削減と運用効率化が期待できます。

現在の推奨アプローチ：

• 既存Terraformプロジェクト: ゾーナルNAT Gatewayで継続運用、Terraformサポート開始を待つ
• 新規プロジェクト: AWS CLIでRegional NAT Gateway作成、将来的にTerraform管理に移行
• コスト重視: 今すぐにでもRegional NAT Gatewayへの移行を検討

移行を検討する際は、現在の通信パターンと外部システムとの連携要件を十分に分析し、適切なモード（AutomaticまたはManual）を選択することが重要です。

参考リンク

• AWS NAT Gateway Documentation
• Regional NAT Gateway Documentation
• AWS CLI NAT Gateway Commands
• Terraform AWS Provider - NAT Gateway

このドキュメントはAWS公式ドキュメントおよびTerraform Providerの調査に基づいて作成されており、最新の情報については公式ドキュメントを参照してください。TerraformサポートのタイムラインについてはHashiCorpのロードマップをご確認ください。

事前準備

• uv 導入

1

curl -LsSf https://astral.sh/uv/install.sh | sh

• awsume で MFA 付き profile 作成
  • 複数の profile も --output-profile claude にすることで一時的なprofile名を claude に統合できる⭐️

1

awsume dummy --output-profile claude

Claude Code + AWS MCP で接続先 AWS アカウント ID 確認

1
2
3
4
5

claude mcp add -s user aws-mcp \
  -e AWS_PROFILE="claude" \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx mcp-proxy-for-aws@latest https://aws-mcp.us-east-1.api.aws/mcp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

⏺ AWS CLI機能を使用してAWSアカウントIDを取得します。

⏺ aws-mcp - aws___call_aws (MCP)(cli_command: "aws sts get-caller-identity")
  ⎿  {
       "response": {
         "status_code": 200,
     … +14 lines (ctrl+o to expand)

⏺ AWSアカウント情報を取得しました：

  AWSアカウントID: 123456789012

  詳細情報:
  - ユーザーID: ABCDEFGHIJKLMNOPQRSTU:kenzo.tanaka
  - ARN: arn:aws:sts::123456789012:assumed-role/admin/kenzo.tanaka
  - ロール: admin

  現在は管理者権限のロールでAWSアカウント 123456789012 にアクセスしています。

Claude Code + CloudWatch Logs MCP　でログ調査

2025年10月13日は非推奨となりました。
https://pypi.org/project/awslabs.cloudwatch-logs-mcp-server/

awslabs.cloudwatch-mcp-server への切り替えが推奨されております。

1
2
3
4
5

claude mcp add -s user aws-cwlogs \
  -e AWS_PROFILE="claude" \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.cloudwatch-logs-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

claude

> ロググループの一覧を出して

> ⏺ AWSのCloudWatchロググループの一覧を取得しますね。

⏺ Bash(aws logs describe-log-groups --query 'logGroups[*].[logGroupName,creationTime,storedBytes]' --outpu
t table)
  ⎿  -----------------------------------------------------------------------------------------
     |                                   DescribeLogGroups                                   |
     +---------------------------------------------------------+----------------+------------+
     … +28 lines (ctrl+o to expand)

⏺ CloudWatchロググループの一覧を取得しました。以下の情報が表示されています：

  ロググループ概要

  | ロググループ名                                                | 作成時刻          | 保存容量(bytes) |
  |--------------------------------------------------------|---------------|-------------|
  | /aws/codebuild/dummy-build-ecrm                    | 1762390572331 | 4,150       |
  | /aws/ecs/autoscaling/dummy-app                     | 1762996301329 | 0           |
  | /aws/ecs/containerinsights/dummy-main/performance | 1756366249199 | 0           |
  | /aws/rds/cluster/dummy-cluster/postgresql         | 1756195223282 | 10,705,811  |
  | RDSOSMetrics                                           | 1756195285485 | 53,837,909  |

  その他、CodeBuildやECSのアプリケーション固有のロググループも複数存在しています。

  最も容量が大きいのはRDSOSMetrics（約51MB）で、次に/aws/rds/cluster/dummy-cluster/postgresql（約10MB
）となっています。

Claude Code + Cost Explorer MCP　でコスト調査

1
2
3
4
5

claude mcp add -s user aws-ce \
  -e AWS_PROFILE="claude" \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.cost-explorer-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

claude

> aws-ce MCPを使って AWSアカウント 123456789012 の先月の料金は？

⏺ AWS アカウント 123456789012 - 2025年10月の料金

  合計料金: $246.06

  サービス別内訳（上位項目）

  | サービス                               | 料金（USD） |
  |------------------------------------|---------|
  | Amazon Relational Database Service |  $87.08 |
  | EC2 - Other                        |  $50.54 |
  | Tax（税金）                            |  $22.36 |
  | Amazon Elastic Load Balancing      |  $18.08 |
  | Amazon Inspector                   |  $16.64 |
  | Amazon CloudWatch                  |  $12.65 |
  | AWS WAF                            |   $9.00 |
  | AWS Key Management Service         |   $8.00 |
  | CodeBuild                          |   $4.06 |
  | Amazon Virtual Private Cloud       |   $3.72 |
  | Amazon Elastic Container Service   |   $3.60 |
  | Amazon GuardDuty                   |   $3.19 |
  | AWS CodePipeline                   |   $2.23 |

  主要コスト要因

  1. RDS（$87.08） - 最大のコスト要因
  2. EC2 - Other（$50.54） - EC2関連の追加コスト
  3. ELB（$18.08） - ロードバランサー
  4. セキュリティサービス - Inspector（$16.64）、GuardDuty（$3.19）、Security Hub（$1.28）

  税金を除いた実際のAWSサービス利用料金は $223.70 でした。

Claude Code + AWS Pricing MCP　で料金確認

1
2
3
4

claude mcp add -s user aws-price \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.aws-pricing-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

claude

> aws-price MCP を利用し Aurora Serverless v2 と db.t4g.medium 2台で 1年全額前払いのリザーブドインスタンスだとどちらが安いか損益分岐点を求めてください。

  前提条件・料金設定

  Aurora Serverless v2（東京リージョン）

  - ACU料金: $0.15/時間（2024年11月値下げ後）
  - 最小容量: 0.5 ACU
  - スケール範囲: 0.5〜128 ACU
  - ストレージ: $0.10/GB月（別途課金）

  Aurora PostgreSQL Reserved Instance - db.t4g.medium（東京リージョン）

  - スペック: 2 vCPU、4GB RAM
  - On-Demand料金: 約$0.09/時間（東京リージョン推定）
  - Reserved Instance（1年、No Upfront）: 約$0.063/時間（30%割引）
  - Reserved Instance（3年、All Upfront）: 約$0.031/時間（65%割引）
  - 2インスタンス: Writer 1台 + Reader 1台

  月額コスト比較

  Aurora Serverless v2 使用量別コスト

  | 平均ACU   | 月額コスト | 想定リソース使用量      |
  |---------|-------|----------------|
  | 0.5 ACU | $54   | 軽負荷（1GB RAM相当） |
  | 1.0 ACU | $108  | 中負荷（2GB RAM相当） |
  | 1.5 ACU | $162  | 高負荷（3GB RAM相当） |
  | 2.0 ACU | $216  | 高負荷（4GB RAM相当） |
  | 3.0 ACU | $324  | 負荷集中時          |

  Aurora PostgreSQL Reserved Instance（2台）コスト

  | 契約タイプ          | 月額コスト | 備考                        |
  |----------------|-------|---------------------------|
  | 1年 No Upfront  | $90.7 | ($0.063 × 2台 × 24h × 30日) |
  | 3年 All Upfront | $44.6 | ($0.031 × 2台 × 24h × 30日) |

  損益分岐点分析

  1年契約 Reserved Instance（$90.7/月）との比較

  損益分岐点: 0.84 ACU/月平均
  - Aurora Serverless v2が有利：平均0.84 ACU未満
  - Reserved Instanceが有利：平均0.84 ACU以上

  3年契約 Reserved Instance（$44.6/月）との比較

  損益分岐点: 0.41 ACU/月平均
  - Aurora Serverless v2が有利：平均0.41 ACU未満
  - Reserved Instanceが有利：平均0.41 ACU以上

  使用パターン別シナリオ

⏺ シナリオ1: 開発・テスト環境

  使用パターン: 平日9-18時のみ稼働（40%稼働率）
  - Serverless v2: 0.5 ACU × 0.4 = 平均0.2 ACU → $21.6/月
  - 1年RI: $90.7/月（常時課金）
  - 結果: Serverless v2が約70%安い

  シナリオ2: 変動負荷本番環境

  使用パターン: 夜間0.5 ACU、日中1.5 ACU（平均0.8 ACU）
  - Serverless v2: 平均0.8 ACU → $86.4/月
  - 1年RI: $90.7/月
  - 結果: Serverless v2がわずかに安い

  シナリオ3: 安定負荷本番環境

  使用パターン: 常時1.2 ACU程度の負荷
  - Serverless v2: 1.2 ACU → $129.6/月
  - 1年RI: $90.7/月
  - 結果: Reserved Instanceが30%安い

  シナリオ4: 高負荷本番環境

  使用パターン: 常時2.0 ACU程度の負荷
  - Serverless v2: 2.0 ACU → $216/月
  - 3年RI: $44.6/月
  - 結果: Reserved Instanceが79%安い

  リソース使用量の目安

  db.t4g.medium（4GB RAM）との等価性

  - 1 ACU ≈ 2GB RAM → db.t4g.medium ≈ 2 ACU
  - db.t4g.mediumと同等の処理能力には約2 ACUが必要

  実際のワークロード対応

  - 軽負荷: 0.5-1.0 ACU（開発環境、小規模アプリ）
  - 中負荷: 1.0-2.0 ACU（通常のWebアプリケーション）
  - 高負荷: 2.0+ ACU（大規模アプリケーション、分析処理）

  追加コスト要素

  Serverless v2の注意点

  - CPU Credits: T4gインスタンスのCPU Credits（$0.09/vCPU時間）はない
  - I/O Cost: 含まれる（Aurora Standardの場合）
  - スケール遅延: 負荷変動時の数十秒のスケール時間

  Reserved Instanceの注意点

  - CPU Credits: $0.09/vCPU時間の追加料金（バースト時）
  - 固定コスト: 使用量に関係なく固定課金
  - 柔軟性: サイズ変更はInstance Family内で可能

  推奨判断基準

⏺ Aurora Serverless v2を選ぶべき場合

  1. 開発・テスト環境（非稼働時間が多い）
  2. 変動負荷（平均0.8 ACU未満）
  3. 予測困難な負荷パターン
  4. 運用開始初期（負荷が見えない段階）
  5. 短期プロジェクト（1年未満）

  Aurora PostgreSQL Reserved Instanceを選ぶべき場合

  1. 安定した本番環境（平均1.0 ACU以上）
  2. 予測可能な負荷
  3. 長期運用確定（1年以上）
  4. コスト最適化重視
  5. CPU集約的ワークロード

  まとめ

  損益分岐点

  - 1年RI: 平均0.84 ACU（約1.7GB RAM使用量）
  - 3年RI: 平均0.41 ACU（約0.8GB RAM使用量）

  実用的な選択指針

  1. 月間平均メモリ使用量 < 1.5GB → Serverless v2
  2. 月間平均メモリ使用量 > 3GB → Reserved Instance
  3. 1.5-3GBの範囲 → 負荷変動パターンで判断

  重要な考慮事項

  - Reserved Instanceは3年契約で最大79%の節約
  - Serverless v2は運用柔軟性で優位
  - 実際のワークロード測定が最も重要な判断材料

  2024年11月の値下げにより、Aurora Serverless v2の競争力が大幅に向上し、中負荷環境でもReserved
  Instanceと遜色ないコストパフォーマンスを実現しています。

Claude Code + AWS Documentation MCP　でドキュメント参照

1
2
3
4

claude mcp add -s user aws-docs \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.aws-documentation-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107

claude

> aws-docs MCP を使って CloudFront 署名付きURLで S3 Object を参照させる際の
CloudFront の設定を教えて

⏺ CloudFrontで署名付きURLを使ってS3オブジェクトを参照させる設定について、AWS
  公式ドキュメントを基にまとめます。

  CloudFront 署名付きURL + S3 オリジンの設定

  1. Origin Access Control (OAC) の設定

  S3バケットポリシーの設定
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowCloudFrontServicePrincipalReadOnly",
        "Effect": "Allow",
        "Principal": {
          "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::your-bucket-name/*",
        "Condition": {
          "StringEquals": {
            "AWS:SourceArn":
  "arn:aws:cloudfront::YOUR-ACCOUNT-ID:distribution/DISTRIBUTION-ID"
          }
        }
      }
    ]
  }

  2. Trusted Key Groups の設定

  公開鍵/秘密鍵ペアの作成
  - RSA 2048またはECDSA 256キーをサポート
  - CloudFrontコンソールまたはAPIでキーグループを作成
  - 公開鍵をキーグループに追加

  3. CloudFront Distribution の設定

  Cache Behavior の設定
  - 署名が必要なパスパターンを設定
  - Trusted Key Groupを指定
  - Origin Access Controlを有効化

  重要な設定項目
  - Origin Access Control: "Sign requests (recommended)" を選択
  - Viewer Protocol Policy: HTTPSの使用を推奨
  - Trusted Key Groups: 署名に使用するキーグループを指定

  4. 署名付きURLの生成

  Canned Policy と Custom Policy の選択

  | 機能          | Canned Policy | Custom Policy |
  |-------------|---------------|---------------|
  | 複数ファイルでの再利用 | ✗             | ✓             |
  | アクセス開始時刻の指定 | ✗             | ✓             |
  | IPアドレス制限    | ✗             | ✓             |
  | URL長        | 短い            | 長い（ポリシー含有）    |

  URLフォーマット例
  https://d1234567890.cloudfront.net/private-content.jpg?Policy=eyJ...&Signa
  ture=abc...&Key-Pair-Id=K1234567890

  5. セキュリティ考慮事項

  必須設定
  - S3バケットへの直接アクセスを制限
  - Origin Access Control (OAC) の使用（OAIより推奨）
  - HTTPS通信の強制
  - 適切な有効期限の設定

  SSE-KMS使用時の追加設定
  KMSキーポリシーにCloudFrontアクセス許可を追加：
  {
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
      "Service": ["cloudfront.amazonaws.com"]
    },
    "Action": [
      "kms:Decrypt",
      "kms:Encrypt",
      "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn":
  "arn:aws:cloudfront::YOUR-ACCOUNT-ID:distribution/DISTRIBUTION-ID"
      }
    }
  }

  6. 実装フロー

  1. ユーザー認証: アプリケーションでユーザーの権限を確認
  2. 署名付きURL生成: 秘密鍵を使用してURLに署名
  3. URLの提供: 認証済みユーザーに署名付きURLを返却
  4. コンテンツアクセス:q
  CloudFrontが署名を検証し、有効な場合のみS3からコンテンツを配信

  この設定により、S3オブジェクトへの安全なアクセス制御が実現できます。

Claude Code + AWS Terraform MCP で実装

1
2
3
4

claude mcp add -s user aws-terraform-provider \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.terraform-mcp-server@latest

Claude Code + AWS Diagram MCP で簡易的な構成図を書かせる

1
2
3
4

claude mcp add -s user aws-diagram \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.aws-diagram-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   AZ-1a         │    │   AZ-1b         │    │   AZ-1c         │
│ ┌─────────────┐ │    │ ┌─────────────┐ │    │ ┌─────────────┐ │
│ │Public Subnet│ │    │ │Public Subnet│ │    │ │Public Subnet│ │
│ │             │ │    │ │             │ │    │ │             │ │
│ │ NAT Gateway │ │    │ │ NAT Gateway │ │    │ │ NAT Gateway │ │
│ │   (1a)      │ │    │ │   (1b)      │ │    │ │   (1c)      │ │
│ └─────────────┘ │    │ └─────────────┘ │    │ └─────────────┘ │
│ ┌─────────────┐ │    │ ┌─────────────┐ │    │ ┌─────────────┐ │
│ │Private Sub  │ │    │ │Private Sub  │ │    │ │Private Sub  │ │
│ │             │ │    │ │             │ │    │ │             │ │
│ │ Resources   │ │    │ │ Resources   │ │    │ │ Resources   │ │
│ └─────────────┘ │    │ └─────────────┘ │    │ └─────────────┘ │
└─────────────────┘    └─────────────────┘    └─────────────────┘

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

┌─────────────────────────────────────────────────────────────────┐
│                        Regional NAT Gateway                     │
│              ┌─────────────────────────────────────────┐        │
│              │         Automatic Expansion             │        │
│              │    ┌──────┐  ┌──────┐  ┌──────┐         │        │
│              │    │ AZ-1a│  │ AZ-1b│  │ AZ-1c│         │        │
│              │    │ NAT  │  │ NAT  │  │ NAT  │         │        │
│              │    └──────┘  └──────┘  └──────┘         │        │
│              └─────────────────────────────────────────┘        │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   AZ-1a         │    │   AZ-1b         │    │   AZ-1c         │
│ ┌─────────────┐ │    │ ┌─────────────┐ │    │ ┌─────────────┐ │
│ │Private Sub  │ │    │ │Private Sub  │ │    │ │Private Sub  │ │
│ │             │ │    │ │             │ │    │ │             │ │
│ │ Resources   │ │    │ │ Resources   │ │    │ │ Resources   │ │
│ └─────────────┘ │    │ └─────────────┘ │    │ └─────────────┘ │
└─────────────────┘    └─────────────────┘    └─────────────────┘

Claude Code + AWS CloudWatch + AWS Application Signals MCP で雑に直近のインシデントを知る

1
2
3
4
5
6
7
8
9
10
11

claude mcp add -s user aws-cw \
  -e AWS_PROFILE="claude" \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.cloudwatch-mcp-server@latest

claude mcp add -s user aws-appsignals \
  -e AWS_PROFILE="claude" \
  -e AWS_REGION="ap-northeast-1" \
  -e FASTMCP_LOG_LEVEL="ERROR" \
  -- uvx awslabs.cloudwatch-appsignals-mcp-server@latest

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

AWS Application Signalsの調査により、以下の状況が確認されました：

🚨 検出された問題

dummy-backend サービスで高レイテンシを検出

1. GET /health エンドポイント
  - 現在のレイテンシ: 55.82ms（p99）
  - 正常ベースライン: 1.58ms
  - 重要度: HIGH
  - 問題: 通常の35倍以上のレイテンシ
2. InternalOperation
  - 現在のレイテンシ: 843.38ms（p99）
  - 正常ベースライン: 281.20ms
  - 重要度: HIGH
  - 問題: 通常の3倍のレイテンシ

📊 監視状況

- 監視対象サービス: 8つ
- SLO設定: 現在未設定
- 期間: 過去24時間

💡 推奨アクション

1. 即座の対応
  - dummy-backendサービスのパフォーマンス調査
  - ヘルスチェックエンドポイントの応答遅延原因特定
2. 中期的対応
  - SLOの設定を検討（現在未設定）
  - アプリケーションログの詳細分析

現在進行中のインシデントとして、ステージング環境のバックエンドサービスでレイテンシ問題が発生していることが確認されました。

適宜追加していきます。

以上

参考になれば幸いです。

とはいえ、Iceberg format-version=3 としてデータを保存し利用はできます。

Athena でクエリ実行できない等の問題こそありますが、format-version=3 として利用はでき、テーブル v3 スペックの恩恵 を受けることができます。

AWS Glue テーブルを Iceberg v3 format で管理し、 Databricks 等の SaaS でデータを参照するような運用をしている場合には大きなパフォーマンスの向上が見込めます。

ですが、 AWS Glue テーブルの最適化機能は format-version=3 の場合、エラーとなります。

その為、Glue Job で Spark SQL 等でテーブル最適化を実施する必要があります。

以下実施例です。

Glue Job Python スクリプト例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from pyspark.context import SparkContext
from awsglue.context import GlueContext
from datetime import datetime

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session

database = 'example'
table = 'dummy'

table_full = f'glue_catalog.`{database}`.`{table}`'

target_file_size_bytes = 268435456 # 256MB

# Rewrite Data Files（コンパクション）
spark.sql(f"""
    CALL glue_catalog.system.rewrite_data_files(
        table => '{table_full}',
        options => map('target-file-size-bytes','{target_file_size_bytes}')
    )
""")

# expire_snapshots（古いスナップショットを削除、最後の3つは保持）
older_than = datetime.now().isoformat()
spark.sql(f"""
    CALL glue_catalog.system.expire_snapshots(
        table => '{table_full}',
        older_than => timestamp'{older_than}',
        retain_last => {snapshot_retain}
    )
""")

# remove_orphan_files（不要ファイル削除）
spark.sql(f"CALL glue_catalog.system.remove_orphan_files(table => '{table_full}')")

Glue マネージメント最適化機能と同等の以下を Glue Job Python スクリプトで実施しています。

• Compaction
• Snapshot retention
• Orphan file deletion

Glue Job 設定

Iceberg テーブル v3 スペックを利用するには iceberg-spark の 1.10.0 以上のバージョンである必要があります。

1. iceberg-spark-runtime-3.5_2.12-1.10.0.jar を S3 にアップロードします。
2. Job parameters に --extra-jars でアップロードされたファイルの S3 URI を指定
3. Job parameters の Spark Conf の設定に --conf spark.jars.packages=org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.10.0 を追加
   • Spark Conf の設定をスクリプト中に記載している場合はそちらに追加してください。
4. Job parameters --user-jars-first を true を追加

参考: カスタム Iceberg バージョンの使用

以上で Glue Job で Iceberg テーブル v3 スペックが利用できます。

最適化されているかの確認

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Rewrite Data Files（コンパクション）
df_rewrite_data_files = spark.sql(f"""
    CALL glue_catalog.system.rewrite_data_files(
        table => '{table_full}',
        options => map('target-file-size-bytes','{target_file_size_bytes}')
    )
""")
df_rewrite_data_files.show(truncate=False)

# expire_snapshots（古いスナップショットを削除、最後の3つは保持）
older_than = datetime.now().isoformat()
df_expire_snapshots = spark.sql(f"""
    CALL glue_catalog.system.expire_snapshots(
        table => '{table_full}',
        older_than => timestamp'{older_than}',
        retain_last => {snapshot_retain}
    )
""")
df_expire_snapshots.show(truncate=False)

# remove_orphan_files（不要ファイル削除）
df_remove_orphan_files = spark.sql(f"CALL glue_catalog.system.remove_orphan_files(table => '{table_full}')")
df_remove_orphan_files.show(truncate=False)

各最適化実行 Spark SQL の戻り値が DataFrame なので、その中身を表示することでどのファイルが削除されたかなどがわかります。

metadata が保存されている S3 Object から確認してみる

S3 に保存されているテーブルのメタデータ (<table>/metadata/*.metadata.json) から確認できます。

Iceberg は内部で metadata ディレクトリに JSON ファイルを置きます。

1
2
3
4

metadata/
  00000-...-metadata.json
  00001-...-metadata.json
  00002-...-metadata.json

• Iceberg はテーブル操作（INSERT, DELETE, COMPACT など）毎に新しい metadata.json を作成する
• 番号が大きいほど最新

この metadata.json がテーブルのその時々の情報を記載しているのでそちらを参考にすることで最適化されているかがわかります。

Compaction　（コンパクション） が実施されているかの確認

以下に metadata.json の例を記載しています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

...
  "snapshots": [
    {
      "sequence-number": 10,
      "snapshot-id": 3823535076387391090,
      "timestamp-ms": 1761614061870,
      "summary": {
        "operation": "append",
        "spark.app.id": "spark-application-1761613983390",
        "added-data-files": "20",
        "added-records": "208126",
        "added-files-size": "29693801",
        "changed-partition-count": "1",
        "total-records": "208126",
        "total-files-size": "29693801",
        "total-data-files": "20",
        "total-delete-files": "0",
        "total-position-deletes": "0",
        "total-equality-deletes": "0",
        "engine-version": "3.5.4-amzn-0",
        "app-id": "spark-application-1761613983390",
        "engine-name": "spark",
        "iceberg-version": "Apache Iceberg 1.10.0 (commit 2114bf631e49af532d66e2ce148ee49dd1dd1f1f)"
      },
      "manifest-list": "s3://bucket/example/table/metadata/snap-3823535076387391090-1-3fc712b9-127d-448c-85b4-34726177a6f6.avro",
      "schema-id": 0,
      "first-row-id": 1873029,
      "added-rows": 208126
    },
    {
      "sequence-number": 11,
      "snapshot-id": 4745314978435154844,
      "parent-snapshot-id": 3823535076387391090,
      "timestamp-ms": 1761614075392,
      "summary": {
        "operation": "replace",
        "added-data-files": "1",
        "deleted-data-files": "20",
        "added-records": "208126",
        "deleted-records": "208126",
        "added-files-size": "28252807",
        "removed-files-size": "29693801",
        "changed-partition-count": "1",
        "total-records": "208126",
        "total-files-size": "28252807",
        "total-data-files": "1",
        "total-delete-files": "0",
        "total-position-deletes": "0",
        "total-equality-deletes": "0",
        "engine-version": "3.5.4-amzn-0",
        "app-id": "spark-application-1761613983390",
        "engine-name": "spark",
        "iceberg-version": "Apache Iceberg 1.10.0 (commit 2114bf631e49af532d66e2ce148ee49dd1dd1f1f)"
      },
      "manifest-list": "s3://bucket/example/table/metadata/snap-4745314978435154844-1-58626d07-e3ea-4638-a263-cea54a49101f.avro",
      "schema-id": 0,
      "first-row-id": 2081155,
      "added-rows": 208126
    }
  ],

sequence-number が大きいほど最新です。

コンパクション後は operation が replace or rewrite となります。

• total-data-files が 20 → 1 となっておりファイル数が削減されている
• total-files-size が 29693801 → 28252807 となっており、ほぼ同じ
• deleted-data-files (削除したデータファイル) が 20
• removed-files-size (削除したファイルサイズ) が 29693801 で sequence-number=10 の管理ファイルサイズと同じ

以上から総ファイルサイズはほぼ変わらず、以前のデータがまるまる削除され、新たに 1 つのファイルを生成していることがわかります。
問題なくコンパクションできているようです。

※ Databricks では DESCRIBE HISTORY クエリがサポートされており、テーブルへの操作履歴を確認できるのでそちらから確認も可能です。

以上

参考になれば幸いです。

ですが、
圧縮形式 zstd の parquet は s3 select 未サポート (2024.10.05 時点) なので、
parquet を解析したい場合、macOS ローカルにダウンロードし、解析するなりが必要です。

現時点 2025.10.03 では、 Iceberg format-versoin=3 では、 Athena からクエリ実行することもできません。

parquet-cli を利用しデータの内容を確認する必要があったので備忘録として残します。

parquet-cli 導入 & 簡易的な使い方

1
2
3
4
5
6
7
8
9
10

brew install parquet-cli

// スキーマ情報確認
parquet schema xxx.parquet

// 全データ表示
parquet cat xxx.parquet

// 最初の数件を表示
parquet head -n 10 xxx.parquet

SaaS への見積もりで流入量が必要だったので、スクリプトで試算した数値と合わせてスクリプトも提出した所、概ね問題ないことを確認いただけました。

流入量・流出量はコスト見積もりの要でしたが、試算方法がわからず苦戦していたので一助になればと思います。

背景

CDC（Change Data Capture）は、データベースの変更をリアルタイムでキャプチャして他のシステムに配信する技術です。

AWS MSK, Confluent などの SaaS 等、 CDC サービスを利用する際、適切な容量計画が重要になります。

しかし、Aurora の WriteThroughput メトリクスがそのまま CDC スループットになるわけではありません。

エンジン固有のオーバーヘッドを考慮した正確な推定が必要です。

ツール概要

本ツールは、Aurora MySQL / PostgreSQL クラスターの CDC スループットを CloudWatch メトリクスから算出するシェルスクリプトを Claude Code と壁打ちしながら作成しました。

主な特徴

• エンジン別最適化: MySQL と PostgreSQL それぞれに特化した係数を使用
• インタラクティブ操作: 複数クラスターから対象を選択可能
• 包括的メトリクス: WriteThroughput、WriteIOPS、ログ使用量を総合的に分析
• 容量計画対応: ピーク値と平均値の両方を提供

技術仕様

Aurora MySQL 分析 (aurora-mysql.sh)

https://gist.github.com/kenzo0107/610df8182f47476e263bc080d164e840

主要メトリクス:

• WriteThroughput（クラスター・インスタンスレベル）
• WriteIOPS（クラスター・インスタンスレベル）
• BinLogDiskUsage（MySQL固有）

CDC 計算式:

1

CDC throughput = WriteThroughput × 0.576

MySQL の binlog フォーマットとレプリケーションオーバーヘッドを考慮した係数です。

0.576 という係数は複数の Aurora MySQL で 実際のCDCスループット / WriteThroughputメトリクス から求められた値です。

今後 Engine バージョンが変更された際にはまた異なる可能性はあります。

Aurora PostgreSQL 分析 (aurora-postgresql.sh)

https://gist.github.com/kenzo0107/1cb26379891ee8b14773609367d5c81e

主要メトリクス:

• WriteThroughput（クラスター・インスタンスレベル）
• WriteIOPS（クラスター・インスタンスレベル）
• TransactionLogsDiskUsage（WAL使用量）

CDC 計算式:

1

CDC throughput = WriteThroughput × 0.8

PostgreSQL の WAL（Write-Ahead Log）オーバーヘッドを考慮した係数です。

こちらの係数も同様の試算方法です。

使用方法

実行例

1
2
3
4
5

# Aurora MySQL クラスターの分析
./aurora-mysql.sh

# Aurora PostgreSQL クラスターの分析
./aurora-postgresql.sh

出力例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

=== Aurora MySQL CDC Analysis ===

Cluster: production-mysql-cluster
Writer Instance: production-mysql-cluster-writer

=== Metrics Summary (Past 7 days) ===

Cluster WriteThroughput:
  Maximum: 24,584,000 bytes/sec
  Average: 32,674 bytes/sec

Writer Instance WriteThroughput:
  Maximum: 24,584,000 bytes/sec
  Average: 65,348 bytes/sec

BinLog Disk Usage (Max): 2,147,483,648 bytes

=== CDC Throughput Estimates ===

Based on Cluster WriteThroughput:
  Peak CDC    : 14,160,505 bytes/sec (113.284 Mbps)
  Average CDC : 18,818 bytes/sec (0.151 Mbps)

Based on Writer Instance WriteThroughput:
  Peak CDC    : 14,160,505 bytes/sec (113.284 Mbps)
  Average CDC : 37,637 bytes/sec (0.301 Mbps)

実装のポイント

エンジン固有の最適化

MySQL (係数: 0.576)

• binlog のバイナリフォーマット
• レプリケーション時の圧縮効果
• イベントヘッダーのオーバーヘッド

PostgreSQL (係数: 0.8)

• WAL の物理ログ構造
• 論理レプリケーション時の変換コスト
• チェックサム・メタデータのオーバーヘッド

容量計画への活用

1. Confluent Cloud の設定指針

スループット設定:

• 最大値: ピーク CDC × 1.2〜1.5（安全マージン）
• 平均値: CDC パフォーマンス監視のベースライン

パーティション数:

1

Required partitions = Peak CDC throughput / 10 MB/s per partition

2. PostgreSQL 固有の設定

1
2
3
4
5
6
7
8

-- 論理レプリケーション有効化
ALTER SYSTEM SET rds.logical_replication = 1;

-- WAL キャッシュサイズ調整
ALTER SYSTEM SET rds.logical_wal_cache = '64MB';

-- 設定反映
SELECT pg_reload_conf();

まとめ

AWS Aurora の CloudWatch Metrics から CDC スループット推定が可能になりました。

エンジン固有の係数を使用することで、ストリーミングサービス流入量の容量計画がより正確に実施できます。

主な利点:

• 正確性: 実測値に基づく係数による高精度な推定
• 効率性: CloudWatch API を活用した自動化
• 実用性: 容量計画に直接活用できる形式での出力

このツールを活用することで、CDC パイプラインの安定運用と適切なリソース配分を実現できます。

以上

参考になれば幸いです。

概要

このスクリプトは以下の機能を提供します：

• awsume -l でプロファイル一覧を取得
• peco でインタラクティブに選択
• 選択されたプロファイルで awsume を実行してスイッチロール

前提条件

以下のツールがインストールされている必要があります：

• awsume: AWS プロファイル管理ツール
• peco: コマンドライン選択ツール
• ~/.aws/credentials にプロファイルが設定済み

インストール

1
2
3
4
5

# awsume のインストール (例: pip経由)
pip install awsume

# peco のインストール (例: Homebrew経由)
brew install peco

スクリプトの実装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#!/bin/bash

# awsume-switcher.sh
# AWS プロファイル切り替えスクリプト

# 必要なコマンドの存在チェック
command -v awsume >/dev/null 2>&1 || { echo "awsume is not installed"; exit 1; }
command -v peco >/dev/null 2>&1 || { echo "peco is not installed"; exit 1; }

# プロファイル一覧を取得してフィルタリング
PROFILE=$(awsume -l 2>/dev/null | \
  grep -v "^default$" | \
  grep -v "^==================================AWS" | \
  grep -v "PROFILE" | \
  grep -v "^$" | \
  grep -v "^----" | \
  peco)

# 選択がキャンセルされた場合
if [ -z "$PROFILE" ]; then
  echo "プロファイル選択がキャンセルされました"
  exit 0
fi

# 選択されたプロファイルで awsume を実行
echo "プロファイル '$PROFILE' に切り替えます..."
awsume "$PROFILE"

使用方法

1
2

# スクリプトを実行
./awsume-switcher.sh

実行すると、設定されているプロファイルの一覧が表示され、矢印キーで選択、Enterで確定できます。

機能の詳細

フィルタリング機能

以下の項目は自動的にリストから除外されます：

• default プロファイル
• ヘッダー行（==================================AWS など）
• PROFILE 文字列を含む行
• 空行
• ダッシュ行（---- など）

エラーハンドリング

• 必要なコマンドの存在チェック
• プロファイルが見つからない場合の処理
• 選択がキャンセルされた場合の処理
• 警告メッセージの抑制

スクリプトの流れ

1. awsume と peco の存在確認
2. awsume -l でプロファイル一覧取得
3. 不要な行をフィルタリング
4. peco で選択画面表示
5. 選択されたプロファイルで awsume 実行

注意事項

• プロファイル選択をキャンセルした場合は正常終了
• エラー発生時は適切なメッセージを表示して終了

まとめ

このスクリプトを使うことで、複数の AWS アカウントを効率的に管理できるようになります。特に多くのプロファイルを持つ環境では、視覚的に選択できる peco の威力を実感できるはずです。

日常的に awsume を使用している方は、ぜひ試してみてください。

自分は alias a="$HOME/awsume-switcher.sh" のようにして使ってます。

以上
参考になれば幸いです。

※ 本記事は Claude Code で調べ得た内容を Obsidian にまとめさせブログ化してもらいました。初の試み💓

💰 料金比較の結論

Confluent CloudとAWS Marketplace版の料金は同じです。

AWS Marketplace版のConfluent Cloudの価格設定は、Confluent直販の価格設定と同じです。つまり、どちらを選んでも基本的な料金体系に違いはありません。

料金体系の詳細

🧮 共通の料金構造

両方とも以下の要素で課金されます：

1. Kafka クラスター: eCKUs（Elastic Confluent Units for Kafka）による時間料金、ネットワーキング（GB単位）、ストレージ（GB-時間単位）
2. Connect: コネクタの使用はスループット（GB単位）とタスクベース価格（タスク/時間単位）で課金
3. Stream Processing: Apache FlinkによるCFUs（分単位）で課金
4. Stream Governance: 環境単位（時間単位）で課金

主な違い

支払い方法と統合面：

• SaaS版: Confluent直接支払い
• AWS Marketplace版: AWS Marketplaceを通じて直接課金され、既存のAWSコミットを活用でき、事務手続きを省略できます

特典：

• AWS Marketplace版では$1,000の無料クレジット（$400即座、$600はプロモコード経由）が提供されます
• AWS Marketplace経由のすべてのConfluent Cloudサインアップには、追加費用なしでConfluent Cloud Engineersによるホワイトグローブオンボーディング、アーキテクチャレビュー、オンデマンドトレーニングが含まれます

推奨

料金面では差がないため、以下の要因で選択することをお勧めします：

1. AWS環境に統合したい場合 → AWS Marketplace版
2. 既存のAWS契約やコミットを活用したい場合 → AWS Marketplace版
3. 統一された請求を希望する場合 → AWS Marketplace版
4. 初期の無料クレジットを活用したい場合 → AWS Marketplace版

料金以外の面では、AWS Marketplace版の方がAWS環境との統合や請求の簡素化において有利と言えるでしょう。

⚠️ PrivateLink を利用する場合、 Enterprise プランを選択する必要がある

秘匿性の高いデータを扱うことが想定されるのでインターネットには出ない内部通信をするとなると PrivateLink の設定が必要になってくるかと思います。
その場合、 Confluent で Enterprise / Dedicated プランを選択する必要があり、そのコストも加味しておく必要があるのでご注意ください。

以上
参考になれば幸いです。

利用する構文チェックツール

• requirements-dev.txt

  1 2 3 4 5 6 7

  pytest==6.2.5 tox==4.26.0 black==25.1.0 bandit==1.8.3 flake8==7.2.0 mypy==1.16.0 isort==6.0.1

  tool	explain
  pytest	Python の テスト実行ツール。テスト関数を自動で見つけて実行します。
  tox	複数の環境でテストやチェックを自動化するツール。CI/CDや複数Pythonバージョン対応に使います。
  black	コード整形ツール（自動フォーマッター）。PEP8に準拠したスタイルに自動で直します。
  bandit	Pythonコードの セキュリティチェックツール。危険なコードパターンを検出します。
  flake8	Pythonコードの 文法・スタイルチェックツール。PEP8違反などを報告します。
  mypy	Pythonコードの 型チェックツール。型ヒント（type hint）が正しく使われているか確認します。
  isort	import文を自動で整理・ソートするツール。blackと一緒によく使われます。

tox.ini 設定例

除外ディレクトリについて CDK プロジェクトを考慮している tox.ini の設定です。
流用十分可能です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

[tox]
# setup.py がなくとも動作する様にする為、指定している
skipsdist = True

[testenv]
# NOTE: 環境にインストールするライブラリを指定する
#   `-r` と `requirements.txt` の間にスペースを入れるとエラーになる
# NOTE: 各環境で利用ツールの version 差異が出ない様、
#   requirements-dev.txt で開発・テスト用のモジュールをバージョン管理する
deps =
    -rrequirements.txt
    -rrequirements-dev.txt
commands = pytest -rsfp

[testenv:lint]
deps = -rrequirements-dev.txt
commands =
    black . --check --skip-string-normalization
    bandit --quiet --exclude ./.tox,./.venv,./.pytest_cache --recursive .
    flake8 .
    mypy --ignore-missing-imports .
    isort . --profile black --check --diff --skip-glob .venv,./.tox,./.pytest_cache

# lint 指摘事項の自動修正. black, isoft のみ対応
[testenv:lint_auto_fix]
deps = -rrequirements-dev.txt
commands =
    black . --skip-string-normalization
    isort . --profile black --diff --skip-glob .venv,./.tox,./.pytest_cache

[flake8]
deps = -rrequirements-dev.txt

# 1行当たりの最大文字数 (default: 80)
# 119: GitHub のコードレビューが表示できる長さ
max-line-length = 119

exclude =
    .git
    __pychache__
    .tox
    .mypy_cache
    .venv
    .pytest_cache
    cdk.out

利用方法

テスト実行方法

1

tox

構文チェック実行

1

tox -e lint

構文自動修正

1

tox -e lint_auto_fix

GitHub Actions 設定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

name: CDK Unit Test

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 5

    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      # Python バージョン取得
      - name: Pick python version
        id: python
        run: echo "version=$(awk '$1 ~ /^python/{print $2}' .tool-versions)" >> $GITHUB_OUTPUT

      # Python セットアップ
      - name: Set up Python
        uses: actions/setup-python@7f4fc3e22c37d6ff65e88745f38bd3157c663f7c # v4.9.1
        with:
          python-version: ${{ steps.python.outputs.version }}

      # 必要ツールの導入
      - name: Install dependencies
        run: pip install -r requirements-dev.txt

      # 構文チェック実行
      - name: Run linter
        run: tox -e lint

      # テスト実行
      - name: Run tests
        run: tox

実装例

Raspberry PI の設定で利用しました。

https://github.com/kenzo0107/raspi-talk/commits/main/tox.ini

以上
参考になれば幸いです。

基本ログは追加のみで更新や削除はされない性質があるので、その点を考慮して登録されることを意識したアーキテクチャが望ましいです。

ECS コンテナロギングの構成

ECS → CloudWatch Logs

デフォルトではこのような構成がよく見受けられます。

graph LRECS-->cw_logs[CloudWatch Logs]

• Pros:
  • リアルタイムでデータ分析が可能
  • 簡易的に設定できる
• Cons:
  • CloudWatch Logs へのログ出力コストが掛かる
  • 他データとの統合的な分析は一手間かかる

他データとの統合的な分析は一手間かかる ?

CloudWatch Logs Insight もあり、ログのみを分析対象とする場合であれば特に問題ないですが、
他データと照合したい場合は統合的な管理が必要です。

例: 特定の時刻で ALB のログと付き合わせて、どの URI にアクセスされたかを集計したい場合

Amazon Athena CloudWatch コネクタ で
Athena から CloudWatch に接続可能ですが、Lambda を介するので Lambda の一度に返せるレスポンスの制限があり、レスポンスで返せないデータは一度 S3 に退避 (spill) したりすることで完全なレスポンスを返すまでに時間を要し、パフォーマンスが悪くなります。

CloudWatch のサブスクリプションフィルターで Lambda でデータ変換し S3 保管

graph LRcw_logs[CloudWatch Logs]--Lambda-->S3

こちらも処理量がお多い場合に Lambda のリソース制限でエラーハンドリングをする必要が出る可能性もあり、あまり利用を推奨しづらい構成です。

ECS → Kinesis Firehose → S3

graph LRECS-->kinesisfirehose[Kinesis Firehose]--parquet-->S3

Kinesis Firehose 経由で S3 にデータを蓄積し、Athena から参照する構成です。

• Pros:
  • S3転送時に失敗した場合にバックアップが取れる
  • 大量リクエストがある場合、 CloudWatch Logs への put object する料金より安くすることができる
  • Athena で統合して分析可能
• Cons:
  • Kinesis Firehose でデータをバッファリング (一定条件で溜め込む) するとリアルタイム性が損なわれる
    • ある程度コストを抑えるには、最大 15 分のバッファリングが可能なので、まとめて S3 にデータを送信ができる
  • 設定に一手間

障害等で緊急のログ調査が必要な時にリアルタイム性が損なわれた状態では運用に懸念があります。
新規の開発時に検証でログが直ちに閲覧できないストレスは想像に難くありません。
データ分析の観点で言えば、Athena で統合でき、親和性が高いですが、実運用の観点では問題がある様に見えます。

ECS → Kinesis Firehose / CloudWatch Logs ハイブリッド

graph LRECS-->kinesisfirehose[Kinesis Firehose]--parquet-->S3ECS-->cw_logs[CloudWatch Logs]

ハイブリッドにすることで実運用を鑑みてリアルタイム性を担保しつつもデータ分析を Athena で統合的にデータ分析できる状態ができます。

• Pros:
  • データ分析用のログとリアルタイムのログを担保できる
• Cons:
  • CloudWatch Logs へのログ出力コストが掛かる
  • 設定に一手間

リクエストの規模にもよりますが、データ分析をする、と言う背景を持った上でのアーキテクチャを鑑みるとこの辺りが落とし所かなと思います。

時折見る辛い構成

graph LRECS--ログ-->RDS

ログデータを DB に溜め込んでいるのを時折見ます。
そのデータを元にリアルタイムにアクセスランキングを出したり、ということをやろうとしたのかな？と背景を想像したりしますが、
悪手である場合が多い印象です。

データ肥大化に対策した上で溜め込んでいるのであれば、まだ良いですが、
そうでなければ、いずれ肥大化してパフォーマンスを落としていくのが目に見えている為です。

RDS から何億レコードを一括で取ろうものなら DB リソースを消費しアプリケーション DB であれば、ユーザ影響を及ぼすことは想像に難くないです。

データ分析の観点からやって欲しくない構成です。

ログは一旦ログストレージ (例: S3)に流し、アプリケーションで利用するデータは別途担保する、というのが望ましいです。

総評

AWS ECS コンテナのロギングでの運用してみてほどよかったハイブリッド形式を紹介させていただきました。

ECS ではサイドカーで fluentbit を起動し、ログをルーティングしました。

参考: https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/firelens-using-fluentbit.html

以上
参考になれば幸いです。

手順

1. 監視や API Key, Application Key を削除

• 監視が残っていると削除できない場合があります。
• API Key を削除することで API Key を利用した Datadog Agent からのデータ収集ができなくなり、意図しないコストの発生を抑える意図があります。

2. サポートに連絡

• 子組織を削除する API は存在せず、ドキュメントに記載のある通り、 Datadog サポートに連絡して削除する必要があります。
• https://docs.datadoghq.com/ja/account_management/#%E7%B5%84%E7%B9%94%E3%81%AE%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%92%E7%84%A1%E5%8A%B9%E3%81%AB%E3%81%99%E3%82%8B
• 子組織削除 API が存在しない為、 terraform-provider-datadog でも子組織を管理するリソースを削除しても子組織自体は残ってしまいます。

サポートの状況次第ですが、おおよそ 1週間程度で削除していただけました。

以上です。

概要

RDS のテーブルデータを分析用テーブルにレプリケートする方法が多数あったのでその一覧をまとめます。

RDS をユーザ影響を極力低くすべく、分析用テーブルへレプリケートして、分析する方法が多々あったので私見ですが Pros/Cons をまとめます。

前提

• アプリケーション DB を配置する AWS アカウントとデータ基盤を構築する AWS アカウントは分けます
• Glue テーブルは iceberg 形式を採用します

RDS→GlueJob→Iceberg テーブル

graph LRsubgraph AWS Account-a  RDSendRDS--SELECT-->GlueJobsubgraph AWS Account data-platform  GlueJob-->Icebergテーブルend

Glue Job から Glue Connection 経由で RDS に接続し、クエリを実行し、抽出したデータを Iceberg テーブルへレプリケートします。

• Pros:
  • コスト安
• Cons:
  • レコード削除に対応できない
    • 論理削除であれば対応はできるが、物理削除されると検知できない
    • 全データをエクスポートし直す、もしくは、削除されたレコードを特定する様、RDS 側と Iceberg テーブルで突き合わせる方法はあるが、リソース逼迫させてしまう恐れがある
  • テーブル毎にデータ取得時の識別子 (PK 相当) となるカラムを決定する必要がある
    • PK がない場合、別途指定する必要がある。
    • 例えば更新されるレコードがある場合、 updated_at をキーにし、差分抽出するような処理が必要になる
  • リアルタイム性を追求すると実行コストが嵩む

運用コストが高く、大規模な DB 環境には向かない。

RDS Zero-ETL 統合 →Redshift

graph LRsubgraph AWS Account-a  RDSendRDS--Zero-ETL-->Redshiftsubgraph AWS Account data-platform  Redshiftend

参考: Amazon Redshift との Amazon RDS ゼロ ETL 統合での作業

RDS の Zero-ETL 統合により完全マネージドで Redshift へレプリケートします。
他の手法と異なり、 Iceberg テーブルでなく Redshift がインターフェースになります。

• Pros:
  • 完全マネージドなサービスでスクリプト不要
  • Redshift は dbt との相性が良い
• Cons:
  • Redshift コスト高
    • Serverless でレプリケート間隔を広げることでコストを抑えることはできそうだが、リアルタイム性は損なわれる
  • Aurora 以外はサポート外 (2024.12.19 時点)

RDS→DMS→S3→GlueJob→Iceberg テーブル

graph LRsubgraph AWS Account-a  RDS--CDC-->DMSendDMS-->S3subgraph AWS Account data-platform  S3--GlueJob-->Icebergテーブルend

参考: Modernize your legacy databases with AWS data lakes, Part 2: Build a data lake using AWS DMS data on Apache Iceberg

• Pros:
  • Redshift よりは安く済みそう
• Cons:
  • DMS 運用コストが高い（AWS SA 様より頂いた意見）
    • バージョン毎の仕様差による障害発生
    • 比較的バージョンアップが多い
    • バージョンアップ時にレプリケートを停止し、再度テーブル作り直す必要があるなど手間が多い
  • Glue Job によるデータ処理（更新・追加・削除）が煩雑化する
  • テーブルのスキーマ変更に Glue Job で対応する必要がある

DMS 採用企業はある

• クックパッド - DMS を利用した継続的なデータ変更検知

RDS→debezium→MSK→S3→GlueJob→Iceberg テーブル

graph LRsubgraph AWS Account-a  RDS--CDC-->debezium  debezium-->MSKendMSK--Parquet-->S3subgraph AWS Account data-platform  S3--GlueJob-->Icebergテーブルend

参考: Synchronize data lakes with CDC-based UPSERT using open table format, AWS Glue, and Amazon MSK

MSK で CDC データを Parquet で S3 に保存し、 Glue Job で Iceberg テーブルに変換します。

• Pros:
  • RDS Zero-ETL サポート外の MariaDB にも対応できる
• Cons:
  • debezium, MSK 等の学習コストが高い（個人の感想）
  • Glue Job によるデータ処理（更新・追加・削除）が煩雑化する
  • テーブルのスキーマ変更に Glue Job で対応する必要がある

RDS→debezium→MSK→DataFirehose→Iceberg テーブル

graph LRsubgraph AWS Account-a    RDSendRDS-->msk_connector[MSK Connector]-->msk_cluster[MSK Cluster]-->Lambda--レコード変換-->Icebergsubgraph AWS Account data-platform    msk_connector[MSK Connector]    msk_cluster[MSK Cluster]    Iceberg    subgraph Data Firehose        Lambda    endend

• Pros:
  • RDS Zero-ETL サポート外の MariaDB にも対応できる
  • Data Firehose 側でバッファ調整やエラーハンドリングできる
• Cons:
  • debezium, MSK 等の学習コストが高い（個人の感想）
  • テーブルのデータ・スキーマ変更に Lambda で対応する必要がある
  • テーブル数分 Data Firehose を作成する必要がある
    • リクエスト量による課金なのでコスト的な問題はないが、管理が煩雑になる
  • 事前に Iceberg テーブルを作成しておく必要がある

RDS→debezium→MSK→Icebergテーブル

graph LRsubgraph AWS Account-a    RDSendRDS-->msk_connector[MSK Connector]-->msk_cluster[MSK Cluster]-->msk_connector_sink_iceberg[MSK Connector Sink Iceberg]-->Icebergsubgraph AWS Account data-platform    msk_connector[MSK Connector]    msk_connector_sink_iceberg[MSK Connector Sink Iceberg]    msk_cluster[MSK Cluster]    Icebergend

• Pros:
  • Data Firehose 管理が不要
    • 「RDS→debezium→MSK→DataFirehose→Iceberg テーブル」のテーブル数分 Data Firehose を作る問題を解決
    • どの程度のリクエスト量かや取りこぼしをハンドリグすることはできない → ad hoc snapshot があるので問題なさそうではある
  • テーブルを事前に作成する必要がなく、自動作成が可能
• Cons:
  • Iceberg Sink Connector 設定の学習コストが高い

RDS→Data Firehose→Iceberg テーブル (preview 版)

graph LRsubgraph AWS Account-A    RDS-->NLB    NLB-->VPCエンドポイントサービスendVPCエンドポイントサービス--CDCログ-->VPCエンドポイントsubgraph AWS Account data-platform    VPCエンドポイント-->data_firehose[Data Firehose]    data_firehose[Data Firehose]-->Icebergend

参考: Amazon Data Firehose を使用して、データベースから Apache Iceberg テーブルに変更をレプリケート (プレビュー)

• Pros:
  • 運用・構築コスト安
  • インターフェースを S3 上の Iceberg テーブルに統合できる
• Cons:
  • 2024 年 12 月 19 日時点では、テーブルを .* で指定すると多数テーブルがある場合、内部エラーとなり実運用に向かない
    • 問い合わせ中 → 想定しないバグだったとのこと。ワイルドカード * でなく、すべてのテーブルを指定することを推奨されました。
  • PrivateLink の構築が必要

RDS を共有しクローン

graph LRaccount_a[RDS]--共有-->data_platform[RDS]subgraph AWS Account-A    account_a[RDS]endsubgraph AWS data-platform    data_platform[RDS]--クローン-->cloned[RDS]end

RDS を共有し、その共有された RDS をクローン作成します。
クローン実施された時点の最新のデータをクローンされた RDS で参照することができます。
リアルタイム性を求めるには難しい構成です。

• Pros:
  • 簡易に最新データのスナップショットが参照できる
• Cons:
  • 定常的にリアルタイムにデータが参照できない
  • 起動に少なくとも 10 分程度かかる

総評

RDS→Data Firehose→Iceberg (preview 版) が運用・構築コスト安で大変期待しています。

様々手法がある中で CDC を利用した Iceberg テーブルへの統合はデファクトになっていく流れにあるかと推察します。

今後がより楽しみです。

以上
参考になれば幸いです。

概要

Glue Job で DB データを取得していた際に Glue Job Bookmark を利用していた際に問題があったので、その際の対応を備忘録として残しておきます。

Glue Job Bookmark 機能とは？

Glue Job で DB やログ情報を取り込みしている場合、どこまで取り込んだかを記録する Bookmark 機能 があります。

DB データを毎回全てダンプするよりも差分のみ抽出（増分エクスポート: Incremental Export）でき、データの取り込み量も抑えられ、Glue Job の実行時間が短縮されます。

Glue Job は実行時間に対して従量課金されるのでコストも抑制できるメリットがあります。

Glue Job Bookmark の問題点

Glue Job の Bookmark は job.commit() された際に更新されます。

取り込み処理中に一部のテーブルでエラーが発生し処理が中断された場合、エクスポート処理が成功したテーブルはデータ自体は更新されますが、Bookmark は更新されず、不整合が発生します。

例: 不整合が起こる例

• table1 処理成功 → データ自体は更新される
• table2 処理成功 → データ自体は更新される
• table3 処理失敗 → データ自体は更新されない
  → Bookmark は更新されない。

全ての処理で transaction を貼ることが対策ではありますが、実行コストが高い場合に、取り込めた分は取り込めた分だけ更新してもらった方が再実行コストが低くて良いです。

問題点への対応策

glue context の create_data_frame.from_catalog を利用して抽出する際は　additional_options['sampleQuery'] を利用し、増分を抽出する、自前 Bookmark 機能で対応しました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

if is_table_exists:
   # テーブルが既に存在する場合

   # Glue Data Catalog テーブルの bookmark key に設定したカラムの最大値取得
   df = self.glueContext.create_data_frame.from_catalog(database=dest_database, table_name=dest_table)
   max_value = df.agg({bookmark_key: "max"}).collect()[0][0]

   # sampleQuery を利用し増分のみ取得
   datasource = self.glueContext.create_dynamic_frame.from_catalog(
      ...
      additional_options={
            'sampleQuery': f"SELECT * FROM {source_database}.{source_table} WHERE {bookmark_key} > {max_value} AND",
            ...
      }
   )

これにより Bookmark 機能を利用せずとも差分抽出をできるように対策しました。

ちなみにクエリの最後に AND があるのは、enablePartitioningForSampleQuery: true にし、JDBC テーブルから並列で読み込む設定をしている為です。

まとめ

• sampleQuery の方が Bookmark 機能より増分エクスポートはしやすい印象
  • DB 負荷を抑えながら取り込むこともできるメリットもある
• Glue Job Bookmark は更新 API 等はなく、Glue Job の実行成功でのみ更新されるので、失敗した場合は全てを失敗と見なすしかなさそう
  • ハンドリングしづらい

以上
参考になれば何よりです。