Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Différents comptes AWS peuvent-ils gérer différents sous-domaines ?

ayi

J’ai deux comptes AWS. Le compte principal avec <code>example.com</code> comme zone hébergée, qui possède ensuite un certain nombre d’enregistrements (par exemple <a href="http://api.example.com" rel="noopener nofollow ugc">api.example.com</a> et <a href="http://kibana.example.com" rel="noopener nofollow ugc">kibana.example.com</a>).
Un second compte va gérer <code>testing.example.com</code> comme zone hébergée, avec le même ensemble d’enregistrements (par exemple <a href="http://api.testing.example.com" rel="noopener nofollow ugc">api.testing.example.com</a> et <a href="http://kibana.testing.example.com" rel="noopener nofollow ugc">kibana.testing.example.com</a>).
Comment puis-je indiquer au compte principal de rediriger les requêtes pour <code>.testing.example.com</code> vers le compte enfant ? 
Je ne veux pas modifier le compte principal car je souhaite utiliser les mêmes templates Cloud Formation dans les environnements « Live » et « Test ».
J’ai configuré les deux comme décrit ci-dessus et cela ne fonctionne pas (<code>api.testing.example.com</code> ne se résout pas). J’ai aussi essayé de définir l’enregistrement NS de <a href="http://testing.example.com" rel="noopener nofollow ugc">testing.example.com</a> dans le compte principal vers celui spécifié dans le compte enfant(1). Hélas, c’est quelque chose que je n’avais jamais fait auparavant et les recherches Google ne retournent rien.
<ol>
<li>J’ai fait une erreur à ce niveau, et c’est en fait la réponse. Voir ci-dessous.</li>
</ol>

ayi_2

<blockquote></blockquote>
Comment puis-je indiquer au compte principal de rediriger les requêtes pour <code>.testing.example.com</code> vers le compte enfant ?
Les requêtes sont référées, pas poussées, mais vous pouvez obtenir le résultat souhaité en déléguant le sous-domaine à un ensemble différent de serveurs Route 53 par rapport à ceux qui hébergent la zone parente.
Examinez la nouvelle zone hébergée que vous avez créée pour <a href="http://testing.example.com">testing.example.com</a>. Elle peut être dans le même compte AWS, un compte AWS différent… n’importe quel compte AWS. Il n’y a rien ici qui soit lié au « compte ». Cela utilise une configuration DNS standard. L’ensemble du DNS est une hiérarchie. La racine globale peut vous indiquer où trouver <code>com</code>, et les serveurs <code>com</code> peuvent vous indiquer où trouver <code>example.com</code>, et il n’y a rien de fondamentalement différent pour que <code>example.com</code> vous indique où trouver <code>testing.example.com</code> au lieu de vous donner une réponse directe.
Notez les 4 serveurs de noms que Route 53 a attribués à la zone hébergée <a href="http://testing.example.com">testing.example.com</a>. Vérifiez qu’ils sont tous différents de ceux attribués à la zone hébergée <a href="http://example.com">example.com</a>. (Qu’ils soient identiques devrait être impossible, mais vérifiez-le quand même.)
Maintenant, de retour dans la zone <a href="http://example.com">example.com</a>, créez un nouvel enregistrement de ressource, avec le nom d’hôte <code>testing</code>, en utilisant le type d’enregistrement <code>NS</code>, et saisissez les 4 serveurs de noms que Route 53 a attribués à <code>testing.example.com</code>, dans le champ ci-dessous.
Désormais, lorsqu’une requête pour <a href="http://testing.example.com">testing.example.com</a> et tout ce qui se trouve en dessous arrive sur l’un des serveurs Route 53 gérant <a href="http://example.com">example.com</a>, la réponse ne sera pas la réponse de <a href="http://testing.example.com">testing.example.com</a> – la réponse fournira au demandeur les 4 enregistrements NS associés à <a href="http://testing.example.com">testing.example.com</a> et une réponse équivalente à « je ne sais pas, mais essayez de demander à l’un de ceux-ci ».
C’est comme cela que ça fonctionne.