本日の主なトピック #
- AWS MCP Server (プレビュー) で Deployment Agent SOPs: AIエージェントが標準作業手順書 (SOPs) に従って、インフラ構築からCI/CDパイプライン作成、デプロイまでを自動実行できるようになりました。
- Amazon Bedrock: Responses API でサーバーサイドカスタムツールの利用が可能になり、クライアントを経由せずに直接ツールを呼び出してマルチステップタスクを実行できます。
- Amazon GameLift Servers: インスタンス数をゼロにするオートスケーリングをサポート。プレイヤーがいない時間帯のインフラコストを劇的に削減できます。
- Amazon EventBridge: イベントペイロードサイズの上限が 256 KB から 1 MB に拡張され、LLMアプリケーションなどでよりリッチなデータを扱いやすくなりました。
- Amazon DynamoDB Global Tables (MRSC): AWS Fault Injection Service (FIS) をサポートし、リージョン障害時のレプリケーション遅延などをシミュレートした耐障害性テストが可能になりました。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon Bedrock が Responses API を使用したサーバーサイドカスタムツールをサポート #
投稿日: 2026年01月29日
何ができるようになったのか #
Amazon Bedrock は、Responses API において OpenAI API 互換のエンドポイントを使用したサーバーサイドツールの利用をサポートしました。 これにより、Amazon Bedrock はクライアントを経由せずに直接ツールを呼び出すことができるようになり、AIアプリケーションは、AWSアカウントの組織的、ガバナンス、コンプライアンス、セキュリティの境界内で、Web検索、コード実行、データベース更新などのリアルタイムかつマルチステップのアクションを実行可能になります。 カスタムLambda関数を提供して独自のツールを実行するか、AWSが提供するツール（notesやtasksなど）を使用することができます。
何が嬉しいのか #
クライアントサイドでのツール実行制御が不要になり、よりセキュアかつ効率的にエージェント的な動作（マルチステップのアクション）を実装できます。OpenAI API互換のエンドポイントを利用できるため、既存の資産や知識を活用しやすい利点もあります。
これまでとどう変わるのか #
- これまで: Bedrock は Converse API、Chat Completions API、Responses API で「クライアントサイド」のツール利用をサポートしていました。ツール実行の制御や結果の受け渡しはクライアント側で行う必要がありました。
- これから: 「サーバーサイド」でツール利用が可能になり、Bedrock が直接ツールを呼び出して結果を取得できるようになります。
具体的なユースケース #
- ユーザーの質問に基づいてデータベースを検索し、その結果を使って回答を生成するチャットボット。
- 自然言語の指示に基づいてコードを実行し、計算結果を返すエージェント。
Amazon Cognito がインバウンドフェデレーション Lambda トリガーを導入 #
投稿日: 2026年01月29日
何ができるようになったのか #
Amazon Cognito は、認証プロセス中にフェデレーションユーザーの属性を変換およびカスタマイズできる「インバウンドフェデレーション Lambda トリガー」を導入しました。 これにより、外部の SAML および OIDC プロバイダーからの応答がユーザープールに保存される前に、プログラムによる完全な制御（属性の変更、追加、上書き、抑制）が可能になります。
何が嬉しいのか #
IDプロバイダー側の設定を変更することなく、Cognito側で柔軟にデータ整形やフィルタリングが行えるようになります。特に、Cognitoの属性制限（文字数など）に引っかかるようなデータを事前に加工してエラーを回避できる点が大きなメリットです。
これまでとどう変わるのか #
- これまで: フェデレーション認証フローにおいて、属性サイズ制限（Cognitoの属性あたり2,048文字制限など）や、外部IDプロバイダーからの不要な属性の取り込みにより、認証フローがブロックされるなどの課題がありました。
- これから: Lambdaトリガーを使用して、ユーザー作成や更新の前に属性を検証・加工できるため、上記のような制限を回避し、必要なデータのみを適切な形式で保存できます。
具体的なユースケース #
- 外部IDプロバイダーから送られてくる大きなグループ属性（2,048文字超）を、Cognitoに保存する前にフィルタリングしたり短縮したりする。
- 複数のIDプロバイダー間で異なる属性名を、Cognitoの標準属性名にマッピングする。
Amazon DynamoDB Global Tables (MRSC) が AWS FIS による耐障害性テストをサポート #
投稿日: 2026年01月28日
何ができるようになったのか #
マルチリージョン強整合性 (MRSC) を備えた Amazon DynamoDB Global Tables が、AWS Fault Injection Service (FIS) をサポートしました。 これにより、新しいFISアクションを使用して、リージョン間レプリケーションの一時停止などのリアルな障害シナリオをシミュレートし、アプリケーションがどのように応答するかを観察・検証できるようになります。
何が嬉しいのか #
これまでシミュレーションが難しかった「マルチリージョン環境でのレプリケーション遅延や停止」といった障害状況を、管理された安全な方法で意図的に発生させることができます。これにより、アプリケーションの回復力（レジリエンス）メカニズムが正しく機能するかを確認し、監視や復旧プロセスを調整して可用性を向上させることが可能になります。
これまでとどう変わるのか #
- これまで: MRSC Global Tables に対する特定の障害シナリオ（特にレプリケーション関連）をFISで直接テストする機能が提供されていなかった可能性があります。
- これから: FISのネイティブアクションとしてMRSC Global Tablesがサポートされ、リージョン障害時の挙動などを容易にテストできるようになります。
具体的なユースケース #
- リージョン間のレプリケーションが一時的に停止した際に、アプリケーションが別のリージョンにフェイルオーバーするか、あるいはエラーを適切に処理できるかをテストする。
Amazon EKS と EKS Distro が Kubernetes バージョン 1.35 をサポート #
投稿日: 2026年01月28日
何ができるようになったのか #
Amazon Elastic Kubernetes Service (EKS) および Amazon EKS Distro で、Kubernetes バージョン 1.35 が利用可能になりました。 EKSコンソール、eksctl、またはIaCツールを使用して、バージョン1.35の新しいクラスターを作成したり、既存のクラスターをアップグレードしたりできます。
何が嬉しいのか #
Kubernetes 1.35 には以下のような重要な機能改善が含まれており、運用効率やパフォーマンスが向上します。
- In-Place Pod Resource Updates: Podを再起動することなくCPUとメモリのリソース割り当てを調整できます。
- PreferSameNode Traffic Distribution: レイテンシを削減するため、リモートノードにルーティングする前にローカルエンドポイントを優先的に使用します。
- Node Topology Labels via Downward API: APIサーバーにクエリを投げなくても、Podがリージョンやゾーン情報にアクセスできるようになります。
- Image Volumes: AIモデルなどのデータアーティファクトを、OCIコンテナイメージを使用して配信できます。
これまでとどう変わるのか #
- これまで: リソース変更のためにPodの再作成が必要だったり、トポロジー情報の取得にAPIサーバーへの負荷がかかる場合がありました。
- これから: Kubernetes 1.35の新機能により、よりスムーズなリソース管理や効率的なトラフィックルーティングが可能になります。
具体的なユースケース #
- AI/MLワークロードなどで、実行中にリソース要件が変わるアプリケーションにおいて、Podを停止せずにリソースを動的にスケーリングさせる。
- 大規模なクラスターにおいて、APIサーバーへの負荷を抑えつつ、Podが自身の配置されているゾーン情報を取得してロジックに活用する。
Amazon EventBridge のイベントペイロードサイズが 1 MB に増加 #
投稿日: 2026年01月29日
何ができるようになったのか #
Amazon EventBridge のイベントペイロードサイズの上限が、従来の 256 KB から 1 MB に引き上げられました。 これにより、開発者はデータを分割、圧縮、または外部ストレージに退避させることなく、よりリッチで複雑なデータを含むイベントを取り込むことができます。
何が嬉しいのか #
大規模言語モデル (LLM) のプロンプト、詳細なテレメトリ信号、機械学習出力の複雑なJSON構造など、コンテキストを豊富に含むデータを扱うイベント駆動型アプリケーションにおいて、アーキテクチャを簡素化できます。
これまでとどう変わるのか #
- これまで: ペイロードサイズが 256 KB に制限されていたため、制限を超えるデータについては、データを分割して複数のイベントで送信したり、S3などの外部ストレージにデータを置いてその参照（URL）のみをイベントに含める（Claim Checkパターン）などの工夫が必要でした。
- これから: 最大 1 MB までのデータを単一のイベントに含めることができるため、複雑なデータ処理ロジックや外部ストレージへの依存を減らし、開発を効率化できます。
具体的なユースケース #
- 生成AIアプリケーションにおいて、長いコンテキストやプロンプトを含むリクエストをEventBridge経由で非同期に処理する。
- IoTデバイスやシステム監視において、詳細なログやメトリクスデータを含んだイベントを集約して処理する。
Amazon GameLift Servers がインスタンス数ゼロへのオートスケーリングをサポート #
投稿日: 2026年01月29日
何ができるようになったのか #
Amazon GameLift Servers で、インスタンス数を自動的にゼロにスケールダウンし、必要に応じてゼロからスケールアップすることが可能になりました。
何が嬉しいのか #
ゲームのアクティビティがない（プレイヤーがいない）期間にインスタンスを完全に停止できるため、不要なインフラコストを排除できます。ゲームセッションのリクエストがあれば自動的に起動するため、応答性を維持しつつコスト最適化を図ることができます。
これまでとどう変わるのか #
- これまで: オートスケーリングを有効に保つためには、アクティビティが少ない、あるいは全くない期間であっても、最低でも1つのインスタンスを稼働させ続ける必要がありました。
- これから: トラフィックがない場合はインスタンス数を0にできるため、深夜帯やメンテナンス時などのコストを劇的に削減できます。特に、ピークとオフピークの差が激しいゲームや、特定の時間帯のみアクティブなリージョナルなゲームで効果を発揮します。
具体的なユースケース #
- 開発中のゲームや、テスト環境のサーバーコスト削減。
- 深夜帯にプレイヤーが極端に少なくなる地域限定のマルチプレイヤーゲーム。
- イベント期間のみ稼働するようなゲームモードの運用。
Amazon Keyspaces がテーブルのプリウォーミング (WarmThroughput) を導入 #
投稿日: 2026年01月29日
何ができるようになったのか #
Amazon Keyspaces (for Apache Cassandra) で、新しいテーブルおよび既存のテーブルに対して「プリウォーミング (事前暖機)」を行うことが可能になりました。 これにより、テーブルのキャパシティモード（プロビジョンドまたはオンデマンド）に関わらず、将来のトラフィック需要に合わせて事前にキャパシティを確保できます。
何が嬉しいのか #
Amazon Keyspaces は自動スケーリングを備えていますが、アプリケーションのローンチ、マーケティングキャンペーン、季節イベントなどによる予測可能な急激なトラフィックスパイクに対して、事前にテーブルを準備できるようになります。これにより、スケーリングの遅延（スロットリング）やエラー率の増加を防ぎ、ユーザー体験を損なうことなく大量のリクエストを処理できます。
これまでとどう変わるのか #
- これまで: 急激な負荷変動が発生した場合、自動スケーリングが追いつくまで一時的にパフォーマンスへの影響が出たり、エラー率が上がったりする可能性がありました。
- これから: テーブル作成時や更新時に予想されるピークスループットを指定することで、トラフィック急増前にテーブルを即座にスケールアップ状態にでき、安定したパフォーマンスを提供できます。
具体的なユースケース #
- 大規模なセールイベント開始時のアクセス集中に備える。
- 新規ゲームタイトルのローンチ直後のログインラッシュに対応する。
Amazon MSK Replicator がアジアパシフィック (ニュージーランド) で利用可能に #
投稿日: 2026年01月28日
何ができるようになったのか #
Amazon Managed Streaming for Apache Kafka (Amazon MSK) の機能である Amazon MSK Replicator が、アジアパシフィック (ニュージーランド) リージョンで利用可能になりました。
何が嬉しいのか #
MSK Replicator を使用すると、数クリックで、異なるリージョンまたは同一リージョンの MSK クラスター間でデータを確実に複製できます。これにより、リージョン間の耐障害性を持つストリーミングアプリケーションを簡単に構築でき、可用性とビジネス継続性を向上させることができます。 カスタムコードの記述やインフラ管理、クロスリージョンネットワーク設定は不要で、トピック設定やACLなどのメタデータも含めて自動的にスケーリングしながら複製を行います。
これまでとどう変わるのか #
- これまで: ニュージーランドリージョンのMSKクラスターでReplicator機能を使用することはできませんでした。
- これから: ニュージーランドリージョンを含む、合計36のAWSリージョンでMSK Replicatorを利用したデータ複製が可能になります。
具体的なユースケース #
- ニュージーランドリージョンのデータを別のリージョンに複製してディザスタリカバリ (DR) 体制を構築する。
- データのローカリティ要件を満たすために、特定のリージョン内でデータを複製する。
AWS MCP Server で Deployment Agent SOPs がプレビュー公開 #
投稿日: 2026年01月29日
何ができるようになったのか #
AWS Model Context Protocol (MCP) Server において、新たに「Deployment Agent SOPs (標準操作手順)」がプレビュー公開されました。 これは、AIエージェント（Claude Desktopなど）に対して、自然言語で指示するだけで、Webアプリケーションのデプロイ作業を完遂させる機能です。 Next.js, React, Vue.js, Angular といった主要なフレームワークをサポートしており、プロジェクト構成の分析から、CDKによるインフラコード生成、デプロイ、そしてCI/CDパイプラインの構築までを、AIがSOP（手順書）に従って自動で実行します。
何が嬉しいのか #
AIへの指示が「一言」で完結します。従来のように「S3バケットを作って、次にCloudFrontを…」と細かく指示する必要がなく、「このアプリをデプロイして」と頼むだけで済みます。 また、AIは確立されたSOP（標準手順書）に従って作業するため、手順の抜け漏れや誤った設定（ハルシネーション）を防ぎ、AWSのベストプラクティスに沿ったセキュアな構成を確実に構築できます。 さらに、デプロイ手順や構成に関するドキュメントも自動でリポジトリに作成されるため、後のメンテナンスも容易になります。
これまでとどう変わるのか #
- これまで: AWS MCP Server v1.0 では、AIに「AWS API」という「道具」だけを渡している状態でした。AIは道具の使い方は知っていても、複雑なデプロイ手順（レシピ）までは持っていないため、ユーザーが詳細に指示出しをする必要があり、失敗もしやすい状態でした。
- これから: AIに「道具」に加えて「SOP（プロのレシピ）」を渡すことができるようになりました。これにより、AIは迷うことなく手順書通りに作業を進められるため、誰が依頼しても高品質なデプロイ結果が得られるようになります。
具体的なユースケース #
- プロトタイプの爆速公開: 新規開発したWebアプリを、インフラ構築の手間をかけずに数分でAWS上に公開し、URLを発行する。
- 標準化された環境構築: チーム内でインフラ構築の手順を統一し、属人化を防ぐ（AIに任せることで均一化）。
Amazon EC2 R7gd インスタンスが欧州 (パリ) リージョンで利用可能に #
投稿日: 2026年01月28日
何ができるようになったのか #
Amazon EC2 R7gd インスタンスが、欧州 (パリ) リージョンで利用可能になりました。 これらのインスタンスは、最大 3.8 TB のローカル NVMe ベース SSD ブロックレベルストレージを備えています。
何が嬉しいのか #
R7gd インスタンスは AWS Graviton3 プロセッサと DDR5 メモリを搭載しており、コストパフォーマンスに優れています。 オープンソースデータベース、インメモリキャッシュ、リアルタイムビッグデータ分析などのメモリ集約型ワークロードや、高速かつ低遅延なローカルストレージ（スクラッチスペース、一時ファイル、キャッシュなど）を必要とするアプリケーションに最適です。
これまでとどう変わるのか #
- これまで: パリリージョンでは R7gd インスタンスタイプを選択できませんでした。
- これから: パリリージョンでも、Graviton3 とローカル NVMe SSD を組み合わせた R7gd インスタンスを利用して、メモリ集約型かつストレージ性能を求めるワークロードを最適化できます。
具体的なユースケース #
- Redis や Memcached などのインメモリキャッシュ。
- PostgreSQL や MySQL などのオープンソースデータベースで、高速なローカルストレージを一時領域として使用する場合。
- リアルタイムのビッグデータ処理。