Hébergement virtuel de compartiments

L’hébergement virtuel consiste à servir plusieurs sites web à partir d’un seul serveur web. Une façon de différencier les sites dans vos demandes d’API REST Amazon S3 consiste à utiliser le nom d’hôte apparent du Request-URI plutôt que simplement la partie du nom du chemin de l’URI. Une demande REST Amazon S3 ordinaire spécifie un compartiment en utilisant le premier composant délimité par une barre oblique du chemin de l’URI de demande. Sinon, vous pouvez utiliser l’hébergement virtuel Amazon S3 pour accéder à un compartiment dans un appel d’API REST grâce à l’en-tête HTTP Host. En pratique, Amazon S3 interprète Host en ce sens que la plupart des compartiments sont automatiquement accessibles (pour un type limité de demandes) à l’adresse https://bucket-name.s3.region-code.amazonaws.com. Pour obtenir la liste complète des régions et points de terminaison Amazon S3, consultez Points de terminaison et quotas Amazon S3 dans le Référence générale d'Amazon Web Services.

L’hébergement virtuel présente d’autres avantages. Par ailleurs, en nommant le compartiment après avoir enregistré le nom de domaine et en faisant de ce nom un alias DNS pour Amazon S3, vous pouvez totalement personnaliser l’URL des ressources Amazon S3, par exemple, http://my.bucket-name.com/. Vous pouvez également publier dans le « répertoire racine » du serveur virtuel de votre compartiment. Cet avantage peut être considérable car beaucoup d’applications existantes recherchent des fichiers dans cet emplacement standard. Par exemple, on peut s’attendre à ce que les fichiers favicon.ico, robots.txt et crossdomain.xml se trouvent tous à la racine.

Demandes de type chemin d’accès

Amazon S3 prend actuellement en charge l’accès aux URL de type hébergement virtuel et chemin d’accès dans toutes les Régions AWS. Cependant, le style path-style URLs sera abandonné à l'avenir. Pour plus d’informations, consultez la remarque importante suivante.

Dans Amazon S3, le style de chemin URLs utilise le format suivant :

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

Par exemple, si vous créez un compartiment nommé amzn-s3-demo-bucket1 dans la Région USA Ouest (Oregon) et que vous souhaitez accéder à l’objet puppy.jpg dans ce compartiment, vous pouvez utiliser l’URL de type chemin suivant :

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

Demandes de type hébergement virtuel

Dans un URI de type hébergement virtuel, le nom du compartiment fait partie du nom de domaine compris dans l’URL.

Le style Amazon S3 URLs virtual-hosted—utilise le format suivant :

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

Dans cet exemple, amzn-s3-demo-bucket1 représente le nom de compartiment, USA Ouest (Oregon) représente la Région et puppy.png est le nom de la clé :

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

Spécification d’un compartiment d’en-tête Host HTTP

Tant que la demande GET n’utilise pas le point de terminaison SSL, vous pouvez spécifier le compartiment pour la demande grâce à l’en-tête Host HTTP. L’en-tête Host dans la demande REST est interprété comme suit :

Exemples

Cette section fournit des exemples URLs et des demandes.

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

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

Pour en savoir plus sur les noms compatibles avec le DNS, consultez Limitations. Pour en savoir plus sur les clés, consultez Clés.

http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html

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

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

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

Personnalisation d'Amazon S3 URLs avec des enregistrements CNAME

Selon vos besoins, vous préférerez peut-être que s3.region-code.amazonaws.com n’apparaisse pas sur votre site web ou service. Par exemple, si vous hébergez des images de site web sur Amazon S3, vous pourriez préférer http://images.example.com/ à http://images.example.com.s3.us-east-1.amazonaws.com/. Tout compartiment avec un nom compatible DNS peut être référencé comme suit : http://BucketName.s3.Region.amazonaws.com/[Filename], par exemple, http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg. Grâce au CNAME, vous pouvez mapper images.example.com à un nom d’hôte Amazon S3 pour que l’URL précédente puisse devenir http://images.example.com/mydog.jpg.

Votre nom de compartiment doit être identique à CNAME. Par exemple, si vous créez un CNAME pour mapper images.example.com à images.example.com.s3.us-east-1.amazonaws.com, http://images.example.com/filename et http://images.example.com.s3.us-east-1.amazonaws.com/filename seront identiques.

L’enregistrement du DNS CNAME doit donner au nom de domaine comme alias le nom d’hôte de type hébergement virtuel approprié. Par exemple, si le nom du compartiment et le nom de domaine sont images.example.com et que votre compartiment se trouve dans la Région USA Est (Virginie du Nord), l’enregistrement CNAME doit avoir comme alias images.example.com.s3.us-east-1.amazonaws.com.

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

Amazon S3 utilise le nom d’hôte pour déterminer le nom du compartiment. C’est pourquoi le CNAME et le nom du compartiment doivent être identiques. Par exemple, admettons que vous avez configuré www.example.com comme CNAME pour www.example.com.s3.us-east-1.amazonaws.com. Lorsque vous accédez à http://www.example.com, Amazon S3 reçoit une demande semblable à la suivante :

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

Amazon S3 voit uniquement le nom d’hôte d’origine www.example.com et n’a pas connaissance du mappage CNAME utilisé pour résoudre la demande.

Vous pouvez utiliser n’importe quel point de terminaison Amazon S3 dans un alias CNAME. Par exemple, s3.ap-southeast-1.amazonaws.com peut être utilisé dans les alias CNAME. Pour plus d’informations sur les points de terminaison Amazon S3, consultez Demander des points de terminaison dans la Référence d’API Amazon S3. Pour créer un site web statique à l’aide d’un domaine personnalisé, consultez Tutoriel : configuration d’un site Web statique à l’aide d’un domaine personnalisé enregistré auprès de Route 53.

Comment associer un nom d’hôte à un compartiment Amazon S3

Limites

La prise en charge de SOAP sur HTTP est obsolète, mais SOAP continue d’être disponible sur HTTP. Les nouvelles fonctions Amazon S3 ne sont pas prises en charge pour SOAP. Au lieu d'utiliser SOAP, nous vous recommandons d'utiliser l'API REST ou le AWS SDKs.

Rétrocompatibilité

Les sections suivantes couvrent divers aspects de la rétrocompatibilité Amazon S3 en ce qui concerne les demandes d’URL de type chemin d’accès et hébergement virtuel.

Points de terminaison hérités

Certaines Régions prennent en charge les points de terminaison hérités. Vous pouvez voir ces points de terminaison dans les journaux ou AWS CloudTrail journaux d'accès de votre serveur. Pour plus d’informations, consultez les informations suivantes. Pour obtenir la liste complète des régions et points de terminaison Amazon S3, consultez Points de terminaison et quotas Amazon S3 dans le Référence générale d'Amazon Web Services.

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

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

S3-Région

Certaines régions Amazon S3 plus anciennes prennent en charge des points de terminaison contenant un tiret (-) entre s3 et le code de région (par exemple, s3‐us-west-2) au lieu d’un point (par exemple, s3.us-west-2). Si votre compartiment se trouve dans l'une de ces régions, le format de point de terminaison suivant peut s'afficher dans les journaux ou CloudTrail journaux d'accès au serveur :

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

Dans cet exemple, le nom du bucket est amzn-s3-demo-bucket1 et la région est US West (Oregon) :

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

Point de terminaison global hérité

Pour certaines régions, vous pouvez utiliser le point de terminaison global hérité pour élaborer des demandes qui ne spécifient pas de point de terminaison spécifique à la région. Le point de terminaison global hérité est comme suit :

bucket-name.s3.amazonaws.com

Dans les journaux ou CloudTrail journaux d'accès de votre serveur, vous pouvez voir des demandes qui utilisent l'ancien point de terminaison global. Dans cet exemple, le nom du compartiment est amzn-s3-demo-bucket1 et le point de terminaison global hérité est :

https://amzn-s3-demo-bucket1.s3.amazonaws.com

Demandes de type hébergement virtuel pour USA Est (Virginie du Nord)

Les demandes effectuées avec le point de terminaison global hérité sont transmises par défaut à la région USA Est (Virginie du Nord). Par conséquent, le point de terminaison global hérité est parfois utilisé à la place du point de terminaison Régional pour USA Est (Virginie du Nord). Si vous créez un compartiment dans la Région USA Est (Virginie du Nord) et que vous utilisez le point de terminaison global, Amazon S3 achemine votre demande vers cette Région par défaut.

Demandes de type hébergement virtuel pour d’autres régions

Le point de terminaison global hérité est également utilisé pour les demandes de type hébergement virtuel dans d’autres régions prises en charge. Si vous créez un compartiment dans une Région qui a été lancée avant le 20 mars 2019 et que vous utilisez le point de terminaison global hérité, Amazon S3 met à jour l’enregistrement DNS pour rediriger la demande vers l’emplacement correct, ce qui peut prendre du temps. Entre-temps, la règle par défaut s’applique et la demande de type hébergement virtuel est acheminée vers la région USA Est (Virginie du Nord). Amazon S3 la redirige ensuite avec une redirection temporaire HTTP 307 vers la région appropriée.

Pour les compartiments S3 situés dans des régions lancées après le 20 mars 2019, le serveur DNS n'achemine pas votre demande directement vers l' Région AWS endroit où réside votre compartiment. Au lieu de cela, il renvoie une erreur HTTP 400 Requête erronée. Pour plus d’informations, consultez Envoi de demandes dans la Référence d’API Amazon S3.

Demandes de type chemin d'accès

Pour la région USA Est (Virginie du Nord), vous pouvez utiliser le point de terminaison global hérité pour les demandes de type chemin d’accès.

Pour toutes les autres Régions, la syntaxe de type chemin exige l’utilisation du point de terminaison spécifique à la Région lors d’une tentative d’accès à un compartiment. Si vous essayez d’accéder à un compartiment avec le point de terminaison global hérité ou un autre point de terminaison qui est différent de celui de la Région où le compartiment réside, vous recevez un code de réponse HTTP 307 d’erreur de redirection temporaire et un message indiquant l’URI correct pour votre ressource. Par exemple, si vous utilisez https://s3.amazonaws.com/bucket-name pour un compartiment qui a été créé dans la Région USA Ouest (Oregon), vous recevez une erreur HTTP 307 Temporary Redirect (Redirection temporaire).