AWS What's New Digest

Appearance

2026年01月22日 ​

[SageMaker] Amazon SageMaker HyperPod introduces enhanced lifecycle scripts debugging ​

概要 ​

Amazon SageMaker HyperPod のライフサイクルスクリプト（lifecycle scripts）実行時のトラブルシューティングが強化され、スクリプト実行ログの所在（CloudWatchロググループ／ログストリーム）や実行進捗を示すマーカーが提供されるようになりました。これにより、クラスター構築やノード操作時の障害原因特定が速くなります。

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

今回の更新により、HyperPod のクラスター作成やノード操作中にライフサイクルスクリプトで問題が発生した場合、より詳細なエラーメッセージが返されるようになりました。エラーメッセージには、該当する CloudWatch ロググループ名とログストリーム名が含まれ、DescribeCluster API の応答または SageMaker コンソールのクラスター詳細画面で確認できます。コンソール上には "View lifecycle script logs" ボタンが追加され、該当ログストリームへ直接遷移できます。加えて、CloudWatch ログにはライフサイクルスクリプトの実行進捗を追跡するためのマーカー（例：ログ開始、スクリプトのダウンロード開始、ダウンロード完了、成功／失敗のマーカー）が出力されるため、どの段階で失敗が発生したかを迅速に特定できます。これらは観測性の改善であり、スクリプトの動作自体を変更するものではありません。機能は、SageMaker HyperPod がサポートされるすべてのリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: SageMaker HyperPod を使って大規模モデル（LLM、拡散モデル、Foundation Models 等）を実行・開発する機械学習エンジニア、SRE、プラットフォーム運用チーム
  • 利用シーンまたは効果: クラスター作成時やノードプロビジョニング時の lifecycle script による失敗の迅速な特定と原因追跡。DescribeCluster API やコンソールから該当の CloudWatch ログへ直接遷移し、失敗箇所（ダウンロード、実行、完了など）を確認できる
  • 運用効果: 障害対応時間（MTTR）の短縮。ログの直接リンクと実行マーカーにより、ログ探索工数を削減しクラスター稼働開始を早める

技術的な注意点 ​

  • IAM権限: DescribeCluster（SageMaker）と CloudWatch Logs の Read 権限（logs:DescribeLogStreams、logs:GetLogEvents 等）が必要です。コンソールからログを開く場合は追加のコンソール表示権限も必要になります
  • リージョン制限: SageMaker HyperPod がサポートされる AWS リージョンで利用可能。利用前に対象リージョンで HyperPod が有効か確認してください
  • コスト: CloudWatch Logs の受信・保管・検索には料金が発生します。ログ出力量が増えるとコスト増加の可能性があるため、ログ保持期間（retention）やフィルタリング方針を検討してください
  • ログ保持と暗号化: CloudWatch Logs の保持期間や KMS による暗号化ポリシーが適用されます。アクセスや復号に必要な KMS 権限を確認してください
  • 影響範囲: これは観測性（可視化・デバッグ）改善の変更であり、ライフサイクルスクリプトの実行内容自体やスクリプトのセキュリティモデルは変更しません
  • 自動化への活用: 出力される実行マーカーを用いてログ解析・アラートや CI/CD の失敗判定を自動化することで、より迅速な対応が可能になります

参考情報 ​

[Clean Rooms] AWS Clean Rooms adds support for join and partition hints in SQL ​

概要 ​

AWS Clean RoomsがSQLクエリでの結合（join）とパーティション（partition）に対するヒント指定をサポートしました。これにより結合戦略やデータ分散を明示的に最適化でき、クエリ性能向上とコスト削減が期待できます。

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

今回のアップデートでは、SQL内にコメント形式のヒントを記述してクエリプランに影響を与えることが可能になりました。ヒントは事前承認された分析テンプレートとアドホックSQLの双方で使用でき、一般的には小さな参照テーブルを全ノードに複製して結合を高速化するbroadcast joinヒントや、データを特定キーでパーティションさせて同キー間で処理を揃えシャッフルを低減するpartitionヒントが利用可能です。これにより大規模テーブル同士の結合で発生するネットワークシャッフルやディスクI/Oを抑え、クエリ実行時間とスキャン/処理コストを下げられます。

実装面では、ヒントはSQLのコメントスタイルで付与します（例: /*+ BROADCAST(table_name) */ のような形式を想定）。ヒントはクエリ最適化器に対する“指示”であり、常に最適な計画を保証するものではないため、実行計画の確認とベンチマークが推奨されます。なお、AWS Clean Roomsは数分でセキュアなクリーンルームを作成し、AWS上またはSnowflakeと協業してデータ共有・共同分析を行える点は変わりませんが、ヒントの適用はClean Roomsのクエリエンジン側での振る舞いに依存します。

影響範囲・利用シーン ​

  • 対象ユーザー: データアナリスト、データエンジニア、SRE/運用チーム
  • 利用シーン: 参照テーブル（ルックアップ）と大規模行ベースデータの結合、キーに基づく集約処理の並列化、クエリテンプレートでの事前最適化
  • 運用効果: ネットワークシャッフルとI/Oを減らしてクエリ性能が向上、処理時間短縮によりコスト削減が期待できる
  • コスト影響: 正しく使えばコスト低減につながるが、誤用（不適切なbroadcastによるメモリ増大など）は逆にコスト増や失敗を招く可能性がある
  • ガバナンス影響: ヒントは事前承認済みテンプレートでの利用が想定されるため、ガバナンスと監査の観点でテンプレート管理が重要

技術的な注意点 ​

  • IAM権限: クリーンルームでクエリ実行や分析テンプレート編集に必要なIAM権限の確認・付与が必要です
  • リージョン制限: AWS Clean Rooms自体の利用可能リージョンに依存します。詳細はリージョン対応表を確認してください
  • コスト: ヒントは実行パターンを変えるため、最適化によりクエリコストが下がる一方、誤用でコスト増加のリスクがあります。事前にテストを推奨
  • セキュリティ/ガバナンス: ヒントの使用はクリーンルームのポリシーやデータアクセス制御の外枠ではなく、アクセス制御は従来通り適用されます。承認済みテンプレート運用を推奨
  • テンプレート承認: アドホックでの使用は可能だが、企業運用では事前承認されたテンプレートでの管理により安全に適用できます
  • SQL構文/互換性: ヒントはコメント形式で付与します（例: /*+ ... */）。実行計画や最適化器の挙動はクリーンルーム側のクエリエンジンに依存し、Snowflake等外部エンジンでの実行時は互換性や効果が異なる可能性があります
  • モニタリング: ヒント適用後はクエリプラン、実行時間、リソース使用量（CPU/メモリ/ネットワーク）を監視して効果を検証してください

参考情報 ​

[Connect] Amazon Connect can now automatically select random samples of agent contacts for evaluation ​

概要 ​

Amazon Connectは、管理者がエージェントごとのコンタクトをランダムに抽出して評価できる機能を追加しました。指定した期間とサンプル数に基づき、録音や画面録画、トランスクリプトの有無などでフィルタしたうえで公平な評価用サンプルを自動作成できます。

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

管理者は「エージェント毎に何件のコンタクトをレビューするか」を指定し（例：直近1週間からエージェントあたり3件）、指定期間内からランダムに対象コンタクトを抽出できます。抽出時に以下のようなフィルタを適用可能です：音声録音あり、画面録画あり、トランスクリプトあり、既に評価済みのコンタクトを除外、など。これにより労働協約や規制、社内ガイドラインで定められたサンプリング要件を満たしたうえで、公平かつ再現性のある評価用サンプルを取得できます。機能はAmazon Connectの評価（contact evaluation）ワークフローから利用でき、全てのAmazon Connect提供リージョンで有効です。抽出はエージェント単位のランダムサンプリングで、指定した件数に満たない場合は利用可能な範囲で返されます。録音やトランスクリプトは既存のストレージ（例：S3）やトランスクリプションサービスの設定に従います。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンター管理者、品質管理（QA）チーム、コンプライアンス担当者
  • 利用シーンまたは効果: 労働協約や規制に基づくサンプリング要件の遵守、定期的な品質評価の自動化、偏りのない coaching 用サンプルの取得
  • 運用効果: 評価作業の工数削減と公平性向上により、コーチング品質と監査対応の効率化が期待できる
  • コンプライアンス: 監査証跡としてのサンプル抽出を再現可能にし、外部規制や内部ポリシー準拠の証明を容易にする

技術的な注意点 ​

  • IAM権限: 評価機能と録音/トランスクリプトへのアクセス権限（Amazon Connect の適切な管理・評価権限、S3オブジェクトの閲覧やKMS復号が必要な場合はそれらの権限）を持つこと
  • リージョン制限: 記事のとおり、Amazon Connect が提供されているリージョンで利用可能（東京リージョン含む）
  • コスト: 機能自体の有無に関する追加課金は明記されていないが、録音保存（S3）、トランスクリプション（Amazon Transcribe 等）、データ取得・保存に伴うストレージやAPIコールの料金は発生する可能性がある
  • データ量制限: 指定期間内に十分な件数が存在しない場合は、要求件数に達しない結果が返ることがある
  • プライバシー/ガバナンス: 録音やトランスクリプトに個人情報が含まれる場合、保持期間やアクセス制御、監査ログを事前に確認・適用することを推奨

参考情報 ​

[Emr] Amazon EMR Serverless now supports AWS KMS customer managed keys for encrypting local disks ​

概要 ​

Amazon EMR Serverlessのワーカーのローカルディスクを、AWSが所有するデフォルトキーに加えて、AWS KMSのカスタマーマネージドキー（CMK）で暗号化できるようになりました。規制・コンプライアンス要件が厳しい環境で、より細かな暗号化制御が可能になります。

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

これまではEMR ServerlessのワーカーローカルディスクはデフォルトでAWS所有のキー（AWS-owned keys）により暗号化されていました。今回の機能追加により、同一アカウントまたは別アカウントのAWS KMSカスタマーマネージドキー（CMK）を指定してローカルディスクを暗号化できるようになります。指定はアプリケーション単位（指定したアプリケーション配下のすべてのワークロードに適用）またはジョブ実行／対話セッション単位で行え、既存のEMR Serverlessアプリケーションにも適用可能です。本機能はサポートされているすべてのEMRリリースで利用でき、Amazon EMR Serverlessが提供されているすべてのリージョン（AWS GovCloud（US）や中国リージョンを含む）で有効です。なお、この暗号化はEMR Serverlessワーカーのローカルディスクに対するもので、S3オブジェクトのサーバーサイド暗号化とは別扱いです。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ要件や規制準拠（PCI、HIPAA、各国法令など）が厳しいデータプラットフォーム運用者、セキュリティ／コンプライアンス担当者
  • 利用シーンまたは効果: ローカル一時ディスクに保存されるログや中間データを自社管理のKMSキーで暗号化することで、監査やキー管理ポリシーへの準拠を実現
  • 運用効果: キーライフサイクル（ローテーション、アクセス制御、監査）を自社で管理でき、第三者監査や法令対応の証跡整備が容易になる

技術的な注意点 ​

  • IAM権限: EMR Serverlessとジョブ実行ロールに対してKMSのDecrypt/Encrypt/GenerateDataKey/DescribeKey等が必要。CMKのキーポリシーやグラントでサービス/実行ロールにキー使用を許可してください
  • リージョン制限: EMR Serverlessが提供されているすべてのリージョン（GovCloud/China含む）で利用可能。ただし利用前に対象リージョンでサービス提供状況とドキュメントを確認してください
  • コスト: AWS KMSのカスタマーマネージドキー利用に伴うKMS API呼び出し料金およびキー管理料金が発生する可能性があります（キー作成やAPIリクエストに対する課金）
  • キー管理（クロスアカウント）: 別アカウントのCMKを使う場合は、CMKのキーポリシーやグラントでEMR Serverless実行側のアカウント/ロールを明示的に許可する必要があります
  • 既存ワークロードへの影響: 設定は新しいアプリケーション設定またはジョブ実行時の指定に適用されます。既に作成済みのローカルディスクに対する既存の暗号化状態はそのままで、既存データの再暗号化は自動では行われません
  • 設定方法: EMR Serverlessのアプリケーション設定またはジョブ実行/対話セッションのパラメータでCMKを指定します（コンソール／CLI／SDK経由での指定が可能）。キーが無効化・削除されるとジョブ実行に失敗するためライフサイクル管理に注意してください

参考情報 ​

[Bedrock] Amazon Bedrock Reserved Tier available now for Claude Sonnet 4.5 in AWS GovCloud (US-West) ​

概要 ​

Amazon BedrockのReserved（予約）サービス層がAnthropic Claude Sonnet 4.5でAWS GovCloud (US-West)に拡張されました。トークン/分の保証容量と優先コンピュートを予約でき、1か月または3か月単位で利用できます。

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

Reserved Tierは、トークン毎分（tokens-per-minute）の保証容量を予約して優先的なコンピュートを確保することで、ミッションクリティカルなアプリケーションに対して予測可能な性能を提供します。入力（input）と出力（output）のtokens-per-minuteを別々に割り当て可能で、要件に応じた非対称なトークン使用（例：要約は入力多め／出力少なめ、生成は入力少なめ／出力多め）に対応できます。予約した容量を超える需要が発生した場合は、自動的に従量課金のStandard（pay-as-you-go）層へオーバーフローして処理を継続するため、サービス中断を回避できます。料金体系は1K tokens-per-minuteあたり固定価格で月次請求、予約期間は1か月または3か月です。本告知での提供対象はAnthropic Claude Sonnet 4.5で、利用はAWS GovCloud (US-West)に限定されます。アクセスにはGOV-CRISクロスリージョンプロファイルを使用し、Reserved Tierの利用申請はAWSアカウントチームへの連絡が必要です。詳細や対応リージョンはドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ミッションクリティカルな生成系/解析系アプリケーションを運用するクラウドエンジニア、SRE、AIプロダクトオーナー
  • 利用シーン: 要求性能を保証したいチャットボット、要約バッチ処理、ドキュメント生成やAPI経由の大量同時リクエスト処理
  • 運用効果: トークン/分の保証と優先コンピュートによりピーク時の予測可能性が向上し、サービス安定性が改善される
  • コスト影響: 予約による固定費（1K tokens-per-minuteあたりの月額）と、予約超過時の従量課金が併存するため、利用パターンに応じたコスト最適化が必要
  • リージョン制限: 現時点ではAWS GovCloud (US-West)で提供（他リージョンはドキュメント参照／要確認）

技術的な注意点 ​

  • IAM権限: Bedrock利用に必要なIAMポリシー（Bedrockへのアクセス権）やGovCloudアカウントの権限を事前に確認してください
  • リージョン制限: 提供はAWS GovCloud (US-West)に限定。一般的なAWS商用リージョンでは未定（ドキュメントで対象リージョンを確認すること）
  • コスト: 予約料金（固定）に加え、予約容量超過分はStandard層の従量課金で請求されるため、負荷パターンに基づく容量設計が重要です
  • アクセス方法: GOV-CRISクロスリージョンプロファイル経由での利用およびAWSアカウントチームへの申し込みが必要です
  • 予約期間/請求: 1か月または3か月の予約が可能で、1K tokens-per-minute単位の固定価格が月次請求されます
  • 運用上の注意: オーバーフロー時は自動でStandard層へ切り替わるが、遅延やコスト増の影響が生じる可能性があるためSLOや費用の想定を行い、必要なら大きめに予約するか監視・アラートを設定してください
  • SLA/保証: 明確なSLA値は告知に記載されていないため、詳細はドキュメントまたはアカウントチームに確認してください

参考情報 ​

[Ec2] Amazon EC2 C8gn instances are now available in additional regions ​

概要 ​

Amazon EC2 の最新 Graviton4 搭載 C8gn インスタンスが、追加リージョン（ムンバイ、ケープタウン、アイルランド、ロンドン、カルガリー等）で利用可能になりました。C7gn 比で最大約30%の演算性能向上と最大600 Gbps のネットワーク帯域を提供します。

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

C8gn は第4世代 AWS Graviton（Graviton4）プロセッサを搭載するネットワーク最適化インスタンスです。主な技術仕様は、Graviton3 ベースの C7gn に対して最大30% のコンピュート性能向上、最新の第6世代 Nitro Card を採用し最大600 Gbps のネットワーク帯域（ネットワーク最適化インスタンス中で最高）を実現します。インスタンスは最大48xlarge まで用意され、最大384 GiB メモリ、EBS に対する帯域は最大60 Gbps をサポートします。さらに、低遅延・クラスター性能向上のために Elastic Fabric Adapter（EFA）を 16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xl のサイズでサポートします。これらにより、ネットワーク仮想アプライアンス、データ解析、CPU ベースの AI/ML 推論、スループット重視のワークロードで高い性能とスケーラビリティを得られます。利用開始は AWS マネジメントコンソール、AWS CLI、各種 SDK から可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク集約型ワークロードを運用するクラウドエンジニア、SRE、ネットワーク仮想アプライアンスベンダー、データ分析／推論エンジニア
  • 利用シーンまたは効果: 高帯域・低遅延が要求されるトラフィック処理（NVA）、大規模データ分析、CPUベースのAI/ML推論、HPCクラスターでの通信集約処理のスループット向上とレイテンシ低減
  • 運用効果: 単位時間当たりの処理能力向上によりコスト効率が改善する可能性（同等性能でインスタンス数を削減）、EFA 対応サイズではクラスタ性能とスケール効率が向上
  • リージョン影響: 追加されたリージョン（ムンバイ、ケープタウン、アイルランド、ロンドン、カルガリー）で直接デプロイ可能になり、データ主権やレイテンシ要件に対応しやすくなる

技術的な注意点 ​

  • リージョン制限: 新たに Asia Pacific (Mumbai), Africa (Cape Town), Europe (Ireland, London), Canada West (Calgary) で利用可能。その他の対応リージョンも存在するため、展開前にリージョンでの可用性を確認してください。
  • インスタンス仕様: 最大48xlarge、最大384 GiB メモリ、ネットワーク帯域最大600 Gbps、EBS 帯域最大60 Gbps。EFA は 16xlarge、24xlarge、48xlarge、metal-24xl、metal-48xl のみサポート。
  • AMI / ドライバ: ARM64 (Graviton4) 対応の AMI とアプリケーションが必要。ENA/EFA ドライバおよびカーネルやライブラリの互換性確認・更新を行ってください（Amazon Linux 2 や主要ディストリビューションは最新版で対応）。
  • 配置とネットワーク: EFA を使う場合はクラスタ配置グループ（placement group）やネットワーク設定が必要。高いネットワーク帯域を利用するワークロードでは ENI 設計やスループット上限を考慮してください。
  • サービスクォータ（vCPU 等）: 新リージョンではデフォルトの vCPU 上限があるため、運用前に Service Quotas で確認し、必要なら増枠申請を行ってください。
  • IAM権限: インスタンス起動、ENI/EFA の割当、EBS ボリューム操作に必要な IAM 権限を事前に確認してください。
  • コスト: Graviton4 による性能向上でコスト効率は改善し得るが、インスタンス単価・データ転送・EBS スループットコスト等を含めて料金比較を行ってください。
  • 互換性注意: 一部サードパーティソフトやドライバが ARM (aarch64) に未対応の場合があるため、移行前にアプリケーション互換性テストを推奨します。

参考情報 ​

[IAM] AWS introduces additional policy details to access denied error messages ​

概要 ​

AWSはアクセス拒否（AccessDenied）エラーメッセージに、同一アカウントおよび同一組織内のIAM／OrganizationsポリシーのARNを追加しました。これにより、どのポリシーが拒否を引き起こしているかをすばやく特定でき、トラブルシューティングが容易になります。

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

従来、AccessDeniedエラーにはポリシーの種類（例：SCP、identity-based policy 等）のみが表示されていましたが、今回の変更で同一アカウントおよび同一組織内のケースに限り、該当ポリシーのAmazon Resource Name（ARN）がエラーメッセージに含まれるようになります。対象となるポリシー種別は、Service Control Policies（SCP）、Resource Control Policies（RCP）、アイデンティティベースポリシー（ユーザー/ロールにアタッチされたポリシー）、セッションポリシー（STSのセッションポリシー）、およびパーミッション境界です。

このARNが表示されることで、同じ種類のポリシーが複数存在する環境でも、明示的なdenyを与えている正確なポリシーを直接特定できます。ポリシーの詳細（ドキュメント）を確認するには表示されたARNをもとに、IAMのGetPolicy/GetPolicyVersionやAWS OrganizationsのDescribePolicyなどのAPI／コンソール操作でポリシー本体を取得します。ただしエラーメッセージに含まれるのはポリシーのARNであり、ポリシー本文そのものが自動的に露出するわけではありません。機能はAWSサービスを横断して段階的に全リージョンへ展開されます。

影響範囲・利用シーン ​

  • 対象ユーザー: IAM/Organizationsを運用するクラウドエンジニア、SRE、セキュリティチーム
  • 利用シーンまたは効果: 複数の同種ポリシーがある環境でAccessDenied発生時に、どのポリシー（SCP/RCP/アイデンティティポリシー/セッションポリシー/パーミッション境界）が原因かを即座に特定し、該当ポリシーを修正または例外対応できる
  • 運用効果: トラブルシューティング時間の短縮、誤ったポリシー調査による無駄工数の削減、明示的なdenyの早期発見によるアクセス問題の迅速解決
  • 制限: 表示されるのはARNのみでポリシー本文は表示されないため、ARNから別途ポリシー本文を取得する必要がある
  • セキュリティ運用への影響: 誰がARNを確認できるかに応じて、ポリシー存在情報が明らかになる可能性があるため、表示権限と情報管理ポリシーを確認する必要あり

技術的な注意点 ​

  • IAM権限: 表示されたARNからポリシー本文を確認するには、iam:GetPolicy / iam:GetPolicyVersion（identity-based）やorganizations:DescribePolicy（SCP等）などの閲覧権限が必要です
  • リージョン制限: 全リージョンへ順次展開中のため、利用しているリージョン/サービスではまだ反映されていない場合があります
  • コスト: 本機能自体に追加料金は発生しません（ただしポリシー取得APIを実行する場合は通常のAPI呼び出しに伴うレート制限などに注意）
  • 表示内容: エラーメッセージに含まれるのはポリシーのARNのみで、ポリシーの全文や評価履歴が自動的に表示されるわけではありません
  • セキュリティ上の考慮: 他者にARNが見えることでポリシーの存在が推測され得るため、必要最小限の情報公開とIAM閲覧権限の管理を継続してください
  • ログ/監査: CloudTrail等の既存監査ログの扱いは変わりませんが、エラーメッセージに含まれるARNを運用ツールやログ集約に取り込むことで解析が容易になります

参考情報 ​

[General] Instance Scheduler on AWS adds enhanced scaling, reliability, and event-driven automation ​

概要 ​

Instance Scheduler on AWSがスケジューリングのオーケストレーションを再設計し、タグイベント追跡、セルフサービス用の情報タグ、EC2の容量不足時に代替インスタンスタイプで再試行するオプション、スケジューリング専用のEventBridge EventBus自動作成を追加しました。これによりスケーラビリティ、信頼性、運用の分散化が向上します。

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

主な変更点は次の通りです。1) タグイベント追跡と強化されたオーケストレーション／fan-out: Instance Schedulerの内部処理が再アーキテクチャされ、AWSのタグ付けイベントを検知してスケジュール操作のシーケンスと配布をより賢く行えるようになりました。これにより多数アカウント・多数リソース環境でのスケーリング性能が向上します。2) セルフサービスのトラブルシューティングを支援する情報タグ: スポーク（メンバー）アカウントに配置されたリソースに対して情報用タグを付与し、現場のクラウドエンジニアが中央管理者に依存せずに問題の原因を把握・切り分けできるようになりました。3) 不足容量（Insufficient Capacity）再試行フロー（オプション）: EC2で起動失敗が不足容量エラーとなった場合、別のインスタンスタイプで自動的に再試行するオプションを導入。特定のAZやリージョンで容量制約がある場合でもワークロードの開始成功率を高めます。4) スケジューリング用の専用EventBridge EventBus自動作成: スケジューリング関連イベントを隔離した専用のEventBusを自動で作成し、外部システムやEventBridgeルールとの統合を簡素化、イベントルーティングと拡張性が向上します。これらの変更により、大規模・分散環境での運用負荷が低下し、稼働率と自動化の柔軟性が高まります。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用チーム（SRE）、クラウドエンジニア、マルチアカウント環境の運用管理者
  • 利用シーンまたは効果: 大規模／分散アカウントでのインスタンスのスケジュール運用（コスト最適化のためのオンオフ）、スポークアカウントでの自己診断、容量不足時の起動成功率向上
  • 運用効果: スケーラビリティ向上により多数リソースの同時スケジュール実行が安定化、情報タグで現場が自律的に問題解決可能に、容量不足の自動再試行でダウンタイムや手動対応を削減

技術的な注意点 ​

  • IAM権限: Instance SchedulerがEventBridge EventBusを自動作成・イベント送信・EC2操作（Start/Stop/Describe/Modify）を行うための権限が必要です。導入時に付与するIAMポリシーを確認してください。
  • リージョン制限: 新機能はEventBridgeやEC2が利用可能なリージョンで動作しますが、実際の提供状況やリージョン固有の挙動（Capacity状況など）はリージョンごとに異なります。導入前に対象リージョンで動作確認してください。
  • コスト: EventBridgeのルール・PutEvents、追加のLambda/Step Functions実行、CloudWatchログ、及び容量不足時に代替インスタンスタイプを起動した場合のEC2料金が発生する可能性があります。コスト影響を事前に評価してください。
  • タグ運用: 情報タグの命名規約・付与ポリシーを設計してください。タグの変更・削除がトラブルシューティング情報やオーケストレーションに影響を与える可能性があります。
  • 代替インスタンスタイプの互換性: 自動で選択される代替タイプはアプリケーションの要件（vCPU、メモリ、ネットワーク、プレースメントグループ、EBS最適化、ライセンス要件等）に合致するか事前確認が必要です。
  • 既存環境との互換性: 自動EventBus作成や新しいオーケストレーションロジックは既存のカスタム統合やルールに影響を及ぼす場合があります。既存のEventBridgeルールや監視フローとの整合性を確認してください。
  • 特記事項: 重大な注意点がない場合でも、本番環境導入前にステージングでの検証を推奨します。

参考情報 ​

[Outposts] Announcing availability of second-generation AWS Outposts racks in 20 more countries ​

概要 ​

第二世代のAWS Outpostsラックが20か国で利用可能になりました。オンプレミスで最新世代のAmazon EC2インスタンスを実行でき、データレジデンシーや低遅延要件に対応します。

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

今回の拡張により、第二世代（2nd-gen）AWS Outpostsラックはアルゼンチン、バングラデシュ、コロンビア、ドミニカ共和国、エクアドル、インド、カザフスタン、メキシコ、モロッコ、ナイジェリア、オマーン、パナマ、カタール、セネガル、セルビア、南アフリカ、韓国、台湾、タイ、ウルグアイのデータセンターやオンプレミス施設へ出荷・設置できるようになりました。第二世代Outpostsラックは最新のx86ベースのAmazon EC2インスタンス（C7i、M7i、R7iなど）をサポートし、第一世代のC5/M5/R5と比較して最大で約40%の性能向上を実現します。ネットワーク面ではスケーリングと構成が簡素化され、新たなカテゴリのアクセラレーテッドネットワーキング対応インスタンス（超低遅延・高スループット向け）も利用可能です。OutpostsラックはAWSインフラ、サービス、API、ツールをローカル環境に拡張し、ローカルでのサービス実行と、管理・運用のためのサポートされたAWSリージョンへの接続を組み合わせて、データ主権やレイテンシ要件に対応します。詳細は公式ユーザーガイドとFAQを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ハイブリッド環境を求めるクラウド/インフラエンジニア、オンプレミスでの低遅延処理やデータレジデンシーを必要とするシステムオーナー
  • 利用シーン: ローカルでのデータ処理（IoTゲートウェイ、金融取引、医療画像処理）、レイテンシ厳格なアプリケーション、現地法令によるデータレジデンシー対応、クラウド移行時の依存関係を持つアプリケーションの移行
  • 運用効果: 最新世代インスタンスによる処理性能向上（最大約40%）、ネットワーク設定の簡素化による運用負荷低減、オンプレでのAWSサービス実行による応答性とコンプライアンスの改善
  • ビジネス/コンプライアンスへの影響: 指定国内でのOutposts設置によりデータ主権要件や規制準拠が容易になり、国際的な事業展開での選択肢が拡大

技術的な注意点 ​

  • 対応インスタンス: C7i、M7i、R7iなどの最新x86世代をサポート（第一世代のC5/M5/R5に対して最大約40%の性能改善）
  • ネットワーク要件: サポートされるAWSリージョンへの管理接続が必要。アクセラレーテッドネットワーキング利用時はNIC/ドライバ要件を確認
  • 設置要件: ラックスペース、電源（冗長電源含む）、冷却、現地搬入・設置作業が必要。AWSとの設置スケジュール調整と物理アクセス手配が必須
  • 互換性/移行: 第一世代Outpostsとのインプレース互換性は限定的な場合があるため、アーキテクチャとAMI/ドライバ互換性を検証
  • リージョン制限: 管理と運用のために接続する“サポートされたAWSリージョン”が必要。最新の対応リージョン・国リストはFAQで確認
  • IAM権限: Outpostsのデプロイ・管理には適切なAWS IAM権限が必要（Outposts関連のサービスロール/ポリシー）
  • コスト: ハードウェアの導入費用、設置・輸送費、稼働中のインスタンス・サービス料金が発生。リージョン/国によって料金や税・輸送コストが変動する可能性あり
  • サポート: 導入前にAWSセールス/サポートと連携して物流、設置要件、保守契約（RMA/交換ポリシー等）を確認

参考情報 ​

[Mq] Amazon MQ now supports Java Messaging Service (JMS) specification for RabbitMQ brokers ​

概要 ​

Amazon MQのRabbitMQ 4ブローカーで、RabbitMQ JMS Topic ExchangeプラグインとRabbitMQ JMSクライアントを使ってJMSアプリケーションを直接接続できるようになりました。JMS 1.1／2.0／3.1をサポートし、AMQPワークロードとの相互運用や段階的な移行が容易になります。

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

Amazon MQのRabbitMQ 4ブローカー（RabbitMQ 4.2を選択）では、RabbitMQ JMS Topic Exchangeプラグインがデフォルトで有効になり、RabbitMQ JMSクライアントを用いて既存のJMSアプリケーション（JMS 1.1、2.0、3.1）をRabbitMQ上で動作させることができます。これにより、JMSクライアントからAMQPエクスチェンジへメッセージを送信したり、AMQPキューからメッセージを消費するなど、JMSとAMQP間の相互運用が可能になり、JMSワークロードの段階的なAMQP移行が容易になります。ブローカーの作成はAWS Management Console、AWS CLI、SDKから行え、M7gインスタンスタイプでRabbitMQ 4.2を選択することで利用を開始できます。本プラグインはAmazon MQ RabbitMQ 4が提供されているリージョンで利用可能で、詳細はAmazon MQのリリースノートおよび開発者ガイドに記載されています。

影響範囲・利用シーン ​

  • 対象ユーザー: JMSベースのアプリケーション開発者、メッセージング基盤のアーキテクト、移行担当者、SRE/運用チーム
  • 利用シーン: 既存のJMSアプリケーションをRabbitMQ上で稼働させたい場合、JMSとAMQPの相互運用が必要なハイブリッド環境、段階的にJMSワークロードをAMQPへ移行する場合
  • 運用効果: 既存のJMSコードを再利用してRabbitMQに移行できるため開発工数とリファクタリングを削減し、段階的移行によりリスクを低減。AMQPシステムとの連携により柔軟なアーキテクチャが構築可能
  • 制約・前提: RabbitMQブローカーはRabbitMQ 4（例: 4.2）で提供される必要があり、M7gインスタンスタイプの選択が案内されている。プラグインはAmazon MQ RabbitMQ 4が提供されているリージョンでのみ利用可能

技術的な注意点 ​

  • IAM権限: ブローカー作成・変更にはAmazon MQ関連のIAM権限（CreateBroker、UpdateBroker、DescribeBroker等）が必要です。アクセス用シークレットは管理してください
  • リージョン制限: 本機能はAmazon MQ RabbitMQ 4が提供されているリージョンで利用可能です。全リージョンで自動的に有効というわけではありません
  • コスト: プラグイン自体に追加料金は明示されていませんが、RabbitMQ 4（M7g等）を選択することでインスタンス課金やデータ転送費用が発生します
  • バージョン互換性: サポート対象はRabbitMQ 4ブローカー（記事例では4.2）およびJMS 1.1／2.0／3.1のクライアントです。使用するJMSクライアントのバージョン互換性を事前確認してください
  • クライアント設定: RabbitMQ JMSクライアントの接続URL、ユーザー／パスワード、仮想ホストやTLS設定を適切に構成する必要があります。接続時の通信暗号化（TLS）や認証方式を運用基準に合わせて設定してください
  • 運用・監視: CloudWatchメトリクスやログ、Amazon MQコンソールでブローカーの状態・接続数・スループットを監視し、JMS→AMQPのマッピングやメッセージの到達性を検証してください
  • セキュリティ: ブローカーのユーザー管理・権限（アクセス制御）とTLSを利用したネットワーク保護を推奨します。必要に応じてVPCエンドポイントやセキュリティグループでアクセス制限を行ってください

参考情報 ​

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

Copyright © 2026