2026/2/27 9:00:00 ~ 2026/3/2 9:00:00 (JST)

最近の発表

Amazon Lightsail expands blueprint selection with a new WordPress blueprint

Amazon Lightsail では新しい WordPress ブループリントが提供され、クラウドで WordPress ウェブサイトを立ち上げて管理することがこれまでになく簡単になりました。数回クリックするだけで、WordPress がプリインストールされた Lightsail 仮想プライベートサーバー (VPS) を作成し、ガイド付きセットアップウィザードに従ってサイトを数分で完全に構成して稼働させることができます。この新しい設計図では、インスタンスメタデータサービスバージョン 2 (IMDSv2) がデフォルトで適用されています。\n Lightsail では、ブループリントとインスタンスバンドルを選択してウェブアプリケーションを構築するだけで、クラウドを簡単に開始できます。Lightsail インスタンスバンドルには、お好みのオペレーティングシステム、ストレージ、毎月のデータ転送許容量があらかじめインストールされているインスタンスが含まれており、すぐに立ち上げて稼働させるために必要なものがすべて揃っています。新しい WordPress ブループリントには、カスタムドメインの接続、DNS の設定、固定 IP アドレスの添付、無料の Let’s Encrypt SSL/TLS 証明書による HTTPS 暗号化の有効化を順を追って説明するセットアップワークフローが含まれています。これらはすべて Lightsail コンソール内から実行できます。 この新しいブループリントは、Lightsail が利用できるすべての AWS リージョンで利用できるようになりました。Lightsail でサポートされているブループリントの詳細については、Lightsail のドキュメントを参照してください。価格の詳細や無料トライアルの開始方法については、こちらをクリックしてください。

EC2 Image Builder enhances lifecycle policies with wildcard support and simplified IAM

カスタマイズされた Amazon マシンイメージの作成、配布、管理を自動化するのに役立つサービスである EC2 Image Builder が、ライフサイクルポリシーでワイルドカードパターンをサポートし、IAM ロールの作成を簡素化できるようになりました。ワイルドカードパターンを使用して 1 つのライフサイクルポリシー内の複数のレシピのイメージを管理したり、コンソールから直接、事前入力されたデフォルトのアクセス権限を持つ IAM ロールを作成したりできるようになりました。\n 以前は、新しいレシピごとに個別のライフサイクルポリシーを作成するか、個々のレシピを手動で選択する必要があったため、新しいレシピが追加されたときの拡張が困難でした。ワイルドカードパターンがサポートされるようになったため、my-recipe-1.x.x のようなパターンを指定して、今後作成される新しいレシピを含め、一致するすべてのレシピにライフサイクルポリシーを自動的に適用できます。さらに、以前はライフサイクル管理用の IAM ロールを作成するには、必要な権限を手動で設定する必要がありました。コンソールで新しいロールを作成すると、EC2 Image Builder は必要なデフォルト権限を自動的に入力するため、セットアップ時間が短縮され、設定エラーの可能性も減りました。これらの機能を組み合わせることで、オンボーディングと継続的なメンテナンスが簡素化され、運用上のオーバーヘッドを抑えながらイメージライフサイクルを大規模に管理できるようになります。 ライフサイクルポリシーはすべての商用 AWS リージョンで利用できます。詳細については、ドキュメントを参照してください。

ARC Region switch adds three new capabilities: post-recovery workflows, RDS orchestration and AWS provider support for Terraform

Amazon Application Recovery Controller (ARC) のリージョンスイッチは、お客様がマルチリージョンアプリケーションのフェイルオーバーを調整して、リージョンの障害が発生した場合に制限された復旧時間を達成するのに役立ちます。マルチリージョンの災害復旧を自動化し、複数の AWS アカウントやリージョンにまたがるアプリケーションを復旧する際のエンジニアリングの労力を軽減し、運用上のオーバーヘッドを排除します。リージョンスイッチには、復旧後のワークフロー、ネイティブ RDS 実行ブロック、Terraform サポートの AWS プロバイダーという 3 つの新機能が加わりました。\n 復旧後のワークフロー。顧客がスタンバイリージョンにフェイルオーバーしても、ディザスタリカバリは終了しません。フェイルオーバーまたはフェールバックを調整したら、お客様は次の復旧イベントに備えて他のリージョンを準備する必要があります。現在、そのためには、スケーリング、リードレプリカの再作成、構成の検証を手動で調整する必要があります。復旧後のワークフローは、お客様がこれらの準備手順を自動化するのに役立ちます。今回のローンチにより、復旧後のワークフローはカスタムアクション Lambda 実行ブロック、Amazon RDS 作成リードレプリカ作成実行ブロック、ARC リージョン切り替えプラン実行ブロック、および手動承認実行ブロックをサポートします。お客様はリードレプリカの作成、Lambda 関数によるカスタムロジックの実行、手動承認ゲートの追加、復旧後の複雑なオーケストレーションのための子プランの埋め込みを行うことができます。復旧後のワークフローはアクティブ/パッシブデプロイで利用でき、手動でトリガーすることもできます。 RDS 実行ブロック。リージョナルフェイルオーバー中に Amazon RDS データベースの復旧を調整するには、リードレプリカをプロモートしてレプリケーションを再作成する手動の手順が必要であり、遅延やエラーが発生します。リージョンスイッチでは、RDS リカバリのオーケストレーションを自動化する 2 つの Amazon RDS 実行ブロックがネイティブでサポートされるようになりました。RDS プロモートリードレプリカ実行ブロックは、フェイルオーバー中にリードレプリカをスタンドアロンインスタンスに昇格するように調整します。RDS リードレプリカ作成実行ブロックは、復旧後のワークフローの一環としてレプリカの作成をオーケストレーションします。 Terraform サポートのための AWS プロバイダー。Terraform の AWS プロバイダーがリージョンの切り替えをサポートするようになりました。これにより、お客様は災害復旧プランを Infrastructure-as-Code として管理し、アプリケーションのデプロイとともに CI/CD パイプラインに統合できるようになりました。

Terraform の AWS プロバイダーサポートの詳細については、Terraform プロバイダーのドキュメントをご覧ください。復旧後のワークフローの実際について詳しくは、復旧後のワークフローチュートリアルをご覧ください。リージョンの切り替えを始めるには、ローンチブログまたはドキュメントをお読みください。

AWS Network Firewall now supports firewall state change notifications through Amazon EventBridge

AWS ネットワークファイアウォールが Amazon EventBridge と統合され、ファイアウォールの状態の変更や設定の更新をリアルタイムで通知できるようになりました。この新機能により、ネットワークセキュリティインフラストラクチャ全体のファイアウォール設定の更新やエンドポイントのステータス変更など、重要なファイアウォールの操作をモニタリングできます。AWS マネージドルール、パートナーマネージドルール、およびファイアウォール設定に影響する変更を即座に可視化できます。\n EventBridge との統合により、ファイアウォールの運用をリアルタイムでより詳細に把握できるようになります。Amazon SNS 経由で通知を送信したり、IT サービス管理 (ITSM) システムでチケットを作成したり、サードパーティのセキュリティ情報およびイベント管理 (SIEM) ソリューションと統合したりする自動化ワークフローを構築できます。この統合により、ネットワークセキュリティインフラストラクチャの運用上の認識を高め、設定の変更や潜在的な問題に迅速に対応できるようになります。 Amazon EventBridge による AWS ネットワークファイアウォールの状態変更通知は、現在 AWS ネットワークファイアウォールと Amazon EventBridge が利用可能なすべての AWS リージョンで利用できます。 AWS ネットワークファイアウォール EventBridge 統合の詳細については、AWS ネットワークファイアウォールのドキュメントをご覧ください。Amazon EventBridge の詳細については、Amazon EventBridge のドキュメントを参照してください。

Amazon Bedrock batch inference now supports the Converse API format

Amazon Bedrock バッチ推論では、モデル呼び出しタイプとして Converse API がサポートされるようになりました。これにより、バッチワークロードに一貫性のあるモデルに依存しない入力形式を使用できるようになりました。\n 以前は、バッチ推論には InvokeModel API を使用したモデル固有のリクエスト形式が必要でした。現在は、バッチ推論ジョブを作成するときに、モデル呼び出しタイプとして Converse を選択し、標準の Converse API リクエスト形式を使用して入力データを構造化できるようになりました。Converse バッチジョブの出力は Converse API のレスポンス形式に従います。この機能により、リアルタイム推論とバッチ推論の両方に同じ統一されたリクエスト形式を使用できるため、プロンプト管理が簡素化され、モデル間の切り替えに必要な労力が軽減されます。コンバースモデルの呼び出しタイプは Amazon Bedrock コンソールと API の両方から設定できます。 この機能は、Amazon Bedrock バッチ推論をサポートするすべての AWS リージョンで利用できます。はじめに、Amazon Bedrock ユーザーガイドの「バッチ推論ジョブの作成」と「バッチ推論データのフォーマットとアップロード」を参照してください。

Amazon CloudWatch logs centralization rules now support customizable destination log group structure

Amazon CloudWatch は、CloudWatch ログ集中化ルールを作成するときに、送信先ロググループ名のカスタマイズをサポートするようになりました。複数のアカウントにまたがるログを管理している組織は、属性を使用して一元化されたログを、アカウント ID、リージョン、組織単位、その他の AWS 組織のメタデータごとに、組織の運営方法やコンプライアンス要件の要求に合致した意味のある階層に整理できるようになりました。\n ターゲットロググループの名前構造は、ログがコピーされるときに CloudWatch Logs が自動的に実際の値に置き換える属性を使用して定義できます。たとえば、$ {source.accountId} /$ {source.region} /$ {source.logGroup} というパターンを使用すると、123456789012/us-east-1/cloudtrail/managementevent のようなデスティネーションロググループが作成され、どのアカウントとリージョンのログの送信元を簡単に特定できます。ソースアカウント ID、リージョン、ロググループ名、組織 ID、組織ユニット ID、ルート ID、フル組織パスなどの属性を使用できます。

カスタマイズ可能な送信先ロググループ名は、一元化ルールがサポートされているすべてのリージョンで使用できます。

お客様は集中管理ルールを使用してログの 1 つのコピーを無料で一元化 (取り込み) できます。一元化されたログのコピーを追加すると、1 GB あたり 0.05 USD が課金されます (バックアップリージョン機能は追加コピーと見なされます)。ストレージ料金が適用されます。詳細については、CloudWatch ログの一元化に関するドキュメントをご覧ください。

AWS Resource Access Manager now supports maintaining shares when accounts change organizations

AWS Resource Access Manager (RAM) は、アカウントが AWS 組織間を移動してもリソース共有の継続性を維持できるリソース共有設定をサポートするようになりました。新しい RetainSharingOnAccountLeaveOrganization パラメータと対応する RAM: RetainSharingOnAccountLeave Organization 条件キーを使用すると、セキュリティ管理者は、アカウントが組織を離れてもアクセスを保持するようにリソース共有を設定し、サービスコントロールポリシー (SCP) を使用して組織全体に一貫したポリシーを適用できます。\n この機能により、合併、買収、またはリストラを受けている組織は、Route53 リゾルバールール、トランジットゲートウェイ、IP アドレス管理プールなどの共有リソースへのアクセスを中断することなく維持できます。セキュリティチームは SCP を使用して、組織全体のアカウント離脱設定におけるリテインシェアリングを強制できます。RAM を有効にすると、組織アカウントは外部アカウントとして扱われるため、明示的な招待の承諾が必要になり、組織間のアカウント移行中もリソースへのアクセスは維持されます。 この機能はすべての AWS 商用リージョンで追加料金なしで利用できます。リソース共有設定の詳細については、AWS RAM のドキュメントを参照するか、AWS RAM 製品ページをご覧ください。

AWS now supports Bacs Direct Debit as a payment method for UK customers

本日より、英国を拠点とする AWS のお客様は、Bacs Direct Debit を使用して AWS サービスの料金を支払うことができます。この新機能により、GBP ベースの銀行口座からクラウド支出を直接管理する便利で自動化された方法が提供されます。\n 顧客は、Bacs 標準をサポートする個人または法人の銀行口座であればどれでも安全に接続できます。以前は、AWS は英国ではクレジットカードまたはデビットカード、および EUR ベースの銀行口座のみを受け付けていました。

サインアップ時に、お客様は AWS のサインアップページから「Bacs Direct Debit」を選択し、銀行を選択して、銀行のモバイルアプリまたはオンラインバンキング認証情報を使用して認証を行うことができます。これにより、所有権が安全に検証され、銀行口座が AWS アカウントにリンクされます。デフォルトでは、このアカウントは今後の AWS 請求書に使用されます。

既存のお客様は、AWS 請求コンソールの [支払い設定] ページに移動して Bacs Direct Debit を追加できます。「支払い方法を追加」を選択し、「Bacs Direct Debit」を選択し、同じ銀行選択と認証フローに従います。確認が完了すると、その銀行口座を今後の請求書の支払い方法として使用できるようになります。

Bacs Direct Debitは、英国地域のお客様に追加費用なしでご利用いただけます。詳細については、「Bacs ダイレクトデビットの支払い方法の管理」を参照してください。

Amazon OpenSearch Service adds new insights for improved cluster stability

Amazon OpenSearch Service では、クラスターオーバーロードとサブオプティマルシャーディングストラテジーという 2 つの新しいインサイトにより、クラスターインサイトが強化されました。準最適シャーディング戦略では、不均一なワークロード分散の原因となるシャードの不均衡を即座に可視化できます。一方、クラスターオーバーロードでは、リクエストのスロットリングや拒否につながる可能性のあるクラスターリソース使用率の上昇が明らかになります。どちらのインサイトにも、影響を受けるリソースの詳細と、実行可能な緩和策の推奨事項が含まれています。\n 以前は、リソースの制約やシャードの不均衡を特定するには、複数の指標とログを手動で関連付ける必要があり、問題を早期に発見することは困難でした。これらの新しいインサイトにより、クラスターの状態をプロアクティブに監視し、タイムリーに行動を起こすことができます。 準最適シャーディングストラテジーは、データノードの数に対してシャードの数が少なすぎるインデックス、またはシャードが他のシャードと比較して不釣り合いに大量のデータを運ぶことによって生じるシャードの不均衡を検出します。不均等なワークロード分散の根本原因を特定し、最適なシャード分散を実現してクエリのパフォーマンスとリソース利用率を向上させるのに役立つ推奨事項を提示します。同様に、Cluster Overload は、リクエストのスロットリングや拒否につながる可能性のある CPU、メモリ、ディスク I/O、ディスクスループット、ディスク使用率などのリソース使用率の上昇を特定するのに役立ちます。また、重要なワークロードを保護するための対策をタイムリーに講じることができるように、スケールアップの推奨事項も提示されます。 OpenSearch バージョン 2.17 以降では、OpenSearch UI が利用可能なすべてのリージョンで、これらの新しいインサイトを追加費用なしで利用できます。サポートされているリージョンの全リストは、こちらをご覧ください。詳細については、Cluster Insights ドキュメントをご覧になるか、入手可能なインサイトの一覧をご覧ください。

Oracle Database@AWS is now available in the Dublin AWS Region

Oracle Database @AWS は、1つのアベイラビリティーゾーン（AZ）から始めて、EU-West-1（ダブリン）で利用できるようになりました。Oracle Database @AWS を使用すると、お客様は AWS データセンター内の Oracle クラウド・インフラ (OCI) が管理する Oracle Exadata システム上のデータベース・サービスにアクセスできます。その結果、お客様はオンプレミスの Oracle Exadata および Oracle Real Application Clusters (RAC) アプリケーションを AWS 上の同等の環境に簡単に移行できるほか、データの暗号化には AWS キー管理サービス (KMS)、モニタリングには AWS CloudWatch などの AWS サービスとの統合によるメリットもあります。ダブリン地域への拡大に伴い、その地域でのデータレジデンシー要件を持つお客様は、オンプレミスの Oracle Exadata および RAC アプリケーションを AWS に移行できます。\n 今回の拡張により、Oracle Database @AWS サービスは、米国東部 1 (バージニア北部)、米国西部 2 (オレゴン)、米国東部 2 (オハイオ)、カリフォルニア州中部 1 (カナダ中部)、欧州中央部 1 (フランクフルト)、欧州西部 1 (ダブリン)、AP-ノースイースト-1 (東京)、および AP-サウスイースト-2 (シドニー) の8つのリージョンで利用できるようになりました。Oracle Database @AWS サービスを使用するには、AWS Marketplace を通じて Oracle にプライベートオファーをリクエストし、AWS マネジメントコンソールを使用してデータベースをセットアップして使用します。 詳細については、Oracle Database @AWS の概要とドキュメントをご覧ください。

Amazon RDS for PostgreSQL supports minor versions 18.3, 17.9, 16.13, 15.17, and 14.22

PostgreSQL 用アマゾンリレーショナルデータベースサービス (RDS) は、最新のマイナーバージョン 18.3、17.9、16.13、15.17、14.22 をサポートするようになりました。これらのバージョンは、2026 年 2 月 12 日の PostgreSQL コミュニティリリースからのリグレッションに対応しています。PostgreSQL の以前のバージョンにあった既知のセキュリティ脆弱性を修正し、PostgreSQL コミュニティによって追加されたバグ修正の恩恵を受けるために、最新のマイナーバージョンにアップグレードすることをお勧めします。\n マイナーバージョン自動アップグレードを使用すると、定期メンテナンス期間中にデータベースをアップグレードできます。大規模な運用を簡素化するには、マイナーバージョンの自動アップグレードを有効にし、AWS Organizations Upgrade Rollout Policy を使用して、本番システムをアップグレードする前に、まず開発環境へのアップグレードを段階的に行うようにして、何千ものアップグレードを段階的に調整します。Amazon RDS Blue/Green デプロイを物理レプリケーションと共に使用して、マイナーバージョンアップグレードのダウンタイムを最小限に抑えることもできます。 Amazon RDS for PostgreSQL を使用すると、クラウドで PostgreSQL デプロイメントを簡単にセットアップ、運用、およびスケーリングできます。価格の詳細とリージョンの提供状況については、Amazon RDS for PostgreSQL の料金表をご覧ください。Amazon RDS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して、フルマネージド型の Amazon RDS データベースを作成または更新します。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Contact Center

AWS Developer Tools Blog

Open Source Project

AWS CLI

Firecracker