はじめに
直近で Amazon VPC の作成から何度かやったのですが、久しぶりに1からやってみた時の覚書です。
VPC
まずは VPC 自体のオブジェクトを作成することになります。
現時点では、確実に IPv4 CIDR の設定は必要になると思うので、最初に決めた帯域を後から変更ができないので、あらかじめ決めておく必要があります。
2017/8/29 のアップデートで、後からCIDRを追加することは可能になっています
基本的には RFC 1918 定義されているプライベートIPアドレスの中から割り当てることになると思います。
- 10.0.0.0/8
- 172.16.0.0/12
192.168.0.0/24
かつてはクラスフルで使用することが多かったと思いますが、最近では、CIDR を切って使うことが多いと思います。 /16 がわかりやすいと思いますが、かなり範囲が大きくて無駄になりやすいので、場合によっては細かく分割するケースもあると思います。
アドレス設計については決めの問題にはなると思いますが、組織内で扱うネットワークアドレス帯域はきちんと管理して、被らないようにしておいた方がトラブルは少ないのではと思います(例えばある会社内で管理しているオフィスのネットワーク帯域と、サービスAのシステムで扱っているネットワーク帯域は別になるようにする、など)。
DHCP オプションセット
VPC で利用するDNSサーバーやNTPサーバーの設定を制御する DHCP オプションセットというリソースがあります。 デフォルトのものが存在しており、構成管理ツール等でVPCを作成する場合に何も指定しないとデフォルトのものが割り当てられることになるかと思います。そのため存在を忘れがちなのですが、VPC毎等に合わせて作成して割り当てるように設定するのも良いかと思います。
IPv6 アドレス
IPv6 では IPv4 のようにグローバルアドレスやプライベートアドレスのクラス A,B,C... といった区別はないようで、グローバルで一意な IPv6 になります。 ルーティング設定次第ではどこからでもアクセス可能になりうるように思われるので気を付ける必要がありそうです。 IPv6 アドレスの割り当て範囲については、VPC での IPV6 CIDR 割り当て時に自動で AWS からの割り当てが可能なので、それを使えば細かくアドレス設計しなくても使える点は便利です。
構成についてはいろいろな形を取ることが可能なようですが、既存の VPC の場合は IPv4 なプライベートアドレスを有効にした状態で、IPv6 の CIDR を割り当てて利用可能にし、その中でリソースをデュアルスタック (IPv4 & IPv6) として、双方のネットワークを考えて構築することになりそうです。 新規の場合は、IPv6 のみとすることも可能かと思いますが、しばらくは平行で扱っていく形になると思います。 ここでは IPv6 については詳しくは取り上げません。
サブネット設計とAZとルーティング
サブネットについては、おそらくWebシステム界隈でよくあるのは、大まかに下記の3つの論理的なレイヤに分割する形かと思います。セキュリティ要件によってはさらに細かく分割したり、PublicとPrivateのみとするなどもあるかと思います。
- Public サブネット
- Private サブネット(インターネットへのアウトバウンドアクセス可能)
- Private サブネット
vpcやサブネットを作成すること自体では料金はかからないので、多くの場合はAZ障害に備えて、各AZ内に必要なサブネットを作成することになると思います。 東京リージョンだとAZが3つあるので、3つのAZ上に、それぞれのサブネットを1つ以上作成する事になります。
Publicサブネットとルーティング
インターネットからのイン、インターネットへのアウトの通信が可能なレイヤをPublicサブネットとして扱うことが多いと思います。
VPC の中に「インターネットゲートウェイ」と呼ばれるものを作成し、VPC にアタッチすることで、VPC 内の パブリック IPv4 アドレスまたは IPv6 アドレスを持つリソースがインターネットへのアクセスが可能になります。 実際に通信させるには、「0.0.0.0/0」を「インターネットゲートウェイ」へルーティングする必要があるので、ルートテーブルに[Destination] (送信先) が 0.0.0.0/0 で、インターネットゲートウェイ ID を [Target] (ターゲット) に持つルートを追加する必要があります。(インターネットからの通信であっても、それを受け付けた後の戻りの通信が外へ出られない状態と思われるため、ルートテーブルの設定は必要)
IPv6 と IPv4 は別のルーティング定義として設定する必要があります。
Private サブネット(インターネットへのアウトバウンドアクセス可能)とルーティング
インターネットからのインを直接受け付けたくないけど、インターネットへのアウトの通信はしたい、といった用途のものがある場合にこういったレイヤを設けるケースがあります。 例えばアプリケーションサーバーなりコンテナへの直接アクセスはさせたくない場合は、念の為外部から通信の経路がないこのレイヤに配置し、外部からの通信はPublicサブネットに配置したロードバランサー経由としたいけど、アプリケーションから外部のサービスのAPIを固定IPで叩きたい、といったケースです。
NAT Gateway
この場合は、上述の PublicサブネットにNATゲートウェイと呼ばれるコンポーネント(かそれに相当する処理を行うEC2インスタンス)を作成する等しておき、各 Private サブネットでは 0.0.0.0/0 をNATゲートウェイに向かうようにルートテーブルへルーティングを設定します。
NATゲートウェイは起動しておくだけで料金がかかり、止めることはできず、また通信量によっても料金がかかります。 AZ障害の可能性に備え、東京リージョンだと3つのAZのPublicサブネットに1つずつで計3つのNATゲートウェイを起動する場合も多いですが、それだけでも結構な料金になります。 また、開発環境はNATゲートウェイを3つ起動しておくのは流石にコスト高なので1つだけにしておきたい、といった要望もよくあると思います。この場合は各サブネットに割り当てるルーティングテーブルで、0.0.0.0/0 の通信を、特定の1つのNATゲートウェイに向ける形になり、若干の環境差異が生じることになります。構成管理ツールを利用して構築する場合は条件分岐を利用して環境ごとにNAT Gatewayの作成個数とルーティングテーブルの設定を制御する必要があるなどの若干の手間もかかります。
代案として、アプリケーションサーバーなりコンテナをPublicサブネットに配置して、パブリックIPやPublicサブネットを割り当てておく構成があるかと思います。この場合、セキュリティグループやネットワークACLの設定をしっかり行なっておき、外部から余計なアクセスを受け入れないよう設定する必要があります。Public IP だとIPが可変なため、固定のIPである必要がある場合はElastic IPでやりくりする必要があります。Fargateタスクには Elastic IP を使えないので Public IP にするか、アウトバウンドの場合は NAT Gateway を利用できるように構成する必要があるかと思います。
Private サブネット
データベース等の外部に露出させたくないリソースを配置するサブネットになります。 ルーティングは基本的には IPV4 プライベートアドレス内やさらに細かい帯域内のみとなるようルーティングを定義する形になるかと思います。 リソースに割り当てるセキュリティグループも細かく設定しておく方がより安全ではありますがその辺りは設計方針によるかもしれません。
アクセス制限回り
アクセス制限はセキュリティグループやネットワークACLが基本になるかと思います。 ネットワークACLはなかなか複雑でサブネット単位でのアクセス制御になるため影響範囲がやや大きいのに対して、セキュリティグループはリソース単位で割り当てて設定が可能なので、セキュリティグループのみで管理するケースも多いと思います。
他には AWS ネットワークファイアウォール というサービスもありますが、こちらは VPC 単位で設定することになります。料金がかかり、後発のサービスでもあるので私自身は触ったことがありません。
あとは ALB や CloudFront では AWS WAF のルールで IP アドレスでアクセス制限することもできます。
ログ
VPC は VPC フローログを設定一発で出力させることができます。 料金はかかりますが、何かあった時のために出力しておいても良いかと思います。
まとめ
久しぶりにAmazon VPCやネットワークを1から触ってみて、ふと改めて雑多に記載しました。
