概要
AWSのVPCを1から構築することになり、理解が浅い部分があったので復習がてらまとめる。
この辺理解すると、Terraformでの構築が楽になるということがわかった。
※間違っている箇所もあると思うけど、そこは随時学びながら修正していきます。
キーワード
VPC
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。
つまり、自分の設計した仮想ネットワーク内にAWSの各リソースを設置して、構築できるという意味。
最初からVPC作ってくれれば良いのでは?とも思うのだけど、ネットワークを大小に分割したい場合など柔軟に対応できるようになっている。
また、そもそもAWSのサービスの中でもVPCに対応していないサービスとかもあるので、VPCで構築しないで一部サービス(Route53だけとかS3だけとか)を使うという場合には要らなかったりする。
サブネット
VPC を作成したら、アベイラビリティーゾーンごとに 1 つ以上のサブネットを追加します。サブネットを作成する際、VPC CIDR ブロックのサブセットである、サブネットの CIDR ブロックを指定します。各サブネットが完全に 1 つのアベイラビリティーゾーン内に含まれている必要があります。1 つのサブネットが複数のゾーンにまたがることはできません。
VPC内でAZごとにサブネットを切る。また、この後に説明するネットワーク構成例に応じて、サブネットを分割していく。ルーティングの設定はルートテーブルで行い、ルートテーブルの関連付けでサブネットとルートテーブルを紐つける。
インターネットゲートウェイ
インターネットゲートウェイは 2 つの目的を果たします。1 つは、インターネットでルーティング可能なトラフィックの送信先を VPC のルートテーブルに追加することです。もう 1 つは、パブリック IPv4 アドレスが割り当てられているインスタンスに対してネットワークアドレス変換 (NAT) を行うことです。
インターネットゲートウェイがVPCの出入り口。VPCとの紐付きやセキュリティグループを設定する以外には特に細かく設定することはないし、変更することもないが、ここを出入り口としていることを知らないとルートテーブルの設定でわからなくなる。
ルートテーブル
VPC の各サブネットをルートテーブルに関連付ける必要があります。サブネットのルーティングは、このテーブルによってコントロールされます。1 つのサブネットは同時に 1 つのルートテーブルにしか関連付けることはできませんが、異なる複数のサブネットを 1 つのルートテーブルに関連付けることはできます。
そのまんま。いわゆるルーティングテーブル。
どこからどこへいくのかの経路情報を記載する。
プライベートネットワークの宛先はプライベートへ、インターネットの宛先はインターネットゲートウェイへや、プライベートネットワークの宛先のみや、インターネットの宛先をNATゲートウェイへ向けるなど。
ルートテーブルに設定するサブネットの関連付け。ルートテーブルとサブネットを関連付けすることで、初めてネットワークがつながるようになる。ここミスるとインターネットでられないとかある。
NATゲートウェイ
ネットワークアドレス変換 (NAT) ゲートウェイを使用して、プライベートサブネットのインスタンスからはインターネットや他の AWS サービスに接続できるが、インターネットからはこれらのインスタンスとの接続を開始できないようにすることができます。
プライベートIPアドレスしか持たないインスタンスなどが、インターネット側からは直接アクセスさせないけど、インターネットへアクセスさせるのに使用する。
ECSを使っていて、コンテナごとにパブリックIPアドレスを振らない場合、NATゲートウェイを介すことでイメージをPullできる。逆を言えば、NATゲートウェイを介すかパブリックIPアドレスを振らないとイメージをPullすることすらできない。
※ECRでイメージを持ってくる場合は、VPCゲートウェイ(Privatelink)を使うが吉かも
また、NATゲートウェイをパブリックサブネットに配置して、プライベートネットワークのインスタンスをNATゲートウェイ経由にするようなルートテーブルの制御をしないとインターネットにでていけない。
この辺は下記の方のサイトが大変わかりやすい。
AWS NATゲートウェイの使い方。プライベートサブネットからインターネットへ
ちなみに作成にも削除にも時間がかかる(5分とか)。おそらく裏でインスタンスが起動しているのではと思っている。
EIP
Elastic IP アドレスは、動的なクラウドコンピューティングのために設計された静的 IPv4 アドレスです。
いわゆるグローバルIPアドレス。インスタンスに付けたり外したりできる。
全部のインスタンスにつけられれば楽なのだけど、お金が結構かかる。
0.005 x 24 x 31=3.72USD。つまり1IPあたり約420円なので、10台とかあるだけで5000円くらいする。
なので、NATゲートウェイ(0.062USD x 24 x 31=46USD,5170円+転送量)などをうまく活用することで、月額コストを下げることにつながると思う。単純計算だと10数台越えるくらいのインスタンスをたてるなら、NATゲートウェイを活用したほうが良さそうだ。
※そもそもEC2インスタンスにアタッチしている場合はEIPは料金が発生しないので、EC2のインスタンス台数で判断しないほうが良さそうです。
なお、NATゲートウェイにもEIPをアタッチすることになる。
構成例
AWSの新しいアイコンセット(わかりやすくなった反面、色味がなくなったアイコン)で構成図を書いてみた。※上のカラフルなアイコンの図はAWS公式サイトからの引用。
ネットワーク1つのみ(Publicサブネットのみ)
Publicサブネットのみの構成。
わかりやすいので管理しやすい。
PublicとPrivateを分割したサブネット2つ
PublicサブネットとPrivateサブネットの構成。
わかりやすさは残しつつ、DBなどインターネットアクセスの要らないサービスをPrivateに配置することでネットワークレベルで分かれている。
PublicとNATゲートウェイを経由するサブネットととPrivateサブネットの3つ
PublicとNATゲートウェイ経由のPrivateネットワークと、Privateネットワークの構成。
用途に応じて各ロールを配置するので、ネットワークレベルで分割できる。
セキュリティ的にも安心度は増す代わりに、複雑さが若干ある。
特にNATプライベートサブネットが複雑。
インタネットからはALBなどのPublicサブネットからのアクセスさせ、インターネットに出る時はNATゲートウェイを介す。
グローバルIPアドレスを持たない場合に特に有効。
NATゲートウェイは同じNATプラベートサブネットに配置するのではなく、Publicサブネットに配置する必要があり、最終的にはInternetGateway経由で外に出ていく。
このサブネットの配置を間違えるとインターネットに出ていけなくなる。
まとめ
ネットワークの構成に関しては、必ずしも一番複雑な物が良いというものでは無いと私は思う。
複雑過ぎて、セキュリティの穴になってしまうくらいだったら、あえてネットワークをシンプルにしてSGやIAMロールなどでしっかり管理するのも一つだろう。
会社のルールや、サービスの規模、性質、チームの運用を踏まえた上で、最適なネットワーク構成をしていくのがクラウドサービスのネットワークにも求められる力だと思う。
他にもVPNやVPC同士の接続など色々なネットワークの使い方があるので、もっと勉強して、クラウドサービスのネットワークに強くなりたい。
<p style='padding: 5px;'>