VPC Peering

AWSの新機能「Inter-Region VPC Peering」でリージョン間VPCピアリングしてみた

国内・海外問わず旅行好きなSIOS Coati開発担当、沼野井です。

 

さて、先日のAWS re:invent 2017では例によってたくさんの新機能がお披露目されましたが、その中の1つ、

Inter-Region VPC Peering

で、リージョン間のVPCピアリングが可能になりました。

今のところ、できるリージョンは

  • 米国東部(バージニア北部)
  • 米国東部(オハイオ)
  • 米国西部(オレゴン)
  • 欧州(アイルランド)

の4つです。残念ながら東京は入ってないんですが、AWSのことなのできっとすぐにできるようになるでしょう。

というわけで、今回はこのInter-Region VPC Peeringを試してみました。

 

ピアリング接続を作成してみる

まず、バージニアとオハイオにVPCを作ります。

バージニア

 

 

オハイオ

 

で、バージニアの方からオハイオにピアリング接続を作成してみます。

バージニアの方で、ピアリング接続の作成画面を開きます。

リージョンを選択するカラムが追加されていますね。オハイオを選んで作成!

成功! 

あとは、同一リージョン内のVPCピアリングと同じようにオハイオ側が承諾すれば完了です。

 

 

無事できました。すごいですね。

 

通信してみる

せっかくなんでインスタンス作って通信してみました。

バージニア

 

オハイオ

 

ping飛ばしてみました。

東京リージョン内の2つのVPCピアリングで接続した2つのインスタンスでのping結果を速度比較してみます。

 

おっ意外と差がありますね? 

まあ、条件などを考慮した厳密な測定では全くないのでご参考、ではありますが、シビアに速度を気にするアプリを開発されている方は、計測・検証が必要かもしれません。

 

CLIで作成してみる

さて、GUI(Management Console)では無事作成できたリージョン間ピアリングですが、CLIではできるんでしょうか?

先ほど作成したVPC Peeringをいったん消して、CLIで再度作成してみましょう。

VPCピアリングを作成するコマンドは aws ec2 create-vpc-peering-connection–peer-region ですが、–peering-regionオプションでピアリング先(アクセプタ)のリージョンを指定すればよいようです。

バージニアに作成したインスタンスでCLIを実行してみます。

DEKITA! CLIもばっちりです。

 

Ansibleでできるか調べてみる

ansibleはどうかな? と思って調べましたが、さすがにまだ未対応のようです。

ec2_vpc_peerモジュール

ピアリング先(アクセプタ)のリージョンを指定することができません(注:上記ページ内のExampleのregionは、ピアリング元(リクエスタ)のリージョンの指定です)。

あせらず、でも期待して待ちましょう!

 


リージョン間ピアリングは使い所が多そうです。SIOS Coati世界展開も近いかも知れません(!?)

この調子でリージョン間ピアリングを通して物理的に人間の輸送ができるようになったりしませんかね? 海外旅行が捗るんですが。
ジェフ・ベゾスさんならあと20年くらいでやってくれそうな気もします。

ansibleによるEC2・VPC環境構築(その3)

食欲の秋に(体重的な意味で)危機感を覚える Coati開発チーム 沼野井です。
でも秋の味覚を食べないという選択肢はないですよね!

 

前回までのあらすじ

ansibleで、

 

VPCと、それに紐づく サブネットルートテーブルセキュリティグループを作ったCoatiだった・・・

 

というわけで、前回に続いて、ansibleでEC2・VPC環境を構築していこうと思います。

今回は、

  • 前回作成したSIOS VPC内に EC2インスタンスを作成
  • 前回作成したSIOS VPCとお客様VPCをPeeringで接続

します。

 

Playbookの内容

Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成と、変数定義をしているall.ymlの内容をもう一回掲載します。

  • ディレクトリ構成

 

group_vars/all.yml

 

 

インスタンス作成

作成したVPC内にEC2インスタンスを作成するplaybook, setup_ec2.ymlの中身を見ていきます。

順にみていきます。

ec2_remote_factsはAWS内の(複数の)インスタンスの情報を集めるモジュールです。
IPアドレス・サブネット名など多種のFilterを設定して検索することができます。
今回は、SUBNET_IDのサブネット、EC2_PRIVATE_IPのIPアドレスのインスタンスが、環境内に既に存在しているかどうかをチェックしています。

続いて、AMIの検索です。
Coati開発チームでは、Coati Manager用のAMIをあらかじめ用意していて、タグ Role=CoatiManager をつけています。ec2_ami_findモジュールを利用して、タグをキーにしてAMIのIDを取得します。

いよいよ、インスタンスの作成です。そのものズバリな ec2モジュールを使います。
パラメータはAWS Management ConsoleでEC2インスタンスを作成する際にお馴染みな面々を指定していきます。imageには、さきほど検索したAMIのIDを指定しています。

instance_tags: で Name=名前, Role=CoatiManager、というタグ付けもしています。

最後の

は、ec2.instancesがある場合にはインスタンスの作成をしない、という条件判定です。
一番最初に ec2_remote_factモジュールで同じIPアドレスとサブネットのインスタンスを検索したときに、もし既に存在している場合には変数ec2.instancesなんらかの値が入っているはずですので、その場合にはインスタンスの作成は行わないようにしています。

 

VPCピアリング接続

VPCピアリングを行うplaybook, vpc_peering.ymlです。

 

ec2_vpc_peerモジュールを使い、接続するVPCをそれぞれ指定して、VPCピアリング接続を行います。
このplaybookを実行したあと、お客様に接続を承認していただくと、晴れて両VPCがピアリング接続されることになります。

ここまでの結果

ついに、Coati環境が完成しました!

いかがでしたでしょうか?
今後も、役に立ちそうなplaybookを紹介していく予定ですので、よろしくお願いします。

 

『SIOS Coatiの申し込みから利用開始までのプロセス』更新のお知らせ

こんにちは、SIOS Coatiチームの黒田です。
前回の記事で、『AWS認証方式の変更のお知らせ』を紹介しましたが、AWS認証方式の変更により
『SIOS Coatiの申し込みから利用開始までのプロセス』を更新しましたので、再度、Coatiの申し込みから利用開始までのプロセスをSTEP1~7を紹介したいと思います。

Coatiの申し込みから導入までのプロセス
STEP1 Coatiの申し込み
STEP2 ヘルプデスクアカウントの登録
STEP3 VPC Peeringリクエストの承認
STEP4 ルートテーブルとセキュリティーグループの設定
STEP5 AWSの認証情報の登録
STEP6 監視対象のインスタンスでスクリプト実行
STEP7 Coatiの利用開始

続きを読む