0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[AWS] インターネット系ネットワークまとめ [SAA対策]

0
Last updated at Posted at 2026-04-14

はじめに

こんにちは。
プログラミング初心者wakinozaと申します。
勉強中に調べたことを記事にまとめています。

十分気をつけて執筆していますが、なにぶん初心者が書いた記事なので、理解が浅い点などあるかと思います。
間違い等あれば、指摘いただけると助かります。

記事を参考にされる方は、初心者の記事であることを念頭において、お読みいただけると幸いです。

記事のテーマ

  • AWS SAA 取得を目指して学習中です。
  • AWSのネットワークについて、インターネット接続関連のものをまとめました。

目次

1. Amazon VPC
2. インターネットゲートウェイ
3. NATゲートウェイ
4. NATインスタンス
5. Egress-Onlyインターネットゲートウェイ
6. Elastic Network Interface

1. Amazon VPC

1.1. VPC(Virtual Private Cloud)

Amazon VPC(Virtual Private Cloud)は、AWS上に存在する仮想ネットワーク環境です。
AWSでは、デフォルトVPCを利用するか、独自にVPCを作成してリソースを配置します。

VPCは、AWSアカウント作成時、各リージョンに自動的に作成される「デフォルトVPC」とユーザーが独自に作成する「デフォルトではないVPC」が存在します。
この記事では、「デフォルトではないVPC」(以後、VPC)について説明していきます。

VPCは独立したプライベート空間であるため、デフォルトの状態では他のVPCやインターネット空間と通信できません。
しかし、AWS内で構築するサービスによってはインターネット接続が必要な場合があります。

そこで、AWSは、VPCからインターネットを利用するネットワークサービスを複数提供しています。

この記事では、AWSにおけるインターネット接続サービスについて紹介します。
まず、前提知識としてIPアドレスと、ルートテーブルについて説明します。

1.2. IPアドレス

ネットワーク上の住所のような役割を持つ値を、「IPアドレス」と言います。

IPアドレスは、32ビットの情報量を持つIPv4と、128ビットの情報を持つIPv6の 2種類のアドレスが存在します。
IPv4は古くから使われてきたIPアドレスで、新しく導入されたのがIPv6です。
2026年現在は、2種類のIPアドレスが混在しています。

IPv6は、豊富なアドレスがあるため、必要とするリソースにそれぞれIPアドレスを付与可能です。

IPv4は、利用可能なパブリックIPアドレスのリソースが限界に達しているため、アドレスを効率よく運用するための仕組みが多数用意されています。
その一つが、「パブリック(グローバル)IPアドレス」と「プライベートIPアドレス」です。

パブリックIPアドレスは、インターネット上で一意になるIPアドレスです。
AWSにおいても、リソースがインターネットと接続するためには、このパブリックIPアドレスが必要です。

一方の、プライベートIPアドレスは、LANなど閉じられたネット空間内でのみ利用できるIPアドレスです。インターネットでは利用できませんが、閉じられた空間内であれば、自由に割り当てて利用できます。
プライベートIPアドレスを利用することによって、1つのパブリックIPアドレス内で、さらに細かくネットワークを区分けして利用することが可能になるのです。

住所で例えれば、パブリックIPアドレスは住所、プライベートIPアドレスは集合住宅の部屋番号のようなものでしょうか。
もし、隣の集合住宅と同じ部屋番号が使われていても、住所が違えば郵便配達の際に間違えることもありません。

AWSにおいてのプライベートIPアドレスは、VPC内だけで有効なIPアドレスのことを指し、VPC内の他のインスタンスやVPCと接続しているネットワークを利用する際に使用します。
VPC内のリソースには、すべてプライベートIPアドレスが自動的に割り当てられていて、リソースを停止・再起動した後も同一のプライベートIPアドレスが付与されています。

また、VPCやVPC内の分割した空間である「サブネット」を作成する際に、IPアドレスの範囲を指定するCIDRブロックを指定しますが、この時指定しているのも「プライベートIPアドレス」です。
プライベートIPアドレスは、VPC内でのみ有効なものであるため、ほかのVPCと同じCIDRブロックを指定することも可能です。
(VPC同士を連携したり、オンプレミス環境との接続する場合は、同じCIDRを指定すると、通信が正常に行えなくなる場合があります。その際は、CIDRをずらすことが推奨されます。)

では、VPC内のリソースからインターネットを利用したい場合はどうするのでしょう。
インターネットを利用する場合は、やはりパブリックIPアドレスが必要です。
AWSでは、VPCでリソースを設定する際に、パブリックIPアドレスを付与するかどうかを選択できます。
パブリックIPアドレスの付与を選択すると、AWSのパブリックIPアドレスプールからパブリックIPアドレスが付与されます。
つまり、パブリックIPアドレスの付与を選択したリソースは、プライベートIPアドレスとパブリックIPアドレスを両方保有していることになります。

パブリックIPアドレスは、あくまでAWSのパブリックIPアドレスプールから割り当てられたものであり、アカウントやリソースに紐づいた固有のものではありません。
そのため、通常のパブリックIPアドレスは、リソースが停止するとパブリックIPアドレスは解放され、再起動した際は別のパブリックIPアドレスが割り当てられます。
ビジネス用途などで、固定のパブリックIPアドレスを利用し続けたい場合は、「Elastic IPアドレス」を使用します。

Elastic IPアドレスは、AWSアカウントに紐づいた、固定のパブリックIPアドレスです。
割り当てたリソースを停止しても、同様のパブリックIPアドレスを維持できます。また、保有しているElastic IPアドレスを別のリソースに自由に割り当てることも可能です。

1.3. ルーティング

一般的には、「ルーティング」とは、ネットワーク同士をつなぐルーターの機能の一つです。
送られてきたパケット(データ)の宛先IPアドレスを確認して、最適な通信経路を探すための機能を指します。
ルーターの中に「ルーティングテーブル」という対応表があり、その対応表を参照することで、宛先IPアドレスにパケットを送るための経路を決定します。

AWSにおいては、物理的なルーターは存在しません。
そのため、サブネット単位の「ルートテーブル」に、どのネットワークにデータを転送するかというルールを記載します。

サブネットは、ルートテーブルの記載から「パブリックサブネット」と「プライベートサブネット」の2つに分けられます。

パブリックサブネットは、インターネットとの接続を行うインターネットゲートウェイ(後述)へのルーティング設定があるものを指します。インターネットとの直接アクセスが可能であるため、インターネットから直接アクセスしたいリソースを配置します。

プライベートサブネットは、インターネットゲートウェイへのルーティング設定がないものを指します。インターネットから直接アクセスされたくないリソースを配置します。

各サブネットには、1つのルートテーブルを付与することができます。
ルートテーブルが付与されていないサブネットは、VPC全体に適用される「メインルートテーブル」をもとにルーティングされます。

2. インターネットゲートウェイ

次に、インターネット接続に関わるサービスを個別に説明していきます。

インターネットゲートウェイ(IGW)は、VPC とインターネットとの間の通信を可能にする VPCコンポーネントです。

VPC内のリソースがインターネット空間と通信をしたい場合、以下の2つが必要です。

  • VPCにIGWがアタッチされていること
  • リソースがパブリックIPアドレスを取得していること

またIGWは、IPv4とIPv6の両方のトラフィックを処理できます。
IPv4のトラフィックでは、1対1のネットワークアドレス変換(NAT)変換を行っています。
IPv6のトラフィックでは、アドレス変換(NAT)を行わず、IPv6グローバルユニキャストアドレスをそのままスルーでインターネットへ通します。

IPv4のトラフィック処理について詳しく見ていきましょう。
パブリックIPアドレスを保有しているリソースは、同時にプライベートIPアドレスも取得しています。
IGWは、リソースに割り当てられたパブリックIPアドレスとプライベートIPアドレスの対応に基づき、1対1の静的NATを実行します。

具体的な流れを見ていきましょう。
VPC内部では、リソース同士はプライベートIPアドレスを利用して通信を行っているため、IGWまでの通信にはプライベートIPアドレスを利用します。
しかし、インターネットではプライベートIPアドレスは利用できません。
そこで、IGWは、VPC内からインターネットへパケットを送信する際に、IPアドレスの対応を確認し、送信元リソースのプライベートIPアドレスをパブリックIPアドレスに変換して送信しています。
また、インターネットからVPC内のリソースへパケットが送信された場合は、宛先のパブリックIPアドレスをVPC内で有効なプライベートIPアドレスに変換して、VPC内に送信しています。

このような静的にアドレス変換を行うため、VPC内のリソースがインターネットと通信することが可能になります。

IGWはVPCに対して1つのみアタッチ可能です。
複数のパブリックサブネットが存在する場合、共通のIGWを介してインターネットと通信します。

2.1. IGWの可用性

IGWは、特定のAZに依存せず、VPC全体で冗長化されています。
単一障害点(SPOF)とならないように設計されており、高い可用性を実現しています。

2.2. IGWの運用負荷

IGWは、マネージドサービスであり、スケーリングや冗長性はAWSが管理します。
運用負荷は極めて低いといえます。

2.3. IGWの利用料金

VPCにIGWを設置すること自体には料金はかかりません。
しかし、IGWを通過するデータには転送料金がかかります。

インターネットから入ってくるパケットのデータ転送(Data Transfer In)料金は、原則無料です。
IGWを通過してインターネットへ出ていくパケットには、AWS共通のデータ量に応じたデータ転送(Data Transfer Out)料金が適用されます。

データ量 データ転送量(Out)
100GB / 月まで 無料
最初の 10TB / 月 0.09ドル/GB
次の 40TB / 月 0.085ドル/GB
次の 190TB / 月 0.07ドル/GB
150TB超 / 月 0.05ドル/GB

3. NATゲートウェイ

次に、NATゲートウェイについて説明していきます。

NATゲートウェイは、アドレス変換機能を持つNATサービスです。
NATゲートウェイは、インターネットを通信先とする「パブリックNATゲートウェイ」と、他のVPCやオンプレミスを通信先とする「プライベートNATゲートウェイ」の2種類に分かれます。
この記事では、VPCのインターネット通信についてまとめていくため、「パブリックNATゲートウェイ」について説明していきます。

パブリックNATゲートウェイ(以下、NATゲートウェイ)は、主にプライベートサブネットに配置されたリソースがインターネットにアクセスする際に利用されます。

IGWとNATゲートウェイは、いずれもインターネットとの通信を実現するコンポーネントですが、その動作には大きな違いがあります。

IGWは、パブリックIPアドレスを持つリソースに対して、プライベートIPアドレスとの1対1の対応に基づく静的NATを提供します。
IGW自体は通信の状態(セッション)を保持せず、ステートレスに動作します。そのため、インターネットからの通信であっても、宛先となるパブリックIPアドレスが有効であり、かつセキュリティグループやネットワークACLで許可されていれば、そのパケットはVPC内のリソースへ到達可能です。

一方、NATゲートウェイはステートフルに動作するNATサービスであり、VPC内から開始された通信(アウトバウンド通信)の情報を保持します。
そのため、NATゲートウェイは応答トラフィック(リターントラフィック)のみを許可し、インターネットから開始された新規のインバウンド通信はすべて破棄します。

この挙動により、NATゲートウェイを経由するプライベートサブネット内のリソースは、インターネットへのアウトバウンド通信は可能である一方、外部から直接アクセスされることはありません。

プライベートサブネットのリソースがNATゲートウェイを通してインターネットに通信するケースを、具体的に見ていきましょう。

まず前提として、以下の状態を整えます。

  • インターネットを利用したいが、インターネットからの通信は拒否したいリソースをプライベートサブネットに配置する。
  • プライベートサブネットのルートテーブルに、NATゲートウェイのルーティングを記載する。
  • NATゲートウェイに、「Elastic IPアドレス」を付与する。
  • パブリックサブネットに、NATゲートウェイを配置する。
  • NATゲートウェイを配置したパブリックサブネットのルートテーブルに、IGWのルーティングを記載する。
  • VPCにIGWをアタッチする。

パケット送信の往路は、以下の通りです。
1.プライベートサブネットのリソースが、NATゲートウェイにパケットを送信します。
2.パケットを受信したNATゲートウェイは、送信元に記載されたリソースのプライベートIPアドレスを、NATゲートウェイのプライベートIPアドレスに変換して、IGWへ送信します。
3.IGWは、アドレス対応に基づいて、送信元アドレスを、NATゲートウェイのプライベートIPアドレスから、NATゲートウェイに付与されたElastic IPアドレスに変換して、インターネットに送信します。

パケット送信の復路は、以下の通りです。
1.IGWがインターネットからのパケットを受信し、アドレス対応に基づいて、宛先のElastic IPアドレスを、NATゲートウェイのプライベートIPアドレスに変換して、NATゲートウェイへ送信します。
2.パケットを受信したNATゲートウェイは、すでに送信したリクエストの応答だった場合は、宛先IPアドレスを、リソースのプライベートIPアドレスに変換して、リソースへ送信します。応答ではなかった場合は、アドレス変換せずにパケットを破棄されます。

この仕組みにより、安全なインターネット接続が実現されます。

3.1. NATゲートウェイの可用性

AZ単位で冗長化されています。
しかし、もし配置したAZにAZ単位の障害が発生すると、NATゲートウェイの機能がダウンしてしまいます。
そのため、高い可用性を求められる環境では、複数のAZにそれぞれNATゲートウェイを作成して、可用性を高めます。

3.2. NATゲートウェイの運用負荷

NATゲートウェイは、マネージドサービスであり、スケーリングや冗長性はAWSが管理します。

3.3. NATゲートウェイの利用料金

NATゲートウェイの利用料金は、次のNATインスタンスの章で説明します。
NATゲートウェイを通過してインターネットへ出ていくパケットには、IGWと同様、データ量に応じたデータ転送(Out)料金が適用されます。

4. NATインスタンス

NATゲートウェイと同じく、プライベートサブネットからインターネットへの通信を可能にするIPv4専用の機能です。
NATインスタンスは、現在NATゲートウェイへの移行が推奨されていますが、AWS SAA試験対策として情報をまとめていきます。

NATインスタンスは、NATゲートウェイとほぼ同様の働きを担うサービスです。
NATゲートウェイはマネージドサービスなのに対し、NATインスタンスはEC2インスタンス上にユーザー自身がNATシステムを構築・管理する点に違いがあります。
また、障害対応やOSパッチの適用、インスタンス監視などをユーザーが担うため、NATゲートウェイに比べNATインスタンスのほうが設計・運用の負担が大きくなります。
そのため、高可用性と管理コストの観点から、NATゲートウェイへの移行が推奨されています。

NATゲートウェイと比べてNATインスタンスが優れているといえる点は、以下の2つです。

  • 利用料金の安さ
  • ポート転送や、踏み台サーバーとしての利用などのカスタマイズ性

1ドル150円と換算した、NATゲートウェイとNATインスタンスの利用料金の違いは、以下の通りです。

項目 NATゲートウェイ NATインスタンス(t4g.nano)
稼働料金(時間単価) 0.045ドル / 時 0.0042ドル / 時
1ヶ月の稼働費 約32.4ドル 約3.0ドル
Elastic IP 料金 約3.6ドル 約3.6ドル
データ処理料金 0.045ドル / GB 0ドル (EC2通信費に含まれる)
合計目安(データ転送10GB時) 約 6,000 円 約 1,000 円

NATゲートウェイには、稼働料金・Elastic IP 料金・データ処理料金がかかるのに対し、NATインスタンスはEC2インスタンスの稼働料金・Elastic IP 料金しかかかりません。
最小サイズのインスタンスタイプを選択することで、トータルの利用料金を抑えることが可能です。
多少の通信不良なら許容できる個人利用や開発時の利用の場合は、コスト削減のためにNATインスタンスを選択するケースも想定できます。

また、NATインスタンスでは、特定のポートに来たリクエストを、プライベートサブネット内のインスタンスの特定のポートに転送する設定をすることで、特定の条件下でインターネットからプライベートサブネットへの接続を許可するなど、独自のカスタマイズが可能です。
ユースケースとしては、プライベートサブネット内のサーバー等をメンテナンスしたいとします。その場合、NATインスタンスに、目的のサーバーへのポート転送設定をしておくことで、NATインスタンスを踏み台サーバーとして、プライベートサブネットのサーバーへSSH接続するといったことが可能です。
(ただし現在は、踏み台サーバーの用途はAWS Systems Manager Session Managerの利用が推奨されています。)

4.1. NATインスタンスの可用性

NATインスタンスは冗長化されていないため、インスタンスが停止すると、その機能が停止します。
そのため、単一障害点(SPOF)となります。

4.2. NATインスタンスの運用負荷

NATインスタンスは、セルフマネージドのサービスであるため、OS のパッチ適用、監視、スケーリング、障害時の再起動はすべてユーザーの責任です。
運用負荷は高いといえます。

4.3. NATインスタンスの利用料金

NATインスタンスの利用料金は、前述の通りです。
また、NATインスタンスを通過してインターネットへ出ていくパケットには、IGWと同様、データ量に応じたデータ転送(Out)料金が適用されます。

5. Egress-Onlyインターネットゲートウェイ

前述のNATゲートウェイ・NATインスタンスは、いずれもIPv4に対応したコンポーネントでした。
AWSには、IPv6に対応したインターネットへの通信コンポーネントが用意されています。
それが、「Egress-Onlyインターネットゲートウェイ(Egress-Only IGW)」です。

IPv4では、インターネットに接続する際にプライベートIPアドレスをパブリックIPアドレスに変換する作業が必要でした。
しかし、そもそもプライベートIPアドレスという仕組みは、IPv4がパブリックIPアドレスを効率的に運用する必要があったため生まれたものです。
IPv6は、無数ともいえるアドレスが用意されているため、全てのリソースにグローバルユニキャストアドレスを割り当てることが基本となっています。(ただし、IPv6にもユニークローカルアドレス等の非グローバルアドレスの仕組みは存在します)

また、Egress-Only IGWは、VPCからインターネットへ(Egress)の接続開始要求は通しますが、インターネットからVPCへ(Ingress)の接続開始要求は通さないという性質を持ちます。
いわば、IPv6版のNATゲートウェイのような役割を果たす、送信専用のインターネット出口です。

Egress-Only IGWを利用するには、VPCにEgress-Only IGWをアタッチし、プライベートサブネットのルートテーブルに、送信先が「::/0(デフォルトルート)」、ターゲットが「Egress-Only IGW ID」となるルートを追加します。

5.1. Egress-Only IGWの可用性

Egress-Only IGWは、特定のAZに依存せず、VPC全体で冗長化されています。
単一障害点(SPOF)とならないように設計されており、高い可用性を実現しています。

5.2. Egress-Only IGWの運用負荷

Egress-Only IGWは、マネージドサービスであり、スケーリングや冗長性はAWSが管理します。
運用負荷は極めて低いといえます。

5.3. Egress-Only IGWの利用料金

IGWと同様、VPCにEgress-Only IGWを設置すること自体には料金はかかりません。
しかし、そこを通過してインターネットへ出ていくパケットには、データ転送(Out)料金が適用されます。

IPv4でプライベートサブネットを構築するとNATゲートウェイの月額維持費(約5,000円〜)が避けられませんが、IPv6で構成しEgress-Only IGWを活用すれば、その維持費をゼロに抑えつつ、安全な送信専用環境を構築できます。

6. Elastic Network Interface

Elastic Network Interface は仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです。

パソコンなどの機器に物理的に存在する「Network Interface Card(NIC)」のクラウド版と考えると理解しやすいかもしれません。
NICは、物理的なネットワークと通信するための出入り口となる部品のことです。
最近のノートPCでは、LANケーブルを挿す口の内側に設置されていることが多く、LANケーブルと物理的に接続することで、OSから渡されたデータをEthernet(通信規格)で定められたルールで加工・送信・受信する役割を担っています。

NICは、OSI参照モデルでいうレイヤー2(データリンク層)に位置する機器です。
MACアドレスを保持し、OSから渡されたIPパケットにEthernetヘッダをつけてフレームに変換し、ケーブルに送信します。また、ケーブルから受信したフレームのEthernetヘッダを読み取り、IPパケットとしてOSに返す働きを行います。

ENIは、NICとNICに関わるネットワーク上の仕組みを抽象化・カプセル化したものです。
具体的には、ENIに以下の属性を含めることができます。

属性 説明
サブネットの IPv4 アドレス範囲からのプライマリプライベート IPv4 アドレス ENI作成時に必ず1つ割り当てられる「メインのIP」
サブネットの IPv6 アドレス範囲からのプライマリ IPv6 アドレス IPv6有効なサブネットで最初に割り当てられるメインアドレス
サブネットの IPv4 アドレス範囲からのセカンダリプライベート IPv4 アドレス 追加で持たせることができる「サブのIP」。1つのリソースを複数のIPアドレスで運用する場合や、障害時の切り替え用として保持可能です
プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4) 特定の「プライベートIPv4アドレス」に対して紐付けられる、固定のパブリックIP
1 つのパブリック IPv4 アドレス AWSが動的に割り当てる、使い捨てのパブリックIP。インスタンスを停止・再起動すると別のIPアドレスに変わってしまう可能性がある
セカンダリ IPv6 アドレス 追加で割り当てられるIPv6アドレス
セキュリティグループ ENIを通過するパケットに対する「ファイアウォールルールセット」
MAC アドレス レイヤー2(データリンク層)で物理的に一意の識別子。ENIが作成された瞬間に固定されます。
送信元/送信先チェックフラグ 「自分(ENI)宛ではないパケット」や「自分が送信元ではないパケット」を破棄するセキュリティ機能。デフォルトでは有効になっているため、NATインスタンスやルーターとして動作させる場合は、無効にする必要がある。

ENIの最大の利点は、自由に付け替えられる点です。

物理層のNICは、機器と一体化しているため、物理的につけ替えることは困難です。
しかし、ENIは仮想化しているため、ENIを任意のリソースに付け替えることが可能です。
物理的な機器と一体化していたNICとは違い、サーバーなどのリソースとENIなどのネットワーク設定が分離しているため、持ち運び可能な「疎結合」なシステムを実現できます。

6.1. ENI の可用性

ENIはAWSの管理下にある論理的なコンポーネントであるため、ENI単体の可用性をユーザーが管理する必要はありません。
しかし、ENIの機動性を利用することでシステムそのものの可用性を高めることが可能です。

例えば、利用していたEC2インスタンスに障害が発生したとします。新しいEC2インスタンスを作成すると、通常、プライベートIPアドレスは別のものに変わってしまいます。しかし、あらかじめネットワークをENIとしておけば、障害が起きたEC2のENIをデタッチし、新しいEC2にアタッチすることで、IPアドレスを維持したまま、中身のサーバーだけを入れ替えることが可能です。
Elastic IPアドレスでもIPアドレスの差し替えは可能ですが、その他のセキュリティグループやMACアドレスなどの設定はその都度必要になります。
ENIはそれらの設定をまとめて別のリソースに移植できるため、運用コストが低くなります。

注意が必要なのは、ENIは作成したAZ内でしか利用できないという点です。
あるAZで作成したENIを、別のAZのリソースにアタッチすることはできないため、AZ単位の障害に対しては、可用性を発揮できない場合があります。

6.2. ENI の利用料金

ENIの作成・維持費は無料です。

まとめ

インターネット接続設定の時の判断基準をまとめます。

  • 外部からのアクセスが必要(Webサーバー等):
    → リソースをパブリックサブネットに配置 + IGW

  • 外部への通信のみ必要、かつ高い信頼性が重要(本番DBのアップデート等):
    → リソースをプライベートサブネットに配置 + パブリックサブネットにNATゲートウェイを配置

  • 外部への通信のみ必要、かつコストを最小化したい(開発環境や個人開発):
    → リソースをプライベートサブネットに配置 + パブリックサブネットにNATインスタンスを配置

  • IPv6環境で送信専用の出口を作りたい:
    → Egress-Only IGW


記事は以上です。
最後までお読みいただき、ありがとうございました。

参考情報一覧

この記事は以下の情報を参考にして執筆しました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?