AWSクロスアカウント環境でのデータ基盤利用

この記事は every Tech Blog Advent Calendar 2024 の 22 日目の記事です。

データ&AIチームでデータエンジニアを担当している塚田です。

弊社のデータ基盤はDatabricksをベースにデータストアとしてAmazon S3を利用しています。

今回、データストアとして利用しているAWSアカウントとは異なるAWSアカウント上でデータ利用する必要があり、比較検討しましたのでその内容をご紹介します。

クロスアカウントにおけるS3で保持しているデータの利用方法

S3にはデータの参照やコピー方法が多数あり、全てを網羅するとそれだけで長くなってしまうので、今回は以下のシチュエーションで利用する前提でいくつか方法を考えてみます。

データを保持しているアカウントとは別のAWSアカウント上のAthenaによるクエリ実行でデータを取得させる
どちらのアカウントの話をしているのかわかりにくくなるため基盤側アカウントと利用側アカウントで表記します。

前項で複数の方法を挙げてみましたので、それぞれについて比較・検討していきます。具体的な設定方法の記載はしておりませんので、実際に利用する場合には公式ドキュメントなどを参照し実施するようにしてください。

個人的にですが、一番メジャーでかつ設定が容易な方法だと思います。データを保持している基盤側アカウントがアクセス制御を行うため管理体制として正常に機能する状態が実現できます。

ほぼ、S3バケットのバケットポリシーを利用したアクセス許可と同じ内容で余計なアクセスポイントを作成することによって管理するリソースが増えているように感じるかもしれません。

ただ今回は利用先が1アカウントの前提で記載していますが、データ基盤で利用しているS3は他のAWSアカウントでも利用するシチュエーションは十分に考えられます。都度S3バケットのバケットポリシーを変更するのはミスをする可能性もあり他のアクセス制限に影響が発生する場合も考えられます。

その点でS3 アクセスポイントを利用することによりアクセスポイント側でアクセス制御が行えるため上記のようなリスクを回避することができます。

こちらもS3 アクセスポイントを利用しますが、作成するアカウントが利用側アカウントになっています。

この案の特徴としては利用側アカウントにアクセスしポイントのリソースが作成されているため、どのバケットに対してのアクセスが行える設定がされているのかを知ることができるところにあると思っています。

アクセス制御自体は基盤側アカウントで行いますのでアクセス管理が煩雑になるというリスクは発生します。

今回の利用方法であればデータをコピーするメリットがなく以下のデメリットがあるため、検討はしましたが、データのコピーを行う方式自体合わないと判断しました。

今回は利用側アカウントにS3 アクセスポイントを作成するを選択しました。

データ基盤側のデータは利用するがAthenaを介した方法のためその参照データがどこにあるか重要ではありません。ただし、AWS Glue crawlerを利用したスキーマの自動生成を行いたいためS3のどこに該当のファイルを配置しているかを把握した上で利用するニーズがありました。

(アクセスポイントを利用するとマネジメントコンソールでデータの構成を参照することができる) 上記のような理由により、利用側アカウントにS3 アクセスポイントを作成し参照管理する方式としました。

Amazon S3はオブジェクトストレージとして様々なシチュエーションで利用することができるサービスだと思います。

その結果として多数の機能、連携できるサービスも多岐にわたっているため利用時に何を採用するべきかは悩むポイントでもあります。

今回ご紹介した方式や判断については全てに通用するものではありませんが、利用用途に沿った調査と判断をした例として参考になれば幸いです。