こんにちは、まつほです。
前回、Amazon Quickでコスト分析をしてみる記事をアップしました。
しかし、どうせなら都度CSVを取得するのではなく、Auroraに蓄積したコストデータを使って分析したい！
というわけで今回は、Amazon QuickからAuroraをデータソースとしてコストデータを取り込んでみます。
同じアカウントにあるAuroraへ接続するだけならそれほど難しくありませんが、今回はクロスアカウント構成にする必要があり、いくつかひっかかりポイントがあったので、その記録です。
最終的にやりたいこと
最終的にやりたいのは前回と同様、AIを活用したコスト分析をはじめとするFinOps活動です。
AWSのコスト情報をAmazon Quickに取り込む方法はいくつかありますが、より高度な分析を行うには、継続的に蓄積されたデータを利用できる環境が必要です。
そこで、以下のような流れでAWSのコスト情報をFinOps活動につなげていきます。
今回の記事で扱うのは、上記のうち、Aurora → Amazon Quickの導線を作る部分です。
今回検証する構成について
今回検証する構成は以下のとおりです。
今回は、AWS PrivateLink/VPC Latticeのリソースゲートウェイ（Resource Gateway）を利用して、クロスアカウント構成のAuroraへの接続を検証します。
接続方式の比較や選定については、弊社の間世田が以下の記事で紹介しています。気になる方はこちらもご覧ください。
AWSネットワークにおけるSaaSへの接続方式まとめ 〜PrivateLink編〜
https://blog.usize-tech.com/saas-network-privatelink/
Amazon QuickからAuroraへ接続してみる
それでは、実際にAmazon QuickからクロスアカウントのAuroraへ接続していきます。
今回は、以下の順番で進めていきます。
- Aurora側アカウントの設定
- Quick側アカウントの設定
- Amazon Quickの設定
1. Aurora側アカウントの設定
まず、Auroraが存在するアカウント側で必要なリソースを作成していきます。
1-1. リソースゲートウェイ
リソースゲートウェイを作成します。
Auroraを配置しているVPCとサブネットを指定します。
1-2. リソース設定
続いてリソース設定を作成します。
当初はAuroraのリソースARNを使用してリソース設定を作成しましたが、リソースエンドポイント側に複数のDNS名が作成され、Quickのデータソース設定ではそのうち1つを指定する形になりました。
今回はQuickから利用する接続先を1つにしたかったため、設定タイプを「単一（Single）」とし、AuroraクラスターのDNS名を指定します。また、先ほど作成したリソースゲートウェイを紐づけます。
1-3. Resource Access Managerでリソースを共有
Resource Access Manager（RAM）からリソース共有を作成します。
「プリンシパルにアクセス権限を付与する」で、接続元となるQuick側のAWSアカウントIDを指定します。
1-4. セキュリティグループ
続いて必要なセキュリティグループを設定します。
■リソースゲートウェイ用SG
| ポート | ソース/送信先 | |
| インバウンド（設定なし） | ‐ | ‐ |
| アウトバウンド | TCP/3306 | Aurora用SG |
■Aurora用SG
既存のAurora用SGに以下のルールを追加します。
| ポート | ソース/送信先 | |
| インバウンド | TCP/3306 | リソースゲートウェイ用SG |
| アウトバウンド（設定なし） | ‐ | ‐ |
2. Quick側アカウントの設定
続いてAmazon Quickを利用するAWSアカウント側の設定を行います。
2-1. VPC・サブネット・ルートテーブル
エンドポイントを配置するVPC、サブネット、ルートテーブルを用意します。
既存のVPC内にエンドポイントを作成する場合は、新規作成は不要です。
2-2. セキュリティグループ
Quick側アカウントでは、リソースエンドポイント用とAmazon Quick用のセキュリティグループを設定します。
■リソースエンドポイント用SG
| ポート | ソース/送信先 | |
| インバウンド | TCP/3306 | Amazon Quick用SG |
| アウトバウンド | TCP/3306 | 0.0.0.0/0 |
■Amazon Quick用SG
| ポート | ソース/送信先 | |
| インバウンド（設定なし） | ‐ | ‐ |
| アウトバウンド（設定なし） | TCP/3306 | リソースエンドポイント用SG |
2-3. エンドポイント
VPCエンドポイントを作成します。
タイプとして「リソース」を選択し、Aurora側アカウントから共有されたリソース設定IDを選択します。
セキュリティグループには、先ほど作成したリソースエンドポイント用SGを指定します。
2-4. IAMロール
Amazon QuickからVPC内のリソースへアクセスするためのIAMロールを作成します。
3. Amazon Quickの設定
AWS側の準備ができたら、Amazon Quickから接続設定を行います。
3-1. VPC接続
Amazon QuickでVPC接続を作成します。
Quick側アカウントで用意した以下のリソースを指定します。
- VPC
- IAMロール
- サブネット
- セキュリティグループ
3-2. Auroraをデータソースとして登録
最後にデータソースを作成します。
データソースとして「Amazon Aurora」を選択し、接続情報を設定します。
接続タイプには、先ほど作成したVPC接続を指定します。
そして重要なのがデータベースサーバーです。
ここにはAuroraのエンドポイントではなく、Quick側アカウントに作成したリソースエンドポイント（Resource Endpoint）のDNS名を指定します。
実際にハマったポイント
実際に構築する中で、以下の2点にハマりました。
1. AuroraのDNS名を指定してもつながらない
一番ハマったのがここです。
最初は「Auroraに接続するのだからAuroraクラスターのDNS名を指定すればよいだろう」と考え、Amazon QuickのデータソースにAuroraのDNS名を設定していました。
しかし、何度試しても接続できません。
今回の構成ではリソースエンドポイントを経由してAuroraへアクセスするため、指定するのはAuroraのDNS名ではなく、リソースエンドポイントの関連付けDNS名でした。
DNS名を変更したところ、無事に接続できました。
2. セキュリティグループは役割ごとに分ける
当初は同じセキュリティグループを複数のリソースで使用していましたが、今回の構成では期待した通信ができませんでした。
そこで、セキュリティグループを以下のように役割ごとに分割しました。
- Amazon Quick用SG
- リソースエンドポイント用SG
- リソースゲートウェイ用SG
- Aurora用SG
それぞれのSG間で必要なTCP 3306の通信を許可する構成に変更することで、正常に接続できました。
接続結果
無事に別アカウントのAuroraをデータソースとして登録できました。
※キャプチャだけではクロスアカウント感が伝わりませんが、別アカウントにあるAuroraのデータを参照しています。
データ接続からAI分析へ
これでようやく、Amazon QuickからクロスアカウントのAuroraに蓄積したデータを参照できるようになりました。
とはいえ、今回やりたかったのはAuroraにつなぐこと自体ではありません。
ここから、コストデータの蓄積 → 可視化・前月差異分析 → AIによる増減要因分析・無駄の発見・レポート生成へと発展させていくのが本来の目的です。
今回は、そのために必要なデータ接続部分まで検証できました。
まとめ
いかがでしたでしょうか。
今回は、AIを活用したFinOps分析基盤の構築に向けて、Amazon Quickからクロスアカウントに配置されたAuroraへの接続を検証しました。
まだデータを参照できるようになった段階ですが、今後はコストデータの可視化や前月差異分析、さらにAIを活用した増減要因分析や無駄の発見、コストレポートの作成などに発展させていく予定です。