Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

AWS初心者向けNW構築ハンズオン-Internal編-

はじめに

AWS初心者にとって、最初に躓きやすい部分がNWの構築かと思います。

インスタンス立ててみたけど、これってどうやると他のノードと通信できるんだっけ？ なんとなく通信できたけど、なんでだ？ といった辺り、なんとなく有耶無耶なままにしていませんか。

今回は2020年12月にローンチされたReachability Analyzerを利用して、AWS初心者向けのNW構築ハンズオン-Internal編-をやってみたいと思います。

参考：新機能 – VPC Reachability Analyzer

流れ

  • 前準備
    1. VPCを２つ作成
    2. 各VPCにサブネットを作成
    3. 各VPC内にEC2を作成
  • AWS Reachability Analyzerを利用しての疎通確認
    • #1 VPC Peeringが不足している
    • #2 Route Tableのルーティングが不足している
    • #3 Security Groupのインバウンドの許可設定が不足している
    • #4 振り返り

前準備

1. VPCを作成

VPCを2つ作成
vpc_a.png
vpc_b.png
参考：Amazon VPC IPアドレス設計レシピ

2. 各VPCにサブネットを作成

各VPC（InternalA, B）に、それぞれサブネットを作成する
subnet.png

3. 各VPCにEC2を作成

今しがた作成した各サブネットにEC2を立てます。
イメージはAmazon Linux2、インスタンスサイズはt2.microの無料利用枠にしています。
ec2_a.png
ec2_b.png

また、EC2作成のタイミングで、Security Groupも作成しています。
判別しやすいようNameのみ設定しており、ルールはデフォルトのままです。
sg_a.png
sg_b.png

Reachability Analyzerを利用しての疎通確認

前準備は完了したので、ここからはReachability Analyzerを利用しながら疎通確認をしていきましょう。

VPCのメニューバーから選択利用できます。
ra01.png

パスの作成と分析からパスを作成します。
今回はInterna-AのEC2からInternal-BのEC2への疎通確認をします。
ポートはhttpsを意識して443としています。
ra02.png

#1 VPC Peeringが不足している

パスを作成すると同時に分析が実行されます。
分析が完了し、ステータスが到達不可能になっていることが確認できます。
詳細を見ていきましょう。
ra03.png

詳細を確認すると、VPC Peeringが接続できていないようです。
ra04.png

VPC Peeringとは、異なるVPC間の通信を実現するためのサービスです。
参考：VPCピアリングを作りながら学んでみた

VPCのコンソール画面からピアリング接続を設定します。
vpc_peering_atob01.png

設定後、アクションメニューバーから承諾を行う必要がある点に注意です。
vpc_peering_atob02.png

再度、分析してみましょう。

#2 Route Tableのルーティングが不足している

分析結果が変わっています。3つ指摘があるようです。先に、1つ目と3つ目を見ていきます。
ra05.png

rtb-026e0943b428a980dとは、Internal A（VPC）に紐付いているルートテーブルです。
pcx-032cb64744c1e754aとは、先程作成したVPC Peeringのことです。
Internal AからVPC Peeringに対するルーティング設定が不足しているという指摘のようです。
ルーティングを設定しましょう。ターゲットを先のVPC Peeringに向けて、送信先のCIDRはInternal Bを指定します。

vpc_a_rt.png

3つ目は反対に、Internal BからVPC Peeringに対するルーティング設定が不足しているという指摘です。同じ要領で設定をします。この時、送信先のCIDRはInternal Aを指定します。
vpc_b_rt.png

再度、分析してみましょう。

#3 Security Groupのインバウンドの許可設定が不足している

先の指摘がクリアになっています。いい感じです。
残りの指摘を見ると、Security Groupのingressルールが不足しているようです。
ra06.png

03766d1ad9783c83bとはInternal BのEC2にアタッチされているSecurity Groupのことです。
このSecurity GroupがInternal AのEC2からの通信を拒絶しているので、許可設定をします。

今回はhttps通信を想定して、443ポートでの疎通確認をしていました。
そのためSecurity Groupのインバウンドルールに443ポート、CIDR10.1.0.0/16からの通信を許可する設定を追加します。
sg_b_inbound.png

再度、分析してみましょう。

#4 振り返り

通信に成功しました！
ra07.png

通信経路も視覚的に確認できます。
ra08.png

わかりやすく注釈をつけてみました。
ra09.png
黒字で記載している箇所は今回意識しなかった箇所です。

  • EC2のENI：
    • EC2が通信を行うためのインタフェースです。ENIがないとEC２は通信を行うことができません。EC2を作成したタイミングで合わせて払い出されています。
  • VPCのACL：
    • VPCの単位でNWの制御を行うためのサービスです。セキュリティグループ同様にセキュリティを高める目的で利用します。

参考：AWSのネットワークインターフェース「ENI」とは
参考：Amazon VPCのネットワークACLについて

なぜ、今回はInternal AのSecurity Groupの設定を操作せずに済んだのかというと、もともと外向きの通信が許可されていたためです。
sg_a_outbound.png

まとめ

今回のNW構成を簡単に図化すると以下です。

Internal AのVPCにいるEC2からInternal BのVPCにいるEC２に向けて投げられた通信は、SecurityGroupを抜けて、VPCのRouteTableを利用して、VPCPeeringへと流れていきます。

VPC Peeringを抜けた通信はやがてInternal Bに到達し、Securituy Groupを抜けて対向のEC2へとたどり着きました。

diagram.png