背景

Athenaが良い感じに女神様なので、他チームに展開したいと考えました。
しかし、そのまま使うとデータベースやら何やらすべて見えてしまうようで、おおっと...と思っていたら最近ワークグループという機能で実装されたらしいのでこれを使って見ました。

まとめ

ワークグループ単位でAthenaを分けられ、データベースやテーブル単位まで（今回はやってませんが）、アクセス管理が出来るようになり、安心してチームごとにAthenaが使えるようになって熱いです。
またチームごとに容量制限が行えるので、心理的なハードルが低い状態で試行錯誤がしやすいのが熱いです。

流れ

ワークグループを作成し、IAMで適用します。

ワークグループの作成

Athenaの画面上部のタブというかメニューの「ワークグループ：」をクリックするとワークグループの画面に移動できます。「ワークグループを作成する」から作成できます。

主な設定項目

◆ワークグループ名

変更出来ないので少し注意。いやかなり注意。

◆説明

日本語で書けるのが地味に嬉しいです。

◆クエリの結果の場所、暗号化

クエリを保存する場所や暗号化を指定できます。
OutputLocationなどを指定しない場合に指定した場所にクエリ結果が出力されます。

◆クライアント側の設定を上書きする

こちらにチェックをすることで、上述の「クエリの結果の場所、暗号化」が強制的に適用されます。
試したところ、ようは以下のような挙動になりました。

↓設定ONの挙動

OutputLocationを指定してもスルーされ（エラーにはならない）、ワークグループで指定した場所にクエリ結果が出力される

↓設定OFFの挙動

OutputLocationを指定すると、ワークグループの設定を無視してOutputLocationで指定した場所にクエリ結果が出力される。

今回やろうとしていることを考えると、設定ON一択ですね。

データの制限

一度ワークグループを作成後、「詳細を表示する」から「データ使用状況の制御」というタブに行くことで、そのワークグループで実行（スキャン）出来る最大データサイズを指定することができます。

この機能により、他チームに展開するうえで「えっ、ミスるとお金掛かるんでしょ・・・？」みたいなハードルを下げることが出来るのは相当熱いです。
実際、SQL自体をすらすら書ける人は多くとも「データのスキャン量まで事前に正確に考えてSQLを書ける人」となるとデータ構造やデータ設計側のスキルを要する事となり、相応にハードルが上がると思います。

IAMまわり

IAMでワークグループ用ポリシーを作成する

こちらを参考にポリシーを作成します。
リソースを「指定」とし、上記で作成したワークグループを指定します。
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/workgroups-iam-policy.html
基本的にこの通りで問題ありません。
記載の通り、arnにはリージョンとアカウントも必要です。

arn:aws:athena:<region>:<user-account>:workgroup/<workgroup-name>

IAMでワークグループ用ポリシーに、データベースへのアクセス制御を入れる

上記の手順の他に実際にデータベースやテーブルへのアクセスを制御するためには AWS Glue側のポリシーが必要となります。
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/fine-grained-access-to-glue-resources.html

そんな感じで、以下のような「特定のワークグループの特定のデータベースのみ操作が行える」ポリシーを作成しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "glue:UpdateDatabase",
                "glue:CreateTable",
                "glue:GetTables",
                "glue:DeleteTable",
                "glue:DeletePartition",
                "glue:GetTable"
            ],
            "Resource": [
                "arn:aws:glue:<region>:<accountid>:table/<データベース名>/*",
                "arn:aws:glue:<region>:<accountid>:database/<データベース名>",
                "arn:aws:glue:<region>:<accountid>:catalog"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "athena:*",
            "Resource": "arn:aws:athena:<region>:<accountid>:workgroup/<ワークグループ名>"
        }
    ]
}

これで、やろうとしていたことが出来るようになりました。

その他、絶妙にハマったこと

IAMの反映ラグ

IAMのポリシーの反映には絶妙に（～数分？）のラグがあるようで、これだ！と思った反映をしたあとは一旦コーヒー休憩などをして確認すると良いです。比較的即時反映の時もあるような気がするのでハマります。また、キャッシュを持っているようで、連続で実行すると成功→失敗→成功みたいな感じにもなるようです。

Athenaの画面へのIAMの反映

Athenaの画面に対しては、時間を置いてもIAMの設定が反映されない現象が起きました。
これはサインアウト→再度サインインによって見えるようになりました。

Amazon AthenaのワークグループとIAMによるデータベース単位のアクセス管理をやってみた

背景

まとめ

流れ