🙃

VPCの基本①

2023/09/23に公開

VPC

VPCとは？

仮想ネットワーク空間を提供するサービス
VPCを設定する時にはリージョンを設定して作成をする
日本でサービスを考えているのならTokyoリージョンでの作成が基本。
Tokyo以外でも構築することは可能だが、オレゴン（アメリカ）に構築すると物理的な距離の問題でTokyoに比べると少し遅い

複数VPC(マルチVPC)

VPCは複数1アカウントについて複数のVPCを作成することが可能
このような構成を「マルチVPC」を呼ぶ。
※ 1アカウントあたりのVPC作成上限は決められている

AWSには「AWS Organizations」というサービスを利用することで複数アカウントも管理することができる
複数のアカウントを持つことでアカウント別の権限管理をできるようになり、これはAWSが推奨している権限管理設計の一つ

AZ

AZとはDCを1箇所に集めずに1つ以上のDCが集合している地域のこと
Tokyoリージョンの場合AZは4つ選択することができる

ap-northeast-1a
ap-northeast-1b ※現在1bはほぼ使われおらず（選択できない）一部のアカウントのみだけ
ap-northeast-1c
ap-northeast-1d

AZにはそれぞれにAZ IDが付与されている
このAZ IDはここのアカウントでバラバラのAZ

サブネット

VPCを利用するときはサブネットで小さなネットワークに切って利用をする
このときサブネットはAZを跨いで作成することはできない

例）
【CIDR】
VPC 10.0.0.0/21
サブネット 10.0.0.0/24 ⇨ 256個のIPアドレス範囲
※ このときVPCは /16~/28 までで作らないとエラーになる

サブネットを利用するにあたって以下の概念がある

パブリックサブネット（インターネットゲートウェイへのルーティングあり）
プライベートサブネット（インターネットゲートウェイへのルーティングなし）

VPCのCIDRは
/21 などの少し大きめ取っておくことがオススメ
上記環境の場合だとサブネットは /24 がオススメ
※ VPC内にロードバランサーを設置する場合、20個のIPアドレス使っているので注意が必要
※ 最初の4と最後の1つ計5つのIPアドレスはAWSが自動的に利用することになっている

サブネットで使用できないIPアドレスは、下記の通りです。
（ここでは、例として10.0.0.0/24でサブネットを作成したと仮定します）
10.0.0.0　ネットワークアドレス
10.0.0.1　VPCルータ用のアドレス
10.0.0.2　DNSサーバのIPアドレス
10.0.0.3　将来利用のためAWSが予約
10.0.0.255　ブロードキャストアドレス

推奨構成

AWSを設計する上で故障に備えた設計(構成)をすることが推奨されている
そのため、一つのサブネットで管理するのではなく、例えAZ 単位での障害があった場合に備えてサブネット分けた構成を推奨している

VPCコンポーネント

RouteTable

サブネット内のルーティングを定義する
サブネットに関連づけて使用する
LocalはVPC内部のこと（デフォルトである削除できないルートと呼ぶ）
0.0.0.0/0 は全てのIPアドレスのこと

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

インターネットへと通信ができるようにするサービス
VPCにアタッチしてVPCとインターネットを繋げる
自動スケールするためユーザーは管理不要
デフォルトで飛ぶ(0.0.0.0/0)のことをデフォルトゲートウェイと呼ぶ

サブネット

パブリックサブネット外部公開OKなサブネットのこと
プライベートサブネット外部公開NGなサブネットのこと
ルートテーブルの設定によって呼ぶ方が変わってくる

NAT GW

プライベートサブネットがインターネットに接続したい(通信を送りたい)場合に使う
アウトバウンドのみをしたいとき
NAT GWはスケールする
サブネットに配置する

ENI

仮想ネットワークインターフェースのこと
EC２のIPアドレスはENIのこと
EC2に複数ENIが付与可能である
ENIへはSGを設定してセキュリティを強化する
パブリックIPアドレス。インターネットと接続できグローバルIPアドレスのことでIPアドレスプールからランダムに割り当てられる
※ デフォルトの設定のままだとパブリックIPアドレスは可変されてしまい、停止した場合都度パブリックIPアドレスが変わってしまう。都度変更されてしまうとセキュリティの変更や、内部のアプリも変えないといけない場合がある

EIP

先ほどパブリックIPアドレスが動的に変更されると記載しましたがEIPを使う（付与）することで静的IPアドレスを持つことができる

注意点として、EIPを確保しただけの状態（アタッチしていない）だと料金が発生する

追記）　IPv４の場合結局は有料化になってしまう

セキュリティグループ

仮想ファイアーウォールサービス
イン/アウトバウンドで制御可能

SGはENI単位でアタッチされ、IPアドレス範囲やSG単位でルールの設定（拒否や許可）が可能

SGの性質として「ステートフルインスペクション型」となっている
⇨ 簡潔にいうと行きの通信が許可されちれば戻りの通信は自動的に許可が行われる

NACL

サブネット単位で設定するファイアーウォール
ルール設定する時に番号で管理され、数の小さな番号のものから設定が反映されていく

「ステートレスインスペクション型」
⇨ ステートフルインスペクション型とは対照に行きも戻りも明示的に設定が必要になってくる
（状態を持たない）

EC2へのログイン

（動画のがわかりやすいですが、テキストベースで簡単に流れをまとめ）

VPCの作成
サブネットの作成
IGW作成&アタッチ
ルートテーブルの変数(0.0.0.0/0:IGW)
EC2の作成
- キーペアの作成
- VPCの設定
- SGの設定(インバウンドでSSH できれば自分のPCのIP)
ログイン(> ssh -i [キーペア] ec2-user@[EC2のパブリックIPアドレス])※ 権限は400
EIPを付与（固定IPアドレスにするため）
プライベートに配置したEC2の作成
- ローカルから秘密鍵をパブリック側のEC2へとscp
- パブリックのEC2からプライベート側のEC2へとプライベートIPアドレスを使用してSSH
NATGWの作成
プライベートサブネット用のルートテーブルを作成編集(0.0.0.0/0:NATGW)

VPCピアリング

VPC同士での通信ができるようになるサービス

VPCを目的別で分けて作成する設計が多い
例えば、「開発環境VPC」「本番環境VPC」「検証環境VPC」などなど
用途によっては、各VPC間で何らかしらの通信を行いたいっていう時にVPCピアリングを利用する

注意点）

IPアドレス範囲は重複してはいけない（通信がわからなくなってしまう）
VPCピアリングを設定するときはVPC同士で1対１の設定が必要
リージョン跨いだ利用も可能
主にルーティングの設定でVPCピアリングに向けてあげることで通信することが可能
VPCを跨いだ接続できない
行きと戻り両方のルーティングを設定しなければならない（していないと戻りが返ってこないなどになってしまう）

VPCエンドポイント

EC2からS3にアクセスしようとした場合、通信が一度インターネットに出てしまう
セキュリティリスクを考えるとインターネットに出ることがダメな要件も存在する

そんな時にインターネットに出ることなくAWS環境内でAWSサービスと通信できるようするのがVPCエンドポイント
名前の通りでAWSリソースとの通信の終端（VPCエンドポイント）
VPCエンドポイントに2種類ある

インターフェース型

実体はENI（SGを設定することができる）
別名で「PrivateLink」「インターフェースエンドポイント」と呼ばれることがある

利用される例） ECR, RedShift, Kinesis
サービスによって必要となるエンドポイントの数が変わってくる。
実体はENIなのでマルチAZ構成を取ろうと思うと2つ以上必要だったりする
料金は有料となっている

ゲートウェイ型

ルートテーブルを設定して利用する
ゲートウェイ型の対象サービスは「S3」と「DynamoDB」の2つとなっている
料金は無料

ルーティングの際に送信先をプレフィックスリストに向けて上げる必要がある(pl-XXXXXXXXX)

プレフィックスリストとは？
HTTPリクエストでプレフィックスリストにあるIPアドレス
S3であればS3を指すIPアドレスのこと
そのプレフィックスリストにルーティングを設定してあげることでS3を操作できるようになる

VPCエンドポイントDemo

ゲートウェイ型

（動画のがわかりやすいですが、テキストベースで簡単に流れをまとめ）
パブリックのEC2とプライベートのEC2を用意
※ 何もしていない状態だとプライベートのEC2からS3には通信はできない
→ aws s3 ls 打っても何も返ってこない

エンドポイント作成。Gateway型を選択（インターフェース型も存在する）
対象のVPC＋プライベートのルートテーブルを選択
(すでにS3と通信ができている前提でVPCエンドポイントを作成してから通信を行うとソースIPアドレス変わってしまうので、IP制限などしている場合は注意してください)
エンドポイントのポリシーも設定できる
作成完了すると pl-XXXXXXXX がルートテーブルに作成できていることが確認
⇨ もう一度aws s3 ls 打つと値が返ってくるようになる

内部DNSからplのIPアドレスから名前解決してくれてIPアドレスに変換してくれるので通信ができるようになる

インターフェース型の作成

（動画のがわかりやすいですが、テキストベースで簡単に流れをまとめ）
先ほどの環境は同じCloudWatch Logsへの通信はない

VPC選択
サブネット選択
SG選択
⇨ 実体はENI作成されるためSGでのセキュリティ対策ができる

VPC FlowLogs

ネットワークキャプチャを行うことができるサービス

取得することで何がいいのか？
システムの運用状況の把握、トラフィックを確認できる、トラブル発生の問題を解決できるなどなど

ログ（キャプチャ）の保存先は「CloudWatch Logs」または「S3」を選択することができる

キャプチャを取れる範囲（単位）としては以下のようになる

VPC単位
サブネット単位
ENI単位

VPC FlowLogsを利用することでシステムへの
ネットワークのパフォーマンスに影響を与えない

Demo

（動画のがわかりやすいですが、テキストベースで簡単に流れをまとめ）

CloudWatch Logsへと保管することを想定
空のロールを作成（後に設定して、CloudWatch Logsへ保存できる権限を与える）
インラインポリシーの追加を行い、以下ロールの中身に書き換えを行う

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}

次にIAMロールから「信頼関係の編集」を選択してプリンシパルを書き換える

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"(ここを書き換え)
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ログの送信先のCloudWatch Logsのロググループを作成
VPC → VPCFlowLog作成(送信先はCloudWatch Logsを選択)
ログレコードをカスタムできる

Demo Athena分析

（動画のがわかりやすいですが、テキストベースで簡単に流れをまとめ）

S3バケットを作成
VPCFlowLog作成(送信先は先ほど作成したS3を選択(arn利用をする))
S3に保存されたログに対してはあくまで保存までなのでフィルターをかけるなどの分析などができない。そこでAthenaを利用することでS3バケットに対してSQLを実行することができる
Athenaの作成については「統合」でCFnで作成することができるのでそちらで作成する
クエリの結果を保存先のS3選択することができる
事前にクエリサンプルがあるので、そちらのSQLを実行することができる

参考記事

参考) https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/working-with-az-ids.html
参考) https://dev.classmethod.jp/articles/reduce-unnecessary-costs-for-nat-gateway/
参考) https://mtrad-blog.com/2022/09/14/post-3430/
参考) https://biz.nuro.jp/column/aws-mama-063/
参考) https://dev.classmethod.jp/articles/aws-cloudformation-nacl/
参考) https://dev.classmethod.jp/articles/handson-vpc-peering/

VPC

VPCとは？

複数VPC(マルチVPC)

AZ

サブネット

推奨構成

VPCコンポーネント

RouteTable

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

サブネット

NAT GW

ENI

EIP

セキュリティグループ

NACL

EC2へのログイン

VPCピアリング

VPCエンドポイント

インターフェース型

ゲートウェイ型

VPCエンドポイントDemo

ゲートウェイ型

インターフェース型の作成

VPC FlowLogs

Demo

Demo Athena分析

参考記事

Discussion