AWS What's New Digest

Appearance

2026年09月19日 ​

[General] AWS Continuum now supports credential testing and accessible domain suggestions ​

概要 ​

AWS Continuum（ペネトレーションテスト用フロンティアエージェント）が、テスト実行前にログイン資格情報の検証とアクセス可能ドメインの候補提示に対応しました。これによりネットワークスコープの初期設定ミスや無駄なテストサイクルを減らせます。

変更内容・新機能の詳細 ​

テスト設定時にログイン資格情報を登録すると、AWS Continuumエージェントが実際のユーザーと同様の手順でアプリケーションへ認証を試行します。認証処理中に到達するすべてのドメイン（リダイレクト先、サードパーティCDNやIDプロバイダ等を含む）を検出して“インスコープURL候補”として提示します。提示された候補は、資格情報の検証が成功・失敗・タイムアウトのいずれであっても返されるため、認証失敗によるフルテスト後の発見を防げます。これにより、事前にアクセス可能なエンドポイントを確認してスコープ調整ができ、誤検出やテストのやり直しを削減します。機能はAWS Continuumが提供されるリージョンで利用可能です。詳細は製品ドキュメントおよび製品ページで案内されています。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、アプリケーションセキュリティエンジニア、ペネトレーションテストチーム
  • 利用シーン: テスト前にログイン資格情報を検証して、ログイン経路で到達する全ドメインを自動検出しスコープ候補として登録する場面
  • 運用効果: 認証失敗によるテストやり直しを減らし、テストサイクルと工数を節約。ネットワークスコープの過少／過大設定を低減して誤検知・見落としを防止
  • リスク低減: テスト前にカバレッジ確認ができるため、本番系や未意図のサービスへの不要な侵入リスクを減らせる
  • 互換性: ログインフロー中に外部IDプロバイダやCDNに到達するアプリケーションでも到達ドメインを検出可能（ただし特殊な認証フローは別途確認が必要）

技術的な注意点 ​

  • IAM権限: Continuumでテスト設定・資格情報登録を行うための権限を持つこと（管理者または該当サービスへの操作権限を付与）
  • リージョン制限: Continuumが提供されるリージョンで利用可能（記事記載のとおり）。リージョンごとの提供状況は製品ページで確認してください
  • コスト: Continuumの利用に伴う料金が発生する可能性があります。資格情報検証自体の追加料金有無は製品ドキュメント／料金ページで確認してください
  • 運用上の注意: 自動認証は実際のログイン操作を模倣するため、アカウントロックアウトポリシーやしきい値、MFA（多要素認証）やSSOフローの影響を受ける可能性があります。テスト用アカウントを用意し、影響範囲を事前に確認してください
  • セキュリティ: テスト用の資格情報は安全に管理（シークレットマネージャ等の使用）し、不要になったら削除すること。資格情報の送信・保存に関する組織のポリシーに従ってください
  • 動作結果: アクセス可能ドメインは資格情報検証の成功・失敗・タイムアウトに関わらず返されます。特殊な認証フロー（MFA、リスクベース認証、CAPTCHA等）は自動検証で意図した通りに動作しない可能性があるため事前検証を推奨します

参考情報 ​

[Govcloud Us] Amazon ECS Express Mode now supports AWS Graviton (ARM64) workloads ​

概要 ​

Amazon ECS Express ModeがARM64（AWS Graviton）をサービスのCPUアーキテクチャとして指定できるようになりました。これによりGraviton搭載の実行環境でARMベースのコンテナを簡単にデプロイでき、x86と比べて最大約40%の価格性能向上を得られます。

変更内容・新機能の詳細 ​

ECS Express Modeは、コンテナイメージを提供するだけでネットワーキング、ロードバランシング、オートスケーリング、デプロイを自動設定し、アプリケーションに自動生成のURLを付与するマネージドな迅速デプロイ機能です。今回のアップデートでサービスのCPUアーキテクチャとしてARM64を指定可能になり、Gravitonベースの実行環境でARMネイティブまたはマルチアーキテクチャ・イメージを稼働できます。ARM64サポートは新規サービスだけでなく既存のExpress Modeサービスにも設定可能で、AWS Management Console、AWS CLI、AWS SDK、およびIaCツールから構成できます。機能はすべてのAWS商用リージョンおよびAWS GovCloud (US) リージョンで利用可能です。適切にARM64イメージを用意することで、コスト最適化や既存フリートとの整合性を高められます。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナ開発者、SRE/運用チーム、DevOpsエンジニア、コスト最適化や高スループットを狙うアプリケーションオーナー
  • 利用シーン: Webアプリ/APIの迅速なデプロイ（Express Mode）でARMネイティブイメージをGravitonで稼働させる場面、既存x86環境からGravitonへ移行してコスト/性能改善を図る移行プロジェクト
  • 運用効果: Gravitonにより最大約40%の価格性能改善が期待でき、マネージド構成によりネットワーク・LB・スケール設定の手間を削減して導入スピードを向上できる

技術的な注意点 ​

  • イメージ互換性: デプロイするコンテナイメージはARM64でビルドするか、マルチアーキテクチャ（multi-arch）マニフェストを用意してください。x86専用イメージはそのままでは動作しません。
  • 既存サービスの切替: 既存サービスをARM64に切り替える際はタスク定義の更新や再デプロイが必要になる場合があります。ダウンタイムや互換性を検証してください。
  • 基盤実行環境: Express Modeが利用する基盤（Fargate/EC2など）でのGravitonサポート状況を事前に確認してください。実行環境によっては追加設定や制約がある場合があります。
  • IAM権限: ecs関連の作成・更新権限（例: ecs:CreateService, ecs:UpdateService）、iam:PassRole、ELBやAutoScaling関連の権限が必要です。最小権限の設計を推奨します。
  • リージョン制限: 発表時点で全AWS商用リージョンおよびAWS GovCloud (US)で利用可能とされていますが、詳細な機能サポートはリージョンごとに異なる可能性があるためドキュメントで確認してください。
  • コスト: Gravitonは価格性能が高い一方、ロードバランサーやデータ転送、追加リソースに対する料金は別途発生します。移行時は総所有コスト（TCO）を評価してください

参考情報 ​

[General] AWS Resilience Hub adds three new capabilities ​

概要 ​

AWS Resilience HubがEKSラベルのサービス入力ソース対応、依存関係インサイト（生成AI活用）、およびAWS Organizations経由のレジリエンスポリシー共有の3機能を追加しました。これによりEKSワークロードの絞り込み発見、依存関係の自動解析、組織横断でのポリシー配布が容易になります。

変更内容・新機能の詳細 ​

主な追加機能の技術的説明:

  • EKSラベルサポート（ネームスペース内のサービス入力ソース）: Resilience HubはKubernetesのラベルを用いてネームスペース内の対象リソースをスコープ指定できるようになりました。既存のラベリング規約を利用して、どのPod/Service/リソースを障害モード解析の入力として発見・解析するかを限定できます。これにより、マルチテナントや複数アプリが混在するクラスタで誤検出を減らし、チームごとの構成に一致した評価が可能になります。
  • 依存関係インサイト（生成AI活用）: 依存性検出を有効化すると、発見されたアプリケーション依存関係を生成AIで解析し、意味のあるパターンを提示します。具体的には新規に見つかった依存関係の提示、クロスリージョン依存の特定、異常な利用パターンのフラグ付けを行い、手動解析の工数を削減して潜在的リスクを早期に可視化します。解析結果は障害モード解析（failure mode analysis）の入力やリスク評価に利用できます。
  • AWS Organizations経由でのレジリエンスポリシー共有: 中央運用チームがResilience HubのレジリエンスポリシーをOrganizations単位で作成・配布できるようになりました。ポリシーの適用状況（どのアカウントやサービスが使用しているか）を組織全体で可視化できるため、ポリシー採用状況の監視や一貫したレジリエンスポスチャの維持が容易になります。 補足: これらの機能は既存のResilience Hub機能（自動依存関係検出、障害モード解析、レジリエンステスト、組織全体のレジリエンスポスチャレポーティング）に統合されます。依存関係インサイトなどの一部は依存性検出の有効化や明示的な操作が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォームエンジニア、SRE、クラウドアーキテクト、運用チーム
  • 利用シーンまたは効果: EKS上の特定アプリケーションのみを対象にした耐障害性評価、依存関係の自動解析によるリスク発見、組織全体でのレジリエンスポリシー配布と採用状況監視
  • 運用効果: 依存関係解析の工数削減、クロスアカウント/クロスリージョンの潜在的障害点の早期検出、ポリシーの一元管理による運用整合性向上
  • セキュリティ/ガバナンスへの影響: Organizations共有によりポリシー準拠を強制しやすくなる一方、共有ポリシーの変更は広範囲に影響するため変更管理が重要

技術的な注意点 ​

  • IAM権限: Resilience Hubの機能利用にはResilience Hub固有のAPI権限に加え、EKSクラスタや関連リソースを読み取る権限（EKS、Kubernetes APIへのアクセス設定やクラスタ側のRBAC設定）が必要です。Organizations共有は組織やアカウントに対する適切な権限が必要になります。
  • リージョン制限: 記事で明示されたリージョン情報はありません。リージョンによっては未対応の場合があるため利用前にコンソールやドキュメントで対応リージョンを確認してください。
  • コスト: 生成AIによる解析や追加の依存関係検出、データ保管・転送による料金が発生する可能性があります。Resilience Hubおよび関連サービスの料金ページで確認してください。
  • 事前準備: EKSラベルで正しく検出するにはクラスタ内で一貫したラベリング運用が必要です。Resilience Hubがクラスタ情報を取得できるようにAPIアクセスや必要なエージェント/統合の設定を行ってください。
  • 運用上の注意: Organizationsでポリシーを共有する前にステージング環境で影響検証を行い、ポリシー変更の運用フローと承認を整備してください。

参考情報 ​

[General] AWS RTB Fabric now supports configurable Availability Zone affinity ​

概要 ​

AWS RTB Fabricは、レスポンダーゲートウェイに対して可変のAvailability Zone（AZ）アフィニティを設定できるようになりました。これにより、パートナー（DSP/SSPなど）がゲートウェイへ接続する際に「自分のAZを優先」するか「ゲートウェイが跨るすべてのAZを利用可能」にするかを選べます。

変更内容・新機能の詳細 ​

技術的には、RTB FabricのクライアントルーティングポリシーにAZアフィニティ設定が追加されました。従来はリクエスト発行者の所属AZのゲートウェイ容量へのみ送信され、他AZの容量が未使用になることがありました。本機能により次の2つの動作を選択できます：

  • リクエスト発行者のAZを優先（prefer same-AZ）：AZ間のレイテンシや境界越えコストを避け、単一AZ内で処理して遅延を最小化します。
  • ゲートウェイが跨るすべてのAZを利用可能（use all AZs）：各リクエスターがより多くのゲートウェイ容量にアクセスできるようにし、スループットや処理能力を向上させます。 設定はResponder Gateway側のクライアントルーティングポリシーで行い、機能自体に対する追加料金はRTB Fabricでは発生しません。導入前にUser Guideに記載されたフリート（ゲートウェイ配置・冗長性）要件を確認する必要があります。機能はRTB Fabricが提供されている全リージョンで利用可能です（記事時点でのRTB Fabric一般提供リージョン：米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シンガポール）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（アイルランド））。 また、RTB Fabricは専用かつ低レイテンシなネットワーク環境を通じて広告関連パートナーとの接続を簡素化し、標準的なクラウドネットワーキングコストを最大80%削減するとされています。

影響範囲・利用シーン ​

  • 対象ユーザー: AdTech事業者（DSP、SSP）、広告配信プラットフォーム、ネットワーク/インフラ担当者
  • 利用シーンまたは効果: マルチAZで稼働する入札システムが、各リクエスターにより多くのゲートウェイ容量を割り当てられるようになりスループット向上や容量の有効活用が可能
  • 運用効果: レイテンシ優先設定で境界越え遅延を回避、容量優先設定でリクエストの処理成功率やスループットを改善できる
  • コスト影響: RTB Fabric自体に対する追加料金はないが、AZを跨ぐトラフィックの増加が他サービスのデータ転送費用に影響する可能性がある
  • 導入前の確認項目: レスポンダーゲートウェイが複数AZにまたがっているか、User Guideに記載のフリート要件を満たしているかを確認すること

技術的な注意点 ​

  • IAM権限: Responder Gatewayのルーティング/設定を更新できるIAM権限（管理者または該当のRTB Fabric設定更新権限）が必要です。具体的な最小権限はUser Guide/ドキュメントで確認してください
  • リージョン制限: 本機能はRTB Fabricが利用可能なリージョンで利用可能です。記事時点の一般提供リージョン：米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シンガポール）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（アイルランド）。各リージョンの対応状況は公式ページで確認してください
  • コスト: RTB Fabric自体には追加料金が発生しませんが、AZ間通信量増加が他のAWSサービスのデータ転送料金に影響する可能性があります。総コストは運用設定（優先AZか全AZ利用か）で変動します
  • 運用上の注意: 設定変更前にステージングで負荷/レイテンシ試験を行い、モニタリング（レイテンシ、エラー率、AZごとの使用率）とアラートを設定してください
  • その他: 機能有効化にはResponder Gatewayのフリート要件を満たす必要があります。設定ミスがあると望ましいトラフィック分散が行われないため、User Guideの手順に従って慎重に設定してください

参考情報 ​

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

概要 ​

Amazon BedrockでMoonshot AIの大規模オープンウェイトモデル「Kimi K3」が一般提供（GA）になりました。2.8兆パラメータ、ネイティブなビジョン対応、最大100万トークンのコンテキストウィンドウを備えたモデルで、コーディングや大規模ドキュメント処理に適しています。

変更内容・新機能の詳細 ​

Kimi K3はMoonshot AIが提供する最も大きなモデルで、公開されたオープンウェイトモデルとして初めて2.8兆パラメータに到達したとされています。主な技術特徴はネイティブなビジョン能力（スキャンページやスクリーンショットの解析を含む）と、最大1,000,000トークンのコンテキストウィンドウを持つ点です。これにより、大規模リポジトリをまたぐ長時間のコーディングセッション、複数ドキュメントの統合解析、長いエージェントワークフローの維持が可能になります。Moonshotは前世代Kimi K2比で約2.5倍のスケーリング効率向上を報告しています。

Amazon Bedrock上では、Kimi K3は他の（プロプライエタリ）モデルと同じセキュリティ境界内で動作し、アクセス制御、暗号化、監査といった統一されたガバナンスを利用できます。さらに、Bedrock上で提供されるオープンウェイトモデルとして初めて「明示的なプロンプトキャッシュ（explicit prompt caching）」をサポートしており、再利用するコンテキストをキャッシュすることでレイテンシ低減と入力（トークン）コスト削減が期待できます。Kimi K3は、Amazon Bedrockが利用可能なリージョンへクロスリージョン推論を通じて提供されます。導入・操作はAmazon BedrockコンソールおよびBedrockのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ソフトウェア開発者、AIエンジニア、NLP/ドキュメント解析担当者、SRE/運用チーム
  • 利用シーン: 大規模リポジトリの長時間コーディングや自動コードレビュー、スキャン／スクリーンショットを含む複数ドキュメントの統合解析、長期にわたるエージェントワークフロー（状態を保った対話型自動化）
  • 運用効果: 1Mトークンのコンテキストにより長期間のコンテキスト維持が可能になり、モデル切替や分割処理の手間を削減。プロンプトキャッシュにより再利用ケースでの応答レイテンシと入力トークンコストを低減できる可能性がある

技術的な注意点 ​

  • IAM権限: Bedrockのモデル一覧・呼び出し権限（例: bedrock:InvokeModel 等）や関連するKMSアクセス権を事前に確認してください
  • リージョン制限: Amazon Bedrockが提供されているリージョンでクロスリージョン推論を介して利用可能です。Bedrock非対応リージョンでは利用できません
  • コスト: 1,000,000トークンの大きなコンテキストは入力コストと処理コストを押し上げる可能性があります。明示的プロンプトキャッシュはトークン課金を抑える手段になりますが、クロスリージョン推論やデータ転送による追加費用も考慮してください
  • セキュリティ・監査: Bedrockの既存のアクセス制御、KMS暗号化、CloudTrailによる呼び出し監査が適用されます。機密データを扱う場合はKMSキー管理・ログ設定を確認してください
  • データフォーマット: ネイティブなビジョン対応を使う場合、画像の前処理（解像度・フォーマット）やOCRの前提条件を確認してください。大量の画像を送る場合は転送・処理コストに注意が必要です
  • 性能留意点: ベンダーの報告ではKimi K3はK2よりスケーリング効率が向上していますが、実ワークロードでのレイテンシ/スループットは入力サイズや同時実行数で変動します。負荷試験とコスト試算を事前に行ってください

参考情報 ​

[Govcloud Us] Amazon SNS now supports message payloads up to 1 MiB ​

概要 ​

Amazon SNSがトピックのメッセージペイロード上限を従来の256 KiBから最大1 MiB（4倍）に拡張しました。トピック属性MaximumMessageSizeを設定することで、Standard/FIFO両タイプのトピックで大きなメッセージを直接配信できます。

変更内容・新機能の詳細 ​

技術的には、SNSトピックの新しいトピック属性「MaximumMessageSize」を設定することで、パブリッシュ可能なメッセージ本文（ペイロード）サイズを最大1,048,576バイト（1 MiB）まで拡張できます（既定は262,144バイト＝256 KiB）。対称に、MaximumMessageSizeを256 KiBより上に設定したトピックは、Amazon SQS、Amazon Kinesis Data Firehose、AWS Lambda のサブスクリプションで大きなペイロードをサポートします（その場合、トピックあたりの総サブスクリプション数は最大100になります）。

運用上の注意点・実装例:

  • MaximumMessageSizeの値はバイト単位で指定します（例: 1048576）。
  • AWS CLIで設定する例: aws sns set-topic-attributes --topic-arn <ARN> --attribute-name MaximumMessageSize --attribute-value 1048576
  • デフォルトの256 KiB制限がある既存トピックは、明示的にこの属性を更新しない限り動作は変わりません。
  • メッセージ属性やヘッダを含めたサイズ計測や、受信側サービス（SQSやLambdaなど）の独自制限は別途確認してください。

背景: IoTデバイスやアプリ統合、ジェネレーティブAIなどで1メッセージあたりのデータ量が増加しており、従来はS3にオフロードしたりメッセージを分割する必要がありました。本変更により、直接大きなペイロードを送信できるケースが増え、アーキテクチャの単純化やレイテンシ低減が期待できます。

影響範囲・利用シーン ​

  • 対象ユーザー: マイクロサービス開発者、分散システム設計者、IoT/エッジデバイス開発者、サーバーレスアプリケーション開発者
  • 利用シーン: 大きなペイロード（画像、モデル入力/出力、複合イベントなど）を単一メッセージで送信したい統合シナリオ
  • 運用効果: メッセージ分割やS3オフロードの頻度が減り、実装と運用の簡素化、レイテンシ低減が図れる
  • 制限・互換性: MaximumMessageSizeを256 KiBより大きく設定したトピックはAmazon SQS、Kinesis Data Firehose、Lambdaのサブスクリプションで大きなペイロードをサポートする一方、トピックあたりのサブスクリプション数が最大100に制限される（256 KiB以下の運用と異なる点）
  • リージョン適用: SNSが利用可能なすべてのAWSリージョンで利用可能（GovCloud（US）を含むリージョン表示あり）

技術的な注意点 ​

  • IAM権限: トピック属性の更新にはsns:SetTopicAttributes等の権限が必要です。パブリッシュ/サブスクライブ側もそれぞれ適切なポリシーを確認してください
  • リージョン制限: SNSが提供されている全リージョンで有効とされています（公式記事では "all AWS Regions where Amazon SNS is available" と記載）。特定リージョンでの確認は推奨します
  • コスト: 送受信するデータ量が増えるため、SNSのデータ転送やサブスクライバ（Lambda実行時間・データ受信、SQS等のリクエスト/データ量）に伴う料金が増加する可能性があります
  • サービス制限: MaximumMessageSizeを256 KiBより上に設定した場合、当該トピックはSQS、Kinesis Data Firehose、Lambdaのサブスクライバをサポートしますが、サブスクライブ先サービス側にも独自のメッセージサイズ制限や挙動があります。受信側（例: SQSのメッセージサイズ上限）を事前に確認してください
  • 設定方法: 属性はAWS CLI、AWS SDK、またはコンソールから変更できます。値はバイト単位で指定（例: 1048576）
  • 互換性: 既存のクライアントや中継サービス（HTTP/HTTPS, Email等）が大きなペイロードを受け取れない場合は、互換性を確認のうえ設計を見直してください

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026