はじめに

このセッションは、AWS Cost and Usage Reports (CUR) を活用した高度なコスト分析のライブコーディングセッションで、Amazon Qとの連携、VPC Flow Logsの統合、Gen AIコストの配分、そしてLake Formationを使ったセキュアなデータ共有まで、実践的なテクニックが紹介されました。

前半：コスト最適化編

1. セッション概要とCURクイズで基礎知識を確認

セッションは参加者全員が立ち上がってのクイズから始まりました。正解したら立ったまま、不正解なら座るという形式で、最後まで残った人にはステッカーがプレゼントされるとのこと。私は3問目で間違えて座りました。

クイズの内容:

1. CURの最新バージョンは？

   • 答え: CUR 2.0
   • CUR 2.0には最新機能がすべて含まれており、今日のデモでもこのバージョンを使用

2. CURのデータはどこに保存される？

   • 答え: S3
   • S3に保存できるデータはすべてCURと統合可能

3. タグはデフォルトでCURに追加される？

   • 答え: No
   • 重要なポイント：コスト配分タグは手動で有効化する必要がある

4. CUR 2.0にアカウント名を追加できる？

   • 答え: Yes
   • これはCUR 2.0の新機能で、今日のセキュリティセクションで活用

2. NAT Gatewayのコスト異常を検知

実際のシナリオとして、AWS Cost Anomaly Detectionから「NAT Gatewayのコストが増加している」という通知を受け取ったところからスタート。
たまによく見る毎月コストが上昇していく棒グラフが表示され、「ウッ」という気持ちになりました。

Cost Explorerで確認すると、以下の3つの項目が増加していました：

• NAT Gateway時間料金
• NAT Gatewayバイト処理料金
• Data Transfer Regional Bytes

Amazon Q in Cost Explorerに「Data Transfer Regional Bytesとは？」と質問すると、「アベイラビリティゾーン間のデータ転送」であることが判明しました。

セッションではAthenaのWEBコンソール上でSQLを変更&実行していき、コストを分析していきました。
case式を用いたgroup byなどを活用して、単純なログ情報から次第に目的の情報を得ていくという流れでした。

分析対象のログは、最初はCURのログでしたが、途中からは実際に何が原因でコストが増加していたのかを分析するためにVPC Flow Logsのログを分析していきました。
ここでbyteをGBに変換する際にbigintをfloatに変換するために1024ではなく1024.0で割るなどの工夫が紹介されました。

3. Amazon Qを活用した問題解決とコスト計算

ここまでのクエリからIPアドレスまで特定されましたが、ここからリソースを特定するためにAmazon Q in Consoleを活用しました。
「このIPアドレスは何？」と質問すると、Amazon Qは環境全体を調べて、EC2インスタンスとその関連情報（タグ、アベイラビリティゾーンなど）を特定してくれました。
さらに、Amazon QにIPアドレスのリストを渡して「これらを分類するクエリを作って」と依頼すると、CASE文を使った分類クエリが返ってきました。

クエリ得られた結果から、最終的にクロスAZ通信が発生していることが判明し、解決方法をAmazon Qに質問してこのセッションの前半フェーズは終了しました。

後半：AI コスト配分とセキュリティ編

1. Gen AIコスト配分の2つの課題

2024年、多くの顧客がGen AIのコスト配分に苦労している理由は2つある、という話から後半セッションが始まりました。

課題1：3種類の課金モデル

Bedrockでモデルを選択する際、実は以下の3つの課金モデルのいずれかを（無意識に）選んでいます：

1. First Party Models：AWSが訓練・開発・販売（例：Nova, Titan）
2. Second Party Models：他社が訓練・開発、AWSが販売（例：Llama）
3. Third Party Models：他社が訓練・開発・販売、AWS Marketplaceを通じて提供（例：Claude）

これらはCURで異なる表示のされ方をします：

• 1st/2nd Party: product_product_code LIKE 'bedrock'
• 3rd Party: product_product_name LIKE '%(Amazon Bedrock)'

課題2：モデル名しか表示されない

EC2インスタンスやNAT Gatewayと異なり、Bedrockの使用はモデル名しか表示されません。リソースIDがないため、どのアプリケーション・部門が使用したのか追跡が困難です。

解決策：Inference Profiles

Inference Profilesを使うと、Bedrockへのアクセスを事前設定できます：

• 使用モデルの指定
• Temperature等のパラメータ設定
• タグ付け（コスト配分の鍵）

CloudFormationの例（確かこんな感じ）：

InferenceProfile:
  Type: AWS::Bedrock::InferenceProfile
  Properties:
    ModelId: anthropic.claude-v3
    Tags:
      - Key: Department
        Value: Sales

2. 部門別コスト配分の実践

タグを用いて部門ごとのBedrockの使用状況を取得するクエリを実行しました。
その結果から以下のような結果が得られ、

• Sales部門：$2.00（最高額だが使用量は少ない）
• Dev部門：$0.67（Salesの1/3のコストだが使用量は同程度）

このセッションでは「Sales部門にClaudeを使う必要があるのか確認する必要がありそうです」という話になりました。

ちなみにクラスメソッドではどの部門であってもClaudeを使うことができます。部門によって「使うな」なんて言われません！うれしい！

3. ユニットコストで最適化効果を可視化

ユニットコスト（Unit Economics）とは1単位あたりの総支出のことで、コスト増加が正当（ユーザー増）なのか問題（設定ミス等）なのかを判断できます。
このセッションでは、EC2・Lambda・Aurora・Bedrockを使ったデモアプリで「1クリックあたりのコスト」を計算しました。

CURのline_item_usage_amount列にLambda invocation数が含まれています。
タグを使ってアプリ全体のコストを取得し、invocation数とJOINすることで単位コストを算出できます。
前半で学んだNAT Gateway修正やモデル変更などの最適化を実施した11月のデータでは、cost_per_invocationが大幅に減少していました。

静的コスト（EC2、RDS）と変動コスト（Lambda、Bedrock）を区別しつつ、ユニットコストを確認するのが良いそうです。
CUR内のデータ（Lambda invocations、API呼び出し、ストレージGB等）を活用できるため、外部データを取得する手間を省けるのも利点です。

4. Lake Formationで安全にCURデータを共有

適切な人に適切なデータだけを共有するため、AWS Lake Formationを使った生データ（CUR）の共有方法が紹介されました。

セットアップは4ステップで構成されます。
(1) Lake Formationにデータ位置を登録（S3バケットとIAM Role、Permission ModeはHybrid Access Modeを選択）
(2) Data Filterを作成して行・列レベルの制限を設定（例：App Teamはline_item_unblended_cost列のみ、アカウント名がApp-Team-%の行のみ）
(3) 権限を付与（SELECT/DESCRIBEのみ許可、DROP/GRANTは拒否）
(4) Athena Workgroupを設定してAthena Managed Storageを使用（S3バケット不要、他チームのクエリ結果が見えない）

動作確認では、管理者は全8アカウントが見えるのに対し、App Team Roleでは2つのアカウントのみ表示され、列も制限されていることが確認できました。

まとめ

このセッションでは、Athenaを用いた分析テクニックをライブコーディング形式で学びました。
Amazon Qは用いていたものの、洞察を生成AIに任せていないのが印象的でした。
逆に知りたいことだけを伝えて、それをどのように実現するかをAIが解決するようなCode talkがあったらそれも聴講したいと思いました。

以上！