いまさら、AWSのネットワーク設計

株式会社サーバーワークス
いまさら、
AWSのネットワーク設計
秋到来！JAWS-UG関西女子会流☆秋のごった煮収穫祭！
2018年10月27日
髙田知典

2
AWSのネットワーク
設計
≒ VPC設計

3
https://www.slideshare.net/AmazonWebServices/arc401serverless-architectural-patterns-and-best-practices/14

4
VPC いらないのでは？

5

6
VPCが必要なサービス

VPC設計の流れ
7
1. VPC構成の決定（単一VPC構成／複数VPC構成）
2. VPCに割り当てるネットワークCIDRの決定
3. サブネット設計/ルートテーブル設計
4. VPCエンドポイント設計

VPC構成のパターン
9
 単一AWSアカウント/単一VPC構成
 単一AWSアカウント/複数VPC設計
 複数AWSアカウント/複数VPC設計

単一AWSアカウント／単一VPC構成
10
 VPC内は、デフォルトでルーティング可能なため、
ネットワークアクセス制限は、NACLおよびSGにて
実装する
 オンプレミスからVPCへ接続する場合は、当該VPC
への接続のみ準備すればよい

単一AWSアカウント/複数VPC構成
11
 VPC内は、ルーティング可能なため、ネットワーク
アクセス制限は、NACLおよびSGにて実装する
 VPC間は、ルーティング不可なため、通信が必要な
場合は、VPC Peeingを構成し、ルートテーブル設定
が必要（→ VPC間のアクセス制限がルーティングで
可能）
 オンプレミスからVPCへ接続する場合は、原則、各
VPC単位で接続が必要
route table route table

単一AWSアカウント/複数VPC構成(Direct Connect Gateway)
12
可能）
 オンプレミスからVPCへ接続する場合は、原則、各
VPC単位で接続が必要
 Direct Connect Gatewayを用いることで、1
つの接続を複数のVPCで使用することができる
AWS
Direct
Connect
Direct Connect Gateway

複数AWSアカウント/複数VPC構成
13
可能）
 オンプレミスからVPCへ接続する場合は、各VPC単
位で接続が必要 (Direct Connect Gatewayは不可)
 AWSアカウトごとに、AWSリソースへのアクセス
範囲（マネコンでの可視範囲等)が制限される。また
請求情報が分離される。

まとめ
14
 下記に該当する要件がなければ「単一AWSアカウント／単一VPC構成」
 複数VPC構成
 システム単位／リソース単位でルーティングによるアクセス制限を行いた
い場合は、「単一AWSアカウト/複数VPC構成」を採用
 AWSリソースへのアクセス範囲（マネコンでの可視範囲等）の制限や、
請求情報の分離が要件なら「複数AWSアカウント/複数VPC構成」を採用
（ただし、Direct Connect Gatewayは利用できない点を留意）

VPCに割り当てるネットワークCIDRの決定

VPCに割り当てるネットワークCIDRの決定
16
 オンプレミスと重複しない大きめのネットワークCIDR(/16等)を割り当てる
 VPC作成後にネットワークCIDRの追加は可能
 プライマリVPC CIDRとセカンダリCIDRの組み合わせに制限がある
 「VPCに割り当てるネットワークCIDRの決定」
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_
Subnets.html#vpc-resize
 VPC Peeing構成時のルートテーブルの設定が煩雑になる可能性

サブネット/ルートテーブル設計

サブネットをどの単位で分けるか?
18
 アベイラビリティゾーン単位 ◎
 ルーティング単位 ◎
 IPアドレスの管理特性単位 ○
 ネットワークセキュリティ制御単位 △

アベイラビリティゾーン単位 ◎
19
Availability Zone #1
VPC subnet
「各サブネットが完全に 1 つのアベイラビリティーゾーン内に含まれている必要があります。1
つのサブネットが複数のゾーンにまたがることはできません。」
VPC subnet

ルーティング単位 ◎
20
VPC subnetVPC subnet
Internet
gateway
VPN
gateway
VPC subnet
VPC NAT
gatewayInternet
Default GWはIGW Default GWはNAT GW
Default GWはVGW
「1 つのサブネットは同時に 1 つのルートテーブルにしか関連付けることはできません」

IPアドレスの管理特性単位 ○
21
 プライベートIPアドレスを指定できるAWSリソース
 EC2
 プライベートIPアドレスを指定できないAWSリソース
 RDS/ElastiCache
 NAT Gateway
 VPCエンドポイント(インターフェス)
 プライベートIPアドレスを指定できない、かつ消費IPアドレスが増減するAWSリソース
 ELB
 EC2(AutoScaling)

IPアドレスの管理特性単位での分離例
22
VPC subnetVPC subnet VPC subnet
Elastic Load
Balancing
VPC subnet
Auto Scaling group
Amazon
RDS
負荷によってELBの消費
IPアドレスが増減
+
最小サブネットサイズ
/27
空きIPアドレス8個以上
負荷によって、EC2の数
≒消費IPアドレスが増減
+
使用IPアドレスの指定は
不可
EC2ローンチ時にIPアド
レスを指定可能
IPアドレスを指定不可

ネットワークセキュリティ制御単位 △
23
VPC subnet VPC subnet
セキュリティレベル2セキュリティレベル1

ネットワークセキュリティ制御単位 △
24
 ネットワークACLを運用する場合 ○
 サブネット単位でアクセス制御が可能なため、有効
 ネットワークACLを運用しない場合 △
 ルートテーブルを分離すれば、対VPC外通信をサブネット単位で制御可能
 対VPC外（インターネット/オンプレミス/他のVPC)
 VPC内通信はセキュリティグループによるインスタンス（ENI）単位の制御のみ
 ルートテーブルを分離しない場合、セキュリティグループによるインスタンス
（ENI）単位の制御のみとなるため、サブネットを分割する必要性はない

まとめ
25
 サブネット分離の基準は、以下の3つのポイント
 アベイラビリティゾーン
 ルーティング（※対VPC外とのアクセス制御）
 IPアドレスの管理特性（特に消費IPアドレスの増減のあるものは注意）
 ネットワークACLを運用する場合は、ネットワークセキュリティ制御の観点も
踏まえて分離する

サブネット/ルートテーブル設計例
26
Internet
gateway VPN
gateway
VPC NAT
gateway
VPC subnetVPC subnet VPC subnet VPC subnet
Elastic Load
Balancing*
192.168.0.0/16
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24 192.168.4.0/24 192.168.6.0/24
192.168.7.0/24 192.168.5.0/24 192.168.7.0/24
VPC NAT
gateway
RTB1 RTB2 RTB3 RTB4
RTB2’

サブネット/ルートテーブル設計例
27
Internet
gateway VPN
gateway
VPC NAT
gateway
Elastic Load
Balancing*
192.168.0.0/16
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24 192.168.4.0/24 192.168.6.0/24
192.168.7.0/24 192.168.5.0/24 192.168.7.0/24
VPC NAT
gateway
RTB1 RTB2 RTB3 RTB4
RTB2’
IGWをデフォルトゲート
ウェイとして、
インターネットとの疎通
NAT Gatewayをデフォル
トゲートウェイとしてイン
ターネットとの疎通を、
NAT経由で確保
VPC内のみ疎通可能とする
VGWをデフォルトゲート
ウェイとして、オンプレミ
スとの疎通を確保
（インターネットとの疎通
なし）

VPCエンドポイント設計

VPCエンドポイント
Internet
gateway
VPC NAT
gateway
192.168.0.0/24 192.168.2.0/24 192.168.4.0/24 192.168.6.0/24
RTB1 RTB2 RTB3 RTB4
Amazon
S3
パブリックなエンドポイントを持つサービスは、インターネット側への経路がないとVPC内からは
利用できない
インターネットへの経路が
ないため、S3を利用できな
い

VPCエンドポイント
Internet
gateway
VPC NAT
gateway
192.168.0.0/24 192.168.2.0/24 192.168.4.0/24 192.168.6.0/24
RTB1 RTB2 RTB3 RTB4
Amazon
S3
VPC内にサービスのエンドポイントを作成して、インターネットへの経路がない場合でも、サービ
スへのアクセスを可能にする
endpoints
インターネット側との疎通
があるものでも、VPCエン
ドポイントを利用させるこ
とが可能

2種類のVPCエンドポイント
31
 ゲートウェイエンドポイント
 対象サービス：Amazon S3、DynamoDB
 ゲートウェイが作成され、指定したルートテーブル上にサービス向けの経路が追加される
 インターフェイスエンドポイント (AWS PrivateLink を使用)
 対象サービス：右記参照
 プライベートIPが付与されたENIが、指定サブネット内に作成される
 上記IPに対応したDNS名を名前解決することでエンドポイントに通信
 VPCの「DNSホスト名」を有効にする
• Amazon API Gateway
• AWS CloudFormation
• Amazon CloudWatch
• Amazon CloudWatch Events
• Amazon CloudWatch Logs
• AWS CodeBuild
• AWS Config
• Amazon EC2 API
• Elastic Load Balancing API
• AWS Key Management
Service
• Amazon Kinesis Data Streams
• Amazon SageMaker Runtime
• AWS Secrets Manager
• AWS Security Token Service
• AWS Service Catalog
• Amazon SNS
• AWS Systems Manager

VPC設計における注意点
32
 ゲートウェイエンドポイント
 適応するルートテーブルを正しく選択する
 インターフェイスエンドポイント (AWS PrivateLink を使用)
 VPC単位で有効／無効となる
 ENIにより、 VPC内の指定サブネットのIPアドレスが消費される
 （例）AWS Systems Managerの場合、最大4つのIPアドレスが必要
 （冗長考慮の場合は8つのIPアドレス）
 使用するサービスの数によっては、インターフェイスエンドポイント用のサブネットを作成するこ
とを検討したほうよい

まとめ
 こんな時代ですが、VPCのことも、時々、思い出してください

いまさら、AWSのネットワーク設計

いまさら、AWSのネットワーク設計

More Related Content

What's hot

Similar to いまさら、AWSのネットワーク設計

More from Serverworks Co.,Ltd.

いまさら、AWSのネットワーク設計