なぜAWSのネットワーク分野を選んだのか？

現在、某SES企業でひよっこネットワークエンジニアである（業務は完全にオンプレのみ）
オンプレとクラウドにおけるネットワークに違いについての理解を深めたい
ネットワークは不可欠だが、軽視されている（気がする）
これから受検予定のAWS ANS対策

前提

まずは大前提となる、AWSグローバルインフラストラクチャ（リージョン、AZ）について簡単にまとめる。それを踏まえて、VPCとそれに乗っかるAWSサービスを一つずつ見ていく。
自分がわかる範囲で、オンプレのネットワーク技術との関連付けや比較も行っていきたい。

リージョン (Region)

データセンターが集まった物理的ロケーションのことで、世界に25ヶ所存在する。(2021年8月現在)
耐障害性のために、１リージョンに必ず２つ以上のAZがある。
リージョンによって、利用できるサービスや料金が異なる。
最新の技術はバージニア北部などのUSのリージョンでスタートするらしい。
下記のように今後もどんどんと増えていく予定。（From: https://aws.amazon.com/jp/about-aws/global-infrastructure/?p=ngi&loc=1）

アベイラビリティゾーン(Availability Zone, AZ)

論理的データセンター群であり、耐障害性のため、それぞれが隔離されて構成されている。
全部で81ヶ所存在する(2021年8月現在)。
セキュリティーの関係上、場所は非公開。
同一AZ内は高速通信が可能。

各種ネットワーク関連サービス

VPC (Virtual Private Cloud)

AWSクラウド内の論理的に分離された仮想プライベートネットワークのこと。
作成する際にIPアドレスレンジをCIDR形式で指定する(例 10.0.0.0/21)。作成後はアドレスレンジを変更できないため、大きめにとっておく（サブネットのところで記述あり）。
あくまで閉じたプライベートネットワーク空間であり、インターネットにつなぐにはインターネットゲートウェイ(Internet Gateway, IGW)が必要となる。これはインターネットとの境界に設置されたルータの役割。IGWでNATを行う。
物理的なルータはなく、代わりにソフトウウェアがルーティングを行っている。
サブネット間での通信はルータなしで直接通信できる。
デフォルトVPCは予めサブネットやインターネットゲートウェイが設定されている。例えば、バージニア北部であれば、VPCは172.31.0.0/16で、下記のようにus-east-1aからus-east-1fの６つのサブネットが作成されている。

デフォルトVPC	172.31.0.0/16

サブネット	AZ
172.31.0.0/20	us-east-1a
172.31.16.0/20	us-east-1b
172.31.32.0/20	us-east-1c
172.31.48.0/20	us-east-1d
172.31.64.0/20	us-east-1e
172.31.80.0/20	us-east-1f

以前はデフォルトVPCを削除してしまった場合、自分で作り直しができず、AWSサポートに申請が必要だったらしい。今は自分で作成が可能（ https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html )。
一つのアカウントで、開発用などの用途によって複数のVPCを使い分けることも可能（マルチVPC）。

サブネット

大きなネットワークを小さく分割したもの(サブネットワーク)。これによって、セキュリティを高める。
/24などのCIDR表記を用いる。拡張することを考えて大きめに設定することが望ましい。
AWSで利用できるのは/16-28の範囲のみ（/29以降だとAuto Scalingできないため）。

CIDR	サブネットマスク	IP総数
/16	255.255.0.0	65,536
/17	255.255.128.0	32,768
/18	255.255.192.0	16,384
/19	255.255.224.0	8,192
/20	255.255.240.0	4,096
/21	255.255.248.0	2,048
/22	255.255.252.0	1,024
/23	255.255.254.0	512
/24	255.255.255.0	256
/25	255.255.255.128	128
/26	255.255.255.192	64
/27	255.255.255.224	32
/28	255.255.255.240	16

下記のように、一部のホストアドレスは予約されているため、実際には利用できない。

ホストアドレス（例: 10.0.0.0/24）	利用用途
.0 (10.0.0.0)	ネットワークアドレス
.1 (10.0.0.1)	VPCの仮想ルータが使用
.2 (10.0.0.2)	VPC上でAWSが提供するDNSサービスで使用
.3 (10.0.0.3)	将来的な拡張に備え、AWSが予約済み
.255 (10.0.0.255)	ブロードキャストアドレス (VPCではブロードキャストはサポートされません。)

(AWS認定アソシエイト資格対策より引用)
※オンプレと共通で使えないホストアドレスは、ネットワークアドレスとブロードキャストアドレス。

高可用性のため、サブネットは複数に分ける。
IGWがアタッチされ、インターネットへの通信が可能なパブリックサブネットとインターネットへの通信ができないプライベートサブネットに分けられる。※ただIGWをアタッチするだけでなく、ルートテーブルを変更する必要あり（下記に詳細あり）。

インターネットゲートウェイ (Internet Gateway, IGW)

マネージド型サービスで高い冗長性・高可用性があり、自動スケーリングが可能。
VPCにアタッチすることで、VPC内のリソースがインターネットに接続できるようになる。
ただアタッチするだけではなく、下記のようなルートテーブルへのルートの追加も必要。
このようなルートテーブル（後述）が関連づけられた、インターネットに接続できるサブネットをパブリックサブネットという。

送信先	ターゲット
10.0.0.0/16	local
0.0.0.0/0	igw-id名

ルートテーブル

パケットをどこに転送するかを定義する。オンプレでいうルータのルーティングテーブルのこと。
localとはVPC内部のことを指しており、こちらはデフォルトで設定されている。
特に何も設定しなくても、VPC内の通信はルーティングされるようになっている（ただしSGなどの設定は必要）

送信先	ターゲット
10.0.0.0/16	local
0.0.0.0/0	igw-id名

NATゲートウェイ (NAT Gateway)

マネージド型サービスで高可用性である。
プライベートサブネットに配置したDBサーバなどを、インターネット経由でソフトウェアの更新をしたいときに使用する。
NAT GWを作成する際、固定のパブリックIPアドレスであるElastic IP(EIP)を取得する。
EIPアドレスを持つNAT GWを使うことによって、プライベートサブネットにあるEC2インスタンスは、NAT GWを経由してインターネットで出ることができる（下図参照）。

送信先	ターゲット
10.0.0.0/21	local
0.0.0.0/0	nat-id名

セキュリティを担保できる理由は、プライベートサブネットにあるインスタンスのプライベートIPアドレスをNAT GWでEIPに変換してIGWへ抜けるから。
NAT GWがサービス開始する前には、NATインスタンスを利用していたが、現在は非推奨。理由は専用のAMI用いてEC2インスタンスでNATをする、管理する必要が生じるから。基本的にはマネージド型のNAT GWが推奨されている。

AWSでのIPアドレス

サブネット内のDHCPサーバがElastic Network Interface (ENI)に対してIPアドレスを割り当てる。
AWSのリソースにはパブリックIPアドレス（任意）、プライベートIPアドレス（必ず）がある。また、プライベートIPアドレスさらにプライマリプライベートIPアドレスと追加で設定できるセカンダリプライベートIPアドレスに分類できる。
パブリックIPアドレスを付与できるが、AWSは基本的にプライベートIPアドレスで動いている。したがって、EC2インスタンス上でifconfigコマンドを実行しても、ENIのプライベートIPアドレスしか表示されない。EC2インスタンスとインターネット通信は全てNAT変換されているから。
パブリックIPアドレスを確認するには、curl http://169.254.169.254/latest/meta-data/public-ipv4 を実行する。
curlコマンドは他にも色々なメタデータを取得可能。

[ec2-user@ip-10-0-0-197 ~]$ curl http://169.254.169.254/latest/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hibernation/
hostname
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups

仮想ファイアウォールのSGとNACL

下記はSAA対策でもよく見るSGとNACLの比較表。

	Security Group	Network Access Control List
動作対象	インスタンス	サブネット
ルール	許可のみ	許可と拒否
動作	ステートフル（戻りの通信は設定不要）	ステートレス（戻りの通信は要設定）
ルールの適応	すべてのルールから、トラフィックを決める	順番にルールを適用し、トラフィックを決める
設定数	複数可	１つだけ

特定のSGを設定したEC2インスタンスとだけ通信することも可能。動的にIPアドレスが変わってしまう時には、アタッチするSGでインスタンスを特定するときもできる。
同じSGが設定されているEC2インスタンス同士は無制限に通信できる（らしい）。
デフォルトのSGでは、送信元が自分自身のSGルールとなっているため、デフォルトSGをアタッチすることで簡単にEC2インスタンス同士ので通信が可能。
NACLはルータのACLと似ている。例えば、許可/拒否の設定が可能なこと、リストの上から順番に適用されていくこと、最後に暗黙のdenyがあること、インバウンド、アウトバウンド両方を設定可能なことが挙げられる。
ある特定のIPアドレス範囲との通信の許可/拒否を設定する際にはNACLを使い、プロトコルなどの指定はSGで行う。

疑問点

サブネットに分けると、オンプレではブロードキャストドメインを小さくすることでルータの処理負荷を減らすメリットがあるが、AWS（クラウド）ではこの部分はあまり関係がない？
サブネットマスクの表記（255.255.255.0）はあまり見かけない気がするが、AWSでは基本的には用いない？
AWSのNATの設定がオンプレと異なり、随分と設定がシンプルである。CiscoルータのNATでDynamicやStatic、NAT poolやらoverloadなどなどオンプレで設定することはAWSでは不要？

最後に

次回は他のVPCやオンプレとの接続ができるVPC PeeringとDirect Connect、VPNあたりを扱っていきたい。

この記事はAWS初学者を導く体系的な動画学習サービス
AWS CloudTechの課題カリキュラムで作成しました。
aws-cloud-tech.com

AWSにおけるネットワークと関連技術についてまとめてみた