2026/9/18 9:00:00 ~ 2026/9/21 9:00:00 (JST)

最近の発表

AWS Continuum now supports credential testing and accessible domain suggestions

AWS Continuum for Penetation Testingは、オンデマンドでカスタマイズされたペネトレーションテストと実際の悪用可能性テストを提供することにより、開発ライフサイクル全体を通じてアプリケーションを積極的に保護する最前線のエージェントです。開発者とセキュリティチームは、侵入テストを実行する前にログイン認証情報をテストし、推奨ドメインを受け取ることができるようになりました。これにより、最初から正確なネットワークスコープを簡単に設定できるようになり、設定ミスや無駄なテストサイクルが減ります。\n 以前は、アプリケーションがアクセスするすべての URL を特定するには手作業が必要で、認証の失敗はテストサイクル全体が完了して初めて発見され、時間とリソースを浪費していました。今回のリリースにより、テスト設定中にログイン認証情報を追加すると、AWS Continuum は実際のユーザーと同じようにアプリケーションを認証し、ログイン中にアクセスしたアクセス可能なすべてのドメインをキャプチャして、対象範囲内の URL 候補として表示します。実際のテストが始まる前に、アクセス可能なドメインを確認し、認証情報を検証し、エージェントが適切なエンドポイントをカバーしていることを確認できます。認証テストが成功、失敗、タイムアウトしたかどうかにかかわらず、アクセス可能なドメインが返されます。この機能の詳細については、更新されたドキュメントをご覧ください。

この機能は、AWS Continuum のペネトレーションテストが可能なすべてのリージョンで利用できます。詳細については、AWS Continuum 製品ページを参照してください。

Amazon ECS Express Mode now supports AWS Graviton (ARM64) workloads

Amazon Elastic Container Service Express Mode では、サービスの CPU アーキテクチャとして ARM64 を指定できるようになりました。これにより、ARM ベースのコンテナイメージを AWS Graviton 搭載コンピューティングに簡単にデプロイでき、x86 ベースのインスタンスと比較してコストパフォーマンスが最大 40% 向上するというメリットがあります。\n Amazon ECS Express モードでは、アプリケーションのクラウドアーキテクチャを調整および管理することで、ウェブアプリケーションや API などのコンテナ化されたアプリケーションを簡単にすばやく起動できます。コンテナイメージを提供すれば、残りの処理は ECS Express Mode が行い、ネットワーク、負荷分散、自動スケーリング、デプロイを設定し、アプリケーションに自動生成された URL を提供します。ARM64 アーキテクチャのサポートにより、Graviton を使用してコストを最適化するか、既存のフリートに合わせるか、ARM 用にネイティブに構築されたイメージをデプロイするかにかかわらず、ワークロードに合ったコンピューティングアーキテクチャを選択できます。

AWS マネジメントコンソール、AWS CLI、AWS SDK、およびコードとしてのインフラストラクチャ (IaC) ツールを使用して、新規および既存の Amazon ECS Express Mode サービスの CPU アーキテクチャを設定できます。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用できます。詳細については、ECS エクスプレスモードのドキュメントを参照してください。

AWS Resilience Hub adds three new capabilities

次世代の AWS Resilience Hub は AWS の中心地であり、プラットフォームエンジニアリングチームとサイト信頼性チームが AWS で実行されているワークロードの耐障害性を評価および強化するのに役立ちます。自動依存関係検出、AI を活用した生成的障害モード分析、モジュール式レジリエンスポリシー、レジリエンステスト、および組織全体のレジリエンスポスチャレポートを提供します。本日、AWS Resilience Hub には、EKS ラベルによるサービス入力ソースのサポート、依存関係に関する洞察、AWS 組織を通じたレジリエンスポリシーの共有という 3 つの新機能が追加されています。\n EKS ラベルはサービス入力ソースをサポートします。Resilience Hub は、名前空間内の EKS ラベルをサービス入力ソースとしてサポートするようになりました。これにより、お客様は既存の Kubernetes ラベル付け規則を使用して、Resilience Hub が障害モード分析中にどのリソースを検出して使用するかを正確に絞り込むことができます。これにより、評価とチームの EKS ワークロードの編成方法との整合性が保たれます。

依存関係に関する洞察。依存関係の発見を可能にしたお客様は、発見されたアプリケーションの依存関係を分析し、意味のあるパターンを明らかにする、AIを活用した新しいジェネレーティブ機能である依存関係インサイトを生成できるようになりました。依存関係に関するインサイトは、新しい依存関係を明らかにし、地域間の依存関係を特定し、異常な使用パターンにフラグを立てます。これにより、チームは依存関係の分析を迅速に行い、潜在的な新しいリスクを特定できます。

AWS 組織を通じたレジリエンスポリシーの共有。Resilience Hub は AWS Organizations を通じたレジリエンスポリシーの共有をサポートするようになり、複数のアカウントに適用できるポリシーを中央チームが構築、管理できるようになりました。これにより、どのサービスが各ポリシーを使用しているかを組織全体で把握できるようになり、導入状況を監視し、組織全体で一貫したレジリエンス体制を確保することが容易になります。

開始するには、AWS コンソールにアクセスしてください。詳細については、製品ページまたはドキュメントをご覧ください。

AWS RTB Fabric now supports configurable Availability Zone affinity

AWS RTB Fabric は、レスポンダーゲートウェイの設定可能なアベイラビリティーゾーン (AZ) アフィニティをサポートするようになりました。この機能により、パートナーがレスポンダーゲートウェイに接続する方法を、パートナー自身のアベイラビリティーゾーンまたはゲートウェイがまたがる任意のアベイラビリティーゾーンのいずれかに接続するかを設定できます。今回のローンチにより、広告テクノロジー (AdTech) 企業が RTB Fabric に追加料金を請求することなく、自社のインフラストラクチャをより効率的に利用できるようになります。\n デマンドサイドプラットフォーム (DSP) とサプライサイドプラットフォーム (SSP) は、複数のアベイラビリティーゾーンで入札システムを運用しています。以前は、AWS RTB Fabric は各リクエストを、リクエスター自身のアベイラビリティーゾーン (AZ) の空きゲートウェイ容量に送信していたため、他の AZ の容量が使用されなくなる可能性がありました。これで、これを制御するクライアントルーティングポリシーを設定できます。境界を越えることでレイテンシーが増えないようにリクエスタ専用の AZ を優先するか、レスポンダーゲートウェイがまたがるすべての AZ を使用して各リクエスターがより多くのゲートウェイ容量にアクセスできるようにするかです。設定可能なアベイラビリティーゾーンのアフィニティは、AWS RTB Fabric が利用可能なすべての AWS リージョンで利用できます。有効にする前に、AWS RTB Fabric ユーザーガイドでフリートの要件を確認してください。

AWS RTB Fabric を使用すると、Amazon Ads、GumGum、Kargo、MobileFuse、Sovrn、TripleLift、Viant、Yieldmo などのアドテックパートナーと 3 つのステップでつながることができると同時に、プライベートで高性能なネットワーク環境を通じて 1 桁ミリ秒のレイテンシーを実現できます。RTB Fabric は標準のクラウドネットワーキングコストを最大 80% 削減し、事前の契約も必要ありません。AWS RTB Fabric は通常、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド) の AWS リージョンでご利用いただけます。詳細については、AWS RTB Fabric 製品ページを参照してください。

Kimi K3 by Moonshot AI is now generally available on Amazon Bedrock

Amazon Bedrockは、お客様が信頼しているのと同じセキュリティとガバナンスで、オープンウェイトモデルのポートフォリオを拡大し続けています。現在、Moonshot AI の Kimi K3 が Amazon Bedrock で一般公開されており、コーディングとナレッジワークのための強力な新しいオプションが提供されています。\n ムーンショット AI によると、Kimi K3 は同社の最も有能なモデルであり、2.8 兆個のパラメーターに達した最初のオープンモデルです。ネイティブのビジョン機能と100万トークンのコンテキストウィンドウを組み合わせているため、大規模なリポジトリにまたがる長時間のコーディングセッション、スキャンされたページやスクリーンショットを含むマルチドキュメント分析、拡張エージェントワークフローに適しています。Moonshot AI は、スケーリング効率が Kimi K2 と比較して約 2.5 倍向上したと報告しています。Amazon Bedrock では、Kimi K3 はプロプライエタリモデルと同じセキュリティ境界内で動作し、モデルポートフォリオ全体でアクセス、暗号化、監査の制御も同じです。Kimi K3 は Amazon Bedrock で初めて明示的なプロンプトキャッシュをサポートしたオープンウェイトモデルで、モデル呼び出し間でコンテキストを再利用する際のレイテンシーと入力コストの削減に役立ちます。

Kimi K3 は、クロスリージョン推論によって Amazon Bedrock を利用できるすべての AWS リージョンで利用できます。開始するには、Amazon Bedrock コンソールにアクセスしてください。詳細については、Amazon Bedrock のドキュメントとローンチに関するブログ投稿をご覧ください。

Amazon SNS now supports message payloads up to 1 MiB

Amazon 簡易通知サービス (Amazon SNS) では、最大 1 MiB のメッセージペイロードがサポートされるようになりました。これは、以前の 256 KiB の制限から 4 倍増加したので、より大きなメッセージを SNS トピックに公開できます。\n Amazon SNS は、マイクロサービス、分散システム、サーバーレスアプリケーションを切り離してスケーリングできる、フルマネージド型のパブ/サブメッセージングサービスです。アプリケーション統合、IoT、ジェネレーティブ AI などのワークロードが 1 つのメッセージで大量のデータを交換することが増えているため、以前の 256 KiB の制限では、お客様は公開前にペイロードをオフロードまたは分割する必要がありました。

今回のリリースにより、SNS 標準トピックと SNS FIFO トピックの両方に新しい MaximumMessageSize トピック属性を設定することで、最大 1 MiB のメッセージペイロードを公開できるようになりました。最大メッセージサイズが 256 KiB 以上に設定されているトピックでは、Amazon SQS、Amazon Data Firehose、AWS Lambda のサブスクリプションがサポートされ、トピックごとに合計で最大 100 のサブスクリプションがサポートされます。

Amazon SNS の 1 MiB サポートは、現在 Amazon SNS が利用できるすべての AWS リージョンでご利用いただけます。Amazon SNS を使用して大きなペイロードを送信する方法の詳細については、Amazon SNS 開発者ガイドを参照してください。

The new AgentCore Runtime is now available in Amazon Bedrock AgentCore

本日、AWSは、Amazon Bedrock AgentCore内のサーバーレスマイクロVMコンピューティングである次世代のAgentCoreランタイムの提供を発表しました。新しいランタイムでは、セッション全体で未使用のメモリを再利用する弾力的なメモリ管理が可能なため、ピーク時ではなく実際の使用量に応じて支払いを行うことができ、コンテナイメージのサイズや同時実行数に関係なく、コールドスタート時間も一定になります。すでに頼りにしているサーバーレスモデルを手に入れることができます。事前プロビジョニングは不要で、スケールはゼロになり、ハードウェアで強制的にセッションを分離でき、支払いは使用した分だけです。コストが低く、起動も早くなります。\n 新しいランタイムでは、各セッションは小さくて効率的なメモリプロファイルで開始されます。追加のメモリーは、ワークロードの必要に応じて割り当てられ、使用されなくなったメモリーは、セッションが終了するまで保持されるのではなく、再利用されます。コールドスタートでは、新しいランタイムがエージェント環境を 1 回準備し、そのスナップショットを撮ります。すべての新しいインスタンスは、起動シーケンスをすべて繰り返すのではなく、そのスナップショットから復元するので、イメージサイズに関係なく開始時間が一定に保たれます。テスト中、新しいランタイムでは、200 MB から 2 GB のコンテナイメージで 1.9 ～ 2.0 秒の P75 コールドスタートを実現しました。これに対し、V1 では 5.4 ～ 30 秒でした。

新しい AgentCore ランタイムは、米国東部1、米国東部-2、米国西部2、欧州西部1、および ap-northeast-1 のリージョンで利用できます。はじめに、ランタイムの作成または更新時に PlatformVersion を V2 に設定してください。

詳細については、AgentCore Runtime ドキュメントまたは AWS ニュースブログをご覧ください。価格の詳細については、AgentCore 料金をご覧ください。

AWS PrivateLink announces Tunnel Endpoints to access network segments

AWS PrivateLink のお客様は、VPC エンドポイントを使用して、別の VPC /アカウントのネットワークセグメントにプライベートかつ安全にアクセスできるようになりました。新しいタイプの VPC エンドポイントである「トンネル」エンドポイントを使用して、ネットワークセグメントにトンネリングし、その中のリソースにアクセスできます。\n AWS PrivateLink は、VPC やアカウントの境界を越えて、負荷分散されたサービス、アプライアンス、およびデータベースやドメインなどのリソースへのプライベートアクセスを可能にする、可用性が高くスケーラブルなテクノロジーです。今回のリリース以前は、外部ベンダーなどとリソースを共有したいお客様は、リソースごとにリソース設定を作成して 1 つずつ行う必要がありました。今では、お客様はネットワーク内の CIDR 範囲を表すリソース設定を作成し、AWS リソースアクセスマネージャー (RAM) を介してベンダーと共有できるようになりました。その後、ベンダーはトンネルエンドポイントを作成し、GENEVE カプセル化を使用してそれをお客様の VPC にトンネリングし、お客様が指定した CIDR 範囲にあるリソースにアクセスできます。トンネルエンドポイントには時間単位の料金がかかり、トンネルエンドポイントを介して処理されるデータには GB 単位の料金がかかります。AWS PrivateLink の料金表ページを参照してください。 この機能は次の AWS リージョンで利用できます:米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (マレーシア)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、カナダ（中部）、カナダ西部（カルガリー）、ヨーロッパ（フランクフルト）、ヨーロッパ（アイルランド）、ヨーロッパ（ロンドン）、ヨーロッパ（ミラノ）、ヨーロッパ（パリ）、ヨーロッパ（スペイン）ヨーロッパ (ストックホルム)、ヨーロッパ (チューリッヒ)、メキシコ (中央)、南米 (サンパウロ)

この機能の詳細と使用を開始するには、AWS PrivateLink のドキュメントを参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Architecture Blog

AWS Cloud Financial Management

AWS Compute Blog

Artificial Intelligence

AWS Messaging Blog

Open Source Project

AWS CLI

AWS CDK

Amplify for Android