AWSにおける重要知識 〜VPC(ネットワーク系)篇〜

目的

VPCとその関連リソースに関する重要知識を学ぶ

VPCのCIDRがRFC1918準拠かどうか

重要度⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️

RFC1918とは？
プライベートIPアドレスとして定められているIPアドレス範囲

RFCはインターネット技術の標準仕様をまとめた文書群のことらしい

RFC1918準拠でないということはインターネット上のIPアドレスと重複している可能性がある
完全にVPC内部で完結した通信であれば問題はないが、将来的に外部システムやSaaSなどと連携した時に詰むので基本的にRFC1918は準拠がマスト

また、内部だけだとしてもNLBのターゲットIPにはRFC1918しか指摘できないなど弊害あり

AWSもVPCはRFC1918準拠を推奨している
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-cidr-blocks.html

そもそもクラウドとかAWSとかいう話ではなく、オンプレやAzureでも同じ話です。

VPCのIPアドレスには余裕を持たせる

重要度⭐️⭐️⭐️⭐️⭐️
後々のリソースの追加はもちろんのことだがAWSでは一つのリソースが複数のIPアドレスを必要とするケースが多い。

VPCエンドポイント(インターフェース)

VPCエンドポイントはアタッチするサブネットのIPアドレスを1つ使用する。
SSM、S3、CloudWatchなどVPCエンドポイントは基本複数あるはずなので注意。

Auto Scalling

EC2をスケールアウトさせて可用性向上を行うサービス
このサービスはスケールアウトの台数分で追加のIPアドレスを必要とする。
追加のIPアドレスが割り当てできない場合はスケーリングが失敗する。

セキュリティグループはステートフル

重要度⭐️⭐️⭐️⭐️⭐️

ステートフルとは？
一方向の通信が許可されていれば、戻りの通信も許可されること

例えば、
セキュリティグループに「inboundの22番ポートを許可」を設定し、EC2にアタッチします。

入ってくるSSHの通信はもちろん許可されますが、EC2からクライアントへ戻っていくSSH通信は許可されていないから一見するとSSHできなさそうです。
しかし、セキュリティグループはステートフルなので実際は可能となります。

ネットワークACLはステートレス

重要度⭐️⭐️
逆にネットワークACLはステートレスです。
入りも戻りもセットで許可しないといけません。

ネットワークACLで通信制御するケースはそこまで多くないので重要度は低いです。(というかVPC単位での制御なので細かい制御をすると事故る)

Amazon Route53 Resolver

重要度⭐️⭐️⭐️
VPC作成時に先頭から +2 のIPアドレスにRoute 53 Resolverが作成される。
これはVPC内部のリソースが名前解決をする際の参照先となる。

Route53 Resolverを深掘りしていく。

EC2内部

EC2を立てると自動的にRoute53 Resolver向きのDNS設定になる。

VPCのCIDR 「10.0.0.0/16」でEC2を立ててみる。
LinuxのDNS参照先設定のファイルである『etc/resolv.conf』を見る

cat etc/resolv.conf

「10.0.0.2」がDNSサーバーとして設定されている。
つまり、EC2は名前解決の際に一番最初にRoute53 Resolverへと問い合わせる。
Route53 Resolverはドメインが内部リソースの場合はその場で返し、外部リソースの場合はさらに別のDNSへと問い合わせを行う。

もちろん、このファイルを消したり、書き換えると終わるので注意。

Route53 Resolverへの通信はセキュリティグループで制御不可能

Route53 Resolverとの通信には「TCP,UDP/53」の穴あけは不要。

一つ実験をしてみる。
EC2に次のセキュリティグループをアタッチして名前解決のコマンドを使用してみる。

↑アウトバウンドの53番は穴あけしてないので本来は名前解決は失敗するのが普通の感覚

↑名前解決できてしまった...

↑さらに上位のDNSサーバーにも届いている

AWSが所有するIPアドレスからの通信

重要度⭐️⭐️⭐️⭐️
これもセキュリティグループで制御できない(全部かどうかはわからない)

自分が出会ったケースだと、VPCフローログで送信元IPアドレスを確認している時にセキュリティグループで弾いているはずのIPアドレスからの通信がACCEPTになっているケースがあった
正直ログの中にあると怪しい通信なのか？AWSの通信なのか？を判断するのが難しい
あらかじめクエリなどでAWSの通信IPアドレスを弾くなどしておくのもありだろう

下記サイトがAWSのIPアドレスである。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ip-ranges.html

Json形式なのでスクレイピングで取得して加工も容易

VPCピアリングのCIDR重複

VPCピアリングとは？
別のVPC同士がエンドポイント経由で通信できるようになるサービス

アカウントやリージョンを跨いだVPCでもピアリング可能

VPCピアリングで接続するVPCのCIDRは重複が許されない

VPC1 : 10.0.1.0/24
VPC2 : 10.0.0.0/16
上のような場合だとNG

VPCフローログは作成後設定変更できない

よくあるのがカスタムログを追加したい場合やログ出力先を変えたいケース
しかし、作り直すしかない

作る前にしっかりと検討が大事