【検証】Amazon S3 Webサーバのルーティング経路をサクッとみてみよう！！

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は検証ということで、Amazon S3で構築したWebサーバのルーティング経路を見てみたいと思います！
ネットワーク初心者の方でもスッと頭に入るように、平易な表現で執筆しておりますのでお気軽に読んでいただければ幸いです。

今回のテーマはルーティング経路を見てみることですので、Amazon S3に関する詳細説明は割愛いたしますので、ご了承いただけますと幸いです。また、今回の検証ではCloudFront経由でのルーティングは対象外としますので、ご了承ください。

目次

• 簡単な構成
• Amzon S3設定
• Tracert結果
• まとめ

簡単な構成

ざっくりとした絵ですが、自宅環境からAmazon S3までの構成については以下の通りです。

Amazon S3

今回の設定はセキュリティ上問題がある設定となっております。
そのため、Amzon S3でWebサーバを構築するときはWAF設定、CloudFront設定や適切なパケットポリシー設定を行ってください。（設定情報に関しては検証後、削除しております）

Amazon S3設定は以下の通りです。

バケットウェブサイトエンドポイントへアクセスすると以下画像が表示されます。

補足すると、画像生成はChatGPT先生にお任せしてみました。

Tracert結果

それでは、自宅環境からTracertを実行してみましょう

PS {実行ディレクト}> tracert webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [{Amzon S3グローバルIP}] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     3 ms     1 ms     1 ms  {自宅ローカルIP}
  2    10 ms     8 ms    17 ms  {自宅ルータ}
  3     8 ms     5 ms     7 ms  {自宅ルータ}
  4     6 ms     6 ms     5 ms  10.9.203.198
  5     *        *        *     要求がタイムアウトしました。
  6     *        *        *     要求がタイムアウトしました。
  7     *        *        *     要求がタイムアウトしました。
  8     *        *        *     要求がタイムアウトしました。
  9     7 ms     8 ms     8 ms  s3-website-ap-northeast-1.amazonaws.com [{Amzon S3グローバルIP}]

トレースを完了しました。
PS C:\Users\inuin>

トレース結果を見てみると、自宅PC⇒ルータ⇒インターネット⇒バケットウェブサイトエンドポイントへアクセスしていることが分かりますね。

そのうえで、10.9.203.198について気になったのでWhoisサービスで調べて見ました。

Whoisとは、IPアドレスやドメイン名の登録者などに関する情報を、インターネットユーザーが誰でも参照できるサービス
https://jprs.jp/about/dom-search/whois/

個人的にWhoisを使って気になったドメインを調べる学習方法はおススメかと思います。調べて見ることで、この企業のドメインはどこのプロバイダを利用しているのかといった興味につながると思います。

Whois検索結果は以下の通りでした。

検索したところ、何も出てきませんでした。
理由は簡単で、10.*から始まるアドレスはローカルIPと呼ばれる所属しているネットワークで利用するネットワークだからですね。

ローカルIPに含まれるアドレス帯として以下の通りです。
クラスA：10.0.0.0 ～ 10.255.255.255
クラスB：172.16.0.0 ～ 172.31.255.255
クラスC：192.168.0.0 ～ 192.168.255.255

ここからは予測ですが、プロバイダ事業者内のネットワークで利用されている機器を指しているのかと思います。

まとめ

今回はAmazon S3 Webサーバのルーティング経路をサクッと調べて見ました。
そのうえで、3つの示唆が得られたかなぁと思いました。

• Tracertを実行することでどのような経路を踏んで通信が行われているか理解できる
  • 疎通確認の定番といえばPingのイメージがありますが、個人的には経路ごとの確認を行えるTracertの方が好きですね
• Amzon S3までのアクセスでAWSの他のリソースへのアクセスはなかった
  • 実はビジネス視点だと、Amzon S3以外の通信がない=セキュリティ対策をS3のみに集中できるといった発見を行うことが出来るといったメリットもあります
• Whoisを利用してみる習慣を身に付けることで、気になったドメインがどこのプロバイダに属しているかキャッチアップできる=興味関心につながる

今回は簡単な検証記事でしたが、読者の皆さんの環境でも簡単に試せると思いますので、ぜひ触ってみてください！！

追記

S3パケット削除後にPingで疎通確認したら疎通確認が通っていましたね。

PS PS {実行ディレクト}> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [{Amzon S3グローバルIP}]に ping を送信しています 32 バイトのデータ:
{Amzon S3グローバルIP} からの応答: バイト数 =32 時間 =6ms TTL=248
{Amzon S3グローバルIP} からの応答: バイト数 =32 時間 =6ms TTL=248
{Amzon S3グローバルIP} からの応答: バイト数 =32 時間 =6ms TTL=248
{Amzon S3グローバルIP} からの応答: バイト数 =32 時間 =6ms TTL=248

{Amzon S3グローバルIP} の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 6ms、平均 = 6ms
PS C:\Users\inuin>

おそらく、ドメイン情報が残っているからPing疎通が通っているのかなぁと推察しています。当たり前ですが、ブラウザからバケットウェブサイトエンドポイントへアクセスしたら、404 Not Foundエラーが表示されました。

Amazon S3削除後の挙動として少し興味深かったので追記しました。