必見の記事

【注意喚起】 2020年9月30日以降、パス形式での S3 API リクエストは受け付けられなくなります。

2020年9月30日以降、S3 API リクエストで「パス形式」の URL 指定は受け付けられなくなります。
2019.05.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2020年9月30日以降、パス形式での S3 API リクエストは受け付けられなくなる、との発表がありましたのでシェアします。

2021.01.27 追記
2020年9月23日に以下の追加アナウンスがありました。
・ユーザーが仮想ホスト形式への移行に必要な時間を確保するための措置として、パス形式の非推奨化は少なくとも 1 年間延期されました。執筆時点において新規バケットについてもパス形式のリクエストは可能ですが、あくまで延期であるため新規に作成されるものについては、仮想ホスト形式を前提にしたほうが良い点は変わらないと思います。
・また、互換性の理由から仮想ホスト形式においてもドットが含まれるバケットのサポートを求めるフィードバックが多く寄せられたため、こちらについてもサポートするように開発を進めているとのアナウンスがありました。

2019.05.09 追記
2020年9月30日以前に作成されているバケットは、パス形式廃止対象から除外になった旨、追記しました

パス形式とは?

S3 API のエンドポイント指定方法には、以下の2つがあります。

  • パス形式(path-style): V1 と呼ばれてるそうです
  • 仮想ホスト形式(virtual hosted–style): V2 と呼ばれてるそうです

パス形式(2020.09.30 以降、サポート終了)

下記のように、パス部分にバケット名が含まれる形式の指定方法です。
バージニアは s3.amazonaws.com ですが、それ以外のリージョンは s3-ap-northeast-1 のようにリージョン名を含みます。

http://s3.amazonaws.com/<bucket-name> (バージニアのみ)
http://s3-ap-northeast-1.amazonaws.com/<bucket-name>

2020年9月30日以降、この形式で S3 API リクエストしても受け付けられなくなります。

仮想ホスト形式(今後も利用可能)

下記のように、ホスト部分にバケット名が含まれる形式の指定方法です。
リージョン名を指定しても、しなくても利用可能です。

http://<bucket-name>.s3.amazonaws.com
http://<bucket-name>.s3-ap-northeast-1.amazonaws.com

今後の対応

  • 新規開発または、開発途中の環境においては必ず「仮想ホスト形式」を利用しましょう。
  • 既にリリース済みの環境についても、サポート終了まで1年以上あります。まずは手元のコードから「パス形式」利用をチェックされるのが良いかと思います。

S3 アクセスログからパス形式の利用が特定できるようであれば、別途、ブログ化しようかと思います。(というか、誰か書いてくれそうな気もしてます)

パス形式から仮想ホスト形式への変更が容易ではないケース(2019.05.02 追記)

2019.05.02 追記
パス形式から仮想ホスト形式への変更が容易ではないケースを追記しました

以下のようなバケット名を利用されている場合、単純に仮想ホスト形式への変更では対応できない可能性があります。その場合、新規バケット名への移行を検討する必要があるかもしれません。

DNS に準拠していない、レガシーなバケット名

2018年3月1日まで、バケット名に大文字やアンダースコアを含めることが出来ていましたが、大文字やアンダースコアは DNS に準拠していないため、仮想ホスト形式が利用できない可能性があります。既に同様のバケット名は作成できないため、未検証ですが大文字については公式ガイドにアクセスできない旨の記載があります。

たとえば、MyAWSbucket には大文字が使われていますが、有効なバケット名でした。このバケットに、仮想ホスト形式のリクエスト (http://MyAWSbucket.s3.amazonaws.com/yourobject) を使用してアクセスしようとすると、URL はバケット MyAWSbucket でなく、バケット myawsbucket に解決されます。このため、Amazon S3 は "bucket not found" エラーを返します。

ピリオドを含むバケット名

バケット名にピリオドを含むことは可能ですが、https で利用されている場合、仮想ホスト形式では SSL ワイルドカード証明書(*.s3.amazonaws.com)に一致しないため、標準のままでは利用することができません。(http での利用に問題はありません)

仮想ホスティング形式のバケットを Secure Sockets Layer (SSL) で使用する場合、SSL ワイルドカード証明書はピリオドを含まないバケットにのみ一致します。この問題を回避するには、HTTP を使用するか、または独自の証明書検証ロジックを記述します。仮想ホスティング形式のバケットを使用するときは、バケット名にピリオド (「.」) を使用しないことをお勧めします。(公式ガイドより

さいごに

ひとまず注意喚起として情報を共有いたしました。

2020年9月といえば、東京オリンピック、パラリンピックの時期ですね。一生に一度あるかないかの自国開催です。ゆっくりと観戦するためにも、なるはやでパス形式の利用有無を確認いただければ幸いです。
(「五輪が終わったら本気だす」はヤメましょうね・・)

以上!大阪オフィスの丸毛(@marumo1981)でした!

リファレンス

対象は2020年9月30日以降に作成されたバケット(2019.05.09 追記)

AWS 公式ブログにてパス形式廃止対象が、2020年9月30日以降に作成されたバケットのみに変更されたとの発表がありました。

Original Plan – Support for the path-style model ends on September 30, 2020.
Revised PlanSupport for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

今回の更新によって、既存のS3バケットについてはパス形式廃止対象から除外されました。

しかしながら、今後の機能アップデートについては仮想ホスト形式のみが対象となる計画もあるようですので、基本的には仮想ホスト形式に移行が推奨であることは変わらないようです。

In With the New As just one example of what becomes possible when using virtual-hosted references, we are thinking about providing you with increased control over the security configuration (including ciphers and cipher versions) for each bucket. If you have ideas of your own, feel free to get in touch.