2026/8/20 9:00:00 ~ 2026/8/21 9:00:00 (JST)

最近の発表

AWS announces the general availability of a new AWS Local Zone in Las Vegas, Nevada

ネバダ州ラスベガスの AWS ローカルゾーンが一般公開されました。新しい AWS ローカルゾーンは、アマゾンエラスティックコンピュートクラウド (Amazon EC2) C7i、M7i、R7i、C8gn インスタンス、アマゾンエラスティックブロックストア (Amazon EBS) ボリュームタイプ gp3、gp2、io1、sc1、st1、アマゾンエラスティックコンテナサービス (Amazon ECS)、アマゾンエラスティッククベルネテスサービス (Amazon EKS)、アプリケーションロードバランサー、AWS ダイレクトコネクトをサポートします。\n AWS ローカルゾーンは、コンピューティング、ストレージ、ネットワーク、その他の一部のサービスなどのコアサービスを世界中の大都市圏により近い場所に拡張する AWS インフラストラクチャデプロイメントです。AWS Local Zones を利用すると、エンドユーザーワークロードの 1 桁ミリ秒単位のレイテンシーの実現、データレジデンシーの要件への対応、AI/ML 推論ワークロードのサポート、レガシーアプリケーションのクラウドへの移行とモダナイゼーションの促進が可能になります。これらすべてを AWS リージョンとして一貫した AWS API、ツール、サービスを維持しながら実現できます。AWS ローカルゾーンは世界中の 30 を超える大都市圏で利用できます。

まず、AWS グローバルビューの [リージョンとゾーン] タブから、または ModifyAvailabilityZoneGroup API を使用して、ラスベガスローカルゾーン (us-west-2-las-2a) を有効にします。料金情報については、AWS ローカルゾーンの料金表ページをご覧ください。詳細については、AWS ローカルゾーンの概要ページをご覧ください。

Amazon Timestream for InfluxDB now supports customer managed keys

InfluxDB 用 Amazon Timestream は、InfluxDB 2 データベースインスタンス、InfluxDB 2 リードレプリカ、および InfluxDB 3 クラスターに保存されているデータを暗号化するために、AWS キー管理サービス（AWS KMS）のカスタマー管理キーをサポートするようになりました。お客様はデータベースリソースを作成するときに対称 AWS KMS キーを選択します。\n Timestream for InfluxDB は、選択されたキーを使用して InfluxDB 2 および InfluxDB 3 リソースの基盤となるデータベースストレージを暗号化します。キーはデータベースリソースと同じ AWS アカウントと AWS リージョンにある必要があります。お客様はリソースの作成時にキーを指定します。リソースの作成後にキーを変更することはできません。

お客様が管理するキーのサポートは、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、および Timestream for InfluxDB アプリケーションプログラミングインターフェイス (API) から利用できます。この機能は、InfluxDB 用タイムストリームが利用できるすべての AWS リージョンで利用できます。顧客管理型キーを使用しても、InfluxDB のタイムストリームに追加料金はかかりません。標準の AWS KMS 料金が適用されます。 カスタマー管理型キーのサポートは、InfluxDB 用 Amazon Timestream が利用できるすべての AWS リージョンで利用できます。開始するには、Amazon タイムストリームコンソールを開いてください。詳細については、InfluxDB 用 Amazon タイムストリームのドキュメントと料金ページを参照してください。

Amazon EKS now supports certificate authority (CA) rotation with automated lifecycle management

本日、Amazon Elastic Kubernetes Service (Amazon EKS) は認証局 (CA) のローテーションを発表しました。これにより、お客様はクラスターの CA を自動化された保護機能を備えたマネージドライフサイクルを通じてローテーションできるようになります。Amazon EKS クラスターにはそれぞれ、クラスターの Kubernetes API への暗号化された接続を許可する独自の CA があります。これで、有効期限が切れる前に CA をローテーションして、クラスターの運用と安全性を維持できます。\n 2018 年の発売以降に作成された Amazon EKS クラスターには、有効期間が 10 年の CA があり、その時代のクラスターは CA ローテーションアクティビティを開始すべき段階に近づいています。Amazon EKS の CA ローテーションは共通の責任です。Amazon EKS はローテーションライフサイクルを管理し、後継の CA を信頼するように AWS が管理するコンポーネントを自動的に更新します。お客様は、後継の CA がアクティブになる前に、ワーカーノードを交換し、後継の CA を信頼するように外部クライアントを更新する責任を負うものとします。EKS Auto Mode インスタンスと AWS Fargate ノードは AWS によって自動的に更新されますが、クラスターの API サーバーに接続する外部クライアントを更新する責任はお客様にあります。Amazon EKS は、このプロセスを通じてお客様をサポートするための自動保護手段を提供しています。たとえば、CA の有効期限が切れる前の事前通知、後継の CA がお客様によって作成されていない場合の自動追加、お客様が独自のスケジュールでアクティベーションを行わなかった場合の自動アクティベーションなどがあります。ロールバック機能により、お客様は前の CA に戻って、後継 CA への移行中に更新によって発生する可能性のある問題を解決できます。

Amazon EKS CA ローテーションは、すべての商用 AWS リージョンで追加料金なしで利用できます。CA ローテーションを開始するには、AWS CLI、EKS API、クラウドフォーメーション、および AWS コンソールを使用できます。詳細については、Amazon EKS のドキュメントと Amazon EKS 認証局のローテーションについて詳しく調べてください。

Amazon CloudFront now supports Origin Access Control (OAC) for Amazon S3 Multi-Region Access Points

本日より、お客様は Amazon S3 マルチリージョンアクセスポイント (MRAP) を使用してオリジンを保護できます。CloudFront オリジンアクセスコントロール (OAC) を使用して、指定された CloudFront ディストリビューションからのアクセスのみを許可できます。\n お客様は Amazon S3 MRAP と CloudFront を併用することで、単一のグローバルエンドポイントからコンテンツを配信できます。これにより、キャッシュミスが発生すると、キャッシュミスが発生すると、リージョン全体で利用可能な最も近いレプリケートバケットに自動的にルーティングされるため、グローバルに分散しているユーザーのパフォーマンスと回復力が向上します。以前は、お客様はカスタムの Lambda @Edge 関数を使用して独自の非対称署名バージョン 4 (SigV4A) 認証ヘッダーを計算して転送する必要がありました。現在、CloudFront は S3 MRAP オリジンへのリクエストをネイティブで署名しています。お客様は、カスタム認証ヘッダーの計算なしに、最寄りのリージョンからより迅速にキャッシュミスフィルを受けることができ、制限付きで OAC で保護された MRAP アクセスを受けることができます。

Amazon S3 MRAP オリジンの CloudFront OAC サポートは、CloudFront 中国リージョンを除き、世界中でご利用いただけます。まず、CloudFront で Amazon S3 MRAP エンドポイントを設定する際に、CloudFront コンソール、SDK、CLI、または CloudFormation を使用して OAC を有効にしてください。詳細については、CloudFront 開発者ガイドを参照してください。この機能に関連する追加料金はありません。

AWS Partner Central agents MCP Server now supports OAuth with AWS Sign-In

AWS パートナーは、AWS サインインを通じて OAuth を使用して Amazon Quick や Kiro などのすでに使用しているツールから AWS パートナーセントラルのエージェントにアクセスできるようになりました。パートナーは、追加の認証ソフトウェアをインストールしたり保守したりしなくても、既存の AWS ID、サインイン方法、IAM 権限、ガバナンスコントロールを使用してエージェントアクセスを許可できます。\n 以前は、AWS パートナーが既存のツールから Partner Central エージェントにアクセスするには、Sigv4 認証情報を使用して MCP プロキシを設定するか、IAM 認証情報を使用して AWS マネジメントコンソールから AWS パートナーセントラルにサインインする必要がありました。OAuth は、パートナーが AWS サインインを使用して Amazon Quick や Kiro などのツールにパートナーセントラルのエージェントへのアクセスを許可できるようにすることで、これを簡素化します。パートナーは、既存のツールから OAuth を使用して共同販売契約、AWS 資金調達申請、AWS Marketplace 出品者の設定を行うことができます。管理者は IAM ポリシー、グローバル条件キー、トークンのイントロスペクションと取り消し API、動的クライアント登録、CloudTrail 監査イベントを使用してアクセスを管理できます。

OAuth サポートは、米国東部 (バージニア北部) リージョンで利用可能な AWS パートナーセントラルエージェントの MCP Server を通じて AWS パートナーが利用できます。詳細については、「パートナーセントラルエージェント MCP サーバーの使用開始」および「OAuth 2.0 によるサインイン」を参照してください。

ARC Region switch adds Amazon RDS Switchover Read Replica execution block 

本日、ARC リージョンスイッチの Amazon RDS スイッチオーバーリードレプリカ実行ブロックを開始します。これにより、マルチリージョンのワークロードで Oracle Data Guard を実行している Amazon RDS データベースのリカバリオーケストレーションが自動化されます。Amazon Application Recovery Controller (ARC) リージョンスイッチは、お客様がマルチリージョンアプリケーションのフェイルオーバーを調整して、リージョンの障害が発生した場合でも制限付きの復旧時間を実現するのに役立ちます。\n リージョナルフェイルオーバー中に Oracle Data Guard を実行している Amazon RDS データベースを復旧するには、お客様は手動でプライマリデータベースとそのリードレプリカの役割を逆転させるか、リードレプリカをプライマリデータベースインスタンスに昇格させる必要があります。リージョンスイッチでは、RDS Switchover リードレプリカ実行ブロックを使用してこの復旧を自動化できるようになりました。同じ実行ブロックが、計画的なフェイルオーバーシナリオではデータ損失なしでプライマリデータベースとリードレプリカ間のロール移行を自動化します。また、リカバリ速度が重要な計画外のフェイルオーバー時にリードレプリカをプライマリデータベースに昇格させることもできます。ネイティブのクロスアカウントサポートにより、リージョンの切り替えプランとは異なるアカウントでホストされている Amazon RDS インスタンスの復旧をオーケストレーションできるため、組織全体の復旧を一元管理できます。

開始するには、Amazon RDS Switchover リードレプリカ実行ブロックのドキュメントを参照してください。ARC リージョンスイッチの詳細については、アプリケーションリカバリコントローラーのページをご覧ください。

Generative AI Inference Recommendation for Amazon SageMaker now available in the SageMaker AI Studio

Amazon SageMaker AI が SageMaker AI Studio でジェネレーティブ AI 推論レコメンデーションを提供するようになりました。これにより、お客様は自分のワークロードに最適な推論設定を見つけるためのガイド付きのローコードコード不要のパスを利用できます。これは 2026 年 4 月の API ベースのローンチをもとにしたもので、プログラムによるアクセスよりも視覚的なワークフローを好むチームにも同じベンチマークインフラストラクチャを拡張しています。\n ジェネレーティブ AI モデルを本番環境にデプロイするには、インスタンスタイプ、サービスコンテナ、最適化戦略の適切な組み合わせを見つける必要があります。これを正しく行うには、通常、数週間にわたる手動によるベンチマーキング、構成の調整、試行錯誤が必要であり、最終的な設定が実際に最適かどうかを簡単に知る方法はありません。この新しいエクスペリエンスでは、レイテンシー、スループット、コストなど、お客様がワークロードと最も重要なことを説明するだけで、残りはSageMaker AIが行います。NVIDIA AiPerf を使用して実際の GPU インフラストラクチャー上で複数の構成をベンチマークし、スループットにはスペキュレイティブデコーディングを、レイテンシーについてはカーネルチューニングといった目標に沿った手法を適用し、測定されたパフォーマンスデータに基づいてランク付けされた本番環境向けの推奨事項を返します。チームは、どの手法を適用するか、どのように構成するかを決める必要なく、数週間ではなく数時間で検証済みの構成にたどり着きます。

この新しいエクスペリエンスでは、レイテンシー、スループット、コストなど、お客様がワークロードと最も重要なことを説明するだけで、残りはSageMaker AIが行います。NVIDIA AiPerf を使用して実際の GPU インフラストラクチャー上で複数の構成をベンチマークし、スループットにはスペキュレイティブデコーディングを、レイテンシーについてはカーネルチューニングといった目標に沿った手法を適用し、測定されたパフォーマンスデータに基づいてランク付けされた本番環境向けの推奨事項を返します。チームは、どの手法を適用するか、どのように構成するかを決める必要なく、数週間ではなく数時間で検証済みの構成にたどり着きます。

SageMaker AI Studio の [ジョブ]、[推論最適化] では、お客様はユースケースプロファイル (インタラクト、生成、要約、またはカスタム) を選択し、最適化の目標 (レイテンシの最小化、スループットの最大化、またはコストの最小化) を選択し、JumpStart、S3、モデルレジストリ、または既存の SageMaker モデルからモデルを選択します。推奨事項は、TTFT、トークン間のレイテンシー、スループット、コストによってランク付けされ、Studio から SageMaker リアルタイムエンドポイントに直接デプロイする前に視覚的に比較できます。

レコメンデーションの生成に追加費用はかかりません。ベンチマーク中にプロビジョニングされた最適化ジョブとエンドポイントには、標準のコンピューティングコストが適用されます。この機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ)、ヨーロッパ (アイルランド)、ヨーロッパ (フランクフルト)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) で利用できます。詳細については、ブログ投稿またはドキュメントをご覧ください。

AWS Direct Connect introduces inbound prefix controls and higher prefix scale

本日、AWS Direct Connect はインバウンドプリフィックスコントロールを発表しました。これは、ワークロードのニーズに基づいて、プライベートおよびトランジット仮想インターフェイス (VIF) にインバウンドルートプレフィックス割り当てを割り当てて管理できる新機能です。専用接続とホスト接続の VIF の IPv4 と IPv6 にそれぞれ最大 1,000 個のプレフィックスを割り当てることができるようになりました。\n 以前は、Direct Connect VIF は、オンプレミスネットワークからプライベート VIF または中継 VIF で AWS にアドバタイズされたルートプレフィックスを最大 100 個受け付けていました。大規模なネットワークや拡大中のネットワークでは、ルートをまとめたり、複数の VIF や接続にわたってセグメント化したりするなどして、この上限を回避するように設計する必要がありました。インバウンドプレフィックスコントロールを使用すると、1 つの VIF に最大 1,000 個のプレフィックスを割り当て、ルートを直接アドバタイズできます。

インバウンドプレフィックス制御では、専用接続レベルと Direct Connect ゲートウェイ (DXGW) レベルで新しいプレフィックス容量プールが導入されました。VIF を作成または更新する場合、特定の数のプレフィックスを割り当てます。割り当ては、アタッチ時に専用接続のプールと DXGW のプールから引き出されます。これにより、ワークロードごとにプレフィックス容量を適切なサイズに設定できます。たとえば、多くのルートを伝送する中継 VIF には大きな割り当てを、同じ接続上のプライベート VIF には小さく割り当てることができます。接続プールのサイズは接続速度に比例し、リンクアグリゲーショングループ (LAG) プールはメンバー接続の数に応じて拡張されます。

AWS Direct Connect コンソールまたは CLI/API を使用してプレフィックス割り当てを設定できます。インバウンドプレフィックス制御は、AWS Direct Connect が利用可能なすべての商用 AWS リージョン、AWS GovCloud リージョン (米国東部および米国西部)、Sinnet が運営するアマゾンウェブサービス中国 (北京) リージョン、および NWCD が運営するアマゾンウェブサービス中国 (寧夏) リージョンで追加料金なしで利用できます。

詳細については、AWS Direct Connect ユーザーガイドの「AWS Direct Connect のインバウンドプレフィックスコントロール」を参照してください。

Amazon Redshift introduces long-term system table retention with Amazon S3 Tables integration

Amazon Redshift は、Amazon S3 テーブルとのネイティブ統合により、システムテーブルデータの長期保存をサポートするようになりました。この機能により、コンプライアンス、監査、およびオブザーバビリティの要件を満たすように、Redshift システムテーブルのデータ保持期間を現在の 7 日間の制限を超えて設定することができます。有効にすると、AWS はシステムテーブルデータを Apache Iceberg 形式で S3 テーブルに自動的に書き込み、パーティショニング、コンパクション、保持を管理します。\n お客様は Redshift システムテーブルを使用して、クエリのパフォーマンスを監視し、データウェアハウスアクティビティを監査し、コンプライアンス要件を満たします。以前は、保存期間を延長するには、システムテーブルデータをコピーするためのカスタムの抽出変換ロード (ETL) パイプラインを構築して維持する必要があったため、開発作業が増え、運用上のオーバーヘッドが継続的に発生していました。複数のデータウェアハウスを運用している顧客は、各ウェアハウスのシステムテーブルデータを 1 つの場所に統合して倉庫間の分析を行うために Redshift データ共有に頼ることになり、さらに複雑になりました。この機能により、システムテーブルデータが自動的に複製されるので、カスタム ETL パイプラインが不要になり、本番環境のワークロードでリソースの競合が発生したりする必要がなくなります。複数のデータウェアハウスを運用している場合、それらのシステムテーブルデータを 1 つの場所に統合して、ウェアハウス間の観測と分析を行うことができます。データはオープンな Apache Iceberg 形式で保存されるため、Redshift、Amazon Athena、その他の Iceberg 互換エンジンを介してクエリを実行し、AWS サービスまたはサードパーティのツールを使用してオブザーバビリティダッシュボードを構築できます。追加の運用オーバーヘッドは発生しません。さらに、AWS Agent Toolkit には、システムテーブルデータをクエリしてパフォーマンスに関する洞察や最適化の推奨事項を明らかにするスキルも用意されています。

この機能は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (台北)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (大阪)、アジアパシフィック (大阪) の AWS リージョンの Amazon Redshift プロビジョンド RG および RA3 インスタンスと Amazon Redshift サーバーレスで利用できます。(ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アジアパシフィック (メルボルン)、アジアパシフィック (マレーシア)、アジアパシフィック (タイ)、カナダ (セントラル)）、ヨーロッパ（フランクフルト）、ヨーロッパ（チューリッヒ）、ヨーロッパ（ストックホルム）、ヨーロッパ（ミラノ）、ヨーロッパ（スペイン）、ヨーロッパ（アイルランド）、ヨーロッパ（ロンドン）、ヨーロッパ（パリ）、イスラエル（テルアビブ）、南米（サンパウロ）詳細については、ドキュメンテーションを参照するか、ブログをご覧ください。

AWS Marketplace now supports category-based notifications and multi-channel delivery for partners

AWS パートナーは、AWS ユーザー通知を通じて AWS Marketplace 通知のカテゴリベースの通知とマルチチャネル配信を設定できるようになりました。以前は、パートナーは AWS アカウントのルート E メールアドレスまたはカスタム E メールエイリアスを通じて AWS Marketplace 通知を受信していましたが、通知カテゴリを選択したり、各カテゴリを管理担当チームにルーティングしたりする方法はありませんでした。今回の発表により、パートナーは各通知カテゴリを受け取る連絡先と、それらの通知の配信方法を選択できます。\n 通知には 4 つのカテゴリがあります。製品リスト通知には、未処理の製品タスク、AMI とコンテナ製品の定期的なスキャン結果、SaaS 製品のベンダーインサイトセキュリティプロファイルスナップショットが含まれます。オファーと契約の通知には、プライベートオファー、リセラーアクティビティ、プロフェッショナルサービスのリクエスト、契約の開始とキャンセル、キャンセルリクエスト、および契約作成の失敗が含まれます。支払いと支払いの通知には、支払いリクエスト、請求調整、請求書提出結果、支払い失敗、支払い問題などが含まれます。アカウント管理通知には、ビジネスおよび銀行口座の検証処理、承認、有効期限、および拒否が含まれます。

デフォルトでは、通知は AWS アカウントのルート E メールアドレスに E メールで配信されます。パートナーは追加の E メールアドレスと配信リストを使用して受信者を追加できます。パートナーは、AWS コンソールモバイルアプリケーションまたは Slack や Microsoft Teams などのチャットアプリケーションの Amazon Q デベロッパーを通じて通知を受け取ることもできます。マネージド通知を有効にすると、パートナーは各カテゴリを受け取る連絡先と配信チャネルを選択できます。

AWS Marketplace のカテゴリベースの通知は、AWS Marketplace が利用できるすべての AWS コマーシャルリージョンでご利用いただけます。詳細については、AWS Marketplace ドキュメントの「AWS Marketplace イベントの E メール通知の管理」を参照してください。管理通知を有効にするには、AWS ユーザー通知コンソールにアクセスしてください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Architecture Blog

AWS Big Data Blog

AWS Compute Blog

AWS Database Blog

Desktop and Application Streaming

AWS for Industries

Artificial Intelligence

AWS Security Blog

AWS Storage Blog

Open Source Project

AWS CLI