Existe uma pequna configuração a ser feita no CloudFront para enviar quaisquer links não encontrados como arquivos físicos no S3 para sua aplicação interpretar e realizar a navegação por rotas.

Para simular o problema, vamos utilizar a aplicação exemplo para rotas Angular, mas fique a vontade para usar a sua e simplesmente testar a solução.

Projeto Angular

Após realizar o download do projeto, executei os seguintes comandos:

npm install
npm run build

Ao finalizar, será criada a pasta “dist/” na raiz do seu projeto. Iremos subir todos os arquivos dessa página em um Bucket S3.

Aplicação

Conseguimos acessar e utilizar toda a aplicação.

Mas, infelizmente, ao tentar atualizar a página ou acessar por um link de rota, recebemos o seguinte erro:

Tudo bem, sem pânico, a solução para esse problema é muito simples. Mas primeiro, vamos entender por que ele acontence.

Ao navegar pelas rotas Angular, a aplicação utiliza a própria URL para servir como histórico e ponto de entrada direto na aplicação. Em outros servidores web como Apache e NGinx existe uma configuração adicional para enviar a URL acessada para a aplicação Angular escolher fazer com ela. Sem essa configuração o servidor web irá simplementes tentar buscar o arquivo em disco.

Configuração no CloudFront

No CloudFront é necessário exatamente a mesma configuração, para aplicá-la, faça o seguinte:

Vá até a sua distribuição do CloudFront, navegue para a aba “Error Pages” e crie uma nova resposta customizada com os seguintes valores:

Vamos entender o motivo de cada configuração:

Mapeamos o erro 404 pois ele é o erro referente a um arquivo não encontrado fisicamente (não existe o arquivo “hero-list” no Bucket S3).

Customizamos então a resposta para carregar o arquivo “index.html” (arquivo inicial da aplicação Angular) e em seguida iremos informar ao navegador do usuário que não houve erro, por isso o novo código 200.

Assim carregaremos a aplicação angular normalmente com a URL que o usuário tentou acessar.

PS: Caso você possua uma tela de erro de permissão ou login customizada você pode criar mais uma resposta customizado para o erro 403 e tratar a rota no Angular.

O post Rotas no Angular + S3 + CloudFront? apareceu primeiro em Resenha do dev.

Como a infraestrutura global é dividida entre regiões, zonas de disponibilidade e pontos de presença da AWS ao redor do global.

Regiões – Regions

Regiões são localizações importantes onde a AWS está presente. O nível de região não é ainda um datacenter físico, mas um conjunto de duas ou mais zonas de disponibilidade.

Zonas de disponibilidade – Availability Zone

Zonas de disponibilidade são a construção física de um datacenter. Como mencionado nas regiões, há um grupo de zonas de disponibilidade em cada região, como por exemplo, a região de São Paulo (sa-east-1).

A cidade de São Paulo conta com 3 zonas de disponibilidade e o padrão de nomenclatura para cada zona é o nome da região + uma letra, iniciando em A.

• sa-east-1a
• sa-east-1b
• sa-east-1c

Cada zona de disponibilidade possuí uma rede física local, sendo nela que você criar seus servidores EC2 para hospedar cada uma de suas aplicações.

Como há uma conexão física entre cada zona e entre todas as regiões, todos os serviços estão disponíveis em todas as regiões. Contudo, muitos dos dados trafegados entre regiões, e as vezes até mesmo entre zonas, pode haver uma cobrança adicional.

Ponto de presença – AWS Edge Location

Por fim, o último ponto da infraestrutura da AWS são os pontos de presença.

Eles nada mais são que pontos espalhados pelo globo com o único propósito de deixar seu conteúdo mais próximo do seu usuário.

Nos pontos de presença não é possível criar nenhum recurso AWS, pois eles são utilizados unicamente pelo CloudFront (Content Delivery Network – CDN da AWS) para armazenar o cache dos arquivos disponíveis em uma zona de disponibilidade.

Os pontos de presença vinculados a região de São Paulo são:

• Rio de Janeiro, Brasil
• São Paulo, Brasil
• Bogotá, Colômbia
• Buenos Aires, Argentina
• Santiago, Chile

Reduzindo a latência, tempo entre a conexão do usuário e o servidor, em cada requisição. Porque ao invés de você se conectar diretamente à um servidor na região de Virginia do Norte (us-east-1), nos EUA, você se conecta no servidor mais próximo da AWS e a partir deste momento, o tráfego é feito pelo link dedicados que a AWS tem entre cada região.

O post AWS – Infraestrutura global apareceu primeiro em Resenha do dev.