Amazon Virtual Private Cloud (VPC) by Default

VPC for Everyone!

2013年4月4日

アマゾンデータサービスジャパン

ソリューションアーキテクト 安川 健太

VPC for Everyone! --EC2-VPCがデフォルトに--

AWSパブリック

クラウド環境 EC2-Classic

EC2-VPC

AWSパブリック

クラウド環境

EC2-VPC

従来のインスタンス起動

• VPCか否かを選択

• デプロイ先AZ / Subnetを選択

EC2-VPCがデフォルトの場合

• VPCか否かを選択

• デプロイ先AZ / Subnetを選択

選択しなければ

EC2-Classic

常にEC2-VPC！

2013年3月12日発表！

EC2-VPCがデフォルトの場合の動作

初めてインスタンスを起動する際の動作

1. Default VPCが自動作成される

2. 各AZにDefault Subnet (public)が自動作成される

3. 選択したAZのDefault Subnetにインスタンスがデプロイされる

4. EC2インスタンスにはPublic IPアドレスがアサインされる

Default VPC (172.31.0.0/16)

デフォルトのデプロイ先VPC

Default Subnet

AZごとに作成されるデフォルトのデプロイ先サブネット

大きさは/20 (4096 IPs)

Public IPアドレス

インスタンスに動的割当て

されるGlobal IPアドレス

VPC for Everyoneがもたらすのは

EC2-VPCが適用されたお客様には

• VPCの進んだネットワーク機能を今までと同様の使い方で提供

これまでと使い方が変わってしまう？

AWSを使い始めるためにVPC

を学ばないといけない？

No!

いわば、EC2サービスのアップグレード！

EC2-VPCの適用で可能になること

VPCでは出来て、EC2-Classicでは出来なかった全て

• 静的IPアドレス設定

• 複数IPアドレス

• 複数ネットワークインターフェース

• セキュリティグループのメンバーシップの動的変更

• セキュリティグループによるOutboundフィルタリング

• NACL

• …

VPC 自体の恩恵

• 複数Subnetの利用

• Private SubnetにPrivate接続してEC2を利用

いつから誰に適用されるか

既に利用実績のあるリージョンについてはこれまで通り

• EC2-ClassicとEC2-VPCの両方をサポート

新規利用のリージョンに適用されていればEC2-VPCがデフォルトに

• シドニー、サンパウロから適用開始

• リージョンによって適用開始時期は異なります

Public IPアドレスについて

EC2インスタンスに動的に割り当てられるGlobal IPアドレス

• 従来のEC2と同様の挙動

• インスタンス起動時に割り当て

• Stop / Startで変わる

• Default Subnetでのみ利用可能

• ユーザが自身で作成したSubnetでGlobal IPアドレスを利用するにはEIPの割り当てが必要

使い所

• 外部との通信のためにGlobal IPアドレスが必要だが、固定である必要がない場合, e.g.

• クライアントとして外部と通信

• Auto Scalingしつつ、直接コネクションを受け付けるサーバ

Default VPC / Default Subnetについて

Default VPC

• VPC指定なしでサービスを起動した際の受入先となる特別なVPC

• EC2, RDS, ELB, EMR, Beanstalk

• リージョンごとに1つまで

• 通常のVPCと同様、Subnetの追加も可能

Default Subnet

• 各AZに自動作成されるSubnet

• Default VPCに所属

• 動的割当されるPublic IPアドレスが利用できる唯一のSubnet

注：Default VPCやDefault Subnetを削除した場合、再作成は要カスタマサポート

違いが全くないわけではないので注意

アカウントを越えたPrivate IPアドレスでの通信は出来ない

• Global IPアドレス(EIP or Public)を利用する必要有り

• （同一アカウント内で異なるVPCに属するインスタンス同士もPrivate IPアドレスでは通信出来ないが、それは現在も同様）

EIPの挙動

• Stop / Startしてもインスタンスとの紐付けは残る

• （現在のVPCでの挙動と同じになる）

アカウントを越えたセキュリティグループの参照はサポートされない

• 対策

• アカウントを越えた監視が目的の場合： EIPを取得し、Src / Dstの指定に利用

• 課金を分けるのが目的の場合： Tag付きビリングの利用に切り替え

• サービスごとのアクセス制限が目的の場合： IAMの利用

プライベートアドレスでの通信の違い

AWSパブリック

クラウド環境

VPC

プライベートIPアドレスでの通信 セキュリティグループ

の設定によりアカウントを越えた通信も可

アカウントを越えた通信はVPC間通信となる

ためプライベートアドレスでは不可

VPCにおけるRDSのアクセス制御

（2012/12/10以降）

アクセス制御はVPC Security Groupに一本化*

• DB Security GroupはVPCでは使わない

DB Security Group VPC Security Group

VPCなしでRDSインスタンスへのアクセスを制御

RDSを含む、VPC内のインスタンスのアクセスを制御

RDSマネージメントコンソールあるいはRDS APIで作成及び管理

VPCマネージメントコンソールあるいはEC2 APIで作成及び管理

ルールを追加する際、ポート番号やプロトコル(TCP/UDP)の指定は不要

ルールを追加する際、プロトコルとポート番号の指定が必要（例：TCP

3306 for MySQL）

EC2 Security Groupからのアクセスを許可する（アカウント問わず）

同一VPC内の他のVPC Security

Groupからのアクセスを許可する

* VPCがデフォルトになっているかに依らない。2012/12/10以前に作成されたDB Security

Groupは自動的にVPC Security Groupに移行済み

APIの後方互換性

新API（Version 2012-10-31） • 2012/12/10にリリース

• VPC内でのDB Security Groupを取り扱わない

旧API（Version 2012-09-17以前） • DB Security Groupの操作を受け入れる（後方互換）

• APIの背後では自動的にVPC Security Groupが作成される

• この時作成されるSecurity Groupには”rds”のPrefixがつく

– DB security group “dbsg-1” VPC Security Group “rds-dbsg-1”

VPC Security GroupによるRDSアクセス制御

SourceにアプリケーションサーバのSecurity Group

を指定

作成したRDSインスタンス用Security Groupをインスタンス作成時に割り当て

RDSインスタンス用Security Groupを作成