AWS What's New Digest

Appearance

2026年06月02日 ​

[General] Amazon Location Service announces public transit and intermodal routing ​

概要 ​

Amazon Location ServiceのRoutes APIが公共交通（Transit）と複合モード（Intermodal）ルーティングをサポートしました。これにより、徒歩・自動車・タクシー・レンタル＋公共交通を組み合わせた経路計算が可能になります。

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

CalculateRoutesオペレーションに新たに travelMode として "Transit" と "Intermodal" が追加されました。Transitモードではバス、地下鉄、列車、フェリー等の公共交通を使ったポイント間ルートを算出し、停留所までの徒歩経路、発着時刻（スケジュール対応）、および路線情報（路線IDや運行区間等）を含む結果が返ります。Intermodalモードは複数の輸送手段を単一ルートで組み合わせる機能で、典型的なパターン（park-and-ride、taxi-and-ride、ラストマイルをタクシー/レンタルで完了する等）をサポートします。APIレスポンスは通常の経路ジオメトリ、レッグ／セグメント単位の指示、所要時間・距離、乗換情報や発着時刻などを含み、アプリはこれらを使って時刻表に基づくナビゲーションや乗換案内、複合移動計画を実装できます。機能は指定の複数リージョンで提供されており、導入ガイド・Transit/Intermodalの専用ドキュメントおよびCalculateRoutes APIリファレンスで利用方法とパラメータ例が確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: モビリティアプリ開発者、物流・配送システム、通勤管理・従業員トランスポート設計者、都市計画・交通解析担当者
  • 利用シーン: 公共交通＋徒歩の乗換案内、車で駐車して公共交通に乗り換える経路提示（park-and-ride）、タクシーやレンタルでラストマイルを補完する複合ルート設計、通勤最適化やルートコスト評価
  • 運用効果: ユーザーに対して実利用に即したマルチモーダル経路を提供でき、正確な到着時刻や乗換情報により利便性と信頼性が向上。モビリティ最適化や混雑回避、業務の効率化（配送や社員送迎の経路最適化）に貢献
  • 導入影響: 既存のRoutes API導入アプリはパラメータ追加で公共交通対応が可能。UI/UXは複合経路の表示・乗換案内・時刻表表示に合わせて拡張が必要
  • リージョン依存: 機能は限定リージョンで提供（下記technicalNotesに地域一覧）

技術的な注意点 ​

  • IAM権限: CalculateRoutes呼び出しに必要なAmazon Locationの権限（例: locations:CalculateRoutes）を付与してください。必要に応じてリソースレベル制御を検討
  • リージョン制限: 現時点で利用可能なリージョンは US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain), South America (São Paulo) のみです。東京リージョン等の対応状況は上記リストで確認してください
  • コスト: CalculateRoutesの呼び出し数に基づく課金が発生します。新しいtravelModeが追加されてもリクエスト単位の料金体系やレート制限が適用されるため、コスト見積りとキャッシュ戦略（頻繁な同一ルートの再計算を避ける等）を検討してください
  • データ品質・更新頻度: 公共交通ルーティングは時刻表・運行データに依存するため、遅延・運休情報や最新ダイヤの反映状況をドキュメントで確認してください。データ提供元や更新頻度はリージョン／プロバイダによって異なる可能性があります
  • API仕様: CalculateRoutesで travelMode に "Transit" または "Intermodal" を指定。Intermodalでは複数モードの組合せ指定や駐車地点などの入力が必要になる場合があります。レスポンスにはレッグ／セグメント、ジオメトリ、所要時間、距離、乗換情報、発着時刻等が含まれます（詳細はAPIリファレンス参照）
  • レート制限・スケーリング: 大量の経路計算要求があるワークロードではレート制限やスロットリングを考慮してください。バッチ事前計算やサーバサイドキャッシュで負荷を平準化することを推奨します
  • フォールバック: 一部地域や路線で公共交通データが不完全な場合、ドライブルート＋徒歩で代替ルートを提示する等のフォールバック設計を検討してください
  • 互換性: 既存のRoutes APIの他のtravelMode（Driving, Walkingなど）との互換性は維持されますが、レスポンスのフィールドや意味が公共交通固有のデータ（発着時刻、乗換情報等）で拡張される点に留意してください

参考情報 ​

[General] AWS Cost and Usage Report 2.0 now supports Athena and Redshift integration ​

概要 ​

AWS Cost and Usage Report 2.0（CUR 2.0）がAthenaおよびRedshiftとのネイティブ統合をサポートし、S3上のCUR 2.0データを標準SQLで即座にクエリ可能になりました。CUR 1.0と同等の統合オプションが提供され、追加のカスタムデータウェアハウス構築が不要になります。

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

CUR 2.0でAthenaおよびAmazon Redshiftを選択すると、エクスポートがクエリエンジンに最適化された形式（Parquet＋GZIPなど）で自動的にS3へ配信されます。各エクスポートにはメタデータと開始用の自動化リソース（インフラテンプレート、テーブル定義、データロード手順など）が含まれるため、ユーザーは手動設定なしにすぐにクエリを開始できます。CUR 2.0のデータは定期的にリフレッシュされ、その更新はAthena/Redshiftのテーブルに自動反映されるため、追加のETL作業は不要です。これにより、S3上のコストデータをParquetのカラムナフォーマットで効率的に保存・検索でき、Athenaのスキャンコスト削減やRedshiftでの分析パフォーマンス向上が期待できます。なお、この機能は商用リージョンで提供されており、AWS GovCloud (US) および中国リージョンは対象外です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドコスト管理者、FinOps担当者、データ分析者、SRE/運用チーム
  • 利用シーン: コスト分析・アラート、請求データの可視化、月次/日次レポート作成、予算・異常検出のためのSQLクエリ実行
  • 運用効果: カスタムETLやデータパイプライン構築の工数削減、Athenaでのスキャン量削減（Parquet圧縮により）、Redshiftでの高速分析が可能になり、コスト可視化サイクルが短縮される

技術的な注意点 ​

  • IAM権限: CURがS3へ書き込むための適切なロール/権限と、Athena/GlueやRedshiftがS3にアクセスするためのIAM権限が必要です
  • リージョン制限: すべての商用AWSリージョンで利用可能。ただしAWS GovCloud (US) および中国リージョンでは未対応です
  • コスト: S3ストレージ費用、Athenaのクエリ料金（スキャン量に基づく）、Redshiftのコンピュート/ストレージ費用、および必要に応じてGlueカタログやCrawlerの追加料金が発生する可能性があります。Parquet圧縮によりクエリコストは低減可能です
  • データフォーマット: エクスポートはParquet（GZIP等の圧縮）等、クエリエンジンに最適化された形式で配信されます。既存のCUR 1.0 CSVパイプラインとはフォーマットが異なるため互換性確認が必要です
  • カタログ・メタデータ: 自動化リソースはテーブル定義（通常Glue Data CatalogまたはRedshift用のDDL）を含むため、Glueカタログの使用やテーブル作成の自動化が想定されています
  • データ更新頻度: CUR 2.0の定期的なリフレッシュによりAthena/Redshiftのテーブルは自動的に更新される設計ですが、厳密な更新間隔や遅延は設定やリージョンによって異なる可能性があるため確認が必要です
  • 暗号化とコンプライアンス: S3上での暗号化（SSE-S3/SSE-KMS）やKMSキーの使用、アクセスログの設定など既存のセキュリティ要件を満たす設定を事前に検討してください

参考情報 ​

[Rds For Sql Server] Amazon RDS for SQL Server supports Bring Your Own Media ​

概要 ​

Amazon RDS for SQL ServerがBring Your Own Media (BYOM) に対応しました。既存のMicrosoft SQL Serverライセンス（Software Assuranceなど、License Mobilityの対象ライセンス）を再利用してRDS上で運用できます。

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

BYOMにより、オンプレミスや他クラウド、またはAmazon EC2上のセルフ管理SQL ServerからAmazon RDS for SQL Serverへ移行する際に、既存のMicrosoftライセンスを流用できます。これにより追加のMicrosoftライセンス購入や既存契約の満了待ちをせずにRDSへ移行でき、RDSが提供する高可用性（Multi-AZ）、自動バックアップ、監視といったマネージド機能を利用できます。BYOMはAWS License Managerと統合されており、AWS環境全体でのSQL Serverライセンス利用状況のトラッキングとコンプライアンス管理が可能です。利用方法や設定手順はAmazon RDS SQL Server User GuideのBYOM関連節を参照してください。料金・リージョンの可用性はRDS for SQL Serverの料金ページで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: オンプレミスや他クラウド、EC2上でMicrosoft SQL Serverを運用しているクラウド移行担当者やDBA
  • 利用シーン: 既存ライセンスを流用してRDSへ移行したいケース（コスト抑制とマネージド運用化）
  • 運用効果: 追加ライセンス購入を回避しながらRDSの自動化・高可用性機能を活用できるため、移行コストと運用負荷を低減
  • ライセンス管理: AWS License Managerとの統合でライセンス使用状況を可視化・監査しやすくなる
  • 移行速度: 既存ライセンスを使えることで、ライセンス契約の期限待ちによる移行遅延を回避可能

技術的な注意点 ​

  • ライセンス条件: MicrosoftのLicense Mobility要件（たとえばSoftware Assuranceの保有など）を満たす必要がある。対象外となる契約形態やライセンスがあるため事前確認が必須
  • AWS License Manager: BYOMを使うにはAWS License Managerでライセンス定義とトラッキングを設定する必要がある。適切なIAM権限も必要
  • リージョン制限: BYOMの提供リージョンは異なるため、利用予定リージョンの対応状況を料金ページやドキュメントで確認すること
  • コスト: RDSのライセンス持込モデルはインスタンス料金にライセンス費用が含まれない場合がある。総所有コスト（運用コスト＋持込ライセンスの契約条件）を事前に算出すること
  • 移行手順: RDSインスタンス作成時のライセンスオプション選択やAWS License Managerへの登録など手順に沿って設定が必要。DBバックアップ／復元やスキーマ互換性の確認を行うこと
  • 互換性: SQL Serverのエディションや機能差分によりRDSで利用できない機能がある場合があるため、アプリケーション側の互換性検証を推奨

参考情報 ​

[General] AWS HealthOmics now supports Nextflow version pinning at run time ​

概要 ​

AWS HealthOmicsは、StartRun APIの新しいengine-settingsパラメータでNextflowエンジンのバージョンを実行時に指定できるようになりました。これにより、特定のNextflowバージョンへ制御された移行や並行検証が可能になります。

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

StartRun APIのengine-settingsパラメータで、実行時にNextflowエンジンのバージョンを明示的に指定できます。指定可能なサポート済みバージョンは 22.04、23.10、24.10、25.10、26.04 です。StartRunで指定したバージョンは、ワークフロー定義の manifest.nextflowVersion に設定されているものより優先されるため、ワークフローソースを変更せずに同一ワークフローを複数エンジンバージョンで試験できます。これにより、本番では検証済みのエンジンバージョンを維持しつつ、開発・検証チームが新しいエンジンで並行テストを行えるため、規制対応環境でのパイプライン検証負荷とリスクを低減します。AWS HealthOmicsはHIPAA適格サービスであり、本機能は同サービスのNextflowワークフロー実行に適用されます。機能は以下のリージョンで利用可能です：US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Singapore, Seoul)。

影響範囲・利用シーン ​

  • 対象ユーザー: ヘルスケア/ライフサイエンスのバイオインフォマティクスエンジニア、データサイエンティスト、SRE/運用チーム
  • 利用シーンまたは効果: 本番パイプラインは既存の安定バージョンで稼働させつつ、開発・検証環境で新しいNextflowバージョンを並行テストして互換性やパフォーマンスを確認できる
  • 運用効果: アップグレードによる予期せぬ動作変化のリスクを低減し、規制対応（検証・バリデーション）作業を分離して実施できる
  • 適用範囲: Nextflowワークフロー実行時にのみ有効（HealthOmicsのNextflowランに適用）

技術的な注意点 ​

  • IAM権限: StartRun API を呼び出せる IAM 権限（例: HealthOmics の StartRun 実行権限）が必要です。必要なアクション名は設定中のポリシーで確認してください。
  • リージョン制限: 本機能は記事に記載のリージョン（US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Singapore, Seoul)）で利用可能です。その他リージョンでは未対応の可能性があります。
  • 対応Nextflowバージョン: サポートされるバージョンは 22.04、23.10、24.10、25.10、26.04 です。指定は engine-settings パラメータで行います。
  • 優先順位: StartRun の engine-settings による指定は workflow の manifest.nextflowVersion より優先されます（実行時オーバーライド）。
  • 互換性／検証: エンジンバージョン間で挙動や実行結果が変わる可能性があるため、本番適用前に十分な回帰テストとバリデーションを行ってください。規制適合が必要な場合は変更管理プロセスへ組み込んでください。
  • コスト: 機能自体に追加料金は明示されていませんが、異なるエンジンでのテスト実行は計算リソース・ストレージの利用増加に伴う通常の実行コストが発生します。
  • 対象ワークフロー: Nextflow ワークフロー実行に限定されます。その他のエンジンやワークフローフレームワークには影響しません。

参考情報 ​

[General] AWS HealthOmics now supports Nextflow version 26.04 ​

概要 ​

AWS HealthOmicsがNextflow v26.04をサポート開始しました。新しい構文検査（strict parser）、レコード型、ワークフロー出力サマリ（JSON）、エージェントログモードといった新機能を利用できます。

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

Nextflow v26.04のサポートにより、HealthOmics上で以下の主要な改善を利用できます。

  • Strict syntax parser（標準で有効）: パイプライン初期化時に厳格なリントチェック、ブロック構造の一貫性、スコープの曖昧さを検出します。実行中（数時間経過後）に発生するエラーを事前に検出でき、無駄な計算時間と費用を削減します。
  • Record types（レコード型）: タプルのインデックス順に依存せず、名前付きフィールドでデータを扱えるため、ワークフローの可読性と保守性が向上し、ミスが減ります。
  • Workflow output summary（JSON形式）: 実行結果の要約をJSONで出力でき、後続のツールチェーン（集計、可視化、自動処理）との連携が容易になります。
  • Agent logging mode: 構造化かつ最小限のログ出力を行うモードで、AI支援デバッグや自動解析に適した出力フォーマットを提供します。

また、HealthOmicsはHIPAA適合が可能なマネージドサービスであり、これらのNextflow機能は同サービスの運用フローに統合されます。Nextflow v26.04は記事で挙げられたすべてのHealthOmicsリージョン（US East (N. Virginia)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Singapore, Seoul)）で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: バイオインフォマティクス開発者、パイプライン運用者、医療・ライフサイエンスの研究チーム
  • 利用シーン: 大規模ゲノム解析やトランスクリプトーム解析などのNextflowベースワークフローの実行・開発、CI環境でのパイプライン検証、AI支援によるデバッグ
  • 運用効果: 初期段階での構文エラー検出により不要なランを削減しコスト低減、レコード型による可読性向上で保守性向上、JSON出力で自動化ツールと直接連携可能
  • リージョン: 現時点での利用可能リージョンはUS East (N. Virginia)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Singapore, Seoul)です。その他リージョンでは未提供の可能性があります。

技術的な注意点 ​

  • IAM権限: HealthOmicsのワークフロー実行に必要なIAMロール（HealthOmics実行ロール、S3アクセス、ECR/EFS/ジョブ実行関連権限など）を事前に確認・付与してください
  • リージョン制限: Nextflow v26.04は記事で列挙されたリージョンで利用可能です。上記以外のリージョンでは未対応の可能性があるため利用前に確認してください
  • コスト: strict parserにより早期失敗検出で計算コスト削減が期待できますが、移行や検証作業には開発工数（コスト）が発生します
  • 互換性: strict syntax parserは厳格な文法検査を行うため、既存のNextflowスクリプトがエラーとなる可能性があります。ローカル/ステージング環境で動作検証を行い、必要に応じてDSLの修正（レコード型への置換やスコープ明示）を行ってください
  • デプロイ設定: HealthOmics上でNextflowバージョンを選択・指定する方法（ワークフロー定義内のランタイム指定等）を事前に確認してください
  • ログ/監視: Agent logging modeは構造化かつ簡潔なログを出力しますが、従来の詳細ログが必要な場合はログモードの切替や追加のログ収集設定を検討してください
  • 特記事項: HealthOmicsはHIPAA対応が可能なサービスですが、医療データの取り扱い・コンプライアンス設定（暗号化、アクセス管理、監査ログ等）は利用者側で適切に設定する必要があります

参考情報 ​

[General] Quick Research now supports customer managed keys ​

概要 ​

Amazon Quick ResearchがAWS KMSのカスタマー管理キー（CMK）によるデータ暗号化をサポートしました。組織が独自に鍵管理・監査を行えるようになり、セキュリティ/コンプライアンス要件に対応します。

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

Quick ResearchはAWS Key Management Service（KMS）で作成したカスタマー管理キー（CMK）を使ってデータを暗号化できるようになりました。これにより、組織は自前のKMSキーで暗号化を行い、CloudTrailとの統合を通じてアクセスや鍵操作の監査ログを取得できます。複数のCMKをサポートしつつ、各AWSアカウント・各リージョンごとに1つのデフォルトキーを設定可能で、データセット単位で鍵を使い分けることができます。CMKはQuickのリソースと同じAWSアカウントかつ同一リージョンで作成する必要があり、サポートされるのは対称（symmetric）KMSキーのみです。セキュリティインシデント時には鍵のアクセスを最短で15分以内に取り消せるとされており、本機能はAmazon Quickが提供されているすべてのリージョンで一般提供（GA）されています。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンス要求が高い企業、セキュリティチーム、クラウド運用/プラットフォームチーム
  • 利用シーンまたは効果: 機密BIデータやレポートを自社管理のKMSキーで暗号化してアクセス制御・監査を強化する場面（規制対応、内部統制、監査証跡の保存）
  • 運用効果: 鍵ポリシーとCloudTrailを組み合わせることでアクセスの可視化と責任追跡が可能になり、鍵無効化による迅速なアクセス遮断（記事では最短15分での対応）により被害拡大を抑止できる

技術的な注意点 ​

  • IAM権限: KMSキーの作成・管理（kms:CreateKey、kms:PutKeyPolicy、kms:DisableKey、kms:ScheduleKeyDeletion 等）およびQuick側がKMSを利用できるように必要なIAMロール/キーの付与を確認してください
  • キーポリシー/サービス接続: Quickが鍵を使用できるようにKMSキーのキー ポリシーまたはgrantで明示的にサービス主体（Quickのサービスプリンシパル）や必要なIAMロールを許可する必要があります
  • リージョン制限: CMKはQuickリソースと同一のAWSアカウントかつ同一リージョンで作成する必要があります。機能はQuickが提供されているリージョンでGAです
  • キータイプ制限: 対称（symmetric）KMSキーのみサポート。非対称キーや外部キー管理（外部KMS）は非対応です
  • 既存データの暗号化: 既存リソースの暗号化を切り替える際は、移行手順や再暗号化の影響（短時間のI/O影響やジョブの再実行）を確認してください
  • デフォルトキー: 各アカウント/リージョンに対して1つのデフォルトCMKを設定可能ですが、データセットごとの鍵分離が必要な場合は追加CMKを作成・割当てしてください
  • 監査/CloudTrail: CloudTrailによりKMSの鍵操作やQuickによる暗号/復号操作のログを取得できます。長期保存や解析にはCloudTrailのログ保存設定とコストを考慮してください
  • コスト: KMSのカスタマー管理キー利用はキー管理料金やAPI呼び出しに対する料金が発生します（キー保管料やリクエスト課金）。CloudTrailログ保存や分析に伴う追加コストも見積もってください

参考情報 ​

[General] Amazon Quick now supports VPC connectivity for MCP connections ​

概要 ​

Amazon QuickがMCP（Model Context Protocol）サーバーへのVPC接続をサポートしました。これにより、インターネットに公開せずにプライベートなMCPサーバーをQuickのAIワークフローに統合できます。

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

従来はQuickのMCP連携はパブリックに到達可能なサードパーティホストに限定されていましたが、今回のアップデートでAmazon VPC内のプライベートにホストされたMCPサーバーへ直接接続できるようになりました。MCPコネクタの作成時にVPC接続を選択し、MCPサーバーのURLを指定することで、Amazon EC2、AWS Fargate、AWS Agentcore、あるいは社内のプライベートなコンピュート上で稼働するMCPサーバーへアクセスできます。接続後はQuick上で自然言語を使ってプライベートMCPとやり取りでき、通信は選択したVPC経路を通じてセキュアにルーティングされます。リージョンに関しては、Amazon Quickが利用可能な全リージョンでVPC接続が利用可能とされています。

影響範囲・利用シーン ​

  • 対象ユーザー: エンタープライズ顧客、セキュアな内部データや専有モデルをQuickに統合したい開発者・SRE
  • 利用シーン: 社内データソースや専有APIを参照するカスタムAIワークフロー、内部ツールの自然言語インターフェース化、プロプライエタリモデルの利用
  • 運用効果: 公開ネットワークにサーバーを晒さずにQuickと連携できるため、セキュリティとコンプライアンス要件を満たしつつAI機能を社内に展開可能
  • 導入障壁: VPCやネットワークの設定が必要なため、ネットワーク運用やIAM設計の準備が前提となる

技術的な注意点 ​

  • IAM権限: MCPコネクタ作成やVPC接続を操作するための適切なIAM権限（Quick側とAWSリソース側）を用意してください
  • ネットワーク設定: セキュリティグループ、サブネットのルーティング、NATゲートウェイやルートテーブルなどVPC側の設定が正しくないと接続できません。必要に応じてVPCピアリングやTransit Gatewayも検討してください
  • DNS/名前解決: プライベートDNSやホスト名の解決が不要または適切に設定されていることを確認してください（内部DNS解決が必要なケースが多いです）
  • 認証・暗号化: MCPサーバーとの通信はTLSなどで保護してください。証明書の検証やクライアント認証（mTLS）が必要な場合は事前に準備が必要です
  • サポート対象のコンピュート: Amazon EC2、AWS Fargate、AWS AgentcoreなどVPC内の任意のコンピュートで稼働するMCPサーバーに対応します
  • コスト: VPCエンドポイント、データ転送、NATゲートウェイ、VPCピアリング/Transit Gateway等の追加費用が発生する可能性があります
  • ログ・監査: 通信の監査やログ（VPC Flow Logs、CloudWatch Logs等）の設計を行い、アクセス監査やトラブルシュートに備えてください
  • リージョン制限: Amazon Quickが提供されている全リージョンでVPC接続が利用可能と明記されていますが、利用前に対象リージョンでのサービス展開状況を確認してください

参考情報 ​

[SageMaker] Amazon SageMaker adds permissions boundaries for SCP compliance ​

概要 ​

Amazon SageMaker Unified Studioは、Tooling blueprintでカスタムのIAM Permissions Boundaryを指定できるようになりました。これにより、Service Control Policies（SCP）で全IAMロールにPermissions Boundaryを必須としている組織でも、SageMaker Unified Studioを追加の管理操作なしに利用できるようになります。

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

ユーザーがプロジェクトを作成する際、SageMaker Unified Studioは従来どおりプロジェクトユーザーロール、Amazon Bedrockサービスロール、Bedrock Lambda実行ロールの3つのIAMロールをプロビジョニングします。本アップデートでは、管理者がTooling blueprintの設定でPermissions Boundary（ポリシーのARN）を指定すると、これら3つのロールが作成時に指定したPermissions Boundaryを付与された状態で自動作成されます。これにより、組織のSCP要件（作成時点でBoundaryが必要）を満たし、プロジェクト作成時に管理者の手動介入が不要になります。Permissions Boundaryはロールの許可を上限（最大限）で制限するため、各プロジェクトで新しいロールが作られても管理者はプロジェクトレベルでの権限コントロールを維持できます。Blueprintレベルで設定するため、一度設定すれば以後作成されるすべてのプロジェクトに自動適用されます。本機能はSageMaker Unified Studioが利用可能なすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティポリシーでIAM Permissions Boundaryを必須としている組織のクラウドセキュリティ担当者、クラウド基盤チーム、データサイエンティストやMLプラットフォーム運用者
  • 利用シーン: 組織のSCPポリシー遵守下でSageMaker Unified Studioを利用し、プロジェクト作成時に自動でPermissions Boundaryを付与してガバナンスを維持する場面
  • 運用効果: プロジェクト作成時の管理者介入を削減し、SCP要件を満たした状態で迅速にプロジェクトをプロビジョニング可能。ロールの権限上限が明確になるため権限管理が容易になる

技術的な注意点 ​

  • IAM権限: Tooling blueprintの設定変更やBlueprintで参照するPermissions Boundaryポリシーの作成には適切なIAM管理権限が必要です（例: iam:CreatePolicy、iam:PutRolePermissionsBoundary やBluePrintを操作するためのSageMaker関連権限）。
  • Permissions Boundaryの形式: 指定するBoundaryは通常ポリシーのARNで管理ポリシーとして存在している必要があり、Boundary自体は権限を付与しない点に注意してください（Boundaryは許可の上限を定義します）。
  • 既存プロジェクトへの影響: Blueprintで設定したPermissions Boundaryは以後作成される新規プロジェクトに適用されます。既存のプロジェクト／ロールには自動的には適用されません。既存ロールにBoundaryを追加する場合は別途対応が必要です。
  • 制限と互換性: Permissions Boundaryが過度に制限的だとBedrock関連サービスやLambda実行などで必要な操作がブロックされ、プロジェクトが正しく動作しない場合があります。Boundaryで許可するアクションを事前に確認してください。
  • リージョン制限: 本機能はSageMaker Unified Studioが利用可能なすべてのAWSリージョンで提供されています（ただしリージョン毎のサービス可用性は別途確認してください）。
  • コスト: 本機能自体による追加料金は発生しません。ただしPermissions Boundaryや関連ポリシーの管理運用コストや、誤設定によるトラブル対応コストに注意してください。

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore Identity now allows you to bring your own secrets with AWS Secrets Manager ​

概要 ​

Amazon BedrockのAgentCore Identityが、AWS Secrets Managerで作成・管理した既存シークレットのARNをCredential Providerで参照できるようになりました。これにより、顧客はシークレット作成時から自社のガバナンス（CMK、タグ、ローテーション、ポリシー）を適用できます。

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

従来、AgentCore Identityはサービス管理のシークレットを自動作成・管理しており、ユーザー側でのタグ付け、カスタマー管理キー（CMK）による暗号化、リソースポリシー設定などが行えませんでした。本アップデートでは、ユーザーがAWS Secrets Managerで自らシークレットを作成・管理し、そのシークレットのARNをAgentCore IdentityのCredential Providerに参照させる（bring your own secret）方式をサポートします。これにより、Secrets ManagerでのカスタムCMK適用、タグ付け戦略、シークレット自動ローテーション、リソースポリシーによるアクセス制御など、既存のガバナンス・コンプライアンスポリシーをそのまま利用可能です。AgentCore Identity側の実行時挙動（シークレット参照方法）は変わらず、ランタイムで参照されたシークレットを用いて認証情報を取得します。本機能は一般提供（GA）として以下14リージョンで利用可能です: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm)。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンス担当者、クラウド運用チーム、アプリケーション開発者
  • 利用シーンまたは効果: 既存のSecrets Managerワークフロー（CMKによる暗号化、タグ付け、ローテーション、リソースポリシー）をAgentCore Identityの認証情報に適用して運用ポリシーと整合させる場面
  • 運用効果: シークレット管理の一元化と監査性向上、組織のガバナンス要件（キー管理やラベル付け）を満たしやすくなることで導入・運用の摩擦を低減
  • 互換性影響: ランタイムでの利用方法は変わらないため既存のAgentCore Identityの挙動を保ちながらシークレットの所有権を移行可能
  • リージョン: 本機能は上記の14リージョンでGA。その他リージョンでは未提供の可能性あり

技術的な注意点 ​

  • IAM権限: AgentCore Identityが参照するSecrets Managerシークレットに対してSecretsManager:GetSecretValue等のアクセス権が必要です。カスタムCMKを使う場合はkms:Decrypt等のKMS許可も必要になります。
  • リージョン制限: GAは14リージョン（US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm)）に限定されています。その他リージョンでの提供状況は都度確認してください。
  • コスト: Secrets Managerでのシークレット管理は別途料金が発生します（シークレットストレージ、API呼び出し、シークレットローテーション等）。コスト影響を評価してください。
  • シークレットローテーション/ライフサイクル: シークレットの自動ローテーションやバージョニングはSecrets Manager側で管理可能ですが、ローテーション後の互換性（参照する形式やキー名）がAgentCore側の想定と合致するよう設計してください。
  • リソースポリシー/タグ: シークレットに対するリソースポリシーやタグ付けはユーザー管理のため、組織のアクセス制御や請求・資産管理に組み込めます。
  • 移行手順: 既存のサービス管理シークレットからBYOシークレットへ切り替える際は、権限付与と検証（AgentCoreが新しいARNを正常に参照できること）を事前に行ってください。

参考情報 ​

[Ec2] Amazon EC2 M8i and M8i-flex instances are now available in Asia Pacific (New Zealand) Region ​

概要 ​

Amazon EC2のM8iおよびM8i-flexインスタンスがアジアパシフィック（ニュージーランド）リージョンで利用可能になりました。カスタムIntel Xeon 6プロセッサ採用により、従来世代比でメモリ帯域や価格性能が向上しています。

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

M8i / M8i-flexはAWS専用のカスタムIntel Xeon 6プロセッサを搭載した汎用インスタンスファミリーです。前世代のIntelベースインスタンスと比べて最大で15%の価格性能向上、メモリ帯域は最大2.5倍を実現します。M7i系との比較では最大で20%の総合性能向上が報告されており、ワークロードによってはさらに大きな改善が見込まれます。具体的な向上例として、PostgreSQLは最大約30%高速化、NGINXベースのWebアプリは最大約60%高速化、AIのディープラーニング推奨モデルは最大約40%高速化とされています。M8i-flexは一般的なサイズ（large〜16xlarge）を提供し、多くの汎用ワークロードで手軽に価格性能の恩恵を受けられる設計です。一方、M8iは最大サイズや継続的な高CPU利用が必要なケース向けで、13サイズ（うちbare metal 2サイズ）と新たに96xlargeサイズを含み、SAP認定も取得しています。利用はAWS Management Consoleから開始できます。移行時はアプリケーションのベンチマークを取り、最適なサイズ／flexの選択を推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、アプリケーション開発者、データベース管理者
  • 利用シーンまたは効果: Web/アプリケーションサーバ、マイクロサービス、中小規模データストア、仮想デスクトップ、エンタープライズアプリケーション、SAP、AI推論やレコメンデーションモデルでの性能改善
  • 運用効果: 同等ワークロードでのコスト効率向上（価格性能改善）やレイテンシ低減、特定ワークロードでの顕著なスループット向上によりスケールダウン／台数削減が可能になる可能性があります

技術的な注意点 ​

  • IAM権限: ec2:RunInstances等の通常のインスタンス起動権限が必要です。事前にIAMポリシーを確認してください
  • リージョン制限: 本リリースはアジアパシフィック（ニュージーランド）リージョンでの提供開始です。他リージョンでは未配信の可能性があるため利用前にリージョンでの可用性を確認してください
  • AMI/ドライバ互換性: 利用するAMIがIntelベースの最新カーネル/ドライバ（ENA、NVMe等）に対応しているか確認してください。特にカスタムドライバや古いカーネルを使う場合は互換性テストが必要です
  • インスタンス上限: vCPU/インスタンス数のクォータがあるため、大口導入前にサービスクォータを確認・引き上げ申請してください
  • SAP/bare metal: SAP認定サイズとbare metalを提供していますが、ライセンス条件やサポート要件（SAPのサポート記載など）を事前に確認してください
  • コスト: 記載の「価格性能向上」は相対指標です。実際の課金はリージョン/サイズ/購入オプション（オンデマンド、Savings Plans、リザーブド等）によるため、移行前に料金表と試用ベンチマークで効果を検証してください
  • パフォーマンス検証: 公表値は特定ベンチマークに基づくため、本番ワークロードでの性能差は異なる可能性があります。アプリ毎にベンチマーク／負荷試験を推奨します

参考情報 ​

[Ec2] Amazon EC2 M8azn instances are now available in Europe (Ireland) Region ​

概要 ​

Amazon EC2 M8azn インスタンスが Europe (Ireland) (eu-west-1) リージョンで利用可能になりました。第5世代AMD EPYC（Turin）プロセッサを搭載し、クラウド上で最大5GHzの高クロック・高ネットワーク性能を提供する汎用高周波・高ネットワークインスタンスです。

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

M8azn は第5世代 AMD EPYC（Turin）プロセッサを採用した高周波・高ネットワーク向けの汎用インスタンスタイプです。主な技術的特徴は以下の通りです:

  • 最高最大CPU周波数: 5.0 GHz（クラウド上での最高周波数を提供）
  • 世代間性能比較: 以前の M5zn と比べ最大2倍の計算性能、M8a と比べ最大約24%の性能向上を謳っています
  • メモリ・キャッシュ: M5zn と比較して最大4.3倍のメモリ帯域幅、L3キャッシュは最大10倍
  • ストレージ/ネットワーク: M5zn 比で最大2倍のネットワークスループット、最大3倍のEBSスループット
  • プラットフォーム: AWS Nitro System（第6世代 Nitro Card）上で動作し、高性能なENI/EBS最適化を提供
  • インスタンス構成: 2〜96 vCPU、最大384 GiB メモリの9サイズ（うち2つはベアメタル） これらの特性により、低レイテンシで高いシングルスレッド性能やメモリ帯域・キャッシュ依存の計算が必要なワークロード（リアルタイム金融分析、HFT、HPC、ゲーム、シミュレーション、CI/CD 等）で効果を発揮します。導入は AWS マネジメントコンソールから可能で、Nitro による ENA（Enhanced Networking）や EBS 最適化が利用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: リアルタイム解析や高周波数CPUを要求するアプリケーション開発者、HPC/金融トレーディング、ゲーム開発・シミュレーションを行うエンジニア
  • 利用シーン: 低レイテンシかつ高シングルスレッド性能が必要なワークロード（高頻度トレーディング、リアルタイム解析、物理シミュレーション、CI/CD ビルド/テストの高速化）
  • 運用効果: より短い処理時間と高速なレスポンスによりバッチ完了/レイテンシ要件を満たしやすくなる。ネットワーク・EBS スループット向上によりI/O負荷の高いアプリケーションもスケールしやすくなる

技術的な注意点 ​

  • IAM権限: インスタンス起動や専用機能利用には通常の EC2 起動権限（ec2:RunInstances 等）と、VPC/ENI/EBS 関連の権限が必要です
  • リージョン制限: 本アナウンスは Europe (Ireland) (eu-west-1) での提供開始を示します。他リージョンでの利用可否はコンソールで確認してください
  • AMI/ドライバー: 最新の AMI を利用し、EN A（Enhanced Networking）と NVMe/EBS ドライバがサポートされていることを確認してください。古いカーネルやドライバでは性能を発揮できません
  • インスタンスクォータ: vCPU 上限やインスタンスタイプごとのクォータがあるため、大量導入時は事前に AWS サポートへクォータ引き上げを申請してください
  • コスト: 高性能インスタンスのため既存世代よりも単価が高い可能性があります。オンデマンド、リザーブド、スポットの料金差やコスト試算を事前に行ってください
  • ベアメタル: ベアメタル variant を利用する場合はホスト機能やライセンス、セキュリティ要件（BIOS/ファームウェア挙動）を検討してください
  • 互換性/制限: Nitro ベースのため多くの Nitro 機能が利用可能ですが、特定の仮想化機能やサードパーティハイパーバイザ互換性は物理ベアメタルでの要検証となります

参考情報 ​

[General] Amazon SageMaker HyperPod now supports EFA-only network interfaces ​

概要 ​

Amazon SageMaker HyperPodでEFA-onlyネットワークインターフェイスがサポートされました。EFA専用インターフェイスをENA（IP用）を付与せずに割り当てでき、サブネットのIPアドレス枯渇を抑えて大規模クラスタをスケールできます。

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

これまでHyperPodの efa インターフェイス型は、EFAデバイスに加えてENA（Elastic Network Adapter）を各インターフェイスにアタッチしており、ENA分のIPアドレスをサブネットから消費していました。新機能の efa-only を指定すると、ネットワークインターフェイスはEFAトラフィック専用として構成され、ENAをアタッチしないためIPアドレスを消費しません。これにより、インスタンス当たり複数のEFA対応インターフェイスを最大限に利用して、低レイテンシ／高スループットのノード間通信を確保しつつ、同一サブネット内でより多くのノードを展開できます。設定はCreateCluster/UpdateCluster APIのClusterNetworkInterface構成で efa-only を指定して行います。EFA-onlyは、HyperPodが利用可能なすべてのAWSリージョンで利用可能です。注意点として、EFA-onlyインターフェイスはIPアドレスを持たないため、そのインターフェイス自体ではSSHやIPベースの管理通信は行えません。したがって、インスタンス上で管理用やインターネット接続が必要な場合は、少なくとも1つのENA（IP付き）インターフェイスを残す設計が必要です。また、EFAを利用するには対応インスタンスタイプ、カーネル／ドライバ（EFAドライバ、libfabric等）とソフトウェアスタック（MPI/NCCL等）の対応が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: 大規模分散トレーニングを行う機械学習エンジニア、MLプラットフォーム／クラスタ運用者
  • 利用シーンまたは効果: ノード間の低レイテンシ・高帯域通信を重視するトレーニングジョブで、サブネットのIPアドレス枯渇を回避してより多くのノードを単一サブネット内に展開可能にする
  • 運用効果: IPアドレスの節約によりサブネット設計を簡略化でき、クラスタサイズの上限に因る再サブネット化やVPC設計変更の頻度を低減できる

技術的な注意点 ​

  • IAM権限: CreateCluster/UpdateClusterの実行に必要なSageMakerの権限を持っていること（ClusterNetworkInterfaceの更新権限を含む）
  • リージョン制限: HyperPodがサポートされているすべてのリージョンで有効（ただし利用可否はリージョンごとのHyperPodサポート状況に依存）
  • コスト: EFA自体の追加料金は通常発生しないが、より大きなクラスタを稼働させることでインスタンス使用料金やデータ転送コストは増加する可能性あり
  • ネットワーク構成: efa-onlyインターフェイスはIPアドレスを持たないため、そのインターフェイス上でのIP通信やセキュリティグループのIPベース制御は適用できない点に注意。管理用トラフィック用にEN A（IP付き）インターフェイスを少なくとも1つ残す設計を推奨
  • インスタンスタイプ／ドライバ: EFA対応インスタンスタイプとOSレベルでのEFAドライバ／libfabric等のセットアップが必要。EFA非対応のインスタンスでは利用不可
  • 運用上の制約: ロギング/デバッグやSSH接続等の管理アクセスはEN A付きインターフェイス経由で行う必要があるため、ノードごとの管理ネットワーク設計が必要
  • API使用方法: CreateCluster/UpdateClusterのClusterNetworkInterface設定で "efa-only" を指定して有効化する

参考情報 ​

[General] Amazon SageMaker HyperPod now offers troubleshooting skills for AI coding assistants ​

概要 ​

Amazon SageMaker HyperPodに、AIコーディングアシスタント（Claude Code、Cursor、Kiro など）から自然言語でクラスター診断が実行できるトラブルシューティングスキルが追加されました。これにより分散トレーニング/推論環境の障害診断と復旧が迅速化されます。

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

HyperPodのトラブルシューティングスキルは、AWSのベストプラクティスを組み込んだ構造化された診断ワークフローをAIエージェントに提供します。各スキルはAWS Systems Manager（SSM）を通じてノードから証跡（ログ、メトリクス、コマンド出力など）を収集し、GPUハードウェア障害、NCCL等の通信不具合、ソフトウェアバージョンドリフト、パフォーマンスボトルネックなどのパターン解析を行い、具体的な対処案と自動診断レポートを生成します。既存のHyperPod（SlurmまたはAmazon EKSでオーケストレーションされた構成）に対して追加のインフラ変更は不要で、SageMaker AI skillsプラグインを介して主要なAIコーディングアシスタントに組み込めます。スキルはオープンソースで公開されており、GitHubのAWSLabsリポジトリからsagemaker-aiプラグインをインストールして利用開始できます。

影響範囲・利用シーン ​

  • 対象ユーザー: MLプラットフォームエンジニア、SRE、データサイエンティスト、MLオペレーション担当者
  • 利用シーンまたは効果: 分散学習・推論クラスターの障害切り分け（GPU故障、NCCL通信エラー、パフォーマンス低下、ソフトウェア不整合）の迅速化によりMTTRを短縮
  • 運用効果: 手作業で複数ノードにSSMログインして解析する工数を削減し、診断の自動化・標準化が可能
  • 適用範囲: SlurmベースとAmazon EKSベースのHyperPodクラスターに対応（既存環境への追加導入が可能）
  • 導入要件: HyperPodが稼働していること、SSMエージェントが各ノードで有効であること、sagemaker-aiプラグインを使用するコーディングアシスタント側への導入

技術的な注意点 ​

  • IAM権限: SSM（SendCommand/GetCommandInvocation/DescribeInstanceInformation 等）、EC2/インスタンスの参照、CloudWatch LogsやSageMaker関連の読み取り権限が必要。最小権限ポリシーを設計してください。
  • ネットワーク/SSM: 各ノードでAWS Systems Manager Agentが稼働し、SSMへの通信が許可されている必要があります（VPCエンドポイントやNAT等のネットワーク経路の確認を推奨）。
  • サポートオーケストレーター: SlurmおよびAmazon EKSでのHyperPodに対応。その他のオーケストレーション環境では追加作業が必要となる可能性があります。
  • ソフトウェア前提: HyperPodインフラ、関連エージェント（NVIDIAドライバ、NCCL、コンテナランタイム等）の情報取得が前提。バージョン情報が不足する環境では診断精度が落ちる可能性があります。
  • コスト: スキル自体はオープンソースですが、診断で実行するSSMコマンドやCloudWatchログの取得、追加のストレージ/ネットワーク転送に伴う通常のAWS利用料が発生する点に注意してください。
  • リージョン制限: 公開情報ではリージョン限定の表記はありませんが、SageMaker/HyperPodの機能提供状況やSSM等のサービスの可用性はリージョン依存するため、導入前に利用リージョンでのサポート状況を公式ドキュメントで確認してください。

参考情報 ​

[Direct Connect] AWS Direct Connect now supports VIF Rate Limiters to help prevent network congestion ​

概要 ​

AWS Direct Connect が専用接続の仮想インターフェイス（VIF）ごとに帯域上限を設定できる VIF Rate Limiters をサポートしました。予期しないトラフィックスパイクで同一接続上の他の VIF の帯域を圧迫するのを防ぎます。

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

VIF Rate Limiters を使うと、専用 Direct Connect 接続上の最大 10 個の VIF に対して、それぞれの最大帯域割当を設定できます。設定可能な容量は 50 Mbps 単位の幅広いインクリメントから、リンク集約グループ（LAG）利用時は最大 1.6 Tbps まで選択可能です。レート制限は AWS ネットワークへのインバウンド／アウトバウンド両方向のトラフィックに適用され、設定容量を超えるトラフィックは超過パケットをドロップして他 VIF の帯域を守ります。新たに CloudWatch に VIF ごとの「構成容量に対する利用率（%）」とドロップパケット数のメトリクスが公開され、閾値に基づくアラーム設定で監視・運用が行えます。設定は Direct Connect コンソール、API、SDK から可能です。リージョンは商用パーティションおよび中国パーティションの、Direct Connect 専用接続がサポートされる全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/クラウドエンジニア、SRE、SaaS/マルチテナントサービス運用者
  • 利用シーンまたは効果: 同一専用接続で複数の VIF を運用する環境で、特定 VIF のトラフィックスパイクが他の VIF の帯域を枯渇させるリスクを軽減し、帯域分離・サービス品質の担保を容易にする
  • 運用効果: トラフィック過負荷による他 VIF への影響を抑止でき、CloudWatch メトリクスで利用率とドロップを可視化して閾値アラートにより事前対応が可能
  • スケーラビリティへの影響: 最大 10 VIF まで個別割当が可能なため、専用接続あたりの論理的分配を計画して容量管理できる
  • コスト面の考慮: 直接的なレートリミッター課金は明示されていないが、CloudWatch メトリクスとアラームの利用に伴う追加料金が発生する可能性がある

技術的な注意点 ​

  • 設定上限: 1 接続あたり最大 10 VIF に対して設定可能です
  • 帯域インクリメント: 50 Mbps 単位で指定可能。LAG 利用時は最大 1.6 Tbps まで対応します
  • トラフィック挙動: 設定容量を超えたトラフィックはパケットドロップされます（遅延バッファリングやキューイングではないため、TCP 再送やアプリケーションレベルの影響を考慮してください）
  • 監視: VIF の利用率（%）とドロップパケット数が CloudWatch に公開されるため、アラームを設定して運用監視が可能です。CloudWatch のメトリクス保存/取得に伴う料金を確認してください
  • 権限: Direct Connect の VIF を更新・管理する IAM 権限（コンソール/API での操作権限）が必要です。実運用では最小権限の IAM ポリシーを適用してください
  • 互換性/制限: 機能は専用接続（Dedicated Connection）に対して提供されます。対応リージョンは Direct Connect 専用接続が利用可能な商用および中国パーティションのリージョンに限られます。各リージョンのサポート状況は事前に確認してください
  • 運用設計上の注意: VIF ごとの割当は合計が物理リンク容量を超えないよう設計すること、またバックアップやフェイルオーバー構成（LAG や別接続）と整合させてください
  • API/コンソール: 設定は AWS Direct Connect コンソール、API、SDK から行えます。自動化ツールや IaC に組み込む場合は API 名とパラメータを確認してください

参考情報 ​

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

Copyright © 2026