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

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

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

いつも記事を読んでいただきありがとうございます！
モブエンジニア（[@mob-engineer](https://qiita.com/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疎通は問題なく出来ている
1. **静的ウェブサイトホスティングを有効にしなくてもPing疎通自体は問題なく通る**
    - おそらくS3作成と同タイミングでDNSサーバ（Route53）へドメイン登録されている
1. **Ping疎通時のパケットウェブサイトエンドポイントで返ってくるグローバルIPは一意でない**
    - おそらく、エンドポイント名に紐づいているIPが複数あるからと推察される

## 公式ドキュメント

https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html

https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints

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

## 検証環境

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

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

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

#### Amazon S3コンソール画面

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/3f3c846c-2843-5e51-699a-79c9f9f9d227.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/d903a781-1276-8ca3-2022-0a31a5c7d047.png)

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

#### ブラウザへのアクセス

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

**webserver-test**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/33857c0c-4a2b-1e3d-cffb-cb415933394e.png)

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

**testdevhoge**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/2672f9bc-2f31-6d7d-c4f8-a19eba9e5a15.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アドレスが返ってきた**と言えるのかなぁと思います。

:::note info
ドメイン情報は.を基準に階層構造を取っています。図で示すと以下のような表現になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/c3af897c-a391-3ffd-756b-0ad453a032cc.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を使ってみて各ドメイン情報を見てみたいと思います。

https://www.cman.jp/network/support/ip.html

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/458e76dc-87e4-8441-c517-3d64dd471313.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3846878/529b0bdc-a402-1a4c-a84d-a8bcfa78e7df.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疎通は問題なく出来ている
1. **静的ウェブサイトホスティングを有効にしなくてもPing疎通自体は問題なく通る**
    - おそらくS3作成と同タイミングでDNSサーバ（Route53）へドメイン登録されている
1. **Ping疎通時のパケットウェブサイトエンドポイントで返ってくるグローバルIPは一意でない**
    - おそらく、エンドポイント名に紐づいているIPが複数あるからと推察される

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

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

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

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

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

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

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