Hébergement Web sans serveur sur AWS App Runner

1. Scénario 1 utilisant un code source :

   a. Validez le code dans le référentiel GitHub source.

   b. Autorisez l'accès au code source en cours GitHub d'utilisation AWS CodeStar.

   c. Fournissez des instructions pour créer et exécuter le service Web et spécifiez un environnement d'exécution géré pris en charge par AWS App Runner. AWS CodeBuildpuis empaquette automatiquement le code et ses dépendances et crée une nouvelle image de conteneur.

   d. L'image du conteneur est ensuite envoyée et stockée dans un référentiel Amazon Elastic Container Registry (Amazon ECR), hébergé dans le compte AWS App Runner détenu.

2. Scénario 2 utilisant une image source :

   a. Vous pouvez également commencer par une image prédéfinie stockée dans un référentiel Amazon ECR géré par le client, hébergé sur le compte du client.

   b. En autorisant l'accès à l'image du conteneur à l'aide d'un AWS IAM Identity Center rôle, l'image est ensuite transmise et stockée dans le référentiel Amazon AWS App Runner ECR géré.

   Création du service App Runner :

3. L'image du conteneur stockée dans Amazon ECR est ensuite extraite pour être déployée en tant que AWS Fargate tâches sans serveur dans le AWS App Runner cloud privé virtuel Amazon, également connu sous AWS App Runner le nom de Service VPC. Les AWS Fargate tâches sont déployées sur un AWS Fargate cluster s'étendant sur plusieurs zones de disponibilité pour une haute disponibilité dans les sous-réseaux privés, et configurées avec AWS Application Auto Scaling.

4. Une URL de service sécurisée apparaît created/published après un déploiement réussi. L'URL du service sécurisé correspond à un équilibreur de charge AWS réseau accessible au public et un nom de domaine par défaut lui est attribué par. AWS App Runner Les clients peuvent également associate/map utiliser un nom de domaine personnalisé qu'ils possèdent, mais celui-ci doit pouvoir être résolu publiquement et peut être enregistré auprès de la zone hébergée publique d'Amazon Route 53 ou auprès de n'importe quel fournisseur DNS.

Trajectoire du trafic entrant :

1. Le client lance une demande vers l'URL du service.

2. L'URL du service est convertie en un équilibreur de charge réseau accessible au public à l'aide d'Amazon Route 53. Le AWS NLB est automatiquement provisionné et détenu par le AWS App Runner service.

3. La demande entre dans le VPC dont il est AWS App Runner propriétaire via le AWS Network Load Balancer (AWS NLB) et est redirigée vers un routeur de requêtes L7.

4. Le routeur de requêtes L7 achemine les demandes entrantes vers une instance de service Web ou une AWS Fargate tâche particulière.

   Chemin du trafic sortant, scénario 1 (le service Web ne nécessite pas l'accès aux dépendances en aval au sein d'un customer/private VPC) :

5. a. Le trafic sortant (ou de retour) est acheminé vers Internet via une passerelle NAT AWS gérée et une passerelle Internet provisionnée dans le VPC dont vous êtes AWS App Runner propriétaire, ou via le mode réseau par défaut.

   Chemin du trafic sortant, scénario 2 (le service Web nécessite l'accès à des dépendances en aval au sein d'un customer/private VPC) :

   b. Le trafic sortant est transféré vers le VPC customer/private appartenant à l'utilisateur, où les données privées resources/dependencies sont provisionnées manuellement avant la fin. user/developer Le trafic est transféré vers le point de terminaison de destination conformément à la table de routage VPC.

6. Le trafic vers Internet est acheminé via une passerelle NAT gérée par le client et une passerelle Internet provisionnée dans le mode réseau VPC customer/private détenu ou VPC Egress.

7. Gestion des identités et des accès AWS(AWS IAM), AWS Key Management Service (AWS KMS) et AWS Systems Manager Parameter Store garantissent un accès basé sur les rôles et stockent en toute sécurité les données confidentielles. AWS Secrets Manager Amazon CloudWatch et AWS X-Ray maintenez l'observabilité.