本日の主なトピック #
- Amazon Bedrock の大幅な機能拡充: OpenAI API 互換エンドポイント (Project Mantle) や、シドニーリージョンでの最新オープンウェイトモデル対応、Claude 4.5 Sonnet のクォータ引き上げなど、生成 AI 利用の柔軟性が向上。
- Amazon CloudWatch アラームミュートルールの導入: メンテナンス時などに通知を一時停止できる機能が追加され、監視の可視性を維持したままアラート疲れを解消。
- セキュリティとガバナンスの強化: AWS Organizations のリソース管理ポリシー (RCP) が DynamoDB をサポートし、組織レベルでのデータ境界構築が可能に。また、S3 Access Grants が台北リージョンで利用可能。
- Amazon Connect の運用効率化: インアプリ通知機能や分析ダッシュボードの詳細なアクセス制御、AI によるタスク概要とネクストアクション提案などが追加。
- データベースの利便性向上: Aurora DSQL の標準 SQL サポート強化、RDS/Aurora のスナップショット復元時におけるバックアップ設定の直接変更、SQL Server 2022 最新 CU サポートなど。
¥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 Aurora DSQL が ID 列とシーケンスオブジェクトのサポートを追加 #
投稿日: 2026年02月13日
何ができるようになったのか #
Amazon Aurora DSQL において、ID 列 (identity columns) とシーケンスオブジェクト (sequence objects) がサポートされました。これにより、PostgreSQL でおなじみの SQL パターンを使用して、自動インクリメントされる整数ベースの ID をデータベース側で直接生成できるようになります。
何が嬉しいのか #
既存の PostgreSQL アプリケーションからの移行が容易になります。また、アプリケーションコードやミドルウェアにカスタムの ID 生成ロジックを実装することなく、注文番号やアカウント ID などの読みやすい整数識別子をデータベース管理で利用できるようになります。
これまでとどう変わるのか #
- これまで: Aurora DSQL で自動インクリメントされる ID を使用する場合、アプリケーション側での実装や代替手段が必要でした。
- これから:
GENERATED AS IDENTITYなどの標準的な SQL 構文を使用して、データベースが管理する効率的な整数 ID を利用できます。
具体的なユースケース #
- 既存の PostgreSQL アプリの移行: シーケンスや SERIAL 型を使用している既存のデータベースを Aurora DSQL へスムーズに移行。
- 管理用 ID の生成: 注文管理システムや顧客管理システムにおいて、一意で連続性のある整数 ID を自動発行。
Amazon Bedrock が OpenAI API 互換エンドポイントでの AWS PrivateLink サポートを拡大 #
投稿日: 2026年02月12日
何ができるようになったのか #
Amazon Bedrock において、bedrock-mantle エンドポイントでも AWS PrivateLink が利用可能になりました。これにより、インターネットを経由することなく、OpenAI API 互換のインターフェースを使用して Bedrock 上のモデルにセキュアにアクセスできるようになります。
何が嬉しいのか #
OpenAI API の仕様に合わせて作成されたアプリケーションを Amazon Bedrock に移行する際、セキュリティ要件（閉域網接続）を満たしたまま利用可能になります。Project Mantle によって提供される高性能で信頼性の高いサーバーレス推論を、プライベート接続環境で享受できます。
これまでとどう変わるのか #
- これまで: Amazon Bedrock では
bedrock-runtimeエンドポイントでの AWS PrivateLink はサポートされていましたが、OpenAI API 互換エンドポイント（bedrock-mantle）へのプライベートアクセスは制限されていました。 - これから:
bedrock-mantleを含む両方のエンドポイントで AWS PrivateLink が利用可能になり、より幅広いアプリケーション構成でセキュアな接続が選択できます。
具体的なユースケース #
- エンタープライズ向けの生成 AI アプリ: 機密データを扱う社内システムから、閉域網経由で OpenAI API 互換コードを使用して Bedrock のモデルを呼び出す。
- マルチクラウド・ハイブリッド環境: オンプレミスや他社クラウドから AWS Direct Connect 経由で、セキュアに Bedrock の OpenAI 互換エンドポイントを利用する。
Amazon Bedrock が AWS GovCloud (US) での Claude 4.5 Sonnet のデフォルトクォータを引き上げ #
投稿日: 2026年02月12日
何ができるようになったのか #
AWS GovCloud (US-West および US-East) リージョンにおいて、Anthropic 社の最新モデルである Claude 4.5 Sonnet のデフォルトクォータが大幅に引き上げられました。具体的には、毎分 5,000,000 トークン、毎分 1,000 リクエストに設定され、これは商用リージョンと同等の水準となります。
何が嬉しいのか #
規制の厳しい環境（政府機関や公共セクターなど）を利用する顧客が、最新の高性能 AI モデルを使用して、より大規模で複雑なワークロードを効率的に拡張できるようになります。以前のクォータと比較して約 25 倍の引き上げとなります。
これまでとどう変わるのか #
- これまで: AWS GovCloud 環境では、最新モデルのクォータが商用リージョンに比べて低く設定されており、大規模なスケールアップには制限がありました。
- これから: 商用リージョンと同じ高水準のクォータが適用されるため、制限を気にせず大規模な推論処理やエージェント開発が可能になります。
具体的なユースケース #
- 大規模なドキュメント解析: 政府機関における膨大な公文書の自動要約や分類処理。
- 高度なエージェント開発: 複雑な推論を必要とする公共サービス向けの対話型 AI エージェントの構築。
Amazon Bedrock がシドニーリージョンで最新のオープンウェイトモデルのサポートを開始 #
投稿日: 2026年02月12日
何ができるようになったのか #
アジアパシフィック（シドニー）リージョンの Amazon Bedrock において、bedrock-mantle エンドポイントを介した最新のオープンウェイトモデルのサポートが開始されました。サポート対象には、DeepSeek、Google、MiniMax、Mistral、Moonshot AI、Nvidia、および OpenAI のモデルが含まれます。
何が嬉しいのか #
オーストラリアおよび周辺地域の開発者は、低遅延かつ高パフォーマンスな環境で、多様な最新 AI モデルを Amazon Bedrock 上で利用できるようになります。Project Mantle の高度な推論エンジンにより、OpenAI API 互換のインターフェースでこれらのモデルを容易に統合可能です。
これまでとどう変わるのか #
- これまで: シドニーリージョンで利用可能なオープンウェイトモデルには制限がありました。また、新しいモデルの導入には時間がかかる場合がありました。
- これから: Project Mantle の導入により、最新モデルの迅速な提供が可能になり、OpenAI API 互換の仕様で多様なモデルを即座に試用・本番利用できます。
具体的なユースケース #
- リージョン内での低遅延推論: データ主権を考慮しつつ、オーストラリア国内のリージョンで最新の Mistral や DeepSeek モデルを使用した AI アプリを構築。
- マルチモデル戦略: 同一の OpenAI 互換 API を通じて、ユースケースに応じて Google や Nvidia のモデルを使い分ける。
Amazon CloudWatch がアラームミュートルールをサポート、アラート疲れを解消 #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon CloudWatch において「アラームミュートルール (Alarm Mute Rules)」が導入されました。これにより、計画的なデプロイ、メンテナンス、または業務時間外などの特定の期間に、アラーム通知を一時的に停止（ミュート）できるようになります。1つのルールで最大100個のアラームを対象にでき、1回限りまたは繰り返し設定が可能です。
何が嬉しいのか #
監視の可視性は維持したまま、不要な通知による「アラート疲れ (alert fatigue)」を防ぐことができます。メンテナンス中に発生する予測可能なアラート通知を抑制しつつ、ミュート期間が終了した際にまだ問題が継続していれば自動的に通知が行われるため、重大な問題を見逃すリスクも軽減されます。
これまでとどう変わるのか #
- これまで: メンテナンス中に通知を止めるには、アラーム自体を無効にするか、通知先の設定を一時的に削除するなどの手動操作が必要でした。これらはメンテナンス後の戻し忘れというオペレーショナルリスクを伴いました。
- これから: ミュートルールを設定することで、スケジュールに基づいて自動的に通知を制御できます。ミュート解除後の自動トリガー機能により、手動での復旧確認漏れも防げます。
具体的なユースケース #
- 定期メンテナンス: 毎週のシステムメンテナンス時間帯に、予測される負荷上昇などのアラート通知を自動で抑制。
- デプロイ作業: 新機能のリリース作業中に発生する一時的なエラー率の上昇による通知を一時的に停止。
- オフタイムの通知管理: 営業時間外の非緊急なアラート通知を静音化。
Amazon Connect がインアプリ通知を開始、重要なアラートをワークスペース上に表示 #
投稿日: 2026年02月13日
何ができるようになったのか #
Amazon Connect のワークスペースヘッダーにインアプリ通知機能が追加されました。設定作業中、データ分析中、あるいは顧客対応中であっても、作業を中断することなく重要な通知を受け取ることができます。ヘッダーのアイコンには未読バッジが表示され、クリックすることでメッセージの確認や関連リンクへのアクセス、既読管理が可能です。
何が嬉しいのか #
チームメンバーに対して、ワークフローを妨げることなく重要な更新、ポリシー変更、即座の対応が必要なアクションアイテムなどを通知できます。また、プログラムから特定の対象ユーザーに向けてターゲットを絞ったメッセージを送信できる API も提供されます。
これまでとどう変わるのか #
- これまで: 重要な連絡事項やシステムの更新情報をユーザーに伝えるには、外部のチャットツールやメール、あるいはワークスペース外での周知が必要でした。
- これから: Amazon Connect のワークスペース内で直接通知を確認できるため、業務に必要な情報を一箇所で把握し、スムーズに行動に移すことができます。
具体的なユースケース #
- トレーニングの督促: 特定のトレーニングが未完了のスーパーバイザーに対して、ワークスペース上でリマインドを送信。
- 緊急の運用変更周知: センター全体の運用ルールが変更された際、ログイン中のエージェント全員に即座に通知を表示。
- システムアップデートの受信: Amazon Connect 自体のシステム更新や重要なお知らせをワークスペース内で直接受け取る。
Amazon Connect が分析ダッシュボードの詳細なアクセス制御機能を開始 #
投稿日: 2026年02月12日
何ができるようになったのか #
Amazon Connect の分析ダッシュボードにおいて、リソースタグを使用した詳細なアクセス制御が可能になりました。エージェント、キュー、ルーティングプロファイルなどの特定のリソースに対してタグを付与し、そのタグに基づいてメトリクスの表示権限を制御できます。また、同じタグを共有するリソースの集計メトリクスをフィルタリングして表示することも可能です。
何が嬉しいのか #
組織の構造や役割に合わせて、適切なユーザーに適切なデータのみを表示させることが容易になります。例えば、特定の部門（例：カスタマーサービス部門）のマネージャーに対して、その部門に所属するエージェントやキューのメトリクスのみを閲覧可能にする、といった柔軟な運用が可能になります。
これまでとどう変わるのか #
- これまで: ダッシュボードのメトリクス表示において、特定のリソースグループ単位での厳密なアクセス制限をかけることが難しく、広範なデータが見えてしまう場合がありました。
- これから: リソースタグを活用することで、「誰がどのリソースのデータを見られるか」をきめ細かく制御でき、コンプライアンスやセキュリティの向上が図れます。
具体的なユースケース #
- 部門別のデータ分離: 複数の部署が混在するコンタクトセンターにおいて、部署ごとにタグを付与し、各部署の管理者が自部署のデータのみを分析できるように制限。
- 特定グループのパフォーマンス監視: 同じ役割（例：テクニカルサポート）を持つエージェントグループの統計情報を、タグフィルタリングを使用して一括で確認。
AWS Outposts 上で最新の Amazon EC2 C8i、M8i、R8i インスタンスが利用可能に #
投稿日: 2026年02月12日
何ができるようになったのか #
第2世代の AWS Outposts ラックにおいて、最新世代の x86 ベース EC2 インスタンスである C8i（コンピューティング最適化）、M8i（汎用）、R8i（メモリ最適化）がサポートされました。これらは AWS 専用にカスタムされた Intel Xeon 6 プロセッサを搭載しています。
何が嬉しいのか #
前世代の 7i インスタンスと比較して、パフォーマンスが 20% 向上し、メモリ帯域幅は 2.5 倍に拡大しました。また、同じラック構成および電力消費量で 20% 多いコンピューティングキャパシティを提供するため、オンプレミス環境でのスペース効率とエネルギー効率が大幅に改善されます。
これまでとどう変わるのか #
- これまで: 第2世代 Outposts で利用可能な最新世代は 7i インスタンスであり、より高いパフォーマンスやメモリ帯域幅を必要とするワークロードには限界がありました。
- これから: 8i インスタンスの導入により、大規模なデータベース、リアルタイムのビッグデータ分析、高画質のビデオエンコーディング、CPU ベースのエッジ推論など、要求の厳しいオンプレミスワークロードをより効率的に実行できます。
具体的なユースケース #
- エッジでの AI 推論: 製造現場などのエッジ環境で、より複雑な機械学習モデルを使用したリアルタイム推論を CPU ベースで実行。
- オンプレミスでの大規模 DB: 高いメモリ帯域幅を活かし、オンプレミス環境に配置が必要な大規模なリレーショナルデータベースのパフォーマンスを改善。
- リアルタイム分析: データのローカル処理が必要な環境において、第2世代 Outposts の限られたスペース内でより高い計算能力を確保。
Amazon RDS が Microsoft SQL Server 向け最新累積更新プログラム (CU23) をサポート #
投稿日: 2026年02月12日
何ができるようになったのか #
Amazon RDS for SQL Server において、SQL Server 2022 向けの最新累積更新プログラムである CU23 (KB5078297) がサポートされました。これにより、最新のバグ修正やセキュリティ更新を適用した SQL Server インスタンスを利用できるようになります。
何が嬉しいのか #
最新の累積更新プログラムを適用することで、データベースの安定性とセキュリティが向上します。AWS マネジメントコンソール、SDK、または CLI を通じて、容易に既存のインスタンスを最新の状態にアップグレードできます。
これまでとどう変わるのか #
- これまで: RDS for SQL Server 2022 のユーザーは、CU23 以前の更新レベルで運用されていました。
- これから: 最新の CU23 がサポート対象に加わったため、マイクロソフトが提供する最新の修正プログラムの恩恵を RDS 環境で受けることが可能になります。
具体的なユースケース #
- セキュリティの維持: 定期的なメンテナンスの一環として、最新の累積更新プログラムを適用し、既知の脆弱性や不具合を解消。
- システム安定化: 以前のバージョンで発生していた特定の問題を解決するために、最新の CU へアップグレード。
Amazon S3 Access Grants がアジアパシフィック（台北）リージョンで利用可能に #
投稿日: 2026年02月12日
何ができるようになったのか #
アジアパシフィック（台北）リージョンにおいて、Amazon S3 Access Grants が利用可能になりました。これにより、Microsoft Entra ID（旧 Azure AD）などのディレクトリサービス内の ID や IAM プリンシパルを、S3 上のデータセットに直接マッピングできるようになります。
何が嬉しいのか #
企業内のアイデンティティに基づいて S3 へのアクセス権限を自動的に付与できるため、大規模なデータセットに対する権限管理が非常に容易になります。データサイエンティストやアナリストなどのエンドユーザーに対して、個別の IAM ポリシーを複雑に管理することなく、使い慣れた企業アカウントでセキュアにデータへアクセスさせることが可能です。
これまでとどう変わるのか #
- これまで: 台北リージョンでは、S3 への詳細なアクセス制御には IAM ポリシーやバケットポリシーを個別に管理する必要があり、ユーザー数やデータセットが増えると管理負荷が高くなっていました。
- これから: S3 Access Grants を使用することで、組織のディレクトリ構造に合わせた大規模かつ柔軟なアクセス権限管理を台北リージョンでも実現できます。
具体的なユースケース #
- データレイクのアクセス管理: 台北リージョンの S3 に構築されたデータレイクに対して、分析チームのメンバーが所属するディレクトリグループ単位で読み書き権限を一括付与。
- マルチテナントアプリケーション: アプリケーションの各エンドユーザーに対して、そのユーザーの属性に基づいた適切な S3 プレフィックスへのアクセスを動的に提供。
AWS Batch がジョブキューとシェア使用率の可視化機能を提供 #
投稿日: 2026年02月13日
何ができるようになったのか #
AWS Batch において、ジョブキューおよび「フェアシェア (fair share)」割り当ての使用率を可視化できるようになりました。ジョブキュースナップショットにキュー使用率データが導入され、FIFO キューやフェアシェアキュー、さらには個別のフェアシェア割り当てが使用しているコンピューティングキャパシティを把握できます。また、ListServiceJobs API に scheduledAt タイムスタンプが追加されました。
何が嬉しいのか #
どのフェアシェア割り当てが最も多くのキャパシティを消費しているか、またどのジョブがリソースを牽引しているかを具体的に特定できるようになります。これにより、リソース配分の最適化や、共有環境における利用パターンの分析、ジョブの実行スケジュール管理が容易になります。
これまでとどう変わるのか #
- これまで: キュー全体の使用状況や、フェアシェア環境での各シェアごとの詳細なリソース消費状況をリアルタイムで把握することは難しく、どのユーザーやプロジェクトがリソースを占有しているかの特定に手間がかかっていました。
- これから:
GetJobQueueSnapshotAPI やマネジメントコンソールの「Share Utilization」タブを通じて、リソースの使用状況を直感的にドリルダウンして確認できます。
具体的なユースケース #
- リソース配分の最適化: フェアシェア設定において、特定のグループが意図せずリソースを独占していないかを監視し、重み付け設定などを調整。
- ジョブ実行タイミングの追跡:
scheduledAtタイムスタンプを利用して、ジョブが投入されてから実際にスケジューリングされるまでの時間を正確に追跡・分析。
AWS Resource Control Policies (RCPs) が Amazon DynamoDB をサポート開始 #
投稿日: 2026年02月12日
何ができるようになったのか #
AWS Organizations の機能である「リソース管理ポリシー (RCP: Resource Control Policies)」において、Amazon DynamoDB のサポートが開始されました。これにより、組織内のリソースに対するアクセス権限の最大値を、組織レベルで中央集中型で管理できるようになります。
何が嬉しいのか #
組織外のアイデンティティによる DynamoDB へのアクセスを拒否するなどのポリシーを一括適用することで、「データ境界 (Data Perimeter)」の構築を強化できます。個々の IAM ポリシーやリソースベースのポリシーに依存しすぎることなく、組織全体のセキュリティ基準を確実に執行できます。
これまでとどう変わるのか #
- これまで: DynamoDB に対する組織全体でのガードレール設定には、主にサービスコントロールポリシー (SCP) が使用されていましたが、これは主に「アイデンティティ（誰が）」に対する制限でした。
- これから: RCP を使用することで、「リソース（何に）」に対するアクセス許可の最大範囲を制限できるようになり、より強固な多層防御が可能になります。
具体的なユースケース #
- データ流出防止: 組織外のアカウントからのアクセスをグローバルに禁止する RCP を設定し、誤設定によるデータの一般公開や外部漏洩を未然に防ぐ。
- コンプライアンスの遵守: 組織全体で許可された特定の VPC エンドポイント経由のみのアクセスを強制する。
Amazon Connect Tasks が AI による概要表示と推奨ネクストアクションを提供 #
投稿日: 2026年02月13日
何ができるようになったのか #
Amazon Connect のタスク管理機能において、生成 AI を活用した「タスク概要」と「推奨される次のアクション」の表示がサポートされました。エージェントがタスクを受け取った際に、これまでの経緯を要約し、解決のために次に行うべきステップを自動で提案します。
何が嬉しいのか #
エージェントが過去の履歴を読み込む時間を大幅に短縮でき、迅速な課題解決が可能になります。例えば、返金リクエストのタスクでは、注文詳細の確認状況や返品資格のチェック結果などを AI がまとめ、最終的な返金完了までの最短ルートを提示してくれます。
これまでとどう変わるのか #
- これまで: エージェントは新しいタスクを受け取るたびに、関連する過去のログやコメント、外部フォームの内容を読み取って現状を把握する必要があり、初期対応に時間がかかっていました。
- これから: ワークスペース上に AI が生成した簡潔なサマリーが表示されるため、状況を即座に把握し、迷うことなく次の作業に移ることができます。
具体的なユースケース #
- 複雑なワークフローの処理: 複数のステップが必要なバックオフィス業務において、現在のステータスを AI に要約させ、手続きの抜け漏れを防ぐ。
- 引き継ぎ案件の迅速な対応: 別の担当者から回ってきたタスクの経緯を瞬時に把握し、顧客への対応を加速させる。
Connect assistant ブロックを追加する必要があります。また、ナレッジベースを追加することで、生成 AI による推奨内容をより精緻にカスタマイズすることが可能です。
Amazon RDS と Aurora がスナップショット復元時のバックアップ設定変更をサポート #
投稿日: 2026年02月13日
何ができるようになったのか #
Amazon RDS および Amazon Aurora において、スナップショットからの復元（リストア）時に、バックアップ保持期間 (backup retention period) とバックアップウィンドウ (preferred backup window) を直接確認・変更できるようになりました。これまでは、スナップショットのメタデータから設定が引き継がれ、復元後に手動で変更する必要がありました。
何が嬉しいのか #
復元作業のプロセスが簡略化され、復元完了直後から意図したバックアップポリシーで運用を開始できます。また、復元を開始する前にスナップショットに含まれるバックアップ設定を確認できるため、予期せぬ設定での復元を防ぐことができます。
これまでとどう変わるのか #
- これまで: スナップショットから復元されたインスタンスやクラスターは、スナップショット作成時のバックアップ設定を自動的に継承していました。設定を変更したい場合は、復元プロセスが完了するのを待ってからインスタンスを「修正 (Modify)」する必要がありました。
- これから: 復元操作の一環として設定を指定できるため、復元完了後の追加の手動操作が不要になります。
具体的なユースケース #
- 開発環境への復元: 本番環境のスナップショットを開発環境に復元する際、復元と同時にバックアップ保持期間を最短（例：0日や1日）に設定し、不要なストレージコストを抑制。
- メンテナンス時の迅速な構成変更: 障害復旧などの緊急時に、復元後の設定変更手順を省くことで、サービス再開までの時間を短縮。