AWS QuicSightを使用して、開発したwebアプリのデータ集計・ダッシュボード化を進めています。
社内では開発アプリごとにアカウントを使い分けているため、開発したwebアプリを管理するAWSアカウントでQuickSightを作成する必要がありました。
ただ、QuickSightは、AWSアカウントとは別にQuickSightアカウントを作成する必要がありますし、QuickSightアカウントごとに固定課金＋従量課金となるのが懸念点でした。
そこで、「QuickSightは、主で利用しているAWSアカウントで統一して別アカウントのRDS等に接続する」という手法を採用することにしました。
この記事では、QuickSightアカウントを作成したAWSアカウント側から、別のAWSアカウントで管理しているRDSに接続する方法を紹介していきます。
なお、RDSアカウント側のVPCやRDSはすでに構築済みとして進めていきます。
目指すべき姿
今回は、VPCピアリング接続を使用して、QuickSightから別アカウントのRDSに接続していきます。
アーキテクチャ図は以下のようなものを計画しています。
※注 最終的には形変わります。
主アカウント（以下、QuickSightアカウント）にVPCとサブネット、そしてVPCピアリング接続を作成します。
開発アカウント（以下、RDSアカウント）では、すでに構築済みのVPCに、QuickSightアカウントが作成したVPCピアリング接続を受け入れていきます。
最終的には、もう少し複雑なアーキテクチャ図になりましたが、構成は大きく変わりません。
次の章から、実際の手順を紹介していきます。
VPCとピアリング接続の作成
まずは、QuickSightアカウント側でVPCとVPCピアリング接続を作成していきます。
今回は、コンソール画面（GUI）から作成していきます。
VPCの作成
AWSコンソールからVPCサービスにアクセスし、新規作成をしています。
VPC作成のGUI画面、いつの間にかVPCだけでなく、サブネットやルートテーブルといった付随する機能が一気に作れるようになったんですね。これは便利！！
VPCの作成の注意点として、QuickSightからVPC接続する際の要件にマルチAZ構成として、2つ以上のサブネットIDが必要になりました（AWSドキュメント記事はこちら）。
したがって、今回は、アベイラビリティゾーン（AZ）を2つ作成して、サブネットはプライベートサブネットを2つ作成しました。
※パブリックサブネットは不要なので構築していません。
VPCピアリング接続の作成
次に作成したVPCにVPCピアリング接続を設定していくのですが、接続するRDSアカウント側のAWSアカウントIDとRDSが属しているVPC IDをしっておく必要があります。
一度、AWSアカウントを切り替えて、AWSアカウントID（数字12桁）と該当するVPC IDをメモ帳などに記録しておきます。
※なお、AWSアカウントをこの後も何度か切り替えることになるので、Google Chormeを別アカウントで複数立ち上げておくとした方が便利ではあります。
私は、操作ミスもあったりしたので、何度もアカウント切り替えるハメになりました。
さて、RDS側のAWSアカウントIDとVPC IDがわかったので、ようやくピアリング接続の設定ができるようになりました。
QuickSightアカウント側でログインしなおして、VPCサービスのサイドメニューからVPCピアリング接続を選択して、新規作成します。
接続側で承諾
VPCピアリング接続を作成すると、ステータス状態が以下のように、RDS側のアカウントで承諾待ちという状態になっています。
RDSアカウントで、このVPCピアリング接続を承諾する必要があります。
RDSアカウントでサインインしなおして、VPCサービスからピアリング接続にアクセスするとQuicSightアカウント側で作成したピアリング接続が反映されていました。
該当するVPCピアリング接続を選択して、アクションから『リクエストを承諾』します。
ルートテーブルの設定
VPCピアリング接続は設定しましたが、現状ではVPCピアリング接続がそれぞれのVPCに置かれているだけです。
ルートテーブルが設定されていないので、それぞれのアカウントでCIDR宛先が互いのVPCピアリングに向くように設定していく。
ここで、QuickSight側のVPC CIDRとRDS側のVPC CIDRを互いに設定するので、それぞれをメモしておく必要があります。
RDSアカウント側のルートテーブル設定
まずは、現在RDSアカウントでログインしている状態なので、RDS側アカウントから設定していきます。
RDSアカウント側では、すでにいくつかのルートテーブルが作成されていましたが、今回は新たにルートテーブルを作成しました。
VPCサービスからルートテーブル作成を行い、接続するVPCをRDSが配置しているVPCを設定します。
ルートテーブルができたので、ルートを編集して、QuicSight側のVPC CIDRとピアリング接続を追加していく。
初期値は、自身のVPC CIDRのみが登録されているので、ルートを追加して、送信先（QuickSight側VPCのCIDR）とターゲットはピアリング接続を選択して、該当するIDを選びます。
QuickSightアカウント側のルートテーブル設定
次は、QuickSightアカウント側のルートテーブルを設定していきます。
まずは、アカウントを切り替える前に、RDSが配置されているVPCのVPC CIDRが必要になるので、メモ帳に記録しておきます。
QuickSightアカウントに再度サインインしなおしました。
QuickSightアカウント側はVPC作成時に自動的に作成されてルートテーブルのうち、サブネットから繋がっている二つのルートテーブルを編集します。
QuickSightからの接続ための設定
VPCは作成できたので、QuickSightからVPC経由で接続するように設定していきます。
QuickSightのアップデートにより、マルチAZ構成などが必須になっていた紹介しましたが、それ以外にもIAMロールなどいくつか不足している設定があったので、追加設定していきます。
なお、QuickSightからVPC接続するために必要な設定は以下の通りです。
- VPCのマルチAZ（2つ以上のサブネット）・・・構築済み
- VPCピアリング接続とルートテーブル・・・構築済み
- IAMロールの設定
- セキュリティグループの設定
3と4がまだ未設定なので、引き続き必要な設定項目を構築していきます。
IAMロールの作成
まずは、QuickSightに必要な実行ロールを作成していきます。
QuickSightに必要な実行ロール（IAMロール）もQuickSightのバージョンアップを紹介する公式ドキュメントに記載がありました。今回はこちらに準拠してIAMポリシーとIAMロール割り当てていきます。
IAMロールに必要なポリシーはマルチAZ構成の際にも紹介したAWSドキュメントに記載がありましたので、こちらを参考にします。（AWSドキュメント記事はこちら）
まずは、IAMロールの作成からカスタム信頼ポリシーを選択して、QuickSightに対するIAMロールを設定します。
カスタム信頼ポリシーは、公式ドキュメントのコピーですが、以下の通りです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "quicksight.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
「次へ」と進み、AWSドキュメントに記載があったEC2に対する許可ポリシーを追加していきます。
と思いましたが、まだ許可ポリシーを作成していないので、ポリシー作成から先に作っていきます。
別タブが開き、許可ポリシーの作成画面になるので、AWSドキュメントに記載のポリシーをコピペしておきます。
先にIAMポリシー作っておいてから、IAMロールの作成画面でポリシーを選択するという手順の方がわかりやすいかもしれません。
別タブで開くので、どっちを編集中か迷ってしまうこともありました。というよりなり、何度か間違えました、、、、
EC2のアクションに対する許可が必要になるようです。
ここも公式ドキュメントのものをコピーしてそのまま使います。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
IAMロールのタブに戻り、作成したIAMポリシーをアタッチしました。
「次へ」と進み、後は分かりやすい名前を付ければQuickSightに対するIAMロールの作成が完了です。
なお、私のようにIAMポリシーを後から作った場合は、IAMロールのタブでIAMポリシー選択画面で再読み込みする必要があります。
セキュリティグループの設定
次に不足していた設定として、QuickSight側、RDS側それぞれにセキュリティグループを設定してお互いの通信を通す許可が必要になります。
QuickSight側はセキュリティグループがそもそも作成できていないので、作成するところから、RDS側は既にあるセキュリティグループにインバウンドルールを追加していきます。
QuickSightアカウント側のセキュリティグループの作成
まずは、QuickSightアカウント側にセキュリティグループを作成していきRDSからの通信を許可していきます。
セキュリティグループを作成して、インバウンドルールに「すべてのTCP」、ソースを「カスタム」として、RDSのVPC CIDRを入力していきます。
ルートテーブルで設定したものと同じです。
RDSアカウント側のセキュリティグループの更新
次に、再びアカウントを切り替えて、RDSアカウント側のセキュリティグループを更新していきます。
RDS側は既にセキュリティグループ作成済みなので、インバウンドルールを更新していきます。
QuickSightのVPC接続
ようやく、QuickSightからVPC接続するための準備ができました。
やっと、QuickSightからVPC設定に着手していきます。
まずは、QuickSight側アカウントでQuickSightにアクセスします。ユーザーアイコンから「QuickSightの管理」をクリック。
その後、サイドメニューから「VPC接続の管理」を選択してVPC接続の追加を行います。
VPC接続の設定で、これまで作成したVPC IDやIAMロール、セキュリティグループなどを設定していきます。
ただ、ここでVPC IDなどを設定するときは、ランダム生成されているVPC IDしか表示されず、検索が非常に困難です。
AWSコンソールを開くためのリンクが配置されているので、別タブでVPC IDを確認しながら設定すると楽になります。
データセット接続
最後に、設定したVPC接続を使用して、RDSに接続するデータセットを作っていきます。
QuickSightのトップページに戻り、サイドメニューの「データセット」→「新しいデータセット」から接続していきます。
データセットの元になるソースは、MySQLやPostgreSQLなど、RDSで使用しているEngineを選択します。
ここにRDSとありますが、RDSから選べるものは自アカウントで作成していているRDSとなりますので、別アカウントの場合はengineを選択します。
今回は、MySQLなので、以降MySQLで設定していく。
接続タイプという箇所で、作成したvpc接続が選べるようになりますので、vpc接続を選びます
その他のエンドポイントやテーブル名、ユーザー名、パスワードはRDSの設定と同じものです。
エンドポイントがわからない場合は、RDSアカウントでログインした直して、RDSサービスから確認することができますので、またメモ帳に残しておくと便利です。
あとは、「接続を検証」ボタンでつながるか確認して、データソースを作成とするRDSのテーブルやビューをデータセットして作成することができます。
また、RDS側でQuickSightに表示するためのビューを作成していないので、情報は限定的ですが、無事接続できグラフ描画できました。
最終的なアーキテクチャ図
色々なブログやドキュメントを参考にしましたが、途中QuickSightのアップデートがあったことからマルチAZ構成など、躓く場面もありました。
ただ、悩みはしましたが、複数のサイトを参考にすれば、VPCピアリング接続自体は投げれ通りに行うことができたと思います。
当初想定したより、やや複雑にはなりましたが、アーキテクチャ図は以下のようになりました。
参考サイト
今回、QuickSightからVPCピアリング接続により、別アカウントのRDSに接続するために、以下のサイトを参考にしました。
QuickSightのバージョンアップがあったことにより、これら複数サイトをトータルして、環境構築していく必要がありました。
VPCピアリング接続に関するもの
QuickSightのバージョンアップに関するもの
おわりに
AWSを使っていくと、プロジェクトごとにアカウント切り替えたりすることが多いので、用途に応じクロスアカウントの設定は色々な箇所で必要になるなと感じました。
今回は、RDSのインバウンドルールなどもあり、やや面倒でした。通常のスイッチロールであればもっとすんなり行けそうですね。
ただ、アカウントの切り替えが面倒くさいと思いました。
chromeブラウザを別アカウントで複数開くことと1Passwordを利用したMFA認証の自動入力もありましたが、それでもやや面倒です。
マネコンからでもロールの切り替え簡単にやっていくことを次チャレンジしてみます。
ポチップ
コメント