Multi-comptes Services

Bonjour,

Je pense qu’il est plus simple de centraliser la gestion des domaines dans un seul compte AWS.
Le coût du domaine lui-même ne change pas en fonction du compte, donc il ne sera ni plus cher ni moins cher selon le compte AWS utilisé.

Avec un équilibreur de charge AWS, il est possible d’ajouter un enregistrement alias même si la zone hébergée Route 53 se trouve dans un autre compte.
Par conséquent, il est possible de configurer le domaine sans déléguer les sous-domaines.
https://www.reddit.com/r/aws/comments/vp7ohc/how_to_add_load_balancer_from_different_aws/
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias-common.html

If you used different accounts to create your Route 53 hosted zone and your load balancer – Enter the value that you got in the procedure Getting the DNS name for an Elastic Load Balancing load balancer.
If you used one AWS account to create the current hosted zone and a different account to create a load balancer, the load balancer will not appear in the Endpoints list.
If you used one account to create the current hosted zone and one or more different accounts to create all of your load balancers, the Endpoints list shows No targets available under Elastic Load Balancers.

De plus, pour les certificats SSL avec ACM, il est nécessaire de les créer pour chaque compte AWS.
Lors de l’émission d’un certificat avec ACM, un enregistrement CNAME de validation est généré. En ajoutant cet enregistrement dans la zone hébergée Route 53, le certificat pourra être utilisé.
https://docs.aws.amazon.com/acm/latest/userguide/setup.html

Pour votre architecture multi-comptes avec Route 53, voici comment cela fonctionnerait :

Partage de Route 53 entre comptes : Vous pouvez centraliser Route 53 dans votre compte "shared" et permettre aux autres comptes (recette, prod) d'y accéder de plusieurs façons :

1. Pour les zones hébergées privées : Vous pouvez associer les VPC de vos comptes recette et prod à la zone hébergée privée du compte shared. Cela permet aux ressources dans ces VPC de résoudre les enregistrements DNS.

2. Pour les règles Resolver : Utilisez AWS Resource Access Manager (RAM) pour partager les règles Resolver entre comptes. Vous créeriez un partage de ressources dans le compte central qui permet aux comptes membres d'utiliser ces règles.

3. Route 53 Profiles : C'est une option pour partager des ressources Route 53 entre comptes de manière centralisée.

Concernant les Load Balancers et Certificate Manager : Les Load Balancers et les certificats restent dans leurs comptes respectifs (recette, prod). Le renouvellement automatique des certificats ACM fonctionne normalement dans chaque compte. Pour associer un DNS du compte shared à un Load Balancer dans un autre compte, vous créez simplement un enregistrement DNS dans la zone hébergée du compte shared qui pointe vers le Load Balancer de l'autre compte.

Architecture de domaines et sous-domaines : Oui, votre approche est correcte. Vous pouvez avoir un domaine principal dans le compte shared (par exemple, votreentreprise.com) et déléguer des sous-domaines à d'autres comptes ou zones hébergées (par exemple, recette.votreentreprise.com, prod.votreentreprise.com). Cela se fait en créant des enregistrements NS (Name Server) dans la zone parent qui pointent vers les serveurs de noms de la zone déléguée.
Sources
Configure cross-account access for Route 53 resources | AWS re:Post
Amazon Route 53 endpoints and quotas - AWS General Reference

Est-ce que c'est la bonne approche à faire? Ou bien il faut que chaque compte gère son DNS ? Car c'est une histoire de coût également

Bonjour,

Merci de votre réponse, je commence à comprendre. Quel serait la meilleur approche selon vous? Je devrais être tous le temps sollicité s'il faut créer des alias DNS sur route53 même si nous allons terraformer la partie Le compte shared appartiendra à la team Devops, alors qu'on pourrait déléguer un peu le travail en laissant les gens crée les alias sur les comptes ?