2025 年の 5 月、.NET アプリケーションを大規模にモダナイズするための初のエージェント型 AI サービスである AWS Transform for .NET の一般提供開始を発表しました。サービスの早期導入期間中に、貴重なフィードバックをいただきました。その中で、.NET アプリケーションのモダナイズに加えて、SQL Server や従来の UI フレームワークもモダナイズしたいというご要望があることがわかりました。お客様のアプリケーションは通常、プレゼンテーション層、アプリケーション層、データベース層の三層アーキテクチャに従っており、これらすべての層を統合的に変換できる包括的なソリューションが求められています。 2025 年 12 月 1 日、皆様からのフィードバックをもとに、Windows アプリケーションスタック全体の複雑で煩雑なモダナイズ作業を軽減する AWS Transform for フルスタック Windows モダナイズ を発表できたことを嬉しく思います。これにより、アプリケーションやデータベースの依存関係を特定し、集中管理された環境を通じて統合的にモダナイゼーションを行えるようになりました。 AWS Transform は、アプリケーション、UI、データベース、デプロイメント層におけるフルスタック Windows モダナイゼーションを最大で 5 倍高速化します。.NET Framework アプリケーションをクロスプラットフォーム対応の .NET に移行するだけでなく、SQL Server データベースを Amazon Aurora PostgreSQL-Compatible Edition に移行し、インテリジェントなストアドプロシージャの変換や依存するアプリケーションコードのリファクタリングも行います。検証およびテストのために、AWS Transform はアプリケーションを Amazon Elastic Compute Cloud (Amazon EC2) の Linux 環境や Amazon Elastic Container Service (Amazon ECS) にデプロイし、運用環境での利用に向けてカスタマイズ可能な AWS CloudFormation テンプレートやデプロイ設定を提供します。AWS Transform には、ASP.NET Web Forms の UI を Blazor にモダナイズする機能も追加されています。 まだまだ紹介する内容は多いため、本投稿では、フルスタック Windows モダナイゼーションにおける AWS Transform の各層の機能を初めてご紹介します。 フルスタック Windows モダナイゼーションの変換ジョブを作成する AWS Transform は、ソースコードリポジトリやデータベースサーバーに接続し、アプリケーションおよびデータベースの依存関係を分析した上で、モダナイゼーションのウェーブを作成し、各ウェーブごとにフルスタック変換をオーケストレーションします。 AWS Transform を始めるには、まず AWS Transform 入門ユーザーガイド に記載されているオンボーディング手順を完了します。オンボーディングが完了したら、自分の認証情報を使って AWS Transform コンソールにサインインし、フルスタック Windows モダナイゼーション用のジョブを作成します。 ジョブを作成した後、 事前準備 を完了します。次に、 AWS Transform が Amazon EC2 および Amazon Relational Database Service (Amazon RDS) 上で稼働する SQL Server データベースに安全にアクセスできるよう、データベースコネクタを設定します。このコネクタは、同じ SQL Server インスタンス内の複数のデータベースに接続できます。 次に、 ソースコードリポジトリに接続する ためのコネクタを設定します。 さらに、変換後のアプリケーションを AWS Transform にデプロイさせるかどうかを選択することもできます。 はい を選択し、アプリケーションをデプロイするためのターゲット AWS アカウント ID と AWS リージョンを指定します。デプロイのオプションは後から設定することも可能です。 コネクタの設定が完了すると、AWS Transform はリソースに接続し、IAM ロール、ネットワーク設定、および関連する AWS リソースを検証して確認します。 検証が正常に完了すると、AWS Transform はデータベースとそれに関連するソースコードリポジトリを検出します。関連コンポーネントをまとめて変換するために、データベースとアプリケーション間の依存関係を特定し、ウェーブを作成します。この分析に基づき、AWS Transform はウェーブ方式の変換プランを作成します。 データベースおよび依存するアプリケーションを評価する 評価のために、AWS Transform が検出したデータベースとソースコードリポジトリを確認し、コードリポジトリに適切なブランチを選択します。AWS Transform はこれらのデータベースとソースコードリポジトリをスキャンし、各データベースとそれに依存する .NET アプリケーション、さらに変換の複雑性のリストを提示します。 モダナイゼーションの対象となるデータベースとリポジトリを選択します。AWS Transform はこれらの選択内容を分析し、詳細なウェーブプランを含む包括的な SQL モダナイゼーション評価レポート を生成します。提案されたモダナイゼーションプランを確認するために、レポートをダウンロードします。レポートには、エグゼクティブサマリー、ウェーブプラン、データベースとコードリポジトリ間の依存関係、そして複雑性分析が含まれています。 大規模なウェーブ変換 AWS Transform が生成するウェーブプランは、各ウェーブごとに 4 つのステップで構成されています。最初のステップでは、SQL Server のスキーマを PostgreSQL に変換します。次に、データを移行します。3 つ目のステップでは、依存する .NET アプリケーションコードを PostgreSQL に対応するよう変換します。最後に、アプリケーションをテスト用にデプロイします。 SQL Server のスキーマを変換する前に、新しい PostgreSQL データベースを作成するか、既存のデータベースをターゲットとして選択できます。 ソースデータベースとターゲットデータベースを選択すると、AWS Transform はレビュー用の変換レポートを生成します。AWS Transform は、テーブル、インデックス、制約、ストアドプロシージャを含む SQL Server スキーマを PostgreSQL 互換の構造に変換します。 AWS Transform が自動で変換できないスキーマについては、 AWS Database Migration Service (AWS DMS) コンソールで手動で対応できます。あるいは、お好みの SQL エディタで修正し、ターゲットデータベースインスタンスを更新することもできます。 スキーマ変換が完了した後、データ移行を進めるかどうかを選択できます。このステップは任意です。AWS Transform は、SQL Server インスタンスから PostgreSQL データベースインスタンスへのデータ移行に AWS DMS を使用します。データ移行は、すべての変換作業完了後に実施することも、テストデータをターゲットデータベースにロードして作業することも可能です。 次のステップはコード変換です。AWS Transform が変換後のコードアーティファクトをアップロードするターゲットブランチを指定します。AWS Transform は、変換後の PostgreSQL データベースに対応するようにコードベースを更新します。 今回のリリースでは、フルスタック Windows モダナイゼーション向けの AWS Transform は、.NET 6 以降のコードベースのみをサポートしています。.NET Framework 3.1 以降のコードベースについては、まず AWS Transform for .NET を使用してクロスプラットフォーム対応の .NET に移行します。この点については、次のセクションで詳しく説明します。 変換が完了すると、ソースブランチとターゲットブランチ、およびそれぞれのコード変換ステータスを確認できます。変換レポートをダウンロードして確認することもできます。 UI 層を含む .NET Framework アプリケーションのモダナイゼーション 2025 年 12 月 1 日リリースする主な機能の一つは、UI フレームワークを ASP.NET Web Forms から Blazor にモダナイズする機能です。これは、既存のモデル・ビュー・コントローラー（MVC）Razor ビューを ASP.NET Core Razor ビューにモダナイズするサポートに追加された機能です。 前述の通り、レガシー .NET Framework のアプリケーションがある場合は、引き続き AWS Transform for .NET を使用してクロスプラットフォーム対応の .NET に移行します。ASP.NET Web Forms 上で構築されたレガシーアプリケーションについて、AWS Transform はバックエンドコードの移行に加え、UI 層を Blazor にモダナイズします。 AWS Transform for .NET は、ASP.NET Web Forms プロジェクトを ASP.NET Core 上の Blazor に変換し、ASP.NET Web サイトの Linux への移行を容易にします。AWS Transform for .NET では、AWS Transform Web コンソールと Visual Studio 拡張機能の両方で、UI 近代化機能がデフォルトで有効になっています。 近代化プロセスにおいて、AWS Transform は ASPX ページ、ASCX カスタムコントロール、およびコードビハインドファイルの変換を処理し、これらを Web アセンブリではなくサーバーサイド Blazor コンポーネントとして実装します。変換の過程で、次のプロジェクトおよびファイルの変更が行われます: から へ 説明 *.aspx、*.ascx *.razor .aspx ページと .ascx カスタムコントロールは .razor ファイルになります Web.config appsettings.json Web.config の設定は appsettings.json の設定になります Global.asax Program.cs Global.asax のコードは Program.cs のコードになります *.master *layout.razor マスターファイルは layout.razor ファイルになります AWS Transform for .NET のその他の新機能 UI の移植に加えて、AWS Transform for .NET は、より多くの変換機能のサポートと開発者体験の向上を追加しました。これらの新機能には、以下が含まれます： .NET 10 および .NET Standard への移行 – AWS Transform は、2025 年 11 月 11 日にリリースされた最新の長期サポート（LTS）版である .NET 10 への移行をサポートする ようになりました。また、すべての .NET 実装で共通する API 群の正式な仕様である .NET Standard へのクラスライブラリの移植もサポートします。さらに、AWS Transform は現在、Visual Studio 2026 向けの AWS Toolkit で利用可能です。 編集可能な変換レポート – 評価が完了した後、特定の要件や好みに応じて変換プランを表示およびカスタマイズできるようになりました。たとえば、パッケージの置き換えの詳細を更新することができます。 リアルタイムの変換更新と推定残り時間 – コードベースの規模や複雑さに応じて、AWS Transform が移行を完了するまでに時間がかかる場合があります。変換の進行状況と推定残り時間をリアルタイムで追跡できるようになりました。 次のステップのマークダウン — 変換が完了した後、AWS Transform は移行を完了するための残りのタスクを記載した次のステップ用のマークダウンファイルを生成するようになりました。これを改訂プランとして使用し、AWS Transform で変換を再実行したり、AI コードコンパニオンを使って移行を完了したりすることができます。 知っておくべきこと その他に知っておくべきことは以下の通りです： AWS リージョン – フルスタック Windows モダナイゼーション向けの AWS Transform は、現在、米国東部（バージニア北部） リージョン で一般提供されています。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 料金 – 現在、AWS Transform の Windows モダナイゼーション機能には 追加料金はかかりません 。AWS Transform の出力を使用して AWS アカウントで作成または引き続き使用するリソースは、それぞれの標準料金に従って課金されます。制限やクォータについては、 AWS Transform ユーザーガイド を参照してください。 サポートされる SQL Server バージョン – AWS Transform は、SQL Server 2008 R2 から 2022 までのすべてのエディション（Express、Standard、Enterprise）への変換をサポートしています。SQL Server は、AWS Transform と同じリージョンの Amazon RDS または Amazon EC2 上でホストされている必要があります。 サポートされる Entity Framework バージョン – AWS Transform は、Entity Framework 6.3 から 6.5 および Entity Framework Core 1.0 から 8.0 のモダナイゼーションをサポートしています。 はじめに – はじめるには、AWS Transform for フルスタック Windows モダナイゼーション ユーザーガイド をご覧ください。 – Prasad 原文は こちら です。

2025 年 11 月 30 日、 AWS Lambda マネージドインスタンスを発表しました。これは、サーバーレスの運用の簡単さを維持しながら、 Amazon Elastic Compute Cloud（Amazon EC2) 上で AWS Lambda 関数を実行できる新機能です。この強化機能は、重要な顧客ニーズに対応しています。すなわち、サーバーレス開発体験を損なうことなく、特殊なコンピューティングオプションにアクセスし、定常ワークロードのコストを最適化できるようにするものです。 Lambda はインフラ管理を不要にしますが、一部のワークロードでは特定の CPU アーキテクチャなどの特殊なハードウェアや、Amazon EC2 の購入契約によるコスト最適化が必要となる場合があります。このジレンマにより、多くのチームは必要なコンピュートオプションや料金モデルにアクセスするためだけにインフラ管理を自ら行い、Lambda のサーバーレスの利点を犠牲にせざるを得なくなっています。これにより、多くの場合、アーキテクチャの大幅な変更や運用責任の増大につながります。 Lambda マネージドインスタンス Lambda マネージドインスタンスを使用すると、Lambda 関数を EC2 インスタンス上でどのように実行するかを定義できます。 Amazon Web Services（AWS） が、アカウント内のこれらのインスタンスのセットアップと管理を行います。最新世代の Amazon EC2 インスタンスにアクセスでき、AWS がインスタンスのライフサイクル管理、OS パッチ適用、ロードバランシング、オートスケーリングなど、すべての運用の複雑さを管理します。これにより、データ集約型アプリケーション向けの高帯域幅ネットワークなど、特定のワークロード要件に最適化されたコンピュートプロファイルを選択でき、Amazon EC2 インフラの管理という運用負荷を負う必要がありません。 各実行環境は、一度に 1 つのリクエストだけでなく、複数のリクエストを処理できます。これにより、各呼び出しごとに別々の実行環境を立ち上げるのではなく、コードが複数の同時リクエストでリソースを効率的に共有できるため、コンピュート消費を大幅に削減できます。Lambda マネージドインスタンスでは、 Compute Savings Plans や リザーブドインスタンス などの Amazon EC2 コミットメントベースの料金モデルを利用でき、 Amazon EC2 オンデマンド料金 より最大 72 % 割引を受けられます。これは、従来の Lambda プログラミングモデルを維持しながら、安定したワークロードに対して大幅なコスト削減を提供します。 試してみましょう Lambda マネージドインスタンスを試すには、 まずキャパシティプロバイダーを作成する必要があります 。次の画像に示すように、ナビゲーションペインの その他のリソース の下にこれらを作成するための新しいタブがあります。 キャパシティプロバイダーを作成するには、 仮想プライベートクラウド (VPC) 、サブネット設定、およびセキュリティグループを指定します。キャパシティプロバイダーの設定を使うことで、Lambda に対してインスタンスをどこにプロビジョニングして管理するかを指定することもできます。 含めたい、または除外したい EC2 インスタンスタイプを指定することもできますし、高い多様性を確保するためにすべてのインスタンスタイプを含めることも選択できます。さらに、最大 vCPU 数やオートスケーリングの利用可否、CPU ポリシーの使用など、オートスケーリングに関連するいくつかの制御項目を指定することもできます。 キャパシティプロバイダーの設定が完了したら、新しい Lambda 関数を作成する際に、その Amazon リソースネーム (ARN) を使って選択できます。ここでは、希望するメモリ割り当てとメモリ対 vCPU の比率も選択できます。 Lambda マネージドインスタンスでの作業 基本設定を確認したので、Lambda マネージドインスタンスの仕組みをさらに詳しく見ていきましょう。この機能では、EC2 インスタンスを Lambda コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (AWS CDK) 、 Terraform などのコードとしての Infrastructure as Code (IaC) ツールを使用して設定したキャパシティプロバイダーに編成します。各キャパシティプロバイダーは、インスタンスタイプ、ネットワーク構成、スケーリングパラメータなど、必要なコンピューティング特性を定義します。 キャパシティプロバイダーを作成する際には、ワークロードの要件に合わせて最新世代の EC2 インスタンスから選択できます。コスト最適化された汎用コンピューティングには、優れた価格性能を発揮する AWS Graviton4 ベースのインスタンスを選択できます。どのインスタンスタイプを選ぶか迷った場合、AWS Lambda は関数の設定に基づき、パフォーマンスとコストのバランスが取れた最適化済みのデフォルトを提供します。 キャパシティプロバイダーを作成した後は、簡単な設定変更を通じて Lambda 関数をそれに紐付けることができます。関数を紐付ける前に、マルチコンカレンシー環境で問題を引き起こす可能性のあるプログラミングパターンについてコードを確認する必要があります。例えば、リクエストごとに一意でないファイルパスへの読み書きや、呼び出し間で共有されるメモリ空間や変数の使用などです。 Lambda はリクエストをインスタンス上の事前プロビジョニング済み実行環境に自動的にルーティングするため、初回リクエストのレイテンシに影響するコールドスタートを排除します。各実行環境はマルチコンカレンシー機能を通じて複数の同時リクエストを処理できるため、関数全体でのリソース利用率を最大化できます。トラフィック増加時に追加のキャパシティが必要になると、AWS は数十秒以内に新しいインスタンスを自動的に起動し、キャパシティプロバイダーに追加します。キャパシティプロバイダーはデフォルトで最大 50% のトラフィックスパイクをスケーリングなしで吸収できますが、組み込みのサーキットブレーカーが極端なトラフィック急増時にコンピューティングリソースを保護します。キャパシティプロバイダーが最大プロビジョニング容量に達し、追加キャパシティがまだ立ち上げ中の場合、リクエストを一時的に 429 ステータスコードで制限します。 このプロセス全体を通じて、運用およびアーキテクチャのモデルはサーバーレスのままです。AWS は、インスタンスのプロビジョニング、OS パッチ適用、セキュリティ更新、インスタンス間のロードバランシング、需要に応じた自動スケーリングを管理します。AWS は、オペレーティングシステムおよびランタイムコンポーネントに対してセキュリティパッチやバグ修正を自動的に適用し、稼働中のアプリケーションに影響を与えることはほとんどありません。さらに、インスタンスの最大稼働期間は 14 日に設定されており、業界のセキュリティおよびコンプライアンス基準に準拠しています。オートスケーリングポリシーの作成、ロードバランサーの設定、インスタンスのライフサイクル管理は自分で行う必要はなく、関数コード、イベントソースの統合、 AWS Identity and Access Management (AWS IAM) 権限、 Amazon CloudWatch での監視はそのまま維持されます。 今すぐご利用いただけます Lambda マネージドインスタンスは、Lambda コンソール、AWS CLI、または AWS SDK を通じて、2025 年 11 月 30 日から利用を開始できます。この機能は、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、および欧州（アイルランド）リージョンで利用可能です。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。詳細は、 AWS Lambda ドキュメント をご覧ください。 Lambda マネージドインスタンスの料金は、3 つの要素で構成されています。まず、通常の Lambda リクエスト料金として、100 万回の呼び出しごとに 0.20 米ドルを支払います。次に、プロビジョニングされたコンピューティング容量に対して、通常の Amazon EC2 インスタンス料金が課金されます。Compute Savings Plans やリザーブドインスタンスを含む既存の Amazon EC2 料金契約をこれらのインスタンス料金に適用することで、安定稼働するワークロードのコストを削減できます。最後に、インスタンスの運用管理を AWS が行う費用として、EC2 オンデマンドインスタンス料金を基に計算される 15% のコンピューティング管理手数料が課金されます。従来の Lambda 関数とは異なり、リクエストごとの実行時間に対して個別に課金されることはありません。マルチコンカレンシー機能は、リクエスト処理に必要な合計コンピューティング時間を削減することで、さらにコストを最適化するのに役立ちます。 初期リリースでは、最新バージョンの Node.js、Java、.NET、Python ランタイムがサポートされており、今後他の言語も対応予定です。この機能は、関数のバージョニング、エイリアス、 AWS Cloud Watch Lambda Insights 、 AWS AppConfig エクステンション、AWS SAM や AWS CDK などのデプロイツールを含む既存の Lambda ワークフローと統合されます。既存の Lambda 関数は、関数コードを変更せずに Lambda マネージドインスタンスに移行できます（マルチコンカレンシー対応のスレッドセーフであることが確認されている場合）。これにより、専用コンピューティングやコスト最適化の恩恵を受けるワークロードでも、この機能を簡単に導入できます。 Lambda マネージドインスタンスは、Lambda の機能を大幅に拡張するものであり、サーバーレスの運用モデルを維持しながら、より幅広いワークロードを実行できます。高トラフィックアプリケーションのコスト最適化や、Graviton4 など最新プロセッサアーキテクチャへのアクセスなど、いずれの場合でも、この新機能は運用の複雑さを増すことなく必要な柔軟性を提供します。Lambda マネージドインスタンスで皆さんがどのようなものを構築するのか、とても楽しみにしています。 原文は こちら です。

はじめに このブログシリーズの Part 1 では、SAP Content Serverを使用しているお客様が、Amazon S3をドキュメントストアとして活用して、コスト効率が高く、堅牢でスケーラブルなドキュメント管理ソリューションを構築する方法を探求しました。このブログシリーズの第2部では、高可用性(HA)を実装することで、お客様がAmazon S3上の SAP Content Server の信頼性を向上させる方法を共有します。 SAP Content Serverにおける高可用性が重要な理由 Uptime Instituteの「2025 Annual Outage Analysis Report」 によると、組織の54%が最近の重大な障害で10万ドル以上のコストが発生したと報告しており、20%は1インシデントあたり100万ドルを超えるコストを経験しています。この中断は組織全体に波及し、注文処理、カスタマーサービス業務、コンプライアンス要件に影響を与えます。ミッションクリティカルなSAPワークロードを実行している組織にとって、SAP Content Serverはドキュメント管理業務のバックボーンを形成します。 ビジネスプロセスが購買発注書、請求書、契約書、規制文書への即座のアクセスに依存している場合、SAP Content Serverへの中断はビジネス運営に影響を与える可能性があります。したがって、SAP Content Serverが高可用性で構成され、潜在的なハードウェア、ソフトウェア、またはネットワーク障害にもかかわらず運用可能でアクセス可能な状態を維持することが非常に重要です。 提案アーキテクチャ このブログシリーズの Part 1 では、SAP Content Serverに保存されたコンテンツのファイルシステムとして Amazon S3 File Gateway を設定する方法を説明しました。コンテンツリポジトリを作成し、SAP ERPがコンテンツリポジトリにアクセスできるように構成しました。さらに、SAP MaxDBからAmazon S3へのコンテンツ移行のステップバイステップガイドを提供しました。 S3 File Gatewayサービスには 99.9%の可用性SLA があり、これは月間最大 43分 の計画外ダウンタイムに相当します。この提案されたHAソリューションは、組織がこの可用性SLAを必要とする場合にのみ必要です。このHAソリューションを使用できる3つの異なるシナリオを、以下の図1、2、3に示します。 図1: RISE with SAP on AWSに接続された高可用性SAP Content Server 図2: オンプレミスSAP ERPサーバーに接続されたAWS上の高可用性SAP Content Server 図3: AWSネイティブSAP ERPサーバーを使用した高可用性SAP Content Server 提案ソリューション 図1では、ソリューションアーキテクチャは、RISE with SAPがNetwork Load Balancer (NLB)を介してSAP Content Serverを通じてS3 File Gatewayに接続するHA設計を実装しています。NLBは、SAP Content Serverからプライマリ S3 File Gatewayインスタンスへのリクエストを効率的にルーティングし、S3バケットに接続されたローカルファイル共有を通じてドキュメントにアクセスします。このアーキテクチャは、S3 File Gatewayエンドポイント用のDomain Name Service (DNS)名を持つNLBを活用し、シームレスなフェイルオーバー機能を確保します。フェイルオーバーが発生すると、NLBは自動的にセカンダリアベイラビリティゾーン(AZ)のアクティブなS3 File Gatewayにトラフィックをリダイレクトし、業務の中断なくビジネスドキュメントへの継続的なアクセスを維持します。 以下は、2つの別々のS3 File Gatewayをインストールおよび構成し、同一のファイル共有を作成し、 Git 上のカスタムpacemakerリソーススクリプトを通じて高可用性を確保するためのステップバイステップガイドです。 カスタムリソースは、NLBターゲットグループ内のS3 File Gatewayファイル共有を管理するためのpacemakerリソースエージェントを実装します。これは、異なるAZ間のインスタンス間で自動的にフェイルオーバーすることにより、S3 File Gatewayの高可用性を提供するように設計されています。このアーキテクチャは、 Overlay IPアドレス を使用する代わりに、NLBのネイティブターゲットグループ機能を活用して、2つのAZ間でS3 File Gatewayインスタンスに直接トラフィックをリダイレクトします。 ステップ1: 2つのS3 File Gatewayをインストールおよび構成 異なるAZに 2つの別々のS3 File Gatewayをインストールおよび構成 することから始めます。このセットアップにより、冗長性が確保され、データアクセシビリティが向上します。両方のゲートウェイがS3バケットにマッピングされていることを確認してください。 図4: 2つのS3 File Gatewayの構成 ステップ2: 同一のファイル共有を作成 次に、同じS3バケットを指す 同一のファイル共有を作成 します。このプロセスにより、両方のAmazon S3 File Gatewayが同じデータにシームレスにアクセスできるようになります。これらのファイル共有の権限が、アプリケーションからのアクセスを許可するように正しく設定されていることを確認してください。 図5: S3 File Gatewayをファイル共有に向ける SAP Content Serverへのエントリポイントとして NLB が必要です。NLBの構成を以下に示します。 図6: NLBの作成 図7: NLBターゲットグループの作成 NLBと関連するターゲットグループの作成については、この ドキュメント を参照してください。 ステップ3: NLB DNS名を使用してNFS共有をマウント NLB DNS名を使用してSAP Content ServerにNFS共有をマウント します。このアプローチにより、クライアントに単一のアクセスポイントが提供され、接続が簡素化され、フォールトトレランスが向上します。NLBが両方のS3 File Gatewayにリクエストを転送するように構成されていることを確認してください。 図8: SAP Content Server内のAmazon S3 File Gatewayマウントポイント ステップ4: 高可用性クラスターフレームワークソフトウェア( SLES / RedHat )を構成 この Git に従ってpacemakerクラスターを構成します。クラスターが正常に構成されたら、「pcs status」を介してクラスターステータスを確認します: 図9: SAP Content Server HAクラスターステータスの確認 ステップ5: EC2 Auto Recoveryを有効化 最後に、インスタンスの EC2 Auto Recoveryを有効化 します(新しく作成されたEC2インスタンスではデフォルトで有効になっていることに注意してください)。この機能は、システム障害が検出されたときにインスタンスを自動的に回復し、ノードがそれぞれのAZで利用可能な状態を維持します。Amazon CloudWatchアラームを構成して、インスタンスのヘルスを監視し、必要に応じて回復アクションをトリガーします。 これらの手順に従うことで、高可用性プラクティスを活用した回復力のあるストレージソリューションを確立し、異なるAZ間で重要なデータへの継続的なアクセスを確保できます。 ステップ6: テスト フェイルオーバー前: トランザクションME22N(購買発注変更)を例として、PDFドキュメントを添付できます。 図10: ME22NによるPDF添付 図11: S3にアップロードされたPDFドキュメント SAP Content Serverのセカンダリノードへのフェイルオーバーは、いくつかの方法でトリガーできます。 AWS Fault Injection Simulator (FIS)は、AWSワークロードで制御された障害注入実験を実行することにより高可用性(HA)テストを自動化する完全マネージド型サービスを提供し、実際の障害が発生する前にアプリケーションの回復力を検証し、災害復旧手順の弱点を特定できます。システム管理者は、現在のアクティブノードで「pcs node standby」や「pcs resource move」などのpacemakerクラスターコマンドを使用してプロセスを開始できます。 あるいは、現在のSAP Content Serverノードで/usr/sapマウントのI/Oを無効にする(例: 「umount」経由)などの障害条件を導入することで、フェイルオーバーを手動で調整またはシミュレートできます。フェイルオーバー中、両方のS3 File Gatewayインスタンスは動作し続けますが、NLBターゲットグループの登録が変更され、セカンダリFile Gatewayインスタンスにトラフィックが向けられます。このアーキテクチャは、NLBが新しくアクティブになったS3 File Gatewayインスタンスにトラフィックをリダイレクトするため、ビジネス運営の中断なくドキュメント管理システムへの継続的なアクセスを維持しながら、シームレスな移行を保証します。 図12: 中断検出後、クラスターステータスはプライマリノードが停止していることを示しています クラスターリソースはセカンダリノードで起動しています: 図13: プライマリノードが停止した後、セカンダリノードがクラスターによって起動されています Content ServerがS3 File Gatewayと共にセカンダリノードで正常にフェイルオーバーすると、図14のように表示されます。 図14: セカンダリノードが正常に起動したことを示すクラスターステータス 以前のプライマリホストでは、S3 File Gatewayがマウントされなくなっていることがわかります。 図15: 以前のプライマリノードでS3 File Gatewayマウントポイントがマウントされなくなりました 新しいプライマリホスト(セカンダリノード)では、S3 File Gatewayがマウントされていることがわかります。 図16: 新しいプライマリノードにマウントされたS3 File Gatewayマウントポイント 最後に、フェイルオーバー後にトランザクションME22Nを介してSAP購買発注添付ファイルの確認を繰り返し、失われていないこと、およびSAP ERPから引き続きアクセスできることを確認します。 図17: フェイルオーバー後のME22NでのPDF添付ファイルの表示 SAP Content ServerのHAにおけるS3とEFSの考慮事項 AWS上でSAP Content Serverをアーキテクトする際、Amazon EFSとS3 File Gatewayの選択には、それぞれの明確な強みを慎重に検討する必要があります。両方のソリューションが高い耐久性とクロスリージョン機能を提供しますが、S3 File Gatewayベースのアーキテクチャは、主にS3の強力なバージョニング機能を通じて際立っています。これはデータ保護にとって重要な利点です。このバージョニング機能により、誤って削除または破損したファイルのポイントインタイムリカバリが可能になります。これは、ファイルの削除または破損が即座に永続的になるEFSベースのソリューションでは利用できない機能です。両方のサービスがコスト最適化のためのインテリジェントなデータ階層化と同様のクロスリージョンDR機能を提供するようになりましたが、S3のバージョニングは本質的に組み込みのバックアップメカニズムを提供し、別個のバックアップソリューションを維持する複雑さとコストを削減します。データリカバリとバージョン管理が重要な要件である組織、特にドキュメントの以前のバージョンを復元する機能が不可欠なコンプライアンス重視の環境では、S3 File Gatewayアーキテクチャがより包括的なデータ保護戦略を提供します。最終的な選択は特定のビジネス要件に依存しますが、S3 File Gatewayは、高可用性とパフォーマンスと並んで、きめ細かなデータリカバリ機能を優先する組織にとって特に魅力的です。 コスト見積もり このブログシリーズの Part 1 では、S3 File Gatewayの2つのコスト見積もりについて説明しました。1つ目の例はContent Serverデータベースサイズが500GBの場合、2つ目の例は5TBのデータベースの場合です。これらの価格見積もりをHAを含めるように拡張すると: SAP Content Server EC2インスタンス(r7i.xlarge)の数を1から2に増やす EBSストレージボリューム(100GB)の数を1から2に増やす S3 File Gatewayの数を1から2に増やす NLBを追加 表1: 価格比較 シナリオ HAなし HAあり 5TBデータベース $542 $656 500GBデータベース $124 $239 AWS Calculator リンク 1a , 1b , 2a , 2b HAを使用した5TBデータベースの場合、コストは$542から$656に増加します。同様に、HAを使用した500GBデータベースの場合、$124から$239に増加し、HAの追加がコストを大幅に増加させないことを示しています。 上記のコストにはオペレーティングシステム関連のサブスクリプションは含まれていないことに注意してください。これらは、 SUSE Linux Enterprise Server for SAP Applications や Red Hat Enterprise Linux for SAP などのAWS Marketplaceで確認できます。 結論 S3 File Gatewayを使用したSAP Content Serverの高可用性ソリューションの実装は、AWS Well-Architected Frameworkの 信頼性の柱 で言及されているように、運用の回復力を維持し、ビジネス継続性を確保することを目指す組織にとって不可欠です。概説された手順に従うことで—複数のS3 File Gatewayのインストールと構成、同一のファイル共有の作成、NLBの利用、Git内のpacemaker用カスタムリソーススクリプトの利用、EC2 Auto Recoveryの有効化—企業は、潜在的な中断に耐える堅牢でスケーラブルなアーキテクチャを作成できます。 システムパフォーマンスと回復力を管理するプロアクティブなアプローチは、ダウンタイムに関連するリスクを軽減するだけでなく、厳格なサービスレベル契約もサポートします。AWSのインフラストラクチャを活用することで、組織はデータの耐久性とアクセシビリティを確保しながら、ドキュメント管理機能を強化できます。インフラストラクチャの進化に伴ってシステムのフォールトトレランスを維持し、災害復旧メカニズムが効果的であることを検証するために、スケジュールされたダウンタイム中に AWS FIS を使用してHAテストを定期的にスケジュールし、自動化することをお勧めします。 企業がクラウド環境への移行を進める中、これらのHAプラクティスの採用は、重要なSAPワークロードを保護し、デジタル時代における運用効率を推進する上で極めて重要になります。適切にアーキテクトされたHAソリューションに投資することで、組織は現代のITランドスケープの複雑さを自信を持ってナビゲートし、SAPシステムが利用可能でパフォーマンスの高い状態を維持できるようにします。 SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、お客様は re:Post – AWSコミュニティのための再構想されたQ&Aエクスペリエンス – を活用できます。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できる議論や質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。 謝辞 このブログへの貢献について、Ferry Mulyadi、Derek Ewell、Spencer Martensonに感謝します。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

はじめに SAP Content Serverは、さまざまな形式とタイプの大量の電子ドキュメントをSAPデータとともに保存およびアーカイブするために設計されたスタンドアロンシステムです。これらのドキュメントは、SAP MaxDBなどのデータベースまたはSAP Content Serverの基盤となるファイルシステムに保存できます。SAP Content Serverに保存される電子ドキュメントの一般的な例には、販売請求書、発注書、給与明細、電子メールなどがあります。SAP Content Serverは、整理されアクセスしやすいデータを確保する集中型ドキュメント管理を提供します。SAP ECCまたはSAP S/4HANAアプリケーションとのシームレスな統合により、ビジネスプロセスが強化され、企業が法的および規制要件を満たすことができます。暗号化とアクセス制御により、堅牢なデータセキュリティを提供します。 MaxDBを使用したSAP Content Serverを使用しているお客様は、管理する追加のデータベースインスタンス、長時間のデータベースバックアップ、増加するストレージコスト、セキュリティ上の懸念など、潜在的な課題と複雑さに直面しています。このブログでは、MaxDBに代わるストレージメカニズムを提供し、 Amazon Simple Storage Service (S3) File Gateway でSAP Content Serverを使用する方法を紹介します。MaxDB上で実行されている既存のSAP Content ServerをAmazon S3 File Gatewayに移行するための段階的なプロセスをご案内します。 Amazon S3 File Gatewayは Amazon S3 に基づいており、99.999999999%（イレブンナイン）のデータ耐久性と、特定の年におけるオブジェクトの99.99%の可用性を提供します。バックアップ、レプリケーション、リカバリなどの機能により簡単なデータ管理を提供し、暗号化とアクセス制御によりデータセキュリティを確保します。他のAWSサービスと統合してワークフローを強化し、データのバージョニングとライフサイクル管理によりコスト最適化を実現できます。たとえば、お客様は法的要件により、SAPの財務データを7年間保存する必要がある場合があります。Amazon S3のグローバルなアクセシビリティ、高い耐久性、ディザスタリカバリオプションにより、SAP Content Serverストレージのモダナイゼーションに魅力的なソリューションとなっています。 前提条件 開始する前に、以下を確認してください： AWSアカウント：Amazon S3 File GatewayサービスをプロビジョニングするためのAWSアカウント SAPシステム：SAP ERP（S/4HANAまたはECC）（例：RISE with SAPまたはBring Your Own License）またはオンプレミス SAPインストールメディア： SAP Content Serverインストールメディア へのアクセス 基本知識：AWSサービスと基本的なSAP管理に関する知識 提案されるアーキテクチャ ほとんどのお客様のシナリオをカバーする3つのアーキテクチャオプションがあります。 図1は、AWS上でSAP RISEを実行しているお客様を示しています。SAP Content Serverはお客様のAWSアカウントにプロビジョニングされ、 AWS Transit Gateway （または Virtual Private Cloud (VPC) Peering ）を介してSAP RISE AWSアカウントに接続されます。 図1：AWS上のRISE with SAPのソリューションアーキテクチャ 図2は、SAP Content Serverを含むオンプレミスのSAPシステムを使用したハイブリッドモデルを示しています。SAP Content Serverは Amazon S3 File Gateway に接続され、オンプレミスのSAP Content Serverアプリケーションをシームレスに接続して、Amazon S3に保存されたコンテンツリポジトリを保存およびアクセスします。 Amazon File Gatewayサービスを含む仮想マシンがオンプレミスにプロビジョニングされ、 ローカルディスクキャッシュ として機能し、Amazon S3に保存されたオブジェクトの取得パフォーマンスを向上させます。 図2：ハイブリッドモデル（オンプレミスとAWS）のソリューションアーキテクチャ AWS上でSAPをネイティブに実行している（BYOL）お客様の場合、図3に示すように、SAP Content ServerをSAPシステムと同じAWSアカウントにプロビジョニングできます。 図3：AWS上でSAPを実行する（BYOL）ためのソリューションアーキテクチャ 設定手順 AWS環境のセットアップ AWS上でSAP Content Serverをセットアップするには、以下の手順に従ってください。 Amazon S3 File Gatewayの設定 ブログ Connect Amazon S3 File Gateway using AWS PrivateLink for Amazon S3 に従ってAmazon S3 File Gatewayを作成します Amazon S3 File Gatewayが作成されたら、図4のスクリーンショットに従って、ファイルシステムマウントポイント「/content_server」としてマウントします さらに、図2のハイブリッドモデルデプロイメントの場合、Amazon S3 File Gatewayはキャッシュストレージを使用して、最近アクセスされたデータへの低レイテンシーアクセスを提供します。キャッシュストレージは、Amazon S3へのアップロード待ちのデータのオンプレミス永続ストアとして機能します。キャッシュストレージのサイズを決定するには、AWSドキュメント Managing local disks for your gateway を参照してください 図4：ファイルシステム SAP Content Server Amazon EC2インスタンスでのセキュリティグループの設定 インバウンドルール：ベストプラクティスとして、SAPのヘルプドキュメント TCP/IP Ports of All SAP Products に記載されているTCP/IPポートを介して、ソースSAPアプリケーションサーバーのみがSAP Content Serverと通信できるようにします SAP Content Serverのインストールと設定 SAP Note 2786364 に従ってSAP Content Serverをインストールします（SAPサポートポータルへのアクセスが必要です） トランザクションOAC0を介してSAP ERPシステムでコンテンツリポジトリを作成します SAPシステムにログインします。トランザクションコードOAC0を入力します Content Repositories画面で、New Entriesボタンをクリックします リポジトリ属性を定義します： Repository：コンテンツリポジトリの一意の名前を入力します（例：Z_STORAGE_GATEWAY） Description：リポジトリの意味のある説明を入力します（例：Z_STORAGE_GATEWAY） Document Area：適切なドキュメント領域を選択します。通常、ARCHIVEまたはGENERALまたはDMS Storage Type：SAP Content Serverを使用している場合は、HTTP Content Serverを選択します Version No：コンテンツサーバーのバージョン番号を入力します（例：0047） Content Serverの詳細を指定します： HTTP Server：SAP Content ServerのURLを入力します（例：http://<server_name>:1090/sapcs） HTTPS Server：HTTPSを使用する場合は、図6を参照してください 図5：HTTP設定のサンプル 図6：HTTPS設定のサンプル 設定を保存します： Saveボタンをクリックしてエントリを保存します 設定を保存するためのプロンプトを確認します 接続をテストします： リポジトリが設定されたら、接続をテストします コンテンツリポジトリを選択し、Content Server Checkボタンをクリックします Content Serverへの接続が成功したことを確認します トランザクションCSADMINを介して、新しいContent Serverリポジトリを指すようにSAP ERPを設定します 前の手順で作成したContent Repository「Z_STORAGE_GATEWAY」を選択します 図7：Amazon S3 File Gatewayコンテンツリポジトリの選択 リポジトリ設定を更新します： 表1：SAP Content Serverパラメータ 図8：Amazon S3 File Gatewayを指すようにリポジトリ設定を更新 設定を保存し、緑色の信号灯に従ってSAP Content Serverが正常に実行されていることを確認します 図9：「running」状態のContent Server Content Serverのテスト – ME22N SAPのトランザクションME22Nは、発注書を変更するために使用されます。これは、購買管理（MM）モジュールの不可欠な部分であり、ユーザーが調達プロセスのために既存の発注書を変更できるようにします。 ME22Nトランザクションでファイルを添付できるようにするには、トランザクションOAC3を介して「Links for Content Repositories」設定を維持する必要があります。この例では、Object Type「BUS2012」とDocument Type「PDF」のエントリがContent Repository ID「Z_STORAGE_GATEWAY」を指している必要があります。 図10〜12に示すように、発注書の1つにPDFファイルを添付し、このファイルをAmazon S3バケットで確認しましょう。 ME22Nで、既存のPOを編集し、create attachmentをクリックして、図10および11に示すようにPDFドキュメントをアップロードします。 図10：トランザクションME22Nでの添付ファイルの作成 図11：添付ファイルが正常に作成されました SAP Content Serverにアップロードされたドキュメントが、Amazon S3バケットに表示されます： 図12：SAP Content ServerドキュメントがアップロードされたAmazon S3バケット 移行手順 MaxDBを使用したSAP Content Serverをファイルシステムに移行するには、以下の一般的な手順に従います： カスタムZプログラム（Z_DOC_COPYおよびZ_MIGRATE_ARCHIVELINK）によるドキュメントの移行 これらのレポートを使用する利点は、カットオーバーまで定期的に移行を実行できることです Z_DOC_COPY（SAP Note 2774469） このレポートは、ソースコンテンツサーバーから添付ファイルをコピーし、選択したドキュメントタイプまたはコンテンツ全体を1つずつターゲットサーバーにコピーするために使用できます。また、このレポートはソースとターゲット間の添付ファイルのリストを比較するため、レポートはいつでも再実行/再開できます SE38を実行し、レポートZ_DOC_COPYを実行します 以下の入力を行い、executeをクリックします Destination Repository: Source Repository: Document List: 図13：Z_DOC_COPY Z_MIGRATE_ARCHIVELINK（SAP Note 1043676） このレポートは、リンクベースのソースコンテンツサーバーからターゲットへの添付ファイルのコピーに使用できます。このレポートは、リンクテーブルエントリを変更し、ターゲットリポジトリで新しく生成されたIDを更新します SE38を実行し、レポートZ_MIGRATE_ARCHIVELINKを実行します 以下の入力を行い、適切なボックスをチェックしてExecuteをクリックします OLD_ARC: <古いContent ServerリポジトリID> NEW_ORC: <新しいContent ServerリポジトリID> 図14：Z_MIGRATE_ARCHIVELINK 検証とテスト すべてのドキュメントが正常に移行され、アクセス可能であることを確認します 新しいContent Serverが期待どおりに機能することを確認するために、徹底的なテストを実行します ドキュメントの整合性とアクセス許可を確認します （Content Server 7.53、SAP Note 2888195）レポートRSCMSTH0、RSCMSTH1、RSCMSTH2を実行して、コンテンツリポジトリが一貫性があり健全であることを検証します 新しいContent Serverへの切り替え： トランザクションコードOAC3を介して、新しいファイルシステムベースのContent Serverを指すようにSAP設定を更新します 移行後の問題について、システムを注意深く監視します 移行後のクリーンアップ： 不要になった場合は、古いMaxDBセットアップをクリーンアップします すべてのバックアップとディザスタリカバリ手順が、新しいContent Server設定を含むように更新されていることを確認します バックアップとリカバリ AWS Backup を使用して、SAP Content Serverコンポーネントの適切なバックアップとリカバリ戦略を提供できます： SAP Content ServerがインストールされたAmazon EC2インスタンス Amazon S3 File Gatewayアプライアンス Content Serverデータを保存するAmazon S3バケット SAP Content ServerデータはAmazon S3バケットに保存されていますが、潜在的なアプリケーションレベルの破損を防ぐために、その内容をバックアップすることは依然として重要です。 詳細については、SAP lens Well-Architected Frameworkドキュメントのベストプラクティス Establish a method for consistent recovery of business data および Establish a method for recovering configuration data を参照してください。 MaxDBとAmazon S3 File Gatewayの比較 表2は、MaxDBとAmazon S3 File Gateway間の総所有コスト（TCO）の比較を示しています。 表2：MaxDB vs. Amazon S3 File Gatewayの比較 **コスト比較は、500GB（ calculatorリンク ）と5TB（ calculatorリンク ）の2つのデータベースサイズで、以下の前提条件で行われました： SAP認定Amazon EC2インスタンス（r7i.large、2 CPU、16GB RAM）にインストールされたSAP Content Server ストレージ オペレーティングシステムとSAPバイナリ用の100GB gp3ストレージ MaxDB：それぞれ600GBおよび5.5TB gp3ストレージ MaxDB：30日間の保持期間を持つ毎日のデータベースバックアップ、 Amazon S3 Standard – Infrequent Access に保存 Amazon S3 File Gateway：ファイルシステムストレージ用に500GBおよび5TB（MaxDBデータベースサイズと同等） Amazon S3 File Gateway：AWS Backupによる30日間の保持期間を持つ継続的なバックアップ AWSシンガポールリージョンでのワークロード 要約すると、コンテンツリポジトリとしてAmazon S3 File Gatewayを使用すると、運用の複雑さとコストが大幅に削減され、信頼性とセキュリティが向上します。 まとめ このブログ投稿では、SAP Content Serverに統合されたファイルシステムとしてAmazon S3 File Gatewayをセットアップする方法について説明しました。その中にコンテンツリポジトリを作成し、コンテンツリポジトリにアクセスするようにSAPシステムを設定しました。さらに、MaxDBからAmazon S3 File Gatewayへのコンテンツ移行のステップバイステップガイドを提供しました。 Amazon S3 File Gatewayでサポートされるファイルシステムセットアップを使用してAWS上にSAP Content Serverをデプロイすることで、SAP環境でのドキュメント管理のための費用対効果が高く、堅牢でスケーラブルなソリューションを提供できます。AWSサービスを活用することで、高可用性、データ耐久性、効率的なパフォーマンスを確保できます。このガイドで概説されている手順に従って、組織のニーズに合わせた独自のSAP Content ServerをAWS上にセットアップしてください。 SAP Content Serverで高可用性を実装したい場合は、ブログ「 Amazon S3によるHA対応の持続可能で耐久性の高いSAPドキュメントおよびデータアーカイブ – Part2 」を参照してください。 AWS for SAPブログ で詳細を読み、AWS上でSAPランドスケープをモダナイゼーションする方法についてのインスピレーションを得てください。 謝辞 このブログへの貢献に対して、Ferry MulyadiとDerek Ewellに感謝します。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

Amazon CloudWatch Internet Monitor for SAP Applications は、インターネット接続に関するリアルタイムのインサイトを提供し、企業が問題をトラブルシューティングし、ネットワークパフォーマンスを最適化するのを支援します。 はじめに これは、AWS上のSAPエンドツーエンド・オブザーバビリティに関するブログシリーズのパート3です。 このシリーズの以前のブログ投稿では、AWS上でホストされるSAPシステムのオブザーバビリティの重要性を探求してきました。 Part 1 では、SAPの3層アーキテクチャを紹介し、Amazon CloudWatch Application Insights、CloudWatch RUM、AWS Network Managerなどのサービスが、プロアクティブな監視、迅速なトラブルシューティング、キャパシティプランニングをどのようにサポートするかを示しました。 Part 2 では、SAPネットワークレイテンシー監視に焦点を当て、AWS Network ManagerやNIPINGなどのツール、およびグローバル接続のためのGlobal AcceleratorやCloudFrontなどのソリューションを紹介しました。 これらの基盤の上に、このブログでは、リモートでアクセスされるSAPアプリケーションの信頼性の高いインターネット接続を確保することに焦点を当て、ハイブリッドワーク環境によってもたらされる課題に対処します。AWS上のSAPシステムの信頼性と効率性を維持するために、ネットワークパフォーマンスを監視および最適化する戦略を強調します。 歴史的に、SAPアプリケーションは企業ネットワーク経由でアクセスされていました。しかし、現在では企業の58%が、ユーザーがリモートオフィス、モバイルデバイス、ハイブリッドワーク環境からインターネット経由でFioriなどのSAPアプリケーションにアクセスできるようにしており、企業ネットワークのみのアクセスから移行しています。この移行により、信頼性の高いネットワーク接続を確保する上で新たな課題が生じています。ネットワーク接続は、SAPアプリケーションのパフォーマンスと信頼性に直接影響するため、継続的な監視と最適化が必要です。 AWSは、 Amazon CloudWatch Internet Monitor を使用してこれらの課題に対処します。SAPアプリケーションにとって、ネットワーク接続の監視と管理は、システムの可用性を維持し、応答性の高いユーザーエクスペリエンスを確保する上で重要な側面です。以下の図1に示すように、主要なインターネット障害とSAPクライアントロケーションへの影響は、Internet Monitorダッシュボードで視覚化できます。 図1: Internet Weather Map – このマップは主要なインターネット障害とクライアントロケーションへの影響を表示します。 Amazon CloudWatch Internet Monitorの理解 Amazon CloudWatch Internet Monitorは、既存のAmazon CloudWatchサービスの拡張機能であり、AWSリソースとアプリケーションの監視に使用されます。CloudWatch Internet Monitorは、AWSリソースのインターネット接続の監視に特化しており、ユーザーがAWS環境とインターネット間のネットワークパフォーマンスを視覚化するのに役立ちます。これにより、企業はネットワークレイテンシーとパケット損失を測定でき、アプリケーションとサービスのアクセシビリティと応答性に影響を与える問題を特定できます。 Amazon CloudWatch Internet Monitorの主要なコンポーネントには以下が含まれます: Monitor: Amazon CloudWatch Internet Monitorは、単一のアプリケーション用のリソースで構成され、インターネットパフォーマンスの表示とヘルスアラートの受信を可能にします。これには、定義されたロケーション(都市)と、Amazon Virtual Private Cloud (VPC)、Network Load Balancer、Amazon WorkSpacesディレクトリ、Amazon CloudFrontディストリビューションなどの監視対象リソースが含まれます。これらのリソースは、監視とインターネットパフォーマンス測定の公開の範囲を確立します。 図2: CloudWatch Internet Monitorの概要 – ヘルスイベント、メトリクス、設定オプションを表示するAmazon CloudWatch Internet Monitorインターフェースの概要。 Metrics: Amazon CloudWatch Internet Monitorは、パフォーマンス、可用性、ラウンドトリップタイム、スループットを含む、CloudWatch用の集約メトリクスを生成します。これらのメトリクスは、カスタム名前空間「 AWS/InternetMonitor 」の下のCloudWatch Metricsで表示でき、アプリケーションへのグローバルトラフィックと各AWSリージョンをカバーします。 Internet measurements: Amazon CloudWatch Internet Monitorは、5分ごとにCloudWatch Logsに測定値を公開します。これらの測定値は、アカウント内の上位500の都市ネットワークをカバーします。これには、特定のVPC、Load Balancer、CloudFrontディストリビューション、またはWorkspacesディレクトリのパフォーマンススコア、可用性スコア、転送バイト数、ラウンドトリップタイムが含まれます。オプションで、データをAmazon S3に保存できます。これらの測定値の例を図3に示します。 図3: Internet Measurements Graph – 指定された期間にわたるレイテンシー、パケット損失、スループットなどのインターネットパフォーマンスメトリクスを示すグラフ。 Health event: Amazon CloudWatch Internet Monitorは、世界中のネットワークレイテンシーの増加など、アプリケーションに影響を与える問題を警告するヘルスイベントを生成します。AWSのグローバルインフラストラクチャ全体の履歴データを使用して、影響を計算し、事前設定されたしきい値に基づいてイベントを作成します。ヘルスイベントは、影響を受けた都市ネットワークの詳細を示し、CloudWatchまたはAWS SDK/CLI経由で表示できます。 Performance and availability scores: Amazon CloudWatch Internet Monitorのパフォーマンススコアと可用性スコアは、パフォーマンスまたは可用性の低下の影響を受けていないトラフィックの推定パーセンテージを表します。これらのスコアは、推定ベースラインと比較して分析されたデータに基づいて計算されます。たとえば、パフォーマンススコアが99%の場合、トラフィックの1%のみがパフォーマンス低下を経験していることを示します。可用性スコアも同様に、指定されたトラフィックの中断のないサービスを反映します。この例を図2に示します。 Round-trip time (RTT): クライアントリクエストが応答を受信するまでの時間を測定します。クライアントロケーション全体で集約され、各ロケーションからのトラフィック量によって重み付けされます。この例を図4に示します。 図4: Round-Trip Time (RTT) Graph – 時間の経過に伴う異なるパーセンタイル(P95、P90、P50)でのクライアントリクエストのラウンドトリップタイムを示すグラフ。 Amazon CloudWatch Internet MonitorがSAPにとって重要な理由 SAPアプリケーションはミッションクリティカルであり、信頼性の高いネットワーク接続に依存しています。CloudWatch Internet Monitorにより、SAPチームは接続を検出、トラブルシューティング、改善でき、エンドユーザーのダウンタイムを最小限に抑えることができます。 Amazon CloudWatch Internet Monitorは、以下の主要な機能とメリットを提供します: 可視性: インターネット接続のリアルタイム監視により、ネットワーク問題を迅速に特定して対処し、SAPシステムのダウンタイムを削減します。 トラブルシューティング: 詳細なフローログへのアクセスにより、SAPワークロードに影響を与えるネットワークパフォーマンス問題の根本原因分析が加速されます。 地理的インサイト: 複数のリージョンからの接続を監視し、ユーザー固有またはロケーションベースの問題にプロアクティブに対応できます。 パフォーマンス最適化: レイテンシー、パケット損失、ジッターに関する実用的なメトリクスにより、SAPアプリケーションのパフォーマンスを向上させるための手動調整が可能になります。 セキュリティ: 疑わしいトラフィックと不正アクセスを検出し、SAP環境のセキュリティを強化します。 スケーラビリティ: SAPワークロードの成長に合わせて監視を簡単にスケールし、パフォーマンスを一貫して保ちます。 AWS統合: CloudWatch AlarmsおよびAWS Lambdaとシームレスに接続し、自動通知と修復を実現します。 SAPでAmazon CloudWatch Internet Monitorを活用するためのベストプラクティス SAP環境でAmazon CloudWatch Internet Monitorのメリットを最大化するには、以下のベストプラクティスの実装を検討してください: VPC Flow Logsを有効化: すべてのSAPインターフェース(SAP FioriフロントエンドとHANAバックエンド間など)の詳細なネットワークトラフィックをキャプチャします。ログを使用して、輻輳、設定ミス、または不正アクセスを特定し、必要に応じてルーティングまたはセキュリティを微調整します。 関連するメトリクスを定義: 主要なKPI(レイテンシー、パケット損失、スループット、可用性)のCloudWatchメトリクスを設定します。たとえば、エンドユーザーからSAPシステムへのレイテンシーを監視し、アラートと迅速なトラブルシューティングをトリガーする実用的なしきい値を設定します。 アラームとアラートを設定: 重要なSAPトラフィック(パケット損失>1%またはレイテンシー>100msなど)のカスタムアラームを作成します。これらのアラームは、チームがSAPプロセスに影響を与える中断を迅速に検出して解決するのに役立ちます。 ダッシュボードを活用: SAPネットワークヘルスを視覚化するダッシュボードを構築し、SAPコンポーネント全体のレイテンシー、パケット損失、スループットなどのメトリクスを組み合わせます。スパイクや障害が検出されたら迅速に対応します。 ログを定期的にレビュー: CloudWatch Internet Monitorログを定期的に分析して、トレンドとボトルネック(ピークSAPアクティビティ中の定期的なレイテンシースパイクなど)を確認します。調査結果を使用して、帯域幅とロードバランシングを最適化します。 ネットワークルートを最適化: ログとメトリクスからのインサイトに基づいて、ルートと帯域幅の割り当てを改善します。SAPワークロードに影響を与える永続的またはグローバルな接続問題には、AWS Direct ConnectやGlobal Acceleratorなどのソリューションを検討してください。 AWS Health Eventsと統合: CloudWatch Internet MonitorをAWS Healthとリンクして、関連するAWSインシデントや計画メンテナンスに関するプロアクティブな通知を取得し、事前にSAPワークロードの再ルーティングまたは保護を可能にします。 SAP監視の開始 CloudWatch Internet Monitorの機能を活用するには、以下の手順に従ってSAPアプリケーションのインターネット接続を監視します: ステップ1: インターネット接続を備えたAWS上で実行されるSAPシステム 最初のステップとして、AWS上のSAPシステムがインターネットアクセシビリティのためのパブリックエンドポイントを持っていることを確認します。SAP Web Dispatcherをエントリポイントとして使用して、リクエストをアプリケーションサーバーにルーティングします。Web DispatcherをApplication Load Balancer (ALB)の背後に配置して、パフォーマンスと可用性を向上させるためにトラフィックを分散します。ALBの前にAWS Web Application Firewall (WAF)を設定して、SQLインジェクションやXSSなどの一般的なWeb攻撃から保護します。 ステップ2: CloudWatchに移動 AWSアカウントにログインしたら、AWS Management Consoleに移動します。AWSサービス検索バーで「CloudWatch」を検索するか、サービスメニューの「Management & Governance」の下で見つけます。 図5: CloudWatchサービスを表示するAWS Management Consoleの検索結果。 ステップ3: CloudWatch Internet Monitorを有効化 CloudWatch Internet MonitorはAmazon CloudWatchの機能であり、すべてのAWSリージョンでデフォルトで有効になっています。有効にするための特定のアクションを実行する必要はありません。ただし、Internet Monitorを最大限に活用するには、監視したいVPCのVPC Flow Logsを有効にする必要があります。 ステップ4: VPC Flow Logsを有効化(オプションですが推奨) AWSリソースとインターネット間のインターネットトラフィックに関する詳細なインサイトを取得するには、VPC Flow Logsを有効にします。これらのログは、VPC内のネットワークインターフェースとの間のIPトラフィックに関する情報をキャプチャします。このデータは、インターネットトラフィックパターンの監視と分析に不可欠です。 VPC Flow Logsを有効にするには: AWS Management Consoleに移動し、「VPC」サービスに移動します。 左側のナビゲーションペインから「Your VPCs」を選択します。 監視したいVPCを選択し、「Actions」ボタンをクリックします。 ドロップダウンメニューから「Create Flow Log」を選択します。 図6: Actionsメニューを使用して選択したVPCのフローログを作成するプロセスを示すAWS VPCダッシュボード。 ログの宛先(CloudWatch Logs)、IAMロール、必要に応じてフィルターを含むFlow Log設定を構成します。ログに記録したい適切なトラフィックタイプを選択してください。 図7: 既存のフローログと選択したVPCの新しいフローログを作成するオプションを表示するAWS VPCコンソール。 典型的なSAP環境でログに記録することを検討すべき一般的なトラフィックタイプは次のとおりです: SAPアプリケーショントラフィック: Fiori/GUIクライアントとバックエンドSAPサーバー間のトラフィックをログに記録して、レイテンシー、パケット損失、ユーザーの中断を監視します。 データベーストラフィック: SAPアプリサーバーとHANAまたは他のデータベース間のログを記録して、リアルタイムトランザクションに影響を与える問題をキャッチします。 統合トラフィック: SAP PI/POと外部またはサードパーティシステム間のフローを監視して、失敗した統合をトラブルシューティングします。 外部アクセス: インターネット経由でSAPへの着信接続(Fiori、VPN)をログに記録して、パフォーマンス、セキュリティ、または不正アクセスの問題を発見します。 セキュリティグループトラフィック: SAP Web/データベースサーバー間のログを記録して、設定ミスや不正アクセスを検出します。 ステップ5: CloudWatch Internet Monitorにアクセス CloudWatch Internet Monitorにアクセスするには、以下の手順に従います: AWS Management Consoleで、「Management & Governance」セクションの「CloudWatch」をクリックします。 CloudWatchダッシュボードで、左側のペインの「Network Monitoring」セクションに移動します。 「Internet Monitors」をクリックします。 図8: CloudWatch Dashboard – メトリクスとアラームを含むInternet Monitorセクションを強調表示したAmazon CloudWatchダッシュボードのスクリーンショット。 ステップ6: Internet Monitorメトリクスを探索 Internet Monitorダッシュボードでは、AWSリソースのインターネット接続とパフォーマンスに関連するメトリクスが表示されます。これらのメトリクスには、インターネットゲートウェイ、VPCエンドポイント、NATゲートウェイなどに関連するデータが含まれます。 ステップ7: CloudWatch Internet Monitorダッシュボードを作成 CloudWatchコンソールに入ったら、SAPアプリケーションのインターネット接続とパフォーマンスメトリクスを視覚化するカスタムダッシュボードを作成できます。 カスタムダッシュボードを作成するには: CloudWatchナビゲーションペインの「Dashboards」をクリックします。 「Create Dashboard」を選択します。 ダッシュボードに名前を付けて、「Create Dashboard」をクリックします。 関連するメトリクスを表示するためにダッシュボードにウィジェットを追加します。VPC Flow Logs、インターネットゲートウェイ、エンドポイント、その他のネットワーク関連パラメータに関連するメトリクスを含めることができます。 図9: Create Custom Dashboard – SAPアプリケーションの特定のメトリクスとデータポイントを視覚化するためにAmazon CloudWatchでカスタムダッシュボードを作成する手順。 ダッシュボードの例: Fioriアプリのパフォーマンス: Fioriアプリに影響を与えるレイテンシーとパケット損失を監視します。例: Fioriサーバーとバックエンド間のレイテンシーを視覚化して、速度低下を検出します。 SAP HANAデータベースサーバーの接続: SAP HANAデータベースサーバーへのインターネット接続を監視します。例: アプリケーションサーバーとHANA間のパケット損失を追跡して、パフォーマンスの問題を確認します。 外部統合: SAP PI/POの接続を監視します。例: SAPと外部システム(CRM)間のトラフィックを視覚化して、スムーズな統合を確保します。 ステップ8: アラームとアラートを設定 SAPパフォーマンスの問題を迅速に検出して対処するためにCloudWatchアラームを設定します。ネットワークレイテンシー(200ms)、パケット損失(1%)、統合可用性(99%)、TCP接続時間(500ms)、バックエンドスループット(50 Mbps)、HTTP応答時間(3秒)、バックエンドエラー(1分あたり5回以上)などの主要なメトリクスのしきい値を設定します。しきい値を超えると、CloudWatchは通知を送信したり、自動応答をトリガーしたりできます。 アラームを作成するには: CloudWatchで「Alarms」を選択し、次に「Create Alarm」を選択します。 メトリクスを選択し、条件を設定し、アクションを定義します。 アラームをアクティブ化して監視を開始します。 図10: Set Up Alarms and Alerting – Amazon CloudWatchで特定のSAPアプリケーション要件に基づいてカスタムアラームとアラートしきい値を設定する手順。 アラームの例: ネットワークレイテンシー: レイテンシーがしきい値(例: 200ms)を超えた場合にアラートします。例: Fioriアプリのレイテンシーが200msを超えた場合に通知します。 SAP HANAデータベースサーバーのパケット損失: パケット損失が設定されたパーセンテージを超えた場合にアラームします。例: SAPサーバーとHANA間のパケット損失が1%を超えた場合にアラートをトリガーします。 統合の失敗: SAP PI/POの中断に対してアラートします。例: 統合トラフィックが低下した場合に通知し、同期の問題を示します。 ステップ9: 監視と最適化 SAPアプリケーションの長期的なパフォーマンスと可用性を確保するために、チームはInternet Monitorによって生成されたダッシュボードとアラートを組織の全体的な運用ヘルスレビュープロセスに組み込む必要があります。これには以下が含まれます: 運用レビューへのダッシュボードの組み込み 所有権とSLAの定義 継続的改善のためのトレンド分析 自動化とエスカレーション 応答のシミュレーションとテスト CloudWatch Internet Monitorのインサイトを運用化することで、組織はリアクティブなトラブルシューティングからプロアクティブなネットワークガバナンスに移行し、ダウンタイムを削減し、SAPワークロードをより効果的にサポートできます。 SAP監視の価格 CloudWatch Internet Monitorは、コスト効率の高い従量課金制の価格モデルを提供し、実際の使用量に基づいてSAPインフラストラクチャを監視できます。価格は2つの主要なコンポーネントに分かれています: 監視対象のSAPリソース これは、アプリケーションサーバー、データベース、その他の主要コンポーネントなどのSAPリソースの数に基づいています。各リソースに対して1時間あたりの料金が発生します。 都市ネットワークごとの料金 都市ネットワークごとの料金は、監視される都市ネットワークの数に依存します。最初の100の都市ネットワークは基本価格に含まれており、追加の都市ネットワークは別途請求されます。 CloudWatch LogsとMetricsの料金 監視サービスの一部として、診断ログがトラフィック量による上位の都市ネットワーク(最大500の都市ネットワーク)のCloudWatch Logsに公開されます。これらのログに対して、使用量に基づいてCloudWatch Logsの料金が発生します。 CW Internet Monitorの価格の詳細については、以下を参照してください – https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.pricing.html 次のステップ: SAPアプリケーションおよび関連シナリオでInternet Monitorを活用することに興味のあるユーザーは、以下のリソースを探索できます: Internet Monitorドキュメント は、セットアップ、ユースケース、ヘルスイベント通知や地理的インサイトなどの機能に関する詳細なガイダンスを提供します。 Introducing Amazon CloudWatch Internet Monitor や Utilizing CloudWatch Internet Monitor with Amazon WorkSpaces Personal などのAWSブログは、アプリケーションヘルスの監視とユーザーエクスペリエンスの最適化のための実用的な例と統合のヒントを提供します。 結論: Amazon CloudWatch Internet Monitorは、SAPチームにインターネット接続とパフォーマンスに関するほぼリアルタイムの可視性を提供し、組織がネットワーク問題をプロアクティブに解決し、AWS上のSAPワークロードの最適な運用を維持できるようにします。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

はじめに SAPシステムを運用している組織は、エンタープライズデータという金鉱の上に座っています。お客様とのやり取り、サプライチェーンオペレーション、財務取引、人事記録など、膨大な情報が蓄積されています。しかし、多くの企業がこの広大な情報リポジトリの潜在能力を十分に引き出すことに苦労しています。従来のウォーターフォールアプローチによるABAPプログラミングでは、シンプルなレポートを作成するだけでも最低1〜2週間かかり、シンプルなBWレポートの構築にはさらに長い時間(開発、テスト、デプロイで約4週間)がかかります。これにより、企業が課題や競争に対処するためのタイムリーな意思決定を行うことが妨げられていました。 生成AI(Generative AI)の力とエンタープライズデータインテリジェンスを組み合わせた新しいソリューションを見てみましょう。このソリューションは、企業がSAPおよびエンタープライズデータとやり取りし、そこから価値を引き出す方法を変革します。組織が競争優位性を獲得するために人工知能を活用しようとする中、 Amazon Bedrock Knowledge Bases とSAPシステムおよび他のデータソースとの統合は、従来のエンタープライズデータ管理と最先端のAI機能の間のギャップを埋めるユニークな機会を提供します。この組み合わせにより、企業はデータにアクセスするだけでなく、それを理解し、そこから学び、これまで想像もできなかった方法で実用的なインサイトを生成できるようになります。 この記事では、Amazon Bedrock Knowledge Basesが組織のSAPおよびエンタープライズデータの活用方法をどのように革新し、イノベーション、効率性、戦略的意思決定のための新たな可能性を創出しているかを探ります。自然言語クエリから自動化されたドキュメント処理、インテリジェントなインサイト生成まで、このソリューションが企業のSAP投資をAI時代の戦略的資産に変革する方法をご紹介します。 統合データインテリジェンスの力 SAPおよびエンタープライズデータとBedrock Knowledge Basesを組み合わせることの真の力は、グローバル製造企業がサプライチェーンオペレーションを革新した事例を見ると明らかになります。不確実な市場状況(最近の関税戦争、極端な気象変動など)と進化するお客様の需要という課題に直面し、この企業は従来の予測手法を超えて、よりダイナミックでインテリジェントな在庫管理システムを構築しようとしました。 Bedrock Knowledge Basesを活用することで、この企業はSAP S/4HANAシステムと多様な外部データソースを橋渡しする統合データ基盤を構築しました。SAP環境は、過去の販売注文や在庫レベルから生産計画や購買履歴まで、豊富な運用データを提供しました。これは、ソーシャルメディアのセンチメント、気象パターン、競合他社の活動、より広範な経済指標などの外部シグナルとシームレスに統合されました。その結果、自然言語でクエリできる包括的なナレッジベースが生まれ、組織全体のビジネスユーザーが複雑なデータにアクセスできるようになりました。 その影響は変革的でした。調達マネージャーは、「来四半期に製品Xの需要に影響を与える要因は何か?」といった質問を単純に尋ねるだけで、過去のSAPデータパターンとリアルタイムの市場インテリジェンスを組み合わせたAI生成のインサイトを受け取ることができるようになりました。システムは、過去の販売トレンドや現在の在庫レベルから、ソーシャルメディアのセンチメントや今後の地域イベントまで、複数の要因を分析し、在庫調整のための微妙なニュアンスを含む推奨事項を提供しました。この包括的なアプローチにより、余剰在庫コストの削減、注文充足率の向上、需要予測の大幅な精度向上といった顕著な結果が得られました。 このユースケースは、Bedrock Knowledge Basesがデータへのアクセスだけでなく、これまで見えなかった実用的なインサイトを明らかにすることを示しています。SAPと非SAPデータソース間の障壁を取り除くことで、組織は今やエンタープライズデータの潜在能力を最大限に活用し、より情報に基づいた戦略的な意思決定を行うことができます。生成AIを通じて構造化データと非構造化データの両方を処理する能力は、ビジネスの最適化とイノベーションのための新たな可能性を開きます。 AWS生成AIサービスを活用した他の実際のお客様成功事例については、 こちらのリンク をご覧ください。 SAPおよび非SAPデータ構造と一般的な課題の概要 組織は、SQL互換データベース、データウェアハウス、またはデータカタログに保存された大量の構造化データを保有しており、生成AIによるこれらのデータの取得にはText-to-SQL変換ステップが必要です。Bedrock Knowledge Basesの構造化データストアサポートにより、ユーザーは差別化されない重労働なしに、自然言語の会話インターフェースを通じてこれらのデータに簡単にアクセスできます。Bedrockは自然言語プロンプトを分析し、自動的にSQLを生成し、データを取得し、回答を生成します—すべてを1つのステップで実行します。 Amazon Bedrock Knowledge Baseの実装 実装の前提条件: クエリエンジンとして事前設定された Amazon Redshift Serverless または Redshift Provisioned Cluster 。このブログでは完全なAWSマネージドサービスとしてRedshift Serverlessを使用しますが、SAPシステムから移動されるデータの頻度が高く定期的なワークロードのシナリオでは、Redshift Provisioned Clusterがコスト面でメリットを提供することが多いため、こちらも検討できます。 SAPデータがAmazon S3上のData Lakehouseアーキテクチャ、またはRedshift Serverless、またはRedshift Provisioned Clusterに保存されていること。このデータ取り込みは、ソースがSAP S/4HANAの場合は AWS Glue for SAP OData を使用して、ソースがSAP HANA Cloudの場合は AWS Glue for SAP HANA を使用して実行できます。SAP接続をサポートする他のISVツールも使用できます。 Bedrock Knowledge Baseを実装する際には、データソース統合、セキュリティ、スケーラビリティ、パフォーマンスなど、考慮すべき点がいくつかあります。以下は、アーキテクチャ図とこのソリューションを実装する際の考慮点です。 データソース統合: 添付ファイル、作業マニュアル、パフォーマンスドキュメントなどの非構造化データで、データソースをベクトルストアKBに同期したい場合は、Amazon Bedrock Knowledge Baseを活用できます。 テーブルなどの構造化データの場合は、 Amazon Bedrock Knowledge Bases for Structured data を使用でき、自然言語を使用して構造化データをクエリできます。 セキュリティとコンプライアンス: SAPデータは、Amazon VPC内のプライベートネットワークで転送および保存する必要があります。SAPデータをAmazon S3上のData Lakehouseアーキテクチャに統合する際には、TLS暗号化などを使用した安全な接続が必要です。 BedrockからRedshift、GlueからRedshift、GlueからSAPへのデータアクセシビリティのためのIAMロールを実装する際には、最小権限の原則を実装する必要があります。 SAPシステムへのアクセスに使用される認証情報などの機密情報を保存するには、Secret Managerを使用します。 Bedrock Guardrailsを使用して、生成AIアプリケーションを有害なコンテンツや望ましくないトピックから保護します。 スケーラビリティとパフォーマンス: このアーキテクチャのすべてのサービスは、高可用性、高パフォーマンス、スケーラブルなAWSマネージドサービスであるため、ソリューションのサイジング、インストール、運用に関する重労働を行う必要はありません。 図1. 構造化SAPおよびエンタープライズデータのためのAmazon Bedrock Knowledge Basesアーキテクチャ アーキテクチャの詳細 1. SAPシステムとAWS VPC間の安全な接続の確立 最初のステップとして、ソースSAPシステムからお客様のAWSアカウント内のVPCへの安全な接続を確立する必要があります。 1-a: データソースがSAP S/4HANAシステムの場合 RISE with SAP VPCは、VPC PeeringまたはAWS Transit Gatewayを通じてお客様管理VPCにプライベートに接続できます。詳細については、RISE with SAPの技術ドキュメント Connecting to RISE from your AWS account を参照してください。この構成により、お客様管理VPC内で実行されるデータ取り込みジョブは、SAP S/4HANAと安全に通信します。 AWSアカウントで実行されるSAPシステムの場合、VPC PeeringまたはAWS Transit Gatewayによって複数のVPC間のプライベート接続を設定できます。 オンプレミスで実行されるSAPシステムの場合、S2S VPNまたはDirect Connectによって、独自のネットワークとAWS間のプライベート接続を確立できます。 1-b: データソースがSAP HANA Cloudの場合 SAP Private Link service を通じて、お客様管理VPCからSAP HANA Cloudインスタンスへのプライベート接続を確立できます。詳細な手順については、ブログ Secure SAP HANA Cloud connectivity using AWS PrivateLink を参照してください。 2. データ統合 Guidance for SAP Data Integration and Management で説明されているように、SAPデータを抽出するオプションは多数あります。このブログでは、 AWS Glue for SAP OData を使用してSAP S/4HANAからデータを抽出します。この抽出プロセスは、Glue Zero-ETL統合またはGlue Visual ETLジョブを使用して実行できます。SAP HANA Cloudからデータを抽出する場合は、 AWS Glue for SAP HANA を使用できます。 Glue Zero-ETL は、一般的な取り込みおよびレプリケーションのユースケースのためにETLデータパイプラインを構築する必要性を最小限に抑える、AWSによる完全マネージド統合のセットです。 SAP ODataをソース として読み取り、Amazon SageMaker LakehouseやAmazon Redshiftなどの ターゲット にデータを書き込みます。 AWS Glue for SAP ODataの設定方法 ステップ2.1: SAP OData接続の作成 AWS Glue for SAP ODataを設定する詳細な手順については、 このブログ を参照してください。安全なデータ転送のために、SAP Odata接続がVPC内で設定されていることを確認してください。 図2. VPC設定を使用したAWS Glue for SAP OData ステップ2.2: Glue Zero-ETL統合のターゲット設定 Glueユーザーガイド を参照し、Zero-ETLターゲットAmazon Redshift Serverlessを設定します。このRedshiftターゲットは、Glue SAP OData接続と同じVPC内に配置する必要があります。 図3. Zero-ETLターゲットRedshift設定 ステップ2.3: GlueでZero-ETL統合を作成 Glueで、Zero-ETL integrationsを選択し、新しい統合を作成します。ソースとターゲットを選択するだけで、データはSAPからRedshift Serverlessにシームレスに統合されます。作成したGlue SAP OData接続と統合ジョブを実行するロールを選択します。 図4. Zero-ETLソースSAP OData接続 SAP S/4HANAシステム内のSAP ODataサービスのリストが取得され、選択用に表示されます。このブログでは、購買発注用の4つのSAP ODataサービスを選択しました。 図5. SAPから購買発注ソースを選択 次はターゲットの選択です。現在、Glue Zero-ETLはターゲットとしてLakehouseまたはRedshiftをサポートしています。事前に作成したこのRedshift serverless名前空間のターゲットsapdatademoを選択します。 Redshift名前空間の大文字小文字区別パラメータを有効にしますが、まだ実行していない場合は、「Fix it for me」ボックスをチェックすることでGlueに実行させることができます。 図6. Zero-ETLターゲットRedshiftデータウェアハウス 4つのソースSAP ODataサービスを選択したため、選択されたオブジェクトがSettingsにリストされ、必要に応じてここでパーティションキーを変更できます。 図7. Zero-ETL統合のオブジェクト設定 レプリケーションの頻度と統合の名前を設定します。 図8. Zero-ETLの頻度と名前 図9. Redshiftコンソールでのゼロ-ETL統合の確認 最後の画面で、設定を確認して統合を作成します。統合が作成されたら、Redshiftサービスコンソールに移動し、Zero-ETL integrationメニューを開きます。作成された統合のステータスがactiveになったら、レプリケーションを開始するためにこの統合用のデータベースを作成する必要があります。 図10. Redshiftでデータベースを作成 3. Redshiftで抽出されたデータを確認 Zero-ETL統合が正常に実行されると、指定されたターゲットAmazon Redshift serverlessのデータベースに4つのテーブルが自動的に作成されたことがわかります。これらの4つのテーブルには、以前に選択した購買発注用の4つのSAP ODataサービスから抽出されたデータが保存されています。 図11. Redshift serverlessデータベースが作成されました 図12. Redshift ServerlessでのSAPデータのサンプルクエリ 4. データ変換 AWS Glue Zero-ETL統合は、SAP ODataからターゲットのAmazon S3上のData Lakehouseアーキテクチャ(図1のポイント4a)またはRedshiftデータウェアハウス(図1のポイント4b)にデータをレプリケートする簡単な方法を提供し、データ抽出ジョブの設定とメンテナンスの労力を必要としません。抽出されたデータをさらに変換したい場合は、AWS Glueを使用できます。Glue Visualジョブエディタでデータ抽出ジョブの後に変換ステップを含めることができます。 例えば、Glue Visualジョブで、作成したSAP OData接続でSAP購買発注ヘッダーと明細ODataサービスを選択し、ターゲットにデータを保存する前にスキーマ変換、テーブル結合変換を定義します。 図1のポイント4bでは、Amazon S3上のData Lakehouseアーキテクチャを使用しています。AWS Glue Catalogを、Amazon S3に保存されたデータの一元化されたメタデータリポジトリとして活用し、Amazon RedshiftなどのさまざまなAWSサービスからのアクセスを容易にします。 図13. SAPデータ抽出と変換のためのGlue Visualジョブ 5. Bedrock Knowledge Bases構造化データストアの作成 このブログでは、Glue Zero-ETLを使用してSAPからデータを抽出したRedshift serverless「sapdatademo」ワークスペースとデータベース「sapzeroetl」を、Bedrock Knowledge Baseのソースとして使用します。データが抽出されたら、Redshift接続の同期ステータスがCOMPLETEであることを確認します。 図14. Redshift serverlessを使用したAmazon Bedrock Knowledge Basesの作成 Amazon Bedrock Knowledge Basesにデータに関するより正確な理解を提供するために、ここでテーブルまたは列に関するメタデータまたは補足情報を提供できます。 図15. Redshift serverlessソースの補足情報 除外または含める列を定義し、キュレートされたクエリを定義することもできます。キュレートされたクエリは、データを取得するためにデータベースをクエリする事前定義された質問と回答例のSQLであり、生成されるSQL出力の精度を向上させることができます。 図16. Redshift serverlessの補足キュレートされたクエリ 6. チャットまたは生成AIアプリケーションのためのKnowledge Basesの統合 構造化データストア用のBedrock Knowledge Basesを作成した後、SAP購買発注に関するいくつかの質問でテストし、Bedrockによって生成されたSQLクエリの精度を確認できます。 図17. 質問とSQL生成を使用したBedrock Knowledge Basesのテスト AWSは、 Generative AI Use Cases (GenU) で独自のチャットアプリケーションを構築するソリューションを提供しています。このチャットアプリのAgent Chat機能を使用して、上記のSAPデータを含むBedrock Knowledge Basesをクエリできます。また、 Amazon Q businessでカスタムプラグイン を作成して、このKnowledge Baseと統合することもできます。別の方法として、Bedrock APIを使用して、このKnowledge Basesを統合し、ビジネスアプリケーションにSAPデータインサイトを生成することもできます。 図18. SAPデータウェアハウスと統合された生成AIチャットアプリケーション コストの考慮事項 以下は、バージニア北部リージョンで計算された、このアーキテクチャで使用される各コンポーネントのコスト例です。 サービス コンポーネント 説明 AWS Glue Zero-ETLジョブソース 任意のアプリケーションからAWS Glueによって取り込まれたデータに対して1GBあたり$1.50、MB単位で課金されます。 AWS Glue Zero-ETLジョブターゲット ターゲットがAmazon S3の場合: Amazon S3に書き込まれたzero-ETLデータを処理するコンピューティングに対してAWS Glue DPU時間あたり$0.44。 AWS Glue Data Catalog メタデータストレージ: 最初の100万オブジェクトは無料。100万を超える場合は月あたり10万オブジェクトごとに$1.00 メタデータリクエスト: 月あたり最初の100万リクエストは無料。100万を超える場合は100万リクエストごとに$1.00 メタデータ価格に基づいて計算するには、 AWS Glue pricing を参照してください。 Amazon Redshift Serverless Redshift Processing Unit RPU時間あたり$0.375 Amazon Redshift Redshift Managed Storage (RMS) リージョンのマネージドストレージに保存されたデータに対して固定のGB-月単位で支払います。例: $0.024/GB。 Amazon S3 Storage S3 ストレージ要件を計算するには、 Amazon S3 pricing を参照してください。 S3 Standard月額コスト: 最初の50 TB: $0.023/GB。次の450 TB: $0.022/GB。500 TBを超える: $0.021/GB Amazon Bedrock Knowledge Bases構造化データ取得(SQL生成) 1000クエリあたり$2.00 Amazon Bedrock その他のコスト: Large Language Modelの使用、チャットアプリケーションの構築 Bedrock pricing および Generative AI use case repository を参照してください。 ネットワーク接続は、ソースSAPシステムとお客様のネットワーク考慮事項によって異なるため、このブログではVPCピアリングやTransit Gatewayの価格などのネットワークコンポーネントは含めていません。AWSアカウントからRISEに接続する際の価格サンプルパターンについては、 RISE with SAP on AWS technical document を参照してください。 結論 Amazon Bedrock Knowledge Basesを通じた生成AIは、単なる別のテクノロジーソリューション以上のものを表しています。これは、組織がエンタープライズデータから価値を抽出する方法における根本的な変化を示しています。従来のSAPシステムと生成AIの革新的な機能の間のギャップを埋めることで、企業は既存のデータ資産を競争優位性の動的なソースに変換できるようになりました。 この変革的なテクノロジーを実装する旅は、3つの重要なステップから始まります: データランドスケープの評価 – 現在のデータエコシステムの包括的な評価を実施することから始めます。SAPシステムから外部データソースまで、貴重な情報がどこに存在するかを理解します。データフロー、潜在的な統合ポイントをマッピングし、データ資産の品質とアクセシビリティを評価します。この基盤は、成功する実装戦略を構築するために不可欠です。 高インパクトのユースケースの特定 – SAPと非SAPデータを組み合わせることで即座のビジネス価値を提供できる機会を探します。より良いインサイトが意思決定を大幅に改善し、お客様体験を向上させ、またはオペレーションを最適化できる領域に焦点を当てます。サプライチェーンの最適化、カスタマーサービスの強化、財務予測のいずれであっても、戦略的目標に合致するユースケースを優先します。 段階的な実装戦略の開発 – 実装には慎重なアプローチを取ります。迅速な成果を示しながら、チームが専門知識を構築できるパイロットプロジェクトから始めます。段階的な拡大を計画し、各フェーズが学んだ教訓に基づいて構築され、測定可能なビジネス価値を提供することを確保します。前述のセキュリティ、パフォーマンス、コスト最適化のベストプラクティスを組み込むことを忘れないでください。 エンタープライズデータインテリジェンスの未来はここにあり、Amazon Bedrock Knowledge Basesがその道を先導しています。これらの最初のステップを踏むことで、組織はデータ資産の潜在能力を最大限に活用し、イノベーションを推進し、ますますAI駆動型のビジネス環境において持続可能な競争優位性を創出し始めることができます。 貴重なエンタープライズデータを十分に活用されないままにしないでください。今こそ行動する時です – Amazon Bedrock Knowledge Basesでデータ駆動型変革への旅を始めましょう。 AWSとSAPからのAIイノベーションの恩恵を受ける お客様とパートナーの皆様を、 AWS-SAP AI Co-Innovation Program を通じて提供される最先端のAI機能を活用することにご招待できることを嬉しく思います。このイニシアチブは、SAPの深い業界専門知識とAWSの高度な生成AIサービスを結集し、複雑なビジネス課題を解決し、イノベーションを推進するお手伝いをします。このプログラムに参加することで、専任の技術リソース、クラウドクレジット、お客様固有のニーズに合わせた業界固有のAIアプリケーションを開発、テスト、デプロイするための専門家のガイダンスにアクセスできます。 さらに、 Amazon Q Developer for SAP ABAP をご紹介できることを嬉しく思います。これにより、ABAP開発者はSAP S/4HANA Cloud Private Edition向けの高度でクラウド対応、アップグレード安定なカスタムコードを作成できるようになります。このツールは、SAP環境内でのカスタマイズと拡張性の新たな可能性を開きます。 最後に、 CloudWatch MCP ServerとAmazon Qを通じてSAPオペレーションを最適化 し、実用的なインサイトを獲得し、全体的なレジリエンスを向上させる変革的な機会をお見逃しなく。これらの革新的なプログラムとテクノロジーからどのように恩恵を受けることができるかについては、今すぐSAPおよびAWSの担当者にお問い合わせください。 謝辞 以下のチームメンバーの貢献に感謝します: Sejun Kim、Akira Shimosako、Spencer Martenson、Kenjiro Kondo、Ambarish Satarkar。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本投稿は、 Manojit Saha Sardar と Chirantan Pandya による記事 「 Group database tables under AWS Database Migration Service tasks for PostgreSQL source engine 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) は、データベースやデータウェアハウスを含むデータリポジトリの転送と複製を容易にするために設計されたクラウドベースのサービスです。同種および異種のデータベースシステム間でデータを転送するソリューションを提供し、さまざまなデータプラットフォーム間の移行を可能にします。 データ転送プロセスは通常、大きく2 つのフェーズがあります： 既存データの移行 (フルロード) – このフェーズでは、AWS DMS が全てのデータ転送を実行し、元のデータストアから転送先のデータストアへ既存のすべての情報を転送します。 継続的な同期 (変更データキャプチャ) – 初期のフルロードの後、AWS DMS は変更データキャプチャ (CDC) と呼ばれている方法を通じて、データ変更の継続的な同期を可能にします。これらの変更はリアルタイムまたはニアリアルタイムで宛先のデータストアに継続的に転送され、適用されます。これにより、宛先のデータストアと元のデータストアが同期した状態を維持します。 AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベースなど、幅広い ソース および ターゲット データリポジトリに対応しています。転送を成功させるには、データベースとアプリケーションの前提条件に取り組むことが不可欠であり、初期段階でのベースとなる準備と計画がこの目標達成に重要な役割を果たします。 AWS DMS はデータベース移行のための堅牢なサービスを提供していますが、移行はプロジェクト毎にユニークであり、それぞれ異なる課題を抱えています。移行を成功させるために不可欠なことは適切な準備と設計プロセスです。パフォーマンスの最適化や潜在的な遅延問題への対処は特に重要です。 このブログ記事では、プロセスの早い段階でフルロードと CDC 遅延の潜在的な根本原因を把握するためのガイダンスを提供し、AWS DMS タスクで最高のパフォーマンスを達成するためにテーブルを適切にクラスタリングする方法を提示します。この記事で説明する戦略に従うことで、データベース移行をより効果的に計画し、タスクの規模を見積もり、潜在的な問題を最小限に抑え、パフォーマンスを最大化させるための効率的な転送プロセスを設計することができます。 データの把握 データ移行プロジェクトに着手するためには、最初に転送するデータを理解する必要があります。フルロードによる転送フェーズでは、ソース情報の完全なレプリカをターゲットのデータベースに転送することが含まれます。この手順により、正確なデータのコピーが、ソースデータベースからコピー先のデータベースに確実に入力されます。 CDC は、ソースのデータベースからのデータおよびデータ構造 (スキーマ) に対して発生した変更をリアルタイムまたはニアリアルタイムで記録する方法です。CDC は、これらの変更を他のデータベースやアプリケーションに配信し、簡単にソースのデータベースと同期し続けることができます。 必要な移行タスクの数やテーブルのグルーピングについて見積もるために、データベースのサイズ、運用負荷、およびハードウェア仕様を調べることで、データベース再配置のフルロードと CDC の要件全体を評価できます。 AWS DMS を利用する際、データ転送の速度に直接的または間接的に影響を与える要因はいくつかあります。以下は、フルロードと CDC の両方に共通する典型的な要因の一部です： データベースオブジェクトの規模 – 巨大なテーブル（ 2 TB を超えるもの）を専用の移行タスクで分離することで、移行効率を向上させることができます。大規模なデータセットの処理を特定のタスクや操作内で分離することで、転送プロセスがより効率的かつ効果的になる可能性があります。 セグメント化されたオブジェクトとされていないオブジェクト – 複数のテーブルを同時に読み込むことで、大きなセグメント化されたテーブルを転送できます。AWS DMS では、複数の並列スレッドを使用して単一の大規模テーブルを読み込むこともできます。これは、複数のセグメントとサブセグメントを持つ数十億レコードのテーブルに特に有効です。 主キーとユニークキーがないオブジェクト – AWS DMS は、大規模なオブジェクトを持つソーステーブルを転送するために、主キーまたはユニークキーを必要とします。 ラージオブジェクト（ LOB ） – AWS DMS は、レプリケーションインスタンスに適切なメモリを割り当てるために必要な、列行ごとの LOB サイズを特定することができないため、LOB 列には特別な処理が必要です。AWS DMS は、 LOB データを移行するためのフル、制限付き、インラインの LOB モード を提供しています。LOB を別のタスクに保持することで、転送アクティビティを効率的に管理できます。 変更量 – ワークロードに CDC の変更が大量に含まれる場合、同じレコードセットを繰り返し更新したり、同じレコードを挿入または更新して削除したりする場合は、 バッチ適用 を使用してターゲットへの適用スループットを向上させることができます。 ソリューションの概要 この投稿の目的は、ソースデータベースのデータディクショナリを分析し、その情報をハードウェアの詳細と組み合わせて、効率的なデータ移行タスクのための推奨事項を作成することです。この分析により、AWS DMS タスクの最適な数と、そのタスク内にあるテーブルのグループ分けを決定し、移行プロセス中の潜在的な遅延問題を軽減します。 このワークフローには、以下のステップが含まれます： ソースの PostgreSQL データベースにコントロールテーブルを作成します。 データディクショナリテーブルとビューを使用して、テーブルサイズ、パーティション、インデックス、制約、データ型、LOB データを分析し、コントロールテーブルにデータを入力します。 受信する変更量をモニタリングして、テーブルの日次による増加量を把握します。 ステップ番号でテーブルを分類します。 テーブルをグループ化します。 以下の図は、本ソリューションのアーキテクチャを示しています。 前提条件 以下の知識があると、このブログ記事が理解しやすくなります： AWS DMS PostgreSQL psql および plpgsql プロシージャ 1. ソースの PostgreSQL データベースでコントロールテーブル作成 この最初のステップでは、table_mapping という名前のコントロールテーブルを作成します。これにより、どのデータを移行しているかを一目で理解できるようになります。このテーブルは、システムカタログと統計ビューを参照して作成され、テーブルのサイズ、パーティション、パーティションサイズ (件数、平均、最小、最大)、LOB カラム、インデックス数、主キーまたはユニークキー制約、外部キー制約、およびテーブルに対する切り捨て、挿入、更新、削除操作の DDL (データ定義言語) / DML (データ操作言語) 操作回数に関する情報が含まれます。 このコントロールテーブルは、テーブルをグループ化する次のステップで使用するためのベースラインデータを提供します。 ソースの PostgreSQL データベースにコントロールテーブルを作成するには： ソースの PostgreSQL データベースに接続します。 以下の SQL ブロックを実行して、コントロールテーブルを作成します： CREATE TABLE TABLE_MAPPING ( OWNER VARCHAR(30), OBJECT_NAME VARCHAR(30), OBJECT_TYPE VARCHAR(30), SIZE_IN_MB NUMERIC(12,4), STEP INTEGER, IGNORE CHAR(3), PARTITIONED CHAR(3), PART_NUM INTEGER, SPECIAL_HANDLING CHAR(3), PK_PRESENT CHAR(3), UK_PRESENT CHAR(3), LOB_COLUMN INTEGER, GROUPNUM INTEGER, TOTAL_DML INTEGER ); 2. コントロールテーブルへの入力 コントロールテーブルが作成できたところで、PostgreSQLデータベース内のシステムカタログおよび統計ビューを用いてコントロールテーブルにデータを格納できます。これらはデータベースオブジェクトに関連するサイズ、タイプ、パーティショニング、制約、LOBデータに関する情報を提供します。具体的には、以下のデータディクショナリオブジェクトが挙げられます： PG_TABLES – PostgreSQL データベース内の各テーブルに関する有用な情報へのアクセスを提供します。 PG_PARTITIONED_TABLE – このカタログテーブルは、テーブルがどのようにパーティション化されているかに関する情報を格納します。 PG_INHERITS – このカタログテーブルは、テーブルとインデックスの継承階層に関する情報を記録します。データベース内の各直接的な親子テーブルまたはインデックスの関係に対して 1 つのエントリが存在します。 PG_CLASS – このカタログテーブルは、列を持つテーブルやインデックス、シーケンス、ビュー、マテリアライズドビュー、複合型、TOAST テーブルなどのその他のオブジェクトについて説明します。 PG_NAMESPACE – このカタログテーブルは名前空間を格納します。名前空間は SQL スキーマの基礎となる構造です。各名前空間は、名前の競合なしに、リレーションと型の個別のコレクションを持つことができます。 INFORMATION_SCHEMA.COLUMNS – データベース内のテーブルとビューの列に関するメタデータを提供します。これは、異なるデータベースシステム間でテーブル構造に関する情報にアクセスするための標準的な方法です。 これらのカタログとビューオブジェクトをクエリすることで、データベースオブジェクトに関するメタデータを取得できます。これにより、データベース内のさまざまなオブジェクトの構造、サイズ、制約、および変更点を特定し分析することができます。 それでは、システムカタログと統計ビューからコントロールテーブルに読み込みます： 対象スキーマ (ここでは 'admin' を使用) にあるデータベーステーブルの詳細 (名前、サイズ、パーティションなど) をコントロールテーブルに挿入します： INSERT INTO admin.table_mapping(OWNER, OBJECT_NAME, OBJECT_TYPE, SIZE_IN_MB, PART_NUM, PARTITIONED) SELECT schemaname, tablename, 'TABLE', pg_total_relation_size(schemaname || '.' || tablename) / 1024.0 / 1024.0, CASE WHEN EXISTS ( SELECT 1 FROM pg_partitioned_table pt JOIN pg_class c ON c.oid = pt.partrelid WHERE c.relname = tablename ) THEN ( SELECT count(*) FROM pg_inherits WHERE inhparent = (schemaname || '.' || tablename)::regclass ) ELSE 1 END, CASE WHEN EXISTS ( SELECT 1 FROM pg_partitioned_table pt JOIN pg_class c ON c.oid = pt.partrelid WHERE c.relname = tablename ) THEN 'YES' ELSE 'NO' END FROM pg_tables WHERE schemaname = 'admin'; 'admin' スキーマのマッピングテーブルから子テーブルデータをクリーンアップします： DELETE FROM admin.table_mapping WHERE object_name IN (SELECT child.relname AS child_table FROM pg_inherits JOIN pg_class parent ON pg_inherits.inhparent = parent.oid JOIN pg_class child ON pg_inherits.inhrelid = child.oid JOIN pg_namespace nmsp_parent ON nmsp_parent.oid = parent.relnamespace JOIN pg_namespace nmsp_child ON nmsp_child.oid = child.relnamespace WHERE parent.relkind = 'p' and nmsp_child.nspname ='admin'); 親テーブルのパーティションテーブルサイズを設定します： WITH partition_sizes AS ( SELECT parent_schema, parent_table, SUM(partition_size)/(1024*1024) as size_mb -- バイトを MB に変換 FROM ( SELECT nmsp_parent.nspname AS parent_schema, parent.relname AS parent_table, pg_total_relation_size(child.oid) AS partition_size FROM pg_inherits JOIN pg_class parent ON pg_inherits.inhparent = parent.oid JOIN pg_class child ON pg_inherits.inhrelid = child.oid JOIN pg_namespace nmsp_parent ON nmsp_parent.oid = parent.relnamespace JOIN pg_namespace nmsp_child ON nmsp_child.oid = child.relnamespace WHERE parent.relkind = 'p' ) subquery GROUP BY parent_schema, parent_table ) UPDATE admin.table_mapping tm SET SIZE_IN_MB = ps.size_mb FROM partition_sizes ps WHERE tm.OWNER = ps.parent_schema AND tm.OBJECT_NAME = ps.parent_table ; 主キーが定義されているコントロールテーブルの PK_PRESENT フィールドを更新します： UPDATE admin.table_mapping SET PK_PRESENT = CASE WHEN EXISTS ( SELECT 1 FROM information_schema.table_constraints WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND constraint_type = 'PRIMARY KEY' ) THEN 'YES' ELSE 'NO' END ; ユニークキーが定義されているコントロールテーブルの UK_PRESENT フィールドを更新します： UPDATE admin.table_mapping SET UK_PRESENT = CASE WHEN EXISTS ( SELECT 1 FROM information_schema.table_constraints WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND constraint_type = 'UNIQUE' ) THEN 'YES' ELSE 'NO' END ; 少なくとも 1 つの LOB カラムを持つコントロールテーブルの LOB_COLUMN フィールドを更新します： UPDATE admin.table_mapping SET LOB_COLUMN = ( SELECT COUNT(*) FROM information_schema.columns WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND data_type IN ('bytea', 'text', 'json', 'jsonb') ); 3. 時間経過に伴う DML 変更量の把握 PostgreSQL データベースの pg_stat_user_tables システムビューには、最後に統計情報が収集されてから、データベース内のすべてのテーブルに対して行われた変更に関する情報が含まれています。PostgreSQL は pg_stat_user_tables を使用して、PostgreSQL 統計コレクターに基づくテーブルの DML と統計情報を収集します。最後の自動バキューム（ autovacuum ）のタイムスタンプは、タイミング情報を取得するために使用されます。定期的な ANALYZE 操作がテーブルに対して実行され、DML の変更に関する情報と最後の分析時間で pg_stat_user_tables を更新します。 毎日のデータを確認することで、テーブルに加えられた日々の変更についてのインサイトを得ることができます。この情報は、パフォーマンスに影響を与えたり、統計の収集や再編成などのメンテナンスタスクが必要になったりする可能性のある、多数の変更が加えられたテーブルを特定するのに役立ちます。 時間経過に伴う DML の変更量を把握するには： pg_stat_user_tables から詳細を取得するために、 MST_DBA_TAB_MOD というステージングテーブルを作成します： CREATE TABLE admin.mst_dba_tab_mod ( DATA_DATE DATE, TABLE_OWNER VARCHAR(128), TABLE_NAME VARCHAR(128), PARTITION_NAME VARCHAR(128), SUBPARTITION_NAME VARCHAR(128), INSERTS BIGINT, UPDATES BIGINT, DELETES BIGINT, TIMESTAMP TIMESTAMP, TRUNCATED VARCHAR(3), TOTAL_DML BIGINT, DROP_SEGMENTS BIGINT ); PostgreSQL の pg_stat_user_tables システムビューから情報を収集し、テーブルの日次平均 DML カウントで MST_DBA_TAB_MOD テーブルを更新します。 カウントは最後に分析された日付から記録され、平均化されるため、最新のテーブル統計情報を持つことでカウントの精度が向上します。 INSERT INTO admin.mst_dba_tab_mod ( TABLE_OWNER, TABLE_NAME, INSERTS, UPDATES, DELETES, TOTAL_DML, TIMESTAMP ) SELECT schemaname AS TABLE_OWNER, relname AS TABLE_NAME, n_tup_ins AS INSERTS, n_tup_upd AS UPDATES, n_tup_del AS DELETES, ROUND((n_tup_ins + n_tup_upd + n_tup_del)::numeric / GREATEST(EXTRACT(EPOCH FROM (now() - last_autovacuum))::numeric / 86400, 1)) AS TOTAL_DML, now() AS TIMESTAMP FROM pg_stat_user_tables WHERE schemaname = 'admin'; 次に、前のステップで埋めた MST_DBA_TAB_MOD からこの情報を収集する以下の UPDATE 文を実行して、コントロールテーブル table_mapping_mapping に DML 情報を入力します： UPDATE admin.table_mapping a SET TOTAL_DML = b.TOTAL_DML FROM admin.mst_dba_tab_mod b WHERE a.OWNER = b.TABLE_OWNER AND a.OBJECT_NAME = b.TABLE_NAME AND b.TABLE_OWNER = 'admin'; 4. テーブルのステップ番号による分類 以下のコードに示すように、テーブルはデータ特性に関するさまざまな要因を基にデータベース内で分類されます。これらの要因には、テーブルがパーティション化されているかどうか、LOB を含むかどうか、テーブルサイズ、テーブルに対して実行された DML 操作の数などが含まれます。LOB フィールドを持たない非パーティション化テーブルはステップ 1 に分類され、LOB フィールドを持つ非パーティション化テーブルはステップ 2 に、LOB フィールドを持たないパーティション化テーブルはステップ 3 に分類され、以下同様に分類されます。例えば、SIZE_IN_MB が 0 と報告されるすべてのテーブルは、移行の対象外として分類されます。ユースケースに応じて、このステップに追加のテーブルを加えることができます。 これらの属性に基づくテーブルの分類は、最適化を目的として行われます。 UPDATE admin.table_mapping SET STEP = 1 WHERE LOB_COLUMN = 0 AND PARTITIONED = 'NO' AND STEP IS NULL ; UPDATE admin.table_mapping SET STEP = 2 WHERE LOB_COLUMN > 0 AND PARTITIONED = 'NO' AND STEP IS NULL ; UPDATE admin.table_mapping SET STEP = 3 WHERE LOB_COLUMN = 0 AND PARTITIONED = 'YES' AND STEP IS NULL ; UPDATE admin.table_mapping SET STEP = 4 WHERE LOB_COLUMN > 0 AND PARTITIONED = 'YES' AND STEP IS NULL ; UPDATE admin.table_mapping SET STEP = 5 WHERE TOTAL_DML > 9999999 ; UPDATE admin.table_mapping SET STEP = 0 WHERE SIZE_IN_MB = 0 AND STEP IS NULL ; 5. データベーステーブルのグループ化 グループの推奨プロセスは、 TABLE_MAPPING コントロールテーブルに格納された情報に基づいて TABLE_MAPPING_GROUPS テーブルを作成し、データを作成することから始まります。このプロセスは、3 つのパラメータを受け取るプロシージャによって開始されます。 マッピングテーブル ( TABLE_MAPPING ) ソースの移行スキーマ ( ADMIN ) タスクごとのデータベースオブジェクトのサイズ ( 600 GB ) タスクごとのデータベースオブジェクトのサイズ (600 GB) は、ソースおよびターゲットのレプリケーションインスタンスの CPU、ネットワーク、I/O 能力などの要因を考慮し、タスク間でテーブルを均等に分散するように選択されています。 シェルスクリプトを使用して admin.both ストアドプロシージャを呼び出し、テーブルをグループ化します。その後、プロシージャ内のセクションを使用して、パーティションテーブルと非パーティションテーブルの両方に対して step と groupnum を使用してグループ化されたテーブルをリストします。 CREATE OR REPLACE PROCEDURE admin.both ( IN p_n NUMERIC, IN p_schema_name VARCHAR, IN p_table_name VARCHAR ) AS $BODY$ DECLARE vTab CHARACTER VARYING(30); vDumpSize DOUBLE PRECISION := 0 ; vSumBytes DOUBLE PRECISION := 0 ; vGroupNum DOUBLE PRECISION := 0 ; vPrevStep DOUBLE PRECISION := 1 ; reggrouptabs RECORD ; BEGIN vDumpSize := 1024 * p_n ; -- Dynamic SQL to truncate the table EXECUTE format('TRUNCATE %I.%I_groups', p_schema_name, p_table_name); -- Dynamic SQL to insert data EXECUTE format(' INSERT INTO %I.%I_groups SELECT owner, object_name, object_type, size_in_mb, step, ignore, partitioned FROM %I.%I', p_schema_name, p_table_name, p_schema_name, p_table_name); FOR reggrouptabs IN EXECUTE format(' SELECT * FROM %I.%I_groups ORDER BY step, size_in_mb', p_schema_name, p_table_name) LOOP IF (reggrouptabs.step != vPrevStep) THEN vGroupNum := 0 ; vSumBytes := 0 ; END IF ; vSumBytes := vSumBytes + reggrouptabs.size_in_mb ; IF (vSumBytes >= vDumpSize) THEN vGroupNum := vGroupNum + 1 ; vSumBytes := 0 ; END IF ; -- Dynamic SQL for UPDATE EXECUTE format(' UPDATE %I.%I_groups SET groupnum = $1 WHERE owner = $2 AND object_name = $3', p_schema_name, p_table_name) USING vGroupNum, reggrouptabs.owner, reggrouptabs.object_name ; vPrevStep := reggrouptabs.step ; END LOOP ; COMMIT ; END ; $BODY$ LANGUAGE plpgsql ; 以下の select ステートメントを実行して、 table_mapping_groups を繰り返し処理し、それぞれのグループ名ごとにテーブル名をリストすることで、最終的な plpgsql プロシージャの出力を収集できます。これは、対応する AWS DMS タスクを作成するために使用できます： SELECT partitioned,step, groupnum, count(1) table_in_group,sum(size_in_mb) Total_group_size FROM admin.table_mapping_groups group by partitioned,step, groupnum ORDER BY 1,2,3 ; デモンストレーション この投稿のソリューションを実証するために、6.2 TB のデータ転送用の PostgreSQL ソースインスタンスを使用し、DMS タスクごとに 600 GB のサイズ内でテーブルをグループ化します。構成には、8 コア、16 vCPU、64 GiB のメモリを備えた db.m5.4xlarge インスタンスを使用しています。CPU 使用率、ネットワークスループット、および運用負荷の評価に基づき、600 GB 単位でタスクを作成することが、このワークロードに最適であると判断されました。ただし、各ソースには固有の特性があるため、適切なクラスターサイズを決定するには、特定のソースデータベースの規模、ワークロード、CPU、メモリ、およびネットワーク使用率を徹底的に分析する必要があります。 このプロセスは、ループテーブルからステップ情報を降順に整理し、その後、定義されたサイズパラメータに従って整理されたデータをクラスタリングする方法を実装しています。 個々のステップを手動で実行する必要がないように、以下の手順をシェルスクリプトに統合しました。 ソースの PostgreSQL データベースにコントロールテーブルを作成します。 データディクショナリのテーブルとビューを使用して、テーブルサイズ、パーティション、インデックス、制約、データ型、LOB データを分析し、コントロールテーブルにデータを投入します。 受信する変更の量をモニタリングすることで、テーブルの日次による増加量を把握します。 ステップ番号でテーブルを分類します。 以下のコードは、対応するシェルスクリプトです： #!/bin/bash # Collect database connection details echo "Please enter database connection details:" read -p "Database name [postgres]: " DB_NAME DB_NAME=${DB_NAME:-postgres} read -p "Database user [postgres]: " DB_USER DB_USER=${DB_USER:-postgres} read -p "Database host [localhost]: " DB_HOST DB_HOST=${DB_HOST:-localhost} read -p "Database port [5432]: " DB_PORT DB_PORT=${DB_PORT:-5432} read -s -p "Database password: " password DB_PASSWORD=$password # Export variables for psql to use export PGPASSWORD="$DB_PASSWORD" # Function to execute psql query and return result execute_query() { psql -U "$DB_USER" \ -h "$DB_HOST" \ -p "$DB_PORT" \ -d "$DB_NAME" \ -t -A \ -c "$1" } # Test connection echo -e "\nTesting database connection..." if ! execute_query "SELECT 1 ;" > /dev/null 2>&1 ; then echo "Error: Could not connect to the database. Please check your credentials." exit 1 fi echo "Connection successful!" # Example 1: Simple SELECT query #echo -e "\nExample 1: List of users" #users=$(execute_query "SELECT usename FROM pg_catalog.pg_user ;") #echo "$users" echo -e "\nCreating the control table" table_ddl=$(execute_query "CREATE TABLE TABLE_MAPPING ( OWNER VARCHAR(30), OBJECT_NAME VARCHAR(30), OBJECT_TYPE VARCHAR(30), SIZE_IN_MB NUMERIC(12,4), STEP INTEGER, IGNORE CHAR(3), PARTITIONED CHAR(3), PART_NUM INTEGER, SPECIAL_HANDLING CHAR(3), PK_PRESENT CHAR(3), UK_PRESENT CHAR(3), LOB_COLUMN INTEGER, GROUPNUM INTEGER, TOTAL_DML INTEGER );") echo "$table_ddl" echo -e "\nCleaning up the old control table" clean_ddl=$(execute_query "TRUNCATE TABLE admin.table_mapping ;") echo "$clean_ddl" echo -e "\nInsert into the control table the database table details " table_insert=$(execute_query "INSERT INTO admin.table_mapping(OWNER, OBJECT_NAME, OBJECT_TYPE, SIZE_IN_MB, PART_NUM, PARTITIONED) SELECT schemaname, tablename, 'TABLE', pg_total_relation_size(schemaname || '.' || tablename) / 1024.0 / 1024.0, CASE WHEN EXISTS ( SELECT 1 FROM pg_partitioned_table pt JOIN pg_class c ON c.oid = pt.partrelid WHERE c.relname = tablename ) THEN ( SELECT count(*) FROM pg_inherits WHERE inhparent = (schemaname || '.' || tablename)::regclass ) ELSE 1 END, CASE WHEN EXISTS ( SELECT 1 FROM pg_partitioned_table pt JOIN pg_class c ON c.oid = pt.partrelid WHERE c.relname = tablename ) THEN 'YES' ELSE 'NO' END FROM pg_tables WHERE schemaname = 'admin';") echo "$table_insert" echo -e "\nCleaning up child table data" clean_dml=$(execute_query "DELETE FROM admin.table_mapping WHERE object_name IN (SELECT child.relname AS child_table FROM pg_inherits JOIN pg_class parent ON pg_inherits.inhparent = parent.oid JOIN pg_class child ON pg_inherits.inhrelid = child.oid JOIN pg_namespace nmsp_parent ON nmsp_parent.oid = parent.relnamespace JOIN pg_namespace nmsp_child ON nmsp_child.oid = child.relnamespace WHERE parent.relkind = 'p' and nmsp_child.nspname ='admin') ; ;") echo "$clean_dml" echo -e "\nPopulate partition table size" pop_part=$(execute_query "WITH partition_sizes AS ( SELECT parent_schema, parent_table, SUM(partition_size)/(1024*1024) as size_mb -- Convert bytes to MB FROM ( SELECT nmsp_parent.nspname AS parent_schema, parent.relname AS parent_table, pg_total_relation_size(child.oid) AS partition_size FROM pg_inherits JOIN pg_class parent ON pg_inherits.inhparent = parent.oid JOIN pg_class child ON pg_inherits.inhrelid = child.oid JOIN pg_namespace nmsp_parent ON nmsp_parent.oid = parent.relnamespace JOIN pg_namespace nmsp_child ON nmsp_child.oid = child.relnamespace WHERE parent.relkind = 'p' ) subquery GROUP BY parent_schema, parent_table ) UPDATE admin.table_mapping tm SET SIZE_IN_MB = ps.size_mb FROM partition_sizes ps WHERE tm.OWNER = ps.parent_schema AND tm.OBJECT_NAME = ps.parent_table ;") echo "$pop_part" echo -e "\nUpdate the PK_PRESENT field of the control table" pk_present=$(execute_query "UPDATE admin.table_mapping SET PK_PRESENT = CASE WHEN EXISTS ( SELECT 1 FROM information_schema.table_constraints WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND constraint_type = 'PRIMARY KEY' ) THEN 'YES' ELSE 'NO' END ;") echo "$pk_present" echo -e "\nUpdate the UK_PRESENT field of the control table " uk_present=$(execute_query "UPDATE admin.table_mapping SET UK_PRESENT = CASE WHEN EXISTS ( SELECT 1 FROM information_schema.table_constraints WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND constraint_type = 'UNIQUE' ) THEN 'YES' ELSE 'NO' END ;") echo "$uk_present" echo -e "\nUpdate the LOB_COLUMN field of the control table " lob_column=$(execute_query "UPDATE admin.table_mapping SET LOB_COLUMN = ( SELECT COUNT(*) FROM information_schema.columns WHERE table_schema = OWNER AND table_name = OBJECT_NAME AND data_type IN ('bytea', 'text', 'json', 'jsonb') );") echo "$lob_column" echo -e "\nCreate a staging table called MST_DBA_TAB_MOD to get the details from pg_stat_user_tables" table_ddl=$(execute_query "CREATE TABLE admin.mst_dba_tab_mod ( DATA_DATE DATE, TABLE_OWNER VARCHAR(128), TABLE_NAME VARCHAR(128), PARTITION_NAME VARCHAR(128), SUBPARTITION_NAME VARCHAR(128), INSERTS BIGINT, UPDATES BIGINT, DELETES BIGINT, TIMESTAMP TIMESTAMP, TRUNCATED VARCHAR(3), TOTAL_DML BIGINT, DROP_SEGMENTS BIGINT );") echo "$table_ddl" echo -e "\nPopulate the MST_DBA_TAB_MOD table with the daily average DML count for the tables " table_dml=$(execute_query "INSERT INTO admin.mst_dba_tab_mod ( TABLE_OWNER, TABLE_NAME, INSERTS, UPDATES, DELETES, TOTAL_DML, TIMESTAMP ) SELECT schemaname AS TABLE_OWNER, relname AS TABLE_NAME, n_tup_ins AS INSERTS, n_tup_upd AS UPDATES, n_tup_del AS DELETES, ROUND((n_tup_ins + n_tup_upd + n_tup_del)::numeric / GREATEST(EXTRACT(EPOCH FROM (now() - last_autovacuum))::numeric / 86400, 1)) AS TOTAL_DML, now() AS TIMESTAMP FROM pg_stat_user_tables WHERE schemaname = 'admin';") echo "$table_dml" echo -e "\nPopulate the DML information in the control table_mapping_mapping table " load_dml=$(execute_query "UPDATE admin.table_mapping a SET TOTAL_DML = b.TOTAL_DML FROM admin.mst_dba_tab_mod b WHERE a.OWNER = b.TABLE_OWNER AND a.OBJECT_NAME = b.TABLE_NAME AND b.TABLE_OWNER = 'admin'; ") echo "$load_dml" echo -e "\nCategorize the tables by step number" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 1 WHERE LOB_COLUMN = 0 AND PARTITIONED = 'NO' AND STEP IS NULL ;") echo "$update_dml" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 2 WHERE LOB_COLUMN > 0 AND PARTITIONED = 'NO' AND STEP IS NULL ;") echo "$update_dml" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 3 WHERE LOB_COLUMN = 0 AND PARTITIONED = 'YES' AND STEP IS NULL ;") echo "$update_dml" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 4 WHERE LOB_COLUMN > 0 AND PARTITIONED = 'YES' AND STEP IS NULL ;") echo "$update_dml" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 5 WHERE TOTAL_DML > 9999999 ;") echo "$update_dml" update_dml=$(execute_query "UPDATE admin.table_mapping SET STEP = 0 WHERE SIZE_IN_MB = 0 AND STEP IS NULL ;") echo "$update_dml" # Clear password from environment unset PGPASSWORD echo -e "\nScript execution completed" 以下はスクリプトを実行した結果で、簡単に参照できるように実行のさまざまなステップを示しています。 [ec2-user@ip-10-0-0-40 ~ ]$ ./pg_table_grouping.sh Please enter database connection details: Database name [postgres]: Database user [postgres]: Database host [localhost]: pg-dms-target.caub0zqkqtdt.us-east-1.rds.amazonaws.com Database port [5432]: Database password: Testing database connection... Connection successful! Creating the control table ERROR: relation "table_mapping" already exists Cleaning up the old control table TRUNCATE TABLE Insert into the control table the database table details INSERT 0 287 Cleaning up child table data DELETE 192 Populate partition table size UPDATE 19 Update the PK_PRESENT field of the control table UPDATE 95 Update the UK_PRESENT field of the control table UPDATE 95 Update the LOB_COLUMN field of the control table UPDATE 95 Create a staging table called MST_DBA_TAB_MOD to get the details from pg_stat_user_tables ERROR: relation "mst_dba_tab_mod" already exists Populate the MST_DBA_TAB_MOD table with the daily average DML count for the tables INSERT 0 287 Populate the DML information in the control table_mapping_mapping table UPDATE 95 Categorize the tables by step number UPDATE 56 UPDATE 20 UPDATE 6 UPDATE 13 UPDATE 0 UPDATE 0 Script execution completed 以下のコードは、コントロールテーブル table_mapping のスニペットです。このテーブルは、このセクションで先ほど示したシェルスクリプトを実行した後、データディクショナリから入力されます。 owner | object_name | object_type | size_in_mb | step | ignore | partitioned | part_num | special_handling | pk_present | uk_present | lob_column | groupnum | total_dml -------+----------------------------------------+-------------+------------+------+--------+-------------+----------+------------------ +------------+------------+------------+----------+----------- admin | bonus_1 | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | bonus | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | bonus_cap | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | bonus_2 | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | bonus_3 | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | canada | TABLE | 0.0156 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | apple | TABLE | 0.0156 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | austin | TABLE | 0.0156 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | dept_2 | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | dept_1 | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | dept_3 | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | dept_cap | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | dummy | TABLE | 0.0078 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | mango | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | lob_col_info | TABLE | 0.0078 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | emp | TABLE | 0.0000 | 1 | | NO | 1 | | NO | NO | 0 | | 0 admin | emp_1 | TABLE | 0.0078 | 1 | | NO | 1 | | YES | NO | 0 | | 0 admin | emp_3 | TABLE | 0.0078 | 1 | | NO | 1 | 以下は、table_mappingを出力したスクリーンショットです。: テーブルグループ化スクリプトを実行すると、最終的な出力は6つの初期ステップ番号、0 – 5 で構成されます: 0 は特別な処理を行うテーブルを無視またはスキップする場合 1 は LOB フィールドのない非パーティション化テーブルの場合 2 は LOB フィールドのある非パーティション化テーブルの場合 3 は LOB フィールドのないパーティション化テーブルの場合 4 は LOB フィールドのあるパーティション化テーブルの場合 5 は DML 操作が多いテーブルの場合 次に、テーブルグループ化シェルスクリプトを実行して、最終的なテーブルごとのグループを作成します。グループの一部であるテーブルは、単一の AWS DMS タスクに含まれます。このコードの詳細については、このブログ投稿の前のセクションを参照してください。 以下のシェルスクリプトは、テーブルの最終的なグループ化を作成します： #!/bin/bash # Collect database connection details echo "Please enter database connection details:" read -p "Database name [postgres]: " DB_NAME DB_NAME=${DB_NAME:-postgres} read -p "Database user [postgres]: " DB_USER DB_USER=${DB_USER:-postgres} read -p "Database host [localhost]: " DB_HOST DB_HOST=${DB_HOST:-localhost} read -p "Database port [5432]: " DB_PORT DB_PORT=${DB_PORT:-5432} read -s -p "Database password: " password DB_PASSWORD=$password # Export variables for psql to use export PGPASSWORD="$DB_PASSWORD" # Function to execute psql query and return result execute_query() { psql -U "$DB_USER" \ -h "$DB_HOST" \ -p "$DB_PORT" \ -d "$DB_NAME" \ -t -A \ -c "$1" } # Test connection echo -e "\nTesting database connection..." if ! execute_query "SELECT 1 ;" > /dev/null 2>&1 ; then echo "Error: Could not connect to the database. Please check your credentials." exit 1 fi echo "Connection successful!" # Step 1: Create the plpgsql procedure echo -e "\nCreating plpgsql procedure..." create_procedure_query=$(cat << EOF CREATE OR REPLACE PROCEDURE admin.both ( IN p_n NUMERIC, IN p_schema_name VARCHAR, IN p_table_name VARCHAR ) AS \$BODY\$ DECLARE vTab CHARACTER VARYING(30); vDumpSize DOUBLE PRECISION := 0 ; vSumBytes DOUBLE PRECISION := 0 ; vGroupNum DOUBLE PRECISION := 0 ; vPrevStep DOUBLE PRECISION := 1 ; reggrouptabs RECORD ; BEGIN vDumpSize := 1024 * p_n ; -- Dynamic SQL to truncate the table EXECUTE format('TRUNCATE %I.%I_groups', p_schema_name, p_table_name); -- Dynamic SQL to insert data EXECUTE format(' INSERT INTO %I.%I_groups SELECT owner, object_name, object_type, size_in_mb, step, ignore, partitioned FROM %I.%I', p_schema_name, p_table_name, p_schema_name, p_table_name); FOR reggrouptabs IN EXECUTE format(' SELECT * FROM %I.%I_groups ORDER BY step, size_in_mb', p_schema_name, p_table_name) LOOP IF (reggrouptabs.step != vPrevStep) THEN vGroupNum := 0 ; vSumBytes := 0 ; END IF ; vSumBytes := vSumBytes + reggrouptabs.size_in_mb ; IF (vSumBytes >= vDumpSize) THEN vGroupNum := vGroupNum + 1 ; vSumBytes := 0 ; END IF ; -- Dynamic SQL for UPDATE EXECUTE format(' UPDATE %I.%I_groups SET groupnum = \$1 WHERE owner = \$2 AND object_name = \$3', p_schema_name, p_table_name) USING vGroupNum, reggrouptabs.owner, reggrouptabs.object_name ; vPrevStep := reggrouptabs.step ; END LOOP ; COMMIT ; END ; \$BODY\$ LANGUAGE plpgsql ; EOF ) execute_query "$create_procedure_query" echo "Procedure created successfully!" # Step 2: Execute the plpgsql procedure echo -e "\nExecuting the procedure..." read -p "Enter p_n value: " p_n read -p "Enter p_schema_name: " p_schema_name read -p "Enter p_table_name: " p_table_name execute_procedure_query="CALL admin.both($p_n, '$p_schema_name', '$p_table_name');" execute_query "$execute_procedure_query" echo "Procedure executed successfully!" # Step 3: Execute the SELECT query and display results echo -e "\nExecuting SELECT query..." select_query=" SELECT partitioned, step, groupnum as substep, count(1) as table_in_group, round(sum(size_in_mb)/1024, 2) as Total_size_GB FROM admin.table_mapping_groups GROUP BY partitioned, step, groupnum ORDER BY 1,2,3 ; " echo " ********************************************************* Tables are grouped based on ${p_n}GB size ********************************************************* 1(10,11,...) --> Non Partition Table. 2(20,21....) --> Non Partition Table(LOB) 3(30,31...) --> Partition Table. 4(40,41...) --> Partition Table(LOB). 5(50,51...) --> High DML Table. 0(0,99) --> Ignore or Skip/Special Handling table. ********************************************************** " # First display the traditional output result=$(execute_query "$select_query") echo -e "\nQuery Results:" echo -e "partitioned\tstep\tsubstep\ttable_in_group\tTotal_size_GB" echo "$result" | sed 's/|/\t/g' # Now generate the formatted output echo -e "\nDetailed Group Summary:" formatted_query=" WITH grouped_data AS ( SELECT concat(step, groupnum) as group_number, count(1) as table_count, round(sum(size_in_mb)/1024, 2) as size_gb, CASE WHEN step = 0 THEN ' comprising of ignored objects' WHEN step = 1 THEN ' with no partitions' WHEN step = 2 THEN ' with no partitions but containing lob fields' WHEN step = 3 THEN ' with partitions' WHEN step = 4 THEN ' with partitions and containing lob fields' WHEN step = 5 THEN ' with high DML change' ELSE '' END as description FROM admin.table_mapping_groups GROUP BY step, groupnum ORDER BY concat(step, groupnum) ) SELECT format('Group number %s will have %s table%s with size of %s GB%s.', group_number, table_count, CASE WHEN table_count = 1 THEN '' ELSE 's' END, to_char(size_gb, 'FM999,999'), description) FROM grouped_data WHERE group_number != '099'; " execute_query "$formatted_query" | while read -r line ; do echo "$line" done # Clear password from environment unset PGPASSWORD echo -e "\nScript execution completed" この plpgsql プロシージャは、データテーブルの移行に関する最終的な推奨事項を生成します。これには、以下のステップを含む plpgsql ブロックの実行が含まれます： 既存の table_mapping_groups という名前のテーブルを確認し、削除して新しいテーブルを作成します。 TABLE_MAPPING から新しい table_mapping_groups テーブルを作成します。 LOB 列と非 LOB 列を持つパーティション化されたテーブルを、600 GB のグループサイズに基づいてグループ化し、10、11、12、13 などのグループを作成します。 同様の手順で、LOB 列と非 LOB 列を持つ非パーティション化テーブルをグループ化します。 このプロセスでは、特別な処理が必要なテーブルを個別のグループに分けたり、特定の要件に基づいて移行から除外したりすることで対応します。ここで説明する移行プロセスはユニークであり、ケースの要件によって異なる場合があります。以下のコード例では、テーブルを ${groupsize} の 600 GB に基づいてグループ化しています： [ec2-user@ip-10-0-0-40 ~ ]$ ./pg_both.sh Please enter database connection details: Database name [postgres]: Database user [postgres]: Database host [localhost]: pg-dms-target.caub0zqkqtdt.us-east-1.rds.amazonaws.com Database port [5432]: Database password: Testing database connection... Connection successful! Creating plpgsql procedure... CREATE PROCEDURE Procedure created successfully! Executing the procedure... Enter p_n value: 600 Enter p_schema_name: admin Enter p_table_name: table_mapping CALL Procedure executed successfully! Executing SELECT query... ********************************************************* Tables are grouped based on 600GB size ********************************************************* 1(10,11,...) --> Nonpartitioned table 2(20,21....) --> Nonpartitioned table(LOB) 3(30,31...) --> Partitioned table 4(40,41...) --> Partitioned table(LOB) 5(50,51...) --> High DML table 0(0,99) --> Ignore or skip/special handling table ********************************************************** Query Results: partitioned step substep table_in_group Total_size_GB NO 0 0 2 0.00 NO 1 0 52 332.71 NO 1 1 2 837.89 NO 2 0 13 413.36 NO 2 1 2 467.77 NO 2 2 1 408.13 NO 2 3 1 648.07 NO 2 4 1 1440.51 NO 2 5 1 1620.33 NO 5 0 1 7.57 YES 3 0 6 0.62 YES 4 0 12 147.91 YES 5 0 1 28.99 Detailed Group Summary: Group number 00 will have 2 tables with size of 0 GB comprising ignored objects. Group number 10 will have 52 tables with size of 333 GB with no partitions. Group number 11 will have 2 tables with size of 838 GB with no partitions. Group number 20 will have 13 tables with size of 413 GB with no partitions but containing lob fields. Group number 21 will have 2 tables with size of 468 GB with no partitions but containing lob fields. Group number 22 will have 1 table with size of 408 GB with no partitions but containing lob fields. Group number 23 will have 1 table with size of 648 GB with no partitions but containing lob fields. Group number 24 will have 1 table with size of 1,441 GB with no partitions but containing lob fields. Group number 25 will have 1 table with size of 1,620 GB with no partitions but containing lob fields. Group number 30 will have 6 tables with size of 1 GB with partitions. Group number 40 will have 12 tables with size of 148 GB with partitions and containing lob fields. Group number 50 will have 2 tables with size of 37 GB with high DML change. plpgsql プロシージャが異なるステップとグループ（substep） 毎にテーブルをグループ化したので、次に各グループに含まれるテーブルのリストを生成する必要があります。これは AWS DMS タスクを作成するために使用できます。最終的なグループ番号は、 step と substep の 2 つの列を連結して生成されます。例えば、ステップ 1 とサブステップ 0 を組み合わせるとグループ番号 10 となり、52 個のテーブルと 340 GB のサイズを持ちます。 同様に、以下のグループも作成されます： Group number 00 will have 2 tables with size of 0 GB comprising of ignored objects. Group number 10 will have 52 tables with size of 333 GB with no partitions. Group number 11 will have 2 tables with size of 838 GB with no partitions. Group number 20 will have 13 tables with size of 413 GB with no partitions but containing lob fields. Group number 21 will have 2 tables with size of 468 GB with no partitions but containing lob fields. Group number 22 will have 1 table with size of 408 GB with no partitions but containing lob fields. Group number 23 will have 1 table with size of 648 GB with no partitions but containing lob fields. Group number 24 will have 1 table with size of 1,441 GB with no partitions but containing lob fields. Group number 25 will have 1 table with size of 1,620 GB with no partitions but containing lob fields. Group number 30 will have 6 tables with size of 1 GB with partitions. Group number 40 will have 12 tables with size of 148 GB with partitions and containing lob fields. 前述の出力では、テーブルは可能な限り希望のグループサイズである 600 GB に近くなるようにグループ化されています。例えば、グループ 10 には 52 個のテーブルが含まれており、合計サイズは 333 GB です。838 GB のサイズの 2 つの巨大なテーブルは、単一のテーブルを分割しないように、グループ 11 として別の AWS DMS タスクに保持されています。テーブルの数とサイズに応じて、一部のグループは希望のグループサイズである 600 GB よりも小さくなったり大きくなったりします。したがって、データベースはパーティション、非パーティション LOB、および DML ボリュームに基づいてグループ化することで 11 のタスクを持つことになります。 次に、以下のスクリプトを使用して、異なるグループの下にあるテーブルをそれぞれのファイルに抽出します： #!/bin/bash # Collect database connection details echo "Please enter database connection details:" read -p "Database name [postgres]: " DB_NAME DB_NAME=${DB_NAME:-postgres} read -p "Database user [postgres]: " DB_USER DB_USER=${DB_USER:-postgres} read -p "Database host [localhost]: " DB_HOST DB_HOST=${DB_HOST:-localhost} read -p "Database port [5432]: " DB_PORT DB_PORT=${DB_PORT:-5432} read -p "Schema name for table_mapping_groups: " usr usr=${usr:-admin} read -s -p "Database password: " password DB_PASSWORD=$password # Export variables for psql to use export PGPASSWORD="$DB_PASSWORD" # Function to execute psql query and return result execute_query() { psql -U "$DB_USER" \ -h "$DB_HOST" \ -p "$DB_PORT" \ -d "$DB_NAME" \ -t -A \ -c "$1" } # Test connection echo -e "\nTesting database connection..." if ! execute_query "SELECT 1 ;" > /dev/null 2>&1 ; then echo "Error: Could not connect to the database. Please check your credentials." exit 1 fi echo "Connection successful!" # Generate parfile equivalent echo "Generating step/group combinations..." execute_query "SELECT DISTINCT concat(step, groupnum) FROM ${usr}.table_mapping_groups WHERE owner = '${usr}' AND step IS NOT NULL" > parfile.lst # Remove any existing files rm -rf ADMIN_TAB* # Process each combination while IFS= read -r combination do echo "Generating table list for step and group ${combination}" execute_query " SELECT object_name FROM ${usr}.table_mapping_groups WHERE concat(step, groupnum) = '${combination}' " > "${usr}_TAB_${combination}.lst" done < parfile.lst # Clear password from environment unset PGPASSWORD echo -e "\nScript execution completed" スクリプトの実行後、テーブル名を含む以下のファイルが生成されます： -rw-rw-r-- 1 ec2-user ec2-user 16 Jul 22 00:04 admin_TAB_21.lst -rw-rw-r-- 1 ec2-user ec2-user 584 Jul 22 00:04 admin_TAB_10.lst -rw-rw-r-- 1 ec2-user ec2-user 43 Jul 22 00:04 admin_TAB_11.lst -rw-rw-r-- 1 ec2-user ec2-user 13 Jul 22 00:04 admin_TAB_00.lst -rw-rw-r-- 1 ec2-user ec2-user 20 Jul 22 00:04 admin_TAB_50.lst -rw-rw-r-- 1 ec2-user ec2-user 9 Jul 22 00:04 admin_TAB_24.lst -rw-rw-r-- 1 ec2-user ec2-user 115 Jul 22 00:04 admin_TAB_30.lst -rw-rw-r-- 1 ec2-user ec2-user 232 Jul 22 00:04 admin_TAB_40.lst -rw-rw-r-- 1 ec2-user ec2-user 8 Jul 22 00:04 admin_TAB_23.lst -rw-rw-r-- 1 ec2-user ec2-user 165 Jul 22 00:04 admin_TAB_20.lst -rw-rw-r-- 1 ec2-user ec2-user 9 Jul 22 00:04 admin_TAB_25.lst -rw-rw-r-- 1 ec2-user ec2-user 9 Jul 22 00:04 admin_TAB_22.lst 次のコードに示すように、同じファイルの一部であるテーブル名は、単一のタスクにグループ化する必要があります： [ec2-user@ip-10-0-0-40 ~ ]$ cat admin_TAB_00.lst canada usail [ec2-user@ip-10-0-0-40 ~ ]$ cat admin_TAB_22.lst montreal [ec2-user@ip-10-0-0-40 ~ ]$ cat admin_TAB_25.lst edmonton [ec2-user@ip-10-0-0-40 ~ ]$ cat admin_TAB_20.lst print_media_hash_cap_a d_storage t print_media_cap_dal print_media print_media_cap tbl_clob print_media_cap_a document_storage doc_storage doc_store storeage quebec クリーンアップ このデモンストレーションの一環として、ソースの PostgreSQL データベースにいくつかのテーブルと 1 つのプロシージャを作成しました。タスクのグループ化が記録された後、以下の DROP ステートメントを使用して、これらのテーブルを削除し、プロシージャをドロップすることができます： DROP TABLE TABLE_MAPPING ; DROP PROCEDURE admin.both ; DROP TABLE MST_DBA_TAB_MOD ; DROP TABLE TABLE_MAPPING_GROUPS ; まとめ この投稿では、システムカタログと統計ビューを活用して、データベースの規模、運用負荷、ハードウェア構成を調査する方法について説明しました。これらの方法は、AWS DMS を使用した効果的なデータベース転送に必要なタスク数とテーブルクラスターの理想的な数を決定するのに役立ちます。データベースオブジェクト情報とソースデータベースのハードウェア仕様を統合することで、移行設計フェーズで十分な情報に基づいた選択を行うことができます。移行タスクを最適化するために、 AWS Database Migration Service ユーザーガイドのベストプラクティス も併せて確認することをお勧めします。 著者について Manojit Saha Sardar Manojit はAWSのシニアデータベースエンジニアで、AWS DMS、Amazon RDS、および Amazon RDS for PostgreSQL 分野のエキスパートです。AWS での職務は、クライアントと協力してさまざまなデータ移行シナリオに取り組み、Amazon RDS for Oracle および Amazon RDS for PostgreSQL に関連する課題の解決をサポートしています。 Chirantan Pandya Chirantan はデータベースエンジニア（AWS カウントダウンプレミアム）であり、AWS DMS と Amazon RDS for PostgreSQL 分野のエキスパートです。AWS では、顧客と緊密に連携してデータベース移行プロジェクトや Amazon RDS for PostgreSQL、Oracle に関するガイダンスや技術支援を提供しています。

本投稿は、Vanshika Nigam による記事 「 Improve AWS DMS continuous replication performance by using column filters to parallelize high-volume tables 」を翻訳したものです。 データベースの移行は難しく、特に、数十億件のエントリーを持つ巨大なテーブルで、頻繁に更新が行われる場合は尚更です。 AWS Database Migration Service (AWS DMS) は、 並列ロード や フィルタリング機能 など、初期の一括データ転送プロセスを大幅に加速できる便利な機能を提供しています。 しかし、ソースデータベースで急速かつ継続的な変更が行われる高頻度の変更データキャプチャ (CDC) シナリオでは、特定の課題が残っています。 このようなシナリオでは、ターゲットデータベースは次のような課題に頻繁に直面します。 高レイテンシー – CDC プロセスが変更のペースに追いつけない可能性があります。大量の継続的な変更により、ソースとターゲットのデータベース間で大幅な遅延が生じ、CDC のパフォーマンスに影響を与える可能性があります。 データ損失のリスク – Oracle などのデータベースでは、AWS DMS が処理する前に、redo ログやアーカイブログが消去される可能性があり、データ損失につながる恐れがあります。 保持期間の制限 – ストレージの制約や組織のポリシーにより、保持期間を延長することが常に可能というわけではありません。 リソースの負荷 – 高頻度の CDC により、ターゲットデータベースと AWS DMS レプリケーションインスタンスの両方に負荷がかかり、レイテンシーの増加、スループットの低下、リソース消費の増加につながる可能性があります。 これらの課題に対処するには、通常、 適切なサイズのレプリケーションインスタンスを選択する 、 タスクの並列化 、 AWS DMS のバッチ適用機能を使用する 、AWS DMS タスク設定を最適化する、効率的なフィルタリング、そして時には独自のソリューションなど、多面的なアプローチが必要になります。 リレーショナルデータベースのターゲットでは、フルロード並列設定とは異なり、パフォーマンス向上のための並列 CDC スレッドを使用するオプションはありません。各タスクは単一のスレッドを使用します。AWS DMS の CDC を含むタスクが数百万の変更イベントを適用する必要がある場合は、論理的に独立したテーブルグループに対して複数の CDC タスクを使用することをお勧めします。これにより、複数の CDC スレッドを使用できます。さらに、適切なカラムフィルターを使用して、大規模なテーブルを複数の CDC タスクに分割することもできます。 この投稿では、CDC フェーズでアクティビティの多いテーブルを複数のタスクに分割するために 列フィルター を使用する方法について説明します。 この手法により、移行プロセスを加速し、ターゲットのレイテンシーを削減できます。 ソリューションの概要 AWS DMS の タスク は移行プロセスの中心となるものです。 テーブルマッピング を通じて、移行対象の特定のテーブル、ビュー、スキーマを定義します。 このマッピングには、フィルタリング機能があり、 WHERE 句を適用することで、行数を制限したり、大きなテーブルを管理可能な小さなセグメントに分割することができます。 この機能は従来、フルロード操作に適用されてきましたが、このソリューションでは、CDC タスクの最適化における可能性を探ります。 この投稿では、Oracle から PostgreSQL への移行にこのソリューションを実装します。 同じアプローチを他のリレーショナルデータベース間の移行にも適用できます。 このソリューションを実装する手順は次のとおりです。 Oracle データベースにサンプルテーブルを作成し (この投稿では、 Amazon RDS for Oracle を使用)、代表的なデータを入力します。 データベースとテーブルレベルでサプリメンタルロギングを確認して有効化します。 行をタスク間で均等に分散するのに適した不変カラムを特定します。不変カラムの詳細については、次のセクションを参照してください。そのような列が存在しない場合は、次の手順を実行します。そうでない場合は、ステップ 4 に進んでください。 一時的な不変カラムを NUMBER(1) データ型で追加します。 既存のデータについては、主キーに対する剰余演算を使用して、新しく作成した不変カラムに値を入力します。この投稿では、 3 で割った剰余を使用する例を示します。この操作により、データが 3 つの異なるグループに効果的に分割され、各グループは主キーを 3 で割った剰余で識別されます。 新しい不変カラムに対してサプリメンタルロギングを有効化します。 新規挿入時に自動的に剰余列を入力するトリガーを作成します。 剰余演算の結果に基づいて、列フィルターを使用して複数の AWS DMS タスクを作成します。これらは、要件に応じて、フルロードと CDC タスクまたは CDC のみのタスクのいずれかになります。この投稿では、3 で割った剰余に合わせて CDC のみの 3 つのタスクを作成します。 移行中にターゲットで一時的な不変カラムを除外するために、AWS DMS タスクに除外列フィルターを追加することを忘れないでください。 選択したターゲットデータベース (この投稿では、 Amazon Aurora PostgreSQL 互換エディション をデータベースとして使用) に移行したデータを検証します。 Amazon CloudWatch を使用して AWS DMS タスクのパフォーマンスを監視します。 次の図は、このソリューションのアーキテクチャを示しています。 データベースのイミュータブルカラムの特定方法 イミュータブルカラムとは、一度設定された値を変更できないカラムのことです。ミュータブルカラムとは、初期挿入後に値を変更できるカラムのことです。 主キーは不変ですが、各行に固有のものです。しかし、私たちの焦点は、複数の行で同じ値を持つ可能性のある不変のカラムを特定することです。これにより、データの分割が均等になり、AWS DMS タスク間で負荷が可能な限り均等に分散されます。例としては、作成タイムスタンプ、カテゴリコード、エリアコード、部門識別子などが挙げられます。このようなカラムを使用することで、データをより均等に分割でき、効率的なレプリケーションと、データ整合性の維持が可能になります。 重要なのは、多数のレコードに関連しながらも一定の値を保つカラムを特定し、それをパーティション分割の基準として使うことで、データの均等な分布を実現することです。 前提条件 始めるには、次の前提条件を満たす必要があります。 アクティブな AWS アカウント 。 Oracle インスタンス (この投稿では Amazon RDS for Oracle を使用) または、オンプレミスの Oracle Database。 Aurora PostgreSQL または RDS for PostgreSQL データベース (この投稿では Aurora PostgreSQL 互換を使用)。まだ Aurora PostgreSQL クラスターを持っていない場合、作成します。手順については、 Amazon Aurora DB クラスターの作成 を参照してください。 ソースとターゲットの両方のデータベースにアクセスできる レプリケーションインスタンス 。詳細については、 AWS Database Migration Service の概要 を参照してください。 ソースでサンプルテーブルの構築 この記事では、RDS for Oracle のデータベースを使用して、次の DDL で TRAVEL_INFO という名前のサンプルテーブルを作成します。 テーブル TRAVEL_INFO を作成します: CREATE TABLE travel_info ( travel_id NUMBER PRIMARY KEY, traveler_name VARCHAR2(100), destination VARCHAR2(100), travel_mode VARCHAR2(10), travel_date DATE ); TRAVEL_INFO テーブルに代表的なデータを挿入します: INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (1, 'John Doe', 'Paris', 'air', TO_DATE('2025-02-15', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (2, 'Jane Smith', 'Venice', 'water', TO_DATE('2025-03-20', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (3, 'Mike Johnson', 'Inca Trail', 'land', TO_DATE('2025-04-10', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (4, 'Emily Chen', 'Tokyo', 'land', TO_DATE('2025-05-22', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (5, 'Carlos Rodriguez', 'Amazon River', 'water', TO_DATE('2025-06-15', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (6, 'Sarah Thompson', 'Camino de Santiago', 'air', TO_DATE('2025-07-01', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (7, 'Alex Morgan', 'Great Barrier Reef', 'water', TO_DATE('2025-08-12', 'YYYY-MM-DD')); ソース Oracle データベースのセットアップ 次の手順に従って、ソースの Oracle データベースをセットアップしてください。 AWS DMS では、データベースレベルのサプリメンタルロギングを有効にする必要があります。次のクエリを実行して、データベースレベルのサプリメンタルロギングを確認してください。 SELECT supplemental_log_data_min ,supplemental_log_data_pk ,supplemental_log_data_fk ,supplemental_log_data_ui ,supplemental_log_data_all FROM v$database ; 最小限のサプリメンタルロギング (supplemental_log_data_min) が NO の場合は、次のクエリを実行して有効にしてください。 EXEC rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD'); CDC でレプリケーションされるスキーマのテーブルについて、テーブルレベルのサプリメンタルロギングが有効になっているかを確認してください。 SELECT owner ,log_group_name ,table_name ,DECODE(ALWAYS,'ALWAYS', 'Unconditional','CONDITIONAL', 'Conditional') always ,log_group_type FROM dba_log_groups WHERE owner IN UPPER(''); プライマリキーを持つテーブルについては、次のクエリを実行するか、後述の AWS DMS エンドポイント設定で追加の接続属性を追加して、サプリメンタルロギングを有効にしてください。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS ; この例で使用するテーブルには不変カラムがありません。そのため、AWS DMS タスクで WHERE 句を使用するための一時的な不変カラムを追加します。 ALTER TABLE travel_info ADD mod_3 NUMBER(1); この新しい列にプライマリキーの剰余演算の結果を設定するため、テーブルを更新します。 UPDATE travel_info SET mod_3 = MOD(travel_id, 3); 新しい列に値が正しく設定されたことを確認するため、テーブルを問い合わせます。 SELECT * from travel_info ; この新しい列にサプリメンタルロギングを追加します。サプリメンタルロギングが有効になっていない場合、AWS DMS タスクは失敗します。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" add SUPPLEMENTAL LOG GROUP LogGroupTest (MOD_3) ALWAYS ; 新しい行が挿入されるたびに剰余演算の列を設定するトリガーを作成します。 CREATE OR REPLACE TRIGGER trg_travel_info_mod3 BEFORE INSERT OR UPDATE OF travel_id ON travel_info FOR EACH ROW BEGIN :NEW.mod_3 := MOD(:NEW.travel_id, 3); END ; / サンプルテーブルのターゲットへの構築 この投稿では、 travel_id カラムの Oracle データ型 NUMBER を PostgreSQL のデータ型 INTEGER にマッピングしました。これは、ターゲットで正しい精度を維持するためです。Oracle の NUMBER カラムから PostgreSQL の理想的なデータ型カラムへの正確なデータ型マッピングを行うには、 Oracle の NUMBER データ型を PostgreSQL に変換する を参照してください。 ターゲットでテーブル構造を作成するには、次のクエリを実行します。ソースで作成した mod_3 カラムは含まれていないことに注意してください。 create table if not exists vanshika.travel_info ( travel_id integer not null, traveler_name character varying(100), destination character varying(100), travel_mode character varying(10), travel_date timestamp without time zone, constraint travel_info_pkey primary key (travel_id) ); ターゲットにテーブルが存在しない場合、AWS DMS は AWS DMS タスクで選択されたテーブル準備モード に関係なく、ターゲットにテーブルを作成します。この場合、DMS が余分な不要カラム ( mod_3 カラムなど) を含むテーブルを作成してしまうことに注意が必要です。 AWS DMS を使用したデータ移行 このセクションでは、データを移行する手順を説明します。 AWS DMS エンドポイントの作成 ソースとターゲットのデータベースに対して AWS DMS エンドポイントを作成 します。AWS DMS エンドポイントは、データストアへの接続情報、データストアの種類、場所を提供します。 Oracle ソースエンドポイントを作成する手順については、 AWS DMS での Oracle データベースのソース利用 を参照してください。 デフォルトの接続設定に加えて、オプションで AddSupplementalLogging=true エンドポイント設定を追加すると、この投稿の前半で説明したクエリを実行してサプリメンタルロギングを明示的に追加していない場合に、AWS DMS が Oracle データベースにテーブルレベルの サプリメンタルロギング を設定します。 PostgreSQL ターゲットエンドポイントを作成する手順については、 AWS Database Migration Service のターゲットとして PostgreSQL データベースを使用する を参照してください。 AWS DMS タスクの作成 最初に RDS for Oracle から Aurora PostgreSQL 互換データベースへの別個のフルロードタスクを使用して、初期データ移行を実行したことに注意してください。フルロードが完了した後、このブログの ソース Oracle データベースのセットアップ セクションで説明されているように、フィルタリングに使用する新しい列をソースに追加しました。 次のステップとして、フィルターとして mod_3 を使用してテーブルを 3 つのタスクに分割します。以下の JSON は、AWS DMS タスクのマッピングルールの例を示しています。剰余列をターゲットから除外するために、 remove-column フィルターを追加することを忘れずに、3 つの別々の CDC タスクを作成してください。 レプリケーションタスクには、次の設定を使用してください: タスク識別子 には、識別可能な名前を入力してください。 ソースデータベースエンドポイント では、作成した Oracle エンドポイントを選択してください。 ターゲットデータベースエンドポイント では、作成した Aurora PostgreSQL エンドポイントを選択してください。 タスクモード では、[プロビジョンド] を選択してください。 レプリケーションインスタンス では、作成したプロビジョンドインスタンスを選択してください。 レプリケーションタイプを [ 複製のみ ] に設定してください。 ターゲットテーブル準備モードを [ 何もしない ] に設定してください。 タスク設定の下で[ CloudWatch ログ をオンにする] を有効にすると、問題をデバッグすることができます。 テーブルマッピング では、 編集モード で  JSON エディタ を選択してください。 DMS タスクのマッピングルールには、次の JSON を使用してください。スキーマ名は、テーブルが作成されたスキーマ名に置き換えてください。 { "rules": [ { "rule-type": "transformation", "rule-id": "259824354", "rule-name": "259824354", "rule-target": "column", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO", "column-name": "MOD_3" }, "rule-action": "remove-column", "value": null, "old-value": null }, { "rule-type": "transformation", "rule-id": "259793105", "rule-name": "259793105", "rule-target": "table", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO" }, "rule-action": "convert-lowercase", "value": null, "old-value": null }, { "rule-type": "transformation", "rule-id": "259761426", "rule-name": "259761426", "rule-target": "schema", "object-locator": { "schema-name": "VANSHIKA" }, "rule-action": "convert-lowercase", "value": null, "old-value": null }, { "rule-type": "selection", "rule-id": "259627857", "rule-name": "259627857", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO" }, "rule-action": "include", "filters": [ { "filter-type": "source", "column-name": "MOD_3", "filter-conditions": [ { "filter-operator": "eq", "value": "0" } ] } ] } ] 移行前評価チェックボックスをオフにしてください。 移行タスクのスタートアップ設定 では、[後で手動で行う] を選択してください。 他の設定はデフォルトのままにして、[ タスクを作成 ] を選択してください。 同じ設定で他の 2 つのタスク を作成してください。各タスクで、 mod_3 カラムの filter-conditions 値を 0、1、2 に置き換えることを忘れずに行ってください。 3 つのタスクを同時に実行してください。 Aurora PostgreSQL に移行されたデータを select クエリを実行して確認してください。 ソースデータベースで DML 操作を実行し、これらの変更がターゲットテーブルにどのように反映されるか、そして DMS タスクが剰余フィルターに対応する行をどのようにピックアップするかを監視してください。 個々のタスクは自身のトランザクションの順序性を維持していますが、3 つのタスク全体でのトランザクションの順序が必ずしも保たれるわけではないことに注意が必要です。この順序の不整合は、タスクの開始と実行が独立していることに起因します。したがって、ターゲットテーブルに現れるトランザクションの最終的な順序は、同じソーステーブルに関係するものであっても、各 CDC のみタスクの開始タイミングの影響を受ける可能性があります。 Oracle から移行する際は、 Oracle マテリアライズドビュー を活用して、選択したカラムに基づいてフィルタリングされたマテリアライズドビューを作成し、必要なデータサブセットのみを PostgreSQL に移行することができます。データ変換には便利ですが、マテリアライズドビューではソース側で更新のオーバーヘッドが発生し、移行のパフォーマンスに影響を与える可能性があります。 可変カラムを使用してテーブルを分割した場合の観察 既存の travel_mode カラムを AWS DMS タスクのフィルターとして使用する代わりに、テーブルに不変カラムを導入するとします。この場合でも、陸路、空路、水路の移動手段に対応する 3 つの CDC タスクを作成することになります。 このシナリオをテストするには、 travel_mode 列のサプリメンタルロギングを有効にする必要があります。これは、次の SQL コマンドを使用して行えます。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" add SUPPLEMENTAL LOG GROUP LogGroupTest (TRAVEL_MODE) ALWAYS ; タスクをセットアップした後、タスクを開始し、ソースでフィルターに使用されているカラムを更新してみてください。 UPDATE travel_info SET travel_mode = 'land' WHERE travel_id = 1 ; AWS DMS がこの変更を検出できないことがわかります。その結果、更新がターゲットデータベース (この場合は Aurora PostgreSQL 互換) に伝播されません。このカラムの更新は頻繁ではないかもしれませんが、発生した更新はすべて見落とされます。この動作は予期されたものですが、データの不整合につながる可能性があります。 したがって、効果的なデータレプリケーションを行うには、作成後に変更されない不変な列にフィルターを適用することが重要です。 パフォーマンス比較 この投稿では、ビジーなテーブルに対する大量の CDC シナリオにおける AWS DMS のパフォーマンスを評価します。AWS DMS は、Oracle をソースとする CDC 操作中のRedo ログの読み取りに、Oracle LogMiner と AWS DMS Binary Reader の 2 つのアプローチを提供しています。この実験では、LogMiner (オンラインおよびアーカイブされた Redo ログファイルを読み取るために設計された Oracle API) を使用することにしました。このソリューションは Binary Reader とも互換性があります。テストプロセスは 2 つの異なるフェーズに分かれていました。最初に単一の CDC タスクを評価し、次にカラムフィルターを使用して複数の CDC タスクに分割しました。 次のインフラストラクチャを使用しました。 ソース: RDS for Oracle インスタンス インスタンスクラス: db.r6i.xlarge ストレージ: 50 GB (3000 IOPS の gp3) Oracle バージョン: 19 (19.0.0.0.ru-2024-10.rur-2024-10.r1) ターゲット: Aurora PostgreSQL 互換エディション インスタンスクラス: db.r6i.xlarge Aurora PostgreSQL 互換エディションのバージョン: 16.1 AWS DMS レプリケーションインスタンス インスタンスクラス: dms.c5.xlarge 割り当てられたストレージ: 50 GB エンジンバージョン: 3.5.4 50 カラムと 20 インデックスを持つサンプルテーブルを作成しました。このテーブルには、ソースとターゲットの両側で最初に 50,000 行のデータが格納されました。次に、進行中の変更を複製するための単一の CDC のみのタスクを設定しました。負荷の高い本番環境をシミュレートするために、一連の DML 操作を実行しました。100 万件の新規レコードを挿入し、同時に 10 万件の既存レコードを更新し、その後 10 万件の更新スクリプトを 2 回実行し、最後にランダムに選択された 10,000 件のレコードに対して CDC トラフィックを生成しました。このテストにより、テーブルに急激で大規模な変更が加えられるシナリオを模倣することができました。この一連のプロセスにより、1 時間の期間で約 5GB のアーカイブログが生成されました。ソースデータベースでの変更率が高いため、このプロセスには時間がかかる可能性があります。AWS DMS がソースデータベースから大量のワークロードを受信すると、CDC ターゲットレイテンシーメトリクスが急上昇することがあります。私たちのテストシナリオでは、激しい活動期間中に CDC の待ち時間がピーク時で約 600 秒に達していることが、次のスクリーンショットに示されています。 この最初のテストでは、単一の CDC タスクを使用する場合の、高ボリューム、高頻度変更シナリオにおけるパフォーマンスへの影響の可能性が浮き彫りになりました。これにより、カラムフィルターを使ってタスクを分割し、ワークロードを分散してレイテンシーを低減することを目的とした後続の実験の舞台が整いました。次のグラフは、単一の CDC タスクと同じワークロードを 3 つの CDC のみタスクに分割した場合のターゲットレイテンシーを示しています。 結果は、ターゲットでのレイテンシが低減されたことを示しています。この改善は、移行プロセスが高速化したことを示しています。従来の CDC は単一スレッド操作でしたが、今回は CDC フェーズで複数のスレッドを作成し、ソースからターゲットへのデータ移行を行えるようになったためです。 実験で使用したデータ量は実際のシナリオを代表するものではないかもしれませんが、CDC 操作でカラムフィルターを使用することのメリットを効果的に示しています。 具体的には、移行プロセスを加速できることを示しており、これは大量のデータ移行には不可欠です。 考慮事項 このアプローチを実装する際には、次の重要な点に留意する必要があります。 新しいカラムを追加するオーバーヘッド – 既存のテーブル構造に適切な不変カラムが見つからない場合、この目的のために新しいカラムを追加すると、いくらかのオーバーヘッドが発生する可能性があります。この変更はデータベーススキーマに影響を与え、特にコードが全テーブルをフェッチする場合は、アプリケーションロジックの変更が必要になる可能性があります。クエリでこの新しいカラムのフィルタリングを実装する必要があり、クライアントアプリケーションに影響を与える可能性があります。進める場合は、運用への影響を最小限に抑えるため、指定のメンテナンスウィンドウ中にこれらの変更をスケジュールしてください。 ソースレイテンシーの潜在的な増加 – 同時スレッド数が増えると、ソースレイテンシーの増加が観測される可能性があります。これは、複数の並列読み取り操作によってソースシステムに追加の負荷がかかるためです。 レプリケーションインスタンスの適切なサイジング – AWS DMS レプリケーションインスタンスが、インスタンスクラスとストレージ容量の点で適切にサイズ設定されていることを確認してください。各タスクは、ソースデータベースからすべての REDO ログを読み取り、適用できるまでそれらを格納する必要があるため、十分なリソースが不可欠です。 バランスの取れた負荷分散 – タスク分割のためのカラムを選択する際は、作成するタスク間で作業負荷をできるだけ均等に分散するものを選んでください。この均等な分散は、CDC フェーズ中の並列処理による効率化の利点を最大限に活かすための鍵となります。 これらの点を慎重に検討することで、大規模な移行シナリオに対しても、潜在的な問題や予期しない副作用を最小限に抑えるような最適な AWS DMS を構築することができます。 クリーンアップ この設計で作成したリソースで不要になったものは、料金が発生しないように削除してください: Aurora PostgreSQL クラスターを削除します 。 RDS for Oracle データベースを削除します 。 AWS DMS レプリケーションインスタンス、ソースとターゲットのエンドポイント、タスクを削除します 。 この実験を既存のデータベースで実施し、運用を続ける予定の場合は、実験が完了したら、ソースとターゲットの両方のデータベースからテストテーブルを明示的に削除してください。 結論 この投稿では、不変のカラムに基づいて複数の CDC タスクにワークロードを分散し、DMS カラムフィルターを使用して大規模で頻繁に使用されるアクティブテーブルを移行する方法を示しました。 この手法を活用することで、データの整合性を維持しながら移行時間を短縮できることを示しました。 この戦略は、フルロードと CDC プロセスの両方を最適化するため、同様の制約に直面する様々な大規模移行に適用できます。 AWS DMS とその機能の詳細については、 AWS DMS ドキュメント を参照してください。AWS DMS フルロード移行のパフォーマンスを改善するためのベストプラクティスについては、 並列読み込みとフィルターオプションを使用して AWS DMS によるデータベース移行を高速化する を参照してください。 著者について Vanshika Nigam Vanshika は、AWS Database Migration Accelerator （DMA）チームのソリューションアーキテクトです。Amazon DMA Advisor として、お客様がオンプレミスデータベースや商用データベースからAWSクラウドデータベースソリューションへの移行を加速できるよう支援しています。Amazon RDS と AWS DMS で 7 年以上の経験を持つ彼女は、効率的なデータベース移行戦略の設計と実装を専門としています。

本記事は 2025 年 11 月 26 日に公開された AWS Blog “ Apply fine-grained access control with Bedrock AgentCore Gateway interceptors ” を翻訳したものです。 企業は AI エージェントを急速に採用してワークフローを自動化し生産性を向上させる中で、重大な課題に直面しています。それは、組織全体で数千のツールへの安全なアクセスを管理することです。現代の AI アプリケーションは、もはや少数のエージェントが数個の API を呼び出すだけのものではありません。企業は統合 AI プラットフォームを構築しており、そこでは数百のエージェント、コンシューマー AI アプリケーション、自動化されたワークフローが、異なるチーム、組織、事業部門にまたがる数千の Model Context Protocol (MCP) ツールにアクセスする必要があります。 この規模の拡大により、セキュリティとガバナンスに関する根本的な問題が発生します。AI エージェント、ユーザー、アプリケーションなど、各呼び出し元が許可されたツールのみにアクセスできるようにするにはどうすればよいでしょうか？ユーザー ID、エージェントのコンテキスト、アクセスされたチャネル、常に変化しうる権限に基づいて、ツールへのアクセスを動的にフィルタリングするにはどうすればよいでしょうか？エージェントからツール、下流の API へと続くマルチホップのワークフローを通じて、機密データを保護するにはどうすればよいでしょうか？そして、パフォーマンスを犠牲にしたり、運用上のボトルネックを作ったり、テナントやユースケースごとに個別の MCP サーバーインスタンスを強制したりすることなく、これらすべてを実現するにはどうすればよいでしょうか？ これらの課題に対応するため、 Amazon Bedrock AgentCore Gateway  はゲートウェイインターセプターという新機能の提供を開始しました。この強力な新機能により、きめ細かなセキュリティ、動的なアクセス制御、柔軟なスキーマ管理が可能になります。 きめ細かなツールアクセス制御 エンタープライズのお客様は、統一された AgentCore Gateway を通じて数千もの MCP ツールをデプロイしています。この単一のゲートウェイを使い、異なるチーム、組織、コンシューマー AI アプリケーション、AI エージェントがツールにアクセスします。各ツールには、呼び出し元のプリンシパルに応じたアクセス権限が割り当てられています。ここでの課題は、プリンシパルの権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への ListTools、InvokeTool、Search API の呼び出しに対して、コンテキストに応じたレスポンスを返すことです。 ツールのフィルタリングは、エージェント ID、ユーザー ID、実行コンテキストなど、複数の動的な要因に基づいて行う必要があります。権限は、ユーザーコンテキスト、ユーザーがエージェントにアクセスするチャネル、ワークスペースのアクセスレベル、その他のコンテキスト属性に基づいて動的に変化する可能性があります。そのため、古い権限状態をキャッシュすることなく、権限の変更が即座にツールの利用可否に反映されるセキュリティを考慮したフィルタリングが求められます。 以下の図は、ユーザーに基づくツールフィルタリングの例です。ゲートウェイがユーザー情報とコンテキストを評価し、許可されたツールを返すまでの流れを示しています。 MCP と下流の API 間でのデータ保護とスキーマ変換 AI エージェントと下流の API 間の連携を管理しながら、セキュリティと柔軟性を維持することは複雑な課題です。組織は、MCP リクエストスキーマを下流の API スキーマに動的にマッピングする必要があります。この動的マッピングにより、ユーザーがプロンプトで送信する可能性のある個人識別情報 (PII) や機密個人情報 (SPI) を削除・除外するなど、重要なデータ保護機能を実現できます。これにより、API 呼び出しで不要な機密情報が下流の API に漏洩するのを防げます。 さらに、お客様はスキーマ変換機能を必要としています。これにより、API の仕様変更に対応しながら MCP スキーマを維持し、下流の実装から独立させることが可能になります。このような疎結合の構成であれば、AI エージェントとツール間の連携を壊すことなく、API の改良とバージョン管理を円滑に進めることができます。そのため、バックエンドチームは、エージェント層への変更を強制したり、特定のツールスキーマを学習した AI モデルの再学習を依頼したりする必要はありません。API 実装の修正、フィールド名の変更、ペイロード構造の再構成、認証要件の更新といった変更を自由に実施できます。 マルチテナント SaaS におけるテナント分離 エージェントやツールをサービスとして提供する組織には、複雑なマルチテナンシー要件があります。お客様は、適切なテナント分離を維持しながら、すべてのユーザーに対して MCP サーバーを提供する必要があります。これには、テナント ID とユーザー ID の両方の検証が必要です。マルチテナント MCP サーバーアーキテクチャでは、異なるユーザーとワークスペースが完全に隔離された状態を保つ必要があり、ツールアクセスはテナント境界に基づいて厳密に制御する必要があります。この課題には、テナントごとに個別のゲートウェイが必要なのか、適切な分離保証があれば単一のゲートウェイでマルチテナントシナリオを安全に処理できるのかを判断することも含まれます。 ツールの動的なフィルタリング お客様は、権限やユーザーコンテキストの変更に応じた、リアルタイムのツールのフィルタリングも必要としています。組織には、ツールを 2 段階でフィルタリングできる統合 MCP サーバーが必要です。まずエージェントの権限とワークスペースのコンテキストでフィルタリングし、次にセマンティック検索でフィルタリングします。権限はいつでも変更される可能性があるため、フィルタリング結果をキャッシュせず、都度動的に判定することが重要です。 カスタムヘッダーの伝播とアイデンティティコンテキストの管理 AI エージェントは、自律的で非決定論的である点において、従来のマイクロサービスとは根本的に異なります。サービス間の信頼と認可技術に依存する従来のマイクロサービス間認可アプローチとは異なり、AI エージェントはエンドユーザーに代わってワークフローを実行し、ユーザーのコンテキストに基づいて、下流のツール、API、リソースにアクセスする必要があります。しかし、認可トークンをそのまま下流のサービスに送信すると、認証情報の盗難、権限昇格、より権限の高いサービスが権限の低い攻撃者に代わって操作を実行するよう騙される「混乱した代理問題」(Confused deputy problem) など、重大なセキュリティ脆弱性が生じます。 権限伝播方式の比較: なりすまし / 代理実行 マルチホップのワークフロー (エージェントからエージェント、ツール、API へと続く流れ）を通じて、アイデンティティのコンテキスト (権限) をどのように伝播させるかは、重要なセキュリティ上の決定事項です。伝播方法には、なりすまし (Impersonation) 方式と、代理実行 (Act-on-Behalf) 方式があります。 なりすまし方式では、元のユーザーの JWT トークンが多段実行の各ホップを通じて変更されずに渡されます。実装は簡単ですが、以下のような重大なセキュリティリスクが伴うため、推奨されません。 下流のサービスが必要以上の権限を持つトークンを受け取る コンポーネントが侵害された場合、権限昇格のリスクが高まる トークンのスコープを特定の下流のターゲットに制限できない なりすまし攻撃 (侵害されたサービスが過剰な権限を持つトークンを悪用) に対して脆弱 代理実行方式では、ワークフローの各ホップが、下流のターゲット専用に発行された個別のスコープ付きトークンを受け取ります。実行コンテキストの伝播には JWT が使用されます。この方式は、以下のメリットがあるため推奨されます。 最小権限の原則 – 各サービスは、特定の下流の API にアクセスするために必要な権限のみを受け取る 影響範囲の制限 – 漏洩したトークンのスコープは制限され、他の場所で再利用することはできない 監査性の向上 – AgentCore Observability を使用して、どのサービスがユーザーに代わって行動したかを示す明確な責任の追跡が表示される トークンスコープの制限 – 各下流のターゲットは、その API に特化したスコープのトークンまたは認証情報を受け取る セキュリティ境界 – コールチェーン内の異なるサービス間で適切な分離が強制される 混乱した代理 (Confused Deputy) の防止 – スコープが制限されたトークンと認証情報により、サービスが不正な操作を実行するよう騙されることを防げる 代理実行方式では、ゲートウェイは受信リクエストから実行コンテキストを抽出し、各下流のターゲットに対して新しいスコープ付き認可トークンを生成します。モニタリングと認可の判断のために、ユーザーの ID コンテキストを維持しながら適切なヘッダーを挿入します。これは、必要以上の権限を持つ認証情報を下流のサービスに公開せずに実現されます。このセキュアなアプローチにより、AI エージェントはユーザーに代わってワークフローを実行でき、多段実行の各ホップで厳格なセキュリティ境界を維持できます。 次の図は、なりすまし方式と代理実行方式のワークフローを比較しています。 なりすまし方式 (図上部) では、エージェントがユーザー A の完全な ID トークン ( "order: read, promotions:write"  スコープすべて) を変更せずに両方のツールに渡します。このため、各ツールは必要以上の権限を受け取ります。一方、代理実行方式 (図下部) では、エージェントが各ツール用に個別のスコープ付きトークンを作成します。Order ツールは "order: read" スコープのみを受け取り、Promotions ツールは "promotions:write" スコープのみを受け取ります。各トークンには "Act: Agent" フィールドが含間れており、エージェントがユーザー A の代理として行動していることを明示し、責任の追跡を明確にします。このように、最小権限の原則に基づいて各下流のサービスに必要な権限のみを付与することで、セキュリティリスクを軽減し、トークンの誤用を防止できます。 AgentCore Gateway: AI エージェントのための MCP のセキュアな統合 AgentCore Gateway は、既存の API や  AWS Lambda 関数をエージェント互換の MCP ツールに変換します。また、ゲートウェイを既存の MCP サーバーに接続することも、サードパーティのビジネスツールやサービス (Jira、Asana、Zendesk など) とシームレスに統合することもできます。この統一されたアクセスポイントにより、エンタープライズシステム全体で安全に MCP を統合できます。さらに、AgentCore Identity を使用することで、エージェントは OAuth 標準を使用した適切な認証と認可により、これらのツールに安全にアクセスできます。 AgentCore Gateway のゲートウェイインターセプターの導入により、2 つのカスタム Lambda 関数を通じて、きめ細かなアクセス制御と認証情報管理を実装できるようになりました。 ゲートウェイリクエストインターセプター – ターゲットツールに到達する前に受信リクエストを処理します。 ユーザー認証情報、セッションコンテキスト、組織のポリシーに基づくアクセス制御、監査証跡の作成、スキーマ変換などが可能です。 ゲートウェイレスポンスインターセプター – 呼び出し元のエージェントに返される前に送信レスポンスを処理します。 監査証跡の作成、ツールのフィルタリング、スキーマ変換、検索およびリストツールのアクセス制御が可能です。 次の図は、ゲートウェイインターセプターを介したリクエスト・レスポンスのフローを示しています。 リクエスト・レスポンスサイクルの各段階でカスタムインターセプターが受信・送信するペイロードの構造を詳しく見ていきましょう。ゲートウェイリクエストインターセプターは、以下の構造のイベントを受け取ります。 {   "interceptorInputVersion": "1.0",   "mcp": {     "gatewayRequest": {         "headers": { "Authorization": "Bearer eyJhbG...", ... },         "body": { "jsonrpc": "2.0", "method": "tools/list", ... }     },     "requestContext": { ... }   } } ゲートウェイリクエストインターセプター Lambda 関数は、 transformedGatewayRequest フィールドを含むレスポンスを返す必要があります。 {   "interceptorOutputVersion": "1.0",   "mcp": {     "transformedGatewayRequest": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります         "headers": { ... },         "body": { ... }     }   } } ターゲットサービスが応答すると、ゲートウェイレスポンスインターセプターが呼び出されます。 入力には、元のリクエストとターゲットからのレスポンスを含むイベントが渡されます。 {   "interceptorInputVersion": "1.0",   "mcp": {     "gatewayRequest": { ... },     "requestContext": { ... },     "gatewayResponse": {  // <-- このフィールドに、ターゲットのレスポンスが含まれます         "statusCode": 200,         "headers": { ... },         "body": {             "jsonrpc": "2.0",             "result": { "tools": [ ... ] }         }     }   } } ゲートウェイレスポンスインターセプター Lambda 関数は、 transformedGatewayResponse フィールドを含むレスポンスを返す必要があります。 {   "interceptorOutputVersion": "1.0",   "mcp": {     "transformedGatewayResponse": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります         "statusCode": 200,         "headers": { ... },         "body": { ... }     }   } } このリクエスト・レスポンス構造の理解は、後半で説明するカスタムインターセプターのロジック実装に不可欠です。ゲートウェイインターセプターは、エージェント型 AI ワークフローのセキュリティと管理に重要な機能を提供します。 ヘッダー管理 – カスタムヘッダーを通じて認証トークン、相関 ID、メタデータを渡す リクエスト変換 – ターゲットサービスに到達する前にリクエストペイロードの変更、コンテキストの追加、データの強化を行う セキュリティ強化 – カスタム認証、認可、データのサニタイズロジック (機密データ編集など) を実装 きめ細かなアクセス制御 – 呼び出し元のアクセス権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への ListTools、InvokeTool、Search 呼び出しに対してコンテキストに応じて応答 マルチテナント MCP ツールのテナント分離 – マルチテナント環境において、呼び出しユーザー、エージェント、テナント ID に基づいてテナント分離とアクセス制御を実装 オブザーバビリティ – エージェントワークフローを監視するためのロギング、メトリクス、トレース情報を追加 ゲートウェイインターセプターは、Lambda 関数、OpenAPI エンドポイント、MCP サーバーなどの AgentCore Gateway ターゲットタイプと連携します。 ゲートウェイインターセプターのユースケース ゲートウェイインターセプターを使用することで、エージェント型 AI システムに柔軟なセキュリティとアクセス制御パターンを実装できます。本記事では、3 つのアプローチを紹介します。ツール呼び出しのきめ細かなアクセス制御、ユーザー権限に基づく動的なツールフィルタリング、分散システム間でのアイデンティティ伝播です。 ツール呼び出しのきめ細かなアクセス制御 AgentCore Gateway は、統一された MCP エンドポイントを通じて複数のバックエンドツールを公開します。異なるロールを持つユーザーには、異なるツールのアクセス許可が必要です。JWT スコープとゲートウェイインターセプターを組み合わせることで、ユーザーが認可されたツールのみを呼び出し、ロールやワークスペースに属するツールを検出できるようにします。きめ細かなアクセス制御では、 Amazon Cognito または他の OAuth 2 プロバイダーが発行する JWT スコープ値を使用します。YAML ファイルや権限マッピングテーブルを持つデータベースでの実装も可能です。今回はシンプルな命名規則に従い、ユーザーは MCP ターゲットへのフルアクセス (例: mcp-target-123 ) またはツールレベルのアクセス (例: mcp-target-123:getOrder ) を受け取ります。これらのスコープは OAuth トークン内のスコープクレームとして表現され、ツール権限に直接対応するため、認可モデルが予測可能で監査も容易です。 次の図は、このワークフローを示しています。 リクエストインターセプターは、以下のステップを通じて実行時にアクセス許可を適用します。 JWT を抽出してデコードし、スコープクレームを取得します。 tools/call を使用して、呼び出されているツールを特定します。 設定ファイルまたはアクセスポリシーデータストアを参照し、ユーザーにフルターゲットアクセスまたはツール固有の権限がない場合はリクエストをブロックします。 認可されていない呼び出しに対しては、構造化された MCP エラーを返し、バックエンドツールハンドラーの実行を防ぎます。 今回のサンプルでは、例えば以下の通り、認可機能の中核部分は意図的に最小限にしています。 def check_tool_authorization(scopes, tool, target):     if target in scopes:        return True return f"{target}:{tool}" in scopes このパターンにより、呼び出しと検出パスの両方で予測可能な認可の適用が可能になります (詳細は次のセクションで説明します)。マルチテナントアーキテクチャでは、追加のクレーム (例: tenantId 、 workspaceId ) でモデルを拡張できます。 運用セキュリティのため、インターセプターは決定論的な動作を保ち、複雑な分岐ロジックを避け、LLM の指示ではなくトークンクレームのみに依存するようにしてください。インターセプターを用いて、LLM がツールを参照または実行する前にゲートウェイ境界で認可を実施することで、ツール実装や MCP ターゲットを変更することなく、ロール、テナント、ドメイン間の強力な分離を実現できます。 ツール検出の動的なフィルタリング エージェントは、2 つの主要な方法で利用可能なツールを検出します。1 つは自然言語クエリ (「注文管理に関連するツールを探す」など) を可能にするセマンティック検索機能、もう 1 つは利用可能なツールの完全なインベントリを提供する標準的な ( tools/list ) 操作です。この検出メカニズムはエージェントの機能の基本ですが、重要なセキュリティ上の考慮が必要です。適切なフィルタリング制御がない場合、MCP サーバーはリクエストしているエージェントやユーザーの認可レベルに関係なく、利用可能なすべてのツールリストを返してしまいます。この制限のないツール検出により、未認可のユーザーやエージェントに機密性の高い機能を公開し、潜在的なセキュリティ脆弱性を生み出します。 ターゲットがセマンティック検索や MCP tools/list リクエストに応答してツールの一覧を返す際、ゲートウェイレスポンスインターセプターを使用してきめ細かなアクセス制御を実施できます。インターセプターはリクエストしているエージェントにレスポンスが到達する前に処理するため、ユーザーは許可されたツールのみを検出できます。このワークフローは以下のステップで構成されています。 ターゲットは、受信した JWT トークンを検証し、きめ細かなアクセス制御とは無関係に、全ツール一覧またはセマンティック検索でフィルタリングされたサブセットを返します。 設定されたレスポンスインターセプターが AgentCore Gateway によって呼び出されます。レスポンスインターセプターはペイロードから JWT を抽出デコードし、ユーザーの権限を定義するスコープクレームを取得します。 インターセプターは、リスト内の各ツールについて、JWT スコープに基づいてユーザーの認可を評価します。 ユーザーがアクセスを許可されていないツールはリストから削除されます。 レスポンスインターセプターは、認可されたツールのみを含む変換されたレスポンスを返します。 以下の図は、MCP tools/list と AgentCore Gateway tools/call (セマンティック検索) の両方についてこのワークフローを示しています。 以下は、レスポンスインターセプター Lambda ハンドラーのコードスニペットです。このハンドラーは、JWT トークンの抽出、ツール一覧の取得、権限に基づくフィルタリングを実行し、認可されたツールのみを含む変換されたレスポンスを返します。 def lambda_handler(event, context):     # ゲートウェイのレスポンスと認証ヘッダーを抽出     gateway_response = event['mcp']['gatewayResponse']     auth_header = gateway_response['headers'].get('Authorization', '')     token = auth_header.replace('Bearer ', '')     # JWT からスコープを抽出     claims = decode_jwt_payload(token)     scopes = claims.get('scope', '').split()          # ゲートウェイのレスポンスからツール一覧を取得 (MCP tools/list リクエストの場合)     tools = gateway_response['body']['result'].get('tools', [])     # structuredContent フィールドから取得 (AgentCore Gateway のセマンティック検索を利用する場合)     if not tools:         tools = gateway_response['body']['result'].get('structuredContent', {}).get('tools', [])          # スコープに基づきツールをフィルタリング     filtered_tools = filter_tools_by_scope(tools, scopes)          # 認可されたツールのみを含む変換されたレスポンスを返す     return {         "interceptorOutputVersion": "1.0",         "mcp": {             "transformedGatewayResponse": {                 "statusCode": 200,                 "headers": {"Authorization": auth_header},                 "body": {                     "result": {"tools": filtered_tools}                 }             }         }     } filter_tools_by_scope 関数は、ユーザーに許可されたスコープに対して各ツールの認可チェックを実装します。 def filter_tools_by_scope(tools, allowed_scopes):     """ユーザーが許可されたスコープに基づいてツールをフィルタリング"""     filtered_tools = []     for tool in tools:         target, action = tool['name'].split('___')         # ユーザーがターゲットへのフルアクセス、あるいは当該ツールへのアクセスを持つか確認         if target in allowed_scopes or f"{target}:{action}" in allowed_scopes:             filtered_tools.append(tool)                   return filtered_tools 完全な実装は  GitHub リポジトリ でご確認ください。 カスタムヘッダーの伝播 AI エージェントが複数の下流のサービスと連携する際、サービス境界を越えてユーザー ID (ユーザー識別子やユーザー情報) を維持することがセキュリティ、コンプライアンス、監査証跡にとって重要です。エージェントが AgentCore Gateway を通じてツールを呼び出す場合、元のユーザーの ID はエージェントからゲートウェイへ、そしてゲートウェイからターゲットサービスへと伝播する必要があります。適切な ID 伝播がなければ、下流のサービスはユーザー固有の認可ポリシーを適用したり、正確な監査ログを維持したり、テナント分離を実装したりすることができません。この課題は、異なるユーザーが同じエージェントインフラストラクチャを共有しながらも、厳格なデータ分離を必要とするマルチテナント環境でより深刻です。 ゲートウェイリクエストインターセプターは、以下のステップに従って、受信リクエストヘッダーとコンテキストから ID 情報を抽出し、下流のサービスが期待する形式に変換し、ターゲットサービスに到達する前にリクエストを拡張します。 ゲートウェイリクエストインターセプターは、受信リクエストから認証ヘッダーを抽出し、下流のサービス向けに変換します。 AgentCore Gateway はリクエストフローを調整し、インターセプターの実行を管理します。 ターゲット呼び出しは、適切にフォーマットされた ID 情報を含む拡張されたリクエストを受け取ります。 ゲートウェイリクエストインターセプターは、ユーザーのアクションをエンドツーエンドで可視化し、サービス境界を越えて一貫した認可ポリシーを適用し、データ主権要件へのコンプライアンスを維持するのに役立ちます。 カスタムヘッダー伝播のワークフロー全体は以下のステップで構成されています。 MCP クライアントが AgentCore Gateway を呼び出します。 AgentCore Gateway がインバウンドリクエストを認証します。 AgentCore Gateway がカスタムインターセプターを呼び出します。 ゲートウェイリクエストインターセプターは、受信リクエストのペイロードを変換します。具体的には、下流の Lambda ターゲットに送信するパラメータとして認証トークンを追加します。受信した JWT をそのまま下流の API に送信すると、特権昇格や認証情報の盗難のリスクがあるため推奨されません (エージェントが下流の API のアクセストークンを使用して MCP サーバーを呼び出す必要がある例外的なケースを除く) 。リクエストからインバウンド JWT を削除し、下流の API を呼び出すための最小権限のスコープダウントークンを持つ新しい JWT を追加することもできます。 AgentCore Gateway は変換されたリクエストでターゲットを呼び出します。ターゲットにはインターセプター Lambda 関数によって渡された認証トークンが含まれています。 AgentCore Gateway がターゲットからのレスポンスを返します。 次の図は、このワークフローを示しています。 以下は、カスタムヘッダーの伝播を実行するインターセプター Lambda ハンドラーのコードスニペットです。 import json import uuid def lambda_handler(event, context):     # ゲートウェイへのリクエストを抽出    mcp_data = event.get('mcp', {})     gateway_request = mcp_data.get('gatewayRequest', {})     headers = gateway_request.get('headers', {})     body = gateway_request.get('body', {})     extended_body = body          # 認証ヘッダーをパススルー     auth_header = headers.get('authorization', '') or headers.get('Authorization', '')    if "arguments" in extended_body["params"]:        extended_body["params"]["arguments"]["authorization"] = auth_header     # 認証ヘッダーが保持された状態の、変換されたリクエストを返す     response = {        "interceptorOutputVersion": "1.0",        "mcp": {            "transformedGatewayRequest": {               "headers": {                    "Accept": "application/json",                    "Authorization": auth_header,                    "Content-Type": "application/json"               },                 "body": extended_body             }         }     }    return response 認証なしと OAuth ベースの認可 多くの企業では、ツールの検出可能性とセキュリティのバランスを取る柔軟な認可モデルが必要です。AI エージェントやアプリケーションが、認可なしで利用可能な MCP ツールを検出および検索できるようにし、ツールカタログ全体でシームレスなツールの探索とセマンティック検索を可能にするシナリオを想定してみましょう。一方で、これらのツールを実際に呼び出す際には、認可されたエージェントとユーザーのみがツールを実行できるように、OAuth ベースの厳格な認可が必要です。さらに、一部のツールは認証が必要で、他のツールはパブリックにアクセス可能、あるいは呼び出し元のプリンシパルの ID やコンテキストに基づいて異なる権限レベルが必要など、ツールごとの認可ポリシーが必要になる場合もあります。 AgentCore Gateway は、すべてのインバウンド呼び出しに対してゲートウェイレベルで「認証なし」の認可タイプを導入することで、この柔軟性をサポートするようになりました。「認証なし」を設定すると、検出目的ですべてのターゲットとツールに認証なしでアクセスできるようになります。メソッドレベル (ListTools と CallTools) での OAuth 認可を強制したり、ツールごとの認可ポリシーを実装したりするには、ゲートウェイインターセプターを使用します。ゲートウェイインターセプターを利用することで、インバウンドの JWT を検査し、認可サーバーのディスカバリ URL を使用して RFC 6749 の要件に対して検証し、特定のメソッドやツール呼び出しへのアクセスをプログラムで許可または拒否することができます。このアプローチにより、きめ細かな制御が可能になります。ListTools や SearchTools リクエストのディスカバリを開放しながら、CallTools リクエストには厳格な OAuth 検証を強制したり、ツール、ユーザーロール、実行コンテキスト、その他組織が必要とするビジネスロジックに応じてカスタム認可ロジックを実装したりすることができます。これらすべてを、MCP 呼び出しのセキュリティが確保され、セキュリティポリシーに準拠した状態で実現できます。 次の図は、このワークフローを示しています。 このプロセスは、すべてのインバウンドコールに対してデフォルトで no-auth が設定された AgentCore Gateway への認証なしの ListTools 呼び出しから始まります。この設定により、ユーザーは認証なしで利用可能なツールを確認できます。ただし、ユーザーが特定のツールを呼び出すために CallTool リクエストを行う場合は、認証が必要です。AgentCore Gateway はカスタムリクエストインターセプター Lambda 関数を呼び出し、認証ヘッダーから JWT トークンを検証し、呼び出されている特定のツールに対するユーザーのスコープと権限をチェックします。認証が成功すると、インターセプターは必要な認証コンテキストでリクエストを変換および拡張し、AgentCore Gateway は変換されたリクエストをターゲットサービスに転送します。ターゲットはリクエストを処理してレスポンスを返し、AgentCore Gateway はそのレスポンスをクライアントに返します。このプロセスにより、ツール一覧の確認はオープンに保ちながら、実際のツール実行には厳密な OAuth ベースの認証を適用します。 インバウンドコールに対して認証なしで設定されたゲートウェイを作成するには、次の CreateGateway API に示すように、 authorizerType を NONE に設定します。 {   "name": "no-auth-gateway",   "protocolType": "MCP",   "protocolConfiguration": {     "mcp": {       "supportedVersions": ["2025-03-26"]     }   },   "authorizerType": "NONE",   "roleArn":  } オブザーバビリティ AgentCore Observability が提供する包括的なオブザーバビリティは、AgentCore Gateway を通じて複数のツールやサービスと連携する AI エージェントワークフローの監視、デバッグ、監査に不可欠です。ゲートウェイインターセプターは、下流のサービスが実行される前に認可を強制し、リクエストを変換し、データをフィルタリングするため、オブザーバビリティのレイヤーは重要なセキュリティ境界となります。これにより、以下の主要なメリットが得られます。 セキュリティ判断の可視化 – インターセプターは、許可/拒否の判断や評価された JWT スコープを含む、認可結果の信頼できるログを生成します。これにより、拒否されたリクエストの確認、ポリシーの動作の検証、ツール呼び出し全体での認可ルールの適用状況の分析に使用できる明確な監査証跡が提供されます。 リクエストとレスポンスのトレーサビリティ – インターセプターは、ヘッダーの拡充、スキーマ変換、機密データの編集など、MCP リクエストとレスポンスがどのように変更されたかを記録します。これにより、ペイロードの変更を完全にトレースでき、エージェントのワークフロー全体で安全かつコンプライアンスに準拠したデータ処理をサポートします。 下流ツールの可観測性 – インターセプターは、ステータスコード、レイテンシー、エラーレスポンスなど、下流ツールの動作をログに記録します。これにより、ターゲット全体で一貫した可視性が確保され、チームは障害のトラブルシューティング、信頼性の問題の特定、エンドツーエンドの実行特性の理解が容易になります。 これらのログはアイデンティティとコンテキストの属性も取得するため、複数のユーザーグループやテナントが同じゲートウェイを共有する環境で、認可の動作を検証し、問題を特定するのに役立ちます。ゲートウェイインターセプターは AgentCore Observability と自動的に統合され、以下の機能を提供します。 認可の判断の リアルタイムモニタリング 所要時間と呼び出し指標による パフォーマンスのボトルネック特定 マルチホップのエージェントワークフローにおける エンドツーエンドのトレーサビリティ マルチテナント環境での認可動作を検証するための ID とコンテキスト属性 次のスクリーンショットは、ゲートウェイインターセプターの Amazon CloudWatch ロググループからのサンプルメトリクスを示しています。 メトリクスによると、ゲートウェイインターセプターは 100% の成功率、最小限のレイテンシー (平均 4.47 ミリ秒)、スロットリングの問題がないなど、健全なパフォーマンスを示しています。これは、システムが最適なパラメータ内で動作しているということです。 次のスクリーンショットは、ゲートウェイインターセプターの CloudWatch からのサンプルログを示しています。 AgentCore Observabilityとの統合により、認可の判断をリアルタイムでモニタリングし、パフォーマンスのボトルネックを特定し、マルチホップのエージェントワークフローにおけるエンドツーエンドのトレーサビリティを維持できます。 まとめ エージェント型 AI システムを大規模に展開する際、組織はセキュリティとアクセス制御という根本的な課題に直面します。AgentCore Gateway のゲートウェイインターセプターは、この課題を解決します。本稿で紹介した 3 つのパターン (ツール呼び出しに対するきめ細かなアクセス制御、ツールの動的なフィルタリング、アイデンティティ伝播) は、安全なエージェント型アーキテクチャを構築するための基盤となる構成要素 (ビルディングブロック) です。これらのパターンにより、認証のギャップを埋め、認証情報を適切に分離し、独自のセキュリティポリシーを適用できます。ゲートウェイインターセプターは、リクエストとレスポンスの両方にプログラム可能な介入ポイントを提供します。これにより、既存のツール実装や MCP サーバーアーキテクチャに手を加えることなく、きめ細かなアクセス制御を実装できます。組織が数百のエージェントと数千のツールに拡大すると、複雑なエージェント型 AI 環境全体でセキュリティ、コンプライアンス、運用の可視性を確保することが不可欠です。ゲートウェイインターセプターは、そのために必要な柔軟性と制御機能を提供し、エンタープライズ統合パターンやセキュリティのベストプラクティスにも準拠しています。ゲートウェイインターセプターを備えた AgentCore Gateway は、エージェント型 AI アーキテクチャにエンタープライズグレードのセキュリティ制御を実装するための柔軟な基盤となります。一般的なエンタープライズの課題に対してゲートウェイインターセプターをどのように活用できるかについて、詳しくは以下のコードサンプルをご参照ください。 きめ細かなアクセス制御 – JWT スコープを使用したツールのロールベースアクセス制御を実装 カスタムヘッダーの伝播 – カスタムヘッダーを変換し、ターゲット API に伝播 ゲートウェイインターセプターの設定とデプロイメントに関する完全なドキュメントについては、 Amazon Bedrock AgentCore Gateway のきめ細かなアクセスコントロール を参照してください。 著者について Dhawal Patel は AWS のプリンシパル Generative AI テックリードです。大企業から中規模のスタートアップまで、さまざまな組織と共に、エージェント AI、ディープラーニング、分散コンピューティングに関する課題に取り組んできました。 Ganesh Thiyagarajan は、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験を持つ AWS のシニアソリューションアーキテクトです。ISV が AWS 上でアプリケーションを変革し、モダナイズするためのサポートを行っています。また、AI/ML テクニカルフィールドコミュニティのメンバーとして、お客様の生成 AI ソリューションの構築とスケーリングを支援しています。 Avinash Kolluri は AWS のシニアソリューションアーキテクトです。Amazon とその子会社と協力して、イノベーションと運用の優位性を加速するクラウドソリューションの設計と実装を行っています。AI/ML インフラストラクチャと分散システムに関する深い専門知識を持ち、基盤モデルの構築、ワークフロー自動化、生成 AI ソリューションのために AWS サービスを活用するお客様を支援することを専門としています。 Bhuvan Annamreddi は AWS のソリューションアーキテクトです。ISV のお客様と協力して高度なクラウドアーキテクチャの設計と実装を行い、AWS サービスを活用して製品の強化を支援しています。生成 AI とサーバーレスアーキテクチャに強い関心を持ち、意味のあるビジネス価値を提供するためのイネーブラーとして、お客様のスケーラブルで安全な革新的なシステムの構築を支援することに情熱を注いでいます。 Mohammad Tahsin は AWS の Generative AI スペシャリストソリューションアーキテクトとして、最新の AI/ML ソリューションの設計、最適化、デプロイについてお客様をサポートしています。この分野における新しい機能の最前線に立ち続けることと継続的な学習に情熱を注いでいます。趣味は、ゲーム、デジタルアート、料理です。 Ozan Deniz は AWS のソフトウェア開発エンジニアとして働いています。彼とチームは生成 AI によって販売者の機能を強化することに注力しています。仕事以外の時間はアウトドア活動を楽しんでいます。 Kevin Tsao は AgentCore Gateway チームのソフトウェア開発エンジニアです。Amazon に在籍して 6 年になり、その間、Bedrock Agents や Amazon Lex などのサービスに貢献し、会話型 AIとエージェント型 AI の分野で働いています。 本記事の翻訳は Solutions Architect の安藤慎太郎が担当しました。原文は こちら です。

みなさんこんにちは。ソリューションアーキテクトの三厨です。2025 年 10 月 14 日にお客様を AWS にお招きして「セキュリティと生成AI について学ぶ GameDay with AWS Partners」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティ/生成 AI への取り組みを知って頂ければ幸いです。 AWS GameDay とは AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWSが提供するユニークなトレーニングプログラムですです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。 このプログラムの特徴は、実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。 参加者は、AWS SecurityHub などの実際のAWSセキュリティサービスを駆使しながら、インシデントの検知から対応までを体験します。このハンズオン形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。 この AWS GameDay の魅力の一つは、ゲーミフィケーションの要素を取り入れている点です。チーム間で競い合いながら学習を進めることで、参加者のモチベーションを高く保ちつつ、効果的な学習を実現しています。さらに、チームでの協力が必要となるため、組織内のコミュニケーション能力の向上にも役立ちます。 セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDayは、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会となっています。多くの企業がクラウド環境でのビジネスを展開する現代において、このような実践的なセキュリティトレーニングの重要性は、ますます高まっているといえるでしょう。 AWS GameDay の流れ、イベントの様子 今回のイベントでは、24社70名 の方々に参加いただきました。CCoEや情報システム部に所属する方だけでなく、事業部に所属されている方や管理職の方など、セキュリティに関心の高い幅広いお客様がGameDayに真剣に取り組んでいただいておりました。皆様は 3 名ごとにチームに分かれてインシデントが発生したというシナリオを元に実際の AWS 環境にログインいただき制限時間2時間の中で調査を行っていただきました。 GameDay の様子 最終結果 – 優勝チームのご紹介 ゲーム本編が終了いたしましたら結果発表となります。今回最も得点を獲得した優勝チームはコニカミノルタ株式会社の皆様が率いるチームでした。おめでとうございました。コニカミノルタ株式会社の皆様からはコメントを頂戴しています。 表彰の様子 イベントに関するご感想 緊張感をもって他社チームと競い合いながら、多くの学びと刺激を得られ、とても貴重な経験になりました！ 工夫された点 等 GameDayが初めてのメンバーもいたので、雰囲気に慣れつつ、気になる部分は1つ1つ解消して進めました。生成AIも活用しながら進めることで、学びを多く得ながらスピード感を持って対応できました！ 解説とパートナーソリューションについて 結果発表の後は、Agentic AI の時代におけるセキュリティについてを AWS と AWS のパートナー 4社 によりお伝えさせていただきました。 Palo Alto Networks パロアルトネットワークスは、グローバル・サイバーセキュリティのリーダーとして継続的なイノベーションを通じてデジタルライフの保護に取り組んでいます。世界中の70,000以上の組織からの信頼と脅威インテリジェンスチームUnit 42の専門知識によってネットワーク、クラウド、セキュリティ運用に渡る包括的なAI搭載セキュリティソリューションを提供しています。パロアルトネットワークスのプラットフォーム化への注力によって、組織は規模に応じてセキュリティを合理化し、セキュリティが組織のイノベーションを促進することを確実にします。   CyberArk CyberArk（NASDAQ：CYBR）は、アイデンティティ セキュリティの世界的なリーダー企業です。モダンエンタープライズにおける人とマシンのアイデンティティを保護する企業として、世界中の組織から信頼されています。CyberArkのAIを活用したアイデンティティ セキュリティ プラットフォームは、アイデンティティの全サイクルにおいて継続的に脅威を予防、検出、対応し、インテリジェントな特権制御をすべてのアイデンティティに適用します。これにより、組織は完全な可視性とゼロトラスト、最小特権の適用を通じて運用およびセキュリティリスクを削減し、従業員、IT、開発者、マシンを含むすべてのユーザーが、場所を問わず安全にリソースにアクセスできるようになります。   Weights&Biases Weights & Biases Japan株式会社は、エンタープライズグレードのML実験管理およびエンドツーエンドMLOpsワークフローを包含する開発・運用者向けプラットフォームを販売する日本法人です。W&Bは、LLM開発や画像セグメンテーション、創薬など幅広い深層学習ユースケースに対応し、国内外で100万人以上の機械学習開発者に信頼されているAI開発の新たなベストプラクティスです。   KnowBe4 KnowBe4は、世界で70,000社以上に採用されているセキュリティ意識向上トレーニングとフィッシング訓練のグローバルリーダーです。ヒューマンリスクマネジメントプラットフォーム（HRM+）は、従業員のセキュリティに関する人的な脆弱性と強みを可視化し、個別に最適化されたトレーニングを提供。これにより、効果的にセキュリティ意識を向上させ、行動変容を促します。トレーニングコンテンツは34ヶ国語以上に対応。多様なビジネス環境に対応し、「人的」セキュリティを強化することで、強固なセキュリティ文化の構築を支援します。   GameDay の後に さて、それでは実際に運用しているサービスに今回の経験を活かしていただくにはどうすればよいでしょうか。 今回体験いただいた AWS SecurityHubなどの種々のセキュリティサービスを導入するのも良さそうですし、紹介いただいたパートナーソリューションを導入したりといった施策を進めるのも良さそうです。ただ、現実のサービスはゲームの状況よりも複雑です。単にサービスやソリューションを導入するのではなく、運用しているサービスの現状把握や人材育成や運用体制を整えるなど必要な手立てを認識する必要があります。 そこで AWS では AWS Well-Architected Framework (W-A) をご用意しています。W-A はAWSがクラウドを10年以上の運用してきた経験や数多くのお客様とのやりとりをもとに作りあげた クラウド設計・運用のベストプラクティス集です。優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性という 6つの柱に基づいて設計されており、気になる要素だけ利用いただくことも可能です。今回であればセキュリティの柱を利用して、まずは運用しているサービスの状況把握をしてみるのはいかがでしょうか。 こうした取り組みを通じて、イノベーションを促進するセキュリティ機能を構築し組織が迅速にスケールすることに自信を持つようなガードレールを作成することは、お客様が少ない労力でより強固なセキュリティポスチャを構築してより多くのリソースを成長に集中させるために重要です。ぜひ、この記事でご紹介したような方法を通じてセキュリティに関する可視性を得て、セキュリティ運用や体制を強化し、イノベーションを加速していきましょう。 このブログはアマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト 三厨 航 が執筆しました。 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。

このブログ記事は、AWS ソリューションアーキテクト 長谷川 仁志 が執筆し、日産自動車株式会社様が監修しています。 2025 年 12 月、アマゾン ウェブ サービス （以下、AWS）のグローバル年次イベント「 re:Invent 2025 」において、日産自動車株式会社（以下、日産自動車）は、AWS との連携により Software-Defined Vehicle (以下、SDV) の開発を加速する「Nissan Scalable Open Software Platform」を構築したことを 発表しました。日産自動車 は、これまでも IT、R&D など様々な領域で AWS を活用してきましたが、本記事では、日産自動車が AWS と連携して推進する SDV 開発の取り組みについて詳しく解説します。 SDV 開発における効率化の必要性 自動車産業は大変革期にあり、車両の価値の多くがソフトウェアによって決定されるようになっています。多くの自動車メーカーが SDV 開発の取り組みに注力するなか、グローバル自動車メーカーとして世界 100 カ国以上で年間 300 万台以上を販売し、常に革新的な製品とサービスを提供してきた日産自動車。同社は SDV 開発に向けた３つの目標 「迅速かつ継続的な価値提供」「必要な安全性と性能の確保」「EV、HEV からガソリン車まですべての顧客への SDV 提供」 を掲げており、その実現に向けた取り組みを加速しています（図表1）。 日産自動車では、SDV 実現に向けたソフトウェア開発のために、主に以下の項目への取り組みに着手しました。 複雑化するソフトウェアに対応する開発効率の向上 増加するテストケースに対応する包括的なテスト体制の整備 処理能力とリソースに制限のあるオンプレミス環境から柔軟性と拡張性に優れたクラウドへの移行 グローバル開発体制の再構築 図表1 出所：AWS AWS を活用した Nissan SDV Platform の構築 上記4つの取り組みを推進するため日産自動車は、2023年「Nissan Scalable Open Software Platform」の開発に着手しました（図表2）。同プラットフォームは、車両ソフトウェア開発を実行する作業環境「Nissan Scalable Open SDK（以下、Open SDK）」、車両データを集約し活用するデータ基盤環境「Nissan Scalable Open Data（以下、Open Data）」が AWS 上に構築され、デジタルツインを実現するための車両 OS「Nissan Scalable Open OS（以下、Open OS）」の 3 層で構成されています。 同プラットフォームの中核となる AWS 上に構築された環境の Engineering Cloud（Open SDK、Open Data）では、ソフトウェア開発から機械学習のトレーニング、テストケースを含むソフトウェアの評価、データ処理まで、包括的な開発環境を提供しています。日産自動車の北米、欧州、日本などの地域の開発チームや、独自のアプリケーションを提供するサードパーティの開発者は、この Engineering Cloud の環境を共通基盤として利用できるので、それぞれの地域固有のニーズへのより迅速な対応ができるとともに、各チームの開発成果物を相互に利用することが可能となり、グローバル体制の再構築につながっています。 図表2 出所：AWS 日産自動車は、この「Nissan Scalable Open Software Platform」の構築においては AWS と連携し、AWS の240を超えるサービス群の中から Platform が求める機能・性能を実現するサービスを活用し、AWS の プロフェッショナルサービス により開発を加速しています。以下では、この連携により実現された特徴的な機能の中から、「1. CI プロセスの自動化による開発効率の向上」「2. グローバル規模での開発環境の統一」「3. 次世代コンテナ管理による開発基盤の革新」を紹介します。 1. CI プロセスの自動化による開発効率の向上 日産自動車は車載ソフトウェア開発の CI パイプラインをオンプレミスのサーバーで実行していましたが、テストに多大な時間を要していました。この課題に対し、このパイプラインをクラウドへ移行し、 AWS Step Functions 、 AWS Lambda を活用した新しいパイプラインを開発しました（図表3）。 このパイプラインは、モデルベース開発とコードベース開発の両方に対応したソフトウェアコンポーネント SIL（Software-in-the-Loop）パイプラインと、各ソフトウェアコンポーネントを統合する統合 SIL の 2 段階で構成されています。さらに、統合SIL においては、AWS のスケールするコンピューティング環境（AWS Lambda）を活用した並列処理の実装により、車載ソフトウェアのテスト実行時間を75％削減することに成功しました。特に統合 SIL では、テストケースの実行から判定、結果のグラフ生成まで、すべての工程を自動化することで、開発者の作業効率を大幅に改善しています。 図表3 出所：AWS 2. グローバル規模での開発環境の統一 日産自動車は、グローバルな SDV 開発の加速に向けて、世界中に在籍する 5,000 人以上の開発者が利用できる共通の開発環境基盤が必要でした。特に、各地域の開発者が共通環境と地域固有の開発環境の両方にアクセスでき、かつ迅速に環境を展開できる仕組みが求められていました。これに対応するため、AWS 上にワークベンチポータルを開発しました。このポータルは、 Backstage をベースとした UI を採用し、世界中のエンジニアが統一された環境で作業できる基盤を提供します（図表4）。 ワークベンチポータルは、AMI を活用した環境展開により、開発者が必要な時に迅速に開発環境にアクセスできる仕組みを実現しています。また、CI パイプラインにおいては AWS CodeBuild と Amazon ECR を組み合わせることで、コンテナイメージのビルドとデプロイを最適化し、Docker in Docker 機能により複雑な開発ツールチェーンも効率的に管理できます。このシステムは、今後 5,000 人以上の開発者の利用を見込んでおり、共通環境と地域固有の環境を柔軟に展開できる設計となっています。 図表4 出所：AWS 3. 次世代コンテナ管理による開発基盤の革新 SDV 開発における重要な課題の一つが、物理 ECU、仮想 ECU、開発環境間でのシームレスな統合でした。日産自動車は、アプリケーションを頻繁に更新するという新たな要求に対応するため、革新的なアプローチとして量産車の実 ECU にコンテナ技術を採用する取り組みを進めています（図表5）。 ECU へのコンテナ採用により、柔軟なアプリケーション更新が可能となります。この実現のため、軽量コンテナ管理を目的として「 Podman 」を採用し、日産独自の3層構成の OS アーキテクチャを組み合わせた設計を採用しています。 AWS Graviton プロセッサー上の Linux 環境から Amazon EC2 上の開発環境まで、一貫したコンテナ管理を可能にし、特に物理 ECU でのコンテナ運用において、リソースの制約が厳しい環境でも効率的な動作を実現しています。さらに、このアーキテクチャは将来の AI 駆動型車両開発を見据えたデジタルツイン環境との統合も視野に入れた設計で、革新的な取り組みとなっています。 図表5 出所：AWS これらの取り組みにより、日産自動車の SDV プラットフォーム「Nissan Scalable Open Software Platform」は、車両アプリケーションから電動パワートレイン、ボディ制御まで、幅広い領域での開発を効率的にサポートする基盤として機能しています。さらに、OTA システムやビリングシステムとの連携により、継続的な価値提供と新たなビジネス機会の創出を可能にしています。 今後の展望：AI活用による更なる進化 日産自動車は、今後も SDV の更なる発展に向けて、AI 技術の活用を積極的に推進していきます。 次世代ProPILOT では、市街地などのより複雑な交通環境を含む一般道において、熟練ドライバーのような運転を可能とした、信頼できる安全な運転支援技術を実現します。次世代 ProPILOT は、2025 年 9 月に開発試作車の運転能力を公開し、2027年度に国内の市販車への搭載を予定しています。これらの機能を支えるため AWS と連携して構築した 「Nissan Scalable Open Software Platform」 をさらに発展させ、Engineering Cloud 上での AI 開発環境の強化を進めていく予定です（図表6）。 図表6 出所：AWS まとめ 日産自動車が AWS との連携により 構築した SDV プラットフォーム「Nissan Scalable Open Software Platform」は、日産自動車にとって今後の自動車産業における競争力の源泉となることが期待されます。 AWS は今後も、日産自動車の「迅速かつ継続的な価値提供」「必要な安全性と性能の確保」「EV、HEV からガソリン車まですべての顧客への SDV 提供」の実現に向けた取り組みを支援していきます。本事例は、従来の製造業がいかにしてソフトウェア主導の開発モデルへと進化できるかを示す優れた実例となっており、同様の課題に取り組む他の企業の皆様にとっても参考になれば幸いです。 日産自動車株式会社　ソフトウエアデファインドビークル開発本部　ソフトウェア開発部部長　杉本 一馬様からのコメント 日産はこれまでも AWS と連携し、車載ソフトウェア開発における CI/CD のクラウド化を 2024 年から実プロジェクトに適用し、着実に開発の効率化をしてきました。この度、「Nissan Scalable Open Software Platform」を発表できたことを大変嬉しく思います。 Software-Defined Vehicle (SDV) でのソフトウェア開発は、日産がお客様へ革新的な価値を迅速かつ継続的に提供し、自動車産業の変革期をリードするための極めて重要な戦略であり、「Nissan Scalable Open Software Platform」はそのイネーブラーとなる Key technology です。 AWS の先進的なクラウド技術と専門知識は、グローバルな開発体制の効率化と、AI を活用した次世代のモビリティ実現に向けた私たちの取り組みを強力に推進してくれると確信しています。この SDV Platform を通じて、日産は未来のモビリティを創造し、お客様に新たな体験を提供してまいります。

この記事は Introducing the fully managed Amazon EKS MCP Server (preview) (記事公開日: 2025 年 11 月 21 日) を翻訳したものです。 複雑な kubectl コマンドや深い Kubernetes の専門知識の代わりに、シンプルな会話を通じて Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを管理する方法を学びましょう。この記事では、新しいフルマネージド EKS Model Context Protocol (MCP) Server (プレビュー) を使用して、深い Kubernetes の専門知識を必要とせず、自然言語でアプリケーションのデプロイ、問題のトラブルシューティング、クラスターのアップグレードを行う方法を紹介します。複数ステップの手動タスクをシンプルな自然言語リクエストに変換する会話型 AI の実際のシナリオを説明します。 Kubernetes ワークロードを管理するチームには、コンテナオーケストレーション、インフラストラクチャ、ネットワーキング、セキュリティにわたる専門知識が必要です。大規模言語モデル (LLM) は開発者がコードを書いたりワークロードを管理したりするのに役立ちますが、リアルタイムのクラスターアクセスがなければ制限されます。古いトレーニングデータに基づく一般的な推奨事項は、実際のニーズを満たしません。 Model Context Protocol (MCP) は、AI モデルにクラスターデータへのリアルタイムの安全なアクセスを提供することで、この問題を解決します。 MCP は、AI モデルがより良いコンテキストのために外部ツールやデータソースに安全にアクセスできるようにするオープンソース標準です。EKS クラスターのリアルタイムでコンテキストに応じた知識で AI アプリケーションを強化する標準化されたインターフェースを提供し、開発から運用まで、アプリケーションライフサイクル全体を通じてより正確でカスタマイズされたガイダンスを可能にします。今年初め、AWS は MCP プロトコルのリリースから数か月以内に、MCP サーバーを 発表 した最初のマネージド Kubernetes サービスプロバイダーの 1 つでした。お客様は EKS と Kubernetes リソース管理のために、この EKS MCP Server をマシンにインストールできました。この初期のローカルインストール可能なバージョンの EKS MCP Server により、私たちはアプローチを迅速に検証し、貴重なお客様のフィードバックを収集することができ、それが今日の発表に直接つながっています。 私たちが受け取った最も一貫したフィードバックは、クラウドホスト型のフルマネージド EKS MCP Server の必要性についてでした。本日、AWS はフルマネージド Amazon EKS MCP Server (プレビュー) をリリースしました。新しいホスト型 EKS MCP Server は、本番環境に不可欠な機能で以前のリリースを改善しています。 インストールとメンテナンスの排除 : バージョン更新の管理やローカルサーバーの問題のトラブルシューティングは不要です。軽量プロキシを通じてホスト型 EKS MCP Server エンドポイントに接続するように AI アシスタントを設定することで、新しいツール、機能、バグ修正を自動的に受け取ります。 一元化されたアクセス管理 : AWS Identity and Access Management (IAM) との深い統合により、サーバーへのアクセスを制御する一元化された安全な方法が提供されます。すべてのリクエストは AWS Signature Version 4 (SigV4) を使用して署名され、既存の AWS 認証情報と IAM ポリシーとのシームレスな統合が可能になります。 強化されたトラブルシューティング : 大規模に数百万の Kubernetes クラスターを管理した運用経験から構築されたナレッジベースへのアクセス。 強化された監視と可視性 : AWS CloudTrail 統合により、ホストされたサービスを通じて行われたすべてのツール呼び出しがキャプチャされ、AI 支援操作の詳細な監査証跡とコンプライアンスレポートが可能になります。 フルマネージド EKS MCP Server の目標は、 Kiro (IDE と CLI) 、 Cursor 、 Cline などの AI を活用した開発ツールを使用している場合でも、EKS クラスターとインターフェースする必要がある独自のエージェントを構築している場合でも、エージェント体験を可能にすることです。この標準化されたインターフェースにより、MCP 互換の AI ツールは、すぐに強力な EKS ガイダンスと自動化を提供できるようになりました。 ホスト型 MCP サーバーに加えて、 Amazon Q とのより深い統合を通じて、Amazon EKS コンソールのトラブルシューティング体験も大幅に改善しています。強化されたコンソールでは、オブザーバビリティダッシュボードのエラーメッセージのすぐ横に AI を活用したトラブルシューティングオプションが表示されます。ワンクリックで根本原因を診断し、修正手順を確認できます。クラスター、コントロールプレーン、ノードヘルスの問題を調査している場合でも、問題の一覧または詳細ビューから直接「Amazon Q で検査」をクリックして調査を開始できます。コンソール統合により、クラスターのヘルスと今後のアップグレードに関する重要な詳細が明らかになり、本番ワークロードに影響を与える前に問題を発見できます。 Amazon EKS MCP Server ツール EKS MCP Server は、問題の診断と EKS クラスターとその Kubernetes コンポーネントの両方を制御するための専門ツールを提供します。これらのツールは次のカテゴリに分類されます。 クラスター管理ツール – EKS クラスターの作成と管理 Kubernetes リソース管理 – Kubernetes コマンドに依存せずに EKS クラスター内の Kubernetes リソースを操作および管理します。 アプリケーションデプロイ – アプリケーションをデプロイするための Kubernetes マニフェストを生成します。 トラブルシューティング – 大規模に Kubernetes クラスターを実行する AWS の運用知識から得られたトラブルシューティングガイドを提供します。 ドキュメントとナレッジベース – 最新の情報とベストプラクティスのために AWS ドキュメントとナレッジベースを検索します。 ツールの完全なリストについては、EKS MCP Server ユーザーガイド をご覧ください。 Amazon EKS MCP Server の使用開始 前提条件 AWS 設定: この機能を使用するには、AWS CLI がマシンにインストールされ、設定されている必要があります。MCP 設定で使用するプロファイルを設定するには、ドキュメント「 Configuration and credential file settings in the AWS CLI 」に従ってください。このブログ記事のシナリオでは、AWS プロファイルは us-west-2 リージョンへのアクセスで設定する必要があります。 MCP クライアント: MCP をサポートする多くのエージェントツールの 1 つを使用できます。このブログ記事では、クライアントとして Kiro CLI を使用します。Kiro CLI の MCP クライアント設定をセットアップするには、 MCP 設定ファイル仕様 に従ってください。 Python 環境: Python の uv パッケージマネージャーがインストールされている 必要があります。パッケージマネージャーは mcp-proxy-for-aws パッケージを自動的にダウンロードして実行するため、個別にインストールする必要はありません。MCP プロキシにより、クライアントは AWS SigV4 認証を使用してリモートの AWS ホスト型 MCP サーバーに接続できます。 AWS Identity and Access Management (IAM) アクセス許可 : AWS プロファイルには、EKS クラスターの読み取り、CloudWatch ログへのアクセス、Kubernetes リソースの表示のための EKS 関連の IAM アクセス許可が必要です。AWS プロファイルへのアクセスを許可する際は、最小権限の原則に従ってください。MCP Server への接続に使用されるロールには、初期化と利用可能なツールに関する情報の取得のために IAM eks-mcp:InvokeMcp のアクセス許可が必要です。読み取り専用ツールの使用には eks-mcp:CallReadOnlyTool が必要で、フルアクセス (書き込み) ツールの使用には eks-mcp:CallPrivilegedTool が必要です。 設定 フルマネージド EKS MCP Server アーキテクチャは、AWS SigV4 認証を使用して MCP クライアントを AWS サービスに安全に接続します。次の図は通信フローを示しています。 図 1: AI クライアントと AWS サービス間の MCP 通信フローを示すアーキテクチャ図 Kiro CLI の設定例を次に示します。 { "mcpServers": { "eks-mcp": { "disabled": false, "type": "stdio", "command": "uvx", "args": [ "mcp-proxy-for-aws@latest", "https://eks-mcp.us-west-2.api.aws/mcp", "--service", "eks-mcp", "--profile", "default", "--region", "us-west-2" ] } } } エンドポイント URL https://eks-mcp.{AWS_REGION}.api.aws/mcp の us-west-2 リージョンに注目してください。これは MCP Server がホストされているリージョンです。 --profile フラグは、MCP Server への接続に使用されるローカル AWS プロファイルを参照します。このフラグはオプションで、環境変数 AWS_PROFILE を使用できます。 --region フラグは、作業対象の EKS クラスターをスコープするリージョンを参照します。このフラグはオプションで、環境変数 AWS_REGION を使用できます。 --read-only フラグを使用して、読み取り専用ツールのみが許可されることを示すことができます。 ツールアクセスレベル EKS MCP Server は 2 つのアクセスレベルをサポートしています。 読み取り専用モード ( --read-only フラグ): すべての読み取り操作とドキュメントツールへのアクセスを提供 フルアクセスモード : すべての読み取り専用ツールに加えて、クラスター作成、リソース管理、ポリシー変更などの書き込み操作を含む 各ツールは、特定の aws eks または kubectl CLI コマンドを置き換えるように設計されており、MCP プロトコルを通じた EKS の管理のためのより統合された体験を提供します。 シナリオ 1: 会話型 AI による EKS クラスターのアップグレード EKS インサイトを使用してクラスターのアップグレード準備状況を評価する EKS MCP Server の機能は重要な機能です。このセクションでは、EKS クラスターが Kubernetes バージョンのアップグレードの準備ができているかどうかを確認する方法を示します。 アップグレード準備状況の確認 プロセスには 3 つの簡単なステップが含まれます。 利用可能なクラスターを一覧表示 して、確認するクラスターを特定する アップグレード準備状況のインサイトを取得 して互換性を評価する EKS ドキュメントを検索 してタイムラインを特定する 実際の例を見てみましょう。 1. EKS クラスターの一覧表示 まず、次のプロンプトから始めます。 Assess my EKS Auto cluster's upgrade readiness, including support status, upgrade timeline, and any blocking issues (翻訳: my EKS Auto cluster のアップグレード準備状況を、サポート状況、アップグレードタイムライン、ブロッキング問題を含めて評価してください) エージェントは list_eks_resources を使用して利用可能なクラスターを検出し、 describe_eks_resource を介して設定を取得します。 図 2: 利用可能な EKS クラスター「my-auto-cluster」を表示するターミナル出力のスクリーンショット これは、評価に利用可能な「my-auto-cluster」という名前のクラスターが 1 つあることを示しています。 2. アップグレード準備状況インサイトの確認 次に、エージェントは UPGRADE_READINESS カテゴリで get_eks_insights ツールを使用して、クラスターのアップグレード準備状況を評価します。 図 3: EKS クラスターのアップグレード準備状況インサイトを示すターミナル出力 3. EKS ドキュメントの検索 最後に、エージェントはアップグレードのタイムラインと価格について EKS ドキュメントを検索します。 図 4: アップグレードタイムラインの EKS ドキュメント検索結果を表示するターミナル出力 アップグレード準備状況レポート インサイト分析に基づいて、包括的なアップグレード準備状況レポートを次に示します。 図 5: すべての互換性チェックが合格していることを示す包括的なアップグレード準備状況レポート クラスター「my-auto-cluster」は Kubernetes 1.33 へのアップグレードの準備が完全に整っています。すべての重要な互換性チェックが合格しており、アップグレードを阻害する問題は特定されませんでした。 アップグレードに EKS MCP を使用する主な利点 自動評価 : 複数のコンポーネントを手動で確認する必要がありません 包括的なカバレッジ : アドオン、ノードの互換性、クラスターのヘルスを評価します 明確なガイダンス : 各チェック結果の具体的な理由を提供します プロアクティブな警告 : 問題がブロッカーになる前に潜在的な問題を特定します EKS Auto Mode の認識 : 最新の EKS デプロイパターンを理解します アップグレード前に互換性を自動的にチェックすることで、準備にかかる時間が短縮され、デプロイの失敗が減少します。 シナリオ 2: 自然言語によるアプリケーションのデプロイ EKS MCP Server は、自然言語プロンプトを通じて高レベルのワークフローを可能にします。たとえば、ユーザーは次のようにリクエストできます。 I want to deploy a simple web app to my EKS cluster named my-auto-cluster that shows 'Hello EKS!' on the page. Use the image from public.ecr.aws/docker/library/httpd:2 as the base, customize it with my message, push it to ECR as linux amd64, and make it accessible from the internet using a load balancer (翻訳: my-auto-cluster という名前の EKS クラスターに、ページに「Hello EKS!」と表示するシンプルな Web アプリをデプロイしたいです。 public.ecr.aws/docker/library/httpd:2 のイメージをベースとして使用し、メッセージでカスタマイズし、linux amd64 として ECR にプッシュし、 ロードバランサーを使用してインターネットからアクセスできるようにしてください) エージェント (Kiro CLI) は、このワークフローを完了するために複数の EKS MCP ツールを調整します。 主要な EKS MCP ツールの動作 1. アプリケーションマニフェストの生成 generate_app_manifest ツールは、最小限の入力で本番環境対応の Kubernetes マニフェストを作成し、デプロイ、サービス、ロードバランサーを自動的に設定します。 図 6: Web デプロイ用のアプリケーションマニフェスト生成を示すターミナル出力 2. 効率化されたデプロイ apply_yaml ツールは、複雑な kubectl ワークフローを置き換えて、単一の操作でマルチリソースの YAML 設定をデプロイします。 図 7: Kubernetes クラスターへの YAML デプロイを示すターミナル出力 3. リソースの検出とステータス list_k8s_resources と read_k8s_resource ツールを組み合わせて、インテリジェントなフィルタリングでデプロイされたリソースを検出し、詳細な設定を取得します。 図 8: デプロイされたアプリケーションのリソース検出とステータスを示すターミナル出力 4. アプリケーションログとイベント get_pod_logs と get_k8s_events ツールを組み合わせて、コンテナログと Kubernetes イベントの両方を表示する包括的なデバッグ機能を提供します。 図 9: アプリケーションログと Kubernetes イベントを表示するターミナル出力 5. CloudWatch オブザーバビリティ get_eks_metrics_guidance 、 get_cloudwatch_metrics 、 get_cloudwatch_logs ツールを組み合わせて、完全なオブザーバビリティのセットアップと監視を提供します。 図 10: CloudWatch オブザーバビリティメトリクスとログのセットアップを示すターミナル出力 デプロイの概要 完全なデプロイワークフローは、EKS MCP ツールがシームレスに連携する力を示しています。 図 11: マニフェストから監視までの完全なワークフローを示すデプロイ概要 EKS MCP Server は、複数ステップのデプロイを単一の会話リクエストに変換し、各段階で情報を提供しながら、オーケストレーション、エラー、監視を処理します。 結果として、AWS の Network Load Balancer を介してアクセス可能な完全なウェブアプリケーションができあがりました。EKS MCP サーバーがどのように複雑なデプロイワークフローを簡単な会話型のリクエストに簡略化できるかがわかります。 シナリオ 3: インフラストラクチャの問題のトラブルシューティング 問題が Kubernetes と AWS インフラストラクチャの境界をまたぐ場合、EKS MCP Server は効果的に診断します。 My LoadBalancer service hello-eks-app in the default namespace on my EKS cluster my-auto-cluster is stuck in pending state and not getting an external IP. Can you help me troubleshoot what's wrong and fix it? (翻訳: my-auto-cluster という EKS クラスターの default 名前空間にある LoadBalancer サービス hello-eks-app が pending 状態で 止まっており、外部 IP を取得できません。何が問題なのかトラブルシューティングして修正していただけますか？) エージェントは、問題を診断して解決するために複数の EKS MCP ツールを調整しました。 主要な EKS MCP ツールの動作 1. サービスステータス分析 read_k8s_resource ツールは LoadBalancer サービスの設定とステータスを取得し、サービスが作成されたにもかかわらず外部 IP が割り当てられていないことを明らかにしました。 図 12: LoadBalancer サービスステータス分析を示すターミナル出力 2. イベント調査 get_k8s_events ツールはサービスの Kubernetes イベントを調査し、サブネットに必要な kubernetes.io/role/elb タグが欠落していることを示す重要なエラーメッセージを発見しました。 図 13: サブネットタグの問題を明らかにする Kubernetes イベントを表示するターミナル出力 3. トラブルシューティングナレッジベース search_eks_troubleshooting_guide ツールは、LoadBalancer サービスの問題とサブネットタグの要件に関するガイダンスについて、専門の EKS トラブルシューティングナレッジベースを検索しました。 図 14: EKS トラブルシューティングガイドの検索結果を示すターミナル出力 4. インフラストラクチャ分析 get_eks_vpc_config ツールは包括的な VPC とサブネット設定の詳細を取得し、欠落しているタグが必要な特定のパブリックサブネットを特定しました。 図 15: VPC とサブネット設定の詳細を表示するターミナル出力 トラブルシューティングの概要 完全なトラブルシューティングワークフローは、EKS MCP ツールが Kubernetes と AWS ドメインをどのように橋渡しするかを示しています。 図 16: 診断手順と解決策を示すトラブルシューティングワークフローの概要 これは、EKS MCP Server が通常 Kubernetes と AWS インフラストラクチャの両方の専門知識を必要とする包括的なトラブルシューティングを可能にし、複雑な診断ワークフローを単一の会話インターフェースに統合する方法を示しています。 Amazon Q による強化された EKS コンソール体験 Amazon EKS は、Amazon Q 統合を通じて、CLI や IDE を超えてコンソールに直接エージェント体験をもたらします。「Amazon Q で検査」機能は、オブザーバビリティダッシュボード全体に表示され、トラブルシューティングと分析のためのコンテキストに応じた AI 支援を提供します。 統合された AI 支援 「Amazon Q で検査」ボタンは、複数のコンソールセクションに戦略的に配置されています。 クラスターのヘルスの問題 : ヘルスの問題が検出されると、「検査」をクリックして、無効化された KMS キーや設定の問題などの問題に対する AI を活用した分析と修復の提案を取得できます。 図 17: クラスターのヘルスの問題に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット アップグレードインサイト : アップグレード準備状況チェックの場合、検査機能は互換性の問題、バージョンスキューの問題、推奨されるアクションの詳細な説明を提供します。 図 18: アップグレードインサイトの警告に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット ノードヘルスのモニタリング : 個々のノードの問題は、検査機能を通じて分析でき、ノードのステータスと基盤となるインフラストラクチャの問題を関連付けます。 図 19: ノードヘルスのステータスに対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット オブザーバビリティデータ : 破損した Webhook、HTTP エラーパターン、API サーバーの問題などの複雑なオブザーバビリティデータは、AI を活用した説明を通じてよりアクセスしやすくなります。 図 20: 破損した Kubernetes Webhook に対する「Amazon Q で検査」を示す EKS コンソールのスクリーンショット コンテキストインテリジェンス 検査機能は Amazon Q の機能を活用し、コンソールのコンテキスト内で直接インサイトを提示します。これにより、ツールを切り替えたり、異なる AWS サービス間で情報を手動で関連付けたりする必要がなくなります。視覚的なダッシュボードから会話型トラブルシューティングへシームレスに移行でき、さまざまなレベルの Kubernetes 専門知識を持つチームにとって EKS の管理がより直感的になります。 まとめ プレビュー版の Amazon EKS MCP Server は、自然言語を通じて複雑な操作をアクセス可能にすることで、チームが Kubernetes とやり取りする方法を変革します。プレビュー版の EKS MCP Server は、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS 商用リージョンで利用できます。複数のドメインにわたる深い専門知識を必要とする代わりに、チームは Kubernetes と AWS サービスをシームレスに橋渡しする会話インターフェースを通じて EKS クラスターを管理できるようになりました。 会話型の EKS の管理を体験する準備はできましたか？この記事のセットアップ手順を使用して、環境で EKS MCP Server を設定することから始めましょう。読み取り専用操作から始めてクラスターインサイトを探索し、チームが会話インターフェースに慣れるにつれて、徐々に完全な管理機能に拡張してください。Amazon EKS MCP Server の詳細については、 Amazon EKS ユーザーガイド をご覧ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本日より、AWS Compute Optimizer はアイドル状態のリソース検出機能を NAT ゲートウェイ にまで拡張します。昨年発表したコンピューティング、ストレージ、データベースリソースに対するアイドル状態のレコメンデーションに続き、使用されていない NAT ゲートウェイリソースを特定してクリーンアップすることで、アプリケーションの信頼性を維持しながら、さらなるコスト削減を実現できるようになりました。 使用されていない NAT ゲートウェイのレコメンデーションを利用する理由 NAT ゲートウェイのようなネットワークインフラストラクチャリソースは、クラウド支出の大きな部分を占めていますが、これらのコストの最適化には固有の課題があります。コンピューティングリソースとは異なり、NAT ゲートウェイは高可用性と災害復旧アーキテクチャにおいて重要な役割を果たすことが多く、どれが本当に使用されていないのか、あるいはどれが災害復旧やバックアップのコンポーネントとして機能しているのかを確実に識別することが困難です。 Compute Optimizer の NAT ゲートウェイのレコメンデーションでは、使用パターンの分析だけでなく、ルートテーブルの関連付けなどのアーキテクチャ上のコンテキストも調査します。この追加のコンテキストにより、本当に使用されていないリソースと、災害復旧のために維持されているリソースを区別することができます。これにより、高可用性の設定を保護しながら、ネットワークコストを最適化できます。 NAT ゲートウェイはどのように “使用されていない” と判断されるのか Compute Optimizer は、NAT ゲートウェイが以下の “使用されていない状態” の条件に該当するかどうかを判断するために、32 日間の Amazon CloudWatch メトリクスを分析します: アクティブな接続がないこと ( ActiveConnectionCount = 0) Amazon Virtual Private Cloud (VPC) 内のクライアントからの受信パケットがないこと ( PacketsInFromSource = 0) 送信先からの受信パケットがないこと ( PacketsInFromDestination = 0) バックアップ構成を保護するため、NAT ゲートウェイがルートテーブルに関連付けられているかどうかも確認します。トラフィックはゼロでもルートテーブルに関連付けられている NAT ゲートウェイは、多くの場合、ネットワークアーキテクチャにおけるスタンバイコンポーネントとして機能しています。ルートテーブルの関連付けを確認することで、このような重要なバックアップコンポーネントを削除対象として推奨しないようにしています。 本当に使用されていない NAT ゲートウェイについては、それらが災害復旧設定の一部かどうかを確認することをお勧めします。例えば、一部の組織では、フェイルオーバーイベント時にプログラムでルートテーブルを更新する AWS Lambda 関数を使用しており、プライマリに障害が発生した場合にのみ、バックアップ用の NAT ゲートウェイにトラフィックをリダイレクトします。このような場合、バックアップ用の NAT ゲートウェイは通常運用時にはトラフィックがゼロでルートテーブルの関連付けもないため、自動検出では「Unused」として使用されていないように表示されます。そのため、“使用されていない” とフラグが付けられた NAT ゲートウェイを削除する前に、高可用性と災害復旧のアーキテクチャを手動で確認することが不可欠です。 使用開始方法 Compute Optimizer にオプトインすると、24 時間以内に使用されていない NAT ゲートウェイのレコメンデーションが自動的に提供され始めます。これらのレコメンデーションは、Compute Optimizer コンソールの既存のアイドル状態のリソースの検出結果と並んで表示されます。 ダッシュボードで「アイドル状態のリソース」ページに移動すると、NAT ゲートウェイを含む、すべてのアイドル状態または使用されていないリソースの統合ビューが表示されます。テーブルには、対応すべきアクションの優先順位付けに役立つ、推定月間節約額 (Estimated monthly savings)、リソースの詳細、およびタグが表示されます: 図1. リソースタイプ別のレコメンデーション一覧表 使用されていない NAT ゲートウェイを個別に選択すると、そのリソースが “使用されていない” と判断された理由を示す使用率メトリクスの詳細ビューが表示されます。32 日間の分析期間における ActiveConnectionCount 、 PacketsInFromSource 、 PacketsInFromDestination のグラフが表示され、アクションを実行する前に “使用されていない状態” を確認できます: 図2. NAT ゲートウェイの詳細ビューとメトリクス これらのレコメンデーションには、Compute Optimizer API を使用してプログラムでアクセスすることもできます。既存の GetIdleRecommendations API で NAT ゲートウェイリソースが利用可能になりました。詳細については、 ユーザーガイド をご参照ください。 AWS Cost Optimization Hub との統合 使用されていない NAT ゲートウェイのレコメンデーションは AWS Cost Optimization Hub (コスト最適化ハブ) とも統合されており、既存のワークフローにネットワークの最適化を組み込むためのもう一つの選択肢を提供します。 Cost Optimization Hub では、これらの NAT ゲートウェイのレコメンデーションがコミットメントやライトサイジング (サイズ適正化) のレコメンデーションと並んで表示され、組織全体の最適化機会を包括的に確認できます。Cost Optimization Hub はレコメンデーション間で重複するコスト削減額を自動的に排除し、削減可能総額を正確に把握できるようにします。 まとめ AWS Compute Optimizer の “使用されていないリソース” の検出機能を NAT ゲートウェイまで拡張することにより、コンピューティング、ストレージ、データベースリソースと共にネットワークインフラストラクチャにも対応した、より包括的なコスト最適化戦略を実装できるようになりました。このサービスはアーキテクチャの状況を考慮するため、災害復旧とフェイルオーバー構成を保護しながら使用されていないリソースを特定でき、最適化を確実に進めることができます。 Compute Optimizer コンソール にアクセスするか、 ユーザーガイド で詳細を学んで、今日から始めましょう。 Nathan Yuan Nathan Yuan は AWS のシニアテクニカルプロダクトマネージャーで、アイドル状態の検出とライトサイジングのレコメンデーションを中心に、最適化製品を担当しています。データ主導のインサイトとクラウド最適化戦略を通じて、お客様のコスト効率化を支援する業務に注力しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

本日より、AWS Compute Optimizer は Amazon Elastic Block Store (EBS) ボリュームの最適化方法を効率化する新しい自動化機能を導入します。最適化作業に貴重なエンジニアリング時間を費やす代わりに、Compute Optimizer のデータに基づくレコメンデーションに従って、アタッチされていないボリュームの継続的なクリーンアップとボリュームタイプのアップグレードを行う自動化ルールを作成できるようになりました。これにより、チームは最も重要な業務に集中できるようになります。 レコメンデーションの確認と適用 自動化ルールを設定する前に、アクションを個別にテストしてレコメンデーションの内容をよく理解しておきましょう。新しい「推奨アクション (Recommended actions)」ページには、AWS Compute Optimizer を通じて直接実施できる最適化の機会が一覧表示されます。実施したいアクションを選択してクリックするだけで適用できます。利用可能な最適化アクションは 2 つあります： アタッチされていない Amazon EBS ボリュームのスナップショット作成と削除: EC2 インスタンスに 32 日以上アタッチされていないボリュームに推奨されます。Compute Optimizer はボリュームを削除する前にスナップショットを作成します。このレコメンデーション基準の詳細については、リソースごとのアイドル状態の基準をご参照ください。 Amazon EBS ボリュームタイプのアップグレード: gp2 から gp3 へ、io1 から io2 へのアップグレードを推奨します。新世代のボリュームタイプへのアップグレードは、従来のタイプと比べて低価格で優れた IOPS とスループット性能を提供するため、より優れたパフォーマンスとコスト効率を実現できます。 ボリューム ID をクリックすると、レコメンデーションの詳細を確認できます。AWS リージョンやリソースタグでフィルタリングして、最適化したいフリートの特定のセグメントを対象にできます。レコメンデーションを確認した後、適用したいアクションを選択し、次のページで確認して実装を開始します（図 1 を参照）。この手動のアプローチは、一回限りのクリーンアップ作業や、各アクションの確認が必要な場合の最適化プロセスの学習に最適です。 図 1: レコメンデーションの確認と適用 自動化ルールによる最適化の効率化 推奨アクションの内容を把握したら、自動化ルール (automation rules) を使用してリソース全体に実装を展開できます。Compute Optimizer は、ルールの基準に一致するたびに、定期的なスケジュールでレコメンデーションを適用します。 1 つの自動化ルールでグローバルに対応できるため、AWS リージョンごとに個別のルールを作成してデプロイする必要はありません。管理アカウントまたは委任管理者は、複数のアカウントにまたがる組織全体のルールを設定でき、一方でメンバーアカウントは特定のニーズに応じてルールを追加する柔軟性を維持できます (図 2 を参照)。 図 2: 組織用の自動化ルールの作成 特定の要件に合わせて自動化ルールを素早く設定できます。特定の地域を対象とするリージョン、本番環境と開発環境のワークロードを区別するためのリソースタグ (Resource tags)、中断のない最適化アクションをフィルタリングするための「restart needed」フラグなどの条件を指定できます。 条件を設定した後、一致する推奨アクションをプレビューして対象の選択を検証できます。条件に一致する現在の推奨アクションと、ルール条件を検証するためのすべてのアクションおよび推定月間節約額の概要を確認できます。 図 3: 自動化ルールの作成 ルールを日次、週次、または月次で実行するように設定すると、Compute Optimizer はその条件に照らして新しいレコメンデーションを継続的に評価します。これにより、新たに特定された “アタッチされていないボリューム” は自動的にスナップショットが作成されて削除され、古い世代のボリュームタイプはルールに従って自動的にアップグレードされます。手動での介入は必要ありません。 図 4: 定期的なスケジュールの設定 自動化イベントの監視 新しいダッシュボードでは、すべての自動化の状況を把握でき、ステータスと実行月ごとのイベント数と推定月間節約額の概要が表示されます。時間の経過に伴う自動化の進捗状況を追跡でき、必要に応じて最適化戦略を改善するのに役立ちます。 図 5: 自動化イベントの概要 同じダッシュボードで各自動化イベントの詳細を掘り下げることができます。各最適化のステータスを追跡し、各自動化の詳細なステップ履歴を確認し、財務的な影響を数値化できます。 図 6: 各自動化イベントの詳細の取得 安全性を最優先に 運用上の信頼性を提供しリスクを最小限に抑えるため、この機能には安全メカニズムが組み込まれています。自動化システムは、アクションを実行する前にリソースの適格性を確認するチェックを行い、指定した条件に一致するボリュームのみを対象とします。また、Compute Optimizer で実行された自動化アクションを元に戻すこともできます。例えば、削除の前に自動的にスナップショットが作成されるため、データは完全に復元可能な状態が維持され、新しいボリュームとして復元できます。これらの多層的な安全対策が連携して機能することで、大規模な自動化に必要な運用上の信頼性を提供します。 アクションを元に戻す必要がある場合は、「自動化イベント (Automation events)」ページから実行できます。ボリュームの削除の場合、AWS Compute Optimizer は作成されたスナップショットからデータを新しい Amazon EBS ボリューム (新しいボリューム ID を持つ) に復元します。ボリュームタイプのアップグレードの場合、Compute Optimizer は新しいボリューム変更を開始して以前の設定にボリュームタイプを変更することで、アクションを元に戻します。 図 7: 必要に応じて変更をロールバックする 始めるためのヒント すでに Compute Optimizer をご利用の場合は、コンソールの新しい「自動化 (Automation)」セクションに移動し、アカウントの自動化機能を有効にしてください。オプトインすると、AWS が必要なサービスリンクロールを自動的に作成します。管理アカウントから組織を管理している場合は、メンバーアカウントもオプトインできます。これにより、複数のアカウントにまたがって適用される組織全体のルールを作成できます。Compute Optimizer を初めて使用する場合は、コンソールで数回クリックするか API からで サービスを有効 にできます。 最初の自動化ルールは小規模に始めて、戦略的に規模を拡大してください。まずは非本番環境を対象にして、自動化プロセスへの確信を深めていきましょう。特定のアカウントを選択するか、「Environment: Development」や「Environment: Test」などのリソースタグに基づいてフィルタリングすることで、開発環境やテスト環境でアタッチされていない Amazon EBS ボリュームのクリーンアップに焦点を当てたルールを作成してください。 自動化の動作に慣れ、期待される結果を確認できたら、ルールの対象をステージング環境に、そして最終的に本番環境のワークロードへと徐々に拡大してください。また、日次の自動化に移行する前に、まずは週次または月次のスケジュールから始めることもできます。このアプローチにより、条件を微調整しながら運用に関する確信を深めることができ、フリート全体に展開する際には、自動化ルールが十分にテストされ、組織のビジネス要件に沿った状態になります。 まとめ AWS Compute Optimizer の新しい自動化機能を最適化のツールボックスに加えることで、チームがお客様のためのイノベーションにより多くの時間を費やしながら、継続的なコスト削減とパフォーマンスの向上を追求できます。 開発環境のクリーンアップであれ、最新世代のテクノロジーの活用であれ、自動化ルールは最適化プロセスを効率化するためのスケーラビリティ、一貫性、運用上の安全性を提供します。非本番環境のワークロードから始めて、段階的な拡大を通じて確信を深め、戦略的に規模を拡大することで、AWS インフラストラクチャ全体で継続的なコスト削減とパフォーマンスの向上を実現できます。 AWS Compute Optimizer コンソールにアクセスし、新しい「自動化 (Automation)」セクションを確認して使用を開始してください。詳細については、 AWS Compute Optimizer ユーザーガイドのドキュメント をご参照ください。 Jimmy Yang Jimmy Yang はシニアプロダクトマネージャーで、お客様のクラウド投資を最大限に活用できるよう支援することに注力しています。コスト管理における課題についてお客様と対話し、それらを解決するための新しい製品体験を構築することを楽しみにしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

日々、企業は根本的な課題に直面しています。SAPシステムには、サプライヤーとの関係、在庫レベル、財務取引、生産計画など、企業運営を推進するビジネスクリティカルなデータが含まれています。しかし、ワークフロー自動化のためにこのデータにアクセスするには、従来、複雑なカスタム統合、専門的なSAP知識、そして多大な開発時間が必要でした。SAPデータと非SAPデータの両方に依存するビジネスプロセスは、従来、これらのソースを統合するために膨大な開発者の労力を必要としていました。サプライチェーンマネージャーを含む事業部門チームはリアルタイムの混乱分析を必要とし、財務チームは請求書の自動例外処理を望み、調達スペシャリストは即座のサプライヤーリスク評価を必要としています。それでも、これらのビジネスニーズを自動化に変えることは複雑なままでした — しかしそれは過去の話です。 Amazon Quick SuiteのAWS Action Connectors for SAP 2025年10月、AWSは Amazon Quick Suite を発表しました。これは、従業員がインサイトの発見、詳細な調査の実施、タスクの自動化、データの可視化、アプリケーション全体でのアクション実行の方法を変革するのを支援する新しいエージェント型チームメイトです。Quick Suiteは、SAP、ServiceNow、PagerDuty、Asanaなどの人気のあるサードパーティアプリケーションと統合し、データを取り込み、ユーザーがQuick Suiteインターフェース内でタスクを作成し、チケットを開き、アクションを実行できるようにします。 このブログでは、Quick Suite内で利用可能なSAP用の組み込みコネクタと、お客様が Amazon Quick Automate を使用してこれらのコネクタを活用し、ビジネスオペレーションを合理化する強力な自動化を構築する方法について説明します。Quick Automateは、企業が大規模で回復力のある自動化を構築、展開、維持できるようにするQuick Suiteの機能です。AWS Action Connectors for SAPは、お客様がライブSAPデータに対してリアルタイムの読み取り操作を実行できるようにし、Quick AutomateがSAP S/4HANAなどのSAP ERPシステムとシームレスに対話できるようにします。さらに、これらのコネクタは、SAP API、認証、データ交換の技術的な複雑さを自動的に処理します。Quick Automateは、構造化されたワークフロー定義とプロセス定義ドキュメントを通じて、複雑なSAP統合をビジネスユーザーがアクセスできるようにすることで、エンタープライズ自動化を変革しています。カスタム開発を数か月待つ代わりに、お客様は数時間でAI駆動のSAP自動化を構築できるようになりました。 このリリースには、一般的なエンタープライズ自動化シナリオに対応するSAP S/4HANA用の5つのコネクタが含まれています。各コネクタは、特定のAPIエンドポイントをアクションとして提供し、正確なデータ取得(読み取り専用)とワークフロー自動化を可能にします: Business Partner: ベンダー分析とお客様の人口統計評価のための包括的なビジネスパートナー、サプライヤー、お客様データにアクセスします。 Product Master: 包括的な在庫管理のための重要な資材データ、プラント情報、供給計画の詳細を取得します。 Bill of Materials: 製品の依存関係と製造要件を理解するために、資材構造とコンポーネントの関係を照会します。 Physical Inventory Documents: 正確な照合プロセスと包括的な監査証跡の維持のために、在庫ドキュメントの転記と在庫移動にアクセスします。 Material Stock: 正確な可用性追跡と在庫最適化のために、場所別のリアルタイム在庫レベルと在庫ポジションを取得します。 詳細なAPI仕様については、各サービスエンドポイントに対応するSAP APIドキュメントを参照できます。自動化を構成する際は、リストされたアクション名を使用して、自動化シナリオが必要とする特定のデータセットにアクセスしてください。 GenpactがAmazon Quick Automateを使用してお客様に代わってサプライチェーンリスク評価を自動化した方法 Genpactは、深い業界知識、プロセスインテリジェンス、ラストマイルの専門知識で認められたエージェント型および先進技術ソリューション企業です。深い業界専門知識とビジネスプロセスの洞察力を持つ同社は、AWSと提携し、Quick Automate上にAI駆動のサプライチェーンレジリエンスソリューションを構築し、エンタープライズリスク管理を変革しました。このソリューションのインテリジェントで自動化されたサプライチェーン監視機能を備えることで、組織は複数のSAPモジュール全体で数分で混乱の影響を評価できます—これは、手動分析に通常必要な2〜3日から劇的な改善です。外部リスク監視システムがサプライチェーンの混乱を検出すると、自動化されたワークフローは、Business Partner Master、Product Master、Bill of Materials、Inventory Managementシステム全体でデータ収集を即座に調整し、ビジネスへの影響の優先順位を計算し、代替調達や関係者への通知などの適切な対応アクションをトリガーします。この画期的なソリューションは、リアルタイムのクロスシステム調整により24時間体制のサプライチェーン保護を提供し、GenpactをAI駆動のビジネスプロセス変革のリーダーとして位置付けています。 Quick AutomateとSAPコネクタを使用すると、自動化された応答プロセスの概要を示す構造化されたワークフローを直感的なユーザーインターフェースを通じて作成できます: 図1: Genpactによって実装されたサプライチェーン混乱対応プロセス この種の自動化されたデータ駆動型アプローチは、企業が回復力を維持し、問題が発生したときにより迅速に対応するのに役立ち、棚に商品を並べ、お客様を満足させ続けます。 SAPアクションは、フィルタリング基準や選択パラメータなどの追加パラメータを指定することでカスタマイズできます。構造化されたプロセスドキュメントを通じて定義されたこの複雑なワークフローは、数分で自動的に実行され、プロアクティブなサプライチェーンリスク管理を可能にします。 AWS Connectors for SAPの使用開始 Quick AutomateでAWS Action Connectors for SAPの使用を開始するには: Amazon Quick Suiteにアクセス: AWS Connectors for SAPは現在、Amazon Quick Suite Integrationsを介してすべてのお客様が利用できます。 接続のセットアップ: Quick Suiteコンソールを通じてSAPシステムへの安全な接続をセットアップし、コネクタで実行する必要なアクションを構成します。 アクションの検出: 接続のセットアップが成功すると、この統合の一部として有効化されたアクションのセットが表示されます。 自動化グループの作成: 次に、Quick Automate Projectsに移動し、Manage groupsをクリックして自動化グループをセットアップし、作成した統合を「Actions」としてオンボードします。 自動化の定義: 次に、自動化プロジェクトを作成し、ビジネスプロセスの概要を示すワークフロー仕様に作成した自動化グループを追加し、適切なSAPコネクタを活用します。 テストと改善: 展開前に生成された自動化をレビュー、テスト、変更します。 展開と監視: 自動化を実行し、Studio経由でパフォーマンスを監視します。 AWS Action Connectors for SAPは、エンタープライズセキュリティ要件を念頭に置いて構築されています: 安全な認証: 現在利用可能な基本認証のサポートと、まもなく利用可能になるOAuthのサポート。 データプライバシー: SAP内で管理されるデータガバナンスと承認(ユーザーとロール)。 これらのコネクタのセットアップに関する詳細なガイダンスについては、 AWSドキュメント を参照してください。今日からAmazon Quick Suiteの使用を開始するには、 スタートガイドページ にアクセスしてください。 SAP on AWSディスカッションに参加 AWSアカウントチームとサポートチャネルに加えて、最近 re:Post を立ち上げました—AWSコミュニティのための再構築されたQ&A体験です。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できるディスカッションや質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。SAPワークロードをAWSに移行する方法の詳細については、 SAP on AWS ページをご覧ください。 謝辞 Amazon Quick Suiteを活用したSAPサプライチェーン向けエージェントAIソリューションを構築するためのAWSとGenpactの戦略的コラボレーションは、お客様がインテリジェントな自動化を通じてサプライチェーンオペレーションを最適化するのに役立ちます。この変革的なパートナーシップを築く上で基本となった専門知識、ビジョン、協力的な精神を持つGenpactリーダーシップ、AWS GenAIスペシャリスト、および拡張AWSサービスチームに感謝の意を表します。 Shriram Bidkar – Associate Vice President, AWS Solutions James Avellone – Director, Sourcing and Procurement Advisory Perryn Stewart – Vice President, Supply Chain Management Reagan Rosario – WWSO Specialist SA- GenAI, AWS Naresh Rajaram – Partner Solution Architect, AWS 著者について Rengarajan Sridharanは、AWS EC2 Commercial Applicationsのシニアテクニカルプログラムマネージャーで、SAPおよびVMwareワークロードに焦点を当てたプログラムを推進しています。エンタープライズリソースプランニング(ERP)ソリューションで20年以上の経験を持つRengaは、お客様がビジネス価値とデジタルトランスフォーメーションの成果を最大化するためにエンタープライズシステムをモダナイゼーションするのを支援することを専門としています。 Apoorva Chandraは、AWSのEC2 SAP Engineeringチームのシニアプロダクトマネージャー – テクニカルで、AWS上でワークロードを実行するSAPエンタープライズのお客様向けのモダナイゼーションとエコシステムイニシアチブをリードしています。彼女の焦点は、お客様がSAPランドスケープを強化するために生成AIと分析サービスの可能性を最大限に引き出すのを支援することです。 Shriram Bidkarは、Genpactのアシスタントバイスプレジデントで、戦略的能力と運用効率を向上させるサプライチェーン変革のためのAWS駆動のエージェントAIソリューションを専門としています。25年以上の経験を持つ彼は、Genpactのお客様に測定可能なビジネス成果をもたらすクラウド移行、モダナイゼーション、AI自動化イニシアチブを推進しています。 James Avelloneは、Genpactの調達およびプロキュアメントアドバイザリープラクティスのディレクターで、クライアントと協力して戦略的能力と運用効率を向上させるサプライチェーン変革を開発および実行しています。業界で15年以上の経験を持つJamesは、ターゲットオペレーティングモデルの設計、データ分析、テクノロジー実装の経験を持つ調達およびソーシングスペシャリストです。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

AWS SDK for SAP ABAP（以下「ABAP SDK」）は、SAP ABAPベースのソフトウェアおよびシステムとAWSサービスとの統合を容易にするために、 2023年半ばに初めてリリース されました。 他のAWS SDK と同様に、ABAP SDKは一連のモジュールとして提供され、開発プロジェクトにインポートすることで、標準化され、安全でスケーラブルな方法でAWSサービスAPIにアクセスできます。ほとんどのAWS SDKは、通常インポート後すぐに使用できます。しかし、SAP ABAP ベースのシステムでは、 SAPの変更および移送システム（CTS） を使用した、より詳細な セットアップ と 設定 プロセスが必要です。さらに、ABAP SDKは現在、400を超える個別の移送ファイルにまで成長しています。 そのため、SAP ABAP開発者およびSAP BASIS管理者がより迅速に作業を開始できるようにするため、本ブログでは、ABAP SDK用のグラフィカルインストーラー（以下「 ABAP SDKインストーラー 」）を紹介します。これは、 GitHub でスタンドアロンのABAPレポートとして本日より利用可能であり、簡単なデプロイのために、SAP開発およびテストシステムの新しいABAPレポートに単純にコピー＆ペーストできます。このレポートは、パッケージマネージャーのようなUIを提供し、ABAP SDKモジュールのインストール、更新、削除を簡単なポイント＆クリック操作で実行できるとともに、SAPシステムに現在インストールされているSDKの部分と利用可能な更新の包括的な概要を提供します。さらに、必要なSSL証明書のインストールやABAP SDK移送ファイルのダウンロードなどの付随タスクの自動化にも役立ちます。 前提条件: SAP RISEへのデプロイの場合 このレポートは、以下の前提条件の下で、SAP RISEシステムにもデプロイおよび実行できます: Gitベースのインストール（つまり、コピー/ペースト以外）の場合、SAP RISEシステムは github.com に接続できる必要があります ABAP SDKをダウンロードするには、SAP RISEから aws.amazon.com への接続が必要です 接続に必要なAmazon SSL証明書は、 amazontrust.com からダウンロード可能である必要があります オプション : SAP RISEシステムからのインターネットアクセスがプロキシ経由で行われる場合、SAP RISEシステムのICMを適切に設定し、上記のサイトをそれぞれのプロキシで許可リストに追加する必要があります。本記事執筆時点では、これらはSAP RISE環境に付属するプロキシの標準許可リストには含まれていません。 はじめに 初回起動時、 ABAP SDKインストーラー は、実行されているSAPシステムが、AWSサービスAPIとの通信に必要なすべてのAmazon SSLルート証明書をSAPトラストストア（トランザクション STRUST ）に保存しているかどうかを確認します。そうでない場合、レポートは Amazon Trust Services から不足している証明書を自動的にダウンロードして管理できます。その後、ユーザーには、SAPシステムに現在インストールされているすべてのABAP SDKモジュールの概要（「 Installed ABAP SDK Modules 」）と、ツリー状のフォルダービューで利用可能なすべてのモジュールのリストが表示されます。「 Available ABAP SDK Modules 」フォルダーには、 最も人気のあるモジュール をリストするサブフォルダーもあります。 最初のフォルダーには、ABAP SDKの機能における重要な役割を強調するために、 ABAP SDKコア モジュールのみが含まれています。ABAP SDKがまだSAPシステムに存在しない場合、コアトランスポートは、初期デプロイ用に選択された他のモジュールとともにインストールする必要があります。ユーザーは、モジュール名の横にあるチェックボックスをクリックし、 <Execute all> または <Execute All (batch)> のいずれかを押すことでこれを行うことができます。その後、レポートは、インストールおよびアンインストール用の最新のABAP SDK .zipアーカイブがSAPシステムのファイルシステムに存在するかどうかを確認します。存在しない場合は、自動的にダウンロードされ、その後アクセスされて、SAPのCTSツールでインポートするために必要なトランスポートファイルが抽出されます。完全に新しいインストール、つまりコアとさらに選択されたモジュールは、少し時間がかかる場合があることに注意してください（バッチモードを推奨）。 ABAP SDKモジュールの管理 起動時および <Refresh> ボタンを押した後、 ABAP SDKインストーラー レポートは、ABAP SDKダウンロードリポジトリでABAP SDKの最新バージョンを確認し、利用可能な場合は、インストールされているすべてのモジュールを更新用にマークします。ABAP SDKインストールの整合性を保つため、現在、異なるモジュールバージョンの混在は許可されていません。インストールされているすべてのモジュールは、現在インストールされているABAP SDKコアモジュールと同じバージョンである必要があります。信号機インジケーターの右側の列には、 <Execute all> または <Execute All (batch)> のいずれかを押した後、レポートがモジュールに対して何を行うかの自然言語による説明が表示されます。後者のオプションは、レポートを実行しているSAP GUIウィンドウへのアクセスをブロックせず、それぞれのモジュールに「Processing…」ステータスを表示することで進行中の操作を示します。 追加のモジュールのインストールは、 「Available modules」フォルダー でそれぞれのチェックボックスを選択することで実行できます。リストで目的のモジュールを見つけるのに問題がある場合は、 虫眼鏡/拡大鏡アイコン でラベル付けされた検索機能ボタン（設定されたSAP GUI（テーマ）によって異なります）が役立ちます。モジュールの3文字の頭字語（TLA）名の左側にあるそれぞれのチェックボックスを選択します。レポートは、すべてのモジュールをABAP SDKの最新バージョンにインストールおよび更新するオプション（ <Execute …> オプション）、または更新なしで選択したモジュールのみをインストールするオプション（ <Install only …> オプション）を提供します。後者の場合、ABAP SDKインストーラーは、システムにまだ存在しない場合、それぞれのABAP SDK .zipファイルバージョンをダウンロードします。 すべての目的のモジュールのチェックボックスが選択されたら、再度 <Execute all> / <Execute All (batch)> を押してインストールおよび更新するか、 <Install only> / <Install only (batch)> を押して更新なしでインストールのみを行い、レポートが自動的にダウンロードしてSAPシステムにインポートするようにします。システムに存在するすべてのモジュールは、「 Installed ABAP SDK modules 」フォルダーの下に表示されます。ABAP SDKの新しいバージョンが利用可能な場合、GUIはそれに応じて表示します。 モジュールの削除も同じ方法で機能します: モジュールのTLAの横にあるチェックボックスの選択を解除すると、削除用に設定され、赤い信号機サインと、右端の2つの列にモジュールが削除されることを示すメッセージでさらに示されます。 <Execute all> または <Execute All (batch)> を押すと、選択解除されたすべてのモジュールの削除トランスポートのインポートが開始され、SDKの新しいバージョンが利用可能な場合は、残りのすべてのモジュールが同時に更新されます。 <Delete only> / <Delete only (batch)> オプションは、更新なしで削除実行をトリガーします。システムに多数のモジュールが存在し、それらすべてを削除したい場合は、「 Delete/De-Select all installed modules 」ボタンを使用して迅速に実行でき、この段落で前述したボタンの選択肢のいずれかを押します。この決定を取り消すには、「 Update/Select all installed modules 」をクリックします。ABAP SDKコアモジュールは、他のすべてのモジュールが削除用に選択されているか、他のモジュールがシステムに存在しない場合にのみ削除できます。 レポートは、個々のモジュールをより詳しく調べることも容易にします。「フォワードナビゲーション」のような方法で モジュール名 、 利用可能なバージョン 、または トランスポートID（TID） をダブルクリックすると、そのモジュールの対応するAPIドキュメントページがブラウザで開きます。 インストール済みバージョン / TID に対して同じことを行うと、インポート中に記録されたそのモジュールのオブジェクトリストに移動します。 TP RC 、 最後のメッセージ 、または トランスポートステータスアイコン をダブルクリックしてフォワードナビゲーションすると、そのモジュールの最新のインポート実行のトランスポートログの概要に移動します。 バックグラウンド処理と追加のダウンロードボタン 特に、多数のモジュールがインストールされていて更新または削除用に設定されている場合、または一度に5つ以上のモジュールをインストールしたい場合は、 <… (batch)> とラベル付けされたボタンを使用してインポートを開始し、バッチモードで実行することをお勧めします。これにより、SAPシステムでバッチジョブが起動され、チェックボックスの編集をブロックすることで、モジュール選択へのさらなる入力が防止されます。バックグラウンドでレポート実行を開始すると、インストールおよび削除の現在のモジュール選択がSAPセッションの共有メモリ領域に書き込まれ、操作が完了するまでそこに保持されます。これにより、レポートは入力をまだブロックする必要があるかどうかを判断できます。 トランザクションSM37に移動し、レポートのような名前のインポートジョブを探すことで、レポートの進行状況を確認できます。ジョブは、完了時にサマリースプール出力も生成します。 <Refresh> ボタンを押すと、インポートジョブがまだ実行中かどうかをさらに調査し、その場合は視覚的なステータス表示を提供します。また、「 Background job details 」ボタンをクリックすることで、いつでもバックグラウンドジョブ番号を表示できます。更新時に、現在実行中の操作の中間結果が断続的に表示される場合があります。たとえば、他のモジュールがすでに削除されている間、モジュールがまだインストール済みとして表示されるなどです。 さらに、Amazon SSLルート証明書を更新する必要がある場合は、「 Install SSL Certificates 」ボタンを押すことで実行できます。最新のABAP SDK .zipファイルをシステムにダウンロードして準備しておきたい場合は、「 Download current SDK 」ボタンを押すことでも実行できます。 現在の制限事項 レポートは現在、実行されているSAPシステムがHTTP(S)を許可するインターネット接続を必要とし、真のオフライン体験を提供していません。SAPシステムは、SSL証明書をダウンロードするために Amazon Trust Servicesウェブサイト 、および ABAP SDKダウンロードページ と ABAP SDK APIドキュメント へのHTTPおよびHTTPS接続を確立できる必要があります。また、現在、手動でダウンロードしたABAP SDK .zipファイルへのパスを指定するオプションもありません。お客様がこれに対する需要がある場合、レポートの将来の改訂で対処できます。さらに、レポートを介してすべてのモジュールをインストールすることは技術的には可能ですが（たとえば、トレーニングシステムなどのエッジケース用）、すべてのチェックボックスをクリックするのは面倒になる可能性があります。このユースケースのために、AWSは現在、利用可能なすべてのモジュールのダウンロードと一括インストールを支援する コマンドラインbashスクリプト を提供しています。ただし、一般的には、特定のユースケースに必要なモジュールのみをインストールすることをお勧めします。これに加えて、 ABAP SDKインストーラー は、現時点では AWS SDK for SAP ABAP – BTP Edition をサポートしていません。最後に、レポートはABAP SDKのインストールの開始や最新の状態を保つのに役立ちますが、現在、自身を更新する手段がないため、最新のリリースを取得するために GitHubリポジトリ を時々確認することをお勧めします。 まとめと次のステップ AWS SDK for SAP ABAP は、お客様が使い慣れたプラットフォームから標準的で実証済みの方法でSAPシステムを強化および拡張する可能性を提供するために構築されました。このブログ投稿で紹介したABAP SDKインストーラーは、お客様がSAP ABAP ベースの開発システムで実験および評価できるように、ABAP SDKのデプロイを加速および簡素化するのに役立ちます。ぜひお試しください！ GitHubリポジトリ からレポートを入手し、興味のあるモジュールを探索してダウンロードし、たとえば、お客様がSAPシステムと Amazon Q や Amazon Bedrock などのAWS AIサービスを組み合わせることでどのように利益を得られるか、または イベント駆動型アーキテクチャ を実現する方法についての、他の複数の AWS for SAPブログ から始めてください。AWS SDK for SAP ABAPには、最も一般的なAWSサービスでABAP SDKを処理する方法を理解するために使用できる多数の コード例 もあります。最後に、AWSでは、お客様のABAP SDKのアイデア、質問、成功事例についてお聞きしたいと考えていますので、お気軽にお問い合わせください！AWSは、 re:Postサイト で公開ディスカッション、質問と回答のフォーラムを提供しています。 AWS for SAP ソリューションアーキテクチャチームは、ディスカッションや質問のためにAWS for SAPトピックを定期的に監視しています。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本記事は 2025年11月21日 に公開された「 Enhancing API security with Amazon API Gateway TLS security policies 」を翻訳したものです。 コンプライアンスフレームワークが進化し、暗号化標準が進歩するにつれて、組織はクラウドセキュリティ体制を改善するための追加の制御を求めています。必要な制御の1つは、より詳細な TLS 設定です。たとえば、規制要件で CBC のような古い暗号を無効にすることや、TLS 1.3 を最小バージョンとして強制することが義務付けられている場合などです。 この記事では、新しい Amazon API Gateway の強化された TLS セキュリティポリシーが PCI DSS 、 Open Banking 、 FIPS などの標準を満たすのにどのように役立つのかや、API が TLS ネゴシエーションを処理する方法を強化する仕組みについて学びます。この新機能は、運用の複雑さを増やすことなくセキュリティ体制を向上させ、API Gateway インフラストラクチャ全体で TLS 設定を標準化する単一の一貫した方法を提供します。 概要 以前、API Gateway は TLS 設定に対する制御が限定的で、カスタムドメイン名に対してのみ提供されていました。デフォルトエンドポイントは固定のセキュリティポリシーを使用していたため、組織のセキュリティやコンプライアンス要件を満たすために、カスタム Amazon CloudFront ディストリビューションなどの追加インフラストラクチャを導入する必要がありました。 今回のリリースにより、すべての REST API エンドポイントタイプ （リージョナル、エッジ最適化、プライベートを含む）で TLS 動作を直接設定し、API とそのカスタムドメイン名の両方に一貫した TLS 設定を適用できます。ワークロードが必要とする最小 TLS バージョンと暗号スイートを強制するために、事前定義された強化セキュリティポリシーから選択できます。たとえば、TLS 1.3 を強制したり、CBC 暗号なしで強化された TLS 1.2 を使用したり、政府ワークロード向けに FIPS に準拠したスイートを採用したり、 ポスト量子暗号 （PQC）を含むポリシーで将来に備えたりできます。新しいセキュリティポリシーは、運用の複雑さを増やすことなく、より細かい制御を提供し、進化するセキュリティとコンプライアンスの期待に API を適合させるのに役立ちます。 API Gateway セキュリティポリシーの理解 API Gateway のセキュリティポリシーは、最小 TLS バージョンと厳選された暗号スイートのセットの事前定義された組み合わせです。クライアントが REST API またはカスタムドメイン名に接続すると、API Gateway は選択されたポリシーを使用して、TLS ハンドシェイク中に受け入れるプロトコルバージョンと暗号を決定します。これにより、クライアントが API への暗号化接続を確立する方法を予測可能かつ強制可能な方法で制御できます。 API Gateway は 2 つのカテゴリのセキュリティポリシーをサポートしています。 TLS_1_0 や TLS_1_2 などのレガシーポリシーは、下位互換性のために引き続き利用可能です。 SecurityPolicy_* プレフィックスで識別される強化ポリシーは、規制されたワークロード、高度なガバナンス、または暗号化の強化に対して、より厳格で最新の制御を提供します。強化ポリシーを使用する場合は、エンドポイントアクセスモードも指定する必要があります。これにより、トラフィックが API に到達する方法に対する追加の検証が追加されます。詳細は以下のセクションで説明します。 強化ポリシーは、各ポリシーが何を強制するかを素早く理解するのに役立つ一貫した命名パターンに従っています。たとえば、REGIONAL および PRIVATE エンドポイントタイプの場合、次のパターンが適用されます： SecurityPolicy_[TLS-Versions]_[Variant]_[YYYY-MM] この構造から、サポートされる最小 TLS バージョン、特殊な暗号化バリアント（FIPS、PFS、PQ など）、およびポリシーのリリース日を識別できます。たとえば、 SecurityPolicy_TLS13_1_3_2025_09 は TLS 1.3 トラフィックのみを受け入れ、 SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09 は TLS 1.2 を最低、TLS 1.3 を最高 TLS バージョンとして、前方秘匿性とポスト量子拡張をサポートします。 各ポリシーは、厳選された暗号の組み合わせにマッピングされます。たとえば、 SecurityPolicy_TLS13_1_3_2025_09 は、3 つの TLS 1.3 暗号スイート（ TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384 、および TLS_CHACHA20_POLY1305_SHA256 ）のみを受け入れ、他のプロトコルバージョンや暗号を拒否します。サポートされているポリシーと暗号の完全なリスト、および EDGE エンドポイントタイプの命名パターンについては、 API Gateway ドキュメント をご参照ください。 セキュリティポリシーをデフォルトエンドポイントとカスタムドメインに適用する方法 API Gateway を使用して、デフォルト API エンドポイントとカスタムドメイン名に異なるセキュリティポリシーを適用できます。TLS ネゴシエーション中、API Gateway は、HTTP Host ヘッダーではなく、クライアントの TLS ハンドシェイクの Server Name Indication（SNI）値に基づいてポリシーを選択します。つまり、ポリシーは、クライアントが TLS を開始するときに使用するホスト名に依存します。 たとえば、クライアントがデフォルトエンドポイントに直接接続する場合： https://abcdef1234.execute-api.us-east-1.amazonaws.com SNI 値がそのホスト名と一致するため、API Gateway はそのデフォルトエンドポイントに適用されたポリシーを使用します。 クライアントが代わりにカスタムドメイン名を介して接続する場合： https://api.example.com API Gateway はそのカスタムドメインに適用されたポリシーを使用します。この場合、SNI 値 api.example.com がどのポリシーが強制されるかを決定します。 この区別は、デフォルトエンドポイントを無効にした場合でも重要です。TLS ネゴシエーションは常に API Gateway がエンドポイント設定を評価する前に発生するため、デフォルトエンドポイントセキュリティポリシーは、そのホスト名に直接接続するクライアントに引き続き適用されます。予期しないクライアント動作を避けるために、可能な限り API とそのカスタムドメイン名を同じセキュリティポリシーで整合させる必要があります。 エンドポイントアクセスモードの理解 強化セキュリティポリシー（ SecurityPolicy_* ）を使用する場合、エンドポイントアクセスモードも指定する必要があります。エンドポイントアクセスモードは、リクエストが API に到達する前に、API Gateway がネットワークパスをどの程度厳密に検証するかを定義します。これにより、追加のガバナンス層が提供され、不正または誤ってルーティングされたトラフィックを防ぐのに役立ちます。 2 つのモードから選択できます： BASIC モードは、標準的な API Gateway の動作を提供します。既存の API を強化セキュリティポリシーに移行する際の推奨される開始点です。クライアントは、追加の検証なしで、現在と同じように API に到達し続けることができます。 STRICT モードは、リクエストが正しいエンドポイントタイプから発信され、TLS ネゴシエーションが設定と整合していることを確認するための強制チェックを追加します。 STRICT モードを有効にすると、API Gateway は次のような追加の検証を実行します： SNI と HTTP Host ヘッダー値が一致する リクエストが API と同じエンドポイントタイプ（リージョナル、エッジ最適化、またはプライベート）から発信される これらの検証のいずれかが失敗すると、API Gateway はリクエストを拒否します。 STRICT は、規制されたワークロードや機密性の高いワークロードを実行する場合など、より強力なセキュリティ保証が必要な場合に適した選択肢です。詳細については、 API Gateway ドキュメント をご参照ください。 BASIC から STRICT モードに切り替えると、変更が完全に伝播するまでに最大 15 分かかります。この期間中、API は引き続き利用可能です。エンドポイントアクセスモードが STRICT に設定されている場合、モードを BASIC に戻すまでエンドポイントタイプを変更できません。 新規および既存の API へのセキュリティポリシーの適用 新しい REST API またはカスタムドメイン名を作成するときにセキュリティポリシーを適用することも、既存のリソースを更新して強化された SecurityPolicy_* オプションのいずれかを使用することもできます。既存の API を移行する場合、推奨されるアプローチは、BASIC モードから開始し、クライアントの動作（SNI と HTTP Host ヘッダー値が一致し、リクエストが API と同じエンドポイントタイプから発信される）を検証してから、互換性を確認した後に STRICT モードに移行することです。 以下のコードスニペットは、さまざまなシナリオにセキュリティポリシーを適用する方法を示しています： セキュリティポリシーと STRICT エンドポイントアクセスモードで REST API を作成する API 作成時にセキュリティポリシーを直接適用でき、TLS ネゴシエーションを制御するためだけに追加のインフラストラクチャを必要としません。 aws apigateway create-rest-api \ --name "your-private-api-name" \ --endpoint-configuration '{"types":["PRIVATE"]}' \ --security-policy "SecurityPolicy_TLS13_1_3_2025_09" \ --endpoint-access-mode STRICT \ --policy file://api-policy.json セキュリティポリシーと STRICT エンドポイントアクセスモードでカスタムドメイン名を作成する カスタムドメイン名を作成するときにもセキュリティポリシーを指定できます。API Gateway は、クライアントが提供する SNI 値に基づいて、TLS ネゴシエーション中に選択されたポリシーを適用します。 aws apigateway create-domain-name \ --domain-name api.example.com \ --regional-certificate-arn arn:aws:acm:region:account-id:certificate/certificate-id \ --endpoint-configuration '{"types":["REGIONAL"]}' \ --security-policy SecurityPolicy_TLS13_1_3_2025_09 \ --endpoint-access-mode STRICT 既存の REST API の更新 既存の API を移行する場合は、まず BASIC モードで強化セキュリティポリシーを適用します。クライアントが BASIC モードで期待どおりに接続できることを確認した後、STRICT モードを有効にします。 1. BASIC モードで新しいポリシーを適用する aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/securityPolicy", "value": "SecurityPolicy_TLS13_1_3_2025_09" }, { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' アクセスログ と Amazon CloudWatch の パフォーマンスメトリクス を使用して、クライアントが期待どおりに API を利用できることを確認します。 2. 検証後に STRICT モードを有効にする aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "STRICT" } ]' 既存のカスタムドメイン名の更新 カスタムドメイン名は、REST API と同じ移行アプローチに従います。 1. BASIC モードで新しいポリシーを適用し、クライアントが正常に接続できることを検証します。 aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[ { "op": "replace", "path": "/securityPolicy", "value": "SecurityPolicy_TLS13_1_3_2025_09" }, { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' 2. 検証後に STRICT モードを有効にする aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "STRICT" } ]' REST API またはカスタムドメイン設定を更新した後、ステージが新しい設定を受け取るように API を再デプロイします。セキュリティポリシーを変更すると、更新が完了するまでに最大 15 分かかります。変更が伝播している間、API ステータスは UPDATING と表示され、完了すると AVAILABLE に戻ります。このプロセス全体を通じて、API は完全に機能し続けます。 エンドポイントアクセスモードのロールバック STRICT モードを適用した後にクライアントが API への接続に失敗する場合は、いつでもエンドポイントアクセスモードを BASIC に戻すことができます。以下のコードスニペットは、REST API に対してこれを行う方法を示しています。 aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' 同じアプローチを使用してカスタムドメイン名を更新できます。 TLS 使用状況とポリシー移行の監視 強化セキュリティポリシーを採用する際、クライアントが API との暗号化接続をどのようにネゴシエートするかを理解することが重要です。監視は、クライアントの準備状況を確認し、更新が必要なレガシーコンシューマーを特定し、ロールアウト中に STRICT エンドポイントアクセスモードが期待どおりに動作することを検証するのに役立ちます。プロトコルと暗号の使用状況を経時的に監視するには、次の API Gateway アクセスログ変数 を使用します。 $context.tlsVersion – ネゴシエートされた TLS バージョン $context.cipherSuite – ハンドシェイク中に選択された暗号スイート これらの変数を使用して、次のことを確認できます： クライアントが期待される最小 TLS バージョンを使用している 強化ポリシーに移行した後、CBC ベースの暗号が使用されなくなった PQC および FIPS に準拠したポリシーが適切なクライアントによって使用されている アクセスログは、移行中に特に有用です。実際のクライアント動作を検証することは、STRICT モードを有効にする前の前提条件です。たとえば、BASIC モードで強化ポリシーを適用した後も、TLS 1.0 または TLS 1.2 CBC 暗号をネゴシエートしているライブクライアントが観察される場合、影響を受けるクライアントを特定し、STRICT モードに切り替える前に修復を計画できます。 将来を見据えたセキュリティ設定 新しいポリシーの一部は、TLS 1.3 とポスト量子暗号（PQC）を組み合わせて、量子対応の脅威アクターが存在する将来に備えるのに役立ちます。これらのポリシーを使用すると、API アーキテクチャを再設計することなく、量子耐性アルゴリズムのテストと採用を開始できます。 標準が進化し、新しい暗号スイートが導入されるにつれて、API Gateway のポリシーモデルは、設定をシンプルで予測可能に保ちながら、新しいバリアントを追加するための明確なパスを提供します。 まとめと次のステップ Amazon API Gateway の強化された TLS セキュリティポリシーとエンドポイントアクセスモードにより、クライアントが API への安全な接続を確立する方法を直接制御できます。PCI DSS、FIPS、Open Banking、PQC などのコンプライアンスニーズに合ったポリシーを選択し、STRICT モードを使用してトラフィックがエンドポイントに到達する方法を制御し、追加のドメインレベルの検証を適用して、API のセキュリティをさらに強化できます。 開始するには： API Gateway ドキュメント で利用可能なセキュリティポリシーのリストを確認します。 より強力な TLS 制御が必要な REST API とドメインを特定します。 BASIC モードで適切な SecurityPolicy-* ポリシーを適用します。 アクセスログと CloudWatch メトリクスを使用してクライアントの動作を検証します。 追加の接続レベルの保護を強制する準備ができたら、STRICT モードに移行します。 サーバーレスアーキテクチャの構築に関する詳細については、 ServerlessLand.com をご参照ください。 翻訳はソリューションアーキテクトの松本が担当しました。

本記事は 2025年11月21日 に公開された「 Build scalable REST APIs using Amazon API Gateway private integration with Application Load Balancer 」を翻訳したものです。 この記事は、プリンシパルソリューションアーキテクトの Vijay Menon とシニアソリューションアーキテクトの Christian Silva によって執筆されました。 本日、 Amazon API Gateway REST API が Application Load Balancer (ALB) とのプライベート統合をサポートすることを発表しました。この新機能により、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API 経由で安全に公開できます。 今回のリリース以前は、API Gateway をプライベート ALB に接続する場合、 Network Load Balancer (NLB) を中間に配置する必要があり、コストと複雑さが増していました。現在は、NLB を必要とせずに API Gateway をプライベート ALB と直接統合できるため、運用オーバーヘッドが削減され、コストが最適化されます。 従来のアーキテクチャ: API Gateway とプライベート ALB の接続 今回のリリース以前は、API Gateway REST API は ALB の前に配置された NLB を経由してプライベート ALB リソースに接続していました。多くのお客様がこのアーキテクチャを使用して本番ワークロードを構築・運用しており、ビジネスクリティカルなアプリケーションに対する信頼性が実証されています。次の図は、このセットアップを示しています。 図 1. 従来のアーキテクチャ: 中間 NLB 経由での API Gateway からプライベート ALB への接続 アーキテクチャの簡素化とコスト削減を求めるお客様のフィードバックに応えて、VPC Link v2 のサポートを REST API に拡張しました。この機能により、REST API でプライベート ALB との直接統合が可能になり、中間 NLB が不要になりました。 新しいアーキテクチャ: API Gateway とプライベート ALB の接続 プライベート ALB との直接統合により、アーキテクチャはよりシンプルで効率的になります。この統合により中間 NLB が不要になり、クライアントとサービス間のホップ数が削減されます。この合理化されたセットアップにより、アプリケーションのアーキテクチャが簡素化され、ALB のレイヤー 7 ロードバランシング機能、認証、認可機能をより効率的に使用できます。これらの ALB 機能は技術的には以前からアクセス可能でしたが、新しいアーキテクチャでは追加の NLB を管理するオーバーヘッドと複雑さが解消されます。簡素化されたアーキテクチャは次のようになります。 図 2. API Gateway とプライベート ALB 間の直接統合 API Gateway エンドポイントとプライベート ALB の直接統合のメリット アーキテクチャの簡素化と運用の優秀性 : API Gateway がプライベート ALB に直接接続できるようになったため、API Gateway とプライベート ALB の間のブリッジとして機能する NLB が不要になりました。これにより、中間ロードバランサーのプロビジョニング、設定、管理、監視が不要になります。インフラストラクチャコンポーネントの削減は、運用オーバーヘッドの削減と潜在的な障害ポイントの減少につながります。トラフィックは Amazon Web Services (AWS) ネットワーク内で API Gateway から ALB に直接流れるため、ネットワークホップとレイテンシーが削減されます。 スケーラビリティの向上 : VPC Link v2 は、ロードバランサーとの 1 対多の関係をサポートします。単一の VPC Link v2 により、API Gateway は VPC 内の複数の ALB または NLB と統合できます。このアーキテクチャ上の利点は、それぞれが独自の ALB の背後にある可能性がある複数のマイクロサービスを持つ複雑なアプリケーションを管理する組織や、多数の API を実行している組織にとって特に価値があります。単一の VPC Link を通じて複数のロードバランサー接続を統合する機能は、管理オーバーヘッドを削減するだけでなく、アーキテクチャのスケーリングにおいてより大きな柔軟性を提供します。アプリケーションが成長し、より多くのサービスやロードバランサーを追加する際に、追加の VPC Link をプロビジョニングする必要がないため、運用効率を維持しながらインフラストラクチャを拡張しやすくなります。 コストの最適化 : アーキテクチャから NLB を削除することで、NLB の実行に対する時間料金と、1 時間あたりに使用される Network Load Balancer Capacity Units (NLCU) の両方を削減できます。複数の環境や多数の API を実行している組織では、これらの削減により年間数千ドルの節約が可能になります。さらに、データ転送パターンがより効率的になります。トラフィックは AWS ネットワーク内で API Gateway から ALB に直接流れるため、より多くのデータ転送料金が発生する可能性のある不要なホップを回避できます。この合理化されたパスは、コストを削減するだけでなく、ネットワークレイテンシーを最小限に抑えることでパフォーマンスも向上させます。 はじめる このチュートリアルでは、 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) の両方を使用したセットアップを実演します。開始する前に、VPC に 内部 ALB が設定されている ことを確認してください。名前が必要なリソースについては、環境に適した名前を使用してください。 ステップ 1: VPC Link v2 の作成 最初のステップは、API Gateway が内部 ALB にトラフィックをルーティングできるようにする VPC Link v2 を作成することです。設定方法は次のとおりです。 API Gateway コンソール に移動します。 左側のナビゲーションペインで、 VPC links を選択します。 Create VPC link を選択します。 VPC Link タイプとして VPC link v2 を選択します。 VPC Link のわかりやすい名前を入力します。 ALB が存在する VPC とサブネットを選択します。高可用性を実現するには、ALB 設定に一致する複数の AWS アベイラビリティーゾーン (AZ) のサブネットを選択します。 VPC Link に 1 つ以上のセキュリティグループを割り当てます。これらのセキュリティグループは、API Gateway と VPC 間のトラフィックフローを制御します。 Create を選択し、VPC Link のステータスが Available になるまで待ちます。このプロセスには数分かかる場合があります。 または、AWS CLI を使用して VPC Link v2 を作成できます。 # VPC Link v2 の作成 aws apigatewayv2 create-vpc-link \ --name "test-vpc-link-v2" \ --subnet-ids "<your-subnet1-id>" "<your-subnet2-id>" \ --security-group-ids "<your-security-group-id>" \ --region <your-AWS-region> # VPC Link v2 のステータス確認 aws apigatewayv2 get-vpc-link \ --vpc-link-id "<your-vpc-link-v2-id>" \ --region <your-AWS-region> ステップ 2: REST API の作成と統合の設定 VPC Link v2 が利用可能になったら、次のステップは REST API を作成し、VPC Link を使用するように設定することです。このプロセスには、API の作成、リソースとメソッドの設定、内部 ALB との統合の設定が含まれます。 API Gateway コンソール で、 Create API を選択します。 REST API を選択します。 API 名を入力し、 Create API を選択します。 Actions を選択してから Create resource を選択して、新しいリソースを作成します。このリソースは、API のエンドポイントを表します。 Actions を選択してから Create method を選択して、メソッドを作成します。メソッドは、API が受け入れるリクエストのタイプ (GET、POST など) を定義します。 次に、統合を設定します。ここで、VPC Link v2 を介して API を内部 ALB に接続します。 統合タイプとして VPC link を選択します。 バックエンド統合の HTTP メソッドを選択します。 新しく作成した VPC Link v2 を選択します。 統合ターゲットとして ALB を指定します。 統合のエンドポイント URL を入力します。URL で指定されたポートは、バックエンドへのリクエストのルーティングに使用されます。 Integration timeout を設定します。 AWS CLI を使用する場合: # REST API の作成 aws apigateway create-rest-api \ --name "test-rest-api" \ --description "REST API integration with internal ALB via VPC link v2" \ --region <your-AWS-region> # REST API のルートリソース ID を取得 aws apigateway get-resources \ --rest-api-id "<your-rest-api-id>" \ --region <your-AWS-region> # 新しいリソースの作成 aws apigateway create-resource \ --rest-api-id "<your-rest-api-id>" \ --parent-id "<your-parent-id>" \ --path-part "internal-alb" \ --region <your-AWS-region> # 新しいメソッドの作成 aws apigateway put-method \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<your-resource-id>" \ --http-method ANY \ --authorization-type NONE \ --region <your-AWS-region> # 統合の作成 aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<your-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "http://test-internal-alb.com/test" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-ALB-arn>" \ --region <your-AWS-region> ステップ 3: デプロイとテスト API が設定されたら、デプロイして正しく動作していることを確認します。 Deploy API を選択して、API の新しいデプロイを作成します。 新しいステージ (例: “test”) を作成します。ステージを使用すると、API の複数のバージョンを管理できます。 デプロイ後、API エンドポイント URL が表示されます。テストに必要なため、この URL をコピーします。 お好みの API クライアントまたはシンプルな curl コマンドを使用して API をテストします。 AWS CLI を使用する場合: # test ステージへの新しいデプロイの作成 aws apigateway create-deployment \ --rest-api-id "<your-rest-api-id>" \ --stage-name "test" \ --region <your-AWS-region> curl コマンドを使用して API 統合をテストします。 curl https://<rest-api-id>.execute-api.<your-aws-region>.amazonaws.com/internal-alb {"message": "Hello from internal ALB"} ステップ 4: VPC Link v2 のスケーリング 単一の VPC Link で、VPC 内の複数の ALB または NLB に接続できるようになり、インフラストラクチャ管理が簡素化されます。この AWS CLI スニペットは、API Gateway が単一の VPC Link v2 を使用して、それぞれが独自の ALB の背後にある複数の内部サービス (例: 注文サービスと支払いサービス) と統合する方法を示しています。両方の統合で同じ VPC Link ID が使用されていることに注目してください。 # 注文サービスの統合 (ALB-1) aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<orders-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "<your-orders-alb-endpoint>" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-orders-alb-arn>" \ --region "<your-aws-region>" # 支払いサービスの統合 (ALB-2) aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<payments-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "<your-payments-alb-endpoint>" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-payments-alb-arn>" \ --region "<your-aws-region>" 詳細なステップバイステップガイドについては、 API Gateway 開発者ガイド の公式ドキュメントをご覧ください。 ユースケース API Gateway とのプライベート ALB 統合により、エンタープライズの課題を解決するアーキテクチャパターンが可能になります。この新機能を活用できる 3 つの主要なシナリオを以下に示します。 Amazon ECS および Amazon EKS 上のマイクロサービス : Amazon ECS または Amazon EKS で実行されているマイクロサービスの公開が、この統合によりシンプルになります。ALB をパブリックインターネットに公開したり、複雑な NLB プロキシパターンを使用したりすることなく、さまざまなサービスへの安全なパスベースのルーティングが可能になります。 ハイブリッドクラウドアーキテクチャ : AWS Direct Connect または AWS Site-to-Site VPN を介して、クラウドネイティブ API とオンプレミスリソース間のシームレスで安全な接続が実現されます。このセットアップにより、HTTP メソッドとヘッダーに基づいて、さまざまな内部システムへの柔軟なルーティングが可能になります。 エンタープライズのモダナイゼーション : モノリシックアーキテクチャからマイクロサービスへの段階的な移行を可能にすることで、アプリケーションの段階的なモダナイゼーションが促進されます。組織は、運用の継続性を維持し、リスクを最小限に抑えながら、レガシーコンポーネントと新しいコンポーネント間でトラフィックをルーティングできます。 まとめ API Gateway REST API と ALB 間の直接プライベート統合により、AWS での API アーキテクチャが強化されます。インフラストラクチャを簡素化し、運用オーバーヘッドを削減することで、この機能は API 駆動型アプリケーションのパフォーマンスと効率を向上させます。 この機能は、VPC Link v2 と ALB が利用可能なすべての AWS リージョンで本日より利用できます。この機能で何を構築し、API アーキテクチャがどのように変革されるかを楽しみにしています。API Gateway コンソールにアクセスして、ALB との直接統合のための最初の VPC Link v2 を作成することで、今すぐ始めることができます。 詳細については、 API Gateway 製品ページ をご覧いただき、 料金の詳細 を確認し、包括的な 開発者ドキュメント を参照して、AWS で世界クラスの API を構築するために利用できるすべての強力な機能について学んでください。

この記事は Build Secure Data Mesh with AWS and Partner Solutions を翻訳した記事になります。翻訳は Solutions Architect 深見が担当しました。 はじめに データメッシュは、組織がドメイン間でデータを管理・共有する方法に革命をもたらす変革的なアーキテクチャパラダイムとして登場しています。 データを製品として扱い、ドメインチームに所有権を分散させることで、データメッシュはドメインの自律性を維持しながら、スケーラブルで安全かつ効率的なデータ共有を可能にします。 このブログは、最新のデータメッシュアーキテクチャを実装中または計画中のデータアーキテクトや技術リーダー向けです。 主に AWS とそのパートナーと協力している世界的な金融サービス組織による革新的な実装から着想を得ていますが、ここで議論される原則とソリューションは業界全体に広く適用できます。 金融機関は、ドメイン固有のガバナンスを維持しながら多様な製品にわたる包括的な顧客ビューを作成するために、データメッシュアーキテクチャの採用を増やしています。 これらの組織は、データが伝統的にサイロ化されていた規制環境において独自の課題に直面しています。 今日のソリューションは、 Apache Iceberg のようなオープンテーブルフォーマット、エンジン間のストレージとコンピュートの分離、クラウドスケールの機能を活用しており、従来のクエリフェデレーションアプローチからの進化を表しています。 最新のデータメッシュアプローチは、エンティティ認証、一貫したアクセス制御、包括的な監査証跡、データ系統追跡を通じて厳格な管理を維持しながら、ストレージレベルでの安全なデータ共有を可能にします。 これにより、チームはセキュリティやコンプライアンス要件を損なうことなく、特定のニーズに最適な専門エンジンを選択できます。 このブログでは、AWS ネイティブの分析サービスとサードパーティエンジンを同時に活用することを目的としたデータメッシュアーキテクチャを実装するための 3 つの重要な要件を探ります：(1)クロスカタログメタデータフェデレーション、(2)クロスアカウント＆クロスエンジンでの認証と認可、(3)分散ポリシーの反映 AWS をデータプロデューサーとコンシューマーの両方として実用的な実装パターンを検討し、Databricks や Snowflake などのパートナーとの統合アプローチを代表例として紹介します。 これらのパターンは、組織が企業全体のガバナンスを維持しながら、データメッシュの中核原則をサポートする柔軟で安全かつスケーラブルなデータアーキテクチャをどのように構築するかを示しています。 主な要素 データメッシュ データメッシュは、中央集権型のデータプラットフォームから分散型のドメイン指向の所有モデルへと移行するアーキテクチャおよび組織的なデータ管理アプローチです。 データを製品として扱い、ドメインチームが生成するデータに責任を持たせます。 例えば、金融機関では、クレジットカード部門が顧客取引データを製品として所有・管理し、明確に定義されたインターフェースとアクセス制御を通じて、不正検出やマーケティング分析などの他部門が安全にアクセスできるようにします。 データメッシュの中核原則には、(1)ドメイン指向の所有権、(2)製品としてのデータ、(3)セルフサービスデータインフラストラクチャ、(4)連合型ガバナンスが含まれます。 詳細については、 データメッシュとは および Let’s Architect! Architecting a data mesh をご覧ください。 データメッシュでは、データプロデューサーがデータコンシューマーが消費できるようにデータを公開します。 フェデレーテッドガバナンス層 (Federated Governance) がデータへのアクセスを規制します。 コンシューマーとプロデューサーは、AWS ネイティブサービスと AWS パートナープラットフォーム間でデータを共有する必要があります。 図1. Databricks や Snowflake などの AWS ネイティブサービスと AWS パートナーによるデータメッシュ設計のコンセプトを示しています。AWS と AWS パートナーの両方がデータコンシューマーとデータプロデューサーの役割を果たしています。 Iceberg オープンテーブルフォーマット Apache Iceberg は、データメッシュアーキテクチャにとって重要なオープンテーブルフォーマットです。 その主な理由は、異なるデータメッシュ環境に不可欠な Amazon Athena 、Snowflake、Databricks などの多様なクエリエンジン間で一貫したデータアクセスを可能にするクロスプラットフォーム互換性にあります。 また、コンシューマーに影響を与えることなくスキーマ進化をサポートし、ガバナンスと監査のためのタイムトラベル機能を提供し、 ACID トランザクション によるデータ一貫性を維持、プラットフォーム間でのきめ細やかなアクセス制御を可能にします。 これらの機能により、データの整合性とガバナンスを維持しながらドメイン間の相互運用性を確保できます。 Lake Formation AWS Lake Formation は、分析と機械学習のためのデータを一元的に管理、保護、共有するのに役立ちます。 Amazon Simple Storage Service (Amazon S3) や Amazon Redshift などの様々なデータストアに保存されたデータと AWS Glue Data Catalog 内のメタデータに対するきめ細やかなアクセス制御を提供します。 次世代の Amazon SageMaker Amazon SageMaker のレイクハウスアーキテクチャは、Apache Iceberg を使用してデータレイクとウェアハウスを 1 つのオープンプラットフォームに統合します。 このレイクハウスは、複数のソースからのデータへの接続、カタログ化、権限管理をスムーズに行います。 AWS Glue Data Catalog と AWS Lake Formation を基盤として構築され、オープンな Apache Iceberg REST API を通じてアクセス可能なカタログを通じてデータを整理し、一貫したきめ細やかなアクセス制御による安全なデータアクセスを提供します。 Amazon SageMaker Unified Studio は、Amazon レイクハウスアーキテクチャの開発環境とオーケストレーション層として機能します。 レイクハウスが Apache Iceberg ベースのデータ基盤を提供する場所であるのに対して、SageMaker Unified Studio は、データサイエンティスト、アナリスト、開発者が AWS サービスと外部パートナープラットフォームの両方のデータをやり取りし操作する場所です。 詳細については、 Connect, share, and query where your data sits using Amazon SageMaker Unified Studio ブログを参照してください。 アイデンティティとアクセス制御の管理 金融サービス組織はサイロ化されたデータから、オープンテーブルフォーマット、ストレージとコンピュートの分離、クラウド機能によって可能になったデータメッシュアーキテクチャへと進化してきました。 この変化により、エンティティ認証、一貫したクロスエンジンアクセス制御、包括的な監査、コンプライアンスモニタリング、データ系統追跡を通じて厳格な管理を維持しながら、クエリフェデレーションではなくストレージレベルでの安全なデータ共有が可能になりました。 このアプローチにより、チームは組織のセキュリティとコンプライアンス要件を維持しながら、ケースに適したエンジンを選択できるようになります。 クロスエンジンデータ共有のためのデータメッシュアーキテクチャが進化するにつれて、2 つの重要なセキュリティ要件が浮上します： プラットフォーム間で一貫したエンティティ ID プラットフォーム間で統一されたアクセス制御 ユーザーとエンジンのアイデンティティ マルチクエリエンジン環境では、ユーザーとエンジンの両方の ID が不可欠です。 ユーザーはサービス間で一貫した ID（フェデレーション ID プロバイダー、IDP サーバーを通じて管理）が必要である一方、エンジンはユーザーに代わってフェデレーションデータソースに接続する際にシステム ID を必要とします。 エンジンは、シームレスなクロスエンジン操作を可能にしながらセキュリティを維持するために、互いに信頼関係を確立する必要があります。 アクセス制御 ID の確認後、アクセス制御には 2 つの重要な側面が関わります：ポリシー定義（AWS および非 AWS エンジン間で許可されるアクションの指定）とポリシーの反映（定期的な同期を伴うエンジンレベルでの実装）です。 このアプローチにより、データが AWS またはパートナーエンジンのどちらを通じてアクセスされるかに関わらず、一貫したセキュリティが維持されます。 マルチエンジンデータメッシュは、2 つの補完的なアクセス制御モデルを活用します： IAM/S3 ポリシーを使用した粗い粒度のアクセス (Coarse-grained access ) Lake Formation を使用したきめ細やかなアクセス制御（Fine-grained access control: FGAC） Lake Formation は、データフィルターを持つ名前付きリソースを使用したロールベースのアクセス制御を含む、きめ細やかなアクセス制御での権限管理を行うための様々な権限モデルをサポートしています： タグベースのアクセス制御（TBAC） ：LF-Tags は、類似したリソースをグループ化し、そのリソースグループに対する権限をプリンシパルに付与できるメカニズムで、権限のスケーリングを可能にします。 属性ベースのアクセス制御（ABAC） ：ユーザー属性に基づいてリソースに対する権限を付与できるようになり、コンテキスト駆動型で、特定の属性値に基づく行レベルのフィルタリングなどの精密なセキュリティ対策が可能になります。 実装の成功のためには、ユーザーがデータメッシュとやり取りするためにどのアクセスポイントを使用するかに関わらず、一貫したセキュリティ実施を維持するために、エンジン間で慎重なポリシーの変換が必要です。 データメッシュアーキテクチャにおける相互運用性の要件 データ相互運用性とは、システムが共通ストレージレイヤーからデータを重複なく安全にアクセス、解釈、処理する能力です。 このブログでは、特に AWS が管理するストレージを使用する AWS ネイティブサービスとパートナープラットフォーム間のデータコンシューマーとプロデューサー間の相互運用性に焦点を当てています。 データメッシュ実装のための主要なデータ相互運用性要件： 1. クロスカタログメタデータフェデレーション – フェデレーションメタデータカタログを通じて、組織の境界を越えてドメインデータ製品を発見可能にする 2. クロスアカウント認証と認可 – コンシューマークエリエンジンが適切な権限でプロデューサーデータにアクセスできる安全な認証情報管理の実装 3. 分散ポリシーの反映 – プロデューサー定義のアクセスポリシーをデータコンシューマーポイント全体に適用する一貫したガバナンスメカニズムの確立 図 2 は、データメッシュアーキテクチャにおける権限の粒度の適用を示しています。 これは、データフェデレーションプロセス中にシステムがユーザー ID またはエンジン ID を想定するかどうかに基づいて、粗い粒度ときめ細やかな権限の違いを示しています。 図 2. この図は、データ相互運用性要件がデータメッシュ内のプロデューサーとコンシューマープラットフォーム間の安全な共有をどのように可能にするかを示しています。クロスカタログアクセスはアプリケーション/システム ID を使用して行われ、ユーザー ID のためのエンジンは、コンシューマーカタログで定義されているとおりに FGAC 制御を実施します。 AWS とそのパートナーがどのようにデータメッシュアーキテクチャを構築し、2 つの主要なパターンを通じてデータ相互運用性要件を実装しているかを探ってみましょう： データプロデューサーとしての AWS プラットフォーム と データコンシューマーとしての AWS プラットフォーム です。 データメッシュの実装: AWS をデータプロデューサーとして利用する 図 3. この図は、データメッシュアーキテクチャにおいてデータプロデューサーとして機能する AWS を示し、AWS ネイティブサービスを使用するプロデューサーから AWS パートナーと AWS ネイティブサービスの両方を使用したコンシューマーへのデータフローを示しています。AWS ネイティブコンピュートエンジンとパートナーコンピュートエンジンの両方が、AWS 管理のデータレイクから直接データを利用しています。 1. クロスカタログメタデータフェデレーション サードパーティのクエリエンジンは、Lake Formation によって管理される AWS データレイク内のデータを検出・理解するために AWS Glue Data Catalog（GDC）を使用します。 GDC は、スキーマ定義、データ型、場所、その他のメタデータを一貫した方法で維持するための手段を提供します。 Glue Data Catalog へのカタログフェデレーションは、 AWS Glue API または AWS Glue Iceberg REST エンドポイント （Glue IRC）のいずれかを介して確立できます。 両方のアプローチが Apache Iceberg テーブルをサポートしていますが、Glue IRC API は統合のための標準的な REST API セットを有効にし、認証と認可のサポートを提供してフレームワークを簡素化します。 2. クロスアカウント認証と認可 サードパーティのクエリエンジンは、 Lake Formation 管理の認証情報 または S3 への直接アクセス用の IAM プリンシパルロールのいずれかを使用して、GDC カタログで検出されたデータにアクセスします。 Lake Formation 管理の認証情報を利用した提供方法が推奨されるアプローチです。 3. 分散ポリシーの反映 AWS Lake Formation との統合により、サードパーティサービスは Amazon S3 ベースのデータレイク内のデータに完全なテーブルアクセス権限で安全にアクセスできます。 組織は、サードパーティのクエリエンジンがきめ細やかなアクセス制御ポリシーを実施できるように、手動のポリシー共有や追加のメカニズムでこれを補完する必要があります。 機能 Lake Formation 認証情報 S3 用の IAM プリンシパル 目的 データレイクアクセス管理 AWS リソースのアクセス制御 粒度 きめ細やかな粒度（テーブル/列/行） 粗い粒度（バケット/プレフィックス/オブジェクト） 管理 Lake Formation で一元化 IAM と S3 バケットポリシー IAM/S3 ポリシー Lake Formation の制御が適用される アクセスを直接制御 ユーザーエクスペリエンス S3 権限の直接管理が不要 明示的な S3 権限が必要 統合 AWS とサードパーティのアプリケーション アプリケーション/ユーザーの直接アクセス 表 1. この表は、S3 ロケーションにアクセスするための Lake Formation による認証情報の提供（推奨アプローチ）と IAM プリンシパルロール方式を比較しています。 データコンシューマーとして利用する際のパートナー製品特有のデータ相互運用性機能 Databricks をコンシューマとして利用する場合 1. クロスカタログメタデータフェデレーション Databricks Lakehouse Federation を使用すると、組織は外部データシステムを Lakehouse 拡張としてクエリおよび統制管理ができます。 GDC に接続する際、Databricks は Iceberg REST カタログエンドポイントではなく、メタデータの検出とフェデレーションのために GDC API を使用します。 詳細については、 Unity Catalog における Hive Metastore と AWS Glue フェデレーションの一般提供開始のお知らせ を参照してください。 2. クロスアカウント認証と認可 データアクセス権限については、Databricks は Lake Formation の認証情報提供メカニズムではなく、従来のクロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。 顧客は、フェデレーションする各テーブルについて、Unity Catalog に S3 バケットストレージを明示的に登録する必要があります。 3. 分散ポリシーの反映 Databricks で Lake Formation のきめ細やかなアクセス制御を複製するには、Lake Formation からアクセスポリシーを抽出し、それらを同等の Databricks Unity Catalog の権限に変換する同期メカニズムが必要です。 これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。 Snowflake をコンシューマとして利用する場合 1. クロスカタログメタデータフェデレーション AWS Glue Data Catalog から Snowflake Horizon カタログへのクロスカタログメタデータフェデレーションを実装するために、Snowflake は カタログ統合 を使用します。 AWS Glue と統合するために、Snowflake はカタログ提供の認証情報などの追加の Iceberg テーブル機能をサポートする AWS Glue Iceberg REST エンドポイント のカタログ統合を作成することを推奨しています。 詳細については、 Apache Iceberg Rest Catalog (IRC) のカタログ統合に関する追加情報 を参照してください。 2. クロスアカウント認証と認可 Snowflake Horizon カタログと AWS GlueのIceberg REST エンドポイントの統合は、Lake Formation による認証情報の提供機能（現在は粗い粒度のみ）をサポートしています。詳細については、 Apache Iceberg テーブルのカタログ提供の認証情報を使用する を参照してください。 3. 分散ポリシーの反映 Snowflake で Lake Formation のきめ細やかなアクセス制御を複製するには、Lake Formation からアクセスポリシーを抽出し、それらを同等の Snowflake Horizon カタログの権限に変換する同期メカニズムが必要です。これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。   パターン 要件 統合機能 コンシューマーとしての Databricks（プロデューサーとしてのAWS） 1. カタログフェデレーション UC から GDC へのフェデレーション 2. データストレージ権限 S3 への IAM ロールアクセス （L F認証情報のサポートなし） 3. データポリシーの反映 カスタムプロセスを介して複製され、Databricks によって実施されるきめ細やかなポリシー コンシューマーとしての Snowflake（プロデューサーとしてのAWS） 1. メタデータフェデレーション CREATE CATALOG INTEGRATION（Apache Iceberg REST） 2. データストレージ権限 Apache Iceberg のカタログ提供の認証情報を使用する （ テーブル全体へのアクセス権を持つ Lake Formation 認証情報 を使用） 3. データポリシーの反映 カスタムプロセスを介して複製され、Snowflake によって反映される FGACポリシー 表2. この表は、AWSをデータプロデューサーパターンとして実装する際に、AWS 管理のデータレイクとのデータ相互運用性を可能にする Databricks と Snowflake が提供する統合機能をまとめたものです。 データメッシュの実装: AWS をデータコンシューマーとして利用する 図4 は、データプロデューサーとしてAWS パートナープラットフォームを使用する際に AWS ネイティブ分析サービスを使用たデータコンシューマーへのデータの流れを示しています。 図4. この図は、データメッシュアーキテクチャにおいてデータコンシューマーとして機能するAWSプラットフォームを示しています。AWS ネイティブコンピュートは、AWS 管理のデータレイクとパートナーが管理するストレージからデータを消費します。 データコンシューマーとしての AWS ネイティブデータ相互運用性機能 1. クロスカタログメタデータフェデレーション AWS Glue は現在、リモート Iceberg への カタログフェデレーション をサポートしています。この機能により、AWS Glue Data Catalog を Databricks Unity Catalog、Snowflake Polaris カタログ、Horizon カタログ、およびカスタム Iceberg REST カタログ実装とフェデレーションを設定することができます。統合後、AWS Glue はバックグラウンドでメタデータの同期を自動的に管理し、クエリ結果にリモートカタログからの最新のテーブル変更が反映されるようにはたらきます。フェデレーションされたテーブルは、Amazon Redshift、Amazon EMR、Amazon Athena、AWS Glue などの AWS 分析エンジンを使用して検出およびクエリが可能です。 2. クロスアカウント認証と認可 Lake Formation は、AWS ネイティブサービスがデータレイクアクセスに使用するのと同じ アプリケーション統合プロセス を使用して、フェデレーションソースにデータガバナンスを拡張します。カタログフェデレーションは、フェデレーションデータソースに対して Lake Formation のきめ細やかなアクセス制御を使用します。 ユーザーが Athena などの AWS コンピュートサービスにクエリを送信すると、AWS ネイティブサービスはアクセス権限を確認して認証情報を取得するためにリクエストを Lake Formation に転送します。認可されると、Lake Formation はこれらの認証情報を AWS ネイティブサービスに提供し、Amazon S3 で要求されたデータにアクセスできるようにします。フェデレーションテーブルにクエリを実行する際、AWS Glue はクエリ時にリモートカタログから現在のメタデータを検出し、Lake Formation は S3 バケットに格納されたテーブルデータへのスコープ付き認証情報を提供してアクセスを管理します。その後、AWS ネイティブサービスは取得したデータにポリシーベースのフィルタリングを適用してから、結果をユーザーに返します。 3. 分散ポリシーの反映 Lake Formation は、フェデレーション 対象のIceberg カタログに対する包括的アクセス制御を提供し、データ所有者が AWS アカウント間でフェデレーションテーブルを共有する際に列、行、セルレベルの権限を付与できるようにします。Lake Formation は、フェデレーションカタログのデータベース/テーブル/列に対するタグベースのアクセス制御（TBAC）もサポートしており、組織は個々のリソースポリシーを管理するのではなく、リモートカタログオブジェクトにタグを適用することでガバナンスを効率化できます。ただし、組織はサードパーティプラットフォームから Lake Formation へのきめ細やかなアクセス制御を同期するための補完的なポリシー共有または追加のメカニズムを実装する必要があります。 データプロデューサーとしてのパートナー固有のデータ相互運用性機能 Databricks 1. クロスカタログメタデータフェデレーション Unity Catalog は OpenAPI 仕様に従って構築され、Apache 2.0 ライセンスで、複数の API 標準を通じて幅広い互換性を提供しています。製品の詳細については Unity Catalog のオープンソース化 をご覧ください。 Databricks は Unity REST API と Apache Iceberg REST カタログを使用して Unity Catalog テーブルへのアクセスを提供しています。具体的な手順については、 Apache Iceberg クライアントから Databricks テーブルにアクセスする と Unity Catalog への外部データアクセスを有効にする を参照してください。 2. クロスアカウント認証と認可 Unity Catalog の認証情報提供メカニズムにより、ユーザーは外部クライアントが Databricks によって管理されるデータ上の権限を継承するように構成できます。Iceberg と Delta の両方のクライアントが認証情報提供メカニズムの利用をサポートしています。AWS 固有の手順については、 外部システムアクセスのための Unity Catalog 認証情報提供、外部システムを使用した Databricks データへのアクセス および サービス認証情報の作成方法 を参照してください。 データアクセス権限については、Glue Data Catalog は Unity 認証情報提供メカニズムではなく、従来のクロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。顧客は、Lake Formation が一時的な認証情報提供を管理できるように、フェデレーションの一部として S3 バケットストレージへの権限を明示的に設定する必要があります。 3. 分散ポリシーの反映 Databricks Unity Catalog のきめ細やかな制御を Lake Formation で複製するには、Unity Catalog ポリシーを抽出し、同等の Lake Formation 権限に変換する同期メカニズムが必要です。組織はこれを手動でのポリシー複製または両方のガバナンスシステム間で継続的な同期を維持するカスタムソリューションの開発のいずれかを通じて実装します。 Snowflake 1. クロスカタログメタデータフェデレーション Snowflake Open Catalog は、オープン API を通じてあらゆる Iceberg テーブルメタデータを公開することで、サードパーティのクエリエンジンとの相互運用性をサポートするように設計されています。これにより、外部エンジンがメタデータにアクセスして Snowflake Open Catalog に格納されているデータをクエリでき、フェデレーションデータアクセスアプローチをサポートします。さらに、Horizon カタログは、外部クエリエンジンを使用して Iceberg テーブルを読み取ることができる Apache Iceberg REST API を公開しています。Snowflake Open Catalog は Apache Polaris の管理バージョンですが、顧客はApache Polaris を直接セルフホストすることもできます。詳細については、 Snowflake Open Catalog の使用開始 を参照してください。 2. クロスアカウント認証と認可 Snowflake Open Catalog 認証情報提供メカニズムは、Open Catalog　メタデータと Apache Iceberg テーブルストレージロケーションの両方のアクセス管理を一元化します。有効にすると、Open Catalog はクエリエンジンにテーブルデータにアクセスするための一時的なストレージ認証情報を提供し、ストレージアクセスを個別に管理する必要性を排除します。具体的な手順については、 Snowflake Open Catalog 認証情報提供 と 外部カタログの認証情報提供を有効にする を参照してください。 単一の Horizon カタログエンドポイントを使用して新規または既存の Snowflake　アカウントで Snowflake の Iceberg テーブルにクエリを実行し、クエリエンジンにテーブルデータにアクセスするための一時的なストレージ認証情報を提供します。 Snowflake Horizon カタログを通じて外部エンジンで Apache Iceberg テーブルにクエリを実行する を参照してください。 データアクセス権限については、GDC は Snowflake 認証情報提供メカニズムではなく、クロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。顧客は、Lake Formation が一時的な認証情報提供を管理できるように、フェデレーションの一部として S3 バケットストレージへの権限を明示的に設定する必要があります。 3. 分散ポリシーの反映 Snowflake のきめ細やかなアクセス制御を Lake Formation へ複製するには、Snowflake からアクセスポリシーを抽出し、同等の Lake Formation 権限に変換する同期メカニズムが必要です。これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。   パターン 要件 統合機能 プロデューサーとしての Databricks （コンシューマーとしての AWS） 1. カタログフェデレーション AWS Glue カタログフェデレーションから Unity Catalogへ 2. データストレージ権限 S3 アクセス用の IAM ロール 3. データポリシーの反映 FGAC ポリシーは手動またはカスタムロジックを介して Lake Formation に複製され、実施される プロデューサーとしての Snowflake （コンシューマーとしての AWS） 1. メタデータフェデレーション AWS Glue カタログフェデレーションで Open Catalog または Horizon Catalog IRC API を使用 2. データストレージ権限 S3 アクセス用の IAM ロール 3. データアクセスポリシー FGAC ポリシーは手動またはカスタムロジックを介して Lake Formation に複製され、実施される 表3. この表は、AWSをデータコンシューマーパターンとして実装する際に、Databricks とSnowflake とのデータ相互運用性を可能にする AWS が提供する統合機能をまとめたものです。 結論 データメッシュアーキテクチャを成功させるには、3つの重要な相互運用性要件に対応する必要があります：クロスカタログメタデータフェデレーション、クロスアカウント認証と認可、そして分散ポリシーの反映です。Apache Iceberg のようなオープンテーブルフォーマットをサポートするパートナーは組織が柔軟で安全かつスケーラブルなデータアーキテクチャを構築できるような補完的な機能を提供しますが、さらに AWS Lake Formation を利用することでデータメッシュ実装のための堅牢な基盤を構築することが可能です。これらのパターンを、Databricks と Snowflake を代表例として使用して実証ました。 Apache Iceberg は、データメッシュアーキテクチャを検討している組織にとって、テーブルフォーマットとして説得力のある利点を提供します。そのクロスプラットフォーム互換性により、異なるクエリエンジン間で一貫したデータアクセスが可能になり、簡素化された認証/認可による効率的な統合オプションを提供します。また、このフォーマットは、スキーマ進化、タイムトラベル機能、ACID トランザクションなどの価値ある機能をサポートしており、分散所有権シナリオでデータの整合性を維持するのに役立ちます。これらの特性により、データメッシュアプローチの実装を検討しているチームにとって、Iceberg は評価する価値があります。 クロスカタログメタデータフェデレーションを実装する ために、AWS とパートナーの機能を活用して分散データ資産の統合ビューを作成し、ドメイン所有権を維持しながらデータ発見をシームレスにします。この重要なバランスにより、金融サービス組織は従来のデータサイロを解消しながら、革新のスピードと規制遵守の両方を維持することができます。 最後に、チームはデータメッシュを実装する前に 組織全体で標準化されたポリシー定義を確立する べきです。プラットフォーム間（AWS Lake Formation、Databricks、Snowflakeなど）で変換できるセキュリティポリシーの共通フレームワークを作成することで、ドメインチームが自分たちのデータ製品を管理する自律性を許容しながら、一貫したガバナンスを維持します。ポリシー標準化は重要な焦点領域であり、共通ポリシー定義フォーマットの確立とクロスエンジンポリシー変換の改善に向けた取り組みが進められています。これらの技術が成熟するにつれて、組織は安全でスケーラブルなデータメッシュアーキテクチャを自信を持って構築し、ドメインチームがデータプロダクトを所有しながら、データエコシステム全体にわたる企業全体のガバナンスと相互運用性を維持することができます。

AWS CloudTrail は、AWS アカウントの API 呼び出しとイベントを記録し、ガバナンス、コンプライアンス、運用上のトラブルシューティングのための監査証跡を提供します。お客様は CloudTrail でデータイベントを有効にすることで、リソースレベルの操作に対するより深い可視性を得ることもできます。これには、 Amazon S3 のオブジェクトレベル操作（GetObject/PutObject など）や AWS Lambda 関数の呼び出しが含まれます。データイベントは、不正アクセスの検出、セキュリティインシデントの調査、およびデータプレーンに関する詳細なアクティビティログを必要とするコンプライアンス要件の充足に役立ちます。 データイベントは、AWS インフラストラクチャにおける重要な監視ポイントになります。Amazon S3 オブジェクトへのアクセス、Amazon DynamoDB の操作、AWS Lambda 関数の呼び出しのいずれにおいても、これらのイベントを理解することはセキュリティ、コンプライアンス、運用の優位性にとって不可欠です。しかし、これらのイベントは膨大な量のデータを生成する可能性があり、ダウンストリームワークフローのコストとストレージ要件の増大を招く恐れがあります。組織はこの点に関して難しい課題に直面することがよくあります：多くの組織は、ダウンストリームシステムに送信されるデータ量を削減することが困難であったり、データイベントの異常を特定したり、異常が発生した際に迅速に対応することに苦労しています。これらの課題は、不必要なコスト負担を生み出し、トラブルシューティングの取り組みを遅らせ、潜在的なセキュリティリスクを放置してしまう可能性をもたらします。 本日、データイベントの監視と対応方法を変革する AWS CloudTrail の強力な新機能を 2 つご紹介できることを嬉しく思います：CloudTrail データイベント用の イベント集約 と Insights です。各機能は、お客様のそれぞれのニーズに対応します。イベント集約は、ダウンストリームワークフローのデータ量を最適化し、API アクティビティの変化パターンを特定しやすくします。そして CloudTrail Insights は、データイベントの異常を特定し、セキュリティ監視を強化するのに役立ちます。インフラストラクチャコストの最適化、コンプライアンス要件の充足、セキュリティインシデントの調査といった目的に対して、これらの新機能は、大量のログデータでチームを圧倒することなく、適切なソリューションを提供します。 この記事では、これらの新機能がどのように機能するかを紹介し、データイベントを分析して実用的なインサイトを作成する方法を説明します。 前提条件 このウォークスルーには、データイベントが有効になっている既存の CloudTrail 証跡が必要です。新しい証跡を作成する際に、集約イベントと Insights イベントを直接有効にすることもできます。また、これら 2 つの新機能は CloudTrail の追加コストが発生します。料金の詳細については、 AWS CloudTrail の料金 をご覧ください。 注意： イベント集約とデータイベント用インサイトを使用するには、証跡でデータイベントを有効にする必要があります。 イベント集約 データイベント用の CloudTrail イベント集約の設定 CloudTrail イベント集約は、データイベントを 5 分間のサマリーに統合し、アクセス頻度、エラー率、最も頻繁に使用された API アクションなどの主要なトレンドに対する可視性を提供します。この要約アプローチは、セキュリティ監視、運用監視にとって重要なインサイトを維持しながら、ダウンストリームの分析システムに送信されるデータ量を大幅に削減します。 このサンプルシナリオでは、データイベントを有効にしている既存の証跡に対して集約を有効化する方法を説明します。 CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 証跡 を選択します。 CloudTrail イベント用の 証跡 を選択します。 Aggregated events で、 編集 を選択します。 Aggregation template で、サービスが提供する以下のテンプレートから任意のものを選択して、データイベントを集約できます。 API Activity ：API 呼び出しのデータイベントに関して、5 分単位のサマリーを取得します。このテンプレートを使用することで、頻度、呼び出し元、ソースを含む API の使用パターンを理解できます。 Resource Access ：AWS リソースのアクティビティパターンを取得します。このテンプレートを使用することで、AWS リソースがどのようにアクセスされているか、5 分間のウィンドウで何回アクセスされているか、誰がリソースにアクセスしているか、どのようなアクションが実行されているかを理解できます。 User Actions ：API 呼び出しを行う IAM プリンシパルに基づいたアクティビティパターンを取得します。 図 1：AWS CloudTrail 集約イベント 変更の保存 を選択します。 CloudTrail は証跡に設定されているリソースに関して、全てのデータイベントの集約を開始します。（ 補足： この機能は、新しい証跡を作成する際にも設定できます）。 CloudTrail 集約イベントの分析 集約イベントは、証跡に設定した S3 バケット内の CloudTrail-Aggregated フォルダに配信されます。その後、 Amazon Athena を使用して S3 バケットからこれらのイベントをクエリしたり、CloudTrail イベントを CloudWatch Logs に配信している場合は CloudWatch Logs Insights を使用することもできます。 CloudWatch Logs Insights を使用して、API アクティビティの集約イベントをクエリし、5 分間の API アクティビティの集約カウントを表示する方法を見てみましょう。次に、全体的なアクティビティに寄与したユーザー ID とリソースを表示します。 CloudWatch コンソール に移動します。 左側のナビゲーションメニューで、 Logs Insights を選択します。 Query definition セクションで、 SQL を選択します。 以下のクエリをコピーして、エディタウィンドウに貼り付けます。（注意： [Log Group] を CloudTrail 用のロググループ名に置き換える必要があります）。 SQL クエリ： SELECT accountId, awsRegion, `summary.primaryDimension.dimension` as Dimension, `timeWindow.windowStart` as `Start Time`, `timeWindow.windowEnd` as `End Time`,`summary.details.3.statistics.0.name` as sourceIpAddress, `summary.primaryDimension.statistics.0.name` as eventName, `summary.primaryDimension.statistics.0.value` as Count, `summary.details.1.statistics.0.name` as userIdentity, `summary.details.0.statistics.0.name` as resource, `summary.details.0.statistics.0.value` as `Resource Count` FROM `[Log Group]` Where `eventCategory` = 'Aggregated' and `summary.primaryDimension.dimension` = 'eventName' ORDER BY `timeWindow.windowStart`, `timeWindow.windowEnd` DESC; クエリの実行 をクリックすると、結果が表示されます。 図 2： CloudWatch Logs Insights のクエリ結果 クエリ結果には、集約イベントの各期間で実行された API アクションと全体のカウントが表示されます。また、API アクティビティの全体カウントに寄与したユーザーとリソースに関して、追加の統計情報も表示されます。さらに、追加の分析のために Resource Access および User Access 集約テンプレートに関連するイベントに対して、同じ要領でクエリを実行することもできます。 サブスクリプションフィルターによる集約イベントのダウンストリームへの送信 イベント集約は、データイベントを 5 分間のサマリーに統合し、全体のカウントを提供するとともに、イベント集約中にキャプチャされた全体カウントに寄与したユーザー ID、API アクティビティ、またはリソースに関する主要な統計情報を表示します。イベント集約レコードのフィールドに関する詳細は、 集約イベントの CloudTrail レコードの内容 のドキュメントを参照してください。イベント集約がデータイベントと比較して配信するイベント量を削減している例を以下に示します。 図 3：CloudTrail におけるデータイベント数と集約イベントの総数の比較 CloudTrail ログに対してサブスクリプションフィルターを作成し、CloudWatch Logs から Kinesis Data Streams、Amazon Data Firehose、Lambda 関数、または Amazon OpenSearch Service などの宛先にデータイベントではなく集約イベントを送信することで、ダウンストリームのシステムに送信されるデータ量を削減できます。 CloudTrail の管理イベントと集約イベントのみを送信するサブスクリプションフィルターの設定方法を見てみましょう。 CloudWatch コンソール に移動します。 左側のナビゲーションメニューで、 ロググループ を選択します。 CloudTrail に使用されているロググループを選択します。 サブスクリプションフィルター タブを選択します。 作成 を選択し、Amazon Kinesis Data Streams、AWS Lambda、Amazon Data Firehose、または Amazon OpenSearch Service のいずれかを選択します。 次に、サブスクリプションフィルターに以下のログ形式とフィルターパターンを使用します。 ログの形式 : JSON サブスクリプションフィルターのパターン：  { ($.eventCategory = “Management”) || ($.eventCategory = “Aggregated”) } 図 4：CloudWatch サブスクリプションフィルター データイベントのインサイト データイベントに対する CloudTrail Insights の設定 AWS CloudTrail Insights は、CloudTrail イベントを分析することで、AWS アカウント内の異常な API アクティビティのパターンを自動的に検出する高度な機能です。以前は管理イベントのみが対象でしたが、現在はデータイベントに対しても、アカウントの通常時と大きく異なる使用パターンを識別できるようになりました。機能を有効化すると、CloudTrail Insights は API コールレートとエラーレートを監視し、リソースプロビジョニングの突然の急増、アクセスパターンやエラーレートなどに関する異常を検出したときに Insights イベントを生成します。 このサンプルシナリオでは、既存の CloudTrail 証跡に対してデータイベント用の Insights イベントを設定する方法を説明します。 CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 証跡 を選択します。 CloudTrail イベントの 証跡 を選択します。 Insights イベント の 編集 を選択します。 Data events Insights types で、以下のオプションを選択できます。 API コールレートインサイト – 1 分あたりに発生するデータ API 呼び出しの数が API コールレートのベースラインから逸脱したときにインサイトを生成します。書き込み操作に関するデータ API 呼び出しのみを計測します。 API エラーレートインサイト – 失敗してエラーを返したデータ API 呼び出しの数がエラーレートのベースラインから逸脱したときにインサイトを生成します。読み取りと書き込みの両方のデータ API 呼び出しを計測します。 図 5：データイベントに対する Insights イベントの設定 Insights イベントを有効にすると、CloudTrail はまず通常のアクティビティパターンのベースラインを確立する必要があり、最初の Insights イベントが配信されるまでに最大 36 時間かかることがあります。また、Insights イベントを無効にしてから再度有効にした場合や、証跡のログ記録を停止してから再開した場合も、同様に Insights イベントの配信が再開されるまでに最大 36 時間かかる可能性があります。 データイベントに対する CloudTrail Insights の分析 CloudTrail Insights イベントは、標準の CloudTrail イベントとは異なり、CloudTrail がアカウントの通常の API アクティビティのパターンからの逸脱を検知した場合にのみ生成されます。コンソールを通じてインサイトイベントを表示する方法を見てみましょう： CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 Insights を選択します。 Data events タブを選択して、インサイトイベントのリストを表示します。 リストから Insights イベントを選択して、詳細を表示します。 図 6：CloudTrail Insights の Insights イベントの一覧 Insights イベントの詳細ページには、異常なアクティビティのタイムラインのグラフが表示されます。 図 7：Insights イベントの詳細 さらに、CloudWatch メトリクスフィルターや Event Bridge ルールを使用して、特定のインサイトパターンに基づいてアラームと通知を設定できます。設定方法の詳細については、ブログ記事 Leveraging AWS CloudTrail Insights for Proactive API Monitoring and Cost Optimization および Analyzing AWS CloudTrail in Amazon CloudWatch をご覧ください。 クリーンアップ 追加料金の発生を防ぐため、このウォークスルー中に作成した CloudTrail Insights と集約イベントの設定を削除してください。 まとめ CloudTrail イベント集約とデータイベントの Insights は、さまざまなお客様のニーズに対応する強力な新機能を提供します。CloudTrail 集約イベントは、CloudTrail のデータをダウンストリームワークフローに送信するお客様向けのソリューションを提供し、必要な可視性を維持しながらデータ量と関連コストの削減を支援します。CloudTrail Insights は、異常やパターンを明確に特定するために必要なコンテキストを提供し、セキュリティチームと運用チームが手動分析なしで異常なアクティビティを検出できるよう支援します。この記事では、データ処理パイプラインを最適化する CloudTrail イベント集約の設定方法と、異常なアクティビティパターンを自動的に検出し、CloudWatch メトリクスフィルターを使用してアラートを作成するためのデータイベント用 CloudTrail Insights の設定方法を説明しました。これらの新しい CloudTrail の機能が、セキュリティ体制の強化やコストの最適化にどのように役立つか詳しく知るには、 AWS CloudTrail ドキュメント をご覧ください。 本ブログは Solutions Architect の 加藤 が翻訳しました。原文は こちら です。