Hospedagem virtual de buckets
Hospedagem virtual é a prática de atender vários sites a partir de um único servidor web. Uma maneira de diferenciar sites em suas solicitações de API REST do Amazon S3 é usar o nome de host aparente do URI da solicitação em vez de apenas a parte do nome do caminho do URI. Uma solicitação REST comum do Amazon S3 especifica um bucket usando o primeiro componente delimitado por barra do caminho do URI da solicitação. Em vez disso, você pode usar a hospedagem virtual do Amazon S3 para endereçar um bucket em uma chamada de API REST usando o cabeçalho Host
HTTP. Na prática, o Amazon S3 interpreta Host
como um aviso de que a maioria dos buckets são acessíveis automaticamente (para tipos limitados de solicitações) em https://
. Para obter uma lista completa de regiões e endpoints do Amazon S3, consulte Endpoints e cotas do Amazon S3 na Referência geral da Amazon Web Services.bucket-name
.s3.region-code
.amazonaws.com
Além disso, a hospedagem virtual tem outros benefícios. Ao nomear o bucket com o nome do domínio registrado e ao tornar esse nome um alias do DNS para o Amazon S3, você pode personalizar totalmente o URL dos recursos do Amazon S3, por exemplo, http://my.
. Você também pode publicar no “diretório raiz” do servidor virtual do bucket. Esta habilidade pode ser importante pois muitos aplicativos buscam arquivos nesse local padrão. Por exemplo, bucket-name
.com/favicon.ico
, robots.txt
e crossdomain.xml
serão todos encontrados na raiz.
Importante
Ao usar buckets no estilo de hospedagem virtual com SSL, o certificado curinga SSL corresponde apenas a buckets que não contêm pontos (.
). Para contornar essa limitação, use HTTP ou escreva sua própria lógica de verificação de certificado. Para obter mais informações, consulte Amazon S3 Path Deprecation Plan
Tópicos
Solicitações no estilo de caminho
Atualmente, o Amazon S3 é compatível com o acesso a URLs no estilo de hospedagem virtual e no estilo de caminho em todas as Regiões da AWS. No entanto, os URLs no estilo de caminho serão descontinuados no futuro. Para obter mais informações, consulte a observação Importante a seguir.
No Amazon S3, os URLs no estilo de caminho usam o seguinte formato:
https://s3.
region-code
.amazonaws.com/bucket-name
/key-name
Por exemplo, se você criar um bucket chamado amzn-s3-demo-bucket1
na região Oeste dos EUA (Oregon) e quiser acessar o objeto puppy.jpg
nele, use o seguinte URL no estilo de caminho:
https://s3.us-west-2.amazonaws.com/amzn-s3-demo-bucket1/puppy.jpg
Importante
Atualização (23 de setembro de 2020): para garantir que os clientes tenham o tempo necessário para fazer a transição para URLs no estilo de hospedagem virtual, decidimos postergar a desativação de URLs no estilo de caminho. Para obter mais informações, consulte Amazon S3 Path Deprecation Plan – The Rest of the Story
Atenção
Ao hospedar o conteúdo de um site que será acessado de um navegador da web, evite usar URLs no estilo de caminho, que podem interferir no modelo de segurança da mesma origem do navegador. Para hospedar o conteúdo do site, recomendamos que você use os endpoints do site do S3 ou uma distribuição do CloudFront. Para obter mais informações, consulte Endpoints de site e Implantar uma aplicação de página única baseado em reação no Amazon S3 e no CloudFront nos Padrões de orientação de perspectiva da AWS.
Solicitações no estilo de hospedagem virtual
Em um URL de estilo hospedado virtual, o nome do bucket faz parte do nome do domínio no URL.
Os URLs no estilo de hospedagem virtual do Amazon S3 usam o seguinte formato:
https://
bucket-name
.s3.region-code
.amazonaws.com/key-name
Neste exemplo, amzn-s3-demo-bucket1
é o nome do bucket, Oeste dos EUA (Oregon) é a região, e puppy.png
é o nome da chave.
https://amzn-s3-demo-bucket1.s3.us-west-2.amazonaws.com/puppy.png
Especificação de bucket do cabeçalho Host
HTTP
Desde que a solicitação GET
não use o endpoint SSL, você pode especificar o bucket para a solicitação usando o cabeçalho Host
HTTP. O cabeçalho Host
em uma solicitação REST é interpretado da seguinte forma:
-
Se o cabeçalho
Host
estiver omitido ou se o seu valor fors3.
, o bucket para a solicitação será o primeiro componente delimitado por barra no URI da solicitação e a chave da solicitação será o restante do URI. Este é o método comum, conforme ilustrado pelos dois primeiros exemplos desta seção. Omitir o cabeçalhoregion-code
.amazonaws.com.rproxy.goskope.comHost
é válido apenas para solicitações HTTP 1.0. -
Caso contrário, se o valor do cabeçalho
Host
terminar com.s3.
, o nome do bucket será o componente inicial do valor do cabeçalhoregion-code
.amazonaws.com.rproxy.goskope.comHost
até.s3.
. A chave da solicitação será o seu URI. Essa interpretação expõe buckets como subdomínios doregion-code
.amazonaws.com.rproxy.goskope.com.s3.
, conforme ilustrado pelo terceiro e pelo quarto exemplos nesta seção.region-code
.amazonaws.com -
Caso contrário, o bucket da solicitação é o valor em letras minúsculas do cabeçalho
Host
, e a chave da solicitação é o seu URI. Essa interpretação é útil se você tiver registrado o mesmo nome DNS que o nome do bucket e se tiver configurado o nome para ser um alias (CNAME) de nome canônico para o Amazon S3. O procedimento para registrar nomes de domínio e configurar o CNAME DNS está além do escopo deste guia, mas o resultado é ilustrado pelo último exemplo desta seção.
Exemplos
Esta seção fornece exemplos de URLs e solicitações.
exemplo – URLs no estilo de caminho e solicitações
Este exemplo usa o seguinte:
-
Nome do bucke ‐
example.com
-
Região: Leste dos EUA (Norte da Virgínia)
-
Nome da chave:
homepage.html
O URL é o seguinte:
http://s3.us-east-1.amazonaws.com/example.com/homepage.html
A solicitação é a seguinte:
GET /example.com/homepage.html HTTP/1.1 Host: s3.us-east-1.amazonaws.com
A solicitação com HTTP 1.0 e a omissão do cabeçalho Host
é a seguinte:
GET /example.com/homepage.html HTTP/1.0
Para obter informações sobre nomes compatíveis do DNS, consulte Limitações. Para obter mais informações sobre chaves, consulte Chaves.
exemplo – Solicitações e URLs no estilo de hospedagem virtual
Este exemplo usa o seguinte:
-
Nome do bucket:
amzn-s3-demo-bucket1
-
Região: Europa (Irlanda)
-
Nome da chave:
homepage.html
O URL é o seguinte:
http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html
A solicitação é a seguinte:
GET /homepage.html HTTP/1.1 Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com
exemplo – método de alias CNAME
Para usar este método, é necessário configurar o nome de DNS como um alias CNAME para
. Para obter mais informações, consulte Personalizar URLs do Amazon S3 com registros CNAME. bucket-name
.s3.us-east-1.amazonaws.com
Este exemplo usa o seguinte:
-
Nome do bucke ‐
example.com
-
Nome da chave:
homepage.html
O URL é o seguinte:
http://www.example.com/homepage.html
O exemplo é o seguinte:
GET /homepage.html HTTP/1.1 Host: www.example.com
Personalizar URLs do Amazon S3 com registros CNAME
Dependendo da necessidade, é possível que você não queira que s3.
apareça no site ou serviço. Por exemplo, se você estiver hospedando as imagens do site no Amazon S3, talvez prefira region-code
.amazonaws.com.rproxy.goskope.comhttp://images.example.com/
em vez de http://images.example.com.s3.us-east-1.amazonaws.com/
. Qualquer bucket com um nome compatível com o DNS pode ser mencionado da seguinte forma:
http://
, por exemplo, BucketName
.s3.Region
.amazonaws.com/[Filename
]http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg
. Ao usar o CNAME, mapeie images.example.com
para um nome de host do Amazon S3, para que o URL anterior se torne http://images.example.com/mydog.jpg
.
O nome do bucket deve ser o mesmo que o CNAME. Por exemplo, se você criar um CNAME para mapear images.example.com
para images.example.com.s3.us-east-1.amazonaws.com
, http://images.example.com/filename
e http://images.example.com.s3.us-east-1.amazonaws.com/filename
serão o mesmo.
O registro DNS do CNAME deve apelidar o nome do domínio para o nome de host apropriado do estilo de hospedagem virtual. Por exemplo, se o nome do bucket e o nome do domínio forem images.example.com
e o bucket estiver na região Leste dos EUA (Norte da Virgínia), o alias do registro do CNAME deverá ser images.example.com.s3.us-east-1.amazonaws.com
.
images.example.com CNAME images.example.com.s3.us-east-1.amazonaws.com.
O Amazon S3 usa o nome de host para determinar o nome do bucket. O nome do CNAME e o nome do bucket devem ser os mesmos. Por exemplo, suponha que você tenha configurado www.example.com
como um CNAME para www.example.com.s3.us-east-1.amazonaws.com
. Quando você acessa http://www.example.com
, o Amazon S3 recebe uma solicitação semelhante à seguinte:
GET / HTTP/1.1 Host: www.example.com Date:
date
Authorization:signatureValue
O Amazon S3 vê apenas o nome do host original www.example.com
e não tem conhecimento do mapeamento CNAME usado para resolver a solicitação.
Você pode usar qualquer endpoint do Amazon S3 em um alias CNAME. Por exemplo, s3.ap-southeast-1.amazonaws.com
pode ser usado em aliases CNAME. Consulte mais informações sobre endpoints em Request Endpoints na Referência de API do Amazon S3. Para criar um site estático usando um domínio personalizado, consulte Tutorial: Configurar um site estático usando um domínio personalizado registrado no Route 53.
Importante
Ao usar URLs personalizados com CNAMEs, você precisará garantir que exista um bucket correspondente para qualquer registro CNAME ou alias configurado. Por exemplo, se você criar entradas DNS para www.example.com
e login.example.com
com o objetivo de publicar conteúdo da Web usando o S3, será necessário criar os dois buckets, www.example.com
e login.example.com
.
Quando um registro CNAME ou alias é configurado apontando para um endpoint do S3 sem um bucket correspondente, qualquer usuário da AWS pode criar esse intervalo e publicar conteúdo com o alias configurado, mesmo que a propriedade não seja a mesma.
Pelo mesmo motivo, recomendamos que você altere ou remova o CNAME ou o alias correspondente ao excluir um bucket.
Como associar um nome de host a um bucket do Amazon S3
Como associar um nome de host a um bucket do Amazon S3 usando um alias CNAME
-
Selecione um nome de host que pertença a um domínio controlado por você.
Este exemplo usa o subdomínio
images
do domínioexample.com
. -
Crie um bucket que corresponda ao nome de host.
Neste exemplo, os nomes de host e do bucket são
images.example.com
. O nome do bucket deve ser exatamente igual ao nome de host. -
Crie um registro de DNS CNAME que defina o nome de host como um alias para o bucket do Amazon S3.
Por exemplo:
images.example.com CNAME images.example.com.s3.us-west-2.amazonaws.com
Importante
Por motivos de encaminhamento de solicitações, o registro de DNS CNAME deve estar definido exatamente como mostrado no exemplo anterior. Do contrário, a operação pode parecer correta, mas acabará causando um comportamento imprevisível.
O procedimento para configurar registros de DNS CNAME depende do servidor DNS ou do provedor DNS. Para obter informações específicas, consulte a documentação do servidor ou entre em contato com o provedor.
Limitações
O suporte a SOAP via HTTP está obsoleto, mas o SOAP continua disponível via HTTPS. Os novos recursos do Amazon S3 não são compatíveis com SOAP. Em vez de SOAP, recomendamos usar a API REST ou os AWS SDKs.
Compatibilidade retroativa
As seções a seguir abordam vários aspectos da compatibilidade com versões anteriores do Amazon S3 relacionados a solicitações de URL no estilo de caminho e no estilo de hospedagem virtual.
Endpoints herdados
Algumas regiões oferecem suporte a endpoints legados. Você poderá ver esses endpoints nos logs de acesso ao servidor ou nos logs do AWS CloudTrail. Para obter mais informações, leia as informações a seguir. Para obter uma lista completa de regiões e endpoints do Amazon S3, consulte Endpoints e cotas do Amazon S3 na Referência geral da Amazon Web Services.
Importante
Embora você possa ver endpoints legados nos seus logs, recomendamos que você sempre use a sintaxe do endpoint padrão para acessar os buckets.
Os URLs no estilo de hospedagem virtual do Amazon S3 usam o seguinte formato:
https://
bucket-name
.s3.region-code
.amazonaws.com/key-name
No Amazon S3, os URLs no estilo de caminho usam o seguinte formato:
https://s3.
region-code
.amazonaws.com/bucket-name
/key-name
s3‐Region
Algumas regiões mais antigas do Amazon S3 são compatíveis com endpoints que contêm um traço (-
) entre o s3
e a região (por exemplo, s3‐us-west-2
), em vez de um ponto (por exemplo, s3.us-west-2
). Se o bucket estiver em uma dessas regiões, você poderá ver o seguinte formato de endpoint nos logs de acesso ao servidor ou nos logs do CloudTrail:
https://
bucket-name
.s3-region-code
.amazonaws.com
Neste exemplo, o nome do bucket é amzn-s3-demo-bucket1 e a região é Oeste dos EUA (Oregon):
https://amzn-s3-demo-bucket1.s3-us-west-2.amazonaws.com
Endpoint global herdado
Para algumas regiões, é possível usar o endpoint global herdado para criar solicitações que não explicitam um endpoint específico da região. A seguir, o endpoint global herdado:
bucket-name
.s3.amazonaws.com
Nos logs de acesso ao servidor ou nos logs do CloudTrail, você poderá ver solicitações que usam o endpoint global herdado. Neste exemplo, o nome do bucket é amzn-s3-demo-bucket1
e o endpoint global herdado é:
https://amzn-s3-demo-bucket1.s3.amazonaws.com
Solicitações no estilo de hospedagem virtual para Leste dos EUA (N. da Virgínia)
Por padrão, as solicitações feitas com o endpoint global herdado vão para a região Leste dos EUA (N. da Virgínia). Portanto, o endpoint global herdado às vezes é usado no lugar do endpoint regional para o Leste dos EUA (Norte da Virgínia). Se você criar um bucket no Leste dos EUA (Norte da Virgínia) e usar o endpoint global, o Amazon S3 roteará sua solicitação para essa região por padrão.
Solicitações no estilo de hospedagem virtual para outras regiões
O endpoint global herdado também é usado para solicitações no estilo de hospedagem virtual em outras regiões compatíveis. Se você criar um bucket em uma região lançada antes de 20 de março de 2019 e usar o endpoint global herdado, o Amazon S3 atualizará o registro DNS para encaminhar novamente a solicitação ao local correto, o que pode levar algum tempo. Enquanto isso, a regra padrão se aplica e sua solicitação no estilo de hospedagem virtual vai para a região Leste dos EUA (N. da Virgínia). Depois, o Amazon S3 a redireciona com um redirecionamento temporário HTTP 307 à região correta.
Para buckets do S3 em regiões lançadas após 20 de março de 2019, o servidor DNS não encaminha a solicitação diretamente à Região da AWS na qual o bucket reside. Em vez disso, ele retorna um erro de solicitação incorreta HTTP 400. Consulte mais informações em Making requests na Referência da API do Amazon S3.
Solicitações no estilo de caminho
Para a região Leste dos EUA (N. da Virgínia), você pode usar o endpoint global herdado para solicitações no estilo de caminho.
Para todas as outras regiões, a sintaxe de caminho exige usar o endpoint específico da região ao tentar acessar um bucket. Se tentar acessar um bucket com o endpoint global herdado ou outro endpoint diferente daquele para a região onde o bucket reside, você receberá um erro de redirecionamento temporário com o código 307 de resposta HTTP e uma mensagem indicando o URI correto para o seu recurso. Por exemplo, se você usar https://s3.amazonaws.com/
para um bucket criado na região Oeste dos EUA (Oregon), você receberá um erro de redirecionamento temporário HTTP 307.bucket-name