■VPC
※仮想ネットワーク（Virtual Private Cloud）を構築できる（リージョンに対して作成）
※後からの構成変更は大変なので、最初によく検討してから構築する
以前は一度作ったものは一切変更できなかったが、今は条件付きで後から拡張できるようになっているみたい（未検証）
Amazon VPCを「これでもか！」というくらい丁寧に解説 - Qiita
https://qiita.com/c60evaporator/items/2f24d4796202e8b06a77
フロントエンドエンジニアですが、AWS 始めてみます
http://tech.recruit-mp.co.jp/infrastructure/retry-aws-minimum-vpc-server-environment/
カジュアルにVPC作った結果がこれだよ！
http://www.slideshare.net/Yuryu/aws-casual-talks-1-vpc
[新機能] VPCのCIDRが拡張可能になりました！IPアドレス範囲を追加可能です！ | Developers.IO
https://dev.classmethod.jp/articles/expanding-vpc-cidr/
Amazon VPCを使ったミニマム構成のサーバ環境を構築する
http://dev.classmethod.jp/cloud/aws/minimum-amazon-vpc-server-environment/
VPC とサブネット
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Subnets.html
デフォルト VPC とデフォルトサブネット
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/default-vpc.html
Amazon VPC設計時に気をつけたい基本の5のこと
https://dev.classmethod.jp/cloud/aws/amazon-vpc-5-tips/
AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい
https://blog.takuros.net/entry/2019/08/26/090220
■リージョンとアベイラビリティゾーンとサブネット
リージョン内にVPC（仮想ネットワーク）を作成し、
その中にサブネット（サブネットワーク）を作成し、
その中にアベイラビリティゾーンを作成し、
その中でサーバの設置などを行う
作業前に、対象が「東京リージョン」であることを確認する（意図的なら他のリージョンで作業するのも問題ない）
2021年3月に、大阪リージョンが追加された。これにより、日本国内のみでマルチリージョンを実現できる
AWS 大阪リージョン - 2021年3月 誕生! | AWS (アマゾン ウェブ サービス)
https://aws.amazon.com/jp/local/osaka-region/
東京リージョンに新たにアベイラビリティゾーンを追加
https://aws.amazon.com/jp/blogs/news/the-fourth-new-availability-zone-tokyo-region/
なお、複数のアベイラビリティゾーンにサーバを配置する構成を「マルチAZ」と呼ぶ
基本的にマルチAZ構成にしておくことが推奨される
■料金
VPC自体は無料で利用できる
よくある質問 - Amazon VPC | AWS
https://aws.amazon.com/jp/vpc/faqs/
「VPC 自体の作成・使用には追加料金はかかりません。
Amazon EC2 などの他のアマゾン ウェブ サービスの利用料金が、データ転送料金を含めこれらのリソースに指定レートで適用されます。」
AWS VPCの料金 | TechCrowd
https://www.techcrowd.jp/datalink/fee-2/
VPC自体は無料で、VPNやNATを使う場合には利用可能時間をもとに課金されるとのこと。（公式のスライドあり。）
■プライベートIPアドレスの範囲
プライベートIPアドレスには
10.0.0.0 〜 10.255.255.255 ... 大規模ネットワーク向け
172.16.0.0 〜 172.32.255.255 ... 中規模ネットワーク向け
192.168.0.0 〜 192.168.255.255 ... 小規模ネットワーク向け
が使える
ただし 192.168.0.1 など、AWS側で予約されていて使えないアドレスがあるので注意
127.0.0.1 〜 127.0.0.254 はローカルループバックアドレス（自分自身を表す）なので、これも使えない
ネットワーク内のIPアドレス
http://www.pc-master.jp/internet/private-ip-address.html
AWSのVPCの予約IPについての勘違い
https://www.infoscoop.org/blogjp/2015/09/11/awsip/
Amazon VPC IPアドレス設計レシピ
http://dev.classmethod.jp/cloud/aws/vpc-cidr/
0から始めるVPC
https://www.slideshare.net/classmethod/0vpc
※デフォルトVPCのプライベートIPアドレスは 172.31.0.0 になっている
※自分でVPCを作る場合、可能なかぎり大きなサイズで作っておくのが無難
具体的には 10.0.0.0/16 で作っておくといい
■ネットワーク構成例
一般的なものとして、以下のような構成がある
基本的には「1」の構成をもとにすればいい
「2」の構成にするが、「4」に変更することを想定して「Public」「Protected」の2階層にする…というのも有効（むしろ1よりも柔軟でいいかも）
本来Trusted（Private）に置くべきサーバでも、監視のためにDMZ（Public）に置いたりすることはある
その場合、セキュリティグループなどでアクセス制限を行う
1
DMZ ... Webサーバなど配置用
Trusted ... DBサーバなど配置用
2
Public ... Webサーバなど配置用
Private ... DBサーバなど配置用
3
DMZ ... Webサーバなど配置用
Operation ... 踏み台サーバ、デプロイサーバ、バッチサーバなど配置用
Trusted ... DBサーバなど配置用
4
Public ... Webサーバなど配置用
Protected ... DBサーバなど配置用
Private ... 外部と通信させない領域
5
Frontend ... ロードバランサー、直接公開のWebサーバなど配置用
Application ... ロードバランサー配下のWebサーバ、バッチサーバなど配置用
Datastore ... DBサーバなど配置用
【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる ｜ Developers.IO
https://dev.classmethod.jp/server-side/network/vpc-knowhow/
ネットワークやサーバなどを作成する際、名前タグを付けることができる
適当に付けても動作上は問題ないが、最初にルールを決めて名前を付けておくといい
以降の解説では例えばVPCの名前タグは「Develop-VPC」としているが、これはあくまでも一例
「xxsystem-dev-vpc」のように「案件名-環境-vpc」と付けるなども有効
弊社で使っているAWSリソースの命名規則を紹介します ｜ DevelopersIO
https://dev.classmethod.jp/cloud/aws/aws-name-rule/
■VPCの作成
AWS → VPC → VPC（左メニュー） → VPCの作成
名前タグ : Develop-VPC
IPv4 CIDR ブロック : 10.0.0.0/16
IPv6 CIDR ブロック : IPv6 CIDR ブロックなし
テナンシー : デフォルト
と設定して作成
2つ目を作成する場合でも、IPv4 CIDR blockは常に 10.0.0.0/16 でいい
（後に記載するサブネットのように、10.1.0.0/16 とずらす必要は無い）
■サブネットの作成
サブネット（左メニュー） → サブネットの作成
名前タグ VPC アベイラビリティゾーン IPv4 CIDR ブロック
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Develop-DMZ-A Develop-VPC ap-northeast-1a 10.0.0.0/24
Develop-DMZ-C Develop-VPC ap-northeast-1c 10.0.1.0/24
Develop-Trusted-A Develop-VPC ap-northeast-1a 10.0.2.0/24
Develop-Trusted-C Develop-VPC ap-northeast-1c 10.0.3.0/24
と設定して作成
※サーバが3台以上の構成だとしても、2つずつの作成でいい（東京リージョンにAZは2つしかないため。…だったが、後ほど追加された。それでも基本的に2つずつの作成でいい）
作成したサブネットに、自動作成されたルートテーブルが割り当てられていることを確認する
※1つのサブネットには1つのルートテーブルのみ、関連付けることができる
自動作成されたルートテーブルはインターネットゲートウェイを考慮したものではないので、以降で
「インターネットゲートウェイとルートテーブルを作成する。ルートテーブルにインターネットゲートウェイを登録する。そのルートテーブルをサブネットに関連付ける」
とする
※インターネットゲートウェイは、VPCをインターネットに接続する仮想ルーター
※ルートテーブルは、個々のネットワークの宛先への経路一覧を保持しているもの
■インターネットゲートウェイ（仮想ルーター）の作成
インターネットゲートウェイ（左メニュー） → インターネットゲートウェイの作成
名前タグ : Develop-Gateway
と設定して作成
作成したものを選択して「VPCにアタッチ」を押し、先ほど作成したVPC「Develop-VPC」を選択して「アタッチ」
■ルートテーブルの作成
ルートテーブル（左メニュー） → ルートテーブルの作成
名前タグ : Develop-Route
VPC : Develop-VPC
と設定して作成
作成したルートテーブルを選択し、下のタブから「ルート」を選択し、「編集」ボタンを押し、「別ルートの追加」ボタンを押す
送信先 : 0.0.0.0/0
ターゲット : 先ほど作成したインターネットゲートウェイ
と設定して保存
サブネット（左メニュー）
先の手順で作成したサブネットを選択し、下のタブから「ルートテーブル」を選択し、「ルートテーブルの変更」ボタンを押す
「ルートテーブル ID」を先ほど作成したルートテーブルに選択し、下の一覧に追加されたのを確認して「保存」ボタンを押す
インターネット接続を許可したいサブネットすべてに対し、同じ操作を行う
※「すべての宛先（0.0.0.0/0）をインターネットゲートウェイに流す」という設定のルートテーブルを作成したことになる
※ルートテーブルは、インターネット接続を許可したいサブネットすべてに対し設定する。今回は Develop-DMZ-A, Develop-DMZ-C のみ
■セキュリティグループの作成
※セキュリティグループ＝ファイヤーウォール。サーバ一台ごとではなく、グループ単位でファイヤーウォールを設定できる
※セキュリティグループ「default」は編集せずに、Webサーバ用やDBサーバ用に新規作成する
セキュリティグループ（左メニュー） → 「セキュリティグループの作成」
名前タグ : Develop-SSH
グループ名 : ssh
説明 : for develop ssh
VPC : Develop-VPC
と設定して作成
グループ名は、デフォルトのセキュリティグループで「default」という名前が付いているので、小文字の英数字で概要を一言で書けば良さそう
説明は、デフォルトのセキュリティグループで「default VPC security group」と設定されているので、英語で概要を書けば良さそう
作成したセキュリティグループを選択し、下のタブから「インバウンドルール」を選択し、「編集」ボタンを押す
タイプ プロトコル ポート範囲 送信元
SSH(22) TPC(6) 22 203.0.113.9/32 … アクセス元のIPアドレス
カスタムTPCルール TPC(6) 10022 203.0.113.9/32 … アクセス元のIPアドレス
と設定して保存。（ただし22番ポートは後ほど塞ぐ）
同様にして以下も作成する。
名前タグ : Develop-Web
グループ名 : web
説明 : for develop web
VPC : Develop-VPC
タイプ プロトコル ポート範囲 送信元
HTTP(80) TPC(6) 80 0.0.0.0/0 … すべてのIPアドレス
HTTP(443) TPC(6) 443 0.0.0.0/0
名前タグ : Develop-Cache
グループ名 : cache
説明 : for develop cache
VPC : Develop-VPC
タイプ プロトコル ポート範囲 送信元
カスタムTPCルール TPC(6) 11211 0.0.0.0/0
名前タグ : Develop-DB
グループ名 : db
説明 : for develop db
VPC : Develop-VPC
タイプ プロトコル ポート範囲 送信元
MySQL/Aurora(3306) TPC(6) 3306 0.0.0.0/0
■パブリックDNSを割り当てるための設定
AWSでPublic DNS(パブリックDNS)が割り当てられない時の解決法
http://qiita.com/sunadoridotnet/items/4ea689ce9f206e78a523
対象のVPCを選択し、「概要」で「DNS 解決」と「DNS ホスト名」を確認する
デフォルトでは
DNS 解決: はい
DNS ホスト名: いいえ
このようになっているが、この設定ではパブリックDNSは割り当てられない
以下の手順で両方とも「はい」にする
（対象のVPCを選択） → アクション → DNS解決の編集
（対象のVPCを選択） → アクション → DNSホスト名の編集
■RDSからVPCを利用するための設定
AWS → RDS → サブネットグループ → DBサブネットグループの作成
名前 : Develop-DB
説明 : for develop.
VPC ID : Develop-VPC
と入力。さらに
アベイラビリティーゾーン : サブネットを作成したAZ
サブネット ID : DB用に作成したサブネット
を追加し、さらに
アベイラビリティーゾーン : サブネットを作成したAZ（上とは別のAZ）
サブネット ID : DB用に作成したサブネット（上とは別のサブネット）
を追加し、「作成」ボタンを押す
■ElastiCacheからVPCを利用するための設定
Laravelのセッション管理にRedisを指定し、AWSのElastiCacheを利用する - 商売力開発ブログ
https://www.prj-alpha.biz/entry/2018/05/06/230232
AWS → ElastiCache → サブネットグループ → Cacheサブネットグループの作成
名前 : Develop-Cache
説明 : for develop.
VPC ID : Develop-VPC
と入力。さらに
アベイラビリティーゾーン : サブネットを作成したAZ
サブネット ID : DB用に作成したサブネット
を追加し、さらに
アベイラビリティーゾーン : サブネットを作成したAZ（上とは別のAZ）
サブネット ID : DB用に作成したサブネット（上とは別のサブネット）
を追加し、「作成」ボタンを押す
■VPCのトラフィックログを取得する
【新機能】VPC Flow LogsでVPC内のIPトラフィックを監視することができるようになりました! ｜ DevelopersIO
https://dev.classmethod.jp/cloud/aws/introduce-to-vpc-flow-log/
VPC Flow Logsの出力先にS3が追加になって安価に使いやすくなりました ｜ DevelopersIO
https://dev.classmethod.jp/cloud/aws/vpcflowlogs_to_s3/
【AWS】VPCフローログを使ってみた - Qiita
https://qiita.com/noskilluser/items/a8db20c9d614c0f3096e