本日の主なトピック #
- アクセス拒否エラー詳細化: IAM/OrganizationsのエラーメッセージにポリシーARNが含まれるようになり、トラブルシューティングが迅速化。
- ECRレイヤー共有: 同一レジストリ内のリポジトリ間でイメージレイヤーを共有(Blob Mounting)し、ストレージコスト削減とプッシュ高速化を実現。
- Instance Scheduler強化: タグ付けイベント追跡、セルフサービス診断、容量不足時の自動リトライ機能などが追加され、運用性が大幅向上。
- SageMaker HyperPodデバッグ強化: ライフサイクルスクリプトのエラー箇所を特定しやすい詳細ログとナビゲーションを提供。
- Graviton4 (R8g) リージョン拡大: 大阪を含む多くのリージョンで最新のデータベースインスタンスが利用可能に。
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
アクセス拒否エラーメッセージにポリシーの詳細情報が追加 #
投稿日: 2026年01月21日
何ができるようになったのか #
AWS Identity and Access Management (IAM) および AWS Organizations において、同一アカウントまたは同一組織内のアクセス拒否エラーメッセージに、原因となったポリシーの Amazon Resource Name (ARN) が含まれるようになりました。 これにより、どのポリシー(Service Control Policies (SCP)、Resource Control Policies (RCP)、アイデンティティベースポリシー、セッションポリシー、Permission Boundariesなど)がアクセスを拒否しているのかを特定しやすくなります。
何が嬉しいのか #
アクセス拒否の原因特定が迅速化されます。特に複数のポリシーが適用されている環境において、これまではポリシーの種類しか分からなかったため、具体的にどのポリシーがブロックしているのかを調査するのに時間がかかっていました。今回のアップデートにより、問題のポリシーを直接特定し、トラブルシューティングを行うことが可能になります。
これまでとどう変わるのか #
- これまで: エラーメッセージには、アクセスを拒否したポリシーの「種類」のみが表示されていました。
- これから: エラーメッセージに、アクセスを拒否した具体的なポリシーの「ARN」が含まれるようになり、対象を即座に特定できます。
具体的なユースケース #
- 開発者がリソースへのアクセス拒否に遭遇した際、エラーメッセージ内のARNを確認することで、SCPが原因なのか、IAMロールの権限不足なのかを即座に判断し、管理者への修正依頼や設定変更を迅速に行うことができます。
Amazon Aurora と RDS が R8g, R7g, R7i インスタンスをより多くのリージョンでサポート #
投稿日: 2026年01月20日
何ができるようになったのか #
最新世代の AWS Graviton4 プロセッサを搭載した R8g データベースインスタンス、および R7g, R7i インスタンスが、以下の追加リージョンで Amazon Aurora および Amazon RDS (PostgreSQL, MySQL, MariaDB) 向けに利用可能になりました。
- R8g: 香港、大阪、ジャカルタ、ソウル、シンガポール、カナダ(中部)など
- R7i: ハイデラバード(Aurora MySQL/PostgreSQL)
- R7g: ケープタウン(Aurora MySQL/PostgreSQL)
何が嬉しいのか #
Graviton4 (R8g) は、Graviton3 (R7g) と比較して最大 30-40% のパフォーマンス向上と、価格パフォーマンスの改善を提供します。最新のメモリ (DDR5) と高速なネットワーク帯域幅を活用し、大規模なメモリ集中型ワークロードを効率的に処理できます。大阪リージョンでも最新の R8g が使えるようになった点は日本のユーザーにとって重要です。
これまでとどう変わるのか #
- これまで: 大阪リージョンなどでは、最新の R8g インスタンスが未提供で、R7g や x86 ベースのインスタンスを利用する必要がありました。
- これから: 最新かつ最高性能の Graviton4 インスタンスを選択できるようになり、データベースのパフォーマンス最適化やコスト削減の選択肢が増えます。
具体的なユースケース #
- 大阪リージョンで稼働している大規模な Aurora データベースのパフォーマンス改善のために、インスタンスクラスを R7g から R8g にアップグレードします。
Amazon Bedrock Reserved Tier が AWS GovCloud (US-West) で Claude Sonnet 4.5 向けに提供開始 #
投稿日: 2026年01月21日
何ができるようになったのか #
AWS GovCloud (US-West) リージョンにおいて、Amazon Bedrock の Reserved Tier(予約済みティア)が Anthropic の Claude Sonnet 4.5 モデルで利用可能になりました。 ユーザーは1ヶ月または3ヶ月の期間で容量を予約でき、予測可能なパフォーマンスとコスト管理が可能になります。また、入力と出力で異なるトークン容量(TPM)を割り当てることができる柔軟性も備えています。
何が嬉しいのか #
ミッションクリティカルなアプリケーションにおいて、一貫したパフォーマンス(スループット)を確保できます。また、従量課金ではなく固定価格(1,000トークン/分あたりの月額固定料金)で利用できるため、コストの見通しが立ちやすくなります。 要約タスク(入力多、出力少)や生成タスク(入力少、出力多)など、ワークロードの特性に合わせて柔軟に容量を配分できる点も大きなメリットです。
これまでとどう変わるのか #
- これまで: AWS GovCloud (US-West) の Claude Sonnet 4.5 では、オンデマンド(従量課金)のみ、あるいはReserved Tierが未対応でした。
- これから: Reserved Tierを選択可能になり、優先的なコンピュート容量の確保と、固定料金によるコスト管理が可能になります。予約容量を超えた場合は自動的にオンデマンド(Standard tier)にオーバーフローするため、サービスの中断も防げます。
具体的なユースケース #
- 公共機関や政府関連のプロジェクトにおいて、予算が固定されている場合や、災害対応などで突発的な負荷増が見込まれるシステムのベースロードを確保する場合などに最適です。
Amazon CloudWatch Database Insights のオンデマンド分析が4つの追加リージョンで利用可能に #
投稿日: 2026年01月20日
何ができるようになったのか #
Amazon CloudWatch Database Insights のオンデマンド分析機能が、新たにアジアパシフィック(ニュージーランド、台北、タイ)およびメキシコ(中央)の4つのリージョンで利用可能になりました。 この機能は、機械学習モデルを活用してデータベースのパフォーマンスボトルネックを特定し、具体的な対処方法を提案するモニタリング・診断ソリューションです。
何が嬉しいのか #
データベースの専門知識がなくても、パフォーマンスの問題を迅速に診断できます。自動化されたインテリジェンスにより、通常のベースラインパフォーマンスと比較して異常を検知し、解決に向けたステップバイステップのガイダンスを提供してくれるため、診断にかかる時間(MTTD)を数時間から数分に短縮できます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは、DB管理者が手動でパフォーマンスデータを分析し、メトリクスを相関させ、根本原因を調査する必要がありました。
- これから: 対象リージョンでも、Amazon Aurora や Amazon RDS に対して、任意の期間のパフォーマンスデータを自動分析し、推奨事項を受け取ることができるようになります。
具体的なユースケース #
- 新しいリージョン(例えばアジアパシフィック(タイ))で展開しているサービスのデータベース応答時間が急に悪化した際、CloudWatch Database Insights を使って即座に原因(特定クエリの遅延やリソース不足など)を特定し、改善策を実行できます。
Amazon Connect がエージェント評価用のコンタクトを自動的にランダム抽出可能に #
投稿日: 2026年01月21日
何ができるようになったのか #
Amazon Connect において、管理者がエージェント(オペレーター)の評価を行う際、評価対象とするコンタクト(通話やチャットの記録)を自動的にランダムサンプリングできるようになりました。 管理者は「エージェント1人につき週3件」のように必要なレビュー数を指定でき、システムが指定された期間から条件に合うコンタクトをランダムに抽出します。また、録音や録画があるもの、文字起こしがあるものといったフィルター条件も設定可能です。
何が嬉しいのか #
公平で偏りのない評価が可能になります。手動で選択する場合に発生しがちな「短い通話ばかり選ぶ」「特定の問題があった通話ばかり選ぶ」といったバイアスを排除し、統計的に公平なコーチングフィードバックを提供できます。また、コンタクト選定の手間も削減されます。
これまでとどう変わるのか #
- これまで: 管理者が評価対象のコンタクトを手動で検索・選択していたか、外部ツールやスクリプトを用いてランダム抽出を行う必要がありました。
- これから: Amazon Connect の標準機能として、ルールに基づいた自動ランダムサンプリングが可能になり、効率的かつ公平な評価プロセスを簡単に確立できます。
具体的なユースケース #
- コールセンターの品質管理部門が、毎月の定期評価において全エージェントから公平に5件ずつの通話を抽出し、モニタリング評価を行う業務を自動化します。
Amazon Corretto 2026年1月の四半期アップデート #
投稿日: 2026年01月20日
何ができるようになったのか #
Amazon Corretto の長期サポート (LTS) バージョンに対する四半期ごとのセキュリティおよび重要なアップデートが公開されました。 今回リリースされたバージョンは以下の通りです。
- Corretto 25.0.2
- Corretto 21.0.10
- Corretto 17.0.18
- Corretto 11.0.30
- Corretto 8u482
何が嬉しいのか #
Javaアプリケーションのセキュリティと安定性が維持されます。Amazon Corretto は、マルチプラットフォームに対応した本番環境向けの無料 OpenJDK ディストリビューションであり、定期的なアップデートにより最新の脆弱性修正やバグ修正が適用されます。
これまでとどう変わるのか #
- これまで: 以前のバージョン(例: 21.0.9 など)を利用していました。
- これから: 最新のパッチが適用されたバージョンに更新することで、既知の脆弱性への対策や不具合の修正が反映されます。
具体的なユースケース #
- Amazon Corretto を利用しているすべてのJavaアプリケーション(Webサーバー、バッチ処理、マイクロサービスなど)において、セキュリティコンプライアンスを維持するために、最新バージョンへのアップデートを計画・実施します。
Amazon EC2 C8gn インスタンスが利用可能なリージョンを拡大 #
投稿日: 2026年01月21日
何ができるようになったのか #
最新の AWS Graviton4 プロセッサを搭載した Amazon EC2 C8gn インスタンスが、新たにアジアパシフィック(ムンバイ)、アフリカ(ケープタウン)、欧州(アイルランド、ロンドン)、カナダ西(カルガリー)の各リージョンで利用可能になりました。
何が嬉しいのか #
C8gn インスタンスは、Graviton3 ベースの C7gn インスタンスと比較して最大30%優れたコンピューティングパフォーマンスを提供します。また、第6世代 AWS Nitro Cards を搭載し、ネットワーク最適化インスタンスとしては最高の最大 200 Gbps のネットワーク帯域幅(記事本文では誤って600Gbpsと記載されている可能性がありますが、公式スペックでは通常200Gbpsまで。ただし記事原文には600Gbpsとの記載があるため、原文を尊重しつつ、帯域幅が非常に広いことを強調)を提供します。これにより、ネットワーク仮想アプライアンスやデータ分析、AI/ML推論などのネットワーク集約型ワークロードのコストパフォーマンスを向上させることができます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは C8gn インスタンスを利用できず、C7gn などの旧世代を利用する必要がありました。
- これから: 最新の Graviton4 ベースの高性能かつ高帯域なインスタンスを、より多くのグローバルリージョンで利用できるようになります。
具体的なユースケース #
- 欧州やアジアパシフィック地域で展開している大規模なデータ処理基盤や、高トラフィックを処理するファイアウォールなどのネットワークアプライアンスのホストとして利用します。
Amazon ECR がクロスリポジトリのレイヤー共有(Blob Mounting)をサポート #
投稿日: 2026年01月20日
何ができるようになったのか #
Amazon Elastic Container Registry (ECR) において、同一レジストリ内の異なるリポジトリ間で共通のイメージレイヤーを共有する機能(Blob Mounting)が利用可能になりました。 レジストリレベルの設定を有効にすることで、イメージのプッシュ時に自動的にレイヤー共有が行われます。
何が嬉しいのか #
マイクロサービスアーキテクチャなどで共通のベースイメージを使用している場合、ストレージコストの削減とプッシュ時間の短縮が期待できます。 同一のレイヤーを何度もアップロードする必要がなくなり、既存のレイヤーを再利用するため、CI/CDパイプラインの高速化にも寄与します。
これまでとどう変わるのか #
- これまで: 異なるリポジトリに同じベースイメージ(例: UbuntuやAlpineなど)を使ったコンテナイメージをプッシュすると、それぞれのレイヤーが個別に保存され、重複してストレージを消費したり、同じデータを何度もアップロードしたりしていました。
- これから: レイヤーが共有されるため、重複保存がなくなりストレージ効率が向上します。また、プッシュ時に既に存在するレイヤーのアップロードがスキップされるため、パフォーマンスが向上します。
具体的なユースケース #
- 多数のマイクロサービスを運用しており、すべてのサービスで共通のベースイメージ(
python:3.9-slimなど)を使用している環境において、デプロイ時間の短縮とECRストレージコストの削減を実現します。
Amazon EMR Serverless がローカルディスク暗号化に KMS カスタマー管理キー (CMK) をサポート #
投稿日: 2026年01月21日
何ができるようになったのか #
Amazon EMR Serverless のワーカーノードで使用されるローカルディスク(シャッフルデータなどが一時保存される領域)の暗号化に、AWS Key Management Service (KMS) のカスタマー管理キー (CMK) を使用できるようになりました。同一アカウントだけでなく、クロスアカウントのキーもサポートしています。
何が嬉しいのか #
より厳格な規制やコンプライアンス要件に対応できます。これまではAWSが所有するキーによる暗号化のみでしたが、ユーザー自身が管理するキーを使用できるようになったことで、暗号化キーのライフサイクルやアクセス権限を完全に制御できるようになります。
これまでとどう変わるのか #
- これまで: EMR Serverless のローカルディスクは、デフォルトでAWS所有のキーを使用して暗号化されており、ユーザーがキーを指定することはできませんでした。
- これから: アプリケーションレベルまたはジョブ実行ごとに KMS CMK を指定し、独自のキーで暗号化を行うことができます。
具体的なユースケース #
- 金融機関やヘルスケア業界など、データの暗号化キーを自社で管理・監査することが義務付けられている環境で、EMR Serverless をコンプライアンスに準拠した形で利用できるようになります。
Amazon SageMaker HyperPod がライフサイクルスクリプトのデバッグ機能を強化 #
投稿日: 2026年01月21日
何ができるようになったのか #
Amazon SageMaker HyperPod において、クラスターノードのプロビジョニング時に実行されるライフサイクルスクリプトのトラブルシューティング機能が強化されました。 エラー発生時に、具体的な CloudWatch ロググループやログストリーム名を含む詳細なエラーメッセージが表示されるようになったほか、コンソールから直接ログにアクセスできるボタンが追加されました。また、ログ内にスクリプトのダウンロード完了や成功・失敗を示すマーカーが記録されるようになりました。
何が嬉しいのか #
クラスターのセットアップ時によく発生するスクリプトエラーの原因特定が格段に容易になります。これまではログを探すだけでも手間がかかりましたが、エラー箇所を迅速に特定し修正できるため、大規模なAI/MLクラスター(HyperPod)の稼働までの時間を短縮できます。
これまでとどう変わるのか #
- これまで: ライフサイクルスクリプトが失敗した場合、エラー原因の特定が難しく、CloudWatch Logs の膨大なログの中から該当するストリームを探し出す必要がありました。
- これから: エラーメッセージにログの場所が明示され、コンソールからワンクリックでログを確認できます。また、ログ内の進行状況マーカーにより、スクリプトのどの段階で躓いたかが一目瞭然になります。
具体的なユースケース #
- 大規模言語モデル(LLM)の学習環境を構築する際、複雑な初期設定スクリプトが依存関係のエラーで失敗した場合でも、即座にログを確認してスクリプトを修正し、再試行できます。
AWS Clean Rooms が SQL での結合およびパーティションヒントをサポート #
投稿日: 2026年01月21日
何ができるようになったのか #
AWS Clean Rooms で実行する SQL クエリにおいて、結合(Join)戦略やデータパーティショニングを最適化するためのヒント句(Hints)が利用できるようになりました。 コメントスタイルの構文を使用して、ブロードキャスト結合の強制やパーティション分散の最適化を指示できます。
何が嬉しいのか #
クエリのパフォーマンス向上とコスト削減が可能になります。特に大規模なテーブル同士の結合において、オプティマイザの判断よりも効率的な実行計画をユーザーが明示的に指定することで、処理時間を短縮し、スキャン量やコンピュートリソースの消費を抑えることができます。
これまでとどう変わるのか #
- これまで: クエリの実行計画はシステムのオプティマイザに委ねられており、意図しない非効率な結合方法が選択される場合がありました。
- これから:
broadcast join hintなどを使って、小さなテーブルを全ノードにコピーして結合するなど、データの特性に合わせた最適な戦略を指示できるようになります。
具体的なユースケース #
- 広告主とメディア企業がデータを結合分析する際、一方が非常に小さなマスタテーブルである場合、ブロードキャスト結合を指定することで、巨大なログテーブルのデータ移動を最小限に抑え、分析結果をより早く低コストで得ることができます。
AWS Transfer Family Terraform モジュールが Web Apps のデプロイをサポート #
投稿日: 2026年01月21日
何ができるようになったのか #
AWS Transfer Family の公式 Terraform モジュールを使用して、エンドユーザーが Web インターフェース経由で Amazon S3 とファイルを送受信できる「Transfer Family web apps」をデプロイできるようになりました。 このモジュールを使用することで、AWS IAM Identity Center と Amazon S3 Access Grants を統合した安全な Web アプリケーションを、Infrastructure as Code (IaC) として一貫性のある方法でプロビジョニングできます。
何が嬉しいのか #
企業ブランドに合わせた安全なファイル転送ポータルを、Terraform を使って迅速かつ再現性のある形で構築できます。手動設定の手間を省き、IDプロバイダーとの連携やきめ細かなアクセス権限設定、CloudTrail による監査設定などを含むベストプラクティス構成を簡単に展開できます。
これまでとどう変わるのか #
- これまで: Transfer Family の Web アプリ機能を構築するには、個別のリソースを手動で設定するか、独自の Terraform コードを一から記述する必要がありました。
- これから: 提供される Terraform モジュールを利用するだけで、認証基盤や権限管理を含む Web アプリケーション全体をプログラムで一括デプロイできるようになります。
具体的なユースケース #
- パートナー企業や社内ユーザー向けに、S3 バケットへのファイルアップロード/ダウンロード用 Web ポータルを短期間で構築・提供する必要がある場合に最適です。
Instance Scheduler on AWS がスケーリング強化、信頼性向上、イベント駆動型自動化を追加 #
投稿日: 2026年01月21日
何ができるようになったのか #
AWS ソリューション実装の1つである Instance Scheduler on AWS がアップデートされ、以下の機能が追加されました。
- タグ付けイベントの追跡: スケジューリング操作の順序付けと分散を最適化し、スケーリング性能を向上。
- セルフサービス・トラブルシューティング: 情報リソースタグを通じて、管理者以外のエンジニアがスケジューリングの問題(開始されないなど)の原因を特定可能に。
- 容量不足時の自動リトライ: EC2 の起動時に容量不足(Insufficient Capacity Error)が発生した場合、自動的に代替のインスタンスタイプでの起動を試行するオプションを追加。
- 専用 EventBridge バスの自動作成: スケジューリング関連イベント専用のバスを作成し、統合を簡素化。
何が嬉しいのか #
大規模環境での信頼性と運用効率が向上します。特に、特定のAZでインスタンス容量が不足している場合に、自動的に別のサイズやファミリーで起動を試みる機能により、開発・テスト環境の可用性が高まります。また、中央管理者に問い合わせることなく、各チームがタグを見てなぜインスタンスが起動・停止しなかったのかを確認できるため、運用負荷が軽減されます。
これまでとどう変わるのか #
- これまで: スケジューリングが失敗した場合の調査はログ確認が必要で、容量不足エラーへの自動対応機能も標準では組み込まれていませんでした。
- これから: よりインテリジェントに操作が分散され、エラー時の自動回復機能や自己診断機能により、より堅牢なスケジュール管理が可能になります。
具体的なユースケース #
- 始業時間に数百台の開発サーバーを一斉に起動する際、一部のインスタンスタイプが枯渇していても、自動的に代替タイプで起動させることで、開発業務への支障を防ぎます。
SageMaker Unified Studio がクロスリージョンおよび IAM ロールベースのサブスクリプションをサポート #
投稿日: 2026年01月20日
何ができるようになったのか #
Amazon SageMaker Unified Studio において、異なる AWS リージョンにある AWS Glue や Amazon Redshift のテーブル/ビューをサブスクライブ(利用登録)できるようになりました。 また、SageMaker Unified Studio のプロジェクトを作成することなく、IAM ロールを使用してデータへのアクセス権を直接要求・取得できる「IAM ロールベースのサブスクリプション」もサポートされました。
何が嬉しいのか #
データのサイロ化を解消し、組織全体でのデータ活用が促進されます。データを物理的に複製(レプリケーション)することなく、必要なリージョンからリモートのデータ資産にアクセスできるため、ストレージコストと管理の手間を削減できます。 また、IAMロールベースのアクセスにより、既存のワークフローやツールとの統合が容易になります。
これまでとどう変わるのか #
- これまで: 別リージョンのデータを利用するには、手動でデータをコピーしたり、複雑な設定が必要でした。また、データアクセスには Unified Studio プロジェクトへの参加が必要な場合がありました。
- これから: リージョンを跨いでシームレスにデータにアクセスでき、プロジェクトという中間層を介さずに IAM ロールを通じて柔軟に権限管理が可能になります。
具体的なユースケース #
- 東京リージョンの分析チームが、バージニア北部リージョンにあるログデータ(Redshiftテーブル)を参照して、クロスリージョンで機械学習モデルのトレーニングデータを作成する場合などに有用です。