【AWS】VPC Reachability Analyzer が発表されたので見てみた

----------------------------------------
本記事は**[ Advent Calendar 2020 ](https://qiita.com/advent-calendar/2020/htc)**の2020/12/13分です。
※Advent Calendar 2020 へはHTCのチームメンバー5人で
毎日日替わりで投稿させていただいていますので、暇なときに覗いてください。
※HTCの紹介は[本イベント1日目の投稿](https://qiita.com/koooota/items/d5b8b036d3b6541a4f63)をご参照ください。

----------------------------------------
文系学部卒SIer新人の**かいと**です。

今回は、AWS re invent 2020にて、**VPC Reachability Analyzer**が発表され、
[前回投稿した記事](https://qiita.com/k-u2nomiya/items/22be5142ae3b68951ba9)にて、書かせていただいたネットワーク周りの悩みを
早速解決してくれそうなので、確認してみました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/083ea876-de8a-b850-7b8c-20786175337b.png)






# 今までの悩み
今までの悩みは```セキュリティグループ(SG)の付け方```です。
具体的にはインスタンス1つにつき、1つのSGをアタッチするのか、
役割ごと(例えばリモートアクセス用など)のSGを複数アタッチするのかという点でした。。。。
（下記は1つのSGによる通信許可設定(out)ですが、これが1つの中に大量に書かれるか、
役割ごとにこれを作成するのかという問題ですね。）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/4e0fa6b5-fa2b-78ad-b967-582a8c592696.png)

個人的にそれぞれにはメリットデメリットがあると思っているので、下記にまとめます。
####SGのアタッチ方法に沿ったメリット/デメリット
- **インスタンス1つ-SG1つ**
    - メリット：通信許可設定の理解がすぐ可能。
    - デメリット：冗長な設定になるので、管理しにくい。複数インスタンスにアタッチしてると変更の際に、影響を受ける範囲が広い。
- **インスタンス1つ-SG複数(役割ごと)**
    - メリット：役割ごとの通信許可で概要は理解しやすい。変更の際に、一か所のSG変更で済む。
    - デメリット：インスタンスにアタッチできるSG数に制限がある。通信許可設定の理解に時間を要する。

そして、おそらく少しはプログラミングなどをかじっているIT脳の方には、
役割ごとに分けてSGを作成&アタッチする法を選びたくなるはず。
そんな私も完全に複数SG派なのですが、デメリット部分が割とめんどくさい。。。

そう感じてるときに、新サービス```VPC Reachability Analyzer```がこの問題を解決してくれるようなので、それを確認してみます！！！

※インスタンスが数個程度であれば1つのSGで十分だと思います。

# VPC Reachability Analyzer
[VPC Reachability Analyzer](https://aws.amazon.com/jp/blogs/aws/new-vpc-insights-analyzes-reachability-and-visibility-in-vpcs/)：VPC内のリソース間の接続性をテスト・可視化できるVPCの新機能です。

***要は、通信のルーティングを可視化・テストしてくれる***というもので、
私が悩んでいた、```通信許可設定の理解に時間を要する```という複数SGによるデメリットを解決してくれるサービスなのです！！！


#実際の動きを確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/6ed57964-355d-956a-6e5f-8e241c313e53.png)
写真左下にできてますね。東京リージョンでも使えるのがうれしい。GAされても使えないときが時々あるから。。

早速作成しに行くっ！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/77e2706c-3b3c-4bb5-69d1-26a44410038b.png)
```名前``` ```送信元タイプどこからどこに通信が到達するか)``` ```プロトコル``` ```ポート```を指定します。
また、送信元タイプは、写真のように下記6つが選択できました。
***Transit Gateways | VPN Gateways | Instances | Network Interfaces | Internet Gateways | VPC Endpoints | VPC Connections***

※ここからは、お金がかかりそうなので、他の方の記事を参考にしました。
1分もたたず、通信到達を確認し、ページ下部の「分析エクスプローラー」で通信のルーティングを可視化することができるそうです！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/97933404-e48d-a7ef-5a04-27cf84a924e2.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/691623/48f3b74a-222f-52a6-9a7d-d6c71bf063a2.png)

これにて、通信の可視化を行えるようになったので、
SGは迷わず役割ごとに作成するのがベストプラクティスですね！！
（※勿論インスタンスの数による）

また、費用に関しては
***Price per analysis processed by VPC Reachability Analyzer: $0.10***とのことなので、有料です！
お気を付けください！（1回調べるのに10円なので、ハンズオン続けてもよかったですねｗ）

# まとめ
・VPC Reachability Analyzerいいですね。。。
どのAWSサービスを通っているのか図で分かりやすいですし、可読性が上がりました。

・aws re invent は今年(2020)から見るようになったのですが、個人的には開発者用サービスに関心があるので、
今後はCodeGuru, DevOpsGuruなどのサービスをピックアップできればと思っています！お楽しみに！

・参考資料
https://dev.classmethod.jp/articles/breaking-vpc-reachability-analyzer/