AWS Lambda と Amazon DynamoDB を使用したクロスアカウントストリーム処理の簡素化

本記事は 2026 年 02 月 09 日に公開された “Simplify cross-account stream processing with AWS Lambda and Amazon DynamoDB” を翻訳したものです。

原文: https://aws.amazon.com/blogs/database/simplify-cross-account-stream-processing-with-aws-lambda-and-amazon-dynamodb/

組織は、セキュリティと分離のためにマルチアカウントアーキテクチャを使用することがよくあります。しかし、Amazon DynamoDB テーブルが 1 つのアカウントにある場合、そのストリームイベントを別のアカウントで処理する必要があるかもしれません。最近まで、これは Amazon Kinesis Data Streams を経由するか、クロスアカウント AWS Identity and Access Management (IAM) ロールを使用したカスタムリレーインフラストラクチャを構築することを意味し、不要な複雑さが追加されていました。Amazon DynamoDB Streams のリソースベースポリシーにより、これらの回避策を避けることができるようになりました。AWS Lambda 関数は、カスタムインフラストラクチャを必要とせずに、アカウント間でストリームを直接消費できます。

DynamoDB は、サーバーレスでフルマネージドな分散 NoSQL データベースであり、大規模環境でも 1 桁ミリ秒のパフォーマンスを実現します。インフラストラクチャを管理することなく、最新の高性能アプリケーションを構築できます。その主要な機能の 1 つが DynamoDB Streams で、ほぼリアルタイムでデータの変更をキャプチャします。この機能は、監査ログ、検索インデックス作成、クロスリージョンレプリケーション、異常検出、リアルタイム分析などのユースケースをサポートします。

Lambda は、サーバーのプロビジョニングや管理なしでコードを実行できるサーバーレスコンピューティングサービスです。Lambda は DynamoDB Streams と統合されているため、テーブルの更新に応じて関数を自動的にトリガーできます。この統合は、データレプリケーション、マテリアライズドビュー、分析パイプライン、イベント駆動型アーキテクチャなどのユースケースに役立ちます。

この記事では、DynamoDB Streams でリソースベースポリシーを使用して、クロスアカウント Lambda 消費を有効にする方法を探ります。アプリケーションワークロードが分離されたアカウントに存在し、ストリーム処理が集中化されたアカウントまたは分析アカウントで行われる一般的なパターンに焦点を当てます。

DynamoDB Streams を使用したクロスアカウント Lambda のメリット

DynamoDB Streams のリソースベースポリシーを使用すると、ある AWS アカウントの Lambda 関数に、別のアカウントの DynamoDB ストリームから読み取る直接アクセスを許可できます。カスタムリレーインフラストラクチャは必要ありません。

この機能により、マルチアカウントイベント駆動型アーキテクチャを簡素化し、セキュリティを向上させ、運用負担を軽減できます。Lambda は、同じアカウントのイベントソースマッピングと同様に、取り込み、フィルタリング、配信、再試行、エラー処理を管理します。

SaaS サービスを運用している場合、集中化された分析パイプラインを実行している場合、または開発、ステージング、本番環境用に分離された環境を管理している場合など、別の AWS アカウントで DynamoDB ストリームイベントを処理したい理由はたくさんあります。DynamoDB Streams のリソースベースポリシーサポートにより、強力なアクセス制御を維持しながら、これらのパターンを簡単に実装できます。

この機能により、いくつかのアーキテクチャパターンが可能になります。

集中データ処理 – 複数のアプリケーションアカウントからのストリームを、Lambda 関数が集約、変換、データウェアハウスへのロードを実行する中央分析またはデータレイクアカウントにルーティングします。
共有サービス – 組織全体のテーブルからストリームを消費する、専用アカウントで再利用可能な監査ログ、コンプライアンス監視、または通知サービスを構築します。
マルチテナントアーキテクチャ – 分離されたアカウント内のテナント固有の Lambda 関数が、集中化された DynamoDB テーブルからデータを処理できるようにし、イベント駆動型ワークフローをサポートしながらセキュリティ境界を維持します。

ソリューションの概要

クロスアカウントアクセスモデルは、2 つのコンポーネントを使用します。

DynamoDB ストリームのリソースベースポリシー（ソースアカウント内） – 消費アカウント内の Lambda 実行ロールに権限を付与します
IAM 実行ロール（消費アカウント内） – Lambda 関数がストリームから読み取ることを許可します

Lambda 関数とクロスアカウント DynamoDB ストリーム間のイベントソースマッピングを構成すると、ストリームのリソースポリシーと Lambda 関数の実行ロールの組み合わせた権限を使用してアクセスが許可されます。ストリームのリソースベースポリシーは Lambda 実行ロールを承認し、実行ロールはストリームレコードの読み取りと処理に必要な特定の権限を提供します。

これがどのように機能するかを説明するために、企業顧客にドキュメント処理サービスを提供する SaaS プロバイダーを考えてみましょう。各顧客は、分離とセキュリティの向上のために専用の AWS アカウントで運用されています。ドキュメントが処理されると、テナントは DynamoDB Streams が有効になっている DynamoDB テーブルにレコードを書き込みます。SaaS サービスチームは、請求と分析のために、これらのレコードを中央 AWS アカウントに集約したいと考えています。クロスアカウント Lambda と DynamoDB Streams を使用すると、この統合は簡単でフルマネージドになります。

次の図は、アーキテクチャを示しています。

アーキテクチャ図

この記事では、アカウント B のテーブルからの DynamoDB ストリームイベントを処理するために、アカウント A に Lambda 関数を設定します。最初に Lambda 実行ロールを作成し、次にストリームを使用して DynamoDB テーブルを設定し、クロスアカウント権限を構成し、最後にイベントソースマッピングでそれらを接続します。

次のコマンドは、変数を使用してセットアップを再利用可能にし、ステップ間での Amazon リソースネーム (ARN) の手動コピーを削減します。

前提条件

このソリューションをデプロイするには、2 つの AWS アカウントと必要なリソースを作成する権限が必要です。このソリューションは AWS コマンドラインインターフェイス (CLI) を使用します。これはこれらの手順を使用してインストールできます。

変数の定義

次のコードを使用して変数を定義します。

# AWS Region
REGION=us-east-1

# Resource names
TABLE_NAME=Orders
ROLE_NAME=CrossAccountStreamProcessor
FUNCTION_NAME=ProcessOrders

アカウント A で Lambda 実行ロールを作成

アカウント A で、Lambda 実行ロールとして機能する IAM ロールを作成します。

ROLE_ARN="$(aws iam create-role \
--role-name "$ROLE_NAME" \
--assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}' \
--query 'Role.Arn' \
--output text)"

aws iam attach-role-policy \
--role-name "$ROLE_NAME" \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole

echo "Role ARN: $ROLE_ARN"

アカウント A で Lambda 関数を作成

Lambda 関数コードを作成します。

cat > index.py << 'EOF'
import json

def handler(event, context):
    print(json.dumps(event, indent=2))
    return {'statusCode': 200}
EOF

コードをパッケージ化します。

zip function.zip index.py

Lambda 関数を作成します。

aws lambda create-function \
--function-name "$FUNCTION_NAME" \
--runtime python3.12 \
--role "$ROLE_ARN" \
--handler index.handler \
--zip-file fileb://function.zip \
--region "$REGION"

アカウント B でストリームを使用した DynamoDB テーブルを作成

アカウント B で、ストリームが有効になっている DynamoDB テーブルを作成します。

STREAM_ARN="$(aws dynamodb create-table \
--table-name "$TABLE_NAME" \
--attribute-definitions AttributeName=OrderId,AttributeType=S \
--key-schema AttributeName=OrderId,KeyType=HASH \
--billing-mode PAY_PER_REQUEST \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region "$REGION" \
--query 'TableDescription.LatestStreamArn' \
--output text)"

echo "Stream ARN: $STREAM_ARN"

アカウント B でストリームにリソースベースポリシーをアタッチ

アカウント B で、DynamoDB ストリームにリソースベースポリシーをアタッチします。まず、JSON ポリシーを作成します。

cat > stream-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountStreamAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "$ROLE_ARN"
      },
      "Action": [
        "dynamodb:DescribeStream",
        "dynamodb:GetRecords",
        "dynamodb:GetShardIterator"
      ],
      "Resource": "*"
    }
  ]
}
EOF

次に、ポリシーを適用します。

aws dynamodb put-resource-policy \
  --resource-arn "$STREAM_ARN" \
  --policy file://stream-policy.json \
  --region "$REGION"

アカウント A でイベントソースマッピングを作成

アカウント A で、Lambda 関数とクロスアカウントストリーム間のイベントソースマッピングを作成します。

aws lambda create-event-source-mapping \
--function-name "$FUNCTION_NAME" \
--event-source-arn "$STREAM_ARN" \
--starting-position LATEST \
--region "$REGION"

考慮事項

このソリューションをデプロイする際は、以下の点に留意してください。

DynamoDB テーブルと Lambda 関数の両方が同じ AWS リージョンにある必要があります
標準の DynamoDB Streams および Lambda の料金が適用されます。クロスアカウントアクセスに対する追加料金はありません
ストリームのリソースベースポリシーは、きめ細かいアクセス制御のためにプリンシパルとして Lambda 実行ロール ARN を使用します
ストリームのリソースベースポリシーは、条件やポリシー変数を含む標準の IAM ポリシー機能をサポートします
ポリシーに次の必須アクションを含めるようにしてください：dynamodb:DescribeStream、dynamodb:GetRecords、dynamodb:GetShardIterator
この機能は、ストリームが有効になっている新規および既存の DynamoDB テーブルの両方で機能します
この機能は Amazon マネージドキーをサポートしていません

クリーンアップ

今後の料金の発生を避けるために、このウォークスルーで作成したリソースを削除します。

アカウント A で、作成したリソースを削除します。

aws lambda list-event-source-mappings \
--function-name "$ProcessOrders" \
--region "$REGION"

aws lambda delete-event-source-mapping \
--uuid <UUID-from-previous-command> \
--region "$REGION"

Lambda 関数を削除します。

aws lambda delete-function \
--function-name "$ProcessOrders" \
--region "$REGION"

IAM ロールを削除します。

aws iam detach-role-policy \
--role-name "$ROLE_NAME" \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole

aws iam delete-role \
--role-name "$ROLE_NAME"

アカウント B で、DynamoDB テーブルを削除します。
```
aws dynamodb delete-table \
--table-name "$TABLE_NAME"
```

まとめ

DynamoDB Streams のリソースベースポリシーサポートにより、AWS アカウント境界を越えてイベント駆動型システムを構築する強力な新しい方法が提供されます。この機能により、カスタム統合ロジックを記述することなく、安全でスケーラブルなパイプラインを作成できます。このソリューションは、SaaS サービスを実行している場合、ログを統合している場合、または変更データを集中的に処理している場合に役立ちます。

Lambda を使用した DynamoDB Streams は、リアルタイムストリーム処理のためのマネージドで信頼性の高いパスを提供します。今すぐクロスアカウント Lambda と DynamoDB Streams を使用して構築を開始し、イベント駆動型アーキテクチャを簡素化しましょう。

著者について

author name

Lee Hannigan

Lee は、アイルランドのドニゴールを拠点とする Amazon DynamoDB シニアデータベースエンジニアです。彼は、ビッグデータと分析技術の強固な基盤を持つ分散システムの豊富な専門知識をもたらします。彼の役割では、Lee は DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に焦点を当てながら、顧客と社内チームがその機能を最大限に活用できるよう支援しています。

Amazon Web Services ブログ