AWS ネットワーク設計
https://gyazo.com/ce026325a9f082c3910bc1cf21a66500
AWS のインフラストラクチャとネットワーク関連サービス
table:network_service
AWS リソース 概要 関連するAWSインフラ
Amazon VPC AWS 上にプライベートネットワークを構築 Region 内で稼働
AWS Direct Connect (DX) AWS と自社拠点/DC間の専用回線 DXロケーションで接続
Amazon Route53 マネージド DNS サービス エッジロケーション内で稼働
AWS サービスのネットワーク観点からの分類
ある Region におけるネットワークは、VPC を用いて構成された プライベート IP アドレス空間 と、それ以外の パブリック IP アドレス空間 に分類される。
table:network_and_services
アドレス空間 稼働サービス
パブリック IP アドレス空間 S3, Lambda, DynamoDB, CloudWatch
プライベート IP アドレス空間 EC2, EDS, EMR
Amazon VPC
Amazon VPC と名前解決
Amazon VPC を立てると、内部向けの DNS が建てられる。内部向けの DNS に向けた設定を社内ネットワークで行えば private 内の名前解決も行える。Amazon VPC と DNS については以下。 Amazon VPC のインフラストラクチャパターン
Amazon VPC をどのくらい用意するか？という問題がある。基本的には、開発の規模が小さければ単一 VPC、大きくなるにつれてマルチ VPC、マルチアカウントが適している。 VPC を1つのみ
ハイパフォーマンスコンピューティング環境
単一の VPC 環境は複数の VPN による分散環境よりもレイテンシーが低い
アイデンティティ管理環境
IAM の管理が楽で、最善のセキュリティを確保できる
1人もしくは非常に小規模のチームの場合
複数の VPC を必要以上に扱うよりも単一の方が簡単
マルチ VPC パターン
単一のチームもしくは単一の組織の場合
開発者が開発/テスト/本番環境へのフルアクセス権を持つ場合は、これで十分
マルチアカウントパターン
大規模な組織や複数の IT チームがある、あるいは急成長が見込まれる中規模な組織の場合
アクセスの管理をしやすくするため
アカウントを分離することで、ワークロードを分離できる。
例えば、パブリック IP アドレス空間にある AWS サービス (S3 等) は、VPC の外にある = マルチ VPC からアクセスが可能になってしまう
マルチアカウントだと、あるアカウントのテスト環境でたてた S3 に別アカウントの開発環境からアクセスできてしまうようなことがなくなる
サブネット
サブネットは、基本的にはインターネットのアクセス可能性を定義する ために利用する。アプリケーション層や機能層に基づいて定義しない。例えば、サーバやコンポーネントの論理的な区分を設けたい場合は、サブネットではなくタグやセキュリティグループを利用するのが良い。このように、サブネットによる分割でなくとも、他の AWS サービスで実現できる場合がある。
ただ、サブネットに紐づく要素は他にもネットワーク ACL やルートテーブルがあり、これらに区切りを加えたいという要件であれば分割もありえる。例えば、RDS には必ず Web サーバ経由でアクセスするようにしたい場合は、Web サーバと RDS を配置するサブネットを分割し、前者のみ VGW にルーティングして後者は local にのみルーティングすることで実現できる。
インターネットのアクセス可能性 とは、パブリック (= インターネットとのアクセスあり) と プライベート (= インターネットとのアクセスなし) の2つである。
基本的には、1 AZ につきパブリック/プライベートサブネットの2つに分割するのがよい。それ以上の分割は要件によって必要ならば行う。例えば、ネットワーク ACL はサブネット単位で設定できるので、これを利用してリソースを分離したい場合もあるかもしれない。ただし、大抵はセキュリティグループを利用した方が細かく制御できるし、IP の過不足を気にする必要がなくなる。
外部に公開するサービスよりも、通常は公開しないサービスの方が多くなるため、プライベートサブネットの方の IP アドレスを多めに確保するのが良い。
パブリックサブネット
ルートテーブル にIGWへのエントリがある
パブリックインターネットへのインバウンド/アウトバウンドのアクセスが可能
プライベートサブネット
ルートテーブル に IGW へのエントリがない
パブリックインターネットからは直接アクセスできない
ジャンプボックス を利用し、アウトバンド専用のパブリックインターネットアクセスを提供する
NAT ゲートウェイ, プロキシ, 踏み台ホスト等
パブリック/プライベートサブネットは、本質的にはどちらも同じサブネットという AWS リソースであり、IGW へのルーティングがあるかどうか？で呼び方が異なるだけである。
サブネットに関連付けられているルートテーブルにインターネットゲートウェイへのルートがある場合、そのサブネットは「パブリックサブネット」と呼ばれます。
サブネットの IP アドレスの範囲を少なくしすぎると、例えば新しく EC2 インスタンスを立ち上げたいときに、IP アドレスが割り当てられない場合にエラーとなってしまう。そのため、多めに割り当てておくのが良い。AWS では、/24 以上が推奨されている。
VPC コンポーネント
配置単位から以下のように分けられる。これは一部で、他にもある。
table:vpc_component
配置単位 サービス 概要
VPC VGW 拠点との接続。接続先は CGW もしくは Direct Connect (DX)
VPC IGW インターネット接続
VPC VPCピア接続 VPC 間の接続
VPC VPCE VPC 外の AWS サービスとの接続
サブネット VPC Router ルートテーブルに基づいてルーティング (自動配置)
サブネット NAT GW プライベートサブネットに NAT 機能を提供
インスタンス Elastic IP 固定 Public IP アドレス
仮想プライベートゲートウェイ (VGW)
プライベートサブネットを作成した際に、そこにアクセスするための手段は以下がある。
踏み台サーバをパブリックサブネットに用意する (OnDemand Bastion パターン)
インターネット経由でプライベートサブネット内のインスタンスにアクセスする
セキュリティグループでアクセス制限を設けた方が良い
プライベート IP アドレス空間に直接アクセスする
踏み台サーバをプライベート IP アドレス空間に配置するとなお良い
各サーバに直でアクセスさせてしまうと、誰が何をしたかわからなくなってしまう
ロギング等が一括で行える
セキュリティをレイヤーで担保できる
どちらを採用するかは、ケースバイケース。後者を実現するのが VGW。プライベート IP アドレス空間に、専用線もしくは VPN を介して接続するためのルーターを配置する。前者の場合は AWS Direct Connect (DX)、後者の場合は カスタマーゲートウェイ (CGW) に接続させる。
インターネットゲートウェイ (IGW)
VPC をインターネットに接続させる。以下の目的を持つ。
VPC 内の通信の送信先をインターネットにルーティング可能にする
パブリック IPv4 アドレスが割り当てられているインスタンスに対してネットワークアドレス変換 (NAT) を行う
VPC ピア接続
WIP
VPC Router/ルートテーブル
VPC が作成されると同時に、
VPC Router が自動的に生成される
メインルートテーブル が自動的に生成される
VPC Router は、サブネット毎のルートテーブル に従ってパケットのルーティングを行う
メインルートテーブル は、明示的にルートテーブルと関連づけられていない全てのサブネットに適用される 特別なルートテーブル
削除はできないが、カスタムルートテーブルで置き換えることはできる
ルートテーブルには、経路の判断ルールを定義した ルート が複数紐づく
VPC 内部向けの経路は、デフォルトで設定されている (ターゲット local)
ルート には、 送信先 と ターゲット が定義される
あるサブネット内のパケットが、該当する 送信先 に送信されようとした時、どの ターゲット に送信されるかを定義する
サブネットとルートテーブルの関係は 多 対 1
ルーティングの定義は、制約が強いものが優先される
0.0.0.0/0 と 10.0.0.0/16 があって、10.0.0.10 にアクセスする場合、後者にルーティングされる
https://gyazo.com/e5b5ae24e537cca6f1d14bc4cf1f4346
NAT ゲートウェイ (NAT GW)
プライベートサブネット内のインスタンスは、そのままではインターネットに接続できない。これを実現する方法は以下がある。
NAT を立てた EC2 インスタンスをパブリックサブネットに配置する
NAT ゲートウェイをパブリックサブネットに配置する
後者の場合に利用する。プライベートサブネットのトラフィックのアウトバウンドを、インターネットに向けることができる。逆に、インターネットからのインバウンドは許可しない。
ネットワークアドレス変換 (NAT) ゲートウェイを使用して、プライベートサブネットのインスタンスからはインターネットや他の AWS サービスに接続できるが、インターネットからはこれらのインスタンスとの接続を開始できないようにすることができます。
ネットワーク設計手順
1. VPC の作成
作成後は変更不可なので、大きめに
/16 が推奨
オンプレミスや他 VPC のレンジと重複させない
のちに相互接続させる可能性があるため
2. サブネットの作成
ルーティングポリシーに従って分割する
インターネットアクセスの有無, 拠点アクセスの有無 等
サイズは /24 が推奨
3. VPCコンポーネントの配置とルーティング設定
インターネットアクセスが必要なら IGW, 社内アクセスが必要なら VGW
Route Table でサブネットをそれらにルーティングする
4. インスタンスの配置とセキュリティコントロールの設定
RDS や EC2、EBS 等のインスタンスの配置
セキュリティコントロールには セキュリティグループ、ネットワーク ACL を利用
5. 名前解決の検討
AWS により自動割り当てされた DNS 名を利用できる