AWS What's New Digest

Appearance

2026年10月02日 ​

[General] The AWS MCP Server is now available in six additional AWS Regions ​

概要 ​

AWS MCP Server（Agent Toolkit for AWS の一部である管理された Model Context Protocol サーバー）が、6つの追加リージョン（シンガポール、シドニー、東京、アイルランド、ロンドン、米国西部（オレゴン））で利用可能になりました。これにより、開発者はより低遅延でリージョン内にデータを留めたまま AI コーディングエージェントを稼働できます。

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

AWS MCP Server は AI ベースのコーディングエージェントに対して AWS API への単一インターフェースを提供するマネージドな Model Context Protocol（MCP）サーバーです。各サービスごとの統合実装をエージェント側で作成・保守する必要がなくなり、エージェントは MCP サーバーのエンドポイントに対してリクエストを送るだけで、MCP が背後の AWS サービスを発見して呼び出します。今回の拡張で、MCP サーバーは以下のリージョンで稼働します（合計8リージョン）：US East (N. Virginia)、US West (Oregon)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)。MCP サーバー自体は上記リージョンのいずれかで動作しますが、MCP を経由して呼び出せる AWS サービスは全ての商用 AWS リージョンにアクセス可能です。今回のリージョン追加により、ローカルエンドポイントへのルーティングで遅延低減やデータレジデンシー要件の遵守がしやすくなります。導入・利用開始は「Getting started with the AWS MCP Server」および「AWS MCP Server endpoints and quotas」の公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: AI コーディングエージェント／自動化エージェントを利用する開発チーム、プラットフォームエンジニア、SRE/運用チーム
  • 利用シーン: エージェントによるインフラ構築（プロビジョニング）、実行中ワークロードの確認、障害時のデバッグ、コード生成からの AWS API 呼び出しを地域内エンドポイントへ低遅延で行うケース
  • 運用効果: エージェント用のサービス別統合の構築・保守工数削減、レイテンシ低下による開発効率向上、リージョン内にリクエストデータを留めることでデータレジデンシー／コンプライアンス要件への対応が容易化

技術的な注意点 ​

  • IAM権限: エージェントが MCP 経由で実行する API に対して適切な IAM ポリシー／ロールを設定してください。最小権限の原則を適用し、必要に応じてロールの切替（sts:AssumeRole）を設計します。
  • リージョン制限: MCP サーバー自体は指定のサポートリージョン（US East (N. Virginia)、US West (Oregon)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)）で稼働します。エージェントはローカルの MCP エンドポイントを指すことで遅延とデータ滞留場所を制御できますが、MCP を経由してアクセスする対象 AWS サービスはすべての商用リージョンに対して呼び出し可能です。
  • ネットワーク/エンドポイント: エージェントと MCP エンドポイント間のネットワーク接続（VPC、セキュリティグループ、NAT/インターネット経路など）を設計してください。プライベート接続や VPC エンドポイントの利用可否はドキュメントで確認のこと。
  • データ保護: MCP サーバーはリクエストデータをホストするリージョンに留められるため、データレジデンシー要件を満たしやすくなります。ログや監査情報の保存先も合わせて設計してください（暗号化・アクセス制御を検討）。
  • コスト: MCP 自体の提供形態に依存しますが、MCP 経由で発生する各種 AWS API 呼び出し、関連サービスの利用料およびデータ転送コストは通常の課金が発生します。大量トラフィックの想定やクロスリージョンアクセスがある場合はコスト影響を評価してください。
  • クォータ/制限: エンドポイントごとのレート制限や同時接続数などのクォータが設定されている可能性があります。利用前に「AWS MCP Server endpoints and quotas」を確認し、必要に応じて引き上げ申請を行ってください。
  • 互換性/導入影響: 既存のエージェント実装を MCP エンドポイントへ向け替える作業が必要です。MCP のプロトコル仕様に合わせたクライアント実装または Agent Toolkit の利用を検討してください。

参考情報 ​

[Bedrock] AgentCore Gateway supports private TLS certificates for VPC endpoints ​

概要 ​

Amazon Bedrock の AgentCore Gateway が、VPC 内のプライベートエンドポイント向けにプライベート証明書（社内 CA 発行証明書）を信頼できるようになりました。MCP、OpenAPI、HTTP プロキシ（passthrough）ターゲットで利用可能で、ALB を挟まずネイティブに TLS 接続を確立できます。

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

AgentCore Gateway は、ターゲットがプライベート CA によって発行された TLS 証明書を使っている場合でも安全にアウトバウンド TLS 接続を確立できるようになりました。ユーザーは PEM 形式の CA 証明書をターゲットに登録し、AgentCore Gateway はその PEM ファイルを Amazon S3 または AWS Secrets Manager から取得してトラストアンカー（信頼の根拠）として使用します。対応対象は MCP サーバーターゲット、OpenAPI ターゲット、HTTP プロキシ（passthrough）ターゲットで、VPC Lattice によるプライベートエンドポイントを利用する構成に適用されます。これにより、内部 CA 発行の証明書を使ったプライベートサービスへ ALB を経由せず接続でき、構成の簡素化・遅延低減・コスト削減が期待できます。サポートは、AgentCore Gateway と Amazon VPC Lattice の両方が利用可能な全リージョンで有効です。詳しい設定手順や API/コンソールでの登録方法は AgentCore Developer Guide を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Bedrock AgentCore を使って VPC 内のプライベートエンドポイントに接続する開発者／SRE／プラットフォームチーム
  • 利用シーン: 社内 CA（プライベート CA）で発行したサーバー証明書を使用するプライベート API やバックエンドサービスへの安全な接続（MCP/OpenAPI/HTTP proxy passthrough）
  • 運用効果: Application Load Balancer を経由せずにネイティブ接続が可能になり、アーキテクチャの簡素化、レイテンシ削減、ALB による追加コスト回避が期待できる
  • セキュリティ: 社内 CA を信頼アンカーとして利用できるため、社内ポリシーに沿った証明書管理が可能。Secrets Manager/S3 を介した CA 配布で鍵管理とローテーション運用がしやすくなる

技術的な注意点 ​

  • 証明書フォーマット: 登録する CA 証明書は PEM 形式（PEM-encoded）である必要があります
  • 取得先: AgentCore Gateway は CA 証明書を Amazon S3 または AWS Secrets Manager から取得します。該当リソースへの読み取り権限が必要です
  • 対象ターゲット: MCP サーバー、OpenAPI、HTTP proxy (passthrough) の各ターゲットが対象です
  • TLS の挙動: 登録した CA 証明書をトラストアンカーとしてアウトバウンド TLS 検証を行います。ターゲットのサーバー証明書がその CA により署名されている必要があります
  • ネットワーク設定: VPC Lattice を用いたプライベートエンドポイントが前提。ターゲットへのルーティング、セキュリティグループ／NACL により接続可能であることを確認してください
  • IAM 権限: AgentCore Gateway が S3/Object や Secrets Manager のシークレットを取得できるように必要な IAM ポリシーを付与してください（例: s3:GetObject、secretsmanager:GetSecretValue）
  • 証明書ローテーション: CA 証明書の更新時は Gateway へ登録し直す必要があります。Secrets Manager を使うとローテーションの自動化が簡単になります
  • リージョン制限: AgentCore Gateway と Amazon VPC Lattice の両方が利用可能なリージョンでサポートされます。片方が未対応のリージョンでは利用できません
  • コスト: S3/Secrets Manager の利用料、VPC Lattice の実行コストおよびデータ転送コストが発生する可能性があります
  • 注意点: 本機能は AgentCore Gateway がターゲットに対してクライアント（アウトバウンド）として TLS 接続を行うケース向けです。AgentCore 自身の公開エンドポイント（インバウンド TLS）とは別の扱いになります

参考情報 ​

[ElastiCache] Amazon ElastiCache for Valkey now supports OpenTelemetry metrics and detailed monitoring ​

概要 ​

Amazon ElastiCache for Valkey が OpenTelemetry メトリクスを Amazon CloudWatch に公開するようになり、標準監視（60秒）に加えて選択式の詳細監視（15秒）をサポートします。各メトリクスは属性（attributes）を持ち、PromQL でフィルタ・集計できます。

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

技術的内容の要点:

  • OpenTelemetry メトリクス公開: node ベースの Valkey クラスターに対して ElastiCache が OpenTelemetry 形式のメトリクスを CloudWatch に発行します。各メトリクスは属性情報を持ち、属性をキーにしたフィルタやラベル集計が可能です（Prometheus Query Language: PromQL を利用可能）。
  • 監視モード: ①Standard（既存）: 既存の CloudWatch Metrics（Classic）を引き続き 60 秒間隔で公開し、あわせてコアな OpenTelemetry メトリクスも 60 秒間隔で無料で公開されます。②Detailed（新規）: フルセットの OpenTelemetry メトリクスから必要なものを選択して 15 秒間隔で公開できます（詳細監視は CloudWatch 側の OpenTelemetry 課金が適用）。
  • 運用/解析の利点: 接続数の上限に近いノードの検出、エラーをタイプ別に分解しての原因追及、メモリ枯渇予測、短時間のレイテンシスパイク検出など短周期で発生する事象の早期検出が可能になります。これらのクエリは CloudWatch の PromQL 対応機能や Grafana から実行できます。
  • ElastiCache Insights 連携: コアの OpenTelemetry メトリクスは CloudWatch の ElastiCache Insights（事前構築ダッシュボード）で利用されます。
  • 利用開始手順（コンソール）: ElastiCache コンソールで対象クラスターの Metrics タブを開き、Detailed を選択して "Configure detailed metrics" を実行します。
  • 利用可能範囲と課金: node ベースの Valkey クラスターで、CloudWatch が OpenTelemetry をサポートする全リージョンで利用可能。ElastiCache 側からの追加課金はなく、詳細監視で選択した OpenTelemetry メトリクス、CloudWatch アラーム、PromQL API クエリについては CloudWatch の課金が適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: Valkey（node ベース）を使うアプリケーションオーナー、SRE/DevOps、監視・オブザーバビリティチーム
  • 利用シーン: ノードごとの接続上限監視、メモリ枯渇予測、エラー種別別のインシデント解析、短時間のレイテンシスパイク検出、Grafana/CloudWatch での PromQL ベースのダッシュボード作成
  • 運用効果: 高解像度（15秒）で短時間イベントを検出して迅速なトリアージが可能。PromQL の既存スキル資産を活かして監視ルールやダッシュボードを移行・共用できる。詳細監視は必要なメトリクスだけ選んでコストと診断深度を両立できる。

技術的な注意点 ​

  • IAM権限: コンソールで詳細監視を有効化するには ElastiCache のリソース変更権限（例: elasticache:ModifyCacheCluster / elasticache:ModifyReplicationGroup に相当する権限）と、CloudWatch のメトリクス閲覧・クエリ実行権限（cloudwatch:GetMetricData, cloudwatch:ListMetrics, cloudwatch:QueryMetrics など）が必要です。必要に応じて CloudWatch アラーム作成権限も付与してください。
  • リージョン制限: CloudWatch が OpenTelemetry をサポートするリージョンで利用可能です。利用前に該当リージョンの CloudWatch の OpenTelemetry サポート状況を確認してください。
  • コスト: ElastiCache 側に追加料金は発生しませんが、Detailed モードで選択した OpenTelemetry メトリクスの収集（15秒間隔）、CloudWatch 上のアラーム、PromQL API クエリには CloudWatch の課金が適用されます。高頻度のメトリクス選択や多数の PromQL クエリはコスト増加要因になります。
  • メトリクス解像度: Standard は 60 秒、Detailed は 15 秒の解像度です。アラート閾値や集計ウィンドウを 15 秒解像度に合わせて見直すことを推奨します。
  • 対象制限: 現時点では node ベースの Valkey クラスターが対象です。その他のエンジン/構成は対象外の可能性があるため事前確認してください。
  • 運用上の注意: 高頻度メトリクスや多数のアラームはアラートノイズを増やすため、必要なメトリクスに絞って有効化し、集計/ダウンレベル化を検討してください。

参考情報 ​

[Security Hub] GuardDuty Runtime Monitoring is now included in the AWS Security Hub Threat Analytics plan ​

概要 ​

Amazon GuardDutyのRuntime Monitoring（OS・ネットワーク・ファイル活動を監視する機能）が、AWS Security HubのThreat Analyticsプランの一部として請求対象に統合されます。これにより、Runtime Monitoringの利用料金が個別のGuardDuty請求ではなく、Security Hubの単一の使用項目として集約されます。

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

GuardDuty Runtime Monitoringは、Amazon EC2インスタンス、Amazon EKSクラスター、Amazon ECS（Fargate）上のコンテナ/ホストでのOS・ネットワーク・ファイル活動を解析し、コンテナエスケープ、権限昇格、クリプトマイニングなどのランタイム脅威を検出します。本変更により、該当するアカウントかつリージョンでSecurity Hubが有効であれば、Runtime Monitoringの使用量は個別のGuardDuty請求ではなく、AWS Security Hubの請求項目として計上されます。請求はEC2/EKS/ECS on Fargateを跨いだ単一の使用タイプとしてメーターされます。検出カバレッジ、発見の種類、GuardDutyのエージェント構成等には変更はなく、再設定は不要です。なお、Threat Analyticsプランの無料トライアルはSecurity Hub Essentialsの無料トライアルとは別扱いであり、本件で新たなRuntime Monitoringの無料トライアルが追加されるわけではありません。請求影響の確認はAWS Cost ExplorerやSecurity Hubの使用状況ページで可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ運用チーム、クラウドインフラ/プラットフォームエンジニア、コスト管理者
  • 利用シーン: EC2/EKS/ECS（Fargate）上でのランタイム脅威検出（コンテナエスケープ、権限昇格、クリプトマイニングなど）の監視とアラート運用
  • 運用効果: 請求がSecurity Hubに集約されることでコスト管理・課金配分（チャージバック）が簡素化される。検出動作やエージェント動作は変わらないため、既存のセキュリティワークフローはそのまま利用可能
  • 請求への影響: Cost and Usageレポートやタグベースの課金配分ルールを見直す必要がある（リソース別のGuardDuty行がSecurity Hubの単一行に変わる）
  • コスト最適化: Security Hubの単一メーターに統合されることで従来のリソース別請求と比較して請求表示が変わるため、予算アラートやコストアロケーションの調整が必要

技術的な注意点 ​

  • IAM権限: Security HubおよびCost Explorer/請求情報を参照するための適切なIAM権限が必要（例: securityhub:、ce:、cur:*、billing:ViewBilling 等の閲覧権限の確認）
  • リージョン制限: Security Hubが利用可能なリージョンでのみ請求の集約が行われる。未対応リージョンでは従来通りGuardDutyでの個別課金となるため、リージョンごとにSecurity Hubの有効化状況を確認すること
  • コスト: Runtime Monitoringの総コスト自体や検出内容は変わらないが、請求カテゴリがSecurity Hubへ移るためコスト集計・タグ付け・チャージバックの設定を更新する必要がある。無料トライアルは別扱いのため、無料枠適用状況を確認すること
  • 設定/互換性: 検出ルール・エージェント構成・発見（finding）の形式は変更なし。既存のGuardDutyエージェントやRuntime Monitoringの設定を再構成する必要はない
  • 運用上の確認点: アカウントとリージョン単位でSecurity Hubが有効化されているか確認する（未有効だと引き続きGuardDutyで個別請求される）。Cost ExplorerやSecurity Hub使用状況ページで請求表示と使用量が期待どおりに移行しているか検証すること

参考情報 ​

[Support] AWS Well-Architected Agent is now available in preview ​

概要 ​

AWS Well-Architected Agent（プレビュー）は、AIを活用して既存のTrusted Advisor / Well-Architected Toolの次世代機能を提供するサービスです。コスト・セキュリティ・パフォーマンス・信頼性の観点で環境を解析し、ビジネス目標に基づいて優先順位付けされた自動化対応可能な推奨を提示します。

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

主な機能と挙動:

  • AI駆動の解析エンジンがクラウド監視データ（メトリクス）、アプリケーションのトポロジー、構成（IaCテンプレート含む）を相関させ、Well‑Architectedのベストプラクティスに照らしてギャップと改善案を検出します。
  • ビジネスゴール（例：コスト最適化／信頼性優先）を定義すると、それに応じて影響度と実行工数で推奨を優先化し、リソース／アプリケーション／アーキテクチャ単位で提示します。
  • IaC解析: Terraform、AWS CDK、CloudFormationテンプレートを解析し、ギャップ検出と合わせて「自動化可能なコード差分（IaC修正）」を提示します。
  • 自動化対応の出力: 推奨はSSMランブック、実行可能なCLIスクリプト、コンソールのガイド付き手順などとして提供され、手動対応から自動適用まで移行できるようにします。
  • 例: 信頼性を重視するワークロードに対しては、マルチAZフェイルオーバー追加の推奨とともに、その構成変更を自動化するSSMランブック、想定されるコスト・性能への横断的影響分析を先に示します。
  • 配布・利用形態: AWS Support経由で提供され、プレビュー時点ではUS East (N. Virginia)、US East (Ohio)、US West (Oregon) のリージョンで利用可能。任意のAWS商用リージョンからワークロードをオンボード可能です。
  • 注意: プレビューのため機能や挙動は将来変更される可能性があり、利用にはAWS Supportプランが必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアーキテクト、SRE、プラットフォーム/運用チーム、DevOpsエンジニア
  • 利用シーン: インフラストラクチャの総合的な健全性レビュー（コスト最適化、セキュリティ改善、性能チューニング、信頼性向上）の自動化と優先順位付け
  • 運用効果: 手動調査の削減、ビジネス目標に基づく影響度優先の改善計画策定、IaC修正の自動化で修復時間（MTTR）と人的ミスを低減

技術的な注意点 ​

  • IAM権限: エージェントがリソース情報・メトリクス・ログ・IaCテンプレートにアクセスできるようなリード権限が必要。SSMランブックを実行する場合は追加の実行権限（SSM:SendCommand 等）が必要になる可能性があります。
  • リージョン制限: 管理コンソール/サービスのアクセスは US East (N. Virginia)、US East (Ohio)、US West (Oregon) の各リージョンで提供。ワークロードのオンボード自体は任意のAWS商用リージョンから可能です。
  • コスト: サービス利用にはAWS Supportプランが必要（有料）。さらに、提示された自動化アクションの実行や追加リソース（例: マルチAZ構成による追加インスタンス・データ転送など）により別途課金が発生する可能性があります。
  • データ収集・プライバシー: エージェントはアカウント内の構成情報、メトリクス、IaC等を解析します。機密情報の取り扱いやログの送信先についてはプレビュー段階でのドキュメントを確認してください。
  • プレビュー注意点: プレビュー機能は変更される可能性があり、SLAや正式サポート条件は将来の一般提供時に更新される可能性があります。
  • 互換性: Terraform、CloudFormation、CDK を解析対象としてサポート。利用しているIaCのバージョンやモジュール構成によっては解析結果に差異が出る場合があります。

参考情報 ​

[Redshift] Amazon Redshift now supports cross-Region queries for your data lake ​

概要 ​

Amazon Redshiftが異なるリージョンのAmazon S3上にあるデータレイクテーブルを直接クエリできるようになりました。Enhanced VPC routingを併用すると、S3とRedshift間のデータレイククエリトラフィックが自分のVPC内に留まり、パブリックネットワークを経由しません。

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

新機能は以下を提供します。

  • クロスリージョンクエリ: Redshiftから別リージョンのS3にあるデータレイクテーブルをコピーやレプリケーションなしで直接クエリ可能。グローバル分析やリージョン別レジデンシ要件を満たすユースケースに有用です。
  • Enhanced VPC routingとの組合せ: 統合データレイククエリエンジンがクラスターのコンピュート上で動作するため、S3とRedshift間のデータ転送はEnhanced VPC routingを有効化すると自分のVPC内（パブリックネットワークを経由しない経路）で行われます。
  • 対応環境: 統合データレイククエリエンジンは、RA（Provisioned）およびServerlessクラスターが利用可能なすべてのリージョンで使用可能。クロスリーンクエリ実行時は標準のデータ転送料金が発生します。
  • セキュリティ/コンプライアンス: 金融、医療、政府など規制業界での利用に向く設計で、ネットワーク境界内でクエリを完結させやすくなっています。
  • 運用面: データを別リージョンへ複製する運用コストや手間を削減できる一方、リージョン間レイテンシやデータ転送料金がパフォーマンス/コストに影響します。

影響範囲・利用シーン ​

  • 対象ユーザー: グローバルに分散したデータを扱うデータエンジニア、データ分析者、SRE/セキュリティチーム
  • 利用シーン: 他リージョンに格納されたS3データをそのまま集計・分析（グローバルレポーティング、リージョン別データの横断集計、レジデンシ要件のあるデータ参照）
  • 運用効果: データの複製/同期を減らして運用負荷を軽減、Enhanced VPC routingによりネットワーク境界内での処理を実現してコンプライアンス要件を満たしやすくなる

技術的な注意点 ​

  • IAM権限: RedshiftがクロスリージョンのS3バケットにアクセスできるように、適切なIAMロールとS3バケットポリシーを設定してください（バケットのリージョンをまたぐアクセス許可が必要）。
  • リージョン制限: 機能は統合データレイククエリエンジンが利用可能なRA（Provisioned）およびServerlessクラスターが提供されているリージョンで使用可能。利用前に対象リージョンのサポート状況を確認してください。
  • コスト: クロスリージョンでのデータ転送には標準のデータ転送料金が発生します。大規模クエリや頻繁なアクセスではコストが増加するため見積りを行ってください。
  • ネットワーク設定: Enhanced VPC routingを有効化する必要があります。VPCエンドポイントやルート、サブネット、セキュリティグループ等のネットワーク設定とアクセス許可を確認してください。パブリック経路を回避する設定が正しく反映されているか検証が必要です。
  • パフォーマンス: リージョン間のレイテンシと帯域がクエリ性能に影響します。遅延が気になる場合はクラスタのサイズ/スケーリングやワークロード設計（フィルタリングやパーティションプルーニング）を検討してください。
  • 互換性/制限: 統合データレイククエリエンジンで動作するクエリに適用されます。特定のSQL機能や外部テーブルの制限がある可能性があるため、詳細は公式ドキュメントで確認してください。

参考情報 ​

[DynamoDB] Amazon DynamoDB introduces filtered export to Amazon S3 ​

概要 ​

Amazon DynamoDBがS3へのテーブルエクスポートで「フィルタ指定（filtered export）」をサポートしました。キー条件・フィルタ・プロジェクションを組み合わせて、出力するアイテム/属性を厳密に絞り込めます。

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

この新機能により、DynamoDBのテーブルデータをAmazon S3へエクスポートする際に、エクスポート対象を精密に指定できます。指定できる要素は主に以下の通りです。

  • Key condition expression: キー属性（パーティションキー、必要に応じてソートキー）に対する条件式を用いてエクスポート対象のアイテム範囲を絞ります。
  • Filter expression: 任意の属性に対するフィルタ式で、キー条件で選ばれたアイテムのうちさらに条件を満たすものだけを出力します。
  • Projection expression: 出力する属性（カラム）を明示的に指定し、エクスポートされるデータ量を削減できます。 このフィルタ機能はフルエクスポートと増分（time-windowベース）の両方で利用可能で、出力結果は指定したアイテムと属性のみになります。用途としては、細かいデータ復旧（特定キー範囲の復元）、アカウント間でデータの一部を移動、分析用に必要なスライスだけを抽出してコンプライアンス要件を満たすなどが挙げられます。提供状況は全リージョン（AWS GovCloud (US) を除く）で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、SRE/運用チーム、セキュリティ/コンプライアンス担当者
  • 利用シーンまたは効果: 必要なアイテム/属性だけをS3へ出力することで、データ共有・増分バックアップ・分析用データ準備・部分的なデータ復旧が容易になる
  • 運用効果: 不要データの除外によりS3保管コストと処理時間を削減し、コンプライアンスや最小権限ポリシーに沿ったデータ抽出が可能になる

技術的な注意点 ​

  • IAM権限: エクスポート実行にはDynamoDBとS3に対する適切なIAM権限（および場合によってはクロスアカウントロールの許可）が必要です。サービスがS3へ書き込む場合のロール/バケットポリシーを用意してください。
  • リージョン制限: ほとんどのAWSリージョンで利用可能ですが、AWS GovCloud (US) リージョンでは未対応です。
  • コスト: エクスポート操作自体の料金とS3の保存/リクエストコストが発生します。Projectionで出力データ量を削減するとS3側コストの低減につながります。
  • キー条件の制約: Key condition expressionはキー属性（パーティションキー／ソートキー）に対する式である必要があります。任意属性だけでキー条件を代替することはできません。必要な範囲指定を設計時に確認してください。
  • S3設定と暗号化: 出力先バケットの暗号化（SSE-S3 / SSE-KMS）設定やバケットポリシー、ライフサイクルルールを事前に検討してください。SSE-KMSを使う場合はKMSキーのアクセス権も必要です。
  • 増分エクスポート: 増分エクスポートは時間ウィンドウに基づくエクスポートをサポートします。時間範囲の指定方法や期待する変更のキャプチャ方法を運用設計で確認してください。

参考情報 ​

[DynamoDB] Amazon DynamoDB Accelerator (DAX) is now available in additional Regions ​

概要 ​

Amazon DynamoDB Accelerator (DAX) が17の追加リージョンで利用可能になりました。これにより、より多くの地域でDynamoDBの読み取りをマイクロ秒レイテンシに高速化でき、ローカルなデータ居住性や低遅延要件に対応できます。

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

DAXはAmazon DynamoDB向けのフルマネージドなインメモリキャッシュサービスで、単一桁ミリ秒からマイクロ秒レベルへの最大10倍の読み取りパフォーマンス向上を提供します。今回の拡張で、Asia Pacific（香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ニュージーランド、大阪、ソウル、台北、タイ）、Canada West（カルガリー）、Europe（ミラノ、チューリッヒ）、Israel（テルアビブ）、Mexico（セントラル）、およびAWS GovCloud（US-East、US-West）の計17リージョンにDAXが展開されました。DAXはDynamoDB API互換であり、アプリケーション側のコード変更は最小限で済みます。フルマネージド運用（自動パッチ適用、自動フェイルオーバー、スケーリング）を提供し、読み取り集中型・バースティなワークロード（リアルタイム入札、ゲームのリーダーボード、EC製品カタログ等）でDynamoDBへの読み取り負荷をオフロードします。DAXクラスターはリージョン内で動作するため、各リージョンでローカルな低遅延アクセスやデータ居住性の要件を満たせます。

影響範囲・利用シーン ​

  • 対象ユーザー: DynamoDBを使用しているアプリケーション開発者、SRE/運用チーム、リアルタイム処理を必要とするサービスオーナー
  • 利用シーン: 読み取り集中かつ低遅延が求められるワークロード（リアルタイム入札、ゲームリーダーボード、商品カタログ、セッション情報の高速参照など）
  • 運用効果: 読み取りレイテンシが単一桁ミリ秒からマイクロ秒に短縮され、DynamoDBテーブルへの読み取り負荷が軽減されることでスループット要件・コストの最適化やユーザ体験改善が期待できる

技術的な注意点 ​

  • IAM権限: DAXクラスターの作成・管理には対応するIAM権限が必要です。クライアント側もDAXアクセス権限を適切に設定してください。
  • リージョン制限: 新たに17リージョンで利用可能になりましたが、すべてのリージョンで利用可能になったわけではありません。DAXはリージョン内のサービスであり、リージョン間の自動レプリケーションは行いません。グローバルな低遅延要件がある場合は、各リージョンにクラスターを配置する必要があります。
  • ネットワーク: DAXクラスターはVPC内で動作します。クライアントからのネットワーク接続（同一VPC、VPCピアリング、適切なセキュリティグループ設定等）を確保してください。
  • 整合性とAPI互換性: DAXはDynamoDB API互換ですが、すべてのAPIが加速されるわけではありません。一般にイベントュアル整合性の読み取りを高速化する用途に最適で、強い整合性の読み取りやトランザクション（TransactWrite/TransactGet）などはサポートが制限される場合があります。実運用前に必須APIの互換性を検証してください。
  • 運用特性: 自動フェイルオーバーやスケーリングはありますが、キャッシュのウォームアップやコールドスタート時の挙動、キャッシュヒット率に依存した効果差を考慮してください。
  • コスト: DAXノードはインスタンスタイプ単位で料金が発生します（稼働時間ベース）。追加で通信費や運用に伴うコストが発生するため、キャッシュ導入によるDynamoDBのRCU/WCU削減とDAX費用を比較して採用を判断してください。
  • テスト推奨: 本番導入前にステージング環境でキャッシュヒット率、レイテンシ改善、コスト影響を測定してください。

参考情報 ​

[Govcloud Us] Amazon GuardDuty now supports centralized management using AWS Organizations declarative policies ​

概要 ​

Amazon GuardDutyがAWS Organizationsの宣言型ポリシーに対応しました。これにより、組織全体のアカウントとリージョンに対して中央でGuardDutyの有効化設定を一元管理・適用できます。

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

新機能では、AWS Organizationsの宣言型（organization）ポリシーとしてGuardDutyの有効化設定を定義できるようになりました。委任管理者（delegated administrator）アカウントから組織ルート、OU、個別アカウント単位でポリシーを作成し、既存のアカウントに適用するとともに、新規アカウント参加時にも自動的にその設定が維持されます。ポリシーは「全リージョン共通のデフォルト設定」と、特定リージョン向けの上書き設定（per-Region override）をサポートします。ポリシーによって有効化された設定はGuardDutyコンソールやAPIからは上書きできません（宣言型の整合性を維持）。機能は全ての商用リージョンとAWS GovCloud (US) リージョンで利用可能です。導入手順は、委任管理者に必要なGuardDutyポリシー管理権限を付与し、GuardDutyコンソールの「Organization policies」から設定するか、AWS OrganizationsのAPIを使ってプログラム的に作成します。これにより、従来のように各リージョンで個別に有効化設定を行う必要がなくなり、設定ドリフトや抜け漏れのリスクを低減できます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/ガバナンスチーム、クラウドセキュリティエンジニア、SRE/運用チーム
  • 利用シーン: マルチアカウント・マルチリージョン環境でGuardDutyの有効化を組織単位で一括適用・維持する場合（新規アカウント参加時の自動適用を含む）
  • 運用効果: リージョンやアカウント間の設定ドリフトを防ぎ、全社的な脅威検出カバレッジの一貫性を確保できる（手動設定の工数削減と誤設定防止）
  • コンプライアンス/監査: セキュリティ基準に沿ったGuardDuty有効化状態をポリシーとして証跡化でき、監査対応が容易になる

技術的な注意点 ​

  • IAM権限: 委任管理者にGuardDutyポリシー管理を行うための適切な権限を付与する必要があります（OrganizationsおよびGuardDuty関連の権限）
  • ポリシーの適用範囲: ポリシーは組織ルート、OU、個別アカウントに適用可能で、既存アカウントと新規参加アカウントの両方に自動適用されます
  • 上書き不可: ポリシーで設定した有効化状態はGuardDutyコンソール/APIから上書きできません（宣言型のため）
  • リージョン制限: 商用リージョンとAWS GovCloud (US)でサポートされています。特定リージョンの可用性やガバメントクラウドの対応状況はリージョン毎に確認してください
  • コスト: 組織内の多数アカウント／多数リージョンでGuardDutyを有効化すると、検出とログ処理に伴う料金が発生します。事前に利用範囲とコスト推計を行ってください
  • 導入方法: GuardDutyコンソールの「Organization policies」から設定するか、AWS OrganizationsのAPIで宣言型ポリシーを作成できます
  • 注意点: ポリシーによる設定は宣言的に強制されるため、特定アカウント単位での一時的な例外対応は設計段階で考慮する必要があります

参考情報 ​

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

Copyright © 2026