OpsWorksで自分で作成したVPCを利用する

これまでデフォルトVPCしか使った事がなかったんですが、今回お客さん先で1つのAWSアカウントで複数プロジェクトを進める事になったので各プロジェクト(OpsWorksのスタックに概ね該当)で固有のVPCで運用しようと考えました。

1つのAWSアカウントで複数のプロジェクトを運用していく場合にはVPCは必須ですね。VPC自体案外簡単ですし、VPC間の連携もピア接続で手間なくできます。今回ピア接続も含めて手順をまとめました。

VPCを独立させるメリット

VPCを環境ごとに独立させる事で下記のメリットがあるように考えています。

AWS上のアクセス権の管理性が良くなる

VPCを独立させるとVPC毎にアクセス管理する事ができるようになります。環境 = VPCで分けていれば対応するアクセス権の管理も分かりやすくなります。たとえば下記のようなポリシーを設ける事もできます。

AWSで特定のVPC下での操作の許可するIAM Policy

セキュリティグループを独立させられる

セキュリティグループはVPC毎に独立します。仮にデフォルトVPCを複数のチームで共有して利用するようになった場合、セキュリティグループが共有されやすい状態になるため、たとえばルール変更等によって違うチームの環境が突然動かなくなる等のリスクがあります。VPCを独立させる事によってそのリスクが軽減されます。

考えられるデメリット

VPC間の連携が多い場合はピア接続する必要があるため、ピア接続のデメリットがそのままデメリットになります。

  • ピア接続上限数
  • ピア接続の料金

パブリックIPアドレスを利用した場合や、異なるアベイアビリティゾーン間のデータ転送と同じ料金(2015年7月現在$0.01/GB)が適用されます。

ピア接続に関するリスクに関しては下記の最後にまとまっています。連携するアプリケーションの数が多い・転送が大きい等の場合には同一のVPCを複数のアプリケーションで共有する等も検討すると良いと思います。

異なるAWSアカウントでのVPCピア接続を試してみた

VPCの構築手順

下記の操作はAWSマネジメント・コンソールのVPCの中で行います。

VPCの作成

VPCを作成します。ネームタグには環境を識別しやすい名称(例: blog等)を、CIDRは10.1.0.0/16等のCIDRを入力します。このCIDRがVPC毎にユニークになっていないとピア接続で連携できなくなってしまうため重複しないように注意しましょう。10.1.0.0/16が既に他の環境で利用されていれば10.2.0.0/16にすると良いと思います。

vpc_vpc1.png

VPCのDNSホスト名を有効にする

デフォルトだとDNSホスト名の箇所が「いいえ」になっています。

vpc_vpc2.png

これを「はい」に変更します。

vpc_vpc3.png

サブネットの作成

次にサブネットを作成します。

vpc_subnet1.png

ネームタグには環境を識別しやすい名称(例: blog-a)を使用します。AvailabilityZoneを分けてサブネットを作るため、ap-northeast-1a, ap-northeast-1cなのでそれに因んでつけると分かりやすいと思います。

VPCには前項で作成したVPCを指定します。

CIDRはap-northeast-1a用のサブネットにはたとえば10.1.1.0/24、ap-northeast-1c用のサブネットには10.1.2.0/24等を指定します。

サブネットの自動割当パブリックIPを有効にする

デフォルトだと自動割当パブリックIPが「いいえ」になっています。

vpc_subnet2.png

これをチェックを入れて有効に変更します。

vpc_subnet3.png

このサブネットの作成をap-northeast-1a用とap-northeast-1c用で2回行ってください。

インターネットゲートウェイの作成

次にインターネットゲートウェイを作成します。これはVPCがインターネットに接続するのに必要な設定になります。

vpc_igw1.png

ネームタグには環境を識別しやすい名称(例: blog)を使用します。

インターネットゲートウェイをVPCにアタッチする

作成したインターネットゲートウェイを先ほど作成したVPCにアタッチします。

vpc_igw2.png

ルートテーブルを編集する

ルートテーブルで作成したVPCに紐付いてるものを選択し、ルートの追加を行います。

vpc_igw3.png

送信先に「0.0.0.0/0」を、ターゲットに先ほど作成したインターネットゲートウェイを指定します。テキストボックスのようになっていますが選択式で指定できます。

OpsWorksのスタック追加

独自のVPCを利用してもOpsWorksの利用方法は基本的に変わりませんが作成時の注意点を記載しておきます。

vpc_opsworks1.png

作成時にVPCに先ほど作成したVPCを、Default Subnetに作成したサブネットのいずれかのサブネットを指定します。

※ OpsWorksのセキュリティグループもスタック作成時にVPCに追加されます。追加したくない場合はAdvancedの設定で追加しないように設定します。

レイヤー追加時の注意点

デフォルトVPC以外のVPCを選択した場合、Public IP addressesが初期状態「No」になっていますので、これを「Yes」に変更し保存します。

vpc_opsworks2.png

これが「No」のままだとインスタンスがうまく生成されませんでした。

VPC間のピア接続

VPCピア接続の作成

VPC間で連携が必要な場合はピア接続を作成し連携を行います。「ピアリング接続」というメニューから新作成します。

vpc_peer1.png

ネームタグには接続を識別しやすいように「環境A – 環境B」といった形で名称を入力します。

ピア接続するローカルVPCには、接続元のVPCを選択します。同じAWSアカウント内でピア接続する場合にはどちらのVPCもローカルなので少し分かりづらいですが、その場合はどちらでも構いません。

アカウントは、同じAWSアカウント内のVPC間接続であれば自分のアカウントを指定します。

VPC IDに接続先のVPCを選択します。同じAWSアカウント内のVPC間接続であれば、「ピア接続するローカルVPC」で指定したものとは異なるVPCを指定することになります。

リクエストの承諾

ピア接続を作成するとピア接続のリクエストが送信されます。これをピア接続の画面で承諾します。

vpc_peer2.png

ルートテーブルの修正

接続を行う2つのVPCでそれぞれルートテーブルを修正します。

VPC1(CIDR: 10.1.0.0/16)からVPC2(CIDR: 10.2.0.0/16)があった場合、まずVPC1は下記のようにVPC2のCIDRを新しくルートに追加します。

vpc_peer3.png

送信先に相手となるVPCのCIDRを、ターゲットにpcxから始まる先ほど作成したピア接続を選択します。

次にVPC2は下記のようにVPC1のCIDRを新しくルートに追加します。

vpc_peer4.png

セキュリティグループを修正する

ピア接続の接続元のIPの場合にアクセスできるようにレイヤーやRDSに設定されているセキュリティグループを修正します。

vpc_peer5.png

上図はRDSへのアクセスを許可する場合の設定で3306ポートで、カスタムIPが「10.2.1.0/24, 10.2.2.0/24」の場合にアクセスできるように設定しています。このカスタムIPにはサブネットのCIDRを指定します。カンマ区切りでカスタムIPを設定すると指定された分だけルールが追加されるので便利です。

参考URL