AWS What's New Digest

Appearance

2026年07月31日 ​

[Lambda] AWS Lambda now supports Java 8, 11, and 17 on Amazon Linux 2023 ​

概要 ​

AWS LambdaがAmazon Linux 2023（AL2023）上でのJavaランタイム（Java 8、11、17）をサポート開始しました。AL2からAL2023へOS単独での移行が可能になり、同時にJavaバージョンを上げる必要はありません。

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

新たに提供されるJava 8、11、17ランタイムは、マネージドランタイムとコンテナベースイメージの両方でAL2023をサポートします。既存のAL2ベースのJavaランタイムはAL2のEOL（2026-06-30）を受け、引き続き重要度の高いセキュリティ修正等については2027-06-30までパッチ提供が行われます。AWSはAL2023上での推奨経路としてJava 21またはJava 25へのアップグレードを勧めており、これらは最新の言語機能とパフォーマンス改善を提供します。すぐにJavaのメジャーアップグレードができない場合でも、Java 8/11/17をAL2023上で動作させることでOSの移行を先行できます。新ランタイムはLambdaが利用可能な全リージョン（AWS GovCloud (US)、中国リージョン含む）で利用可能です。移行支援としては、記事で言及されている「AWS Transform custom」を利用する手段が案内されています。コンテナイメージを利用する場合はAL2023ベースのイメージに切り替えて再ビルドや互換性検証を行ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: Lambda上でJava（8/11/17）を利用している開発者、SRE/運用チーム、セキュリティ担当者
  • 利用シーンまたは効果: AL2からのOS移行（セキュリティとサポート継続）や、OSのみをAL2023に移してJavaバージョンは据え置く運用が可能に。将来的にはJava 21/25へのアップグレードで性能改善や新機能を活用可能
  • 運用効果: サポート対象およびSLA適用維持のための移行計画が容易になり、AL2のEOL後も1年間（〜2027-06-30）は重要セキュリティパッチが提供されるため移行猶予がある
  • リージョン影響: Lambdaが利用可能な全リージョンでAL2023版ランタイムが利用可能（GovCloud/China含む）

技術的な注意点 ​

  • IAM権限: コンテナイメージをECRにプッシュする場合はECRの権限、Lambda関数の更新にはlambda:UpdateFunctionCode等の権限が必要です
  • リージョン制限: 記事によれば全リージョンで利用可能。ただし導入前に対象リージョンでの確認を推奨します
  • コスト: ランタイム自体の追加費用は通常発生しませんが、移行作業（ビルド、テスト、デプロイ）やコンテナストレージ（ECR）・CI実行などの運用コストがかかる可能性があります
  • 互換性: JNIやネイティブライブラリ、OS依存のバイナリを使っている場合はAL2023向けに再ビルド／互換性検証が必要です。ライブラリのglibcやシステムパッケージの差異に注意してください
  • ランタイムサポート期限: AL2ベースのJava 8/11/17ランタイムは2027-06-30まで重要なセキュリティ修正が提供されますが、AL2023へ移行しないとサポート/ SLAの対象外になる可能性があるため計画的な移行が必要です
  • テスト: 本番切替前にステージングで動作確認、パフォーマンステスト、監視（CloudWatch）やログの挙動確認を行ってください
  • その他ツール: Javaバージョンを上げる場合はAWSが推奨するJava 21/25への移行を検討。移行支援ツール（記事のTransform系機能）も活用可能です

参考情報 ​

[General] Amazon CloudWatch announces managed Prometheus collectors ​

概要 ​

Amazon CloudWatchはフルマネージドのPrometheusコレクターを提供開始しました。これによりOpenTelemetry Collectorを自前でデプロイすることなく、EKS/EC2/ECS/MSK/OpenSearchなどからPrometheusメトリクスを収集できます。

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

新しいマネージドPrometheusコレクターは、ユーザーがスクレイプ設定（Prometheus-style scrape config）と対象リソースへの接続情報を指定するだけで、CloudWatch側がコレクターのプロビジョニング、スケーリング、収集を自動で行います。収集されたメトリクスはOpenTelemetryフォーマットでCloudWatchに取り込まれ、PromQLでのクエリが可能です。これによりAWSが提供するメトリクス（vended metrics）と同一のビューでアラーム/ダッシュボード/クロスサービス相関を行えます。サポートされるディスカバリ方法は、Kubernetesサービスディスカバリ（EKS）、AWS Cloud Mapを使ったDNSベースのサービスディスカバリ（ECS）、インスタンス直接スクレイプ（EC2）、およびMSK/OpenSearchのオープンな監視エンドポイントです。EKS・MSK・OpenSearchのメトリクスは自動ダッシュボードで可視化でき、PromQLクエリとCloudWatchアラームに利用可能です。利用可能リージョンはCloudWatch OTLPエンドポイントが存在する全リージョン（Asia Pacific (New Zealand) を除く）。課金はコレクター時間課金と標準のCloudWatch OpenTelemetryメトリクス取り込み料金が適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/プラットフォームエンジニア、SRE、アプリ開発チーム、運用チーム
  • 利用シーンまたは効果: 自前でOpenTelemetry Collectorを運用せずにEKS/ECS/EC2/MSK/OpenSearchのPrometheusメトリクスを一元収集・クエリ・アラート化できる（運用負荷の低減、運用コストの簡素化）
  • 運用効果: スケーリングや可用性の管理不要になり、PromQLでAWSマネージドメトリクスと組み合わせたクロスサービス相関や統合アラートが容易になる

技術的な注意点 ​

  • IAM権限: コレクターの作成・管理やリソースへのアクセスに必要なCloudWatch/OTEL関連のIAM権限が必要（事前に権限設計を確認してください）
  • リージョン制限: CloudWatch OTLPエンドポイントが存在するリージョンで利用可（ただし Asia Pacific (New Zealand) は除く）
  • ネットワーク/接続: 対象のメトリクスエンドポイント（Pod/EC2インスタンス/MSK/OpenSearch）がCloudWatchコレクターから到達可能であることが必要。VPCエンドポイントやセキュリティグループ等のネットワーク設定を確認してください
  • コスト: コレクターの時間課金が発生し、加えてCloudWatchのOpenTelemetryメトリクス取り込み料金が適用されます。メトリクス量と保存期間によるコスト増加を見積もってください
  • 互換性/メトリクス命名: メトリクスはOpenTelemetry形式で取り込まれるため、一部のPrometheusラベルや命名（job/instance等）のマッピングに差異が出る可能性があります。クエリ/ダッシュボードを移行する際に確認が必要です
  • サービスディスカバリ: EKSはKubernetesサービスディスカバリ、ECSはAWS Cloud Mapを使用するため、それぞれのサービスディスカバリ設定（Cloud Map登録など）が整っていることを確認してください
  • 移行考慮点: 既存の自己管理OpenTelemetry Collectorを置き換える場合、スクレイプ設定・リラベリング・認証情報（TLS/Basic/Authヘッダ等）をマネージドコレクター設定へ移行する必要があります

参考情報 ​

[Ec2] AWS CodeDeploy now available in five additional AWS regions ​

概要 ​

AWS CodeDeployがアジア太平洋（ニュージーランド、タイ、台北、マレーシア）とメキシコ（中部）の5リージョンで利用可能になりました。これにより、該当リージョンのユーザーは低遅延でローカルにデプロイサービスを利用でき、データレジデンシー要件に対応できます。

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

AWS CodeDeployは、Amazon EC2インスタンス、オンプレミスサーバー、AWS Lambda関数、およびAmazon ECSサービスへのアプリケーションデプロイを自動化するフルマネージドサービスです。今回のリリースで以下が利用可能になりました。

  • 新規対応リージョン: Asia Pacific (New Zealand), Asia Pacific (Thailand), Asia Pacific (Taipei), Asia Pacific (Malaysia), Mexico (Central)
  • 機能: インプレース・ブルー/グリーン等のデプロイ方式や、数台から数千台規模へのスケール、自動ロールバックやデプロイライフサイクルイベントによるカスタムフックの実行など、既存のCodeDeploy機能をローカルで利用可能
  • 運用面: 手動操作を削減してデプロイ標準化を実現し、ダウンタイム低減やリリース速度の向上に寄与
  • グローバル展開: 商用リージョンで34リージョン、さらにAWS GovCloud (US)と中国リージョンでも提供されているため、グローバルなデプロイ戦略にも組み込みやすい

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、DevOpsエンジニア、SRE、およびオンプレ/クラウド混在環境を運用するチーム
  • 利用シーン: ローカルリージョン内での低遅延デプロイ、データレジデンシー対応が必要な法令準拠環境での継続的デリバリーパイプライン
  • 運用効果: デプロイの自動化と標準化により人的ミスを削減し、ローリングやブルー/グリーンでの無停止リリースを実現。地域内運用により遅延低減とトラブルシューティングの迅速化が期待できる

技術的な注意点 ​

  • IAM権限: CodeDeployの利用にはサービスロール（CodeDeployサービスロール）や対象リソース用のインスタンスプロファイル、Lambda/ECS向けの適切な実行ロールが必要です。事前にポリシーを確認してください。
  • リージョン制限: 本発表で5リージョンが追加されましたが、全機能（例: 特定のデプロイ方式や統合機能）が即座に全リージョンで同等に提供されるとは限りません。利用前にコンソールまたはドキュメントで各機能の対応状況を確認してください。
  • コスト: CodeDeploy自体はユースケースにより追加料金のないケースもありますが（サービス仕様に依存）、デプロイアーティファクトの保存（S3）、CloudWatch Logs、データ転送など関連リソースに対する課金が発生する可能性があります。コスト影響を事前に見積もってください。
  • アーティファクト配置: デプロイ用リビジョンはS3やCodeCommit/GitHub等を利用します。可能であれば同リージョン内のS3バケットを使用してレイテンシーと転送コストを最小化してください。
  • サービスクォータ: 大規模デプロイ時は同時デプロイ数やAPIレート制限などのクォータに注意し、必要に応じてAWSサポートへ引き上げ申請を行ってください。

参考情報 ​

[SageMaker] Amazon SageMaker Unified Studio brings richer Git version control to all project tools ​

概要 ​

Amazon SageMaker Unified Studioは、Query Editor、Visual ETL、Workflows、NotebooksなどのStudio内ツールから直接、ファイル単位の柔軟なGit版管理を提供する機能を拡張しました。従来の自動同期方式に替わり、プロジェクト単位で強制されない選択的なリポジトリ管理とブランチ操作が可能になります。

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

主な変更点は以下の通りです。 ・ファイル単位のバージョン管理: 以前の自動同期（プロジェクト全体を同期するモデル）を置き換え、ユーザーが追跡するファイルを明示的にリポジトリに追加して管理できます。これにより不要なファイルをバージョン管理から除外できます。 ・統一されたGit体験: Query Editor、Visual ETL、Workflows、そしてこれまでGitサポートがなかったNotebooksを含む全てのプロジェクトツールで一貫したソース管理が利用可能になりました。 ・複数リポジトリ／ブランチの同時接続: プロジェクトは任意のタイミングで複数のリポジトリやブランチを接続でき、プロジェクト作成後でもリポジトリを追加できます（リポジトリはプロジェクト作成から分離されています）。 ・プロジェクト内でのブランチ操作と競合解消: ブランチ作成、最新の取り込み（pull）、競合の解決、コミット／プッシュがプロジェクト画面内で実行可能です。複数の変更をまとめて1アクションでコミット＆プッシュできます。 ・外部Gitプロバイダー対応とCLIアクセス: GitHub、GitLab、Bitbucketのリポジトリをサポート。JupyterLabやCode Editorを使用している場合は、組み込みターミナルから通常のGit CLIアクセスも維持されます。 ・導入と互換性: 機能はAmazon SageMaker Unified Studioをサポートする全リージョンで利用可能で、IAMおよびIAM Identity Centerドメインの両方に対応。既存のプロジェクトで旧Git体験を利用している場合は、プロジェクトを更新して新しいモデルへオプトインできます。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、MLOps/SRE、データエンジニア
  • 利用シーン: ノートブックやETLフロー、クエリ、ワークフローのコード／設定を選択的にバージョン管理してチームで共有・レビューフローを回す場合（例: 実験トラッキング、モデル再現性、CI/CD統合）
  • 運用効果: 不要ファイルを排除した軽量なリポジトリ管理、Studioから出ずにブランチ操作や競合解消が可能になり開発サイクルとコラボレーション効率が向上する

技術的な注意点 ​

  • IAM権限: SageMakerおよび関連リソース（必要に応じてSecrets ManagerやSystems Manager Parameter Store）への適切なIAM権限を確認してください。Git接続の設定やシークレット参照に追加権限が必要です。
  • Git認証: GitHub/GitLab/Bitbucket側の認証（パーソナルアクセストークン、OAuth、SSHキー等）の設定が必要です。プライベートリポジトリを使う場合は認証情報の管理手順を確立してください。
  • リージョン制限: 本機能はAmazon SageMaker Unified Studioをサポートするリージョンで利用可能です。Studio自体が未対応のリージョンでは利用できません。
  • ネットワーク/アクセス: プライベートなGitホスティング（オンプレやVPC内サービス）を利用する場合は、必要なネットワーク経路（VPC接続やプロキシ、エンドポイント等）を確保してください。
  • 既存プロジェクト移行: 旧来の自動同期方式を使っているプロジェクトはオプトインで新モデルへ切替可能です。移行前に追跡対象ファイルや.gitignore相当の取扱いを設計してください。
  • コスト: この機能自体に専用の追加料金は明示されていませんが、SageMakerの利用時間、データ転送、関連サービス（Secrets Manager等）の利用に基づく通常の料金が発生します。
  • 運用上の注意: ファイル単位で追跡するため、環境定義（依存ライブラリやシステム設定）を管理しないと再現性に影響が出ます。環境設定ファイルやランタイム依存は明示的にバージョン管理することを推奨します

参考情報 ​

[Direct Connect] AWS Direct Connect now supports BGP route visibility on Virtual Interfaces ​

概要 ​

AWS Direct ConnectがBGPルートの可視化機能を提供開始しました。Direct Connectの仮想インターフェイス（プライベート/トランジット/パブリックVIF）間で交換されるBGPルートの受信・送信情報をコンソールおよびAPIで確認できます。

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

この機能では、Direct Connectがあなたのオンプレミスルーターから受け入れたルート（accepted routes）とAWSがあなたのルーターに広告しているルート（advertised routes）を一覧表示できます。各ルートについてプレフィックス、アドレスファミリー（IPv4/IPv6）、ASパス、BGPコミュニティ値、インストールタイムスタンプが表示され、プレフィックス・ASパス・コミュニティ・アドレスファミリーでのフィルタリングが可能です。表示はDirect Connectコンソールから参照できるほか、ListVirtualInterfaceRoutes APIを使ってプログラム的に取得できます。対象はプライベートVIF、トランジットVIF、パブリックVIFで、多地域の複雑な構成やBGPポリシーの検証、想定外のトラフィック経路の診断に有用です。機能は全てのAWS商用リージョンと中国リージョン（北京／寧夏）で利用可能とされています。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワークエンジニア、SRE、ハイブリッドネットワークを管理する運用チーム
  • 利用シーン: BGPネイバーのルート交換状況確認、ルート伝播の検証、BGPポリシー（フィルタ・コミュニティ）の動作確認
  • 運用効果: ルーティング障害の原因特定を迅速化し、誤った広告や受信ルートによるトラフィック逸脱を早期に検出可能
  • 複雑構成での利点: マルチリージョン/トランジットゲートウェイを跨ぐ経路の可視化により設計・検証負荷を低減
  • 制限に関する注意: 表示されるのはVIFレベルのBGP経路であり、VPCルートテーブルやTransit Gatewayの内部伝播状況は別途確認が必要

技術的な注意点 ​

  • IAM権限: ListVirtualInterfaceRoutes APIを呼ぶにはdirectconnect:ListVirtualInterfaceRoutes等の権限が必要。コンソール操作にはDirect Connectの表示権限が必要です
  • リージョン制限: 全AWS商用リージョンおよび中国リージョン（北京: Sinnet、寧夏: NWCD）で利用可能と明記されています。その他の特殊リージョンは公式情報を確認してください
  • コスト: 公開情報ではこの可視化機能自体に追加料金は明記されていませんが、APIコール数や運用の増加による間接コスト（監視自動化・ログ保存等）は考慮してください
  • 可視範囲: 表示はVIFレベルでの受信/送信ルートのスナップショットです。AWS内部でのルート選択やVPC/Transit Gatewayへの伝播は別の制御要素（ローカルプレファレンス、AWSのルート選択等）で決まります
  • 実装上の注意: API利用時はページネーションやレート制限に注意してください。また、BGP収束のタイミングによる一時的な差分が出ることがあるため、時刻情報（インストールタイムスタンプ）を確認して事象と突合してください

参考情報 ​

[Redshift] Amazon Redshift RG large and 12xlarge instances now available on the trailing track ​

概要 ​

Amazon RedshiftのGravitonベースRGインスタンス（rg.large、rg.12xlarge）がトレーリングメンテナンストラック（パッチP202以降）で利用可能になりました。安定性を重視する本番環境でもGravitonの性能とコスト優位を活用できます。

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

トレーリングトラック（既にリーディングトラックで検証済みのバージョン）で、rg.largeとrg.12xlargeがパッチP202以降で利用可能になりました。これにより、RGインスタンスはリーディング／トレーリング両トラックで利用できるようになり、AWS Gravitonプロセッサのメリット（RA3に比べ最大2.4倍のクエリ性能、vCPUあたり約30%低い価格）を安定バージョンで享受できます。対象リージョンは、RGが一般提供（GA）されている全リージョンです。新規クラスタ作成または既存クラスタのリサイズでrg.large／rg.12xlargeへ変更可能で、操作はAWSマネジメントコンソール、AWS CLI、AWS SDKで実行できます。詳細はAmazon Redshiftのクラスタバージョン管理（パッチ/トラック）に従ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: Redshiftを本番で利用するデータエンジニア、SRE、BIチーム
  • 利用シーン: 安定版パッチでGravitonの高性能・低コストを利用したクエリ高速化、コスト最適化（新規クラスター構築、既存クラスターのインスタンスタイプ変更）
  • 運用効果: 本番向けの安定トラックでGravitonインスタンスを使えるため、クエリ性能向上とvCPUあたりコスト削減が期待できる（リソース削減やスループット向上によるコスト効率改善）

技術的な注意点 ​

  • IAM権限: クラスター作成・リサイズにはredshift:CreateCluster、redshift:ModifyCluster、関連するIAM/STS/EKS権限が必要です。コンソール/CLI経由で作業するユーザーの権限を確認してください。
  • リージョン制限: RGインスタンスはRGがGAのリージョンで利用可能です。全リージョンで自動的に利用可能になるわけではないため、対象リージョンを事前確認してください。
  • バージョン/互換性: トレーリングトラックのパッチP202以降が必須です。既存クラスタが古いパッチの場合はトラック切替やパッチ適用が必要になります（運用ポリシーに従って検証を実施してください）。
  • リサイズと稼働影響: インスタンスタイプの変更やノード構成変更はリサイズが必要で、クラシックリサイズやスナップショット／復元が発生する場合がありダウンタイムが発生する可能性があります。Elastic Resizeが利用可能かどうかで影響時間が変わります。
  • コスト: ドキュメントの通りvCPU単価はRA3より低いとされていますが、実運用ではノード数・ストレージ構成・クエリ負荷により総コストが変わります。導入前にワークロードでのベンチマークと見積りを推奨します。
  • 性能検証: 最大2.4xの性能改善はワークロード依存です。実用にあたっては代表クエリでベンチマークを行い、レイテンシ、スループット、並列性、IO/メモリ特性を確認してください。

参考情報 ​

[IAM] IAM Policy Simulator moves to the IAM console and adds additional capabilities ​

概要 ​

IAM Policy Simulatorが独立サイトからIAMコンソールに統合され、サービスコントロールポリシー（SCP）の評価やポリシー除外などの新機能が追加されました。これによりポリシーのユニットテストやガードレール検証をより実務に即して実行できます。

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

主な変更点は三つです。1) コンソール統合: 既存のスタンドアロン版を置き換え、IAMコンソールの「Policy simulator」メニューから利用可能になりました。2) SCPの評価: 組織のサービスコントロールポリシーをシミュレーションに含めて、SCP階層がアイデンティティポリシーやリソースポリシーとどのように相互作用するかを検証できます（組織のガードレールが意図どおり機能するかの確認が可能）。3) シミュレーション柔軟性の向上: API経由でリージョン制限やタグ要件などの条件キーを考慮したテストができるようになり、特定のポリシーを除外して「このポリシーを外すとどうなるか」を検証する機能が追加されました。また、クロスアカウントのシミュレーションでは、アイデンティティベースとリソースベースの各ポリシーごとの判定結果を返し、拒否に寄与したポリシーのマッチしたステートメントのみを結果に含めるようになりました。これらはSimulatePrincipalPolicyおよびSimulateCustomPolicy APIで利用でき、テスト自動化やCIパイプラインへの組み込みが容易です。機能はIAM Policy Simulatorが提供されているリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: IAM管理者、セキュリティ/ガバナンスチーム、プラットフォーム/インフラエンジニア、SRE
  • 利用シーン: ポリシーのユニットテストとCI連携によるデプロイ前検証、SCPを含めたガードレール検証、クロスアカウントアクセスのトラブルシューティング
  • 運用効果: デプロイ前に過剰権限やガードレールの逸脱を検出できるため、セキュリティリスク低減と運用コスト削減につながる

技術的な注意点 ​

  • IAM権限: シミュレーション実行には iam:SimulatePrincipalPolicy や iam:SimulateCustomPolicy などの権限が必要です。SCPを参照・含める場合は組織のポリシー閲覧に関する権限（AWS Organizationsの読み取り権限）も必要になる場合があります。
  • リージョン制限: IAM Policy Simulatorがサポートするリージョンで利用可能です。リージョン未対応の場合は利用不可になるため、事前に対象リージョンを確認してください。
  • コスト: コンソールおよびAPIのシミュレーション自体に追加料金は基本的に発生しません（ただし大量の自動実行による関連API呼び出し数やログ出力に伴うコストは別途発生する可能性があります）。
  • API/自動化: 新機能は SimulatePrincipalPolicy / SimulateCustomPolicy API で利用可能です。CI/CDへの組み込みや単体テストの自動化が可能なので、APIパラメータ（例: ポリシー除外、SCPの包含、条件キー指定）を確認して実装してください。
  • 動作上の注意: クロスアカウントシミュレーションでは、返される「マッチしたステートメント」が拒否に寄与したポリシーのみを反映するよう改善されていますが、期待どおりの判断を得るために対象ポリシー群を明示的に指定してテストすることを推奨します。
  • 移行/運用: 旧スタンドアロンURLからの遷移が必要になります。既存のブックマークや自動化で旧エンドポイントを参照している場合は修正してください。

参考情報 ​

[Bedrock] Amazon Bedrock announces up to 80% lower prices for OpenAI GPT‑5.6 models ​

概要 ​

Amazon Bedrock上のOpenAI GPT‑5.6モデル（LunaとTerra）の推論料金が、GPT‑5.6 Lunaで最大80%、GPT‑5.6 Terraで20%引き下げられました。変更は2026年7月30日付で自動適用されます。

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

OpenAIの価格改定に合わせて、Amazon Bedrockのオンデマンド推論料金が更新されました。GPT‑5.6 Lunaは高速で高スループットなワークロード向けに最適化されており、ツール連携（マルチステップワークフロー）を利用した処理に向いています。想定ユースケースには大量のコンテンツ処理、分類、カスタマーサービスの自動化、定型的な実装作業などが含まれます。一方、GPT‑5.6 Terraは推論の知能・速度・コストのバランスに優れ、より高度な推論を必要とする日常的な本番ワークロードに適しています。GPT‑5.6 Lunaの価格は80%削減、GPT‑5.6 Terraは20%削減、GPT‑5.6 Solの価格は変更なしです。新価格は顧客側の設定変更を必要とせず自動適用されます。これらのモデルはOpenAI Responses APIを通じてbedrock-mantleエンドポイント経由で提供され、利用可能リージョンは US East (N. Virginia)、US East (Ohio)、US West (Oregon) です。詳細および最新価格はAmazon Bedrockのドキュメントと価格ページをご確認ください。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、アプリ開発者、SRE/運用チーム、AIを組み込むプロダクトオーナー
  • 利用シーンまたは効果: コンテンツ処理や分類、チャットボット/カスタマーサポート自動化、バッチ推論や高スループットAPI呼び出しでコスト削減を実現
  • 運用効果: 単位タスクあたりのコスト低下により、より大規模なワークロードの処理やモデル適用範囲の拡大が可能
  • コスト影響: Lunaで最大80%削減、Terraで20%削減。モデル利用料が下がるためTCO改善が期待できる
  • リージョン影響: 現時点では US East (N. Virginia)、US East (Ohio)、US West (Oregon) のみで提供

技術的な注意点 ​

  • IAM権限: BedrockとOpenAIモデルの呼び出しに必要なIAM権限（bedrock:InvokeModel など）を確認してください
  • リージョン制限: GPT‑5.6 Luna/Terraは現在 US East (N. Virginia)、US East (Ohio)、US West (Oregon) のみで利用可能です
  • コスト: モデル推論料金は低減しますが、データ転送、ストレージ、その他AWSサービスの利用に伴う料金は別途発生します。最新の料金はBedrockの料金ページで確認してください
  • API/エンドポイント: OpenAI Responses API互換の呼び出しを bedrock-mantle エンドポイント経由で行います。既存のAPI呼び出し方法に大きな変更は不要ですが、エンドポイント/モデル名の指定を確認してください
  • 互換性: GPT‑5.6 Sol の価格変更はありません。モデル特性（Lunaは高速・高スループット、Terraはバランス型）を踏まえて選択してください
  • 設定変更: 価格変更は自動適用されるため顧客側での設定変更は不要です
  • 監査/請求: 請求明細でモデル別の使用量と費用を確認してください

参考情報 ​

[Virtual Private Cloud] AWS announces general availability of Policy-Based Routing on AWS Transit Gateway ​

概要 ​

AWS Transit GatewayでPolicy-Based Routing（PBR）が一般提供になりました。送信元/宛先IP、ポート、プロトコルなどパケット属性に基づき転送先ルートテーブルを選択でき、追加のVPCや経路ホップを作らずにトラフィックを柔軟に制御できます。

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

PBRはTransit Gatewayに紐づく“ポリシーテーブル”を使って動作します。顧客はTransit Gatewayアタッチメントにポリシーテーブルを関連付け、順序付きのルールセットを定義します。各ルールはパケット属性（送信元/宛先IPアドレス、ポート、プロトコルなど）でトラフィックを分類し、マッチしたパケットを指定のTransit Gatewayルートテーブルへ転送します。ルール適用は「first-match-wins（先にマッチしたルールを適用）」です。これにより、例えば機密ワークロードをAWS Network Firewallやサードパーティの検査アプライアンス経由で通す、送信元によりDirect Connect/VPN経路を選ぶ、プロダクションと開発を別ルーティングドメインに分離して横移動を制限するといったユースケースが簡素化されます。PBRはAWS Management Console、AWS CLI、SDKで設定可能で、全ての商用リージョン（Transit Gatewayが提供されているリージョン）で利用可能です。料金は従来のTransit Gateway料金に含まれ、PBR自体に追加料金は発生しません。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワークアーキテクト、セキュリティチーム、エンタープライズのクラウドネットワーク運用者
  • 利用シーン: トラフィック検査（Network Firewall/サードパーティ検査アプライアンス）へのステアリング、送信元/プロトコルに応じたDirect Connect/VPN経路選択、プロダクション/開発環境のルーティング分離
  • 運用効果: 追加VPCや複雑な経路ホップを削減し、インラインでのトラフィック分類・転送が可能になるため設計と運用の簡素化、セキュリティ境界の強化、およびトラブルシューティングの単純化が期待できる

技術的な注意点 ​

  • IAM権限: Transit Gatewayのポリシーテーブル、アタッチメント、ルートテーブルを作成/変更/参照する権限が必要（Transit Gateway関連のEC2 API操作やコンソール操作を許可するポリシーを準備してください）。
  • リージョン制限: 全ての商用AWSリージョン（Transit Gatewayが提供されているリージョン）で利用可能と発表されていますが、導入前に対象リージョンで正式に有効化されていることを確認してください。
  • コスト: PBR自体に追加料金は発生しません。従来通りTransit Gatewayのデータ転送・アタッチメント費用等が適用されます。ステアリング先にあるNetwork Firewallやサードパーティアプライアンス、Direct Connect等の利用料金は別途発生します。
  • 設計上の注意: ルールは順序付きでfirst-match-winsのため、ルールの並び（優先順位）設計が重要です。未マッチトラフィックがどのルートテーブルに流れるかを事前に確認してください（既存のTransit Gatewayルーティング挙動との整合を取る必要があります）。
  • 運用/監視: ポリシー変更がトラフィック経路に即時影響を与えるため、変更運用（CI/CDや変更管理）と監視（フローログやネットワーク監査ログ）を整備してください。非対称ルーティングや検査アプライアンスの戻り経路による通信断を避けるため、双方向の経路設計を確認してください。
  • パフォーマンス/スケーリング: PBRは追加料金を伴わないものの、Transit Gateway自体のスループットや接続上限、検査アプライアンスの処理能力を考慮した設計が必要です。特に大量フローの分類が増える環境では負荷を評価してください。

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026