AWS What's New Digest

Appearance

2026年04月21日 ​

[Local Zones] Amazon EC2 G7e instances now available in AWS Local Zones in Los Angeles ​

概要 ​

Amazon EC2のG7eインスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition GPU + 第5世代Intel Xeon Scalable）がロサンゼルスのAWS Local Zone（us-west-2-lax-1b）で一般提供開始され、低遅延でGPU大規模演算をエッジに近い場所で利用できるようになりました。

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

G7eインスタンスはNVIDIA RTX PRO 6000 Blackwell Server Edition GPUと第5世代Intel Xeon Scalable（Emerald Rapids）プロセッサを組み合わせた高性能GPUインスタンスです。ロサンゼルスLocal Zoneへの配備により、ユーザーに近い場所での低遅延アクセスおよびローカルストレージへの高速アクセスが可能になります。主な用途はクリエイティブワークロード（スタジオ向けワークステーション、VFX編集、カラーコレクション、VFXフィニッシング、リアルタイムレンダリング）およびAIワークロード（LLMのデプロイメント、推論、エージェント型AIなど）のエッジでの実行です。利用開始は、AWS Global ViewでLos Angeles Local Zone（us-west-2-lax-1b）をオプトインし、Amazon EC2コンソール、AWS CLI、またはAWS SDKからG7eインスタンスを起動します。課金はオンデマンドとSavings Plansで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クリエイティブ制作チーム（VFX、ポストプロダクション、レンダリング担当）、AIエンジニア、リアルタイムグラフィックス開発者
  • 利用シーン: ロサンゼルス近傍でのスタジオワークステーション代替、低遅延のリモートレンダリング、オンプレ代替のVFXパイプライン、エッジでのLLM推論やリアルタイムAIエージェントの実行
  • 運用効果: エンドユーザーへのレイテンシー低減、ローカルストレージへの高速アクセスによる作業効率向上、データセンターやオフィス内ワークステーションの置換による管理負荷低減
  • 可用性/導入: Los Angeles Local Zone（us-west-2-lax-1b）へのオプトイン後に利用可能。オンデマンドとSavings Plansでの契約が可能
  • コスト影響: 高性能GPUインスタンスのため実行コストは上昇する可能性がある。長期利用ならSavings Plansの検討でコスト最適化可

技術的な注意点 ​

  • リージョン制限: 提供はロサンゼルスLocal Zone（us-west-2-lax-1b）への配備。利用前にLocal Zoneをオプトインする必要あり
  • IAM権限: Local ZoneのオプトインやEC2インスタンス起動に必要なIAM権限（EC2、IAM、VPC関連）を持つこと
  • AMI/ドライバ: GPUドライバ（NVIDIA）、CUDAや対応するライブラリのインストールが必要。公式のGPU対応AMIまたはカスタムAMIの利用を推奨
  • クォータ/割当: 新しいインスタンスファミリーはデフォルト割当が制限される場合があるため、必要に応じてAWSサポートでクォータ増加を申請
  • ネットワーク/ストレージ: Local Zoneのネットワーク設計（VPCサブネット、ローカルAZとの接続）とストレージ（EBSやローカルストレージのレイテンシ）を確認
  • 料金: オンデマンドとSavings Plansが利用可能。データ転送やLocal Zone固有の料金構成を確認すること
  • 互換性: 使用するソフトウェア（レンダラー、VFXツール、AIフレームワーク）がBlackwell世代GPUおよびドライバと互換であることを事前に確認すること
  • その他: Local Zone利用は既存のus-west-2リージョン設定と連携するが、リソース配置や運用フローにおいてLocal Zone特有の設計が必要

参考情報 ​

[General] Amazon Location Service now offers bulk address validation for the United States, Canada, Australia, and the United Kingdom ​

概要 ​

Amazon Location Serviceが米国・カナダ・オーストラリア・英国向けに一括住所検証機能を提供開始しました。大量の住所データを検証・修正・標準化し、信頼度スコアや配達可能性指標を返すことで配送失敗削減やCRMデータクレンジングに活用できます。

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

本機能はAmazon Location Serviceの「bulk address validation」で、顧客が自分のAmazon S3バケットに住所データをアップロードし、Amazon Location Service Jobs APIで検証ジョブを提出すると、処理完了後に正規化・補正された住所データを取得できます。検証は各国の公的／権威ある郵便データと突合し、綴り間違い、郵便番号の欠落、非標準的な略称等を修正して地域ごとの郵便フォーマットに整形します。各結果にはconfidence（信頼度）スコアとdeliverability（配達可能性）指標が付与され、どの住所を信頼・利用するかをアプリケーション側で判断できます。さらに、米国・カナダ・オーストラリアの住所については、同一ジョブで検証済み住所に対する座標（ジオコード）出力をオプションで取得可能です。ユースケースはCRM移行前のデータクレンジング、配送先検証による配送失敗削減、本人確認／不正防止の住所スクリーニング、DMターゲティングや保険査定精度向上など多岐にわたります。サービスは複数リージョンで利用可能（以下参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: Eコマース／物流運用者、データエンジニア、SRE、CRMマイグレーション担当、フィンテック／保険の審査チーム等
  • 利用シーン: 大量住所データの一括クレンジング（CRM移行前）、出荷前の配送先検証、本人確認／不正検知の住所一致判定、ダイレクトメールや保険引受のターゲティング精度向上
  • 運用効果: 配送エラー・送料ロスの削減、データ品質向上による顧客体験改善とマーケティング精度向上、本人確認精度向上による不正リスク低減

技術的な注意点 ​

  • IAM権限: Location ServiceのJobs API呼び出し権限と、入力/出力用S3バケットへの読み書き権限が必要です（適切なIAMロール/ポリシーを用意してください）。
  • リージョン制限: 提供リージョンは記事記載の以下（2026-04-21時点）です：US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Canada (Central), Europe (London), South America (São Paulo)。リージョン未対応の場合は利用不可です。
  • ジオコーディング対応: 検証結果への座標付与（ジオコード）は米国／カナダ／オーストラリアの住所でオプションとして可。英国ではジオコード出力は提供されない点に注意してください。
  • データ入出力: 入力は顧客管理下のS3バケットに配置してジョブを提出し、処理完了後に標準化・補正済みのファイルを取得します。S3のバケットリージョンやアクセス設定、暗号化設定（KMS等）を事前に確認してください。
  • コスト: Address validation自体のAPI利用料金、ジョブ処理に伴うS3ストレージ・PUT/GET料金、データ転送費用などが発生する可能性があります。大量バッチ処理ではコスト見積りを行ってください。
  • パフォーマンス/遅延: 大量データを一括処理する設計のためバッチ完了まで時間がかかる場合があります。リアルタイム検証が必要な用途は個別API（存在する場合）やオンライン検証と組み合わせて検討してください。
  • 個人情報保護: 住所は個人情報に該当するため、処理時の保存・転送・ログ取り扱いについて社内のコンプライアンス（GDPR等）や業界規制を確認し、必要に応じて暗号化やアクセス制御を適用してください。
  • 外部依存: 検証は権威ある郵便データ等と突合するため、地域別のデータ品質や特殊ケース（新設住所・建物名の扱い等）によっては期待どおりに補正されないケースがあり得ます。検証結果の信頼度スコアを活用して運用ルールを設計してください。

参考情報 ​

[Aurora] Amazon Aurora serverless: Up to 30% better performance, smarter scaling, and still scales to zero ​

概要 ​

Amazon Aurora Serverless がプラットフォームバージョン4にアップデートされ、前バージョン比で最大30%の性能向上とワークロードを理解する改良されたオートスケーリングを実装しました。負荷に応じてゼロまでスケールダウンできるまま、より高負荷な用途でもサーバーレス構成を利用しやすくなっています。

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

主な変更点は次の通りです。性能: プラットフォームバージョン4で最大30%の性能改善が行われ、従来より高いスループットと低遅延が期待できます。スケーリングの賢さ: 新しいスケーリングアルゴリズムがワークロードの特性（バースト、長いアイドル、タスク間の競合など）を把握して容量を調整するため、複数タスクがリソースを争うような忙しいWebアプリやAPIサービス、agentic AIアプリケーションに適しています。スケール・トゥ・ゼロ: 未使用時は自動的にゼロまで縮小され、使用した分のみ課金されます（追加料金なしで提供）。配布・導入: 新規クラスター、復元、クローンは自動的にプラットフォームバージョン4で起動します。既存のv1/v2/v3クラスタは保留中のメンテナンス適用、停止→再起動、あるいはブルー/グリーンデプロイで直接v4へ移行可能です。確認方法: AWS マネジメントコンソールのインスタンス構成セクション、またはRDS APIの ServerlessV2PlatformVersion パラメータでクラスタのプラットフォームバージョンを確認できます。コストとリージョン: プラットフォーム4自体に追加料金はありませんが、実際の課金は使用した容量（ACU等）に基づくためワークロード次第でコストが変動します。詳細はドキュメントと料金ページを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/データベースエンジニア、SRE、アプリケーション開発者（特にバースト負荷やアイドル期間の長い agentic AI/ボット系アプリを扱うチーム）
  • 利用シーン: 高トラフィックなWebアプリやAPI、短期間で多数のセッションが発生するエージェント駆動のAIワークロード、イベント駆動のアプリケーション（アクセス頻度が変動するサービス）
  • 運用効果: 自動スケーリングの精度向上でリソース競合による性能低下を抑制でき、未使用時はゼロまで縮小してコストを削減。性能改善によりサーバーレスで扱えるワークロードの範囲が拡大する

技術的な注意点 ​

  • IAM権限: クラスタのアップグレードや停止/再起動、ブルー/グリーン操作には適切なRDS管理権限が必要（rds:ModifyDBCluster、rds:RebootDBInstance等）。
  • リージョン制限: プラットフォームバージョン4の提供状況はリージョンごとに異なります。導入前に対象リージョンでの可用性を確認してください（料金ページ・ドキュメント参照）。
  • アップグレード運用: 既存クラスタをv4へ移行する際、保留中メンテナンス適用や停止→再起動はダウンタイムを伴う可能性があります。ダウンタイムを最小化する場合はブルー/グリーンデプロイを検討してください。
  • 接続とコールドスタート: スケールダウンでゼロになるとコールドスタートが発生し接続確立に遅延が生じることがあります。接続再試行やコネクションプールの設計を見直してください。
  • コスト: プラットフォーム4自体は追加料金なしですが、実際の課金は使用した容量（ACUベース）に依存します。スケール動作の変化によりトータルコストが変動するため、料金ページでACU課金モデルを確認のうえテスト運用で費用影響を評価してください。
  • 確認方法: クラスタのプラットフォームバージョンはコンソールのインスタンス構成欄、またはRDS APIの ServerlessV2PlatformVersion パラメータで確認可能です。
  • 自動適用: 新規クラスター／復元／クローンは自動的にプラットフォームv4で作成されます。既存クラスターは明示的な手順で移行が必要です。

参考情報 ​

[Organizations] AWS Backup adds Amazon Redshift Serverless and Aurora DSQL support for AWS Organizations backup policies ​

概要 ​

AWS BackupがAWS Organizationsのバックアップポリシーで、Amazon Redshift ServerlessのnamespaceとAmazon Aurora DSQLのクラスタをリソース種別として直接指定できるようになりました。これにより、タグや「全リソース」指定に頼らず、組織単位で対象リソースを精密に制御できます。

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

従来、OrganizationsレベルでRedshift ServerlessやAurora DSQLを組織ポリシーでバックアップ対象にするには、タグベースの選択やメンバーアカウント内の全リソースを対象にする必要がありました。本アップデートにより、組織の管理者はAWS Backupのバックアップポリシー作成時に「リソース種別」として直接「Redshift Serverless namespace」や「Aurora DSQLクラスタ」を選択できるようになります。これにより、以下が可能です：

  • 組織全体に対して特定のデータベースタイプだけを含める／除外する精密なバックアップポリシーの適用
  • ポリシーの一貫性向上と運用工数の削減（各アカウントで個別設定する必要が減少）
  • 既存のバックアップ機能（バックアップライフサイクル、バックアップボールト、コピー/クロスリージョン設定など）と組み合わせて利用可能 この機能は、AWS Backupおよび該当サービスが提供されている全てのAWS CommercialおよびGovCloudリージョンで利用できます。管理はAWS Backupコンソール、AWS CLI、またはAWS SDK経由で実施できます。詳細な操作手順や設定はAWS Organizationsのバックアップポリシーのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 組織単位でバックアップ管理を行うクラウド管理者、SRE、バックアップ/コンプライアンス担当者
  • 利用シーン: 組織レベルでRedshift ServerlessのnamespaceやAurora DSQLクラスタのみを確実にバックアップ対象に含めたいとき（例：データ分析基盤のみを集中管理）
  • 運用効果: タグ付け漏れやアカウントごとの設定差異によるバックアップ漏れを減らし、ポリシーの一元管理で運用負荷とヒューマンエラーを削減できる
  • ガバナンス/コンプライアンス: 組織全体で一貫した保存期間・ライフサイクルを適用しやすくなり、監査対応が容易になる

技術的な注意点 ​

  • IAM権限: 管理アカウント（Organizationsの管理者）はAWS Backupで組織ポリシーを作成・適用する権限が必要。メンバーアカウント側でバックアップ操作を実行するためのサービスロールや必要な権限が事前に設定されていることを確認してください。
  • リージョン制限: この機能はAWS Backupおよび該当サービス（Redshift Serverless, Aurora DSQL）が利用可能なAWS CommercialおよびGovCloudリージョンで利用可能です。サービス未対応のリージョンでは利用できません。
  • コスト: 新規バックアップの作成や保管、（オプションの）クロスリージョン/クロスアカウントコピーはストレージとデータ転送のコストが発生します。ポリシー適用により対象が増減すると料金も変動します。
  • 既存ワークフローとの互換性: これまでのタグベース選択や全リソース選択と併用可能ですが、リソース種別指定を追加すると対象判定が変わるため既存ポリシーの動作確認を推奨します。
  • 運用上の注意: リソース種別名（API/コンソール上の表記）がサービスのアップデートで変更される可能性があるため、ポリシー作成時にコンソールまたはAPIで正しいリソースタイプを確認してください。

参考情報 ​

[Lambda] AWS Lambda Durable Execution SDK for Java GA ​

概要 ​

AWS Lambda Durable Execution SDK for Javaが一般提供（GA）になりました。Java開発者がLambda上で長時間・多段階のワークフロー（耐久実行）を簡単に実装できるようになります。

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

Durable Execution SDK for Javaは、Lambdaのイベント駆動モデルを拡張し、処理の進捗を自動でチェックポイント化して外部イベント待ちの間に最大1年まで実行を中断（suspend）できる機能をJava向けに提供します。SDKは以下を含みます：

  • 進捗管理（checkpointing）用のステップ抽象
  • 人やエージェント介在のコールバック連携（human/agent-in-the-loop）
  • 信頼性の高い関数チェイニング（durable invocation）
  • 効率的な待機（wait）操作による実行の一時停止 技術要件・特徴：
  • 対応ランタイム: Java 17以上
  • デプロイ方法: Lambda管理ランタイム（jar）またはコンテナイメージのどちらでも利用可能
  • ローカル開発: SDKに含まれるローカルエミュレータでデバッグ・テスト可能
  • 利用ケース例: 注文処理パイプライン、AIエージェントのオーケストレーション、人手承認が入るワークフローなど
  • 実行の耐久性: SDKが状態を管理し、再試行やチェイニングを容易にすることでカスタムの進捗トラッキングや外部オーケストレータの導入を不要にすることを目指す

影響範囲・利用シーン ​

  • 対象ユーザー: Javaでサーバーレスアプリを開発するソフトウェアエンジニア、アーキテクト、SRE
  • 利用シーン: 長時間／多段階の業務ワークフロー（受注処理、決済と承認の組合せ、AIワークフローのオーケストレーション、人間承認付きフロー等）
  • 運用効果: 外部オーケストレーションサービスやカスタム状態管理を減らし、リトライや中断からの復帰を簡潔に実装できるため開発工数と運用負荷が低減
  • 可観測性/デバッグ: ローカルエミュレータで事前検証が可能で、本番デプロイ前のデバッグ効率が向上
  • 導入リスク: ランタイム要件（Java 17+）、リージョン対応状況、コスト設計の確認が必要

技術的な注意点 ​

  • IAM権限: Lambdaの作成・更新・実行（lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:InvokeFunction 等）や、コンテナイメージを使う場合はECR関連権限が必要となります。コールバックや外部サービス連携に応じた追加権限も要確認。
  • リージョン制限: GAとはいえ、機能の提供状況はリージョンごとに異なります。導入前にAWS Regional Services Listで対象リージョンを確認してください。
  • Javaバージョン/ランタイム: Java 17以上が必須。Lambdaの管理ランタイムまたはコンテナイメージでデプロイ可能。
  • ローカル開発: SDKのローカルエミュレータで大部分のロジックを検証可能だが、実際の耐久性・スケールやリージョン固有の挙動は本番での検証が必要。
  • コスト: 長期待機や状態管理のための追加の制御プレーン／保存コストや、Durable機能特有の課金が発生する可能性があります。価格はLambdaの料金ページとリージョン別サービスリストで事前に確認してください。
  • 制限/考慮点: 実行の一時停止は最大で1年まで可能と明記されていますが、状態サイズ・API呼び出し頻度・スループット要件などは設計時に考慮する必要があります。

参考情報 ​

[Connect] Amazon Connect Outbound Campaigns now supports contact priority ordering ​

概要 ​

Amazon Connect Outbound Campaignsが、最大10個のプロファイル属性に基づいて通話キャンペーンとJourney内のボイスアクティビティでコンタクトを優先順にダイヤルできるようになりました。初回ダイヤルは再試行より常に優先され、重要顧客や時間敏感な機会にエージェントリソースを集中できます。

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

・サポート内容: セグメント内のコンタクトを最大10個の顧客プロファイル属性（例: 顧客生涯価値、アカウント階層、予約日時等）でソートし、優先順にダイヤルします。 ・適用範囲: 音声キャンペーンおよびAmazon ConnectのJourney内のボイスアクティビティに適用されます。 ・優先制御のルール: 初回ダイヤル（初回試行）は常に再試行より優先されるため、優先順がキャンペーン実行中に維持されます。 ・設定箇所: セグメント作成時にAmazon Connect Customer Profilesでソート属性を設定して開始します。ソートは複数属性の組合せで優先順位を決めることができ、必要に応じて属性の昇順/降順的な扱いで優先付けします（コンソールやドキュメントの設定項目を参照）。 ・運用上のポイント: 属性が正しくプロファイルに存在し、値の正規化（日時形式、数値のスケール等）ができていることが重要です。大規模セグメントや高頻度の再試行ポリシーと組み合わせると、ダイヤリングのスループットやスケジュールに影響が出るため事前検証が推奨されます。 ・コスト/可用性: この優先ダイヤル機能自体に追加料金は発生しませんが、通話やOutbound Campaignsの通常コスト（通話料、Connect利用料等）は別途発生します。機能はAmazon Connect Outbound Campaignsが提供されているすべてのリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: コールセンター運用者、キャンペーン管理者、CRM/マーケティングチーム、SRE/運用チーム
  • 利用シーン: 高価値顧客や契約更新が近いアカウントへの優先的なアウトバウンド、予約が近い患者への優先連絡、時間限定オファーの優先配信
  • 運用効果: エージェント稼働を重要なコンタクトに集中できるためコンバージョン率向上や機会損失の低減が期待される
  • SLA/運用負荷への影響: 優先順の維持により再試行ポリシー設計やスロットリング調整が必要になる可能性がある
  • データ品質影響: ソート属性の正確性・正規化が低いと期待どおりの優先化が行えない

技術的な注意点 ​

  • IAM権限: Customer Profiles（セグメント編集）およびAmazon Connect Outbound Campaignsの作成/編集に必要な権限を事前に確認してください（コンソールやAPI操作に対応するConnect/CustomerProfilesの権限）。
  • リージョン制限: 記載のとおり、Outbound Campaignsが提供されているリージョンで利用可能です。特定リージョンでの提供状況はAWSマネジメントコンソールまたはリージョン一覧で確認してください。
  • コスト: 優先ダイヤル機能自体に追加課金はありませんが、通話料金やOutbound Campaignsの通常料金は別途発生します。大量発信時の通話料とConnect利用料を見積もってください。
  • 属性制限: ソートに使用できるプロファイル属性は最大10個までです。属性の存在・型（日時/数値/文字列）の整合性を確認してください。
  • 実装上の注意: 大きなセグメントや複雑な優先ルールはダイヤリングパフォーマンスに影響する可能性があります。ステージング環境でテストし、再試行ポリシーやスロットリング設定と整合させてください。
  • 監視/ロギング: キャンペーンの実行順序や再試行が期待どおり動作しているかをCloudWatchやConnectのレポートで監視してください。

参考情報 ​

[Elastic Block Store] Amazon EBS expands volume modification enhancement to AWS European Sovereign Cloud Region ​

概要 ​

Amazon EBSは、AWS European Sovereign Cloud（Germany）リージョンで、24時間のローリングウィンドウあたり1ボリュームにつき最大4回のElastic Volumes変更をサポートするようになりました。これにより、ボリュームのサイズ増加、タイプ変更、性能調整をより高頻度に即時実行できます。

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

今回の拡張により、同一ボリュームに対して過去24時間に開始した変更が4回未満であれば、前の変更が完了した直後に次のElastic Volumes変更を開始できます。Elastic Volumesの変更ではボリュームのサイズ（容量）拡張、ボリュームタイプの変更（例：gp2→gp3やio1→io2）、IOPS・スループット等の性能パラメータの調整が可能で、ボリュームのデタッチやインスタンスの再起動を伴わずに実施できます。これにより、突発的なデータ増加やワークロード急増時に運用の機動性を高め、アプリケーション稼働に伴うダウンタイムや大きな性能影響を避けながらストレージをスケールできます。変更の管理は既存のAPI/CLI/コンソールワークフローで行え、リージョンへの反映は自動で有効化されます。変更ステータスはDescribeVolumesModificationsなどのAPIやコンソールで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、データベース管理者、アプリケーション運用チーム
  • 利用シーン: データ容量の急増対応、バースト的なI/O需要への即時対応、テスト→本番移行での性能調整
  • 運用効果: ボリュームの即時スケールや性能調整が可能になり、ダウンタイムやインスタンス再起動を伴わずに迅速なリソース調整ができる
  • リージョン: AWS European Sovereign Cloud（Germany）リージョン適用（他リージョンは既存の適用状況に従う）

技術的な注意点 ​

  • IAM権限: ボリューム変更にはec2:ModifyVolumeなどの権限が必要（実運用では最小権限ポリシーを検討してください）
  • リージョン制限: 本拡張はAWS European Sovereign Cloud（Germany）リージョンに適用。その他リージョンの対応状況は別途確認してください
  • コスト: 変更自体に追加料金は通常発生しませんが、容量増加や高性能ボリュームへの切替は月間料金・IOPS/スループット課金に影響します。コスト見積りを事前に実施してください
  • 操作制限: 1ボリュームあたり24時間のローリングウィンドウで最大4回の変更が可能（この上限を超える変更は開始できません）
  • 互換性/運用: 容量拡張後にOSやファイルシステム側でのパーティション/ファイルシステム拡張作業が必要な場合があります。データベース等はオンラインリサイズの手順を確認してください
  • 監視: 変更状況はDescribeVolumesModifications、CloudWatchメトリクス、イベントログで確認・監視してください
  • 既存ワークフロー: 自動的にリージョンで有効化されるため、既存のAPI/CLI/コンソール手順を変更する必要は基本的にありませんが、運用ポリシー（変更回数の運用ルールなど）は見直しを推奨します

参考情報 ​

[General] Amazon EVS now offers Microsoft Windows Server Licensing ​

概要 ​

Amazon Elastic VMware Service (Amazon EVS) が Microsoft Windows Server のライセンス付与（entitlement）を提供開始しました。EVS上の Windows Server 仮想マシンに対して、AWS から vCPU 時間単位で Windows Server ライセンスを取得・管理できるようになります。

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

Amazon EVS は AWS Nitro 搭載の EC2 ベアメタル上で VMware Cloud Foundation (VCF) をお客様の VPC 内に展開するマネージドサービスです。本アップデートにより、EVS 上で稼働する Windows Server VM に対して AWS から Windows Server ライセンス権利を付与できるようになりました。手順は EVS コンソールまたは AWS CLI で、EVS とお客様の VMware vCenter Server を接続するコネクタを構成し、ライセンス付与したい VM の VM ID を指定するだけです。ライセンスは vCPU-時間単位で課金され、必要に応じて VM ごとに付与／解除をいつでも行えるため、移行フェーズや運用に合わせて柔軟にコスト管理が可能です。EVS の標準的な迅速構築ワークフロー（GUI のステップバイステップまたは CLI）を使えば、数時間で完全な VCF 環境を立ち上げ、オンプレミスからのワークロード移行やデータセンター撤退スケジュールに合わせたライセンス移行を容易に進められます。本機能は Amazon EVS が利用可能な全リージョンで提供されています。詳細な手順や対応状況は公式のウォークスルー／ユーザーガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: VMware を既に利用している企業（クラウド移行担当者、インフラ/クラウド運用チーム、アプリ所有者）
  • 利用シーン: オンプレミスの Windows Server ワークロードを EVS に移行して、移行期間中および移行後に AWS からライセンスを付与して運用するケース
  • 運用効果: データセンター退出期限の短縮、既存 VMware 環境を維持しながらの迅速な移行、vCPU 時間単位の課金により使用量に応じたコスト最適化が可能

技術的な注意点 ​

  • IAM権限: EVS コンソール／CLI での操作やコネクタ設定に必要な IAM 権限を事前に確認・付与してください（詳細は公式ドキュメント参照）。
  • ネットワーク/接続要件: EVS とお客様の vCenter 間の接続設定が必要です。コネクタ構成時に vCenter への管理接続やファイアウォール設定等のネットワーク要件を満たす必要があります。
  • 対応 OS/バージョン: 本記事では "Windows Server" として言及されていますが、対応するエディションやバージョンはドキュメントで確認してください（特定バージョンが対象外の場合があります）。
  • 請求/コスト: Windows Server ライセンスは vCPU-時間単位で課金されます。これに加えて EC2 ベアメタル（Nitro）や Amazon EVS のインフラ利用料が発生します。コスト見積りは移行計画時に必ず実施してください。
  • リージョン制限: 本機能は Amazon EVS が提供されているすべてのリージョンで利用可能とされていますが、利用前に対象リージョンでの提供状況を確認してください。
  • ライセンス／コンプライアンス: Microsoft のライセンス条件（BYOL や License Mobility など）や契約条件との整合性を確認してください。必要に応じて Microsoft または法務部門と事前確認を行ってください。
  • 運用上の注意: ライセンス付与は VM 単位で VM ID を指定して行います。ライセンス付与は VM の移行そのものを自動化するものではないため、移行手順や停止/起動の影響を考慮して実施してください。

参考情報 ​

[Greengrass] AWS IoT Greengrass v2.17 now supports non-root installation and introduces new light weight components ​

概要 ​

AWS IoT Greengrass v2.17 がリリースされ、Linux上でランタイムを非rootユーザーとしてインストール／実行できるようになり、メモリ使用量を大幅に削減したlighter-weight（nucleus lite）コンポーネントが追加されました。企業や規制環境でのセキュリティ要件への対応と、リソース制約のあるエッジデバイスでの運用を容易にします。

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

主な変更点と技術的説明：

  1. 非rootインストール／実行サポート
  • Greengrass v2.17 ではインストーラーとランタイムが非rootユーザー環境で動作可能になりました。これにより、組織ポリシーでrootアクセスが禁止されている環境でも Greengrass を導入できます。非root実行時はデバイスファイルやネットワークポート（特に1024未満のポート）、システムキャパビリティ（capabilities）、ユーザーのグループ所属などの権限設定を適切に構成する必要があります。
  1. アンインストールライフサイクルの自動発動
  • コンポーネントをデバイスから削除すると、自動的にアンインストールライフサイクルが起動してクリーンアップ（プロセス停止、ファイル削除、依存関係解放など）を行えるようになりました。これにより手動での後処理やデバイス上の残留物管理が簡素化されます。
  1. Nucleus lite（軽量）コンポーネント群
  • Secure Tunneling lite: メモリ使用量が従来の約36MBから約4MBへ削減され、帯域やRAMが限られたデバイスでもトンネリング機能が利用可能になります。
  • Fleet Provisioning 更新: TPM 2.0 を利用した暗号処理と安全なデバイスアイデンティティ管理をサポート。オンボーディング時の鍵管理をハードウェアベースで強化します。
  • PKCS#11 インターフェース: HSM／TPMに格納された鍵・証明書を使って Greengrass nucleus lite が AWS IoT Core に対して認証できるようになりました。これにより秘密鍵をソフトウェア領域に置かずに認証が可能です。
  1. リージョンと互換性
  • v2.17 は AWS IoT Greengrass を提供している全リージョンで利用可能です。対象プラットフォームは Linux 系が中心で、非root実行はLinuxの権限管理／デバイスノードアクセスの取り扱いを前提とします。

影響範囲・利用シーン ​

  • 対象ユーザー: エッジ/IoT 開発者、クラウド/デバイス運用チーム、セキュリティ/コンプライアンス担当者
  • 利用シーン: セキュリティポリシーでrootアクセス禁止の企業環境でのGreengrass導入、メモリが制約された組み込みデバイスでの安全なトンネリングやプロビジョニング、HSM/TPMを用いた鍵管理による強固なデバイス認証
  • 運用効果: デバイス上のメモリ消費削減により低リソースデバイスでも機能提供が可能になり、アンインストールの自動クリーンアップで運用作業と障害リスクを低減。非root実行によりセキュリティ監査や規制対応が容易化される

技術的な注意点 ​

  • IAM権限: Greengrass のデプロイやコンポーネント操作には既存の Greengrass 用IAMロール／ポリシーが必要。非rootでもクラウド側の権限は変わりませんので事前に確認してください。
  • OS/プラットフォーム: Linux 環境が対象。Windowsや非Linuxプラットフォームでの非rootサポートは対象外の可能性があります。
  • 非root特有の注意: 非root実行時はデバイスファイル（/dev/*）、ネットワークポート、ファイルシステム領域へのアクセス権をユーザー/グループ単位で適切に設定する必要があります。低番号ポートや特権操作が必要な場合は setcap や特定のグループ付与などで対応してください。
  • 機能差分: nucleus lite コンポーネントはメモリ削減を優先しており、標準コンポーネントと比べて一部機能が削られている可能性があります。機能要件を満たすか検証してください。
  • TPM / PKCS#11 要件: TPM 2.0 や PKCS#11 準拠のHSMが必要。デバイス側のハードウェアサポートと対応ドライバ／ミドルウェア（PKCS#11ライブラリ等）を事前に用意してください。
  • リージョン制限: AWS IoT Greengrass を提供している全リージョンで利用可能です（記事時点）。
  • コスト: Greengrass 自体の利用に関する追加料金は明示されていませんが、TPM/HSMの導入やハードウェア変更、より多くのデバイスをオンボードする場合の運用コストは発生する可能性があります。

参考情報 ​

[Documentdb] Amazon DocumentDB (with MongoDB compatibility) now supports in-place upgrade from version 5.0 to 8.0 ​

概要 ​

Amazon DocumentDB（MongoDB互換）がバージョン5.0から8.0へのインプレース（既存クラスタ上での）メジャーバージョンアップをサポートしました。コンソール／CLI／SDKで数クリックまたはコマンド実行で実施でき、追加のクラスタ作成やエンドポイント変更、インデックス再構築は不要です。

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

本アップデートは「in-place major version upgrade (MVU)」を提供し、既存のDocumentDBクラスタを保持したまま5.0から8.0へ移行できます。操作はAWS Management Console、AWS CLI、またはAWS SDKから行えます。8.0への移行で期待できる主な改善点は、クエリ待ち時間が最大7倍短縮、ストレージ圧縮が最大5倍向上、ベクターインデックス構築が最大30倍高速化、加えてコレーション（collation）、ビュー（views）、新しい集約ステージ／演算子、テキスト検索（text index v2）などMongoDB 8.0相当の機能追加を受けられます。公式発表ではエンドポイント変更やインデックス再構築は不要とされていますが、アップグレード中はノードの再起動や短時間の接続中断が発生する可能性があるため、メンテナンスウィンドウでの実施や事前バックアップ、ステージング環境での検証を推奨します。インプレースMVUはDocumentDB 8.0が提供されている各リージョンで利用可能で、MVU自体に追加課金はありません。

影響範囲・利用シーン ​

  • 対象ユーザー: DocumentDBを利用しているアプリケーション開発者、データベース管理者、SRE/運用チーム
  • 利用シーンまたは効果: 既存クラスタを止めずに主要バージョンを更新して、クエリ応答性能向上やストレージコスト削減、新しい集約機能・テキスト検索・ベクター検索能力をすぐに利用可能にする場面
  • 運用効果: 新クラスタ作成やエンドポイント切替の作業負荷やダウンタイムを低減し、アプリケーション側の接続設定変更なしで機能・性能を向上できる

技術的な注意点 ​

  • 必要な権限: DocumentDBクラスタの変更・スナップショット作成・復元を行えるIAM権限（管理者権限または相当のドキュメントDB操作権限）を事前に用意してください
  • リージョン制限: インプレースMVUはDocumentDB 8.0が利用可能なリージョンで提供されます。利用前に対象リージョンで8.0とMVUが有効か確認してください
  • コスト: MVU自体に追加料金は発生しませんが、アップグレード前のスナップショットや検証用環境の追加、短時間のリソース増加に伴う通常の課金は発生します
  • 互換性／クライアント: アプリケーションのMongoDBドライバがMongoDB 8.0のプロトコルや新機能に対応しているか確認してください。新機能を利用する場合はドライバのバージョンアップが必要な場合があります
  • バックアップとロールバック: アップグレード前に必ずスナップショットを取得してください。ダウングレードは自動では難しく、ロールバックが必要な場合はスナップショットから別クラスタを作成して復元する手順が必要になる可能性があります
  • ダウンタイムの可能性: 公表情報ではインプレースでエンドポイント維持かつインデックス再作成不要とされていますが、アップグレード中にインスタンス再起動や短時間の接続中断・フェイルオーバーが発生する可能性があるため、業務影響を考慮した実施計画を立ててください
  • テスト推奨: 本番適用前にステージング環境で互換性・パフォーマンス検証（特にクエリプラン・テキスト検索・ベクター検索の挙動）を実施してください
  • インデックス再構築: 公式発表ではインデックス再構築は不要とされていますが、ストレージ圧縮や実行計画の変化によりパフォーマンスに差異が出る場合があるためアップグレード後の監視を行ってください

参考情報 ​

[EKS] Amazon EKS enhances cluster governance with new IAM condition keys ​

概要 ​

Amazon EKSがクラスタ作成/構成API向けに7つの新しいIAM条件キーを追加しました。これによりIAMポリシーやService Control Policies(SCP)でクラスタ設定に対するより細かいガードレールを事前適用できるようになります。

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

追加された条件キーと用途の概要:

  • eks:endpointPublicAccess / eks:endpointPrivateAccess: APIエンドポイントの公開/非公開アクセスを条件として強制し、プライベート専用APIエンドポイントの作成を防止または許可します。
  • eks:encryptionConfigProviderKeyArns: シークレット等の暗号化にカスタマー管理のAWS KMSキーのARNを必須化できます（AssociateEncryptionConfig/APIやCreateCluster時の暗号化設定に適用）。KMSキーは適切なキー ポリシー/権限を持つ必要があります。
  • eks:kubernetesVersion: 許可されたKubernetesバージョンのみをクラスタ作成・アップデートで許可し、バージョン管理ポリシーを強制できます。
  • eks:deletionProtection: 本番クラスタに対して削除保護の適用を必須化し、誤削除ガードレールを提供します。
  • eks:controlPlaneScalingTier: コントロールプレーンのスケーリングティア（性能/スケールクラス）を指定して、許可されたスケール構成のみを許容できます。
  • eks:zonalShiftEnabled: ゾーンシフト（高可用性/フェイルオーバー）機能の有効化を条件として要求できます。 これらの条件キーは CreateCluster、UpdateClusterConfig、UpdateClusterVersion、および AssociateEncryptionConfig API 呼び出しに適用され、AWS Organizations のSCPとも組み合わせてマルチアカウント環境で中央集権的にガバナンスを実装できます。新しい条件キーは Amazon EKS が利用可能なすべてのリージョンで追加料金なしで利用可能です。実際にポリシーへ組み込む際は、IAMのCondition構文（演算子や値の形式）やサービス認可リファレンスの条件キー定義を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンスチーム、SRE、プラットフォーム/クラウド基盤チーム、マルチアカウントを運用する組織
  • 利用シーンまたは効果: クラスタ作成時にプライベートAPIのみを許可、KMSによる顧客管理キーでの暗号化を強制、特定のKubernetesバージョンや削除保護を必須化することで、準拠ポリシーを事前適用しコンプライアンス違反や誤操作を未然に防止できます
  • 運用効果: 手動チェックやデプロイ後の修正を減らし、組織全体で一貫したクラスタ設定のガバナンスを実現。SCPと組み合わせることでアカウント単位の逸脱を中央管理で防げます

技術的な注意点 ​

  • IAM権限: 新しい条件キーを使うにはIAMポリシーやSCPのCondition句を更新してください。条件キーの演算子や値形式は Service Authorization Reference を参照する必要があります
  • KMSキー管理: eks:encryptionConfigProviderKeyArns を使う場合、指定するKMSキーのキー ポリシー/アクセス許可を事前に設定し、EKSが必要とする操作（例: データキー生成や暗号化/復号に必要な権限）を付与してください
  • 対応API: CreateCluster、UpdateClusterConfig、UpdateClusterVersion、AssociateEncryptionConfig に適用されます。CloudFormation/CDK/eksctl等からのAPI呼び出しでも条件評価されます
  • リージョン制限: Amazon EKS が利用可能なすべてのリージョンで利用可能です（追加料金なし）
  • 互換性/運用: 既存のクラスタ設定に対してポリシーを適用すると、Create/Update API 呼び出しが拒否される可能性があります。移行時はステージングでポリシー影響を検証してください
  • コスト: 条件キー自体に追加料金は発生しませんが、KMSや高可用性設定（ゾーンシフトや上位のコントロールプレーンティア）により追加コストが発生する可能性があります

参考情報 ​

[Msk] Amazon MSK Replicator now supports log forwarding for replication visibility ​

概要 ​

Amazon MSK Replicatorがレプリケーション用のログ配信をサポートし、レプリケーションのヘルスに対するエンドツーエンドの可視化とトラブルシューティングを強化しました。CloudWatch、S3、Data Firehoseへログを送信でき、典型的なエラーに対する診断ガイダンスが含まれます。

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

MSK ReplicatorはAmazon MSKの機能で、Kafkaクラスタ間のデータレプリケーションを自動化します。本アップデートにより、レプリケータが内部で生成するログ（重要なレプリケーションイベント、エラー、およびそれぞれの解決手順を含む「実行可能な」ログエントリ）を指定した宛先へ配信可能になりました。ログに含まれる代表的な情報は、ソーストピックの権限不足、ターゲットクラスタのパーティション割当上限（quota）不足、レコードサイズ超過などの一般的な障害とその対処法、さらにオフセットコミット、トピック検出イベント、内部で使われるKafkaクライアントからの警告やエラーなどの定常動作情報です。ログ配信はReplicator作成時または更新時にAmazon MSKコンソール、AWS CLI、またはAWS CloudFormationで有効化でき、送信先はAmazon CloudWatch Logs、Amazon S3、またはAmazon Kinesis Data Firehoseが選べます。利用可能リージョンはMSK Replicatorが提供されている全リージョンで、本機能自体の利用に伴う追加コストはログの送信先サービス（CloudWatch Logs、S3、Firehose）の課金によります。従来はCloudWatchメトリクスで進捗や健全性を監視していましたが、今回のログ配信により詳細かつ説明付きのイベント情報で自己解決が容易になり、サポート依存を減らせます。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォームエンジニア、SRE、データエンジニア、運用/監査チーム
  • 利用シーン: レプリケーション失敗時の原因特定（権限、パーティション枯渇、サイズ制限など）、運用時のオフセット/同期状況の監査、監査証跡の長期保管（S3転送）
  • 運用効果: 問題発生時の初動対応時間短縮と自己診断の促進、障害の根本原因把握が容易になりAWSサポート依存を低減、監査/コンプライアンス向けにログを長期保存可能

技術的な注意点 ​

  • IAM権限: Replicator設定でログ配信先へ書き込むためのIAMロール/ポリシー（CloudWatchLogs, S3, FirehoseへのPut権限等）が必要です
  • リージョン制限: 本機能はMSK Replicatorが提供されている全リージョンで利用可能と記載されていますが、利用前に対象リージョンでのReplicator提供状況を確認してください
  • コスト: ログ配信自体は無料ではなく、選択する送信先サービス（CloudWatch Logsのログ取り込み/保管課金、S3のPUT/ストレージ費用、Firehoseの取り込み/転送コスト等）に応じて課金されます
  • ログ形式と内容: アクション可能な診断メッセージ（権限不足、パーティション割当上限、レコードサイズ超過などの詳細）と定常イベント（オフセットコミット、トピック検出、Kafkaクライアントの警告等）を含みます。ログの構造（JSONなど）やフィールド名はドキュメントで確認してください
  • 有効化方法: Amazon MSKコンソール、AWS CLI、またはAWS CloudFormationでReplicatorの作成/更新時にログ配信を有効化します。CloudFormationテンプレートのプロパティ名やCLIパラメータは公式ドキュメントを参照してください
  • ログの保持/ライフサイクル: CloudWatch Logsの保持設定やS3のライフサイクルルール（保管期間やアーカイブ）を組み合わせて運用設計を行ってください
  • セキュリティ: S3へ送る場合はバケットポリシーと暗号化（SSE）を検討し、CloudWatch LogsやFirehose送信時の暗号化オプションやアクセス制御も確認してください

参考情報 ​

[Msk] Amazon MSK Replicator now supports enhanced consumer offset synchronization for bidirectional replication ​

概要 ​

Amazon MSK Replicatorが双方向レプリケーション時のコンシューマオフセット同期を強化しました。これにより、アプリケーションをKafkaクラスター間で移動しても正しい位置から処理を再開でき、プロデューサ／コンシューマの移行順序に依存しなくなります。

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

今回の強化では、MSK Replicatorが双方向（bidirectional）レプリケーション中にコンシューマグループのオフセットをソース／ターゲット両クラスター間で同期する際、プロデューサがどちらのクラスターで稼働しているかに依存しなくなりました。従来はプロデューサとコンシューマが同じクラスター上でアクティブな場合にのみオフセット同期が行われていたため、アプリケーション移行時に順序を厳密に管理する必要があり、ロールバック時の重複処理リスクがありました。強化後は、MSK Replicatorが各クラスター間でコンシューマオフセットを確実に同期するため、プロデューサ／コンシューマを独立して、任意の順序で移動できます。オプションはAmazon MSKコンソール、AWS CLI、およびAWS CloudFormationでReplicator作成時に有効化可能です。本機能はMSK Replicatorが利用可能なすべてのAWSリージョンでサポートされています（詳細な対応状況はドキュメント参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafkaを利用するアプリケーション開発者、プラットフォーム／SRE、データエンジニア
  • 利用シーン: クラスター間移行（バージョンアップ、リージョン移行、クロスAZ/クロスリージョン移行）、災害対策（DR）やクラスタ統廃合時のダウンタイム最小化
  • 運用効果: プロデューサとコンシューマの移行順序に依存せずアプリケーションを移動可能になり、移行中のデータ重複やロールバック時の再処理リスクを低減。運用作業の簡素化と移行計画の柔軟化が期待できる

技術的な注意点 ​

  • IAM権限: Replicatorの作成・管理にはMSKおよび関連リソース（VPC、EC2など）に対する適切なIAM権限が必要です。作成時に使用するIAMロール/ポリシーを事前に確認してください。
  • リージョン制限: 本機能は「MSK Replicatorが利用可能なリージョン」でサポートされます。リージョンによる提供状況はドキュメントで確認してください。
  • コスト: MSK Replicatorの利用に伴う追加料金や、クラスタ間（特にリージョン間）でのデータ転送コストが発生する可能性があります。移行時のデータ量に応じた料金影響を事前に評価してください。
  • 互換性: コンシューマオフセットの同期動作はKafkaの標準的なコンシューマグループモデルに基づきます。カスタム実装や特殊なオフセット管理を行っている場合は動作確認をおすすめします。
  • 設定方法: 機能はコンソール、AWS CLI、CloudFormationから有効化可能です。既存のReplicator設定を変更する場合の影響範囲は事前に検証してください。

参考情報 ​

[Msk] MSK Replicator now supports replication from external Apache Kafka clusters to MSK Express Brokers ​

概要 ​

Amazon MSK Replicatorが外部のApache Kafkaクラスター（オンプレミス、自主管理のAWS上、他クラウド）からMSKのExpressブローカーへのデータ複製をサポートしました。これによりMSK Expressへの移行、ディザスタリカバリ（DR）、ハイブリッド／マルチクラウドでのデータ配信が容易になります。

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

MSK ReplicatorはAmazon MSKに組み込まれた管理型のレプリケーション機能で、今回の拡張により外部KafkaクラスターからMSK Expressブローカーへ直接データを複製できるようになりました。主な技術的特徴は以下のとおりです。

  • 双方向対応: MSK Express ←→ 外部Kafkaの双方へレプリケーション可能で、フェイルフォワード／フェイルバックやマルチクラウド配布をサポートします。
  • トピック名保持とループ回避: レプリケーション中に元のトピック名を保持しつつ、無限ループを自動的に回避します（自己反復の抑止ロジックを内蔵）。
  • コンシューマーオフセット同期: コンシューマーグループのオフセットを双方向で同期し、プロデューサーとコンシューマーをクラスター間で順序や同期の制約なく独立して移動可能にします。
  • セキュリティ・接続: 外部クラスターとの接続にはネットワーク経路（VPN、Direct Connect、パブリック接続など）とKafkaの認証（TLS/SASLなど）設定が必要です。
  • MSK Expressの利点活用: ExpressブローカーはStandardブローカーと比較して最大3倍のスループット、最大20倍のスケールアップ速度、リカバリ時間の90%短縮を目標に設計されており、レプリケーション先として高スループット・短復旧を実現します。
  • 運用簡素化: 自前でMirrorMaker等を管理する必要がなく、AWSマネージド機能としてレプリケーションジョブの作成・監視・管理が可能です。 この機能はMSK Expressブローカーが利用可能な全リージョンでサポートされます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド移行担当者、SRE/運用チーム、データプラットフォーム/ストリーミングチーム
  • 利用シーン: オンプレや他クラウドで稼働中のKafkaからMSK Expressへ段階的にワークロードを移行する際のデータ同期、MSK ExpressをDRフェイルオーバー／バックアップ先として使うケース、ハイブリッド／マルチクラウドでのデータ配信
  • 運用効果: 自主管理のレプリケーション基盤を削減して運用コストを低減、トピック名を維持したまま移行できるためアプリケーション側の変更を最小化、コンシューマーオフセット同期によりプロデューサー／コンシューマーの移動を独立して実施可能でダウンタイムやデータロスのリスクを低減
  • パフォーマンス影響: MSK Expressへの移行によりスループット向上と復旧時間短縮が期待できるが、レプリケーション元のスループットやネットワーク帯域がボトルネックになる可能性あり

技術的な注意点 ​

  • IAM権限: MSK Replicatorの作成・管理には適切なIAM権限が必要です（MSK関連の管理権限やカスタムポリシーでreplicator作成/管理権限を付与）。詳細はドキュメントで確認してください。
  • ネットワーク/接続: 外部Kafkaとの接続にはブートストラップサーバーへの到達性が必要です。VPN、AWS Direct Connect、VPCピアリング、パブリックエンドポイントなどの構成およびセキュリティグループ/ACLの設定を確認してください。
  • 認証/暗号化: TLSおよびSASLなどの認証方式をサポートします。証明書やクライアント認証情報の設定（truststore/keystore等）が必要です。
  • リージョン制限: 本機能はMSK Expressブローカーが利用可能なリージョンでサポートされます。Expressが未提供のリージョンでは利用できません。
  • コスト: MSK Replicatorの利用に伴う追加料金や、MSK Expressブローカーの利用料金、レプリケーションに伴うデータ転送（特にリージョン間転送）コストが発生する可能性があります。料金ページで確認してください。
  • 互換性/運用注意: トピックのパーティション数・設定や保持ポリシーがレプリケーション先と適合するか確認してください。ネットワーク分断や遅延時に一時的なレプリケーション遅延や重複が発生する可能性があるため、モニタリングとアラートを整備してください。
  • 監視: レプリケーションジョブのメトリクス・ログ（遅延、スループット、エラー）をCloudWatch等で監視し、必要に応じてスループットやバッファ設定を調整してください。

参考情報 ​

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

Copyright © 2026