Zenn
⛳

AWS初心者向け~ゼロからECSアプリケーションの構築まで~　ネットワーク編

2025/03/06に公開
AWS
初心者
ECS
tech

2. ネットワーク編

目次
  1. VPC、サブネット、InternetGateway、NAT Gateway、ルートテーブル、ECSアプリケーション用セキュリティグループを設定する。
  2. VPCの説明
  3. サブネットの説明
  4. IGWの説明
  5. NATゲートウェイの説明
  6. ルートテーブルの説明
  7. セキュリティグループの説明

最終的にECSアプリケーションを以下のようなネットワーク構成で作成したい。

1.VPC、サブネット、InternetGateway、NAT Gateway、ルートテーブル、ECSアプリケーション用セキュリティグループを設定する。

1. VPC、サブネット、ルートテーブル、NATゲートウェイの作成

us-east-1リージョン（米国バージニア北部）にVPCを作成する。2つのAZにまたがり
privateサブネット、publicサブネットとpublicサブネットの1つにNATゲートウェイを設定したいため
マネジメントコンソールでVPCも含めたリソースを一括で作成する。
↓以下画像を参考にする。

2. VPCの確認

2Publicサブネット・２Privateサブネットが作成され、Publicサブネットのルートテーブルは1つに作成されている。Privateサブネットは、AZごとにルートテーブルが用意されているので２ルートテーブル存在し、
VPCデフォルトのルートテーブルも存在するため合計4つのルートテーブルが作成されている。

3. ルートテーブルの中身確認

まずPublicサブネットのルートテーブルを確認する。
作成したVPC(10.0.0.0/16）に入る通信は、Publicサブネット内部に送るのでlocalが設定され
それ以外の通信（インターネットから入っている通信）は、全てInternetGatewayに向かうようルートが設定されている。ネットワーク構成の通りのルートとなっているため変更不要である。

3.サブネットについて

基本的には、どのようなリソースを置く空間か、public用・private用かで分けます。
パブリックサブネットは、インターネットゲートウェイへのルートを持つサブネットです。
簡潔にいうとインターネットへの通信が可能なサブネットです。

プライベートサブネットは、インターネットゲートウェイへのルートを持たないサブネットです。

サブネットを作りすぎると利用できるリソース数も減るので、サブネットは必要最低限を作成するように心掛けた方が良いです。
例えばvpcを「10.0.0.0/16」で作成している場合にてサブネットを256個(8bit)分作ります。各サブネットのIP CIDRを/24で構成すると既存のVPCのCIDRから8bit分は埋まるので、各サブネット内に配置できるリソースの数は、8bit分なので256個になります。
つまり10.0.1.0/24というip CIDRのサブネットがあるならそのサブネット内で利用できるリソースのipは
10.0.1.1 ~ 10.0.1.254の範囲になります。
目的にもよりますがPrivateサブネットにECSやRDSなど複数リソースを置く場合には、サブネットのサブネットマスクは、/24では小さいかもしれないので、要注意です。

4.IGWについて

VPC内のリソースとインターネットとやりとりするのに必要なのがInternet Gatewayです。
Internet Gatewayは無料です。

5. NATゲートウェイについて

NATゲートウェイは、Privateサブネット内のリソースがインターネットにアクセスできるようにする役割を持っています。
インターネットと通信するためにはパブリックIPが必要ですが、Privateサブネットに配置したリソースはインターネットから見えるようにはしたくありません。
そこでNATゲートウェイが登場します。NATゲートウェイがインターネットへの通信とプライベートなリソースとのやり取りとの中間に位置しインターネットとのやり取りを担ってくれます。（NATゲートウェイ経由でインターネットゲートウェイに通信を向かわせることで実現します。）

6.ルートテーブルについて

先ほどNATゲートウェイを作成しましたがこれだけでは通信はできません。
通信がどこに向かうかというルートをルートテーブルで決まることで初めてインターネットとの通信が可能になります。
ネットワーク図
で見るようにネットワークとの入り口は、Publicサブネットになります。
こちらでVPCの内側と外側に向かう経路を決めます。
これは一般的に似たような構成になります。

外部（インターネット）からVPC内部に来る通信は、内部リソース宛を指すLocal（VPCのIP CIDR）を指定し、内から外へ向かう通信はInternet Gatewayに向けます。

ルートの適用順序（優先順位）

ルートとして追加した順番通りにはなりません。
公式サイトより以下のようなルールで決まります。そのため一番上に0.0.0.0/0のすべての通信のルートを書いたからといってすべてそのルートを通るようなことはありません。

7. セキュリティグループについて

通信の制御（許可）をするのがセキュリティグループです。
ECSやLambdaなどのAWSリソース単位に設定できます。
インバウンドルール（Ingress）でリソースに入る通信を許可し
アウトバウンドルール（Egress...イーグレスと発音します）でリソースから出ていく通信の許可を設定します。
注意したいのはセキュリティグループのルールはステートフルだということです。
つまりIngressで設定した通信は目的のリソースに到達後レスポンスを呼び出し元に返すために
再度リソースから出ていきますが、これはIngressで許可した通信であることをAWSが覚えているので
アウトバウンドルール（Egress）で上記レスポンスを許可するルールを設定していなくてもEgressの通信は許可されます。
＝＞インバウンドルールで書いた通信をわざわざアウトバウンドルールで書く必要はないということです。

リソース作成時の注意点

作成したリソースを一覧画面で正確に確認すること！！セキュリティグループ作成の失敗時を例にする
マネジメントコンソールでのリソース作成失敗時には、作成しようとしたリソースの残骸がないかは注意が必要です。（これはCDKを利用したスタックのデプロイなどでも同様に注意が必要です。）

  1. セキュリティグループを作成し、説明欄を日本語で記載する。

  2. 説明欄は日本語で入力できないのでエラーになります。

  3. ここで作成画面からは遷移しないので、説明欄を英語にして再度作成します。

  4. なんとセキュリティグループが2つできています！！

上記手順でセキュリティグループが2個できる理由としては、セキュリティグループの作成が正確には２段階に別れているからです。

  1. セキュリティグループそのものの作成
  2. 上記セキュリティグループへのルールの追加

先ほどの説明欄の日本語によるエラーではセキュリティグループの作成自体は完了していますが
Ingress,Egressルールの作成でエラーになったわけです。
ですが作成画面からは遷移しないためあたかも何も作成さえていないように見えてしまうわけです。
これに気づかずセキュリティグループを2個作成し、ルールのない間違ったセキュリティグループを
例えばLambdaなどのAWSリソースに付与してしまうと目も当てられません。（実体験です...）

基本的には作成時の失敗時にセキュリティグループもロールバックされるので
エラーが起きた時に作成していたセキュリティグループが残ることはありませんが
一覧画面で作成したリソースと作成していないはずのリソースがないかも見たほうが良いです。

Discussion