AWS Glueテーブルを別アカウントへ移行する方法｜CloudFormationとAPIの選び方

AWSアカウントを分けるとき、AthenaやETL処理で使っているGlueテーブルも移行先で使えるようにしたいことがあります。ここで最初に分けて考えたいのが、テーブルの定義と、実際のデータの保存場所です。

Glue Data Catalogのテーブルは、列の構造やデータの場所などを表すメタデータです。テーブルを別アカウントに作っても、S3のファイルまでコピーされるわけではありません。本記事では、S3を参照する通常の外部テーブルを対象に、定義の再作成と利用確認の流れを整理します。Icebergテーブルやビューなどは、それぞれの形式に応じた移行設計が別途必要です。

移行方法は、今後の管理方法から選ぶ

どちらも、移行元のリソースの所有者を直接変更する操作ではありません。移行元を確認し、移行先に必要な定義を作り直します。まず一つの代表的なテーブルで確認してから対象を広げると、参照先や権限の問題を見つけやすくなります。

CloudFormationは、移行後の変更管理まで揃えたい場合に使う

データベース、テーブル、パーティションなどをテンプレートに記述して、移行先アカウントへデプロイします。GlueはクローラーやジョブなどにもCloudFormationで対応しているため、関連リソースと合わせた管理を検討できます。AWS公式のGlue用CloudFormationサンプルに、データベース・テーブル・パーティションの定義例があります。

ただし、既存テーブルが自動的に完成したテンプレートになる、という意味ではありません。元の列定義や形式を調べ、移行先のデータベース名、S3パスなどを反映する必要があります。環境ごとに変わる値をパラメータにすると、次の展開でも再利用しやすくなります。

APIは、取得した定義を整えてから再作成する

APIを使う場合は、移行元のGetTableで情報を取得し、移行先のCreateTableでテーブルを作ります。移行先データベースを先に準備し、各呼び出しで利用するアカウントとリージョンを確認します。

GetTableの応答全体を、そのままCreateTableへ渡すことはできません。作成時はTableInputなどの入力形式に合わせ、取得結果に含まれる管理情報と作成に必要な項目を分けます。仕様はGetTableとCreateTableを照合してください。

1. 元の定義を保存し、対象テーブルを一覧にする。
2. 移行先のデータベースとデータ配置を決める。
3. 作成APIの入力形式へ変換し、S3のLocationなどを確認する。
4. 移行先へ作成し、必要なパーティションも登録する。
5. 実際の利用者の権限でクエリを実行する。

テーブルだけ作っても、パーティションは揃わない

日付別などのパーティションをカタログに登録している場合、テーブルのパーティションキーと、個々のパーティション情報を区別します。例えばyearというキーを定義しただけでは、各年の登録済みパーティションを移したことにはなりません。

明示的なパーティション登録が必要な構成では、移行元の情報を取得し、BatchCreatePartitionなどで移行先へ登録します。パーティション自身にも保存場所の情報があるため、テーブル側のLocationだけ変更して終わりにしないでください。Athenaのパーティション射影を使っている場合は、射影用パラメータの確認など、構成に合った方法を選びます。

S3のデータを残すか、移すかを先に決める

テーブル定義の移行作業とS3のデータ移行作業を分けると、「テーブルは見えるが検索できない」ときの原因を追いやすくなります。IAM、S3バケットポリシー、KMSの権限に加え、Lake Formationで管理している場合は、その権限も確認対象です。

完了条件は、同じ名前のテーブルが見えることではない

移行先で、実運用と同じ権限を使って代表的なクエリを実行します。列名や型だけでなく、対象期間の件数、パーティションの範囲、NULLや文字化けの有無を確認します。データが更新され続ける場合は、比較時点も揃えます。

最初は読み取り対象を小さな期間に絞り、期待する結果が得られてから通常の処理へ広げると確認しやすくなります。テーブルの作成成功、データへのアクセス成功、結果の一致を別々に確認してから、旧環境の停止を判断します。

関連する記事

• ALBの応答時間をアクセスログで確認する方法：Athenaでログを分析する利用場面の参考になります。
• CloudWatch Logsの別アカウント移行：過去ログの保管と、今後の収集を分けて設計する方法を整理しています。