LoginSignup
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@mob_engineer(モブエンジニア)

【技術検証】Amazon S3削除後の静的ウェブサイトエンドポイントの挙動整理してみた！！

Last updated at Posted at 2025-01-05

本記事は「【検証】Amazon S3 Webサーバのルーティング経路をサクッとみてみよう!！」執筆後に確認した、静的ウェブサイトエンドポイント挙動について整理した記事となります。

https://qiita.com/mob_engineer/items/cb4fe697cbec96ef3183

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

静的ウェブサイトエンドポイントに関する挙動が興味深かったので、記事としてアウトプットしてみました。

ややマニアックな記事なので、興味を持つ方は少ないかもしれませんが、平易な表現で執筆することを心掛けておりますので、お気軽に読んでいただければ幸いです！

目次

  • 今回の検証で見つかった挙動
  • 公式ドキュメント
  • 検証環境
    • Amazon S3コンソール画面
    • ブラウザへのアクセス
  • 検証その１ webserver-testへのPing疎通を行ってみる
  • 検証その2 testdevhogeへのPing疎通を行ってみる
  • 検証その3 webserver-testとtestdevhogeへPingを5回ずつ実行してみる
  • 良く見直してみると...
  • 検証その4 s3-website-ap-northeast-1.amazonaws.com宛にping疎通を行ってみる
  • 検証その5 各ドメインのWhois情報を見てみよう
  • 検証結果の整理
  • （再掲）今回の検証で見つかった挙動
  • 今回の挙動をビジネス視点で考えてみる

今回の検証で見つかった挙動

結論から先にお伝えすると、今回見つかった挙動として以下の通りです。

  1. Amazon S3削除後もパケットウェブサイドエンドポイントは生き残っている
    • 少なくともPing疎通は問題なく出来ている
  2. 静的ウェブサイトホスティングを有効にしなくてもPing疎通自体は問題なく通る
    • おそらくS3作成と同タイミングでDNSサーバ（Route53）へドメイン登録されている
  3. Ping疎通時のパケットウェブサイトエンドポイントで返ってくるグローバルIPは一意でない
    • おそらく、エンドポイント名に紐づいているIPが複数あるからと推察される

公式ドキュメント

ウェブエンドポイントに関するドキュメントを読んでみましたが、それらしい説明はなかったので、おそらく内部仕様なのかなぁと思いました。

検証環境

今回テスト利用するドメイン名は以下の通りです

  • webserver-test.s3-website-ap-northeast-1.amazonaws.com
    • 削除済みドメイン
  • testdevhoge.s3-website-ap-northeast-1.amazonaws.com
    • 静的Webサイト無効化

AWSコンソール側の設定として以下の通りです。

Amazon S3コンソール画面

image.png

testdevhogeしかバケットが存在しないことが確認できました。

念のためtestdevhogeの設定も見てみましょう

image.png

S3 静的ウェブサイトホスティングの設定も無効になっていることが確認取れました。

ブラウザへのアクセス

それぞれのドメインでWebブラウザへアクセスしてみましょう。

webserver-test

image.png

当たり前ですが、バケットが存在していないのでThe specified bucket does not existのエラーが表示されていますね

testdevhoge

image.png

これも当たり前ですが、バケットがWebサイト用に構成されていないのでThe specified bucket does not have a website configurationのエラーが表示されていますね。

検証その１ webserver-testへのPing疎通を行ってみる

webserver-testのドメインへのPing疎通を行ってみた結果として次の通りでした。

PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.16.251]に ping を送信しています 32 バイトのデータ:
52.219.16.251 からの応答: バイト数 =32 時間 =9ms TTL=245
52.219.16.251 からの応答: バイト数 =32 時間 =6ms TTL=245
52.219.16.251 からの応答: バイト数 =32 時間 =19ms TTL=245
52.219.16.251 からの応答: バイト数 =32 時間 =8ms TTL=245

52.219.16.251 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 19ms、平均 = 10ms
PS C:\>

問題なくPingが返ってきていますね。

検証その2 testdevhogeへのPing疎通を行ってみる

testdevhogeのドメインへのPing疎通を行ってみた結果として次の通りでした。

PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.150.75]に ping を送信しています 32 バイトのデータ:
52.219.150.75 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.150.75 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.150.75 からの応答: バイト数 =32 時間 =8ms TTL=248
52.219.150.75 からの応答: バイト数 =32 時間 =6ms TTL=248

52.219.150.75 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 8ms、平均 = 7ms
PS C:\>

問題なくPingが返ってきていますね。

検証その3 webserver-testとtestdevhogeへPingを5回ずつ実行してみる

webserver-testへのPing結果は以下の通りでした。

webserver-testの場合

PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.9.67]に ping を送信しています 32 バイトのデータ:
52.219.9.67 からの応答: バイト数 =32 時間 =9ms TTL=245
52.219.9.67 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.9.67 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.9.67 からの応答: バイト数 =32 時間 =7ms TTL=245

52.219.9.67 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 9ms、平均 = 7ms
PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.162.31]に ping を送信しています 32 バイトのデータ:
52.219.162.31 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =53ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =8ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =7ms TTL=248

52.219.162.31 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 53ms、平均 = 18ms
PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.162.31]に ping を送信しています 32 バイトのデータ:
52.219.162.31 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =11ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =8ms TTL=248
52.219.162.31 からの応答: バイト数 =32 時間 =7ms TTL=248

52.219.162.31 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 11ms、平均 = 8ms
PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.136.235]に ping を送信しています 32 バイトのデータ:
52.219.136.235 からの応答: バイト数 =32 時間 =6ms TTL=245
52.219.136.235 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.136.235 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.136.235 からの応答: バイト数 =32 時間 =7ms TTL=245

52.219.136.235 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 7ms、平均 = 6ms
PS C:\> ping webserver-test.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [3.5.154.147]に ping を送信しています 32 バイトのデータ:
3.5.154.147 からの応答: バイト数 =32 時間 =7ms TTL=57
3.5.154.147 からの応答: バイト数 =32 時間 =8ms TTL=57
3.5.154.147 からの応答: バイト数 =32 時間 =9ms TTL=57
3.5.154.147 からの応答: バイト数 =32 時間 =7ms TTL=57

3.5.154.147 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 9ms、平均 = 7ms
PS C:\>
  • 1回目に返ってきたIPアドレス：52.219.9.67
  • 2回目に返ってきたIPアドレス：52.219.162.31
  • 3回目に返ってきたIPアドレス：52.219.162.31
  • 4回目に返ってきたIPアドレス：52.219.136.235
  • 5回目に返ってきたIPアドレス：3.5.154.147

testdevhogeへのPing結果は以下の通りでした。

testdevhogeの場合

PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.9.55]に ping を送信しています 32 バイトのデータ:
52.219.9.55 からの応答: バイト数 =32 時間 =8ms TTL=245
52.219.9.55 からの応答: バイト数 =32 時間 =9ms TTL=245
52.219.9.55 からの応答: バイト数 =32 時間 =8ms TTL=245
52.219.9.55 からの応答: バイト数 =32 時間 =7ms TTL=245

52.219.9.55 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 9ms、平均 = 8ms
PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [3.5.156.122]に ping を送信しています 32 バイトのデータ:
3.5.156.122 からの応答: バイト数 =32 時間 =7ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =7ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =7ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =8ms TTL=57

3.5.156.122 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 8ms、平均 = 7ms
PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [3.5.156.122]に ping を送信しています 32 バイトのデータ:
3.5.156.122 からの応答: バイト数 =32 時間 =6ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =8ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =7ms TTL=57
3.5.156.122 からの応答: バイト数 =32 時間 =7ms TTL=57

3.5.156.122 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 8ms、平均 = 7ms
PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.9.75]に ping を送信しています 32 バイトのデータ:
52.219.9.75 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =14ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =9ms TTL=245

52.219.9.75 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 14ms、平均 = 9ms
PS C:\> ping testdevhoge.s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.9.75]に ping を送信しています 32 バイトのデータ:
52.219.9.75 からの応答: バイト数 =32 時間 =6ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =7ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =9ms TTL=245
52.219.9.75 からの応答: バイト数 =32 時間 =7ms TTL=245

52.219.9.75 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 9ms、平均 = 7ms
PS C:\>
  • 1回目に返ってきたIPアドレス：52.219.9.55
  • 2回目に返ってきたIPアドレス：3.5.156.122
  • 3回目に返ってきたIPアドレス：3.5.156.122
  • 4回目に返ってきたIPアドレス：52.219.9.75
  • 5回目に返ってきたIPアドレス：52.219.9.75

タイミングによって同じIPアドレスを返していますが、基本的に異なるIPアドレスが返ってきていますね。

良く見直してみると...

検証1～3を通じてPing疎通を行ってみましたが、実は返していたIPアドレスはs3-website-ap-northeast-1.amazonaws.comのドメインに属していたIPアドレスが返っていることが分かりました。
言い換えると、webserver-testとtestdevhogeがs3-website-ap-northeast-1.amazonaws.comのサブドメインとして登録されていたため、s3-website-ap-northeast-1.amazonaws.comのIPアドレスが返ってきたと言えるのかなぁと思います。

ドメイン情報は.を基準に階層構造を取っています。図で示すと以下のような表現になります。
image.png

そのうえで、s3-website-ap-northeast-1.amazonaws.com宛にPing疎通を行うと、amazonaws.comが返ってくるのではと想像できるかと思うので、一度試してみたいと思います。

検証その4 s3-website-ap-northeast-1.amazonaws.com宛にping疎通を行ってみる

s3-website-ap-northeast-1.amazonaws.comへのPing疎通の結果として以下の通りでした。

PS C:\> ping s3-website-ap-northeast-1.amazonaws.com

s3-website-ap-northeast-1.amazonaws.com [52.219.199.3]に ping を送信しています 32 バイトのデータ:
52.219.199.3 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.199.3 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.199.3 からの応答: バイト数 =32 時間 =7ms TTL=248
52.219.199.3 からの応答: バイト数 =32 時間 =7ms TTL=248

52.219.199.3 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 7ms、最大 = 7ms、平均 = 7ms

残念ながら、s3-website-ap-northeast-1.amazonaws.comからIPアドレスが返ってきていますね

ちなみに、amazonaws.com宛にPing疎通を行った結果は以下の通りでした。

PS C:\> ping amazonaws.com

amazonaws.com [72.21.210.29]に ping を送信しています 32 バイトのデータ:
72.21.210.29 からの応答: バイト数 =32 時間 =173ms TTL=244
72.21.210.29 からの応答: バイト数 =32 時間 =171ms TTL=244
72.21.210.29 からの応答: バイト数 =32 時間 =172ms TTL=244
72.21.210.29 からの応答: バイト数 =32 時間 =172ms TTL=244

72.21.210.29 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 171ms、最大 = 173ms、平均 = 172ms

こちらは、amazonaws.comに紐づいているIPアドレスが返ってきましたね。

検証その5 各ドメインのWhois情報を見てみよう

CMANのWhoisを使ってみて各ドメイン情報を見てみたいと思います。

Whoisは各レジストリ事業者も公開していますが、トップレベルドメイン名（今回の場合はcom）によっては正しく結果表示されない場合もあります

webserver-test.s3-website-ap-northeast-1.amazonaws.com

image.png

52.219.17.43で登録されていますね。

testdevhoge.s3-website-ap-northeast-1.amazonaws.com

image.png

52.219.12.36で登録されていますね。

検証結果の整理

検証1～5までを実施して見えた事実をまとめてみましょう

  • 検証その１ webserver-testへのPing疎通を行ってみる
    • Ping疎通は問題なく行われていた
  • 検証その2 testdevhogeへのPing疎通を行ってみる
    • Ping疎通は問題なく行われていた
  • 検証その3 webserver-testとtestdevhogeへPingを5回ずつ実行してみる
    • 異なるIPアドレスが返ってきた
    • IPアドレスを返しているのはs3-website-ap-northeast-1.amazonaws.comだった
  • 検証その4 s3-website-ap-northeast-1.amazonaws.com宛にping疎通を行ってみる
    • s3-website-ap-northeast-1.amazonaws.comから回答が行われていた
  • 検証その5 各ドメインのWhois情報を見てみよう
    • webserver、testdevhogeのドメインはWhoisに登録されていた

（再掲）今回の検証で見つかった挙動

  1. Amazon S3削除後もパケットウェブサイドエンドポイントは生き残っている
    • 少なくともPing疎通は問題なく出来ている
  2. 静的ウェブサイトホスティングを有効にしなくてもPing疎通自体は問題なく通る
    • おそらくS3作成と同タイミングでDNSサーバ（Route53）へドメイン登録されている
  3. Ping疎通時のパケットウェブサイトエンドポイントで返ってくるグローバルIPは一意でない
    • おそらく、エンドポイント名に紐づいているIPが複数あるからと推察される

今回の挙動をビジネス視点で考えてみる

今回見つかった事象をふーん、そんな挙動が発生するんですねだけで終わらせておくのはもったいないので、ビジネス視点でどのようなリスクがあるか考えてみました。

あくまで個人の意見ですのでその点ご了承ください。

  • 静的Webエンドポイントを無効化にしていたとしても攻撃される可能性がある
    • 静的Webエンドポイントを無効化しているから外部公開しても攻撃されないから大丈夫と外部公開したら、もしかしたら予期せぬ攻撃被害にあう可能性がある
      • S3をデータベースとして利用している場合はリスクがあるかなぁと思います
  • 死活確認で利用するグローバルIPアドレスを正しく設定できない可能性がある
    • 責任共有モデルではAWSが保証する範囲といえ、ユーザから死活監視を求められた場合、正しいグローバルIPアドレスを特定するのが難しい
  • S3バケットを作成しただけなのにドメインとして登録されている気持ち悪さがある
    • セキュリティを気にするユーザだと、S3作成しただけなのに勝手にドメイン登録されているんだけどと思ってしまう可能性がある

簡単ですが、検証結果を技術記事としてまとめてみました。
（個人的にAmazon S3は奥深いと思いました）

さっとまとめたので、認識相違・誤字脱字などがあるかもしれません。

もしありましたら、温かくコメントを頂ければありがたいです。
最後まで、記事を読んでいただきありがとうございました！

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?