実践VPC実践VPCISOBE Kazuhiko (cloudpack)

cloudpack night #2 2012-03-23

提供

この発表はcloudpackの提供でお送りいたします

01 26

自己紹介

Twitter: muramasa64

cloudpackでAWSで提案・設計・運用最近VPCを使う案件が多いです

好きなAWSサービス: API

02 26

VPCはパラダイムシフト

従来のAWSのシステム設計とは方法論を変えなければならない

もちろんオンプレミスとも違う

03 26

VPCを使って分かったこと

これまでVPCの設計をしてきて、ある程度固まってきた使い方について紹介

04 26

サブネット

サブネットをどう分割するか

05 26

サブネット単位でできること

ネットワークACL

ルーティング

どこかのAZに所属AZをまたげない

06 26

サブネットの分け方

ルーティング単位で分けるInternetと通信する

VPNの接続拠点に直接アクセスする

NATインスタンスを使ってる

07 26

サブネットの分け方

ELB専用サブネットを作る(推奨)

RDSは専用でなくてもよさそう？

08 26

セキュリティグループ

セキュリティグループはEC2稼働中に付け替えられて便利

この機能を前提とすると、従来とは違った使い方のほうがすっきるする

09 26

従来のやりかた

defaultセキュリティグループはすべてにつける

サーバ間の通信をすべて許可する設定

全てに共通な設定(管理サーバからのアクセスなど)を設定

10 26

従来のやりかた

サーバのカテゴリごとにつけるWebサーバなら、web、DBサーバならDBというグループを作ってつける

同じカテゴリなら、同じルールの設定が必要になるため

11 26

従来のやりかたの課題

同じIPアドレスからの許可を、複数のグループに設定が必要だったりして面倒

このIPアドレスって、どこのIPアドレスだっけ？

12 26

VPCでの考え方

下記のようなグループ分けをする領域別グループ

機能別グループ

利用者別グループ

13 26

領域別グループ

通信を許可する領域別につくる

internetからのアクセス、VPC内部のアクセス

14 26

機能別グループ

サーバのもつ機能ごとに設定する

Webサーバ、DBサーバ、NATインスタンス

15 26

利用者別グループ

cloudpack、お客さま、開発会社など

グループ単位で追加・変更・削除すると管理しやすい

16 26

ネットワークACL

サブネット単位複数AZはまたげない

Denyルールが使える

ステートレス設定がやや面倒

サブネット内の通信は影響なし17 26

ネットワークACLの使い所

通常のFW的使い方は、セキュリティグループでやる

Denyルールを活用するサブネット間で通信させたくないとき

特定のIPアドレスから攻撃があった時にブロックする

18 26

VPCの設計での事例

とりあえずVPCを使うのは決まっていた

VPCのCIDRは、192.168.0.0/24という顧客の要望

/24だと、AZを複数作るとカツカツ192.168.0.0/25, 192.168.0.128/25の2つ

ここまでは良かった…19 26

あっ、サブネットが足りない

えっ、ELB使うの？

ELBは、IPアドレスが123個以上無いと作れない

もうサブネットは追加できないし…

VPN接続の設定はしちゃったのでCIDRを増やして作り直しもNG

20 26

とりあえずの解決策

/25ならELBをひとつ作ることはできる

まず、/25のサブネットを作る

そこにELBを入れる

その後にEC2を立ち上げる

21 26

問題点

ELBを複数作ることができない消して作りなおしもできない

Amazonの推奨ではないELBは専用のサブネットが望ましい

でも、123個必要って、ちょっと制限がきついのでは…

22 26

今後の対策

最初にしっかりとシステム構成を定義しましょう

ELBを後から追加したいとかは厳しい

最初に定義できない場合は、VPCは広く確保しておく

23 26

ちなみに

Virtual Private Gatewayは別のVPCにアタッチし直せる

別のVPCを作ってアタッチし直すという技が使える

今回も検討したけど事情があり使えなかった

システムのリプレースに便利かも24 26

まとめ

VPCは便利だけど使い方が難しい

ちゃんと設計してから構築しましょう

ご意見募集！

25 26

　

ご静聴ありがとうございました

26 26