CI部5課の山﨑です。
今回は自身で利用されるシナリオを考えて異なるアカウント間でVPCピアリング接続をしてみました。
シナリオ
ある企業の経営企画室は今後の経営戦略を考えていく上で、伸び悩む営業部門にメスを入れたいと考えている。そこで営業部門の事業実態を第三者の視点から分析・業務改善を行うために営業情報が蓄積されているデータベースにアクセスしたいと考えている。当企業ではAWSクラウドを利用しており、経営企画室と営業部門でそれぞれ別のアカウントを使用している。
構成図
以下、今回構築する環境の構成図です。実際の企業でもっと複雑な環境だと思いますが、今回の構築にあたって不要な部分は省略しています。
構築
VPCピアリング接続の作成
VPCのコンソール画面から[ピアリング接続]を選択します。 VPCリクエスタはVPCピアリングの接続元、今回だとアカウントA（経営企画室）でピアリングさせたいVPCのIDを入力します。
アカウントは[別のアカウント]を選択します。そして、アカウントIDを入力します。リージョンは東京リージョンを設定し、VPCアクセプタにはピアリング先のVPCのIDを入力します。
【アカウントA（経営企画室）】
これでピアリング接続が作成されました。ステータスは[承諾の保留中]となっています。ステータスを利用可能にするためにはピアリング先、つまりアカウントB（営業部門）でピアリング接続を承認する必要があります。
【アカウントB（営業部門）】
アカウントB（営業部門）のアカウントに移動してきました。先程と同様にVPCコンソール画面から[ピアリング接続]を選択すると、ピアリング接続が作成されておりステータスも[承認の保留中]となっています。
[アクション]から[リクエストの承諾]を選択します。 
これでピアリング接続の作成は完了です！ しかし、これだけだとまだVPC間で通信することはできません。VPCのルートテーブルの設定が必要になります。
VPCのルートテーブルの設定
先程の[VPCピアリング接続リクエストの承諾]の画面中に[ルートテーブルを今すぐ変更]とありますので選択します。するとアカウントB（営業部門）のVPCのルートテーブル設定画面に遷移します。
アカウントB（営業部門）のVPCのルートテーブル
送信先にはアカウントA（経営企画室）のVPCのCIDRを設定します。ターゲットは[Peering Connection]を選択し、先程作成したピアリング接続のIDを設定します。
アカウントA（経営企画室）のVPCのルートテーブル
送信先にはアカウントB（営業部門）のVPCのCIDRを設定します。ターゲットは[Peering Connection]を選択し、先程作成したピアリング接続のIDを設定します。
これでVPCのルートテーブル設定は完了です！！ しかし、アカウントB（営業部門）のセキュリティグループでアカウントA（経営企画室）からの通信は許可されていないのでまだ通信ができません
セキュリティグループの設定
RDSのコンソール画面からVPCのセキュリティグループに遷移することができます。
インバウンドルールを追加します。ここでソースにはセキュリティグループIDを入れていますが、これはアカウントA（経営企画室）のEC2インスタンスにアタッチしているセキュリティグループです。これにより指定したセキュリティグループに所属しているインスタンスのみ通信を許可することができるようになりました。
通信確認
まずは、アカウントA（経営企画室）のEC2インスタンスにログインします。MySQLをインスタンスにインストールした後、mysqlコマンドを叩くと無事にアカウントB（営業部門）のRDSに接続することができました！！ RDSインスタンスへの接続方法については下記ドキュメントをご覧ください。 MySQL データベースエンジンを実行している DB インスタンスに接続する
まとめ
今回は別アカウントに存在するRDSに接続するというシナリオのもとVPCピアリング接続を設定してみました。 他にも同一リージョン間でのVPCピアリング、異なるアカウントかつ異なるリージョン間でのVPCピアリング等、いくつかピアリング接続のパターンはありますが、 ベースは今回検証した内容と変わらないかなと思います。また今回はRDSへ接続しましたが、EC2インスタンスに接続する際も手順は大きくは変わらないかなと思うので、様々なケースに応用させていきたいと思います。
