VPC(Virtual Private Cloud) †
- VPC EC2起動中でもSecurity Groupを変更可能。EC2 Classicでは出来ない
- EC2選択 > Actions > Networking > Change Security Group
Regional NAT Gateway: リージョンレベルのNAT Gateway †
今まで(Zone):
- private subnetからインターネットへ通信したい場合、public subnetにNAT gatewayを設置する必要があった。private subnet x3(AZ) = 1~3 NAT gatewayが必要。1個の場合は、NAT gatewayのあるAZが丸ごと死んだ場合、他のAZが問題なくても疎通できなくなる
- NAT gatewayを通るトラフィックによって課金され、かなり高価になる。prod環境用にMulti-AZ構成だと、2~3倍のコストになる。
- ルートテーブルにNAT gatewayへのルーティング追加が必要
- 料金(ap-northeast-1 東京): 1AZ = 約USD 45/月（USD USD 0.062/時間 × 1AZ × 730時間）+ 通信料(1GB = USD 0.062)
Regional NAT Gateway:
- リージョンレベルで動作。単一AZの障害を受けない
- public subnetなしで利用可能
- 料金: NAT GatewayのEIPを割り当てたAZ毎。1 AZ=1 NAT gateway構成なら以前と変わらない。元がSingleAZ構成だと、auto modeではAZの数だけNAT gatewayが増えるため価格が上がる。
- 手動でEIPを割り当ても可能(以前の使い方)、コスト削減、集約したい場合
Regional, Zonal の選択:
記事:
VPC Lattice: VPC向けのリバースプロキシサービス †
記事:
apne1-az3の廃止 †
- apne1-az3は売り切れて使えなくなったAZ。古いAWSアカウントでのみ見えていた。
- 2025年2月28日に廃止
記事:
Share VPC: subnet単位で他AWSアカウントと共有 †
記事:
使用IPアドレス数等の監視 †
- CloudWatchでNetworkAddressUsageを見るためには、VPCで明示的に有効にする必要がある
記事:
VPC Reachability Analyzer: 接続性テスト †
送信先がRDSの場合:
記事:
プレフィックスリスト: CIDRブロックを定義して、キュリティグループルール等から参照 †
Managed prefix lists: 複数CIDRの管理 †
VPC Ingress Routing †
VPC Peering: VPC同士の接続 †
VPC Endpoint †
- VPC エンドポイント - Amazon Virtual Private Cloud
- AWS APIは、基本インターネットに公開されている。AWSアカウント中だが、VPCの外にあるイメージ。
- public subnetにあるリソースからはIGWを通してAWS APIへアクセスできる。この場合はインターネットへ出ずに、プライベート通信として処理される。
- private subnetにあるリソースはインターネットへアクセスできない。アクセスしたい場合は、nat-gatewayかVPC endpointを用意する。
- VPC Endpointには、ゲートウェイ型(S3, DynamoDBのみ)、インタフェース型がある
コスト:
- 月200GBを超える転送量が発生する場合は、VPC endpointを用意した方が安い？
- 【AWSコスト最適化】VPC エンドポイントを消すだけでセキュリティそのままにコストが節約できた
- VPC エンドポイント
- 時間料金: USD 0.014 / 時間 (APN1-VpcEndpoint-Hours) * AZの数
- 処理データ料金 (最初の 1PB): USD 0.01 / GB (APN1-VpcEndpoint-Bytes)
- nat-gateway
- 時間料金: USD 0.062 / 時間 (APN1-NatGateway-Hours) * AZの数 (1~N, 可変)
- 処理データ料金: USD 0.062 / GB (APN1-NatGateway-Bytes)
terraformの場合:
記事:
設計 †
- 設計時の注意
- 後からCIDRを変更はできないので十分に考えた方が良い。rfc1918準拠等
- 他のVPCと接続したい場合(VPC peering)、CIDRが重複していると接続できない。その場合は重複を避ける。また、route tableが重複しても通信が出来ない。
- 広すぎるCIDRはVPCやサブネット数が足りなくなるので避ける。デフォルトVPCの「/16」は同設定を増やしていくには大きすぎる場合がある
- ただし、EKSではインスタンスサイズによって1台数十のIPを予約、podに1IP割り当てるため数百のIPを消費する。/24では不足するので、/16もあり。
- 小さすぎてもオートスケールするリソース(ELB, Lambda, EC2 AutoScale, etc)があるので困る。
- ブロードキャスト、マルチキャストは非対応
- apne1-az3 は避ける。売り切れているのでec2等が作れない。
- 例:
- VPC CIDR: 10.10.0.0/21
- IP range: 10.10.0.0 - 10.10.7.255
- IP数: 2048
- 最大Subnet数(1 VPC): 8
- SubnetはPublic, Privateでそれぞれ最低 3 つあれば良い。(EKS Architecture)
- 最大Public Subnet数: 4
- 最大Private Subnet数: 4
- 最大NAT gateway: 4 (Private Subnetの数だけ) コスト($45/month程)がかかるので注意。2つに減らしても良い。0だとprivate subnetからinternetへトラフィックが流れない。
- Region辺りのAZは、最大4つ程。
- AZ毎にPublic/Private Subnetを作る。AZは売り切れる事があるので、冗長性を確保したい場合 最低 3 AZは欲しい。
Private Subnet †
デフォルトではインターネットと通信ができない。
DBやCache等の外部と通信させたくないリソースを置く。
- VPC とサブネットのサイズ設定
VPC を作成する場合は、 RFC 1918 に指定されているように、プライベート IPv4 アドレス範囲から CIDR ブロック (/16 以下) を指定することをお勧めします。
10.0.0.0 - 10.255.255.255 (10/8 プレフィックス)
172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス)
192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス)
VPC NAT Gateway †
- 料金は結構高いので注意
- VPC Subnet毎に設置する事で、Outgoingトラフィックのための固定IPを持てるため、アクセス制限が厳しい環境で使える。
- VPC Lambdaの場合、internetへ通信したい場合、NAT gatewayを通すように設定する。
記事:
NAT Gatewayのコスト削減/分析 †
記事:
ClassicからVPCへの移行 †
High Availability for Amazon VPC NAT Instances †
![[PukiWiki]](image/owl.png "[PukiWiki]")
