2026/11/12 9:00:00 ~ 2026/11/13 9:00:00 (JST)

最近の発表

Amazon Aurora and RDS now support Graviton5-based R9g database instances

AWS Graviton5 ベースの R9g データベースインスタンスは、PostgreSQL との互換性と MySQL との互換性を備えた Amazon Aurora と、PostgreSQL、MySQL、MariaDB の Amazon RDS で一般的に利用できるようになりました。\n Graviton5 ベースの R9g インスタンスは、データベースエンジン、バージョン、ワークロードにもよりますが、Amazon Aurora の同等のサイズの Graviton4 ベースのインスタンスと比較して、オンデマンド料金で最大 30% のパフォーマンス向上と最大 22% のコストパフォーマンスの向上を実現します。AWS Nitro システム上に構築された R9g インスタンスには、ラージから 48 x ラージまで 9 つのサイズがあります。最大 192 基の vCPU、メモリと vCPU の比率 8:1、最大 100 Gbps のネットワーク帯域幅、最大 72 Gbps の帯域幅を Amazon エラスティックブロックストア (Amazon EBS) に提供します。

R9g データベースインスタンスの使用を開始するには、Amazon RDS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用します。インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、およびヨーロッパ (フランクフルト) リージョンで利用できます。これらのインスタンスクラスをサポートする特定のエンジンバージョンについては、Aurora と RDS のドキュメントを参照してください。料金については、「Amazon Aurora 料金表」と「Amazon RDS 料金表」を参照してください。

Amazon MWAA now supports fine-grained access control with IAM Identity Center and multi-team environments

Apache Airflow 向け Amazon マネージドワークフロー (Amazon MWAA) は、きめ細かなアクセス制御をサポートするようになりました。これにより、管理者は Apache Airflow 環境内のどのワークフローとリソースに誰がアクセスできるかを正確に制御できます。きめ細かなアクセス制御は、IAM Identity Center 統合とマルチチーム環境という 2 つの新機能によって実現されています。\nIAM アイデンティティーセンターの統合により、ユーザーは社内アイデンティティプロバイダーを使用して Apache Airflow UI にサインインできます。承認は、IAM Identity Center 権限セットにアタッチされた IAM ポリシーと、リソースタイプ (DAG、接続、変数、プールなど)、アクション、および特定のリソース ID ごとにアクセスを対象とする条件キーを使用して、リクエストごとに評価されます。 マルチチーム環境では、複数のチームが 1 つの MWAA 環境を共有できます。Amazon S3 には各チームが独自の DAG フォルダを作成し、ユーザーには共有された DAG と IAM Identity Center グループのメンバーシップに基づく各自のチームの DAG のみが表示されます。チームはインフラストラクチャを共有することでコストを削減し、環境設定を一度設定することで管理を簡素化します。マルチチーム環境は、現在プレビュー段階の Apache Airflow マルチチーム機能をベースとしています。 これらの機能は Amazon MWAA が利用可能なすべての AWS リージョンで利用できます。 詳細については、IAM Identity Center 統合ドキュメントとマルチチーム環境のドキュメントをご覧ください。

Amazon Connect Customer supports merging and linking related cases in the agent workspace

Amazon Connect Customer では、エージェントがエージェントワークスペース内の関連するケースをマージしてリンクできるようになりました。これにより、エージェントは顧客の問題をより迅速に解決し、一貫した対応が可能になります。顧客が同じ問題について複数回、または異なるチャネルで企業に連絡すると、履歴が複数のケースに分かれてしまうことがあります。エージェントはそれらのケースを 1 つのケースにまとめて 1 つの履歴にまとめることができます。たとえば、エージェントは、出荷の遅延について顧客が開いたチャットケースとメールケースを統合できます。\n エージェントは、同じ問題で影響を受けたさまざまな顧客のケースなど、関連するケースをリンクできるため、影響を受けるすべての顧客に対して一貫した対応をまとめることができます。

ケースは、米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中央)、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) の AWS リージョンでご利用いただけます。詳細を確認して使用を開始するには、ケースのウェブページとドキュメントをご覧ください。

Amazon SNS now supports push notifications in four additional AWS Regions

Amazon Simple Notification Service (Amazon SNS) は、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、ヨーロッパ (チューリッヒ)、および AWS GovCloud (米国東部) リージョンでのプッシュ通知の送信をサポートするようになりました。\n Amazon SNS はフルマネージド型のパブ/サブサービスで、AWS Lambda、Amazon SQS、Amazon Data Firehose、HTTP、SMS (AWS エンドユーザーメッセージング経由)、プッシュ通知、E メールなど、複数のエンドポイントにメッセージを配信します。今回のローンチにより、これら 4 つの追加リージョンのお客様は Amazon SNS を使用して、Amazon デバイスメッセージング (ADM)、Apple プッシュ通知サービス (APN)、Baidu クラウドプッシュ (Baidu)、Firebase クラウドメッセージング (FCM)、および Windows プッシュ通知サービス (WNS) のサポート対象プッシュ通知サービスにプッシュ通知を送信できます。

プッシュ通知を送信できるリージョンの全リストについては、Amazon SNS 開発者ガイドの「サポートされているリージョンと国」を参照してください。詳細については、Amazon SNS プッシュ通知ドキュメントを参照してください。

AWS Quick enhances granular governance with the ability to restrict structured data sources

本日、AWS Quick は、カスタム権限による構造化データコネクタの制限の一般提供を発表しました。この機能により、管理者はユーザーが作成、更新、または共有できるデータソースの種類をきめ細かく制御できるため、組織はセルフサービス分析を実現しながらデータガバナンス要件を適用できます。\n この機能により、管理者はQuick UI、API、または AWS コマンドラインインターフェイスを使用して Enterprise エディションでカスタム権限プロファイルを設定できます。たとえば、組織はファイルアップロードデータソースの作成を制限しながら、ユーザーに Amazon Redshift データソースの作成を許可することができます。管理者は、特定のコネクタのデータソースをユーザーが共有できないようにすることもできます。作成、更新、共有の制限は個別に設定できるため、すべてのデータソースタイプに適用される制限よりも正確な制御が可能になります。 この機能は、ここに記載されているサポート対象のすべての AWS クイックリージョンで利用できるようになりました。詳細については、こちらのドキュメントをご覧ください。

Amazon Route 53 Domains now supports self-service restore for expired and deleted domains

Amazon Route 53 ドメインでは、Amazon Route 53 コンソール、AWS CLI、または AWS SDK を使用して、期限切れまたは最近削除されたドメインを自分で復元できるようになりました。以前は、ドメインを復元するには AWS サポートにリクエストする必要がありました。更新を怠ったり、支払い方法が期限切れになったり、誤って削除したりして失われたドメインを回復し、それに依存するウェブサイト、電子メール、アプリケーションを復元できるようになりました。\n ドメインを復元するには、ドメイン名を入力し、復元価格を確認し、請求を受け入れてリクエストを送信します。Route 53 は最上位ドメイン (TLD) レジストリと連携して登録を再開し、ドメインを AWS アカウントに戻します。ほとんどの TLD レジストリは復元をサポートしており、各レジストリは、有効期限切れまたは削除後もドメインを復元できる期間を設定します。通常、ドメインの復元には登録や更新よりも費用がかかります。

詳細については、『Route 53 開発者ガイド』の「期限切れまたは削除されたドメインの復元」または「Amazon Route 53 ドメイン」ページを参照してください。サポートされている TLD の完全なリストについては、Route 53 TLD リストを参照してください。料金については、Route 53 の料金ページをご覧ください。

EC2 Image Builder console now integrates with the DevOps Agent for troubleshooting and resource creation

EC2 Image Builder が Image Builder コンソールで AWS DevOps エージェントと直接統合されるようになりました。これにより、障害が発生したイメージパイプラインのトラブルシューティングや、コンソールのチャットパネルから直接リソースの作成が可能になります。障害が発生したパイプラインは最大 50 件まで一度に診断でき、同じ会話でフォローアップの質問をすることができます。また、必要な内容を説明してリソースを作成することもできます。エージェントは、サービスですでに検証済みの値をコンソールに入力します。\n この統合により、障害が発生したパイプラインを診断するために、ビルドログを手動で調べたり、エラーコードを相互参照したり、構成修正を繰り返したりする必要がなくなり、時間と専門知識を大幅に節約できます。エージェントはビルドログ、ワークフローステップ、コンポーネント、ネットワーク設定を読み取り、根本原因と修正手順を提供します。リソースの作成では、エージェントが設定を検証してからコンソールに入力し、ユーザーが確認して送信できるようにします。独自の AI エージェントを使用してトラブルシューティングを行ったり、ビルドしたりする場合、AWS エージェントツールキットの新しい EC2 Image Builder スキルでも、同じトラブルシューティングや作成を行うことができます。

この機能はすべての商業地域で利用できます。開始するには、EC2 Image Builder コンソールを開き、コンソールパネルから DevOps エージェントを使用してください。詳細については EC2 Image Builder のドキュメントを、料金については DevOps エージェントの料金表ページを参照してください。

Amazon FSx for Lustre lowers the entry cost of Intelligent-Tiering file systems by 75%

Amazon FSx for Lustre は、インテリジェント階層化ファイルシステムのプロビジョニングされた最小スループット容量とメタデータ IOPS を 75% 削減します。これにより、小規模なデータセットから始まり、時間の経過とともに増加するハイパフォーマンスコンピューティング（HPC）と機械学習のワークロードに、インテリジェント階層化をさらに費用対効果の高い方法で使用できるようになります。\n FSx for Lustre インテリジェント階層化ストレージクラスは、クラウド内で最も低コストで唯一完全に伸縮自在な Lustre ファイルストレージを提供します。ホットデータとコールドデータが混在し、一貫した SSD レベルのパフォーマンスを必要としないワークロード向けに最適化されています。ファイルシステムのスループット容量によって、基盤となるファイルサーバーがサポートする読み取りおよび書き込み速度が決まり、メタデータ IOPS のレベルによって、1 秒間に作成、読み取り、削除できるファイルとディレクトリの数が決まります。本日の発表により、インテリジェント階層型ファイルシステムの最小スループット容量が 4,000 MBps から 1,000 MBps に、メタデータの最小パフォーマンスが 6,000 IOPS から 1,500 IOPS に低下しました。

より低いスループット容量とメタデータ IOPS レベルは、インテリジェント階層化ストレージクラスが利用可能なすべての AWS リージョンの Lustre インテリジェント階層ファイルシステム用の新しい FSx で利用できます。詳細については、Amazon FSx for Lustre ユーザーガイドの「インテリジェント階層化ストレージクラスのパフォーマンス特性」を参照してください。

AWS Backup now supports resource modifiers for Amazon EKS restores

本日、AWS バックアップは Amazon Elastic Kubernetes サービス (Amazon EKS) バックアップを復元する際のリソース修飾子のサポートを発表しました。リソース修飾子を使用すると、復元中に Kubernetes リソースを変換できるため、復元されたクラスターをターゲット環境に適応させることができます。\n アカウント間または AWS リージョン間でコピーされた EKS バックアップを復元すると、復元されたクラスターには IAM ロール、データベースエンドポイント、Amazon ECR レジストリ URI など、ソース環境に関連する参照が格納されます。以前は、復元のたびにこれらの参照を手動で探して更新する必要がありました。これには時間がかかり、エラーも発生しやすかったです。リソース修飾子を使用すると、YAML ファイルを介して一度変換ルールを定義するだけで、AWS Backup が復元の一部として自動的に適用するため、クロスアカウントおよびクロスリージョンの災害復旧ワークフローの信頼性が向上します。

Amazon EKS バックアップ用のリソース修飾子の AWS Backup サポートは、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンで利用できます。開始するには、AWS Backup ドキュメントとリリースブログをご覧ください。

AWS Cloud WAN now supports BGP communities on Direct Connect attachments for routing policy

AWS Cloud WAN が Direct Connect アタッチメントの BGP コミュニティをサポートするようになり、エンタープライズハイブリッドネットワークの高度なルーティング制御が可能になりました。以前は、クラウド WAN ルーティングポリシーでは、サイト間 VPN と Connect のアタッチメントについてのみ BGP コミュニティを評価していました。現在では、お客様はオンプレミスでルーティングインテントを使用してルートにタグを付けたり、Cloud WAN 内でフィルタリングやパスプリファレンスのルールを適用したり、Direct Connect を介してコミュニティをオンプレミスのルーターに伝達したりできます。\n この機能により、企業はオンプレミス環境からルーティングポリシーを動的に通知することで、ハイブリッドネットワークのオーケストレーションを簡素化できます。お客様はコミュニティタグを照合して、プロダクショントラフィックとディザスタリカバリトラフィックをフィルタリングしたり、優先パスの優先順位を付けたり、地域への伝播を制限したりすることができます。これにより、VPN オーバーレイの回避策や手動によるポリシー複製が不要になり、運用の複雑さや設定ミスのリスクが軽減されます。

AWS クラウド WAN ダイレクトコネクトアタッチメントに関する BGP コミュニティサポートは、AWS ダイレクトコネクトと AWS クラウド WAN の両方が利用できるすべての AWS リージョンで利用できます。利用可能なリージョンの全リストについては、クラウド WAN ルーティングポリシーのドキュメントを参照してください。

Amazon Managed Service for Apache Flink introduces enhanced snapshots

Amazon Managed Service for Apache Flink では、Apache Flink アプリケーションと AWS リージョン全体でアプリケーションの状態をキャプチャ、エクスポート、復元できる拡張スナップショットがサポートされるようになりました。これにより、ブルー/グリーンデプロイを実行したり、状態を失わずにセルフマネージド型のワークロードを Amazon Managed Service for Apache Flink に簡単に移行したり、リージョン間の復旧に備えてセカンダリリージョンにバックアップを取ったりできるようになりました。\nBlue/Green デプロイの処理を一時停止せずにアプリケーションアップデートをデプロイするには、アプリケーションから拡張スナップショットを作成し、それを使用して 2 つ目のアプリケーションを起動します。自己管理型ワークロードを移行するには、その Apache Flink セーブポイントを拡張スナップショットとして Amazon マネージドサービス for Apache Flink にインポートします。クロスリージョンのリカバリでは、拡張スナップショットを Amazon Simple Storage Service (Amazon S3) バケットにエクスポートし、エクスポートされた状態をセカンダリージョンのバケットにレプリケートします。 現在、拡張スナップショットは、欧州ソブリンクラウド (ドイツ) を除き、Apache Flink 向け Amazon マネージドサービスが利用できるすべての AWS リージョンの Apache Flink 1.20 以降のアプリケーションで利用できます。拡張スナップショットストレージは、耐久性に優れたアプリケーションバックアップとして、毎月 GB 単位で課金されます。詳細を確認して使用を開始するには、『Amazon マネージドサービス for Apache Flink 開発者ガイド』の「拡張スナップショット」を参照してください。また、AWS エージェントツールキットを Kiro、Claude Code、または Cursor とともに使用して、拡張スナップショットを使用した Flink アプリケーションの構築と運用のガイダンスを得ることができます。

Amazon RDS for SQL Server now supports M8id and R8id instances

SQL Server 用アマゾンリレーショナルデータベースサービス (Amazon RDS) が M8id インスタンスと R8id インスタンスをサポートするようになりました。これらのインスタンスは AWS でのみ利用可能なカスタムの Intel Xeon 6 プロセッサを搭載しており、ローカルの NVMe SSD ストレージも含まれています。最大 384 個の vCPU、3 TiB のメモリ、22.8 TB のローカル NVMe SSD ストレージまで拡張できます。これは M5d インスタンスと R5d インスタンスの 4 倍の vCPU とメモリ、ローカルストレージの 6 倍以上に相当します。\n M8id または R8id を使用するように DB インスタンスを作成または変更すると、RDS for SQL Server は自動的に tempdb データファイルとログファイルをローカルの NVMe インスタンスストアに配置します。これにより、tempdb の読み取りと書き込みのレイテンシーは Amazon EBS ストレージよりも低くなります。データベースデータとログファイルは Amazon EBS に残ります。スナップショットにはインスタンスストアの tempdb ファイルが含まれていないため、スナップショットは小さくなり、空きバックアップストレージの使用量も少なくなります。詳細については、「Amazon RDS for SQL Server の tempdb データベースのインスタンスストアサポート」を参照してください。

新しい M8id および R8id インスタンスを使用するには、RDS マネジメントコンソールまたは AWS SDK または CLI を使用して、既存の RDS データベースインスタンスを変更するか、新しい RDS データベースインスタンスを作成します。M8id インスタンスと R8id インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (フランクフルト)、ヨーロッパ (ストックホルム)、ヨーロッパ (スペイン)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (マレーシア) の AWS リージョンで利用できます。料金の詳細については、Amazon RDS for SQL Server の料金表を参照してください。

The next generation AgentCore runtime is now the default

本日より、Amazon Bedrock AgentCore の新しいランタイムでは、デフォルトで次世代の AgentCore ランタイムが使用されます。新しいランタイムは、初期化されたエージェントのスナップショットから各セッションを復元し、作業に合わせてコンピューティングとメモリをスケーリングし、アイドル状態のエージェントをゼロまでスケーリングします。すべてのセッションは、ハードウェアで分離された独自の Firecracker MicroVM で引き続き実行されます。エージェントは、大規模なコードベースのコンパイル、ブラウザーの操作、セッション内でのローカルモデルの読み込みなどの重い作業を実行できます。 \n セッションは 8 vCPU と 32 GB のメモリまで拡張可能で、最大 10 GB のコンテナイメージをサポートします。2 GB のイメージでは、P75 でのセッション開始時間は 2 秒未満で、前世代の 29.7 秒から短縮されています。アイドル状態のエージェントはゼロまでスケールアップされ、メモリはリリース後数分以内に再利用されます。つまり、マルチターンエージェントの場合、1 セッションあたりの請求メモリが最大 68% 少なくなるということです。

既存のランタイムは、移動するまで現在のバージョンのままです。既存のランタイムを移動したり、まだデフォルトになっていないリージョンで次世代のランタイムを使用するには、ランタイムを作成または更新するときに PlatformVersion を V2 に設定します。新しいランタイムを現在のバージョンで維持するには、PlatformVersion を V1 に設定します。

新しい AgentCore ランタイムは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、南米 (サンパウロ)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (ミラノ)、ヨーロッパ (パリ)、ヨーロッパ (スペイン)、ヨーロッパ (ストックホルム)、アジア太平洋 (マレーシア) のデフォルトランタイムになりました:米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、南米 (サンパウロ)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (ミラノ)（ムンバイ）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（タイ）、およびアジアパシフィック（東京）。詳細については、AgentCore ランタイムのドキュメントまたは AWS ブログをご覧ください。価格の詳細については、AgentCore 料金表をご覧ください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Architecture Blog

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Compute Blog

Containers

AWS Database Blog

Desktop and Application Streaming

AWS Developer Tools Blog

AWS DevOps & Developer Productivity Blog

AWS for Industries

Artificial Intelligence

AWS for M&E Blog

AWS Storage Blog

Open Source Project

AWS CLI

Amplify for iOS

AWS Load Balancer Controller

Karpenter

Amazon EKS Anywhere