見出し画像

AWS の高額請求原因と解決策一覧：NAT Gateway から Lambda 再帰ループまで

そよ風

1. 序論：クラウドエコノミクスにおける不可視コストの構造

結論
AWS におけるコスト異常の多くは、インスタンスタイプなどの固定要素ではなく、データ転送、ログ取り込み、API リクエストといった「不可視トラフィック」に起因する。これらはアーキテクチャの設計不備により指数関数的に増大するリスクを持つ。

1.1 コスト発生のメカニズムとリスク対象

AWS の従量課金モデル（Pay-as-you-go）において、以下のサービス群は監視の死角となりやすく、予期せぬ高額請求（Bill Shock）の主要因となる。

  • NAT Gateway ： データ処理料金とクロス AZ 転送。

  • Amazon GuardDuty / AWS Config ： メタデータ監視と設定変更記録。

  • AWS Lambda / Amazon S3 ： 再帰的ループと API リクエスト。

  • Amazon Macie / CloudWatch Logs ： データスキャンとログ取り込み。

2. NAT Gateway のコスト異常と対策

結論
NAT Gateway のコスト超過の主因は「データ処理料金」であり、クロス AZ 通信や不適切なルーティングがコストを増幅させる。VPC エンドポイントの活用と Egress トラフィックの監視が必須である。

2.1 課金構造とリスク・マルチプライヤー

NAT Gateway のコストは稼働時間よりもデータ処理量に依存する。特にアベイラビリティーゾーン（AZ）を跨ぐ通信はコストを三重に発生させる可能性がある。

表 2.1 ： NAT Gateway の標準的な料金体系（us-east-1 / ap-northeast-1）

$$
\def\arraystretch{1.5}
\small
\begin{array}{|l|l|l|}
\hline
\textsf{課金項目} & \textsf{単位価格（概算）} & \textsf{技術的特性とリスク} \\
\hline
\textsf{\textbf{稼働時間料金}} & \textsf{\$0.062 / 時間} & \textsf{アイドル状態でも発生する固定費。マルチ AZ 構成では AZ 数分だけ倍加する。} \\
\hline
\textsf{\textbf{データ処理料金}} & \textsf{\$0.062 / GB} & \textsf{最大のリスク要因。NAT Gateway を通過する全てのパケットに対して課金される。} \\
\hline
\textsf{\textbf{データ転送量}} & \textsf{\$0.09 / GB} & \textsf{インターネットへの送信時に、処理料金とは別に加算される。} \\
\hline
\end{array}
$$

2.2 アンチパターンと技術的解決策

  • アンチパターン ： S3 や DynamoDB へのアクセスを NAT Gateway 経由で行う。

    • 結果 ： 10 TB のデータを処理した場合、約 $620 のデータ処理料金が無駄に発生する。

  • 解決策 ： Gateway 型 VPC エンドポイントを使用する。

    • 効果 ： ルートテーブルへの設定により通信が NAT Gateway をバイパスし、コストがゼロになる。

2.3 異常検知のための CloudWatch Alarm 定義

監視すべき最重要メトリクスは `BytesOutToDestination` である。以下は外部送信量が「 15 分間で 5 GB 」を超えた場合にアラートを発報する JSON 定義である。

{
    "Type": "AWS::CloudWatch::Alarm",
    "Properties": {
        "AlarmName": "Critical-NAT-Gateway-High-Egress-Traffic",
        "AlarmDescription": "Alert triggers when NAT Gateway egress traffic exceeds 5GB in a 15-minute window.",
        "Namespace": "AWS/NATGateway",
        "MetricName": "BytesOutToDestination",
        "Dimensions": [
            {
                "Name": "NatGatewayId",
                "Value": "nat-0xxxxxxxxxxxxxxxxx"
            }
        ],
        "Statistic": "Sum",
        "Period": 900,
        "EvaluationPeriods": 1,
        "Threshold": 5368709120,
        "ComparisonOperator": "GreaterThanOrEqualToThreshold",
        "TreatMissingData": "missing"
    }
}

3. セキュリティ・ガバナンスサービスのコスト最適化 (GuardDuty & Config)

結論
セキュリティサービスは監視対象のリソース量に比例してコストが増加する。GuardDuty の S3 保護機能と AWS Config の連続記録モードは、設定次第でコストドライバーとなる。

3.1 Amazon GuardDuty ： S3 保護の課金構造

GuardDuty の S3 保護機能は、管理イベントではなく「データイベント（ GetObject , PutObject 等）」の量をベースに課金される。

表 3.1 ： GuardDuty S3 保護の料金階層（us-east-1）

$$
\def\arraystretch{1.5}
\small
\begin{array}{|l|l|}
\hline
\textsf{イベント数（月間）} & \textsf{料金（100 万イベントあたり）} \\
\hline
\textsf{最初の 5 億イベント} & \textsf{\$0.80} \\
\hline
\textsf{次の 45 億イベント} & \textsf{\$0.40} \\
\hline
\textsf{50 億イベント以降} & \textsf{\$0.20} \\
\hline
\end{array}
$$

  • リスクシナリオ ： 機械学習ジョブや Athena による大規模スキャンが数十億のイベントを発生させ、数百ドルの請求を引き起こす。

  • 対策 ： 高頻度アクセスが発生するバケットを除外設定するか、必要なアカウントのみで機能を有効化する。

3.2 AWS Config ： 設定変更記録 (CI) の抑制

AWS Config は「 Configuration Item (CI) 」の記録数（ $0.003 / レコード）に応じて課金される。

  • リスク要因 ： Auto Scaling Group による頻繁なインスタンスの作成・削除や、Lambda による動的なタグ更新。

  • 対策 ： 「定期記録（Periodic Recording）」モードを適用し、記録頻度を 24 時間に 1 回に抑制する。

コード 3.1 ： Config 記録数の急増を検知する CloudWatch Metric Math
特定リソースタイプのスパイクを監視するための数式である。

SEARCH('{AWS/Config,ResourceType} MetricName="ConfigurationItemsRecorded" NOT ResourceType="All"', "Sum", 86400)

4. サーバーレスの再帰的ループ防止 (Lambda & S3)

結論
AWS Lambda と S3 / SQS 間の「再帰的ループ」は無限の請求を発生させる。AWS の自動検知機能に依存せず、アーキテクチャレベルでの分断とアラーム設定が必要である。

4.1 無限駆動の発生メカニズムと対策

Lambda 関数が処理結果を出力し、その出力が再び同じ Lambda 関数をトリガーすることでループが発生する。

  • 発生事例 ： S3 の `ObjectCreated` イベントで起動した Lambda が、同一バケットにファイルを書き込む。

  • AWS の対策 ： 同一チェーン内で関数が 16 回以上呼び出された場合、実行を停止する（一部構成を除く）。

4.2 再帰ループ検知アラーム

自動検知機能によりドロップされた呼び出しを監視する `RecursiveInvocationsDropped` メトリクスのアラーム定義である。

{
    "Type": "AWS::CloudWatch::Alarm",
    "Properties": {
        "AlarmName": "Lambda-Recursive-Loop-Dropped-Alert",
        "Namespace": "AWS/Lambda",
        "MetricName": "RecursiveInvocationsDropped",
        "Statistic": "Sum",
        "Period": 60,
        "EvaluationPeriods": 1,
        "Threshold": 0,
        "ComparisonOperator": "GreaterThanThreshold",
        "TreatMissingData": "notBreaching"
    }
}

4.3 S3 リクエスト料金のリスク

S3 の HTTP エラーコード（ 403 / 404 等）に対する課金は廃止されたが、以下のリスクは残存する。

  • LIST リクエスト ： $0.005 / 1,000 リクエスト。無限ループ内で `ListBucket` を実行した場合、高額請求が発生する。

  • 成功リクエスト (200 OK) ： 外部からの大量の正規アクセスは依然として課金対象である。

5. データ分類とログ監視のコスト (Macie & CloudWatch Logs)

結論
Amazon Macie の自動検出と CloudWatch Logs の全量取り込みは、データ量に比例してコストが激増するため、スコープの限定とストレージクラスの使い分けが必須である。

5.1 Amazon Macie ： 自動検出のコスト構造

Macie の「自動検出（Automated Sensitive Data Discovery）」機能はスキャン量に応じて課金される。

  • 料金 ： $1.00 / GB（最初の 50 TB まで）。

  • リスク ： 100 TB のデータをスキャンした場合、約 $100,000 の請求が発生する可能性がある。

  • 防止策 ： スキャン対象バケットを厳選し、コンソールで「推定コスト」を事前に確認する。

5.2 CloudWatch Logs ： 取り込みコストの最適化

ログの取り込み（Ingestion）は S3 への保存と比較して高額である。

表 5.1 ： CloudWatch Logs 料金比較（us-east-1）

$$
\def\arraystretch{1.5}
\small
\begin{array}{|l|l|l|}
\hline
\textsf{クラス} & \textsf{料金} & \textsf{適用ケース} \\
\hline
\textsf{\textbf{Standard クラス}} & \textsf{\$0.50 / GB} & \textsf{リアルタイム監視、メトリクスフィルターが必要なログ。} \\
\hline
\textsf{\textbf{Infrequent Access (IA) クラス}} & \textsf{\$0.25 / GB} & \textsf{事後分析のみに使用するログ（開発環境、VPC フローログ詳細）。} \\
\hline
\textsf{\textbf{S3 Standard 保存}} & \textsf{\$0.023 / GB} & \textsf{参考値。長期保存目的の場合。} \\
\hline
\end{array}
$$

6. コストガバナンスの最終防衛線：Service Control Policies (SCPs)

結論
監視による事後対応には限界がある。Service Control Policies (SCPs) を用いて、高額リソースの作成と未承認リージョンの使用を物理的にブロックすることが最も確実な予防策である。

6.1 高額な EC2 インスタンスタイプの起動禁止

特定の安価なインスタンスタイプ以外を拒否するポリシーである。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringNotLike": {
                    "ec2:InstanceType": [
                        "t2.micro",
                        "t3.micro",
                        "t3.small"
                    ]
                }
            }
        }
    ]
}

6.2 未承認リージョンの使用禁止（リージョンロック）

指定されたリージョン（例：東京、バージニア北部）以外での操作を全面的に拒否するポリシーである。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "NotAction": [
                "iam:*",
                "route53:*",
                "cloudfront:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1",
                        "us-east-1"
                    ]
                }
            }
        }
    ]
}

7. 機械学習による異常検知 (Cost Anomaly Detection)

結論
静的な閾値ベースのアラームでは検知できない緩やかなコスト増を捕捉するために、AWS Cost Anomaly Detection を利用する。即時通知のためには SNS アクセスポリシーの設定が必要である。

コード 7.1 ： SNS トピックアクセスポリシー (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSAnomalyDetectionSNSPublishingPermissions",
      "Effect": "Allow",
      "Principal": {
        "Service": "costalerts.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyTopic"
    }
  ]
}

8. 結論：コスト耐性のあるアーキテクチャの要件

結論
AWS におけるコストリスクを最小化するためには、以下の技術的統制の実装が不可欠である。

  • トラフィック制御 ： NAT Gateway を回避し、VPC エンドポイントを活用する。

  • 再帰防止 ： Lambda のループ検知アラームを設定する。

  • メタデータ最適化 ： AWS Config の定期記録と GuardDuty の除外設定を行う。

  • ガバナンス ： SCP により高額リソースと未承認リージョンをブロックする。

これらの対策により、エンジニアは請求額への不安を排除し、開発に専念できる環境を構築できる。

いいなと思ったら応援しよう！