

# Amazon S3 汎用バケットへのアクセス
<a name="access-bucket-intro"></a>

Amazon S3 汎用バケットにアクセスするには、Amazon S3 コンソール、AWS Command Line Interface、AWS SDK、または Amazon S3 REST API を使用できます。S3 汎用バケットへのアクセス方法ごとにサポートされるユースケースは異なります。詳細については、次のセクションを参照してください。

**Topics**
+ [ユースケース](#accessing-use-cases)
+ [Amazon S3 コンソール](#accessing-aws-management-console)
+ [AWS CLI](#accessing-aws-cli)
+ [AWS SDK](#accessing-aws-sdks)
+ [Amazon S3 REST API](#AccessingUsingRESTAPI)
+ [汎用バケットの仮想ホスティング](VirtualHosting.md)

## ユースケース
<a name="accessing-use-cases"></a>

Amazon S3 汎用バケットのユースケースに応じて、バケット内の基になるデータにアクセスするための推奨方法が異なります。以下のリストには、データにアクセスする一般的なユースケースが含まれています。
+ **静的ウェブサイト** – Amazon S3 を使用して静的ウェブサイトをホスティングできます。このユースケースでは、S3 汎用バケットをウェブサイトと同様に機能するよう設定できます。Amazon S3 上でウェブサイトをホスティングするステップを説明する例については、「[チュートリアル: Amazon S3 での静的ウェブサイトの設定](HostingWebsiteOnS3Setup.md)」を参照してください。

  パブリックアクセスをブロックするなどのセキュリティ設定を有効にして静的ウェブサイトをホストするには、Amazon CloudFront とオリジンアクセスコントロール (OAC) を使用し、HTTPS などの追加のセキュリティヘッダーを実装することをお勧めします。詳細については、「[安全な静的ウェブサイトの使用開始](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html)」を参照してください。
**注記**  
Amazon S3 は、静的ウェブサイトアクセスの[仮想ホスト形式](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#virtual-hosted-style-access)と[パス形式の URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#path-style-access) の両方をサポートしています。バケットはパス形式の URL と仮想ホスト形式の URL を使用してアクセスできるため、DNS 準拠のバケット名を使用してバケットを作成することをお勧めします。詳細については、「[汎用バケットのクォータ、制限、制約](BucketRestrictions.md)」を参照してください。
+ **共有データセット** — Amazon S3 でスケールする場合、マルチテナントモデルを採用して、共有汎用バケット内のプレフィックスごとに異なるエンドカスタマーまたはビジネスユニットを割り当てるのが一般的です。[Amazon S3 アクセスポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html)を使用すると、共有データセットにアクセスする必要のあるアプリケーションごとに、1 つの大きなバケットポリシーを個別のアクセスポイントポリシーに分割できます。このアプローチにより、共有データセット内で他のアプリケーションが実行中の操作を中断することなく、アプリケーションに適したアクセスポリシーの構築に集中しやすくなります。詳細については、「[アクセスポイントを使用した共有データセットへのアクセスの管理](access-points.md)」を参照してください。
+ **高スループットワークロード** - Mountpoint for Amazon S3 は、Amazon S3 汎用バケットをローカルファイルシステムとしてマウントするための、高スループットのオープンソースファイルクライアントです。Mountpoint を使用すると、アプリケーションは、開く、読み取るなどのファイルシステム操作を通じて Amazon S3 に保存されているオブジェクトにアクセスできます。Mountpoint はこれらの操作を S3 オブジェクト API 呼び出しに自動的に変換し、アプリケーションが Amazon S3 のエラスティックなストレージとスループットにファイルインターフェイスを通じてアクセスできるようにします。詳細については、「[Amazon S3 バケットをローカルファイルシステムとしてマウントする](mountpoint.md)」を参照してください。
+ **マルチリージョンアプリケーション** －Amazon S3 マルチリージョンアクセスポイントは、複数の AWS リージョンにある S3 汎用バケットからのリクエストを満たすためにアプリケーションで使用できるグローバルエンドポイントを提供します。マルチリージョンアクセスポイントを使用して、単一のリージョンで使用するのと同じシンプルなアーキテクチャでマルチリージョンアプリケーションを構築し、世界中のどこでもこれらのアプリケーションを実行することができます。マルチリージョンのアクセスポイントは、パブリックインターネット経由でリクエストを送信する代わりに、Amazon S3 へのインターネットベースのリクエストを高速化する組み込みのネットワーク耐障害性を実現します。詳細については、「[マルチリージョンアクセスポイントを使用したマルチリージョントラフィックの管理](MultiRegionAccessPoints.md)」を参照してください。
+ **Secure Shell (SSH) File Transfer プロトコル (SFTP)** — インターネット経由で機密データを安全に転送する場合は、Amazon S3 汎用バケットで SFTP 対応サーバーを使用できます。AWS SFTP は、SSH のセキュリティおよび認証機能を完全にサポートするネットワークプロトコルです。このプロトコルでは、ユーザー ID、権限、キーをきめ細かく制御したり、IAM ポリシーを使用してアクセスを管理したりできます。SFTP 対応サーバーを Amazon S3 バケットに関連付けるには、まず SFTP 対応サーバーを作成してください。次に、ユーザーアカウントを設定し、サーバーを Amazon S3 汎用バケットに関連付けます。このプロセスのウォークスルーについては、「*AWS ブログ*」の「[AWS Transfer for SFTP – Amazon S3 用のフルマネージド SFTP サービス](https://aws.amazon.com/blogs/aws/new-aws-transfer-for-sftp-fully-managed-sftp-service-for-amazon-s3/)」を参照してください。

## Amazon S3 コンソール
<a name="accessing-aws-management-console"></a>

コンソールは、Amazon S3 と AWS リソースを管理するためのウェブベースのユーザーインターフェイスです。Amazon S3 コンソールでは、バケットに簡単にアクセスしてバケットのプロパティを変更できます。コンソール UI を使用すると、コードを記述することなく、ほとんどのバケットオペレーションを実行することもできます。

AWS アカウント にサインアップ済みの場合は、Amazon S3 コンソールにサインインし、そのホームページで **[S3]** を選択することで、Amazon S3 コンソールにアクセスできます。こちらのリンク ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を使用して直接アクセスすることもできます。

## AWS CLI
<a name="accessing-aws-cli"></a>

AWS CLI を使用すると、コマンドを発行したり、システムのコマンドラインでスクリプトを作成したりして、AWS (S3 を含む) のタスクを実行できます。例えば、複数のバケットにアクセスする必要がある場合は、AWS CLI を使用して一般的で反復的なタスクを自動化することで時間を節約できます。組織の規模が拡大するにつれて、一般的なアクションのスクリプト作成性と再現性が頻繁に検討されます。

[AWS CLI](https://aws.amazon.com/cli/) は、幅広い AWS のサービスのセットに対するコマンドを提供しています。AWS CLI は、Windows、macOS、Linux でサポートされています。使用を開始するには、「 [https://docs.aws.amazon.com/cli/latest/userguide/](https://docs.aws.amazon.com/cli/latest/userguide/)」を参照してください。Amazon S3 用コマンドの詳細については、*AWS CLIコマンドリファレンス*の [s3api](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/index.html) および [s3control](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/index.html) を参照してください。

## AWS SDK
<a name="accessing-aws-sdks"></a>

AWS には、さまざまなプログラミング言語およびプラットフォーム (Java、Python、Ruby、.NET、iOS、Android など) のライブラリとサンプルコードで構成された SDK (ソフトウェア開発キット) が用意されています。AWS SDK は、S3 や AWS へのプログラムによるアクセスを作成するのに役立ちます。Amazon S3 は REST サービスです。AWS SDK ライブラリを使用して Amazon S3 にリクエストを送信できます。これは、基盤となる Amazon S3 REST API をラップし、プログラミングタスクを簡素化します。例えば、SDK は署名の計算、リクエストの暗号化による署名、エラーの管理、リクエストの自動再試行などのタスクを処理します。AWS SDK のダウンロードやインストールなどの詳細については、「[AWS のツール](https://aws.amazon.com/tools/)」を参照してください。

Amazon S3 とのすべてのやり取りは認証されるか匿名で行われます。AWS SDK を使用している場合、指定したキーから、ライブラリによって認証のための署名が計算されます。Amazon S3 へのリクエストの作成方法の詳細については、「[Making requests](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)」を参照してください。

## Amazon S3 REST API
<a name="AccessingUsingRESTAPI"></a>

Amazon S3 は、プログラミング言語に依存しないアーキテクチャとして設計されており、AWS がサポートされているインターフェイスを使用してオブジェクトを保存、取得します。Amazon S3 REST API を使用して、プログラムによって S3 や AWS にアクセスすることができます。REST API は、Amazon S3 に対する HTTP インターフェイスです。REST API では、標準 HTTP リクエストを使用してバケットとオブジェクトを作成、取得、削除できます。

REST API を使用する場合、HTTP をサポートする任意のツールキットを使用できます。匿名で読み取り可能なオブジェクトであれば、ブラウザを使用して取得することもできます。

REST API は標準の HTTP ヘッダーとステータスコードを使用するため、標準のブラウザとツールキットが予期したとおりに機能します。一部のエリアでは、HTTP に機能が追加されています (たとえば、アクセスコントロールをサポートするヘッダーを追加しました)。このように新機能を追加する場合、できるだけ標準 HTTP 書式の使用法に合致するように最善を尽くしました。

ただし、アプリケーションで直接 REST API を呼び出す場合、署名を計算するコードを作成し、それをリクエストに追加する必要があります。Amazon S3 にリクエストを行う方法の詳細については、「Amazon S3 リファレンス」の「[Making requests](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)」を参照してください。**

# 汎用バケットの仮想ホスティング
<a name="VirtualHosting"></a>

仮想ホスティングとは、単一のウェブサーバーから複数のウェブサイトにサービスを提供することです。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 エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/s3.html)」を参照してください。

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

**重要**  
SSL と共に仮想ホスト形式の汎用バケットを使用している場合、SSL ワイルドカード証明書は、ドット (「`.`」) を含まないバケットのみと一致します。この制限を回避するには、HTTP を使用するか、または独自の証明書検証ロジックを記述します。詳細については、*AWS ニュースブログ*の[Amazon S3 パスの非推奨化プラン](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/)を参照してください。

**Topics**
+ [パス形式のリクエスト](#path-style-access)
+ [仮想ホスト形式のリクエスト](#virtual-hosted-style-access)
+ [HTTP `Host` ヘッダーバケット仕様](#VirtualHostingSpecifyBucket)
+ [例](#VirtualHostingExamples)
+ [CNAME レコードを使用した Amazon S3 URL のカスタマイズ](#VirtualHostingCustomURLs)
+ [ホスト名を Amazon S3 バケットに関連付ける方法](#VirtualHostingCustomURLsHowTo)
+ [制限事項](#VirtualHostingLimitations)
+ [下位互換性](#VirtualHostingBackwardsCompatibility)

## パス形式のリクエスト
<a name="path-style-access"></a>

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

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

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

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

```
https://s3.us-west-2.amazonaws.com/amzn-s3-demo-bucket1/puppy.jpg
```

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

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

## 仮想ホスト形式のリクエスト
<a name="virtual-hosted-style-access"></a>

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

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

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

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

```
https://amzn-s3-demo-bucket1.s3.us-west-2.amazonaws.com/puppy.png
```

## HTTP `Host` ヘッダーバケット仕様
<a name="VirtualHostingSpecifyBucket"></a>

`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 レコードの設定の手順については扱いませんが、このセクションの最後の例にその結果を示します。

## 例
<a name="VirtualHostingExamples"></a>

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

**Example — パス形式の URL とリクエスト**  
この例では以下を使用しています。  
+ バケット名 ‐ `example.com`
+ リージョン ‐ 米国東部 (バージニア北部) 
+ キー名 ‐ `homepage.html`
URL は次のとおりです。  

```
1. http://s3.us-east-1.amazonaws.com/example.com/homepage.html
```
リクエストは次のとおりです。  

```
1. GET /example.com/homepage.html HTTP/1.1
2. Host: s3.us-east-1.amazonaws.com
```
HTTP 1.0 でのリクエストと `Host` ヘッダーの省略は次のとおりです。  

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

DNS 互換名については、「[制約事項](#VirtualHostingLimitations)」を参照してください。キーの詳細については、「[キー](Welcome.md#BasicsKeys)」を参照してください。

**Example — 仮想ホスト形式の URL とリクエスト**  
この例では以下を使用しています。  
+ **バケット名** ‐ `amzn-s3-demo-bucket1` 
+ **リージョン** ‐ 欧州 (アイルランド) 
+ **キー名** ‐ `homepage.html`
URL は次のとおりです。  

```
1. http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html
```
リクエストは次のとおりです。  

```
1. GET /homepage.html HTTP/1.1
2. Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com
```

**Example — CNAME エイリアス方式**  
この方式を使用するには、DNS 名を `bucket-name.s3.us-east-1.amazonaws.com` の CNAME エイリアスとして設定する必要があります。詳細については、「[CNAME レコードを使用した Amazon S3 URL のカスタマイズ](#VirtualHostingCustomURLs)」を参照してください。  
この例では以下を使用しています。  
+ バケット名 ‐ `example.com` 
+ **キー名** ‐ `homepage.html`
URL は次のとおりです。  

```
1. http://www.example.com/homepage.html
```
例は次のとおりです。  

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

## CNAME レコードを使用した Amazon S3 URL のカスタマイズ
<a name="VirtualHostingCustomURLs"></a>

要件によっては、「`s3.region-code.amazonaws.com`」をウェブサイトまたはサービスに表示したくない場合もあります。例えば、ウェブサイトの画像を Amazon S3 でホスティングしている場合に、`http://images.example.com.s3.us-east-1.amazonaws.com/` ではなく `http://images.example.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` のエイリアスであることが必要です。

```
1. 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 は次のようなリクエストを受け取ります。

**Example**  

```
1. GET / HTTP/1.1
2. Host: www.example.com
3. Date: date
4. Authorization: signatureValue
```

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

どの Amazon S3 エンドポイントも、CNAME エイリアスで使用できます。たとえば、`s3.ap-southeast-1.amazonaws.com` は CNAME エイリアスで使用できます。エンドポイントの詳細については、「*Amazon S3 API リファレンス*」の「[リクエストエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTAPI.html)」を参照してください。カスタムドメインを使用して静的ウェブサイトを作成するには、[チュートリアル: Route 53 に登録されたカスタムドメインを使用した静的ウェブサイトの設定](website-hosting-custom-domain-walkthrough.md) を参照してください。

**重要**  
CNAME でカスタム URL を使用する場合は、設定した CNAME またはエイリアスレコードに一致するバケットが存在することを確認する必要があります。たとえば、`www.example.com` と `login.example.com` の DNS エントリを作成し、S3 を使用してウェブコンテンツを公開するには、`www.example.com` と `login.example.com` の両方のバケットを作成する必要があります。  
CNAME またはエイリアスレコードが、一致するバケットがない S3 エンドポイントをポイントするように設定されている場合、AWS ユーザーは、所有権が同じでなくても、そのバケットを作成し、設定されたエイリアスでコンテンツを公開できます。  
同じ理由で、バケットを削除するときは、対応する CNAME またはエイリアスを変更または削除することをお勧めします。

## ホスト名を Amazon S3 バケットに関連付ける方法
<a name="VirtualHostingCustomURLsHowTo"></a>

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

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

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

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

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

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

   例: 

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

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

## 制限事項
<a name="VirtualHostingLimitations"></a>

 SOAP API for Amazon S3 は新規顧客には利用できず、2025 年 8 月 31 日にサポート終了 (EOL) となります。REST API か AWS SDK を使用することをお勧めします。

## 下位互換性
<a name="VirtualHostingBackwardsCompatibility"></a>

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

### レガシーエンドポイント
<a name="s3-legacy-endpoints"></a>

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

**重要**  
ログにレガシーエンドポイントが表示される場合もありますが、バケットにアクセスするには、常に標準のエンドポイント構文を使用することをお勧めします。  
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
<a name="s3-dash-region"></a>

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

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

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

```
https://amzn-s3-demo-bucket1.s3-us-west-2.amazonaws.com
```

#### レガシーグローバルエンドポイント
<a name="deprecated-global-endpoint"></a>

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

```
bucket-name.s3.amazonaws.com
```

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

```
https://amzn-s3-demo-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 エラーが返されます。詳細については、「Amazon S3 API リファレンス」の「[Making requests](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)」を参照してください。**

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

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