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

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

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

## リージョン (Region)
- データセンターが集まった物理的ロケーションのことで、世界に25ヶ所存在する。(2021年8月現在)
- 耐障害性のために、１リージョンに必ず２つ以上のAZがある。
- リージョンによって、利用できるサービスや料金が異なる。
- 最新の技術はバージニア北部などのUSのリージョンでスタートするらしい。
- 下記のように今後もどんどんと増えていく予定。
![AWS_グローバルインフラストラクチャ___AWS.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/370277/8a23100e-1a37-6fc5-10fe-5cce4901d54f.png)（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を行う。
![case-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/370277/14e86ac8-8185-092f-5eeb-72a475cb678b.png)
- 物理的なルータはなく、代わりにソフトウウェアがルーティングを行っている。
- サブネット間での通信はルータなしで直接通信できる。
- デフォルト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名 |

![case-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/370277/14e86ac8-8185-092f-5eeb-72a475cb678b.png)

## ルートテーブル
- パケットをどこに転送するかを定義する。オンプレでいうルータのルーティングテーブルのこと。
- 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名 |

![VPC講座_2.019.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/370277/71e006bc-a989-710a-a292-aa2c7a7ae6ac.jpeg)

- セキュリティを担保できる理由は、プライベートサブネットにあるインスタンスのプライベート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-cloud-tech.com](aws-cloud-tech.com)