いまさら、AWSのネットワーク設計
•Download as PPTX, PDF•
13 likes•28,067 views
AWSに関するお問い合わせ：<a href="https://www.serverworks.co.jp/contact/" >https://www.serverworks.co.jp/contact/</a> サーバーワークスエンジニアブログ：http://blog.serverworks.co.jp/tech/ 当社の髙田が2018年10月27日開催のJAWS-UG関西女子会にて登壇した際の発表資料です。 ※免責事項 本書の情報・資料の記載には注意を払っておりますが、記載された情報の内容が正確であるか、更新時期が適切かどうかなどについて一切保証するものではありません。 また、記載された情報またはその誤りなど、本書記載の情報に関連して生じた損害または障害などに関しては、その理由の如何に関わらず、またその損害等が直接的か間接的かを問わず、一切責任を負うものではありません。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to いまさら、AWSのネットワーク設計
Similar to いまさら、AWSのネットワーク設計 (20)
More from Serverworks Co.,Ltd.
More from Serverworks Co.,Ltd. (20)
Recently uploaded
Recently uploaded (9)
いまさら、AWSのネットワーク設計
- 7. VPC設計の流れ 7 1. VPC構成の決定（単一VPC構成／複数VPC構成） 2. VPCに割り当てるネットワークCIDRの決定 3. サブネット設計/ルートテーブル設計 4. VPCエンドポイント設計
- 8. VPC構成の決定
- 9. VPC構成のパターン 9 単一AWSアカウント/単一VPC構成 単一AWSアカウント/複数VPC設計 複数AWSアカウント/複数VPC設計
- 11. 単一AWSアカウント/複数VPC構成 11 VPC内は、ルーティング可能なため、ネットワーク アクセス制限は、NACLおよびSGにて実装する VPC間は、ルーティング不可なため、通信が必要な 場合は、VPC Peeingを構成し、ルートテーブル設定 が必要（→ VPC間のアクセス制限がルーティングで 可能） オンプレミスからVPCへ接続する場合は、原則、各 VPC単位で接続が必要 route table route table
- 12. 単一AWSアカウント/複数VPC構成(Direct Connect Gateway) 12 VPC内は、ルーティング可能なため、ネットワーク アクセス制限は、NACLおよびSGにて実装する VPC間は、ルーティング不可なため、通信が必要な 場合は、VPC Peeingを構成し、ルートテーブル設定 が必要（→ VPC間のアクセス制限がルーティングで 可能） オンプレミスからVPCへ接続する場合は、原則、各 VPC単位で接続が必要 Direct Connect Gatewayを用いることで、1 つの接続を複数のVPCで使用することができる route table route table AWS Direct Connect Direct Connect Gateway
- 13. 複数AWSアカウント/複数VPC構成 13 route table route table VPC内は、ルーティング可能なため、ネットワーク アクセス制限は、NACLおよびSGにて実装する VPC間は、ルーティング不可なため、通信が必要な 場合は、VPC Peeingを構成し、ルートテーブル設定 が必要（→ VPC間のアクセス制限がルーティングで 可能） オンプレミスからVPCへ接続する場合は、各VPC単 位で接続が必要 (Direct Connect Gatewayは不可) AWSアカウトごとに、AWSリソースへのアクセス 範囲（マネコンでの可視範囲等)が制限される。また 請求情報が分離される。
- 14. まとめ 14 下記に該当する要件がなければ「単一AWSアカウント／単一VPC構成」 複数VPC構成 システム単位／リソース単位でルーティングによるアクセス制限を行いた い場合は、「単一AWSアカウト/複数VPC構成」を採用 AWSリソースへのアクセス範囲（マネコンでの可視範囲等）の制限や、 請求情報の分離が要件なら「複数AWSアカウント/複数VPC構成」を採用 （ただし、Direct Connect Gatewayは利用できない点を留意）
- 16. 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構成時のルートテーブルの設定が煩雑になる可能性
- 17. サブネット/ルートテーブル設計
- 18. サブネットをどの単位で分けるか? 18 アベイラビリティゾーン単位 ◎ ルーティング単位 ◎ IPアドレスの管理特性単位 ○ ネットワークセキュリティ制御単位 △
- 19. アベイラビリティゾーン単位 ◎ 19 Availability Zone #1 VPC subnet Availability Zone #2 「各サブネットが完全に 1 つのアベイラビリティーゾーン内に含まれている必要があります。1 つのサブネットが複数のゾーンにまたがることはできません。」 VPC subnet
- 20. ルーティング単位 ◎ 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 つのルートテーブルにしか関連付けることはできません」
- 21. IPアドレスの管理特性単位 ○ 21 プライベートIPアドレスを指定できるAWSリソース EC2 プライベートIPアドレスを指定できないAWSリソース RDS/ElastiCache NAT Gateway VPCエンドポイント(インターフェス) プライベートIPアドレスを指定できない、かつ消費IPアドレスが増減するAWSリソース ELB EC2(AutoScaling)
- 22. 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. ネットワークセキュリティ制御単位 △ 23 VPC subnet VPC subnet セキュリティレベル2セキュリティレベル1
- 24. ネットワークセキュリティ制御単位 △ 24 ネットワークACLを運用する場合 ○ サブネット単位でアクセス制御が可能なため、有効 ネットワークACLを運用しない場合 △ ルートテーブルを分離すれば、対VPC外通信をサブネット単位で制御可能 対VPC外（インターネット/オンプレミス/他のVPC) VPC内通信はセキュリティグループによるインスタンス（ENI）単位の制御のみ ルートテーブルを分離しない場合、セキュリティグループによるインスタンス （ENI）単位の制御のみとなるため、サブネットを分割する必要性はない
- 25. まとめ 25 サブネット分離の基準は、以下の3つのポイント アベイラビリティゾーン ルーティング（※対VPC外とのアクセス制御） IPアドレスの管理特性（特に消費IPアドレスの増減のあるものは注意） ネットワークACLを運用する場合は、ネットワークセキュリティ制御の観点も 踏まえて分離する
- 26. サブネット/ルートテーブル設計例 26 Internet gateway VPN gateway VPC NAT gateway VPC subnetVPC subnet VPC subnet VPC subnet VPC subnetVPC subnet VPC subnet VPC subnet Availability Zone #1 Availability Zone #2 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. サブネット/ルートテーブル設計例 27 Internet gateway VPN gateway VPC NAT gateway VPC subnetVPC subnet VPC subnet VPC subnet VPC subnetVPC subnet VPC subnet VPC subnet Availability Zone #1 Availability Zone #2 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をデフォルトゲート ウェイとして、オンプレミ スとの疎通を確保 （インターネットとの疎通 なし）
- 28. VPCエンドポイント設計
- 29. VPCエンドポイント Internet gateway VPC NAT gateway VPC subnetVPC subnet VPC subnet VPC subnet 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を利用できな い
- 30. VPCエンドポイント Internet gateway VPC NAT gateway VPC subnetVPC subnet VPC subnet VPC subnet 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エン ドポイントを利用させるこ とが可能
- 31. 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
- 32. VPC設計における注意点 32 ゲートウェイエンドポイント 適応するルートテーブルを正しく選択する インターフェイスエンドポイント (AWS PrivateLink を使用) VPC単位で有効／無効となる ENIにより、 VPC内の指定サブネットのIPアドレスが消費される （例）AWS Systems Managerの場合、最大4つのIPアドレスが必要 （冗長考慮の場合は8つのIPアドレス） 使用するサービスの数によっては、インターフェイスエンドポイント用のサブネットを作成するこ とを検討したほうよい
- 33. まとめ