Hospedagem na web sem servidor em AWS App Runner

1. Cenário 1 usando um código-fonte:

   a. Envie o código para o repositório de GitHub origem.

   b. Autorize o acesso ao código-fonte durante GitHub o uso AWS CodeStar.

   c. Forneça instruções para criar e executar o serviço web e especifique um ambiente de tempo de execução gerenciado suportado pelo AWS App Runner. AWS CodeBuildem seguida, empacota automaticamente o código e suas dependências e cria uma nova imagem de contêiner.

   d. A imagem do contêiner é então enviada e armazenada em um repositório do Amazon Elastic Container Registry (Amazon ECR), hospedado na conta AWS App Runner de propriedade.

2. Cenário 2 usando uma imagem de origem:

   a. Como alternativa, comece com uma imagem pré-criada armazenada em um repositório Amazon ECR gerenciado pelo cliente, hospedado na conta de propriedade do cliente.

   b. Ao autorizar o acesso à imagem do contêiner usando uma Centro de Identidade do AWS IAM função, a imagem é então enviada e armazenada no repositório AWS App Runner gerenciado do Amazon ECR.

   Criação do App Runner Service:

3. A imagem do contêiner armazenada no Amazon ECR é então retirada para implantação como AWS Fargate tarefas sem servidor dentro da Amazon Virtual Private Cloud, AWS App Runner de propriedade da Amazon, também conhecida como Service VPC. AWS App Runner As AWS Fargate tarefas são implantadas em um AWS Fargate cluster executado em várias zonas de disponibilidade para alta disponibilidade em sub-redes privadas e configuradas com o AWS Application Auto Scaling.

4. Uma URL de serviço segura ocorre created/published após uma implantação bem-sucedida. O URL do Secure Service é mapeado para um AWS Network Load Balancer voltado para o público e recebe um nome de domínio padrão por. AWS App Runner Os clientes também podem ter associate/map um nome de domínio personalizado que possuam, mas ele deve ser resolvido publicamente e pode ser registrado na Zona Hospedada Pública do Amazon Route 53 ou em qualquer provedor de DNS.

Caminho de tráfego de entrada:

1. O cliente inicia uma solicitação para o URL do serviço.

2. O URL do serviço é resolvido para um Network Load Balancer voltado para o público usando o Amazon Route 53. O AWS NLB é automaticamente provisionado e de propriedade do serviço. AWS App Runner

3. A solicitação entra na VPC AWS App Runner de propriedade por meio do AWS Network Load Balancer (AWS NLB) e é redirecionada para um roteador de solicitação L7.

4. O Roteador de Solicitações L7 encaminha as solicitações recebidas para uma instância ou AWS Fargate tarefa específica do serviço web.

   Caminho de tráfego de saída, cenário 1 (o serviço web não exige acesso às dependências downstream dentro de uma customer/private VPC):

5. a. O tráfego de saída (ou retorno) é roteado para a Internet por meio de um gateway NAT AWS gerenciado e de um gateway de internet provisionado na VPC de AWS App Runner propriedade ou no modo de rede padrão.

   Caminho de tráfego de saída, cenário 2 (o serviço web requer acesso às dependências downstream dentro de uma customer/private VPC):

   b. O tráfego de saída é encaminhado para a VPC customer/private de propriedade, onde as privadas resources/dependencies são provisionadas manualmente até o final. user/developer O tráfego é encaminhado para o endpoint de destino de acordo com a tabela de roteamento da VPC.

6. O tráfego para a Internet é roteado por meio de um gateway NAT gerenciado pelo cliente e de um gateway de internet provisionado no modo de rede VPC ou VPC customer/private Egress de propriedade.

7. AWS Identity and Access Management(AWS IAM), AWS Key Management Service (AWS KMS) e AWS Systems Manager Parameter Store garantem acesso baseado em funções e armazenam dados confidenciais com segurança. AWS Secrets Manager CloudWatchAmazonize e AWS X-Ray mantenha a observabilidade.