# Hospedagem virtual de buckets de uso geral 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 de uso geral 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](https://docs.aws.amazon.com/general/latest/gr/s3.html) 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 utilizar buckets de uso geral no estilo de hospedagem virtual com SSL, o certificado SSL curinga 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](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/) (Plano de depreciação de caminhos do Amazon S3) no *AWS News Blog.* **Topics** + [Solicitações no estilo de caminho](#path-style-access) + [Solicitações no estilo de hospedagem virtual](#virtual-hosted-style-access) + [Especificação de bucket do cabeçalho `Host` HTTP](#VirtualHostingSpecifyBucket) + [Exemplos](#VirtualHostingExamples) + [Personalizar URLs do Amazon S3 com registros CNAME](#VirtualHostingCustomURLs) + [Como associar um nome de host a um bucket do Amazon S3](#VirtualHostingCustomURLsHowTo) + [Limitações](#VirtualHostingLimitations) + [Compatibilidade retroativa](#VirtualHostingBackwardsCompatibility) ## 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](https://aws.amazon.com/blogs/aws/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](WebsiteEndpoints.md) e [Implantar uma aplicação de página única baseado em reação no Amazon S3 e no CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) 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. **Example – 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: ``` 1. http://s3.us-east-1.amazonaws.com/example.com/homepage.html ``` A solicitação é a seguinte: ``` 1. GET /example.com/homepage.html HTTP/1.1 2. Host: s3.us-east-1.amazonaws.com ``` A solicitação com HTTP 1.0 e a omissão do cabeçalho `Host` é a seguinte: ``` 1. GET /example.com/homepage.html HTTP/1.0 ``` Para obter informações sobre nomes compatíveis do DNS, consulte [Limitações](#VirtualHostingLimitations). Para obter mais informações sobre chaves, consulte [Chaves](Welcome.md#BasicsKeys). **Example – 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: ``` 1. http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html ``` A solicitação é a seguinte: ``` 1. GET /homepage.html HTTP/1.1 2. Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com ``` **Example – 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](#VirtualHostingCustomURLs). Este exemplo usa o seguinte: + Nome do bucke ‐ `example.com` + **Nome da chave** ‐ `homepage.html` O URL é o seguinte: ``` 1. http://www.example.com/homepage.html ``` O exemplo é o seguinte: ``` 1. GET /homepage.html HTTP/1.1 2. 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`. ``` 1. 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: **Example** ``` 1. GET / HTTP/1.1 2. Host: www.example.com 3. Date: date 4. 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](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTAPI.html) 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](website-hosting-custom-domain-walkthrough.md). **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`. 1. 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. 1. 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 As APIs SOAP para o Amazon S3 não estão disponíveis para novos clientes e chegam ao fim da vida útil (EOL) em 31 de agosto de 2025. 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](https://docs.aws.amazon.com/general/latest/gr/s3.html) 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](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html) 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 legado ou outro endpoint diferente daquele para a região onde o bucket reside, você receberá um erro de redirecionamento permanente com o código 301 de resposta HTTP e uma mensagem indicando o URI correto para o recurso. Por exemplo, se usar `https://s3.amazonaws.com/bucket-name` para um bucket criado na região Oeste dos EUA (Oregon), você receberá um erro de redirecionamento permanente HTTP 301.