はじめに
今回は以下のアップデートの紹介をしてみます！
2026 年 4 月 23 日に Amazon Athena の managed connectors が発表されました。
Amazon DynamoDB や PostgreSQL、MySQL など 12 のデータソースに対して、フェデレーテッドクエリの設定が簡単になったみたいです。
これまでフェデレーテッドクエリを使うには、自分のアカウントに AWS Lambda 関数をデプロイして管理する必要がありました。
managed connectors では、その Lambda を Athena 側で管理してくれるので、自分のアカウントに Lambda が作られません。コンソールからデータソースを選んで接続情報を入れるだけで、フェデレーテッドクエリが使えるようになります。
今回はこの managed connectors を使って、DynamoDB と Aurora のデータを SQL で結合してみます！
この記事で学べること
- DynamoDB と Aurora をデータソースとして設定する手順
- AWS Lake Formation の権限設定
- 異なるデータソース間の JOIN クエリの実行方法
前提知識・条件
- 検証日: 2026 年 4 月 25 日
- リージョン: ap-northeast-1（東京）
やってみた
準備：DynamoDB と Aurora の準備
まずは、DynamoDB と Amazon Aurora PostgreSQL Serverless v2（以降、Aurora）を AWS CDK で構築しました。ソースコードはこちらです。
VPC は NAT Gateway 付きの Private サブネット構成にしています。
後述しますが、Athena の managed connector が VPC 内に ENI を作成してデータソースに接続します。
そのため、NAT Gateway 経由でのインターネットアクセスが必要でした。
データ投入
今回の検証では、EC サイトを想定した 2 つのテーブルを用意しました。
DynamoDB には注文データを格納する orders テーブルを作成しました。
| カラム | 型 | キー | 備考 |
|---|---|---|---|
| order_id | S | PK | 注文 ID |
| customer_id | S | SK | 顧客 ID |
| product_id | S | なし | 商品 ID（GSI/LSI なし） |
| quantity | N | なし | 数量 |
| order_date | S | なし | 注文日 |
| status | S | なし | pending/shipped/delivered |
Aurora には商品マスタの products テーブルを作成しました。
| カラム | 型 | キー | 備考 |
|---|---|---|---|
| product_id | VARCHAR | PK | 商品 ID |
| product_name | VARCHAR | 商品名 | |
| category | VARCHAR | カテゴリ | |
| price | NUMERIC | 価格 |
ポイントとして、DynamoDB 側の product_id と status には GSI/LSI を付けていません。
これらのカラムで WHERE 句を書くと Scan モードになるので、その動作も確認してみます。
DynamoDB の orders テーブルにはサンプルの注文データを 5 件投入しました。
| order_id | customer_id | product_id | quantity | order_date | status |
|---|---|---|---|---|---|
| ORD-001 | CUST-001 | PROD-001 | 2 | 2026-04-01 | shipped |
| ORD-002 | CUST-002 | PROD-002 | 1 | 2026-04-02 | pending |
| ORD-003 | CUST-001 | PROD-003 | 3 | 2026-04-03 | shipped |
| ORD-004 | CUST-003 | PROD-001 | 1 | 2026-04-04 | delivered |
| ORD-005 | CUST-002 | PROD-004 | 5 | 2026-04-05 | shipped |
Aurora の products テーブルには商品マスタを 4 件投入しました。
| product_id | product_name | category | price |
|---|---|---|---|
| PROD-001 | ワイヤレスマウス | PC周辺機器 | 3980 |
| PROD-002 | USBキーボード | PC周辺機器 | 5480 |
| PROD-003 | モニターアーム | オフィス用品 | 12800 |
| PROD-004 | ウェブカメラ | PC周辺機器 | 8900 |
今回はこの 2 つのテーブルに存在する product_id をキーにテーブル結合したクエリを発行してみます。
データカタログ用 IAM ロールの準備
managed connectors でデータソースを作成する際に、AWS Glue Data Catalog IAM ロールが必要です。
Athena がデータソースへアクセスする際に、このロールが使用されます。
このロールの設定が少し面倒で、トライアンドエラーで作成していく必要がありました。
結果、以下のような形になっています。
まず、信頼ポリシーには glue.amazonaws.com と lakeformation.amazonaws.com の 2 つを設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
権限ポリシーは用途ごとに分けて付与しました。
まず、managed connector の実行に必要な Glue 関連の権限です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:ManagedConnector",
"glue:GetConnection",
"glue:GetConnections",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:GetTable",
"glue:GetTables",
"glue:GetCatalog",
"glue:GetCatalogs"
],
"Resource": "*"
}
]
}
DynamoDB へのアクセスにはマネージドポリシー AmazonDynamoDBReadOnlyAccess を使いました。
Spill 用 Amazon S3 バケットへのアクセス権限も必要です。
フェデレーテッドクエリの結果が大きい場合、一時的に S3 にデータを退避（Spill）する仕組みがあり、そのためのバケットです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket",
"s3:DeleteObject",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::<spill-bucket-name>",
"arn:aws:s3:::<spill-bucket-name>/*"
]
}
]
}
Aurora（PostgreSQL）用には、AWS Secrets Manager と VPC ネットワーク関連の権限も追加します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>-*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVpcs"
],
"Resource": "*"
}
]
}
データソースの作成（DynamoDB / PostgreSQL）
Athena コンソールの「データソースとカタログ」から「データソースの作成」を選択します。
DynamoDB と PostgreSQL それぞれでデータソースを作成しました。
DynamoDB 側の設定はシンプルです。データソースとして「Amazon DynamoDB」を選択し、データソース名と IAM ロール、Spill 用 S3 バケットを指定するだけです。
Aurora 側は VPC 関連の設定が加わります。ホスト、ポート、データベース名、Secrets Manager のシークレット、VPC、サブネット、セキュリティグループを指定します。
セキュリティグループは、Athena コネクタ用の SG を CDK で作成しておきました。
Aurora 側の SG には、このコネクタ用 SG からのポート 5432 のインバウンドを許可しています。
作成が完了すると、Athena コンソールの「AWS Glue データカタログ」一覧にデータソースが表示されます。
Lake Formation の権限設定
managed connectors で作成されたフェデレーテッドカタログは Lake Formation で権限管理されます。
クエリを実行するユーザーに対して、カタログ・データベース・テーブルの各レベルで権限を付与する必要があります。
今回はCLI で権限を付与しています。
DynamoDB 側の例です。
# カタログレベル
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Catalog":{"Id":"<account-id>:athena-dynamodb2"}}' \
--permissions "ALL" --region ap-northeast-1
# データベースレベル
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Database":{"CatalogId":"<account-id>:athena-dynamodb2","Name":"default"}}' \
--permissions "ALL" --region ap-northeast-1
# テーブルレベル（全テーブル）
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Table":{"CatalogId":"<account-id>:athena-dynamodb2","DatabaseName":"default","TableWildcard":{}}}' \
--permissions "ALL" --region ap-northeast-1
PostgreSQL 側も同様ですが、public スキーマがデータベースとして認識されるため、testdb と public の両方に権限付与が必要でした。
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Catalog":{"Id":"<account-id>:athena-postgresql2"}}' \
--permissions "ALL" --region ap-northeast-1
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Database":{"CatalogId":"<account-id>:athena-postgresql2","Name":"public"}}' \
--permissions "ALL" --region ap-northeast-1
aws lakeformation grant-permissions \
--principal '{"DataLakePrincipalIdentifier":"<sso-role-arn>"}' \
--resource '{"Table":{"CatalogId":"<account-id>:athena-postgresql2","DatabaseName":"public","TableWildcard":{}}}' \
--permissions "ALL" --region ap-northeast-1
動作確認（DynamoDB 単体）
まずは DynamoDB 単体でクエリしてみます。
SELECT * FROM "athena-dynamodb2"."default"."orders"
5 件の注文データが返ってきました！
managed connector 経由で DynamoDB のデータを SQL で取得できています。
SuccessfulRequestLatency のメトリクスを見てみると、Scan で 29.4ms と出ているので、Scan で動いていることがわかります。
大量データの場合は RCU の消費に注意が必要ですね。
動作確認（PostgreSQL 単体）
次に Aurora 側です。
SELECT * FROM "athena-postgresql2"."public"."products"
商品マスタ 4 件が返ってきました。
動作確認（DynamoDB + PostgreSQL JOIN）
最後は、DynamoDB の注文データと Aurora の商品マスタを product_id で JOIN してみます。
SELECT o.order_id, o.customer_id, p.product_name, p.price, o.quantity
FROM "athena-dynamodb2"."default"."orders" o
JOIN "athena-postgresql2"."public"."products" p
ON o.product_id = p.product_id
DynamoDB と Aurora のデータが 1 つの SQL で結合できました！
まとめ
今回の検証で以下のようなことがわかりました。
- Athena managed connectors を使って、DynamoDB と Aurora のデータを 1 つの SQL で結合できた
- managed connectors では自アカウントへの Lambda デプロイが不要になり、セットアップが簡単になった
- ただし IAM ロール、Spill 用 S3 バケット、Lake Formation の権限設定は引き続き必要
- VPC 内のデータソースに接続する場合は NAT Gateway 付きの Private サブネット構成が必要
- VPCエンドポイントでも可能かと思います
このアップデート前はもっと大変だったのかなと思いつつ、データカタログ用 IAM ロールの準備等がまだまだ複雑だなぁとは感じますが、良いアップデートだな！ と思い、紹介しました。
誰かのお役に立てば幸いです。