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を作成
Top Related