本日の主なトピック #
- Amazon Bedrock の拡張: GLM 5、MiniMax M2.5、NVIDIA Nemotron 3 Super といった最新のフロンティア級モデルが相次いでサポート。
- Graviton4 東京上陸: 最新世代プロセッサ搭載のネットワーク最適化インスタンス EC2 C8gn が東京リージョンで利用可能に。
- Lambda の AZ 認識: 関数内から実行中のアベイラビリティゾーンを特定できるメタデータエンドポイントが登場。
- Security Agent の進化: 侵入テスト結果の PDF レポート出力と、Service Quotas による上限管理に対応。
- EC2 Fleet のコスト最適化: 中断可能なキャパシティ予約をサポートし、組織内の余剰リソースを有効活用可能に。
¥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 で MiniMax M2.5 と GLM 5 モデルが利用可能に #
投稿日: 2026年03月18日
何ができるようになったのか #
Amazon Bedrock のモデル選択肢がさらに広がり、新たに GLM 5 と MiniMax M2.5 の 2 つのフロンティア級モデルがサポートされました。
- GLM 5: 複雑なシステムエンジニアリングや、長期的なエージェントタスクに最適化された汎用大規模言語モデルです。マルチステップの推論、数学、高度なコーディング、ツールを活用したワークフローに対応し、長いコンテキストをサポートします。
- MiniMax M2.5: 推論効率とタスク分解能力に優れたエージェントネイティブなモデルです。高い推論スループットと強化学習を組み合わせることで、実世界の時間・コスト制約下で、主要な商用モデルと同等以上の速度で複雑なワークフローを完了させることができます。
何が嬉しいのか #
開発者は、より高度な推論や自律的なエージェントタスクを必要とするアプリケーションにおいて、用途やコスト、パフォーマンスの要件に合わせて最適なモデルを選択できるようになります。特に、複数のツールを組み合わせる高度なエージェントや、複雑なロジックを必要とするエンジニアリング業務の自動化において、強力な選択肢となります。
これまでとどう変わるのか #
- これまで: Bedrock では主要な複数のモデルが提供されていましたが、エージェントタスクの効率化や高度なシステムエンジニアリングに特化した最新の GLM や MiniMax モデルは直接利用できませんでした。
- これから: Bedrock の統一された API を通じて、GLM 5 や MiniMax M2.5 を自社のアプリケーションに簡単に組み込むことが可能になり、最新の推論・エージェント機能をセキュアに利用できるようになります。
具体的なユースケース #
- 高度な自律型エージェント: マルチステップの推論が必要な顧客サポートや業務自動化エージェントの開発。
- システムエンジニアリングの自動化: GLM 5 の高度なコーディング能力を活かした、複雑なシステムの設計・実装支援。
- コスト・パフォーマンス重視の推論: MiniMax M2.5 を活用し、高いスループットを維持しながら複雑なタスクを効率的に実行。
NVIDIA Nemotron 3 Super が Amazon Bedrock で利用可能に #
投稿日: 2026年03月18日
何ができるようになったのか #
NVIDIA の最新モデルである Nemotron 3 Super が Amazon Bedrock で利用可能になりました。
Nemotron 3 Super は、複雑なマルチエージェント・アプリケーション向けに設計された、オープンなハイブリッド Mixture-of-Experts (MoE) モデルです。エージェント・ワークロードに特化しており、高速かつコスト効率の高い推論を実現します。これにより、AI エージェントは長いマルチステップのタスクにおいても、文脈を失うことなく正確に処理を継続できるようになります。
何が嬉しいのか #
このモデルは、モデルの重み、データセット、レシピが公開されているフルオープンなモデルであり、カスタマイズやセキュアなデプロイが容易です。Bedrock のマネージド API を通じて利用できるため、インフラの準備やモデルのホスティングを行う必要がなく、OpenAI API との互換性もあるため、既存のワークフローへの統合もスムーズに行えます。
これまでとどう変わるのか #
- これまで: マルチエージェント・ワークロードに最適化された最新のオープンな MoE モデルを Bedrock で直接利用することはできませんでした。
- これから: サーバーレスで、NVIDIA Nemotron 3 Super の高度な推論能力とカスタマイズ性を活かしたアプリケーションを、プロダクション規模で迅速に構築・デプロイできるようになります。
具体的なユースケース #
- マルチエージェント・ワークフロー: 複数のエージェントが連携して複雑なタスクをこなすシステムの構築.
- 長期タスクの自動化: 長時間の対話や、多数のステップを伴う業務プロセスの自動化.
- カスタマイズ重視のエンタープライズ AI: 公開された重みやレシピを活用し、特定のドメインに特化したモデルの調整と安全な運用.
Amazon EC2 C8gn インスタンスが東京リージョンを含む追加リージョンで利用可能に #
投稿日: 2026年03月19日
何ができるようになったのか #
最新世代の AWS Graviton4 プロセッサを搭載した、ネットワーク最適化インスタンス Amazon EC2 C8gn が、東京、ジャカルタ、ハイデラバード、サンパウロ、チューリッヒの各リージョンで新たに利用可能になりました。
C8gn インスタンスは、第 6 世代の AWS Nitro カードを採用しており、ネットワーク最適化インスタンスの中で最高となる最大 600 Gbps のネットワーク帯域幅を提供します。また、従来の Graviton3 ベースの C7gn インスタンスと比較して、最大 30% 向上したコンピューティングパフォーマンスを実現しています。
何が嬉しいのか #
非常に高いネットワーク帯域幅と強力なプロセッサ性能により、ネットワーク仮想アプライアンス、データ分析、CPU ベースの AI/ML 推論など、ネットワーク負荷の高いワークロードにおいて、パフォーマンスの向上とコストの最適化を同時に実現できます。
また、最大 48xlarge のインスタンスサイズ、384 GiB のメモリ、最大 60 Gbps の EBS 帯域幅をサポートしており、大規模なワークロードにも柔軟に対応可能です。さらに、一部のサイズでは Elastic Fabric Adapter (EFA) もサポートしており、密結合クラスタにおける低レイテンシ通信が可能です。
これまでとどう変わるのか #
- これまで: 東京リージョンなどでは、Graviton4 を搭載した最新のネットワーク最適化インスタンス C8gn を利用することができず、前世代のインスタンスに頼る必要がありました。
- これから: 日本国内のユーザーも、最新の Graviton4 による高い電力効率と圧倒的なネットワーク性能を、東京リージョンで直接享受できるようになります。
具体的なユースケース #
- ネットワーク仮想アプライアンス: ファイアウォールやルーターなどの高スループットが求められるネットワーク機能。
- 大規模データ分析: 大容量データの転送と高速な処理が必要なデータパイプライン。
- CPU ベースの AI 推論: Graviton4 の演算能力を活かした機械学習モデルの推論。
- HPC クラスタ: EFA を活用した密結合な計算ノード間通信。
Amazon EC2 Fleet で中断可能なキャパシティ予約がサポート #
投稿日: 2026年03月19日
何ができるようになったのか #
複数のインスタンスタイプやアベイラビリティゾーンをまたいでインスタンスを一括起動できる Amazon EC2 Fleet において、新たに「中断可能（interruptible）なキャパシティ予約」をサポートしました。
これにより、EC2 Fleet で使用する起動テンプレート（Launch Template）に、中断可能なキャパシティ予約の ID を指定できるようになります。未使用のオンデマンドキャパシティ予約を AWS Organizations 内で中断可能な予約として共有・有効化している場合、EC2 Fleet を通じてこれらを容易に消費し、インスタンスを起動することが可能です。
何が嬉しいのか #
組織全体でのキャパシティ予約の利用効率を高め、コストを最適化できます。未使用の予約を「中断可能」なリソースとして他のワークロードに開放することで、遊休リソースの無駄を減らし、組織全体での EC2 利用料を削減できます。また、EC2 Fleet の単一の API コールでこれらを管理できるため、運用の簡素化も図れます。
これまでとどう変わるのか #
- これまで: オンデマンドキャパシティ予約は、明示的に指定された特定のワークロードでのみ利用されるのが一般的でした。中断可能なキャパシティ予約を効率的に複数のインスタンスタイプにわたって利用するには、個別のリクエストや複雑な管理が必要でした。
- これから: EC2 Fleet の仕組みを使って、中断可能なキャパシティ予約を簡単に活用できるようになります。これにより、スポットインスタンスに近いコストメリットを、組織内の余剰リソースを使って享受できる機会が増えます。
具体的なユースケース #
- バッチ処理や開発環境: オンデマンドキャパシティ予約の空き時間を活用して、中断が許容される非クリティカルなジョブやテスト環境を低コストで実行。
- 組織内リソースの最大活用: AWS Organizations 内の別のアカウントで確保されているが一時的に使われていないキャパシティを、EC2 Fleet を介して有効活用。
Amazon RDS Custom for SQL Server で OS アップデートの管理が可能に #
投稿日: 2026年03月19日
何ができるようになったのか #
Amazon RDS Custom for SQL Server において、新たに OS（オペレーティングシステム）アップデートの確認と、適用スケジュールの設定が可能になりました。
これまで、RDS Custom では提供されたエンジンバージョン (RPEV) を通じて SQL Server がプリインストールされた AMI を利用していましたが、最新の OS アップデートが利用可能になった際に、API を通じてそれらを直接確認・管理できるようになります。
- アップデートの確認:
describe-pending-maintenance-actionsAPI を使用して、適用可能な保留中の OS アップデートを表示。 - 通知の受信:
RDS-EVENT-0230を購読することで、新しい OS アップデートが利用可能になった際にアラートを受信可能。 - 適用の実行:
apply-pending-maintenance-actionAPI を使用して、即時適用または次回のメンテナンスウィンドウでの適用をスケジュール設定。
何が嬉しいのか #
カスタマイズ性が高い RDS Custom を利用しつつ、セキュリティや安定性のために重要な OS の最新化を、マネージドな体験に近い形で効率的に追跡・管理できるようになります。これまで手動で行う必要があったアップデート情報の収集や適用タイミングの管理が自動化・効率化されます。
これまでとどう変わるのか #
- これまで: RDS Custom は OS へのアクセスが可能な分、OS レベルのアップデート状況を把握したり、適切なタイミングで適用をスケジュールしたりする作業は、標準の RDS と比較してユーザー側の管理負担が大きくなっていました。
- これから: 標準の RDS と同様に、保留中の maintenance-actions として OS アップデートを管理できるようになり、運用の自動化が進みます。
具体的なユースケース #
- セキュリティコンプライアンスの維持: 新しい OS パッチがリリースされた際に迅速に検知し、指定したメンテナンス時間内に確実に適用する運用の自動化。
- マルチアカウントでの一括管理: API を活用して、組織内の複数の RDS Custom インスタンスに対する OS アップデートの適用状況を一元監視。
Amazon SageMaker Unified Studio でカスタムメタデータによる検索が可能に #
投稿日: 2026年03月18日
何ができるようになったのか #
Amazon SageMaker Unified Studio のカタログ検索において、新たにカスタムメタデータを使用したフィルタリングが可能になりました。
これにより、キーワード検索や意味検索（セマンティック検索）に加え、ビジネスリージョン、データ分類、試験 ID など、組織独自の属性を使用してカタログ内の資産を絞り込むことができます。
- 多様なフィルタ形式: 文字列フィールドでの「包含（contains）」検索、数値フィールドでの「一致（equals）」「より大きい（greater than）」「より小さい（less than）」検索をサポート。
- 複合フィルタ: 複数のフィルタを組み合わせて、より詳細な絞り込みが可能。
- ブラウザでの永続化: 選択したフィルタはブラウザのセッション間で保持されます。
- API サポート: UI だけでなく、
SearchListingsAPI を介したプログラマティックな検索も可能です。
何が嬉しいのか #
プロジェクト内のデータ資産やモデルが増大しても、自分たちで定義したメタデータを使って、必要なアセットを迅速に見つけ出せるようになります。例えば、「特定の研究 ID に関連するデータセット」や「特定の地域で収集されたモデル」などを瞬時に特定でき、開発のスピードアップに繋がります。
これまでとどう変わるのか #
- これまで: 主にキーワードやセマンティック検索に頼っており、特定の業務上の属性に基づく厳密な絞り込みが困難な場合がありました。
- これから: 組織独自のメタデータを活用した柔軟で強力な検索が可能になり、カタログの利便性が大幅に向上します。
具体的なユースケース #
- データガバナンスの強化: 「機密（Confidential）」とマークされたデータセットのみをフィルタリングして、アクセス範囲を確認。
- 研究・実験の整理: 試験 ID やサンプルタイプを指定して、特定のプロジェクトに関連する全アセットを表示.
- 地域ごとのデータ管理: ビジネスリージョンでフィルタリングし、各拠点のデータ活用状況を把握.
シドニーに新しい AWS Direct Connect ロケーションが開設 #
投稿日: 2026年03月19日
何ができるようになったのか #
オーストラリア、シドニーの Equinix SY5 において、新たに AWS Direct Connect ロケーションが開設されました。
この新しいロケーションから、中国を除くすべてのパブリック AWS リージョン、AWS GovCloud リージョン、および AWS Local Zones へのプライベートな直接ネットワーク接続が可能になります。シドニーでは 4 番目、オーストラリア国内では 10 番目の Direct Connect サイトとなります。
- 接続オプション: 10 Gbps および 100 Gbps の専用接続.
- セキュリティ: MACsec 暗号化のサポート.
何が嬉しいのか #
シドニー周辺のデータセンターやオフィスから AWS へのプライベート接続の選択肢が増え、冗長性の確保や高帯域な通信環境の構築が容易になります。Direct Connect を利用することで、パブリックインターネット経由の通信よりも一貫性のあるネットワーク体験が可能となり、大容量データの転送や低レイテンシが求められるアプリケーションの運用に最適です。
これまでとどう変わるのか #
- これまで: シドニーには既存のロケーションがありましたが、Equinix SY5 を拠点とするユーザーにとっては、接続構成の柔軟性や物理的な距離の面で選択肢がさらに広がります。
- これから: Equinix SY5 内または近隣に設備を持つ企業は、より短い経路で、最大 100 Gbps の高速かつセキュアな専用線接続を AWS と確立できるようになります。
具体的なユースケース #
- ハイブリッドクラウドの構築: オンプレミスのデータセンターと AWS をセキュアかつ広帯域な専用線で接続.
- リアルタイムデータの転送: 一貫した低レイテンシが必要な金融取引やメディアストリーミングなどのワークロード.
- ディザスタリカバリ: シドニー内の複数の Direct Connect ロケーションを組み合わせて、高可用な冗長構成を実現.
AWS Security Agent が Service Quotas に対応 #
投稿日: 2026年03月13日
何ができるようになったのか #
AWS Security Agent が新たに AWS Service Quotas をサポートしました。これにより、ユーザーはサービスの上限（クォータ）を中央集権的に管理できるようになります。
具体的には、以下のことが可能になります。
- クォータの確認: 現在適用されている上限値と、その使用状況を Service Quotas コンソールから一元的に把握。
- 緩和申請の簡素化: コンソールから直接クォータの引き上げをリクエストでき、適格なリクエストは自動的に承認。
- 制限項目の管理: 侵入テスト（ペンテスト）のアクション実行時間や、同時に実行可能なペンテストジョブの数などの制限を管理。
何が嬉しいのか #
開発チームやセキュリティチームは、サービスの制約（クォータ）に予期せず到達することを防ぎ、ペンテストなどのセキュリティ活動をスムーズにスケールさせることができます。制限に近づいていることを事前に把握し、必要に応じて自動承認を含む迅速なクォータ緩和を受けることで、運用のダウンタイムを最小限に抑えられます。
これまでとどう変わるのか #
- これまで: AWS Security Agent の特定の制限状況を確認したり、引き上げを依頼したりするためのプロセスが他の AWS サービスと統一されていない場合がありました。
- これから: 他の主要な AWS サービスと同様に Service Quotas コンソールで管理できるため、インフラ全体のクォータ管理がより一貫性のあるものになります。
具体的なユースケース #
- 大規模なペンテストの実施: 多数のジョブを並行して走らせる際に、事前に同時実行数のクォータを確認・引き上げ。
- 定期的なセキュリティ監査: 年間のアクション実行時間のクォータを監視し、不足しそうな場合に計画的に緩和申請。
AWS Security Agent で侵入テストレポートのダウンロードが可能に #
投稿日: 2026年03月17日
何ができるようになったのか #
AWS Security Agent において、侵入テスト（ペンテスト）レポートを PDF 形式で作成・ダウンロードできるようになりました。
このレポートには、以下の詳細な情報が含まれます。
- エグゼクティブサマリー: セキュリティ体制と検出結果のハイレベルな概要。
- テスト範囲 (Scope): 何をテストしたか。
- テスト手法: 使用されたアプローチや技術、タスクの詳細。
- 検出結果の詳細: 脆弱性情報やリスク評価を含む包括的な内容。
さらに、レポートはリスクレベル、確信度（Confidence）、検出ステータス、リスクタイプ、タスクステータスなどのフィルタを使用してカスタマイズ可能です。
何が嬉しいのか #
数週間かかっていた侵入テストを数時間に短縮しつつ、その結果をプロフェッショナルな報告書として即座に共有できるようになります。カスタマイズ可能なフィルタにより、関係者（経営層、開発チーム、監査担当など）に応じて必要な情報に絞ったレポートを作成でき、社内での情報共有やリスク対策の意思決定を迅速化できます。
これまでとどう変わるのか #
- これまで: オンデマンドの侵入テスト機能はありましたが、その結果をチーム間で共有したりレビューしたりするための標準化された、かつ詳細なドキュメントを即座に生成する手段が限定的でした。
- これから: 数クリックでカスタマイズされた詳細な PDF レポートを取得でき、コンプライアンス対応やセキュリティ改善のアクションへスムーズに移行できます。
具体的なユースケース #
- 経営層への報告: エグゼクティブサマリーを活用し、現在のセキュリティ体制の全体像を報告。
- 開発チームへの指示: 高リスク（High Risk）の検出結果のみをフィルタリングし、優先的に修正すべき脆弱性リストを共有。
- 監査対応: テスト手法や範囲、詳細な検出結果を含むレポートを証跡として活用。
AWS が NIXL と EFA の連携をサポートし LLM 推論を高速化 #
投稿日: 2026年03月19日
何ができるようになったのか #
Amazon EC2 において、NVIDIA Inference Xfer Library (NIXL) と Elastic Fabric Adapter (EFA) の連携がサポートされました。これにより、分離型（disaggregated）の大規模言語モデル（LLM）推論が大幅に高速化されます。
具体的には、以下の 3 つの重要な改善が実現されます。
- KV キャッシュのスループット向上: プリフィル（Prefill）ノードとデコード（Decode）ノード間での KV キャッシュ転送を高速化。
- トークン間レイテンシの低減: 推論時の応答速度（インタートークンレイテンシ）を改善。
- メモリ利用の最適化: さまざまなストレージレイヤー間での効率的な KV キャッシュ移動を可能にし、メモリ使用効率を向上。
何が嬉しいのか #
LLM の推論をスケールさせる際、計算リソースを効率的に分散させる「分離型推論」において、ボトルネックとなりやすい KV キャッシュの転送が EFA を通じて最適化されます。これにより、大規模な LLM サービスをより高いパフォーマンスと低いコストで運用できるようになります。NVIDIA Dynamo、SGLang、vLLM などの主要フレームワークともネイティブに統合されています。
これまでとどう変わるのか #
- これまで: 分離型推論アーキテクチャでは、ノード間でのデータ（特に KV キャッシュ）移動がレイテンシやスループットの課題となっていました。
- これから: NIXL と EFA を組み合わせることで、ノード間通信を極限まで効率化でき、ユーザーは好みの EC2 インスタンスとフレームワークを選択しながら、最高水準の推論パフォーマンスを享受できます。
具体的なユースケース #
- 大規模 LLM の商用サービス化: vLLM などのフレームワークを使用し、高負荷環境下で低レイテンシ・高スループットな推論を提供。
- 分離型推論アーキテクチャの構築: プリフィル処理とデコード処理を別々のノード群で行い、リソース効率を最大化するシステム設計。
AWS Lambda がアベイラビリティゾーン (AZ) メタデータをサポート #
投稿日: 2026年03月19日
何ができるようになったのか #
AWS Lambda において、関数の実行環境からアベイラビリティゾーン (AZ) のメタデータを取得できるようになりました。
新しいメタデータエンドポイントを通じて、関数が現在どこの AZ（例: use1-az1）で実行されているかを特定できます。
- AZ 認識ルーティング: 後続のサービス（Amazon ElastiCache や Amazon RDS など）へのアクセス時に、同じ AZ 内のエンドポイントを優先的に選択し、クロス AZ レイテンシを削減できます。
- 障害耐性の強化: 特定の AZ における障害注入テスト（Fault Injection Testing）など、AZ を意識したレジリエンスパターンの実装が可能になります。
- 広範なサポート: すべてのランタイム（カスタムランタイム、コンテナイメージ含む）で利用可能。VPC 設定の有無にかかわらず、また SnapStart やプロビジョニングされた同時実行ともシームレスに動作します。
何が嬉しいのか #
これまで Lambda 関数がどの AZ で動いているかを確実に知る方法はありませんでした。このアップデートにより、関数自ら実行場所を把握できるようになるため、地理的に近いリソースへのアクセスを最適化し、パフォーマンス向上と通信コストの削減を図ることができます。また、カスタムな解決策を自前で構築・維持する必要がなくなります。
これまでとどう変わるのか #
- これまで: Lambda は高可用性を実現するために複数の AZ で自動的に実行されますが、開発者が実行中の AZ をプログラムから特定する標準的な手段はありませんでした。
- これから: HTTP リクエスト一つで AZ ID を取得でき、Powertools for AWS Lambda などのユーティリティを活用して簡単に AZ 認識ロジックを組み込めます。
具体的なユースケース #
- キャッシュアクセスの最適化: 同じ AZ に配置された ElastiCache ノードに接続し、データ取得のレイテンシを最小化。
- カオスエンジニアリング: 特定の AZ でのみ障害をシミュレートするテストの実施。
- トラフィック管理: AZ ごとのリソース使用状況やエラー率の分析。