バケットの仮想ホスティング - Amazon Simple Storage Service
パス形式のリクエスト仮想ホスト形式のリクエストHTTP Host ヘッダーバケット仕様例 CNAME レコードを使用した Amazon S3 URL のカスタマイズホスト名を Amazon S3 バケットに関連付ける方法制限事項下位互換性

バケットの仮想ホスティング

仮想ホスティングとは、単一のウェブサーバーから複数のウェブサイトにサービスを提供することです。Amazon S3 REST API リクエストでサイトを区別する方法の 1 つとして、単なる URI のパス名部分ではなく、リクエスト URI の明確なホスト名を使用します。通常の Amazon S3 REST リクエストは、リクエスト URI パスのスラッシュで区切られた先頭コンポーネントを使用してバケットを指定します。代わりに、Amazon S3 仮想ホスティングでは、HTTP Host ヘッダーを使用することで、REST API コールでバケットを指定することができます。実際には、Amazon S3 は Host を、ほとんどのバケットは https://bucket-name.s3.region-code.amazonaws.com で自動的にアクセス可能である意味であると解釈します (限定されたタイプのリクエストの場合)。Amazon S3 リージョンとエンドポイントの完全なリストについては、Amazon Web Services 全般のリファレンス の「Amazon S3 エンドポイントとクォータ」を参照してください。

仮想ホスティングには、他の利点もあります。さらに、登録されたドメイン名を使用してバケットの名前を指定し、その名前を Amazon S3 の DNS エイリアスにすることによって、Amazon S3 リソースの URL を完全にカスタマイズすることができます (例: http://my.bucket-name.com/)。バケットの仮想サーバーの「ルートディレクトリ」に公開することもできます。多くの既存のアプリケーションがこの標準ロケーションでファイルを検索するため、この機能は重要です。たとえば、favicon.ico、robots.txt、および crossdomain.xml はすべてルートで見つかることが見込まれています。

重要

SSL と共に仮想ホスト形式のバケットを使用している場合、SSL ワイルドカード証明書は、ドット (「.」) を含まないバケットのみと一致します。この制限を回避するには、HTTP を使用するか、または独自の証明書検証ロジックを記述します。詳細については、AWS ニュースブログのAmazon S3 パスの非推奨化プランを参照してください。

パス形式のリクエスト

現在、Amazon S3 では、すべての AWS リージョン で仮想ホスト形式の URL とパス形式の URL の両方をサポートしています。ただし、パス形式の URL は将来廃止される予定です。詳細については、次の重要な注記を参照してください。

Amazon S3 では、パス形式の URL は次の形式を使用します。

https://s3.region-code.amazonaws.com/bucket-name/key-name

例えば、DOC-EXAMPLE-BUCKET1 という名前のバケットを 米国西部 (オレゴン) リージョンで作成し、そのバケットで puppy.jpg オブジェクトにアクセスする場合、次のパス形式の URL を使用できます。

https://s3.us-west-2.amazonaws.com/DOC-EXAMPLE-BUCKET1/puppy.jpg
重要

更新 (2020 年 9 月 23 日) – お客様が仮想ホスティング形式の URL への移行に必要な時間を確保できるように、パス形式 URL の非推奨化を延期することが決定しました。詳細については、AWS ニュースブログ の「Amazon S3 Path Deprecation Plan – The Rest of the Story」を参照してください。

警告

ウェブブラウザからアクセスするウェブサイトのコンテンツをホストする場合は、生成元が同じブラウザのセキュリティモデルを妨げる可能性があるパススタイルの URL の使用を避けてください。ウェブサイトコンテンツをホストするには、S3 ウェブサイトエンドポイントまたは CloudFront ディストリビューションのいずれかを使用することをお勧めします。詳細については、「ウェブサイトエンドポイント」およびAWS 規範的ガイダンスパターンの「Deploy a React-based single-page application to Amazon S3 and CloudFront」(React ベースの単一ページアプリケーションを Amazon S3 と CloudFront にデプロイする) を参照してください。

仮想ホスト形式のリクエスト

仮想ホスティング形式の URI では、バケット名は URL のドメイン名の一部です。

Amazon S3 仮想ホスト形式の URL は、次の形式を使用します。

https://bucket-name.s3.region-code.amazonaws.com/key-name

この例では、DOC-EXAMPLE-BUCKET1 はバケット名、米国西部（オレゴン）はリージョン、puppy.png はキー名です。

https://DOC-EXAMPLE-BUCKET1.s3.us-west-2.amazonaws.com/puppy.png

HTTP Host ヘッダーバケット仕様

GET リクエストが SSL エンドポイントを使用しないかぎり、HTTP Host ヘッダーを使用してリクエストに対してバケットを指定できます。REST リクエストの Host ヘッダーは、次のように解釈されます。

  • Host ヘッダーが省略されるか、またはその値が s3.region-code.amazonaws.com である場合、リクエストのバケットはリクエスト URI のスラッシュで区切られた先頭コンポーネント、リクエストのキーはリクエスト URI の残りの部分になります。このセクションの最初および 2 つ目の例に示すように、これが通常の方式です。Host ヘッダーは、HTTP 1.0 リクエストでのみ省略可能です。

  • 上記のいずれの条件も該当せず、Host ヘッダーの値が .s3.region-code.amazonaws.com で終わる場合、バケット名は Host ヘッダーの値のうち、先頭から .s3.region-code.amazonaws.com までの値になります。リクエストのキーはリクエスト URI になります。この解釈により、このセクションの 3 番目と 4 番目の例で示されているように、.s3.region-code.amazonaws.com のサブドメインとしてバケットが公開されます。

  • それ以外の場合、リクエストのバケットは Host ヘッダーの小文字の値、リクエストのキーはリクエスト URI になります。この解釈は、バケット名と同じ DNS 名を登録してして、その名前を Amazon S3 の 正規名 (CNAME) エイリアスとして設定している場合に有用です。このドキュメントではドメイン名の登録および CNAME DNS レコードの設定の手順については扱いませんが、このセクションの最後の例にその結果を示します。

例

このセクションでは、URL およびリクエストの例を示します。

例 — パス形式の URL とリクエスト

この例では以下を使用しています。

  • バケット名 ‐ example.com

  • リージョン ‐ 米国東部 (バージニア北部)

  • キー名 ‐ homepage.html

URL は次のとおりです。

http://s3.us-east-1.amazonaws.com/example.com/homepage.html

リクエストは次のとおりです。

GET /example.com/homepage.html HTTP/1.1
Host: s3.us-east-1.amazonaws.com

HTTP 1.0 でのリクエストと Host ヘッダーの省略は次のとおりです。

GET /example.com/homepage.html HTTP/1.0

DNS 互換名については、「制約事項」を参照してください。キーの詳細については、「キー」を参照してください。

例 — 仮想ホスト形式の URL とリクエスト

この例では以下を使用しています。

  • バケット名 ‐ DOC-EXAMPLE-BUCKET1

  • リージョン ‐ 欧州 (アイルランド)

  • キー名 ‐ homepage.html

URL は次のとおりです。

http://DOC-EXAMPLE-BUCKET1.s3.eu-west-1.amazonaws.com/homepage.html

リクエストは次のとおりです。

GET /homepage.html HTTP/1.1
Host: DOC-EXAMPLE-BUCKET1.s3.eu-west-1.amazonaws.com
例 — CNAME エイリアス方式

この方式を使用するには、DNS 名を bucket-name.s3.us-east-1.amazonaws.com の CNAME エイリアスとして設定する必要があります。詳細については、「CNAME レコードを使用した Amazon S3 URL のカスタマイズ」を参照してください。

この例では以下を使用しています。

  • バケット名 ‐ example.com

  • キー名 ‐ homepage.html

URL は次のとおりです。

http://www.example.com/homepage.html

例は次のとおりです。

GET /homepage.html HTTP/1.1
Host: www.example.com

CNAME レコードを使用した Amazon S3 URL のカスタマイズ

要件によっては、「s3.region-code.amazonaws.com」をウェブサイトまたはサービスに表示したくない場合もあります。例えば、ウェブサイトの画像を Amazon S3 でホスティングしている場合、http://images.example.com/ の代わりに http://images.example.com.s3.us-east-1.amazonaws.com/ と表示することができます。DNS 互換名を持つすべてのバケットは、 http://BucketName.s3.Region.amazonaws.com/[Filename] のように参照できます (例: http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg)。CNAME を使用すると、images.example.com を Amazon S3 のホスト名にマッピングできるため、この URL は http://images.example.com/mydog.jpg になります。

バケット名は CNAME と同じである必要があります。例えば、CNAME を作成して images.example.com を images.example.com.s3.us-east-1.amazonaws.com にマッピングした場合、http://images.example.com/filename と http://images.example.com.s3.us-east-1.amazonaws.com/filename はどちらも同じになります。

CNAME DNS レコードは、ドメイン名を適切な仮想ホスティング形式のホスト名にエイリアス設定する必要があります。たとえば、バケット名とドメイン名が images.example.com で、バケットが 米国東部 (バージニア北部) リージョンにある場合、CNAME レコードは images.example.com.s3.us-east-1.amazonaws.com のエイリアスであることが必要です。

images.example.com CNAME 			images.example.com.s3.us-east-1.amazonaws.com.

Amazon S3 はホスト名を使用して、バケット名を決定します。そのため CNAME とバケット名は同じである必要があります。たとえば、www.example.com を www.example.com.s3.us-east-1.amazonaws.com の CNAME として設定したとします。http://www.example.com にアクセスすると、Amazon S3 は次のようなリクエストを受け取ります。

GET / HTTP/1.1
Host: www.example.com
Date: date
Authorization: signatureValue

Amazon S3 は元のホスト名 www.example.com だけを認識し、リクエストを解決するために使用される CNAME マッピングを認識しません。

どの Amazon S3 エンドポイントも、CNAME エイリアスで使用できます。たとえば、s3.ap-southeast-1.amazonaws.com は CNAME エイリアスで使用できます。エンドポイントの詳細については、「エンドポイントのリクエスト」を参照してください。カスタムドメインを使用して静的ウェブサイトを作成するには、チュートリアル: Route 53 に登録されたカスタムドメインを使用した静的ウェブサイトの設定 を参照してください。

重要

CNAME でカスタム URL を使用する場合は、設定した CNAME またはエイリアスレコードに一致するバケットが存在することを確認する必要があります。たとえば、www.example.com と login.example.com の DNS エントリを作成し、S3 を使用してウェブコンテンツを公開するには、www.example.com と login.example.com の両方のバケットを作成する必要があります。

CNAME またはエイリアスレコードが、一致するバケットがない S3 エンドポイントをポイントするように設定されている場合、AWS ユーザーは、所有権が同じでなくても、そのバケットを作成し、設定されたエイリアスでコンテンツを公開できます。

同じ理由で、バケットを削除するときは、対応する CNAME またはエイリアスを変更または削除することをお勧めします。

ホスト名を Amazon S3 バケットに関連付ける方法

CNAME エイリアスを使用してホスト名を Amazon S3 バケットに関連付けるには

  1. 管理するドメインに属するホスト名を選択します。

    この例では、images ドメインの example.com サブドメインを使用します。

  2. ホスト名と一致するバケットを作成します。

    この例では、ホスト名およびバケット名は images.example.com です。バケット名はホスト名と完全に一致する必要があります。

  3. ホスト名を Amazon S3 バケットのエイリアスとして定義する CNAME DNS レコードを作成します。

    例:

    images.example.com CNAME images.example.com.s3.us-west-2.amazonaws.com

    重要

    リクエストルーティングの理由により、CNAME DNS レコードは、前述の例と完全に一致するように定義する必要があります。そうしない場合、正しく動作するように見えても、最終的には予期しない結果を招くことがあります。

    CNAME DNS レコードを設定する手順は、お使いの DNS サーバーまたは DNS プロバイダーによって異なります。個別の情報については、お使いのサーバーのマニュアルをご覧になるか、プロバイダーにお問い合わせください。

制限事項

SOAP のサポートは HTTP 経由では廃止されましたが、HTTPS 経由では引き続き利用可能です。Amazon S3 の新機能は SOAP でサポートされていません。SOAP の代わりに、REST API か AWS SDK を使用することをお勧めします。

下位互換性

以下のセクションでは、パス形式および仮想ホスト形式の URL リクエストに関連する Amazon S3 の下位互換性のさまざまな側面について説明します。

レガシーエンドポイント

一部のリージョンでは、レガシーエンドポイントがサポートされています。これらのエンドポイントは、サーバーアクセスログまたは AWS CloudTrail ログに表示される場合があります。詳細については、次の情報を確認してください。Amazon S3 リージョンとエンドポイントの完全なリストについては、Amazon Web Services 全般のリファレンス の「Amazon S3 エンドポイントとクォータ」を参照してください。

重要

ログにレガシーエンドポイントが表示される場合もありますが、バケットにアクセスするには、常に標準のエンドポイント構文を使用することをお勧めします。

Amazon S3 仮想ホスト形式の URL は、次の形式を使用します。

https://bucket-name.s3.region-code.amazonaws.com/key-name

Amazon S3 では、パス形式の URL は次の形式を使用します。

https://s3.region-code.amazonaws.com/bucket-name/key-name

s3‐Region

一部の古い Amazon S3 リージョンでは、ドット (s3.us-west-2 など) ではなく、s3 とリージョンコードの間にダッシュ (-) を含むエンドポイント (s3‐us-west-2 など) がサポートされています。バケットがこれらのリージョンのいずれかにある場合、サーバーアクセスログまたは CloudTrail ログに次のエンドポイント形式が表示されることがあります。

https://bucket-name.s3-region-code.amazonaws.com

この例では、バケット名は DOC-EXAMPLE-BUCKET1 で、リージョンは米国西部 (オレゴン) です。

https://DOC-EXAMPLE-BUCKET1.s3-us-west-2.amazonaws.com

レガシーグローバルエンドポイント

一部のリージョンでは、レガシーグローバルエンドポイントを使用して、リージョン固有のエンドポイントを指定しないリクエストを作成できます。レガシーグローバルエンドポイントポイントは次のとおりです。

bucket-name.s3.amazonaws.com

サーバーアクセスログまたは CloudTrail ログに、レガシーグローバルエンドポイントを使用するリクエストが表示される場合があります。この例では、バケット名は DOC-EXAMPLE-BUCKET1 であり、レガシーグローバルエンドポイントは次のとおりです。

https://DOC-EXAMPLE-BUCKET1.s3.amazonaws.com
米国東部 (バージニア北部) の仮想ホスト形式のリクエスト

レガシーグローバルエンドポイントで行われたリクエストは、デフォルトでは米国東部 (バージニア北部) リージョンに送信されます。したがって、レガシーグローバルエンドポイントは、米国東部 (バージニア北部) のリージョン別エンドポイントの代わりに使用されることがあります。米国東部 (バージニア北部) にバケットを作成し、グローバルエンドポイントを使用する場合、Amazon S3 はデフォルトでリクエストをこのリージョンにルーティングします。

他のリージョンに対する仮想ホスト形式のリクエスト

レガシーグローバルエンドポイントは、サポートされている他のリージョンでの仮想ホスト形式のリクエストにも使用されます。2019 年 3 月 20 日より前に開始されたリージョンにバケットを作成し、レガシーグローバルエンドポイントを使用すると、Amazon S3 は DNS レコードを更新してリクエストを正しいロケーションにルーティングします。この処理には時間がかかる場合があります。その間、デフォルトのルールが適用され、仮想ホスト形式のリクエストは米国東部 (バージニア北部) リージョンに送られます。次に、Amazon S3 は HTTP 307 一時的リダイレクトを使用して正しいリージョンにリダイレクトします。

2019 年 3 月 20 日より後に開始されたリージョンの S3 バケットの場合、DNS サーバーはリクエストをバケットが存在する AWS リージョン に直接ルーティングしません。代わりに HTTP 400 Bad Request エラーが返されます。詳細については、「リクエストの実行」を参照してください。

パス形式のリクエスト

米国東部 (バージニア北部) リージョンでは、パス形式のリクエストにレガシーグローバルエンドポイントを使用できます。

他のすべてのリージョンでは、パススタイル構文の場合、バケットへのアクセスを試行するときにリージョン固有のエンドポイントを使用する必要があります。レガシーグローバルエンドポイント、またはバケットが存在するリージョンのエンドポイントとは異なる別のエンドポイントを使用してバケットにアクセスしようとすると、HTTP レスポンスコード 307「一時的なリダイレクト」エラーと、リソースの正しい URI を示すメッセージが表示されます。たとえば、米国西部 (オレゴン) リージョンで作成されたバケットに https://s3.amazonaws.com/bucket-name を使用すると、HTTP 307 Temporary Redirect エラーが発生します。