Zenn
🦥

AWSのVPCってなんやねん

2024/02/24に公開
AWS
Security
tech

自己紹介

どもども、フリーランスエンジニアとして働いている井上弥風です。
ずっとバックエンドメインで仕事をしてきたのですが、インフラ側がヨワヨワ過ぎたので勉強を始めました。

まずはVPCを深掘りして全体像をつかんでいきます。
対戦よろしくお願いします。

VPCとは？

VPCに関して調べてみたところ、公式の説明が下記でした

Amazon Virtual Private Cloud (Amazon VPC) とは、リソースの配置、接続性、セキュリティなど、仮想ネットワーク環境をフルで制御できるサービスです。AWS サービスコンソールで VPC を設定するところから始めます。次に、Amazon Elastic Compute Cloud (EC2) や Amazon Relational Database Service (RDS) インスタンスなどのリソースを追加します。最後に、アカウント、アベイラビリティーゾーン、AWS リージョンを超えて、VPC 同士の通信方法を定義します。以下の例では、各リージョン内の 2 つの VPC 間でネットワークトラフィックを共有しています。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html

何言ってん○○ねん(調べる)

VPCの基本概念

VPCに関して説明している他の記事も見ていくと、大体下記のような説明が多かった

  • AWS上に作成できるプライベート仮想ネットワーク空間
  • AWSが提供している機能の一つで、AWSアカウント内に専用の仮想ネットワーク空間を構築することができる
  • 安全で隔離されたプライベートクラウドであり、パブリッククラウド内でホストされている

VPCの詳細に関しては後述するが、いったん今は「AWS上で自分専用のネットワーク空間を作って & 使って色々出来ちゃう野郎～～！！」って理解でOK

VPCとその他のAWSサービスの関係性って何？

AWSサービスでよく聞くものとして

  • EC2
  • RDS
  • HogeHoge...

などがあるけど、VPCと上記のAWSサービスの関係性に関して説明すると、
「EC2」とか「RDS」とか「HogeHoge」っていうお笑い芸人(各AWSサービス)達がいるんだけど、そのお笑い芸人たちは自分たちが芸をする舞台を持っていないから仕事(漫才)ができない
↓
それだと困るぜ
↓
そこで、VPCはお笑い芸人が芸を行うための舞台として機能してくれる
つまり、「よしもと漫才劇場」っていう環境をVPCが提供してくれて、お笑い芸人(各AWSサービス)はその舞台を使うことで自由に仕事(システムを稼働させる)することができるって感じ

VPCを使用するメリット

VPCを利用するメリットに関して調べてみると

  • 導入コストが低い
  • 簡単に仮想ネットワークを構築できる
  • 拡張性が高い

といった内容が出てきた

上記の内容だけだとあまりピンとこないというか腑に落ちないというか...
なぜ「ピンとこなかった」のかと言うと、

  • 導入コストが低いって何と比べて？
  • 簡単に仮想ネットワークを構築できるって何と比べて？
  • 拡張性が高いって何と比べて？

あたりが不明瞭だからだと思う

これは過去の背景から順に追っていくことで理解できた
そもそも、仮想ネットワークやクラウドの技術が発展する前は、企業や組織が自身のネットワークを構築する場合、主に物理的なインフラストラクチャー（オンプレミス環境）に依存していた

ただ、クラウドに比べてオンプレミスを利用するには下記のようなデメリットが存在する

  • 機械を購入する費用が高い(導入コスト)
  • ネットワークを構築するにあたり土地を用意したり電源を供給してくれる設備を整えないといけない(ネットワーク構築の手間)
  • 物理的な機器の交換には時間や労力がかかる(拡張性)

つまり、オンプレミスと比べてクラウドの方が導入コストだったりネットワーク構築の手間がはるかに低くて、そこがそのままVPCを含むクラウド環境を使用するメリットって感じ
(オンプレミスにももちろん利点はあるけどここでは割愛)

VPCの用途

VPCは様々な用途があるためすべての用途を記載することは難しいので、VPCの一般的な用途を記載する

セキュリティと隔離性

VPCを使用することでAWSリソースをインターネットから隔離したプライベートネットワーク内に配置することができる
後述するが、パブリックサブネットやプライベートサブネット、セキュリティグループやネットワークACLを利用することで一定のセキュリティ水準を担保することができる

用途ごとの使い分け

よく開発案件などに参画していると下記の単語を耳にする

  • 開発環境(dev環境とか)
  • テスト環境(stg環境とか)
  • 本番環境(prod環境とか)

駆け出しの頃は何となく「開発する環境なんだろうな！！」「テストする環境なんだろうな！！」といった理解しかしていなかったけど、VPCを利用することで用途ごとに環境を切り分けることができるっていう超凄いことだった

環境ごとに分けられることの何が良いかと言うと、

  • 「開発環境用」のVPCを作成して、その中にRDSだったりEC2だったりを作成する
  • 「本番環境用」のVPCを作成して、その中にRDSだったりEC2だったりを作成する

例として上記のように開発環境と本番環境を別々のVPCで管理すると、開発環境で誤ってRDSの中のデータをすべて削除してしまったとしても、本番環境のデータには何も影響を及ぼさなくなる
(僕この前間違えてdev環境のDBのデータ消しちゃったので本当に大切だなあ、、と思いました草)

つまり開発環境では自由にアプリの動作確認ができるし、本番環境に影響を及ぼしてしまうかもしれないっていう不安を抱えずに開発を進められるってわけ(すげー)

用途ごとの使い分けができるっていうのは開発からリリース、運用をしていくのにも大切な要素であり便利よねー

VPCの構成要素

ここでは主にVPCと一緒に登場する下記の機能を紹介する

  • サブネット
  • ルートテーブル
  • インターネットゲートウェイ(IGW)
  • NATゲートウェイ

サブネット

「サブネットとはVPCのIPアドレスの特定の範囲を指す」とか言われてもあんまりピンとこない...
上記で記載したが、VPCとは例として挙げるとお笑い芸人が漫才をするための舞台、つまりステージ

そしてサブネットとはステージを分割したものって感じ

なんでステージ分割すんねん問題につながるので、分割する理由を理解しやすいように説明してみる

ちょっとVPCの例をステージから学校に変えてみる
VPCが学校全体だとすると、学校にある個々のクラスが各AWSサービス

もし学校にクラスという概念がなく、下級生から上級生までが一つの場所で勉強していたらどうなる？？？
「えー今日から入学してきた一年生の～～～ちょっともう六年生なんだから遊んでばっかり～～えー四年生になった皆さんは今年から修学旅行が～～」
ってな感じで辛み

だから、学校というVPCの大枠を各用途ごとにクラス(サブネット)で分割したほうが管理したりするのが楽だよね！！
っていうだけ！！

  • 大きな箱→VPC
  • 大きな箱を分割した小さな箱→サブネット

サブネットには「プライベートサブネット」と「パブリックサブネット」という二種類のサブネットがあるのでそれを簡単に説明してみる

プライベートサブネット

「VPCがあって～～サブネットがあって～～サブネットは二種類存在して～～」ってなると頭の整理が大変になってくるんだけど、実際には超シンプルで、
プライベートサブネットはインターネットから直接アクセスさせたくないものを配置するサブネット

学校の例で例えると、外部からのお客さん(地域の人とか子供のご家族)に勝手に入ってほしくない部屋(校長室とか事務関係の資料がたくさんある部屋)がプライベートサブネット

もう少し具体的に説明すると、外部から直接アクセスしてほしくないDBなど重要なデータを置く場所がプライベートサブネット

単純に「勝手に入らないで～！勝手に見ないで～！」の場所がプライベートサブネット

パブリックサブネット

プライベートサブネットはパブリックサブネットの逆バージョン

学校の例で例えると、外部からのお客さんを招く応接室がパブリックサブネット

具体的に説明すると、外部から直接アクセスされてもいい、というか直接アクセスしてもらうべきWebサーバーを置いたりする場所がパブリックサブネット

プライベートサブネットとパブリックサブネットの違い

違いに関しては割と明白で分かりやすい
今まで登場したVPC・プライベートサブネット・パブリックサブネットをAWSの構成図で書いてみると↓こんな感じ

ルートテーブル

そもそもルートテーブルって「特定の何か」ではなく複数あるらしい

  • メインルートテーブル
    • VPCに自動割り当てされるルートテーブル
  • カスタムルートテーブル
    • VPC用に各自設定するルートテーブル

ルートテーブルには複数の種類があるけど、目的は全部同じで「通信の流れを定義した通信ガイドブック」

  • 井上さん宛ての荷物(通信)は神奈川県横浜市~~~に届ける
  • 田中さん宛ての荷物(通信)は東京都千代田区~~~に届ける

上記のように、「○○から来た荷物(通信)」をどこに届けるかを決めたルールブックがルートテーブルっていう理解でOK

で、ルートテーブルはサブネットに関連付ける必要がある
関連付けるっていうのは、ルートテーブルAのルールをサブネットAに適応させますよってことみたい

つまりルートテーブルAをサブネットAに関連付けた場合、サブネットAはルートテーブルAのルールに基づいてルーティングを行う
(詳しくは後述)

メインルートテーブル

ルートテーブルは一般的に用途ごとに手動で作成していくんだけど、「メインルートテーブル」は手動で作成するのではなくVPC作成時に一緒に作成されるルートテーブル
つまりVPCを作成したら自動でメインルートテーブルは作成される

上記で記載した通り、「ルートテーブル」はサブネットに関連付けて利用する
↓
じゃあ意図的にサブネットに何も関連付けなかったらどうなるの？
↓
メインルートテーブルが勝手に適応される！！(うほーー！！)

って感じ
つまり、サブネットには何かしらのルートテーブルを関連付ける必要があるんだけど、何も関連付けていない場合そのサブネットはメインルートテーブルに基づいてルーティングを行うことになる

カスタムルートテーブル

メインルートテーブルはVPC作成時に自動で作成されるのに対して、カスタムルートテーブルは手動で作成しサブネットに関連付ける

ここで「カスタムルートテーブルを作らないでメインルートテーブルをサブネットに関連付ければいんじゃね？」という疑問が生まれるので、その疑問を解消していく

まず、メインルートテーブルは1つのVPC内に1つだけ作成される
そしてサブネットは必要に応じて複数作成できる

サブネットにカスタムルートテーブルを関連付けない場合、上記で記載した通りサブネットにはメインルートテーブルが適応される

例としてメインルートテーブルをサブネットA、サブネットB、サブネットCに関連付けていたとする(具体的にはカスタムルートテーブルをサブネットに関連付けていないのでメインルートテーブルが自動的に各サブネットに関連付けられている)

ここで、サブネットAのルーティング定義を他の物とは別のものにしたい場合どうなるだろう？
サブネットAのルーティング定義を変更するにはメインルートテーブルを修正する必要がある
そしてメインルートテーブルを修正した場合、メインルートテーブルに関連付けられているサブネットA,B,Cすべてのルーティング定義が変わってしまう...

ので、、、、サブネット事にルーティング定義を変えたい場合はカスタムルートテーブルを作成してそれをサブネットに関連付けましょうね、っていう感じになるらしい(圧倒的納得感)

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

まずAWSには「○○Gateway」っていうのがたくさんある
インターネットゲートウェイの説明をする前に「Gateway」って何？って部分をちょっとだけ掘り下げると、AWSで登場する「Gateway」は「データ通信をする際に、その通信がどこを通るか」のまさに「どこ」の部分らしい

そしてその「○○Gateway」の中の一つがインターネットゲートウェイなんだけど、こやつの役割としては単純にVPC内とインターネットをつなぐトンネルのイメージ

インターネットゲートウェイがあるおかげでVPC内部とインターネットとの双方向通信が可能になる

NATゲートウェイ

前提として、プライベートサブネットはVPC外との通信を直接やり取りできない

しかしプライベートサブネットに置いたリソースでも必要に応じてインターネットにアクセスしたい場合がある(APIリクエストなど)

プライベートサブネットからインターネットへ直接アクセスすることはできないが、NATゲートウェイを介することでインターネットにアクセスすることができる

「なぜNATゲートウェイを介して通信を行うのか？」
この問いに対する答えは何とIPアドレスにあった

まず前提として、IPアドレスは主に二種類存在する

  • グローバルIPアドレス
  • プライベートIPアドレス

グローバルIPアドレスは世界中でユニーク(一意)のため、重複を許さない
プライベートIPアドレスは会社や家庭などの組織内（ローカル）で一意に割り当てられるIPアドレスで、組織内では重複を許さないが組織Aと組織Bで重複する分には問題ない

次に、プライベートサブネットに配置される各種AWSのリソース(EC2やRDS...)にはプライベートIPアドレスが割り振られる
プライベートIPアドレスはVPC内でのみ有効であり、インターネット上に存在しているIPアドレスではないため、インターネットに接続することができない

しかしプライベートサブネットでも必要に応じてインターネットに接続したい場合、まず「プライベートIPアドレスからグローバルIPアドレスに変換」をする必要がある

そして、このIPアドレスの変換処理を行ってくれるのがNATゲートウェイっていうわけ！！(すげー！！)

つまり、NATゲートウェイはプライベートサブネットからインターネットへ接続する際にIPアドレスを変換してくれる役割を持っていて、内部(プライベートサブネット)から外部(インターネット)へ接続するためのお手伝いをしてくれる

そしてNATゲートウェイがモテる理由はアウトバウンド接続(内部から外部へのアクセス)のみ機能し、インバウンド接続(外部から内部)は許可しない
つまり内部から外部へのアクセスは可能だが、外部から内部へアクセスされることが無いため、プライベートサブネットのセキュリティが担保される

↓プライベートサブネットからNATゲートウェイを介してインターネットへ接続する例

インターネットゲートウェイとNATゲートウェイの違い

  • インターネットゲートウェイ (IGW)
    • 目的: VPCとインターネットとの間で双方向の通信を可能にする
    • 使用ケース: パブリックサブネット内のリソース（例: ウェブサーバー）がインターネットから直接アクセス可能である必要がある場合に使用される
    • 機能: IGWはVPCに接続され、パブリックIPアドレスを持つリソースがインターネットと双方向に通信することを可能する
  • NATゲートウェイ (NAT GW)
    • 目的: プライベートサブネット内のリソースがインターネットにアウトバウンド接続（外部への通信）を行うことを可能にするが、インターネットからのインバウンド接続（外部からの直接アクセス）は許可しない
    • 使用ケース: プライベートサブネット内のリソース（例: データベースサーバー）がインターネットへのアクセス（ソフトウェア更新など）を必要とするが、インターネットから直接アクセスされることは望ましくない場合に使用される
    • 機能: NAT GWはプライベートサブネット内のリソースからのアウトバウンドトラフィックのIPアドレスをNAT GWのIPアドレスに変換し、インターネットへのアクセスを仲介する。ただし、インターネットからの直接のインバウンド接続をリソースに転送することはない
    • セキュリティ: NAT GWにより、プライベートサブネット内のリソースが外部から直接アクセスされるリスクを低減しつつ、インターネットリソースへの必要なアクセスを提供する

インターネットゲートウェイ・サブネット・ルートテーブル・NATゲートウェイの関連性

一旦今までの内容を整理する
まずインターネットゲートウェイはVPC内(パブリックサブネット)とインターネットを接続するための通信経路として機能する

次にサブネットはVPC内に作成するもので、プライベートサブネットとパブリックサブネットに分類される

  • プライベートサブネット
    • 外部からのアクセスを許容せず、外部と隔離したいリソースを配置する
  • パブリックサブネット
    • 外部からのアクセスを許容し、双方向に通信を行うリソースを配置する

そしてルートテーブルは大きく分けてメインルートテーブルとカスタムルートテーブルに分類される

  • メインルートテーブル
    • VPC作成時に自動で作成されるもので、ルートテーブルを関連付けていないサブネットに自動で関連付けられる
  • カスタムルートテーブル
    • メインルートテーブルと違い手動で作成する必要があり、用途ごとにサブネットに関連付ける
      • カスタムルートテーブルを関連付けたサブネットにはメインルートテーブルは関連付けられない(サブネットに関連付けられるルートテーブルは一つのみだが、ルートテーブルは複数のサブネットに関連付けられる)

次にNATゲートウェイはプライベートサブネットからインターネットへ接続する際のIPアドレスの変換を行う

  • IPアドレスの変換はプライベートIPアドレスからグローバルIPアドレスのみ
  • NATゲートウェイはパブリックサブネットに配置し、プライベートサブネットからパブリックサブネットに配置されたNATゲートウェイを介してインターネットに接続する流れ

VPCの深堀りと周辺知識の理解

ここからは「VPCとは直接関係ないがVPCを使う上で理解しておくべき機能」などを説明していく
VPCに関する内容だけをとりあえず知りたい場合は下の方にある「VPC使ってみたんゴ！！」を見ると実際の利用手順が記載されているので見てみてね

セキュリティグループとネットワークACL

インバウンド・アウトバウンド

セキュリティグループ・ネットワークACLでは下記の概念が登場するので、まず先に下記の説明から入る

  • インバウンド
  • アウトバウンド

と言っても全然難しいものではなく、
インバウンドとは外部から内部への通信方向を意味し、
アウトバウンドは内部から外部への通信方向を意味する

そしてインバウンド・アウトバウンドを許可する・許可しないといった設定をすることで、トラフィックを制御することができる

https://www.seeds-std.co.jp/blog/creators/2022-02-02-194955/

セキュリティグループ

セキュリティグループはEC2インスタンスやELB、RDSやLambda...など(セキュリティグループはインスタンスレベルで動作する)に適応するファイアウォール機能で、主にVPC上に配置するリソースの通信の制御をするために利用される
(ファイアウォールとはネットワークの通信において、その通信をさせるかどうか(許可するかどうか)を判断し許可または拒否する仕組み)

セキュリティグループは下記の二種類に分類される

  • デフォルトセキュリティグループ
  • カスタムセキュリティグループ
デフォルトセキュリティグループ

「デフォルト」・「カスタム」の違いは上記で記載したメインルートテーブルとカスタムルートテーブルに似ている

デフォルトセキュリティグループはVPC作成時に自動で作成されるもので、EC2インスタンス起動時にセキュリティグループを明示的に指定しない場合、デフォルトセキュリティグループが自動で適応される

カスタムセキュリティグループ

カスタムルートテーブルと同じく、カスタムセキュリティグループは自動的に作成されるものではなく手動で作成する必要がある

デフォルトセキュリティグループではなく特定の設定をEC2インスタンスに適応させたい場合などにカスタムセキュリティグループを用途ごとに作成し、適応させるイメージ
例:

  • Webサーバー
    • Webサーバー用のカスタムセキュリティグループを作成
  • メールサーバー
    • メールサーバー用のカスタムセキュリティグループを作成
セキュリティグループの整理

デフォルトセキュリテAWSあります。ネットワーク ACL に明示的にサブネットを関連付けない場合、サブネットはデフォルトのネットワーク ACL に自動的に関連付けられます。
ネットワーク ACL を複数のサブネットに関連付けることができます。ただし、サブネットは一度に 1 つのネットワーク ACL にのみ関連付けることができます。サブネットとネットワーク ACL を関連付けると、以前の関連付けは削除されます。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html

カスタムネットワークACL

カスタムネットワークACLはカスタムセキュリティグループと同じく、VPC作成時に自動で作成されるのではなく手動で作成する必要がある

カスタムネットワークACLは任意のサブネットに割り当てることができ、上記で説明した通りカスタムネットワークACLが割り当てられていないサブネットににはメインネットワークACLが割り当てられる

ステートフル・ステートレス

  • セキュリティグループはステートフル
  • ネットワークACLはステートレス

// TODO: アプリ開発におけるステートフル・ステートレスとAWSのコンテキストにおけるステートフル・ステートレスが若干異なる(異なるというよりそれらが指す対象??)気がしており、私自身まだ完全に理解できていないので理解出来次第詳細記載します

セキュリティグループとネットワークACLの違い

デフォルトのインバウンド・アウトバウンド設定
  • セキュリティグループ
    • インバウンド: すべて拒否
    • アウトバウンド: すべて許可
  • ネットワークACL
    • インバウンド: すべて許可
    • アウトバウンド: すべて許可

セキュリティグループはインバウンドを許可すると、インバウンドに対する応答としてのアウトバウンドトラフィックが自動的に許可される

僕がここで誤解していたのは、セキュリティグループはインバウンドを許可するとアウトバウンドも許可されるのだと思っていた

つまりインバウンド(外から内)のアクセスを許可したら、アウトバウンド(内から外)も許可されると思っていたのだが、実際には許可したインバウンドの応答(アウトバウンド)のみが許可されるだけで、この動作は「応答」のトラフィックに限定されるという点が重要だった

※セキュリティグループのデフォルト設定では、アウトバウンド通信は全て許可されている
EC2インスタンスから外部のサービスへのリクエストは、特別なアウトバウンドルールを設定しなくても可能みたい
ただし、セキュリティ上の理由から特定のアウトバウンド通信のみを許可したい場合は、アウトバウンドルールを明示的に設定して、必要な通信だけを許可するようにする必要がある
これにより、不要な通信を制限し、セキュリティを強化することができる

ネットワークACLはインバウンドを許可したからといってアウトバウンドが自動的に許可されるわけではないため、インバウンド・アウトバウンド両方を許可したい場合は明示的に設定をする必要がある

ホワイトリスト・ブラックリスト形式
  • セキュリティグループ
    • ホワイトリスト形式
  • ネットワークACL
    • ブラックリスト形式でありホワイトリスト形式(詳細は下記)

いきなりなんのこっちゃって感じだけどここはめっちゃ簡単

セキュリティグループは許可する通信のみを定義するホワイトリスト形式
(お笑いライブに入場できないお客さんを把握するのではなく、入場できるお客さんのみ把握しておけばよいイメージ)

ネットワークACLは許可しない通信のみを定義するブラックリスト形式
(お笑いライブに入場できるお客さんを把握するのではなく、入場できないお客さんのみ把握しておけばよいイメージ)
.
.
.
とよく色々な記事で紹介されているが、ここは若干誤りがある

ネットワークACLは実際にはホワイトリスト形式であり、ブラックリスト形式とも言える

単純にネットワークACLは許可・拒否するトラフィックを両方定義することができるため、両方の動作が可能なため「完全なブラックリスト形式」とは言えない

セキュリティグループが明確に「許可する通信のみを定義する」というホワイトリストの概念に基づいているのに対して、ネットワークACLが「許可しない通信を定義する」というブラックリストの動作も可能であることから、対比のためにブラックリスト形式と表現されていると思うが、実際にはネットワークACLが許可する通信を定義する能力も持っていることを適切に反映していないため、この点は理解しておくといいかも

  • セキュリティグループに何も定義していないとデフォルトでインバウンド通信を拒否し、アウトバウンド通信を許可する
  • ネットワークACLは許可または拒否する通信を明示的に定義することが可能であり、デフォルトで全ての通信を許可する設定がされているのは、AWSが提供するデフォルトのネットワークACLの場合
    • 新しく作成されたネットワークACLには、デフォルトでルールが存在しないため、全ての通信が拒否される

VPCピアリング

VPCピアリングは異なるVPC間の通信をする際の接続方法で、VPCピアリングを使用する主な利点の一つは異なるVPC間でセキュアな通信を実現することができる点にある

VPC ピアリング接続は、2 つの VPC 間でプライベートなトラフィックのルーティングを可能にするネットワーキング接続です。ピア接続された VPC のリソースは、同じネットワーク内に存在しているかのように、相互に通信できます。VPC ピアリング接続は、自分の VPC 間、別の AWS アカウント の VPC との間、または別の AWS リージョンの VPC との間に作成できます。ピア接続された VPC 間のトラフィックは、パブリックインターネットを経由しません。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-peering.html

VPCピアリングの利用例

例として、株式会社トマトネギという会社が開発部門と営業部門で異なるVPCを利用していたとする

開発部門のVPCではVPC内で開発・テストが行われており、営業部門のVPC内では顧客管理システムが既に稼働している

開発部門のアプリケーションは営業部門の顧客管理システムから顧客データを取得して様々な処理を実行したいのだが、セキュリティ的に顧客管理システムをインターネット経由でアクセスさせたくない

このような場合にVPC間の接続ができるVPCピアリングを利用することで、安全にプライベート通信を行うことができる

具体的になぜインターネット経由でアクセスさせたくないのか？

「インターネット経由でアクセスができる」というのは、つまり外部からアクセス可能なエンドポイントを持つという事に他ならない

つまり世界に公開されたインターネット上に自社の重要なデータが保管された場所への入場ゲートをこちらから用意するようなもので、外部はそのエンドポイントにアクセスできてしまう
(具体的にはアクセスはできるものの認証などで弾かれるが、「そのエンドポイントを呼び出すこと自体は可能、つまり呼び出し自体は成功する」というのが問題)

何が問題かというと、インターネット経由でアクセスできるようにエンドポイントを持つという事は、インターネット経由を経由する通信の傍受・改ざん・中断といった様々なセキュリティ脆弱性にさらされてしまうとも言える

つまりインターネット経由でのアクセスを許可する場合、入場ゲートをこちらから用意しており、入場してほしくない人(アクセス)を警備員(セキュリティグループやネットワークACL、WAF（Webアプリケーションファイアウォール）、IDS/IPS（侵入検知・防御システム）)などがずっと監視しておく必要がある
これらの警備体制を適切に整えること自体が一苦労な上に、セキュリティ設定を変更する際は細心の注意を払わなくてはいけないため一つの設定ミスが命取りになる

具体的に、なぜVPCピアリングによる通信は安全なのか？

公開ネットワーク経由の通信に対して、VPCピアリングによる通信はAWS内部のネットワークを通過する
この時点で通信の傍受、改ざん、中断といったリスクを大幅に減らすことができる

またVPCピアリングによる通信を行う際はパブリックIPアドレスを用意する必要がないというのも大きなメリットである

パブリックIPアドレスを持つというのはイコール公開エンドポイント(外部からの入場ゲート)を持つという事に他ならない

これに対してプライベートIPアドレスは特定のネットワーク内(この場合はVPC内)でしか有効ではないIPアドレスのため、外部からのエンドポイント、つまり入り口を持たずに済む

つまりパブリックIPアドレスを持たないという事は外部からの直接的なアクセスポイントを提供しないという事でもあるため、VPCピアリングによる通信は公開ネットワークを利用した通信より安全と言える

VPN接続

VPN接続とはインターネットという公共のネットワーク上にプライベートな通信チャネルを作成して接続する技術

VPNの機能とメリット

  • 暗号化
    • VPNはデータを暗号化することで、通信内容が第三者によって傍受されたとしても、解読されにくくする
      • 電車での通勤を例にとると、VPN接続の暗号化は、通勤者が所持品や貴重品を透明なカバンではなく、「不透明でロック付きのケース」に入れて持ち歩くようなもの
      • 万が一スリに遭っても、ケースを開けることができず、盗まれた物が悪用されるリスクが低くなる
  • 仮想的な専用線
    • 物理的な専用線を敷設する代わりに、インターネット上に仮想的な「専用線」を作成する
    • これにより、高額なコストをかけずに専用線と同等のセキュリティとプライバシーを実現できる
    • 例として公共の道路を使いながらも、自分だけの見えないトンネルを通って会社に通勤しているようなイメージ
  • アクセス制御
    • VPNを通じて、特定のネットワークリソースへのアクセスを制限することができる
    • これは、特定の人だけが使える専用の入口を設け、許可された人のみが通過できるようにするイメージ

VPNとVPCの利用例

  • オンプレミスネットワークとクラウドの接続
    • データセンターやオフィスネットワークからクラウド上のVPCへの安全なアクセスが必要な場合、VPNを使用してVPCに接続する
    • これにより、オンプレミスなどからVPC内のリソースへ安全にアクセスできるようになる
  • 異なるクラウド環境間の接続
    • 異なるクラウドプロバイダー間、または異なるクラウドリージョン間でVPCを安全に接続する必要がある場合、VPNを用いてこれらのVPC間に安全な通信路を確立できる

まあ色々記載したけど「安全に通信できるトンネルなんだなー」って感じ

AWS Transit Gateway

Transit Gateway は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを相互接続するために使用できるネットワークの中継ハブです。クラウドインフラストラクチャがグローバルに拡張されるにつれて、リージョン間ピアリングはAWSグローバルインフラストラクチャ AWS データセンター間のすべてのネットワークトラフィックは、物理層で自動的に暗号化されます。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/what-is-transit-gateway.html

AWS Transit Gatewayとは、AWS（Amazon Web Services）で提供されているネットワークトランジットハブサービス、、と言われても理解しにくいし文章で理解するより図を見たほうが分かりやすいかも
↓書いてみた

このサービスを利用することで、AWS上の異なるVPC（Virtual Private Cloud）、オンプレミス環境、さらには他のクラウドサービスとの接続を一元管理できるようになる

VPCピアリングとの違い

VPCピアリングは、2つのVPC間で直接接続を確立し、プライベートIPアドレスを使用してリソース間で通信することを可能にするAWSのサービス

つまり多数のVPC間で通信を行う場合、各VPC間でピアリング接続を個別に設定する必要があり、その管理が複雑になりがち

なので複数のVPC間を接続したい場合にAWS Transit Gatewayを利用することでVPC間の接続が容易になる他、管理の手間を大幅に削減できる

AWS Direct Connect

AWS Direct Connectは、オンプレミスのデータセンターやオフィスとAWSクラウド間で専用の物理接続を確立するサービス

この接続を通じて、インターネットを介さずにAWSのリソースにアクセスできるため、通信の安定性が向上し、より低い遅延でのデータ転送が可能になる

VPCエンドポイント

VPCエンドポイントはVPCからAWSのパブリックサービス(S3, DynamoDB...)へのプライベートなアクセスを可能にする機能

深掘り

VPCエンドポイントはVPCがインターネットを介さずにAWSのパブリックサービスにアクセスするために利用されるもの

上記で記載した通りだが、VPCエンドポイントはVPCとAWSとは全くの無関係な外部サービスとのプライベートな通信をするためのものではなく、あくまでVPCとAWSのパブリックサービスとの接続をプライベートに通信するための機能

VPCエンドポイントを使う理由

「VPCとAWSのパブリックなサービスってどちらもAWSのサービスだから通信もプライベートになる訳ではないんだ..」と素人意見を持ってしまった
(というかあまりAWS側を触れてこなかったのでプライベート or パブリックを意識したことがなかった)

まず前提から調べていくと、例としてVPCとS3がどちらもAWSが提供するサービスだからと言って両者の通信がプライベートなわけではなく、普通にインターネットを介して通信される
(というか多くのAWSサービスはデフォルトでインターネット経由でアクセスされ、それはAWS内のサービス間であっても同様)

しかし通信内容が非常に重要であり、セキュリティ的にインターネットを介さずプライベートに通信をしてセキュリティを担保したい場合も存在する

そんなときに使用するのがVPCエンドポイントって訳で、こやつを利用することでプライベートな通信を実現できる

VPCピアリングとなんか似てね？

VPCピアリングは、異なるVPC間でのプライベート通信を可能にするサービスであり、VPCエンドポイントはVPCからAWSのパブリックサービスへのプライベート通信を提供するといった違いがある

AWS PrivateLinkは自分のVPCから他のVPC内のサービスやS3,DynamoDB、AWS Marketplaceを通じて提供されるサードパーティーのアプリ、オンプレミスなどにプライベートにアクセスできる
// TODO: 詳細は今度(脳内コンパイルエラー)

VPCエンドポイントとAWS PrivateLinkの違い

  • VPCエンドポイント
    • VPCとAWSのパブリックサービスへのプライベートなアクセスに特化している
  • AWS PrivateLink
    • VPCエンドポイントより広範囲に綿sリプライベートなアクセスが可能

まあVPCエンドポイントは特定の用途に特化していてAWS PrivateLinkはその上位互換って感じなのかな(時間ある時にちゃんと書きやす)

VPCフローログ

結論から言うとVPCフローログはVPCのネットワークインターフェイスとの間で行き来するIPトラフィックに関する情報をキャプチャ(保存)できるようにする機能

結構面白いので詳細を記載する

ネットワークインターフェイスとの間で行き来するIPトラフィックの情報をキャプチャする

VPCフローログは、Amazon VPC内のネットワークインターフェースを通過するIPトラフィックの情報を記録する
記録する情報としては

  • 送信元のIPアドレス
  • 宛先のIPアドレス
  • 使用されたポート番号
  • 使用されたプロトコル
  • トラフィックが許可されたか拒否されたか

上記のような情報が記録される

記録したデータ(フローログデータ)はCloudWatch LogsやS3に対して発行する

フローログデータは、分析やアーカイブのためにAmazon CloudWatch LogsやAmazon S3バケットに送信される
これにより、ユーザーはログデータへ簡単にアクセスすることができ、過去のログを調査することができる

ネットワーク通信には影響を及ぼさない

VPCフローログはネットワークのパフォーマンスに影響を与えずに運用される
つまり、フローログのキャプチャやログデータの発行がネットワークのスループットやレイテンシーを悪化させることはない(これすげー)

フローログデータの取得から発行までは数分の時間差があるためリアルタイムではない

フローログデータのキャプチャとログデータの発行にはタイムラグがある(数分程度)
そのためフローログはリアルタイムの監視ツールとしては使用できないものの、セキュリティ分析やトラブルシューティングにはめっちゃ便利

まとめ

初めてzennの記事を書いてみました
書いてみて感じた反省点として下記です

  • 1記事に詰め込み過ぎ草
  • 各サービスごとに記事を書いた方が自分もそのサービスにのみ集中ができるし、読者の方もそっちの方が楽な気がする
  • 深掘りしきれない点・理解しきれない点が部分的にあったのでどこかのタイミングで埋めていきたい

記事を書きながら感じたことは下記です

  • AWSってめっちゃサービスあるやん(当たり前)
  • AWSの各サービスをしっかりと理解するにはインターネットの知識は必須
    • IPアドレスだったりIPアドレスの範囲だったりhogehoge...
  • 記事を書くことでoutputができるため色々と学習にはなるが、書くだけじゃなく実際に使った方がもっと理解できる

Discussion