AWS What's New Digest

Appearance

2026年01月15日 ​

[Govcloud Us] Amazon VPC IPAM policies now support RDS and Application Load Balancers ​

概要 ​

Amazon VPC IP Address Manager (IPAM) のポリシー機能が、Amazon RDS インスタンスと Application Load Balancer (ALB) に対するパブリックIP割り当ての管理をサポートしました。これにより、IP管理者はこれらリソースのパブリックIPv4アドレス割り当てを中央で制御・強制できます。

変更内容・新機能の詳細 ​

今回の拡張で、IPAMポリシーは以下を中央で定義・適用できるようになりました：RDSインスタンス、Application Load Balancer（ALB）、リージョナル可用性モードで利用するNAT Gateway、および Elastic IP（EIP）。ポリシーで定義したIPプールからの割り当ては各アプリケーションチームが上書きできず、常にコンプライアンスを維持します。これにより、ネットワークACL、ルートテーブル、セキュリティグループ、ファイアウォールなどでのIPベースのフィルタリングが確実に機能し、運用やセキュリティ設計の簡素化と堅牢化が期待できます。機能は全てのAWS商用リージョンとAWS GovCloud (US) で利用可能で、VPC IPAM の Free Tier と Advanced Tier の両方でサポートされています。Advanced Tier を利用すると、アカウント間およびリージョン間でポリシーを適用できます。導入はIPAMポリシーのドキュメントに従って設定し、価格の詳細はVPCの価格ページ（IPAMタブ）を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/IP管理者、クラウドセキュリティチーム、SRE、データベース/アプリ開発チーム
  • 利用シーン: RDS や ALB に割り当てるパブリックIPv4アドレスを特定のIPAMプールに限定して、アクセス制御リストやセキュリティグループでIPベースのルールを厳密に運用したい場合
  • 運用効果: 個別チームへの教育や手順遵守の依存を減らし、IP割当の一貫性を確保することでネットワーク設計・セキュリティ運用の信頼性が向上する
  • リスク/注意点: ポリシー適用により特定のIPプール以外からの割当が抑制されるため、既存運用で固定IPに依存している外部ルールや証明書設定等の調整が必要になる可能性がある

技術的な注意点 ​

  • IAM権限: IPAMポリシーの作成・管理にはEC2/IPAM関連の権限が必要です。IPAMポリシーやプール、スコープを操作する権限を適切に付与してください（管理者ロールまたは限定的なIPAM管理権限）。
  • 既存割り当て: 既に割り当て済みのパブリックIPに対して自動的に再割当が行われるわけではありません。ポリシーは主に今後の割当に対して適用されます。既存リソースをポリシー下に移行する場合は個別対応が必要です。
  • 対象IP種別: 本機能は主にパブリックIPv4（EIPやRDS/ALBのパブリックIP、リージョナルNATのパブリック割当）に対する制御です。プライベートIPやIPv6アドレスの割当管理とは別扱いとなる点に注意してください。
  • リージョン制限: 全商用リージョンおよび AWS GovCloud (US) で利用可能と発表されていますが、実運用前に対象リージョンでの有効化状況を確認してください。
  • コスト: VPC IPAM の Free Tier と Advanced Tier の両方で利用可能です。Advanced Tier を使ってアカウント／リージョン横断のポリシー管理を行う場合は追加コストが発生する可能性があるため、VPC の価格ページ（IPAMタブ）で料金を確認してください。

参考情報 ​

[Bedrock] Amazon Bedrock introduces API keys to streamline development in GovCloud regions ​

概要 ​

Amazon BedrockでのAPIキー認証がAWS GovCloud (US) リージョンでも利用可能になりました。これにより、IAMプリンシパルやポリシーを手動で構成することなく、コンソールやSDKから素早くアクセス資格情報を発行して生成系AIの開発を加速できます。

変更内容・新機能の詳細 ​

今回の拡張で、Amazon Bedrockは商用リージョンに続きAWS GovCloud (US) リージョンでもAPIキーによる認証をサポートします。開発者はBedrockコンソールまたはAPI/SDKから短期および長期のAPIキーを作成でき、これらのキーを使ってBedrockモデルへのAPI呼び出しを認証します。短期APIキーはコンソールセッションの継続時間、または最長12時間まで有効（短い方が優先）で、主に一時的な開発やデバッグ用途に適しています。長期APIキーは有効期限を定義でき、AWS IAMコンソールからキーの管理（作成、無効化、削除）が可能であるため、継続的なアプリケーション認証に利用できます。キーはコンソールとSDKの両方から生成可能で、これにより初期のプロトタイピングや短期的な統合作業でIAMロールやポリシーを都度作成する必要がなくなります。同機能はAmazon Bedrockが利用可能な商用およびGovCloudのリージョンで利用できます。詳細な実装例やコードスニペットは公式ドキュメントおよびブログ記事を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、MLエンジニア、SRE/運用チーム
  • 利用シーン: 素早いプロトタイピングやモデル統合時の認証簡略化（短期デバッグ、PoC、CI/CDテスト環境）
  • 運用効果: IAMプリンシパルやポリシーの手作業を減らし、初期開発速度を向上。長期キーを用いた運用では継続的なサービス認証の手間を削減

技術的な注意点 ​

  • IAM権限: APIキー作成・管理には対応するIAM権限が必要。IAMポリシーでキー作成/削除権限の最小化を検討してください。
  • リージョン制限: 本アップデートはAWS GovCloud (US) と商用リージョンのBedrock提供リージョンに適用。利用可否は各リージョンのBedrock提供状況を確認してください。
  • キー有効期限: 短期キーはコンソールセッションまたは最大12時間で失効。長期キーは有効期間を設定可能／管理はIAMコンソールから行います。
  • キー管理・ローテーション: 長期キーを運用で使う場合はローテーション・失効手順を整備し、不要キーは速やかに無効化してください。
  • セキュリティ: APIキーは資格情報の一種のため漏洩防止が必須。環境変数やシークレットマネージャー等で安全に保管し、最低権限の考え方を併用してください。
  • コンプライアンス/GovCloud: GovCloudでの提供により、米当局向けのセキュリティ・コンプライアンス要件を満たすケースでの利用が容易になりますが、具体的な規制適合はユーザー側で確認してください。
  • コスト: APIキー自体に追加料金は通常発生しませんが、BedrockのAPI呼び出しやモデル利用にかかるコストは別途発生します。

参考情報 ​

[Iot Device Management] AWS IoT Device Management launches Wi-Fi Simple Setup for managed integrations ​

概要 ​

AWS IoT Device Managementは、管理された統合（managed integrations）向けにWi‑Fi Simple Setup (WSS) を追加しました。これによりQRコードを使った簡易Wi‑Fiプロビジョニングで、エンドユーザーのデバイスセットアップをほぼゼロタッチ化できます。

変更内容・新機能の詳細 ​

WSSはmanaged integrations経由で動作し、ソリューションプロバイダーがユーザーのWi‑Fi認証情報を安全に保存しておくことで、新しいデバイスの導入時にQRコードスキャンだけで接続を完了できます。一般的なフローは（1）ユーザーがモバイルアプリで自身のWi‑Fi情報をmanaged integrationsに登録、（2）新しいデバイスの電源投入後にデバイス固有のQRコードをモバイルアプリでスキャン、（3）IoTハブが一時的に隠しAP（hidden network）をブロードキャストし、ハブ経由で保存済みの認証情報をデバイスへ安全に転送、という流れです。managed integrationsは複数ベンダー・複数プロトコルのデバイスを管理できるため、Wi‑Fi対応デバイスのオンボーディングを統一された仕組みで自動化できます。なおmanaged integrationsのWSS機能は記事時点で Canada (Central) と Europe (Ireland) に展開されています。

影響範囲・利用シーン ​

  • 対象ユーザー: IoTソリューション開発者、デバイスベンダー、プロビジョニングを簡易化したいSaaS/サービス事業者
  • 利用シーン: スマート家電や商用センサー等の消費者向け・企業向けWi‑Fiデバイスの初期セットアップ（QRコードを使ったモバイルアプリ経由のオンボーディング）
  • 運用効果: エンドユーザーのセットアップ時間短縮とサポートコール削減、現場での手動Wi‑Fi入力や手順ミスの低減
  • 導入範囲: 複数ベンダーを含むmanaged integrationsベースのIoTソリューションに適用可能で、既存のデバイス管理ワークフローへ組み込みやすい
  • 制限: 機能は記事時点で Canada (Central) と Europe (Ireland) のリージョンに限定されるためリージョン依存の影響あり

技術的な注意点 ​

  • IAM権限: managed integrationsおよびIoT Device Managementを操作するためのIAM権限（IoT:*, device-management関連権限）を適切に付与する必要があります
  • リージョン制限: WSS対応のmanaged integrationsは Canada (Central) と Europe (Ireland) のみで利用可能（記事公開時）。他リージョンでの利用可否はドキュメントやコンソールで確認してください
  • コスト: IoT Device Managementやmanaged integrationsの利用料、データ転送、APIリクエスト等による追加コストが発生する可能性があります。モバイルアプリ・バックエンド側の運用コストも考慮してください
  • セキュリティ: Wi‑Fi認証情報の保存・転送は暗号化とアクセス制御が重要。QRコード自体には認証情報を直接埋め込まない設計が推奨されます。証明書ベースのデバイス認証やTLS、最小権限のIAMロールを併用してください
  • 前提条件: デバイス側がWi‑Fi接続（ステーション／AP切替や一時APによる初期化）に対応していること、ソリューション側でモバイルアプリのQRスキャン機能とmanaged integrationsの連携が実装されていることが必要です
  • 互換性: managed integrationsはマルチベンダーを想定しますが、各ベンダー・デバイスの実装差（Wi‑Fiチップの動作、AP検出方法等）を事前検証してください
  • 運用注意: 資格情報のローテーションや失効、オンボーディング失敗時のフォールバック（手動設定フロー）の用意を検討してください

参考情報 ​

概要 ​

AWS Transform customがAWS PrivateLinkに対応し、利用可能リージョンを米国東部（バージニア北部）に加えて欧州（フランクフルト）リージョンに拡張しました。これによりVPC内からインターネット経由せずにコード変換サービスへ安全にアクセスできます。

変更内容・新機能の詳細 ​

AWS Transform customは、言語バージョンアップ、API移行、フレームワーク更新などの繰り返し行うコード変換作業を自動化するサービスです。エージェントは大規模コードベースに対して一貫性のある変換を実行するために設計されており、自然言語やドキュメント、コードサンプルからカスタム変換定義を作成できます。また、Java、Python、Node.jsなどの一般的なシナリオについてはAWS管理の変換定義が利用可能で、実行を重ねることで継続的学習により変換品質が向上します。今回のアップデートで、サービスへのアクセスにInterface VPCエンドポイント（AWS PrivateLink）を利用できるようになり、トラフィックをパブリックインターネットに出すことなくTransform customに接続可能になりました。加えてeu-central-1（Europe (Frankfurt)）リージョンでの利用が開始され、リージョンローカルでの低遅延・データ主権要件への対応が強化されます。

影響範囲・利用シーン ​

  • 対象ユーザー: エンタープライズ開発チーム、コンサルティングパートナー、SRE/プラットフォームチーム
  • 利用シーンまたは効果: 大規模リファクタリング・言語/フレームワークの一括アップグレード、自動化されたAPI移行作業の一貫実行
  • セキュリティ/コンプライアンス効果: PrivateLinkを使うことでトラフィックがVPC内に留まり、パブリックインターネットを経由しないため規制・コンプライアンス要件に適合しやすくなる
  • 運用効果: エージェントによる反復的変換の自動化で人的ミスを削減し、コードベース全体への適用を高速化できる
  • リージョン影響: 新たにeu-central-1で利用可能になったため、欧州拠点のレイテンシ・データ主権要件に対応可能（ただしその他リージョンでは未提供の可能性あり）

技術的な注意点 ​

  • IAM権限: サービス使用にはTransform custom固有のAPI呼び出し権限やエージェントの実行権限が必要です。PrivateLinkを作成/利用するにはec2:CreateVpcEndpointなどVPCエンドポイント関連の権限が必要です。
  • ネットワーク設定: PrivateLink利用時はInterface VPCエンドポイントを作成し、関連するセキュリティグループ・DNS解決（enablePrivateDns）を適切に設定する必要があります。エージェントはVPC内からそのエンドポイントへ到達できる必要があります。
  • リージョン制限: 本リリースでの提供は既存の米国東部（バージニア北部）と新たに欧州（フランクフルト）のみです。他リージョンでの利用は順次対応の可能性がありますので事前確認が必要です。
  • コスト: Interface VPCエンドポイントの時間課金およびデータ処理料金が発生します。Transform custom自体の利用料金（実行リクエストやデータ転送等）がある場合はそれも加算されるため、コスト試算を行ってください。
  • データ保護・プライバシー: 変換処理のためにコードやメタデータが送信される設計の可能性があるため、機密コードを扱う場合はデータの保存/送信ポリシー、リージョン配置、契約上の取り扱い（SLA/データ処理協定）を確認してください。
  • エージェント運用: エージェントは実行環境にデプロイして変換を実行するため、CI/CDやバッチ実行の統合、リソース（CPU/メモリ）要件、ログ/監査の取り扱いを事前に設計してください。

参考情報 ​

[Cloud Financial Management] Enhanced Transactions view now available in AWS Billing Console ​

概要 ​

AWS Billing コンソールの「Transactions」ビューが強化され、読み込み速度の大幅改善、支払い照合の簡素化、データ精度向上を提供します。全ての商用リージョンで 2026-01-12 に一般提供されました。

変更内容・新機能の詳細 ​

Payments ページの Transactions ビューが再設計され、ミリ秒単位のページ読み込み（以前は分単位になる場合あり）や、数万件のトランザクションを持つアカウントでもタイムアウトなく完全な履歴表示が可能になりました。主な新機能は次のとおりです：包括的な残高トラッキング（請求額と利用可能残高の明確な +/- 表示）、トランザクションのステータス指標の視認性向上、詳細かつ高速なフィルタリング機能、請求書ステータスの統合表示、およびレコードを単一ビューでパフォーマンス低下なく参照できる点です。Organizations の Billing Transfer を利用する組織向けに「Usage Consolidation Account」列が追加され、複数アカウントにまたがる取引の追跡が容易になっています。公式ドキュメントにより管理・操作方法やさらなる詳細を確認できます。なお、発表ではコンソールの表示強化が中心であり、同等の機能が API/CLI で提供されているかは明記されていません。

影響範囲・利用シーン ​

  • 対象ユーザー: 財務/コスト管理担当者、SRE、クラウド運用チーム、会計・請求担当者
  • 利用シーン: 支払い履歴の照合、請求書ステータス確認、複数アカウントのトランザクション追跡、月次/四半期の決算作業
  • 運用効果: トランザクション探索と照合作業にかかる時間短縮、タイムアウトや部分的な結果取得による調査工数の削減
  • 複数アカウント運用への効果: Usage Consolidation Account 列により、Billing Transfer や組織横断の取引追跡が容易になり、統合請求の監査が効率化
  • リージョン: すべての AWS 商用リージョンで利用可能（2026-01-12 時点）

技術的な注意点 ​

  • IAM権限: 請求情報閲覧には管理アカウント（マネジメントアカウント）でのアクセス権、または Billing 閲覧権限（AWSBillingReadOnlyAccess 等）が必要です。ルートアカウントや明示的に付与された請求関連ポリシーを確認してください。
  • リージョン制限: 発表では全ての商用リージョンで有効とされています。GovCloud/China 等の特殊リージョンは明記されていないため、該当リージョンでは別途確認が必要です。
  • コスト: コンソール表示の改善による追加料金は発生しないと想定されます（発表時点）。ただしデータエクスポートや別サービス連携を行う場合は追加コストが発生する可能性があります。
  • API/CLI: 発表はコンソールの Transactions ビューの改善に焦点を当てており、同等の機能が API/CLI で利用可能かは明示されていません。自動化が必要な場合はドキュメントや API リリースノートを確認してください。
  • 組織・統合請求: 統合請求 (Consolidated Billing) や Billing Transfer を利用する場合、マネジメントアカウントでの表示権限やアカウントマッピングの理解が必要です。
  • データ精度: 表示される残高やステータスはコンソールの集計に基づきます。財務報告や会計処理には公式の請求書/請求レポートを併用してください。

参考情報 ​

[Redshift] Amazon Redshift Serverless adds queue-based query resource management ​

概要 ​

Amazon Redshift Serverlessがキュー単位のクエリリソース管理をサポートしました。ワークロードごとに専用キューを作成し、メトリクスに基づく監視ルール（Query Monitoring Rules：QMR）と自動応答を細かく設定できます。

変更内容・新機能の詳細 ​

新機能では「キュー（queue）」を作成し、各キューに対して独立したQuery Monitoring Rules（QMR）を割り当てられます。これにより、以前はワークグループ単位で一律適用されていたQMRを、ワークロード／ユーザーロール／クエリグループ単位で差別化して運用可能になります。QMRはメトリクスに基づくプレディケート（例：実行時間、CPU/メモリ消費、読み書きバイトなど）を評価し、しきい値を超えた場合に自動でクエリを中断するなどのレスポンスを実行できます。各キューは独立して動作し、そのキューに属するクエリのみが該当ルールの対象となります。管理はAWS Management ConsoleとRedshiftのAPIで行え、利用可能な監視メトリクスはドキュメント（Query monitoring metrics for Amazon Redshift Serverless）に一覧があります。機能はAmazon Redshift Serverlessをサポートする全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、DBA、SRE、分析ワークロードを管理する開発チーム
  • 利用シーンまたは効果: ワークロードごと（バッチETL、インタラクティブBI、Ad-hocクエリ等）に異なる監視・制御ポリシーを適用し、過剰なリソース消費や長時間クエリを自動で抑止
  • 運用効果: リソース競合の局所化とSLOの強制が容易になり、重要ワークロードの安定性向上と不要なコスト増加の抑制が期待できる

技術的な注意点 ​

  • IAM権限: キュー・QMRの作成・更新・割当を行うためのRedshift Serverless管理権限（コンソール/API）を付与する必要があります。最小権限のポリシー設計を推奨します
  • リージョン制限: Amazon Redshift Serverlessをサポートするリージョンで利用可能です（該当リージョンでのみ有効）
  • コスト: 機能自体に直接の追加料金は基本的に発生しませんが、ルールによりクエリが中断されることで実行時間が短縮され、コスト削減につながる可能性があります。ルール管理の運用コスト（設計・テスト）は別途発生します
  • 既存互換性: これまでのワークグループレベルのQMRは残りますが、キューに割当てられたクエリはそのキューのルールが適用されます。既存ルールとの優先関係や影響範囲は事前に検証してください
  • 運用上の注意: 重要なクエリや長時間処理が許容されるバッチには適切な例外や緩和ルールを設け、ステージング環境でルールの副作用（誤中断など）を検証してください
  • 管理方法: AWSコンソールおよびRedshiftのAPI/SDKでキューとQMRを管理できます。自動化（インフラコード）を導入する場合はAPIの安定性と権限設計に注意してください

参考情報 ​

[Govcloud Us] Amazon EBS now supports up to four Elastic Volumes modifications in 24 hours ​

概要 ​

Amazon EBSのElastic Volumes操作で、ボリュームごとに24時間のローリングウィンドウ内で最大4回まで変更を行えるようになりました。これにより、容量やボリュームタイプ、性能（IOPS/スループット）を迅速に調整でき、インスタンスの停止やボリュームのデタッチが不要です。

変更内容・新機能の詳細 ​

今回の更新で、Elastic Volumes（ModifyVolume等を使ったオンラインのボリューム変更）における回数制限が緩和され、ボリューム単位で直近24時間に開始した変更が4回未満であれば、新しい変更を前回の完了直後に即時開始できます。Elastic Volumesはサイズの拡張、ボリュームタイプ変更（例: gp2→gp3 など）、IOPS/スループットの調整をインスタンスを再起動・ボリュームのデタッチなしで実行可能です。変更は自動的に有効化され、既存ワークフローの変更は不要です。適用後、OS上でファイルシステムの拡張（Linuxではgrowpart/resize2fs、Windowsではディスクの再スキャンとボリューム拡張等）が必要になる場合があります。機能は全ての商用リージョン、AWS GovCloud (US)、中国リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、SRE、DB/アプリケーションエンジニア、DevOpsチーム
  • 利用シーンまたは効果: 突発的なデータ増加やワークロードのスパイク時に即座に容量や性能をスケールアップしてサービス継続性を確保
  • 運用効果: インスタンス停止やボリュームデタッチを伴わないためダウンタイムを最小化でき、24時間当たりの変更回数制限が緩和されたことで短時間での複数調整が可能になる

技術的な注意点 ​

  • IAM権限: ec2:ModifyVolume や ec2:DescribeVolumes などの権限が必要。自動化する場合は適切なロール/ポリシーを確認してください
  • リージョン制限: 全商用リージョン、AWS GovCloud (US)、中国リージョンで利用可能。その他特殊リージョンは要確認
  • コスト: ボリューム容量、ボリュームタイプ、設定したIOPS/スループットに基づき課金が変動します。性能を上げると料金が上がる点に注意してください
  • 変更制限: 本件は「1ボリュームあたり直近24時間で最大4回の変更開始」が上限です。ボリュームサイズの縮小（縮小不可）は通常サポートされないため、縮小はスナップショットと再作成等の手順が必要です
  • OS/ファイルシステム: サイズ拡張後にOS側でファイルシステムのリサイズが必要な場合があります。Linuxの一般的ファイルシステムや最新のWindowsではオンライン拡張が可能ですが、事前検証を推奨します
  • インスタンス制約: 一部の高性能スループット/IOPSはインスタンスのネットワーク/インスタンス仕様に依存します。期待する性能を得るためにインスタンスの仕様（Nitro等）を確認してください

参考情報 ​

[General] AWS Data Exports adds granular operation visibility for Amazon Bedrock model usage ​

概要 ​

AWS Data ExportsがAmazon Bedrockの操作種別をコストレポートで明示するようになり、従来の「Usage」ラベルに代わってInvokeModelInferenceやInvokeModelStreamingInferenceなどの詳細な操作区分が出力されるようになりました。これにより、FinOpsやコスト最適化での詳細な利用分析が可能になります。

変更内容・新機能の詳細 ​

主な変更点は、AWS Data Exports経由で出力されるコスト・使用状況レポートにおいて、Amazon Bedrockの各操作タイプが粒度高く識別できるようになったことです。具体的には：

  • Legacy CURおよびCUR 2.0では、line_item_operation列に具体的な操作名（例: "InvokeModelInference"、"InvokeModelStreamingInference"）が出力され、従来の汎用的な"Usage"ラベルが置き換えられます。
  • FOCUS向けData Exportsでは、x_Operation列に同様の粒度ある操作情報が含まれます。
  • AWS Cost ExplorerのAPIでもOperationディメンション値としてこれらの操作タイプが利用可能になり、APIやダッシュボードで直接集計・フィルタリングできます。 この可視化はAmazon Bedrock上のすべてのファウンデーションモデル（全プロバイダ）に適用されるため、プロバイダ別やモデル別、ストリーミング推論と通常推論といった利用パターンの区別・集計が可能になります。導入にあたっては、既存のCUR/FOCUSパーシングロジック・BIダッシュボード・FinOpsレポートのカラム処理を更新して新しい列名／値を取り込む必要があります。また、レポート出力を有効にしていること（CUR/CUR 2.0またはData Exportsの設定）が前提です。

影響範囲・利用シーン ​

  • 対象ユーザー: FinOpsチーム、コスト最適化担当者、SRE/運用チーム、データアナリスト
  • 利用シーンまたは効果: モデル別／操作別（通常推論 vs ストリーミング推論）の課金集計やコスト配分、異常利用検出、プロバイダ別コスト比較の精緻化
  • 運用効果: 詳細な操作単位での可視化により、無駄な呼び出しの特定、コスト削減施策の優先順位付け、モデル利用ポリシーの最適化が可能になります

技術的な注意点 ​

  • IAM権限: CURやData Exportsの設定閲覧・作成にはBilling関連の権限（organizations/billing:ViewBilling、cur:PutReportDefinition等）やS3アクセス権が必要です。Cost Explorer API利用時はce:*権限が必要になります。
  • リージョン制限: 請求データはグローバルに集約されますが、Data Exportsの設定や出力先（S3バケットのリージョン）・FOCUSのサポート状況はアカウント／リージョン構成に依存するため、設定を確認してください。
  • コスト: 本機能自体で追加料金が発生する旨の案内はありませんが、CUR/FOCUSの有効化によるS3保存、AthenaやGlueでのクエリ、Cost Explorer APIの利用には通常のストレージ・クエリ費用が発生します。
  • データフォーマット変更: 新しい操作タイプはline_item_operation（Legacy/CUR2.0）、x_Operation（FOCUS）、Cost ExplorerのOperationディメンションに出力されます。既存のETLやダッシュボード処理はこれらのカラム名と新しい値を取り込むよう更新してください。
  • 互換性: 既存レポートで"Usage"等の汎用ラベルに依存している集計ロジックは誤集計を招くため、操作別条件での再集計が必要です。
  • 対応サービス: 本改善はAmazon Bedrock（全ファウンデーションモデル）に対して適用されます。
  • 有効化手順: CUR/CUR 2.0またはAWS Data Exports（FOCUS含む）をBillingコンソールで有効化し、レポート出力先やスケジュールを確認してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026