AWS What's New Digest

Appearance

2026年08月21日 ​

[Simple Email Service] Amazon SES now supports open and click tracking override parameters ​

概要 ​

Amazon SESがSendEmailおよびSendBulkEmail APIに対してオープン（開封）トラッキングとクリックトラッキングのオーバーライドパラメータをサポートしました。APIコール単位でトラッキングの有効/無効を指定でき、構成セットを組み合わせて管理する必要がなくなります。

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

技術的には、SendEmailおよびSendBulkEmailの送信リクエストに対してオープントラッキングとクリックトラッキングの設定を直接指定するパラメータが追加されました。このオーバーライドはリクエスト単位で適用され、関連付けられた構成セット(Configuration Set)に定義されたトラッキング動作より優先されます。従来は各トラッキング設定の組み合わせごとに別々の構成セットを作成・管理する必要がありましたが、今回の機能によりその管理負荷が軽減されます。特に、受信者ごとの同意（例：GDPRやCNIL等に基づく追跡同意）を尊重する必要があるケースで、個々の送信に応じたトラッキング制御が容易になります。クリックトラッキングは通常リンクの書き換え（リダイレクト）を伴い、オープントラッキングは埋め込みピクセルで計測されるため、これらを無効にすると該当するクリック/開封イベントが収集されなくなります。コストは追加されず、Amazon SESが提供されるすべてのリージョンで利用可能です。SendBulkEmailについては、バルク送信の各送信エントリ単位でオーバーライドを指定できる（受信者レベルの同意に応じた制御が可能）ようになっています。

影響範囲・利用シーン ​

  • 対象ユーザー: メール送信アプリケーション開発者、マーケター、SRE/運用チーム
  • 利用シーン: 受信者ごとのトラッキング同意を尊重した個別送信（GDPR/CNIL対応）や、一時的にトラッキングを無効にしたいテスト送信
  • 運用効果: 構成セットの数を減らせるため設定管理が簡素化され、受信者同意に基づく細かな制御が可能になりコンプライアンス対応が容易化される

技術的な注意点 ​

  • IAM権限: ses:SendEmail / ses:SendBulkEmail の実行権限および参照する構成セットを利用する場合はそれらを参照する権限を確認してください
  • リージョン制限: 追加費用なしで、Amazon SESが提供されるすべてのリージョンで利用可能です
  • コスト: この機能自体に追加料金は発生しません。ただしトラッキングを無効にすると開封・クリック計測データが減るため、分析やレポートへの影響を考慮してください
  • 既存構成への影響: オーバーライドは構成セットの設定より優先されます。既存の構成セットを変更する必要はありませんが、優先順を理解して運用設計してください
  • 配信と計測の挙動: クリックトラッキングはリンク書き換え（リダイレクト）を行い、オープントラッキングは埋め込みピクセルで計測します。いずれも無効化すると対応するイベントは収集されません
  • SDK/CLI対応: 最新のSES API/SDKでオーバーライド用パラメータが利用可能です。ご利用の言語用SDKとCLIのバージョンを確認してください

参考情報 ​

[Local Zones] AWS announces the general availability of a new AWS Local Zone in Las Vegas, Nevada ​

概要 ​

AWSはネバダ州ラスベガスに新しいAWS Local Zone（us-west-2-las-2a）を一般提供（GA）しました。これによりラスベガス近傍のユーザーへ単一桁ミリ秒のレイテンシでコンピュートやストレージなどの主要サービスを提供できます。

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

今回のラスベガスLocal Zoneは一般提供となり、以下のリソース/サービスをサポートします：Amazon EC2（C7i、M7i、R7i、C8gnインスタンスタイプ）、Amazon EBSボリューム（gp3、gp2、io1、sc1、st1）、Amazon ECS、Amazon EKS、Application Load Balancer、AWS Direct Connect。AWS Local ZonesはAWSリージョンの機能を大都市圏に拡張するインフラ展開で、リージョンと同じAPI/ツールを使いながらエッジ近傍での低レイテンシ実行、データ居住要件対応、AI/ML推論ワークロードの近接実行、レガシーアプリケーションの移行・近代化を支援します。ラスベガスのLocal Zoneは、AWS Global Viewの「Regions and Zones」タブから有効化するか、ModifyAvailabilityZoneGroup APIを使って有効化できます。料金はLocal Zones専用の課金体系が適用されるため、詳細はAWS Local Zonesの料金ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: エッジ近傍での低レイテンシが必要なウェブ/ゲーム運営者、リアルタイム推論を行うMLエンジニア、メディア処理やライブ配信を行う開発者・SRE
  • 利用シーン: ゲームのマッチメイキングやリアルタイム通信、エンドユーザー向けの低遅延API/ウェブアプリ、オンプレミスやコロケ環境とのハイブリッド接続（Direct Connect）を利用したデータセンター近傍処理、エッジでのML推論
  • 運用効果: レイテンシが単一桁ミリ秒へ改善されユーザー体験向上、データ居住要件の遵守が容易化、遅延に敏感なワークロードのクラウド移行・近代化が加速

技術的な注意点 ​

  • 有効化方法: AWS Global View の Regions and Zones タブから us-west-2-las-2a を有効化、または ModifyAvailabilityZoneGroup API を使用して有効化します
  • サポートサービス/制限: 提示されたインスタンス・EBSタイプ・ECS/EKS・ALB・Direct Connect は利用可能ですが、RDS、Lambdaなど他サービスはLocal Zoneで未提供または制限されている場合があるため事前確認が必要です
  • IAM権限: Local Zone を有効化・操作するには該当するEC2/Organizationsの権限（ModifyAvailabilityZoneGroup 等）が必要です。アカウント設定や組織ポリシーが影響するため権限を確認してください
  • リージョン制限: ラスベガスLocal Zoneは us-west-2 に紐づくローカルゾーン（us-west-2-las-2a）です。Local Zone は親リージョンと同一アカウントで有効化が必要で、全リージョンで自動的に利用可能になるわけではありません
  • コスト: Local Zone 専用の料金が適用されます。インスタンス時間、EBS、データ転送料金（Local Zone ↔ リージョン間やインターネット転送）など追加課金が発生する可能性があるため料金ページで確認してください
  • キャパシティとクォータ: Local Zone は初期キャパシティやインスタンスタイプごとの割当に制限がある場合があります。大規模導入前にクォータ増加申請や事前検証を推奨します
  • ネットワーク/接続: Direct Connect を利用する場合はローカル接続設定やVPCルーティング、セキュリティグループ／NACLの確認が必要です。ALBやEKSなどのネットワーク構成もリージョンと整合させてください

参考情報 ​

[Timestream] Amazon Timestream for InfluxDB now supports customer managed keys ​

概要 ​

Amazon Timestream for InfluxDBが、データの保存時暗号化においてAWS KMSのカスタマー管理キー（CMK）をサポートしました。InfluxDB 2のデータベース、Read Replica、InfluxDB 3クラスタ作成時に対称KMSキーを指定してストレージを暗号化できます。

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

ユーザーはデータベースリソースを作成する際に同一アカウントかつ同一リージョンに存在する対称（symmetric）AWS KMSキーを選択します。選択したキーはInfluxDB 2インスタンス、InfluxDB 2のRead Replica、およびInfluxDB 3クラスタの基盤ストレージの暗号化に使用され、リソース作成後にキーを変更することはできません。本機能はAWS Management Console、AWS CLI、Timestream for InfluxDB APIから利用可能で、Timestream for InfluxDBが提供されているすべてのリージョンでサポートされます。Timestream for InfluxDB自体への追加料金は発生しませんが、標準のAWS KMS料金が適用されます。運用上は、KMSキーのポリシーや権限・ローテーション・削除などがデータアクセスに影響するため事前に設計・確認が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ重視のクラウドアーキテクト、プラットフォーム/インフラ運用者、コンプライアンス担当者
  • 利用シーン: 機密性の高い時系列データを保持するInfluxDB 2/3のインスタンスやRead Replicaで、組織管理のKMSキーによる暗号鍵ライフサイクル管理（ポリシー・ローテーション・監査）を適用したい場合
  • 運用効果: 組織が管理するCMKで暗号化することで、鍵ポリシー・アクセス制御・監査ログを一元管理でき、コンプライアンス対応やキー消去によるデータアクセス制御が容易になる

技術的な注意点 ​

  • IAM権限: KMSキーを指定するには、キーを参照できるIAM権限（kms:DescribeKey、kms:Encrypt/kms:GenerateDataKey 等）と、Timestreamがそのキーを使用できるようにKMSキーのキー ポリシーまたは付与(grant)でTimestreamの利用を許可する必要があります。具体的なサービスプリンシパルやロールをキー ポリシーで許可してください。
  • リージョン制限: 指定するKMSキーはデータベースリソースと同一AWSアカウントかつ同一リージョンに存在する必要があります。クロスアカウント／クロスリージョンのKMSキーは利用できません。
  • キーの種類と不可変性: サポートされるのは対称（AWS KMSの対称CMK）です。リソース作成後にCMKを変更することはできません。削除予定や無効化されたキーが存在するとデータ復号や運用に影響します。
  • キー管理・ローテーション: 自動ローテーションを有効にしている場合でも、KMSの仕様に従って運用されます。キーの削除・無効化・削除保留（pending deletion）はデータアクセスを阻害するため注意してください。
  • 課金: Timestream for InfluxDB側の追加料金はありませんが、KMSの標準料金（APIリクエストやキー管理料金等）が発生します。
  • 利用方法: キーはコンソール／AWS CLI／APIでリソース作成時に指定します。既存リソースへ適用するためのキー変更はサポートされていません。
  • 互換性: 対象はInfluxDB 2データベースインスタンス、InfluxDB 2 Read Replica、InfluxDB 3クラスタです。特定リージョンでのサービス未提供は適用外です。

参考情報 ​

[Ec2] Amazon EC2 P6-B300 instances are now available in the Asia Pacific (Seoul) Region ​

概要 ​

Amazon EC2の新しいGPUインスタンス「P6‑B300」がアジアパシフィック（ソウル）リージョンで利用可能になりました。大規模なトリリオンパラメータ級の基盤モデルやLLMの学習・推論向けに設計された高帯域・大容量メモリのインスタンスです。

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

P6‑B300インスタンスは8基のNVIDIA Blackwell Ultra GPUを搭載し、GPU側合計2.1 TBの高帯域メモリ、システムメモリ4 TB、EFA（Elastic Fabric Adapter）で最大6.4 Tbps、専用ENAスループット300 Gbpsを提供します。現行提供サイズはp6-b300.48xlargeのみです。P6‑B200世代比でネットワーク帯域が2倍、GPUメモリとFP4（スパースなし）時のTFLOPSがそれぞれ1.5倍となり、より大きなモデルを1インスタンスで収められることや、学習・推論時のトークンスループット向上、トレーニング時間短縮が期待できます。現在利用可能なリージョンは米国（オレゴン、バージニア、AWS GovCloud US-East）とアジアパシフィック（ソウル）です。これらインスタンスは高性能ネットワーク（EFA/ENA）と最新のGPUドライバ・ソフトウェア（CUDA、NVIDIAドライバ、MPI/libfabric等）による最適化が前提となります。

影響範囲・利用シーン ​

  • 対象ユーザー: 大規模なトランスフォーマーモデルやトリリオンパラメータ級の基盤モデルを開発・学習・デプロイする研究者、MLエンジニア、AIスタートアップ
  • 利用シーン: 大規模モデルの分散学習（モデル並列・データ並列の低減）、高スループットなバッチ推論、ファインチューニングや大規模データセットのトレーニング
  • 運用効果: 1インスタンスでより大きなモデルを収容できるため通信オーバーヘッドと実装複雑性が減少し、ネットワークとGPUメモリの増加によるトレーニング時間短縮およびトークンスループットの向上が見込めます

技術的な注意点 ​

  • リージョン制限: 提供リージョンは US West (Oregon)、AWS GovCloud (US‑East)、US East (N. Virginia)、および Asia Pacific (Seoul) に限定されています
  • インスタンスサイズ: 現時点では p6-b300.48xlarge のみ提供されています
  • ドライバ/AMI: NVIDIAドライバ、CUDA、各種並列通信ライブラリ（libfabric、Open MPI等）、およびENA/EFAドライバが必要です。対応済みのGPU最適化AMIの利用を推奨します
  • EFA/ネットワーク: 高性能EFAを活かすためにクラスタ配置（cluster placement group）や適切なネットワーク設定が必要です。ENAは専用の300 Gbpsスループットを持ちます
  • クォータ/プロビジョニング: 大型GPUインスタンスはアカウントのクォータ制限を受けるため、事前にサービスクォータの引き上げ申請を行ってください
  • コスト: 高性能インスタンスのため時間あたりの料金は高くなります。スポットやSavings Plansの利用でコスト最適化を検討してください
  • セキュリティ/IAM権限: インスタンス起動やEFA設定には通常のEC2起動権限に加え、必要に応じてVPC/ENI関連の権限が必要です
  • 互換性: 一部旧ソフトウェアやカーネルでは最新GPUドライバやEFAがサポートされない可能性があるため、ベースAMIとカーネルの互換性を確認してください

参考情報 ​

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

概要 ​

Amazon EKSがクラスタの証明書署名局（CA）ローテーションを自動化されたライフサイクル管理でサポート開始。期限切れ前のCA更新を管理し、切替作業中の安全策やロールバック機能を提供します。

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

Amazon EKSはクラスタごとのKubernetes APIを保護するCAのローテーション機能を提供します。2018年以降に作成されたEKSクラスタのCAは有効期限が10年で、期限が近づいているためローテーションが必要です。本機能はEKS側と顧客側の共有責任モデルで動作し、EKSはローテーションのライフサイクル管理とAWS管理コンポーネントの後継CAへの信頼設定を自動で行います。顧客はワーカーノードの差替えや外部クライアント（kubectl、CI/CD、監視・管理ツール等）が後継CAを信頼するよう更新する責任があります。EKS Auto ModeインスタンスおよびAWS FargateノードはAWS側で自動更新されます。運用を支援する自動的な安全策として、期限前の事前通知、顧客が後継CAを作成しない場合の後継CA自動追加、顧客が指定したスケジュールでの自動有効化（顧客が有効化しない場合）があります。問題発生時に以前のCAへ戻すロールバック機能も提供されます。追加料金はなく、全ての商用AWSリージョンで利用可能です。操作はAWS CLI、EKS API、CloudFormation、AWS マネジメントコンソールで実行できます。

影響範囲・利用シーン ​

  • 対象ユーザー: EKSクラスタの運用担当者、SRE、セキュリティチーム、CI/CDや監視システムを運用する開発チーム
  • 利用シーンまたは効果: CAの有効期限到来前に計画的にCAを更新することでAPIサーバの証明書失効によるサービス停止を防止
  • 運用効果: 自動通知／自動追加／自動有効化といった安全策により手動作業やミスを減らし、ロールバック機能でリスクを低減できる

技術的な注意点 ​

  • IAM権限: クラスタの更新操作を実行できるEKS管理権限（Describe/Update等）を持つIAMロール/ユーザが必要です。具体的なAPI呼び出し権限を事前に確認してください。
  • リージョン制限: 公表では「全ての商用AWSリージョン」で利用可能とされていますが、利用前に対象リージョンで有効か確認してください。
  • コスト: CAローテーション自体に追加料金は発生しません。ただし、ワーカーノードを置換（再作成/ローリングアップデート）する場合はEC2/EKSリソースの追加コストや一時的な容量増が発生する可能性があります。
  • ノード／ワーカーの扱い: EKS Auto ModeインスタンスとAWS Fargateは自動更新されますが、セルフマネージドノードや一部のマネージドノードは顧客側で置換（AMI更新やローリング再起動）する必要があるため、事前にノードグループのタイプを確認してください。
  • クライアント互換性: kubectl、kubeconfig、CI/CD、監視ツール、カスタムクライアント等、APIサーバ証明書を検証する外部クライアントは後継CAを信頼するよう更新する必要があります。証明書ピンニングや組み込みCAバンドルを使っているクライアントは特に注意してください。
  • 実行タイミングと自動化: 事前通知を受け取ったらテスト環境で後継CAの受け入れ検証を行い、ロールアウトスケジュール（手動有効化または自動有効化）を確認してください。自動有効化が有効な場合、指定の猶予期間を過ぎるとAWS側で有効化されます。
  • ロールバックの制限: ロールバック機能は提供されますが、実行可能な時間帯や条件（後継CAの有効化状態や既に交換済みのノード数等）に制約がある可能性があるため、ロールバック手順と制限を事前に確認してください。
  • 運用ツール: ローテーション操作はAWS CLI、EKS API、CloudFormation、コンソールで実行可能です。自動化パイプラインに組み込む場合はAPI/CLIを用いた検証・実行フローを準備してください。

参考情報 ​

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

概要 ​

Amazon CloudFrontがAmazon S3のMulti-Region Access Points（MRAP）をオリジンとして利用する際に、CloudFront Origin Access Control（OAC）でネイティブにリクエスト署名（SigV4a）できるようになりました。これによりカスタムのLambda@Edgeで署名ヘッダーを生成する必要がなくなり、グローバルなキャッシュミス復旧性能とアクセス制御が向上します。

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

今回の更新で、CloudFrontはS3 MRAPをオリジンに設定した場合に、OACを使ってCloudFront側で自動的に署名（Asymmetric Signature Version 4 / SigV4a）したリクエストをMRAPに送信できるようになりました。S3 MRAPは単一のグローバルエンドポイントを提供し、キャッシュミス時に利用者に最も近いレプリケート済みバケットへ自動でルーティングするため、レイテンシの改善と耐障害性の向上が期待できます。従来はユーザー側でLambda@Edge等を使いSigV4aのAuthorizationヘッダーを計算して転送する実装が必要でしたが、今回CloudFrontがネイティブに署名を行うため、運用の簡素化とセキュリティ強化（指定したCloudFront配信のみがMRAPへアクセス可能）を同時に実現します。設定はCloudFrontコンソール、SDK、CLI、CloudFormationからOACを有効にしてS3 MRAPエンドポイントを指定するだけで利用可能です。利用可能リージョンは全世界（CloudFront Chinaは除く）で、追加料金は発生しません。より詳細な実装やガイドはCloudFront Developer GuideおよびS3 MRAPのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: CloudFrontでグローバル配信を行っている開発者、SRE、コンテンツ配信/アーキテクト
  • 利用シーンまたは効果: S3 MRAPをオリジンにしたグローバル配信で、キャッシュミス時に最寄りリージョンから高速にフェッチしつつ、MRAPへのアクセスを指定したCloudFront配信に限定したいケース
  • 運用効果: Lambda@Edgeやカスタム署名ロジックの排除による運用簡素化、セキュリティ強化（オリジンへのアクセス制限）、およびキャッシュミス時のレイテンシ低減によるユーザ体験改善

技術的な注意点 ​

  • IAM権限: CloudFront OACを設定するためのIAM操作（CloudFrontリソースの変更）や、MRAPのアクセスポリシーを更新する権限が必要です。詳細な権限は導入前に確認してください。
  • リージョン制限: 全リージョンで利用可能ですが、CloudFront China（中国リージョン向けCloudFront）では未対応です。
  • コスト: 本機能自体に追加料金はありませんが、MRAP経由でのデータ転送やCloudFrontの通常料金は発生します。キャッシュミスによるオリジンフェッチが増えるとデータ転送費用が増加する点に留意してください。
  • 設定/互換性: CloudFrontのオリジン設定でS3 MRAPエンドポイントを指定し、OACを有効化してください。CloudFormation/CLI/SDKからの設定もサポートされています。
  • アクセスポリシー: MRAPやバックエンドバケットのアクセスポリシー（バケットポリシー／MRAPポリシー）を、CloudFront OACで署名されたリクエストのみ許可するように適切に更新する必要があります。詳細は公式ドキュメントを参照してください。
  • 移行注意点: 既にLambda@Edge等でSigV4aヘッダーを生成している実装は、OACへ移行することで不要になりますが、移行時にはポリシーや設定の整合性（不要なカスタムヘッダーの削除やアクセスポリシーの更新）を確認してください。

参考情報 ​

[IAM] AWS Partner Central agents MCP Server now supports OAuth with AWS Sign-In ​

概要 ​

AWS Partner Central agents MCP ServerがAWS Sign-In経由のOAuthをサポートしました。これによりパートナーは既存のAWS IDとガバナンスで外部ツール（例: Amazon Quick、Kiro）からPartner Central agentsへ安全にアクセスできます。

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

変更点: MCP ServerがOAuth（AWS Sign-In）をサポートし、パートナーが既存のAWS認証情報やIAM権限を使ってサードパーティ／社内ツールからPartner Central agentsへアクセスできるようになりました。従来はSigV4認証を使ったMCPプロキシの構築またはAWS Management ConsoleでのIAMログインが必要でしたが、OAuthにより以下が可能になります。 ・ツール側でOAuthフローを実装することにより、ユーザーは追加の認証ソフトウェアをインストールせずにアクセスを許可できる ・管理者は既存のIAMポリシーやグローバル条件キーでアクセスポリシーを制御可能 ・トークンのインスペクション（Introspection）および取り消し（Revocation）APIにより、アクセストークンの状態管理が可能 ・動的クライアント登録（dynamic client registration）に対応し、クライアント管理の運用負荷を低減 ・CloudTrailの監査イベントでOAuthを使ったアクセスの記録・追跡が可能 利用ケースとしては、コーセル（co-sell）案件の連携、AWSファンディング申請、AWS Marketplaceのセラー設定などのワークフローでサードパーティツールからAgent機能を呼び出す場面を想定しています。注意点として、OAuth連携はMCP Serverの機能であり、現在はUS East (N. Virginia) リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: AWSパートナー（ソリューション提供者）、クラウド/インテグレーション開発者、SRE/運用チーム
  • 利用シーン: Amazon QuickやKiro等の既存ツールからPartner Central agentsを呼び出してコーセル連携、AWS funding申請、Marketplaceセラー設定を自動化・統合する場面
  • 運用効果: SigV4プロキシや追加の認証基盤を運用する必要がなくなり、導入と保守の負荷低減、既存IAMポリシーでの一元的なガバナンスが可能
  • セキュリティ効果: トークンインスペクション／取り消しとCloudTrail監査によりアクセスの可視化と即時失効が可能になり、侵害時の対応が迅速化

技術的な注意点 ​

  • IAM権限: OAuthで許可する操作はIAMポリシーで制御します。必要なIAMロール／権限を事前に設計し、最小権限原則を適用してください
  • リージョン制限: 現時点では US East (N. Virginia) リージョンで提供されています。他リージョンへの展開予定は公式アナウンスを確認してください
  • コスト: 新たなAWS課金項目が明示されてはいませんが、追加のAPI呼び出しやログ取得（CloudTrail）に伴う通常のAWS料金や、統合ツール側の運用コストが発生する可能性があります
  • クライアント要件: 統合するツールはOAuth 2.0（およびAWS Sign-Inの仕様）に対応している必要があります。動的クライアント登録を利用する場合、そのフローに対応していることを確認してください
  • トークン管理/セキュリティ: クライアントシークレットの安全な保管、リダイレクトURIの厳格設定、アクセストークン/リフレッシュトークンの短い寿命と適切なローテーションを推奨します。トークンのインスペクションとリボークAPIを組み込んだ運用設計を行ってください
  • 監査: OAuthログおよびトークン操作はCloudTrailで記録可能です。監査要件がある場合はCloudTrailの設定とログ保持ポリシーを確認してください
  • 互換性: 既存のSigV4ベースの統合は引き続き動作しますが、OAuthへ移行する場合はクライアント実装の変更が必要です

参考情報 ​

[General] ARC Region switch adds Amazon RDS Switchover Read Replica execution block ​

概要 ​

Amazon Application Recovery Controller (ARC) の Region switch に「Amazon RDS Switchover Read Replica」実行ブロックが追加され、Oracle Data Guard を利用するマルチリージョンの Amazon RDS データベースのロール切替（スイッチオーバー／リードレプリカのプロモーション）を自動化できるようになりました。これにより、リージョン障害時の復旧オーケストレーションを迅速かつ一元的に実行できます。

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

ARC の Region switch に新しい実行ブロック「RDS Switchover Read Replica」が導入されました。この実行ブロックは、Oracle Data Guard を構成した Amazon RDS（マルチリージョン構成）の以下の操作を自動で行います：

  • 計画フェイルオーバー（planned failover）では、プライマリとリードレプリカの役割を安全に入れ替える（switchover）ことでゼロデータロスを実現
  • 非計画フェイルオーバー（unplanned）では、リードレプリカを迅速にプライマリへプロモートして復旧時間を短縮（ただしプロモーション時のデータ整合性・損失リスクは状況に依存） また、ネイティブのクロスアカウント対応により、リージョンスイッチプランが別アカウントでホストされている RDS インスタンスに対してもロール切替をオーケストレーション可能です。これにより組織横断での中央運用・復旧管理が容易になります。実行ブロックは Region switch のフロー内に組み込み可能で、他の実行ブロック（例：ロードバランサ切替、DNS 更新、アプリケーション再起動等）と組み合わせて総合的な復旧ランブックを作成できます。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチリージョンで Oracle Data Guard を利用する Amazon RDS を運用するデータベース管理者、SRE、クラウド運用チーム
  • 利用シーン: リージョン障害や計画メンテナンス発生時のデータベースの自動ロール切替（switchover / read-replica のプロモート）を Region switch の復旧フローに組み込むケース
  • 運用効果: 復旧作業を自動化・標準化することで復旧時間（RTO）の短縮、ヒューマンエラーの低減、複数アカウントに跨る復旧の中央管理が可能になる

技術的な注意点 ​

  • 前提要件: 対象の RDS は Oracle Data Guard（マルチリージョンでのプライマリとリードレプリカ）で構成されていること。事前にレプリケーションと接続設定が正常である必要があります
  • IAM権限: Region switch が実行対象アカウントの RDS 操作を行えるように、ARC が対象アカウントを引き受ける（assume role）ための IAM ロール／信頼ポリシーおよび RDS のスイッチオーバー／プロモートを許可する権限が必要です（RDS の変更操作権限を確認してください）
  • データ損失の可能性: 計画スイッチオーバーはゼロデータロスを目指す設計ですが、非計画フェイルオーバーでのプロモーションは同期状況に依存し、データ損失や整合性問題が発生する可能性があります。運用ポリシーで取り扱いを明確にしてください
  • リージョン制限: すべてのリージョンで利用可能とは限りません。対象リージョン（および東京リージョンを含むか）は公式ドキュメントで事前確認してください
  • クロスアカウント: ネイティブのクロスアカウント実行をサポートしますが、事前にターゲットアカウント側で IAM ロールの設定と信頼ポリシーの整備が必要です
  • テスト運用: 本番切替前に非本番環境で計画スイッチオーバーの検証を実施し、アプリケーション側の接続再確立や DNS 更新手順等と組み合わせて総合テストを行ってください
  • コスト: ARC の利用や追加 API／操作自体に関連した直接課金が発生する場合があります（ARC のサービス料金、クロスアカウントのログ・監視等）。RDS の稼働時間や追加リソースによる料金影響も考慮してください

参考情報 ​

[Sagemaker Deploy] Generative AI Inference Recommendation for Amazon SageMaker now available in the SageMaker AI Studio ​

概要 ​

Amazon SageMaker AI StudioにGenerative AI Inference Recommendationsが追加され、ビジュアルな低コード/ノーコードワークフローで推論用の最適構成を自動ベンチマーク・推薦できるようになりました。API版（2026年4月リリース）で提供していたベンチマーク基盤をStudioのGUIに拡張した機能です。

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

SageMaker AI Studioの「Jobs > Inference optimization」から利用可能で、ユーザーはユースケースプロファイル（Interact/Generate/Summarize/Custom）、最適化目標（レイテンシ最小化、スループット最大化、コスト最小化）、およびモデル（JumpStart、S3、Model Registry、既存のSageMakerモデル）を選択します。選択内容に基づき、実GPUインフラ上でNVIDIA AIPerfを用いた複数の構成（インスタンスタイプ、サービングコンテナ、最適化技法など）をベンチマークし、TTFT（time-to-first-token）、トークン間レイテンシ、スループット、コストでランク付けされた推奨構成を返します。推奨にはスループット向けのspeculative decodingやレイテンシ向けのカーネルチューニング等、目的に合わせた最適化技法が自動適用されます。Studio上で結果を比較表示でき、推奨構成をそのままSageMakerリアルタイムエンドポイントへデプロイ可能です。推奨生成自体に追加料金はなく、最適化ジョブやベンチマーク時にプロビジョニングされるエンドポイント/コンピュートについては標準の課金が適用されます。利用可能リージョンは US East (N. Virginia), US West (Oregon), US East (Ohio), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo) です。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、MLOpsチーム、データサイエンティスト、SRE/運用チーム
  • 利用シーン: Generative AIモデル（チャット/生成/要約等）の本番推論構成の選定・検証（レイテンシ/スループット/コストのトレードオフ評価）
  • 運用効果: 手動ベンチマークや試行錯誤に要する数週間の作業を数時間に短縮し、実測データに基づく本番向け構成での迅速な導入が可能
  • 展開: StudioのGUIで視覚的に比較した上でワンクリックでSageMakerリアルタイムエンドポイントにデプロイできるため、本番化の工程が簡易化される
  • 対象リージョン: US East (N. Virginia), US West (Oregon), US East (Ohio), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo)

技術的な注意点 ​

  • IAM権限: SageMaker Studio上で最適化ジョブ・エンドポイントの作成、S3/Model Registryへのアクセスを行うためのIAMロールとポリシー（CreateModel、CreateEndpoint、CreateProcessingJob/CreateTransformJob等）の許可が必要です
  • リージョン制限: 機能は明示されたリージョンで利用可能（上記リスト）。その他リージョンでは未提供の可能性があります
  • コスト: 推奨生成自体は無料ですが、最適化ジョブやベンチマークでプロビジョニングされるGPUインスタンス、エンドポイントの稼働時間に対して標準のインスタンス課金、データ転送、ストレージ等の料金が発生します
  • サービスクォータ: ベンチマークでGPUインスタンスを一時的に多量に使用するため、事前に該当リージョンのインスタンス上限（service quotas）と割当を確認し、必要なら引き上げ申請してください
  • モデル互換性: JumpStart、S3、Model Registry、既存SageMakerモデルが指定可能。カスタムコンテナを使う場合はAIPerfやSageMaker推論ランタイムとの互換性（必要なライブラリやエントリポイント）を確認してください
  • ネットワーク/データ保護: 実データでベンチマークする場合はS3の暗号化、VPC設定、S3エンドポイントやKMSキーの権限設定などを適切に行ってください
  • 測定差異: ベンチマークはSageMakerのGPU環境での実測に基づきますが、実運用環境（VPC構成、ネットワーク、同時リクエストの性質）により実際のスループット/レイテンシは差が出ることがあります

参考情報 ​

[Direct Connect] AWS Direct Connect introduces inbound prefix controls and higher prefix scale ​

概要 ​

AWS Direct Connectは、VIFごとの入力（オンプレ→AWS）プレフィックス割当を管理できる「Inbound prefix controls」を発表しました。これにより、従来のVIFあたり100プレフィックス制限が緩和され、IPv4/IPv6それぞれ最大1,000プレフィックスまで割当可能になります。

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

主な変更点と技術的内容:

  • 既存挙動: これまでプライベート/トランジットVIFはオンプレ側からAWSへ広告できるルートプレフィックス数の上限がVIF当たり100プレフィックスでした。
  • 新機能: Inbound prefix controlsにより、プライベートおよびトランジットVIFでIPv4/IPv6それぞれ最大1,000プレフィックスを割り当て可能になりました（Dedicated/Hosted接続対応）。
  • プレフィックスプール: プレフィックス割当は接続単位（専用接続プール）とDirect Connect Gateway（DXGW）単位のプールから消費されます。VIFを作成または更新する際に、そのVIFに割り当てるプレフィックス数を指定し、割当は接続プールと（DXGWにアタッチする場合は）DXGWプールの両方から差し引かれます。
  • スケーリング: 接続プールのサイズは接続速度に応じてスケールし、LAG（Link Aggregation Group）の場合はメンバー接続数に応じてプールサイズが拡張されます。
  • 操作方法: AWS Management Console、AWS CLI、またはAPIからプレフィックス割当を設定・更新できます。
  • 利用対象: 専用接続およびホステッド接続上のプライベートVIF／トランジットVIFに適用されます。
  • 互換性・制約: 割当数を超えてオンプレから広告したプレフィックスは受け入れられない可能性があるため、割当計画が必要です。
  • 料金・リージョン: 追加料金は発生せず、AWS Direct Connectが利用可能な全ての商用リージョン、AWS GovCloud（US-East/US-West）および中国リージョン（北京：Sinnet、寧夏：NWCD）で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク/クラウドエンジニア、SRE、オンプレとAWS間で多数のプレフィックスを広告する企業
  • 利用シーン: 大規模なオンプレIPプレフィックスを直接1つのVIFで広告したいケース（例：多数のテナントを持つトランジットVIF、広域ネットワークの移行）
  • 運用効果: ルート集約やVIFの分割といった回避策を減らし、VIF単位でプレフィックス容量をワークロードに応じて右サイズできるため運用の簡素化とルーティング管理の柔軟化が期待できる

技術的な注意点 ​

  • IAM権限: Direct ConnectのVIF作成/更新・DXGWアタッチ・プレフィックス割当を行うためのAWS Direct Connectに関するIAM権限（例: directconnect:CreatePrivateVirtualInterface, directconnect:UpdateVirtualInterface, directconnect:AssociateVirtualInterface/AssociateTransitGatewayAttachments 相当の権限）を事前に確認してください。
  • リージョン制限: 全商用リージョン、AWS GovCloud (US-East/US-West)、および中国（北京・寧夏）で利用可能。未対応リージョンがある場合はAWSコンソールまたはリージョンのサービスページで確認してください。
  • コスト: 新機能自体に追加料金は発生しません。ただし接続数やLAG、DXGW等の既存リソースの構成変更に伴う通常の接続料金やデータ転送料金は発生します。
  • 割当ルール: 割当はIPv4/IPv6それぞれ別に管理され、VIFに指定した割当数を超える広告は受け入れられない／拒否される可能性があるため、広告プレフィックス数と割当の整合を取ってください。
  • プール要件: DXGWにアタッチする場合、専用接続側のプールとDXGW側の両方に十分な空きが必要です。プールの上限は接続速度やLAGメンバー数に依存するため、大規模環境では事前にプール容量を確認して計画してください。
  • 既存設計への影響: 以前の「100プレフィックス制限」に依存した集約やVIF分割の設計は見直し可能。ただしBGPポリシーやルートフィルタリング等の既存ネットワーク運用ルールは継続して管理する必要があります。

参考情報 ​

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

概要 ​

Amazon Redshiftがシステムテーブルのデータを長期保持できるようになり、ネイティブにAmazon S3 Tables（Apache Iceberg形式）へ書き出すことで、既存の7日間制限を超えて監査・可観測性要件を満たせるようになりました。AWS側でパーティション管理、コンパクション、保持設定を自動的に行います。

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

新機能では、Redshiftのシステムテーブル（クエリログ、監査情報、パフォーマンスメトリクス等）をAmazon S3 Tablesへ自動的に書き出し（Apache Icebergフォーマット）、現在のデフォルト7日保有を超える長期保持を設定可能にします。AWSはS3 Tables上のパーティション管理・コンパクション・データ保持（retention）を管理するため、ユーザー側でETLパイプラインを構築・運用する必要がなくなります。複数のデータウェアハウスを運用している場合は、各クラスタのシステムテーブルデータを単一のS3 Tablesに自動でレプリケートして、クロスウェアハウスの可観測性や分析を容易にします。データはオープンなApache Iceberg形式で格納されるため、RedshiftだけでなくAmazon AthenaやIceberg互換のクエリエンジンからも直接照会でき、サードパーティーのBI/ダッシュボードツールと組み合わせた分析や可視化が可能です。さらに、AWS Agent Toolkitがシステムテーブルの照会スキルを提供しており、パフォーマンス洞察や最適化推奨の抽出を支援します。本機能はAmazon RedshiftのProvisioned（RG/RA3）とServerlessで利用可能で、利用可能リージョンはUS East (N. Virginia)、US East (Ohio)、US West (N. California)、US West (Oregon)、Africa (Cape Town)、Asia Pacific（Hong Kong、Taipei、Tokyo、Seoul、Osaka、Mumbai、Hyderabad、Singapore、Sydney、Jakarta、Melbourne、Malaysia、Thailand）、Canada (Central)、Europe（Frankfurt、Zurich、Stockholm、Milan、Spain、Ireland、London、Paris）、Israel (Tel Aviv)、South America (Sao Paulo)です。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、データエンジニア、SRE/運用チーム、データアナリスト
  • 利用シーンまたは効果: 監査・コンプライアンスログの長期保存、クエリパフォーマンス履歴の長期分析、複数Redshiftクラスタの横断的可観測性（クロスウェアハウス分析）が容易に
  • 運用効果: カスタムETLや追加のパイプライン開発・保守が不要になり、本番クラスターへのリソース競合を低減できる
  • 分析効果: Iceberg形式のためRedshift、Athena、他のIceberg対応エンジンで共通データセットを照会でき、既存のBI/ダッシュボードに統合しやすい
  • コスト影響: データ保管（S3 Tablesのストレージ）とS3/Athena等でのクエリ実行コストが発生。ETL運用コストは削減可能

技術的な注意点 ​

  • IAM権限: RedshiftがS3 Tablesへ書き出すためのIAMロール/サービスロールに対してS3書き込み（PutObject/AbortMultipartUpload/PutObjectAcl等）やバケット参照（GetBucketLocation、ListBucket）権限、さらにGlue Data Catalogを利用する場合はGlueのテーブル作成・更新権限が必要になる可能性があります。事前に必要な権限を確認してロールを設定してください。
  • リージョン制限: 本機能は記事に記載の特定リージョンで利用可能です（US East (N. Virginia)、US East (Ohio)、US West (N. California)、US West (Oregon)、Africa (Cape Town)、Asia Pacific: Hong Kong, Taipei, Tokyo, Seoul, Osaka, Mumbai, Hyderabad, Singapore, Sydney, Jakarta, Melbourne, Malaysia, Thailand、Canada (Central)、Europe: Frankfurt, Zurich, Stockholm, Milan, Spain, Ireland, London, Paris、Israel (Tel Aviv)、South America (Sao Paulo)）。その他リージョンでは未対応の可能性があります。
  • コスト: 機能利用自体に追加のRedshift料金が発生するかはドキュメントで要確認。S3のストレージ料金、リクエスト料金、Athena等でのクエリ実行料金は別途発生します。長期保持ポリシーによりストレージ量が増加する点に注意してください。
  • 対応インスタンスタイプ: Amazon Redshift Provisioned（RGおよびRA3）とAmazon Redshift Serverlessでサポートされています。旧世代インスタンスでは利用不可の可能性があります。
  • データフォーマット/互換性: データはApache Iceberg形式で格納されるため、Iceberg互換のクエリエンジンやツールでの利用が可能です。既存のプロセスがIcebergを前提としていない場合は互換性確認が必要です。
  • 運用挙動: AWSがパーティション管理・コンパクション・保持を自動で行いますが、保持期間設定・データライフサイクル（削除）ポリシーは設定に依存するため、運用ポリシーを事前に設計してください。
  • 移行/既存ETL: 既に自前でシステムテーブルを外部にコピーするETLを運用している場合は、新機能に切り替えることでETLを廃止できるが、移行計画（データ重複の回避、アクセス制御の統一等）が必要です。

参考情報 ​

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

Copyright © 2026