Hospedagem virtual de buckets - Amazon Simple Storage Service

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://bucket-name.s3.region-code.amazonaws.com. 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.

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.bucket-name.com/. 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, 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 (Plano de depreciação de caminhos do Amazon S3) no AWS News Blog.

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 no Blog de notícias da AWS.

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 for s3.region-code.amazonaws.com, 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çalho Host é válido apenas para solicitações HTTP 1.0.

  • Caso contrário, se o valor do cabeçalho Host terminar com .s3.region-code.amazonaws.com, o nome do bucket será o componente inicial do valor do cabeçalho Host até .s3.region-code.amazonaws.com. A chave da solicitação será o seu URI. Essa interpretação expõe buckets como subdomínios do .s3.region-code.amazonaws.com, conforme ilustrado pelo terceiro e pelo quarto exemplos nesta seção.

  • 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 bucket-name.s3.us-east-1.amazonaws.com. Para obter mais informações, consulte Personalizar URLs do Amazon S3 com registros CNAME.

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.region-code.amazonaws.com apareça no site ou serviço. Por exemplo, se você estiver hospedando as imagens do site no Amazon S3, talvez prefira http://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://BucketName.s3.Region.amazonaws.com/[Filename], por exemplo, 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
  1. Selecione um nome de host que pertença a um domínio controlado por você.

    Este exemplo usa o subdomínio images do domínio example.com.

  2. 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.

  3. 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/bucket-name para um bucket criado na região Oeste dos EUA (Oregon), você receberá um erro de redirecionamento temporário HTTP 307.