本日の主なトピック #
- Amazon Bedrock の進化: OpenAI 互換の Projects API やバッチ推論での Converse API サポートにより、開発効率と管理性が向上。
- データベース運用の強化: RDS PostgreSQL のロック競合可視化や最新マイナーバージョンへの対応、Oracle Database@AWS の欧州展開。
- インフラ管理の柔軟性: ECS Managed Instances のキャパシティ予約統合や、EC2 Image Builder のワイルドカードによるライフサイクル管理。
- セキュリティと監視の自動化: Network Firewall の状態変更通知や、CloudWatch Logs 集約時の柔軟なロググループ名設定。
- グローバルな利便性向上: 英国での口座振替サポートや、AWS Organizations 間でのリソース共有維持機能の追加。
¥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 バッチ推論が Converse API 形式をサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon Bedrock のバッチ推論において、モデル呼び出しタイプとして Converse API 形式が利用可能になりました。これにより、バッチ処理においてもモデルに依存しない一貫した入力フォーマットを使用できるようになります。
何が嬉しいのか #
リアルタイム推論とバッチ推論で同じ統一されたリクエスト形式を使用できるため、プロンプトの管理が簡素化され、モデルの切り替えに伴う改修コストを削減できます。
これまでとどう変わるのか #
- これまで: バッチ推論では、InvokeModel API を使用したモデル固有のリクエスト形式が必要でした。
- これから: バッチ推論ジョブの作成時にモデル呼び出しタイプとして Converse を選択し、標準的な Converse API リクエスト形式で入力データを構成できるようになります。
具体的なユースケース #
- リアルタイム推論で開発したプロンプトをそのままバッチ処理に流用する。
- 複数の異なるモデルに対して、同一 of 入力フォーマットでバッチ推論を実行し、精度やコストを比較する。
Amazon Bedrock が OpenAI 互換の Projects API をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
Amazon Bedrock の分散推論エンジン「Mantle」において、OpenAI 互換の「Projects API」がサポートされました。これにより、複数のアプリケーション、環境、またはチームごとに個別のプロジェクトを作成し、論理的な分離を強化できます。
何が嬉しいのか #
各プロジェクトに対して、IAM ベースのきめ細かなアクセス制御を設定したり、タグを付与してコストの可視化を図ったりすることが可能です。OpenAI の API 仕様を使いつつ、AWS のセキュリティとガバナンス機能を活用できる点が大きなメリットです。
これまでとどう変わるのか #
- これまで: OpenAI 互換の API を使用する場合、プロジェクト単位での明確なリソース分離やコスト管理が難しく、1つのエンドポイントに複数のワークロードが混在しがちでした。
- これから: Mantle エンジンを通じて Chat Completions API などを利用する際、プロジェクトごとに環境を分けることができ、マルチチーム開発がより安全かつ管理しやすくなります。
具体的なユースケース #
- 開発、ステージング、本番の各環境をプロジェクトとして分離し、開発者が必要以上に本番リソースへアクセスできないよう IAM で制御する。
- 社内の複数の開発チームが Bedrock を共有して利用する際、チームごとのプロジェクトにタグを付けて利用料を正確に按分する。
Amazon CloudWatch が RDS PostgreSQL のロック競合診断をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
Amazon CloudWatch Database Insights の「Advanced モード」において、Amazon RDS for PostgreSQL インスタンス向けのロック競合診断機能が追加されました。これにより、進行中および過去のロック競合問題の根本原因を数分で特定できるようになります。
何が嬉しいのか #
Database Insights コンソールでロック状態を可視化し、ブロックしているセッションと待機しているセッションの関係を容易に把握できます。また、過去15か月分のロックデータが保持されるため、後日の調査も容易になります。
これまでとどう変わるのか #
- これまで: ロック競合を診断するには、手動でカスタムクエリを実行したり、アプリケーションログを分析したりする必要がありました。
- これから: コンソール上でロックを引き起こしている主要なセッション、クエリ、またはオブジェクトを迅速に特定し、トラブルシューティングを効率化できます。
具体的なユースケース #
- データベースのパフォーマンスが低下した際、どのセッションが他のセッションをブロックしているか即座に確認する。
- 数日前に発生したスパイクの原因がロック競合であったか、過去のデータを遡って調査する。
Amazon EventBridge Scheduler がクォータ監視用のリソース数メトリクスを追加 #
投稿日: 2026年02月17日
何ができるようになったのか #
Amazon EventBridge Scheduler において、スケジュールおよびスケジュールグループの概算数を示すリソースカウントメトリクスが Amazon CloudWatch に出力されるようになりました。
何が嬉しいのか #
アカウント内のリソース使用状況をリアルタイムで監視し、サービスクォータ（上限）に近づいたことを検知できます。これにより、リソースが不足する前にクォータの引き上げを申請するなど、キャパシティプランニングが容易になります。
これまでとどう変わるのか #
- これまで: アカウント内に作成済みのスケジュール総数をメトリクスとして直接把握することは困難でした。
- これから: CloudWatch コンソール上でスケジュールの総数を確認でき、アラートを設定することでクォータの管理を自動化できます。
具体的なユースケース #
- 大規模なバッチ処理で数百万のスケジュールを作成する際、現在の使用量を監視してクォータ超過によるエラーを未然に防ぐ。
- 定期的にスケジュールの増加傾向を確認し、将来的なクォータ引き上げの必要性を判断する。
Amazon OpenSearch Service がクラスタの安定性向上のための新しいインサイトを追加 #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon OpenSearch Service の Cluster Insights に、「Cluster Overload（クラスタの過負荷）」と「Suboptimal Sharding Strategy（最適でないシャード戦略）」の2つの新しいインサイトが追加されました。これにより、クラスタの安定性を損なう要因を迅速に特定できるようになります。
何が嬉しいのか #
これまでは、リソースの制約やシャードの不均衡を特定するために、複数のメトリクスやログを手動で突き合わせる必要がありました。今回のアップデートにより、問題のあるリソースの詳細と具体的な対策案が提示されるため、プロアクティブな対応が可能になります。
これまでとどう変わるのか #
- これまで: シャードの偏りによるワークロードの偏在や、リソースの飽和を検知するには、高度な分析スキルと時間が必要でした。
- これから: OpenSearch v2.17 以降を使用している場合、コンソール上で「最適でないシャード構成」や「CPU/メモリ/ディスクI/Oの過負荷」といったインサイトを確認し、推奨されるスケールアップ案などに従って迅速に対処できます。
具体的なユースケース #
- 特定のノードに負荷が集中している場合に、シャードの再配置やインデックス設計の見直しを検討する材料にする。
- 検索リクエストの拒否（Reject）が発生しそうな兆候を、過負荷インサイトから事前に察知してインスタンスタイプを変更する。
Amazon SNS が欧州（スペイン）リージョンでプッシュ通知をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
Amazon Simple Notification Service (Amazon SNS) が、AWS 欧州（スペイン）リージョンからのモバイルプッシュ通知の送信をサポートしました。
何が嬉しいのか #
スペインリージョンを利用しているユーザーは、ADM、APNs、Baidu、FCM、MPNS、WNS といった主要なプッシュ通知サービスに対して、直接通知を送信できるようになります。
これまでとどう変わるのか #
- これまで: スペインリージョンの SNS からプッシュ通知を送信することはできず、他のサポート済みリージョンのエンドポイントを利用する必要がありました。
- これから: スペインリージョンの SNS エンドポイントを使用して、グローバルなモバイルデバイスへプッシュ通知を配信でき、アーキテクチャの簡素化が図れます。
具体的なユースケース #
- スペインリージョンで運用しているモバイルアプリのバックエンドから、iOS/Android デバイスにリアルタイムの通知を送信する。
- リージョン内でのデータ処理結果を、管理者やエンドユーザーのモバイル端末へ即座に通知する。
Amazon ARC リージョンスイッチにポストリカバリワークフローなど 3 つの新機能が追加 #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon Application Recovery Controller (ARC) のリージョンスイッチ機能が拡張され、新たに「ポストリカバリワークフロー（復旧後ワークフロー）」、「RDS 実行ブロック」、「Terraform の AWS プロバイダー対応」の 3 つの機能が追加されました。
何が嬉しいのか #
リージョン障害からのフェイルオーバー後の準備作業（読み取りレプリカの再作成やスケーリングなど）を自動化できるようになります。また、RDS の昇格やレプリカ作成がネイティブにサポートされ、Terraform による IaC 管理も可能になったため、災害対策（DR）の運用負荷が劇的に軽減されます。
これまでとどう変わるのか #
- これまで: フェイルオーバー後のスタンバイリージョンの再整備や RDS 読み取りレプリカの昇格などは、手動での操作やカスタムスクリプトが必要であり、エラーや遅延の原因となっていました。
- これから: 「ポストリカバリワークフロー」により、フェイルオーバー成功後に Lambda の実行やレプリカ作成を自動で開始できます。また、IaC として DR 計画を管理し、CI/CD パイプラインに統合できます。
具体的なユースケース #
- リージョン A から B へフェイルオーバーした後、自動的にリージョン A の RDS を読み取りレプリカとして再作成し、次の障害に備える。
- フェイルオーバー完了の承認ゲートを手動で挟みつつ、前後のインフラ調整を自動化する。
AWS Resource Access Manager が組織間のアカウント移動時の共有維持をサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
AWS Resource Access Manager (RAM) において、アカウントが AWS Organizations 内外に移動した際にもリソース共有を継続できる新機能が追加されました。新しい RetainSharingOnAccountLeaveOrganization パラメータを使用することで、組織を抜けるアカウントに対してもリソースアクセスを維持できます。
何が嬉しいのか #
企業の合併、買収、または組織再編に伴うアカウントの移動時に、Route 53 Resolver ルールや Transit Gateway などの共有リソースへのアクセスを中断させることなく移行作業を進めることができます。
これまでとどう変わるのか #
- これまで: アカウントが組織（Organization）を離脱すると、その組織内で共有されていたリソースへのアクセスは自動的に解除されていました。
- これから: この設定を有効にすることで、アカウントが組織を離れても RAM は外部アカウントとして扱い、明示的な招待承諾を通じてアクセスを継続できるようになります。
具体的なユースケース #
- 企業の売却に伴い、一部のアカウントを新しい AWS 組織へ移行する際、既存の共有 Transit Gateway を使い続ける。
- 共通の IPAM プールを共有したまま、複数の子会社に跨るアカウントを別々の組織へ分離して管理する。
AWS が英国（UK）の顧客向けに Bacs ダイレクトデビットをサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
英国（UK）を拠点とする AWS ユーザーが、AWS サービスの支払いに Bacs ダイレクトデビット（口座振替）を利用できるようになりました。ポンド（GBP）ベースの銀行口座から直接支払いが可能です。
何が嬉しいのか #
クレジットカードやデビットカードの利用が制限されている企業や、銀行口座からの直接引き落としを希望するユーザーにとって、支払いの自動化と管理がより便利になります。
これまでとどう変わるのか #
- これまで: 英国のユーザーは、クレジットカード、デビットカード、またはユーロ（EUR）ベースの銀行口座による支払いのみが認められていました。
- これから: AWS 請求コンソールの「支払い設定」から Bacs ダイレクトデビットを選択し、モバイルアプリやオンラインバンキング経由でセキュアに口座を連携して支払いに利用できます。
具体的なユースケース #
- 英国のスタートアップ企業が、法人口座から直接 AWS 利用料を支払うように設定し、クレジットカードの限度額を気にせず運用する。
- 既存の請求プロセスを簡素化するために、支払手段をポンド建ての口座振替に一本化する。
Amazon CloudWatch Logs 集約ルールにおいて転送先のロググループ名をカスタマイズ可能に #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon CloudWatch Logs の集約（Centralization）ルールにおいて、転送先（集約先）のロググループ名の構造をカスタマイズできるようになりました。属性（変数）を使用して、アカウント ID、リージョン、組織単位（OU）などに基づいた階層的なロググループ名を自動生成できます。
何が嬉しいのか #
複数のアカウントやリージョンからログを一箇所に集める際、どのログがどこから来たのかをロググループ名から直感的に判別できるようになります。これにより、ログの管理効率と検索性が大幅に向上します。
これまでとどう変わるのか #
- これまで: ログを集約する際、転送先のロググループ名の自由度が低く、大量のアカウントが関わる場合に整理が困難でした。
- これから:
${source.accountId}/${source.region}/${source.logGroup}のようなパターンを定義することで、123456789012/us-east-1/cloudtrail/managementeventといった分かりやすい構造を自動で作成できます。
具体的なユースケース #
- 組織全体の CloudTrail ログを中央のセキュリティアカウントに集約し、アカウント ID ごとに整理して保管する。
- 複数の OU（組織単位）ごとにロググループの接頭辞を分け、アクセス権限管理を容易にする。
AWS Marketplace が同一アカウント内での複数契約（Concurrent Agreements）をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
AWS Marketplace において、SaaS およびプロフェッショナルサービス製品の「Concurrent Agreements（並行契約）」がサポートされました。これにより、1つの AWS アカウント内で同じ製品に対して複数の購入・契約が可能になります。
何が嬉しいのか #
企業内の異なる事業部やチームが、それぞれの予算や交渉済みの条件、価格設定に基づいて、同一の SaaS 製品を独立して調達できるようになります。既存の契約を解約したり変更したりすることなく、追加の契約を結ぶことが可能です。
これまでとどう変わるのか #
- これまで: 1つの AWS アカウントにつき、1つの製品に対してアクティブな契約は1つしか持てませんでした。そのため、追加購入や別条件での契約が必要な場合は、既存契約の更新を待つか、複雑な回避策を講じる必要がありました。
- これから: 同一アカウント内で複数の有効なサブスクリプションを並行して保持でき、事業単位での柔軟な調達が実現します。
具体的なユースケース #
- セキュリティチームが全社導入した SaaS 製品とは別に、マーケティングチームが独自のオプションを追加して同じ製品を別途契約する。
- 全社契約の更新時期を待たずに、特定のプロジェクト期間だけ追加のプロフェッショナルサービスを単発で購入する。
EC2 Image Builder がライフサイクルポリシーのワイルドカード対応と IAM 設定の簡素化を導入 #
投稿日: 2026年02月27日
何ができるようになったのか #
EC2 Image Builder のライフサイクルポリシーにおいて、イメージレシピの指定にワイルドカード（*など）が使用可能になりました。また、コンソールから必要な権限があらかじめ設定された IAM ロールを直接作成できるようになり、初期セットアップが簡素化されました。
何が嬉しいのか #
これまでは、新しいレシピを作成するたびに個別のライフサイクルポリシーを作成するか、手動でレシピを追加する必要がありましたが、ワイルドカード指定により将来追加されるレシピも自動的に管理対象に含めることができます。
これまでとどう変わるのか #
- これまで: レシピごとにポリシーを作成する必要があり、レシピ数が増えるにつれて運用負荷が増大していました。
- これから:
my-recipe-1.x.xといったパターン指定で、一致するすべてのレシピに対して一括で削除やアーカイブのルールを適用できます。
具体的なユースケース #
- セマンティックバージョニングに基づいて作成される複数のイメージレシピを、1つの「クリーンアップポリシー」でまとめて管理する。
- ライフサイクル管理用の IAM ロール作成時に、必要な権限の漏れによる設定ミスを最小限に抑える。
Amazon ECS Managed Instances が EC2 キャパシティ予約との統合をサポート #
投稿日: 2026年02月26日
何ができるようになったのか #
Amazon ECS Managed Instances (ECS MI) において、Amazon EC2 キャパシティ予約（Capacity Reservations）が利用可能になりました。キャパシティプロバイダーの設定で capacityOptionType=reserved を選択し、特定のキャパシティ予約グループを指定できます。
何が嬉しいのか #
インフラ管理を AWS に任せつつ、ミッションクリティカルなワークロードに対して確実に計算リソースを確保できるようになります。コスト効率と可用性のバランスを考慮した、よりきめ細かなスケーリング戦略が実現します。
これまでとどう変わるのか #
- これまで: ECS MI では、オンデマンドまたはスポットインスタンスの利用に限定されていました。
- これから: 「予約キャパシティのみ使用（reservations-only）」、「予約を優先し、不足時はオンデマンドへ切り替え（reservations-first）」、または「予約を使用しない（reservations-excluded）」といった柔軟な設定が可能です。
具体的なユースケース #
- 突発的なアクセス増加時でも確実に起動させたい重要なマイクロサービスのために、あらかじめ確保したキャパシティ予約を ECS MI で利用する。
- 予約したリソースを使い切った後でも、オンデマンドにフォールバックしてサービスの継続性を維持する。
AWS Network Firewall が EventBridge 経由での状態変更通知をサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
AWS Network Firewall が Amazon EventBridge と統合されました。これにより、ファイアウォールの構成変更やエンドポイントの状態変化、管理ルール（AWS/パートナー）の更新などをリアルタイムで通知できるようになります。
何が嬉しいのか #
ネットワークセキュリティ基盤における重要な変更を即座に把握できます。自動ワークフローを構築することで、SNS による通知、ITSM システムへのチケット起票、SIEM ソリューションへの統合などが可能になり、運用上の気づきと迅速な対応が実現します。
これまでとどう変わるのか #
- これまで: ファイアウォールの構成変更や状態の変化をリアルタイムで検知し、自動的なアクションに繋げるには、ログの監視など間接的な手段が必要でした。
- これから: EventBridge のイベントとして「構成変更」や「エンドポイントの状態」を直接受け取れるため、より確実かつ迅速な自動化が可能です。
具体的なユースケース #
- セキュリティルールの更新が行われた際、即座に Slack 通知を飛ばす。
- ファイアウォールのエンドポイントに異常が発生した際、自動的にトラブルシューティング用のチケットを起票する。
Oracle Database@AWS が欧州（アイルランド）リージョンで利用可能に #
投稿日: 2026年02月27日
何ができるようになったのか #
Oracle Database@AWS が、AWS 欧州（アイルランド）リージョン（eu-west-1）で利用可能になりました。まずは1つのアベイラビリティーゾーン（AZ）から開始されます。
何が嬉しいのか #
AWS データセンター内にある、OCI（Oracle Cloud Infrastructure）によって管理された Oracle Exadata システム上のデータベースサービスを利用できます。これにより、オンプレミスの Exadata や RAC（Real Application Clusters）を AWS 環境へスムーズに移行し、かつ AWS KMS（暗号化）や CloudWatch（監視）といった AWS サービスとの統合メリットを享受できます。
これまでとどう変わるのか #
- これまで: アイルランドリージョンにおいて Oracle Database@AWS を利用することはできず、同リージョンにデータレジデンシー（データ保存場所）の要件を持つ企業は導入が困難でした。
- これから: アイルランドを含む全 8 リージョン（東京を含む）で、オンプレミス環境に近い高いパフォーマンスの Oracle データベースを AWS 上で運用できるようになります。
具体的なユースケース #
- 欧州に拠点を置く金融機関が、ダブリンリージョンの AWS 環境から低遅延で Oracle 基幹データベースへアクセスしつつ、データを AWS サービスで分析する。
- オンプレミスの Oracle RAC 環境を、クラウド上で同等の構成とパフォーマンスを保ちながらリフト＆シフトする。
Amazon RDS for PostgreSQL が最新マイナーバージョン 18.3、17.9、16.13、15.17、14.22 をサポート #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon RDS for PostgreSQL において、最新のマイナーバージョンである 18.3、17.9、16.13、15.17、および 14.22 が利用可能になりました。これらのバージョンは、2026年2月12日の PostgreSQL コミュニティリリースにおけるデグレード（回帰バグ）を修正するものです。
何が嬉しいのか #
既知のセキュリティ脆弱性が修正され、PostgreSQL コミュニティによって追加された最新のバグ修正の恩恵を受けることができます。特に、直近のリリースでの不具合を解消し、データベースの安定性を向上させることができます。
これまでとどう変わるのか #
- これまで: 以前のマイナーバージョンでは、特定の条件下で回帰バグの影響を受ける可能性がありました。
- これから: スケジュールされたメンテナンスウィンドウでの自動マイナーバージョンアップグレードや、Blue/Green デプロイメントを活用して、最小限のダウンタイムで安全に最新の状態へ移行できます。
具体的なユースケース #
- セキュリティコンプライアンスを維持するために、脆弱性修正を含む最新バージョンへ定期的にアップデートする。
- 数千件規模の DB アップグレードが必要な組織において、AWS Organizations のアップグレードロールアウトポリシーを用いて、開発環境から本番環境へ段階的に展開する。
Amazon Lightsail が新しい WordPress ブループリントを導入 #
投稿日: 2026年02月27日
何ができるようになったのか #
Amazon Lightsail において、新しい WordPress ブループリントが提供開始されました。ガイド付きのセットアップウィザードにより、数クリックで WordPress がプリインストールされた仮想プライベートサーバー（VPS）を起動できます。また、IMDSv2（インスタンスメタデータサービス v2）がデフォルトで強制されるようになり、セキュリティも向上しています。
何が嬉しいのか #
ドメインの接続、DNS 設定、静的 IP の割り当て、さらには Let’s Encrypt による無料の SSL/TLS 証明書を使用した HTTPS 化まで、コンソール上のステップバイステップのワークフローに従うだけで、数分でサイトを立ち上げることができます。
これまでとどう変わるのか #
- これまで: WordPress サイトをセットアップするには、手動でドメイン連携や証明書の設定を行う必要があり、初心者にはややハードルが高い場合がありました。
- これから: すべての設定がウィザード形式で統合されているため、専門知識が少なくても、安全で実用的な WordPress 環境を迅速に構築できます。
具体的なユースケース #
- 個人のブログや企業のランディングページを、セキュアな設定（IMDSv2、HTTPS）を維持したまま、コストを抑えて短時間で公開する。
- 開発者がプロトタイプ用の CMS 環境を素早く用意し、ドメインや SSL の構成まで一気に完了させる。