¿Pueden diferentes cuentas de AWS administrar diferentes subdominios?

Tengo dos cuentas de AWS. La cuenta maestra con example.comuna Zona Hospedada, entonces tiene una serie de conjuntos de registros (es decir, api.example.com y kibana.example.com).

Una segunda cuenta se administrará testing.example.comcomo una Zona Hospedada, con el mismo conjunto de conjuntos de registros (es decir, api.testing.example.com y kibana.testing.example.com).

Cómo le digo a la cuenta maestra que remita las solicitudes .testing.example.coma la cuenta secundaria. No quiero cambiar la cuenta maestra, ya que quiero usar las mismas plantillas de formación en la nube en 'Live' y 'Test'.

He configurado los dos como se indica arriba y no funciona ( api.testing.example.comno se resuelve). También he intentado configurar el registro testing.example.com ns en la cuenta maestra en el especificado en la cuenta secundaria (1). Por desgracia, esto no es algo que haya hecho antes y las búsquedas de Google no devuelven nada.

1) Lo estropeé, y esta es la respuesta. Vea abajo.

Cómo le digo a la cuenta maestra que envíe las solicitudes .testing.example.coma la cuenta secundaria.

Las solicitudes se remiten, no se envían, pero puede lograr el resultado deseado delegando el subdominio a un conjunto diferente de servidores de la Ruta 53 de los que alojan la zona principal.

Mire la nueva zona alojada que creó para testing.example.com. Esto puede estar en la misma cuenta de AWS, una cuenta de AWS diferente ... cualquier cuenta de AWS. Aquí no hay nada relacionado con la "cuenta". Esto utiliza la configuración de DNS estándar. El conjunto de DNS es una jerarquía. La raíz global puede decirle dónde encontrar com, y los comservidores pueden decirle dónde encontrar example.com, y no es nada materialmente diferente example.comdecirle dónde encontrar en testing.example.comlugar de darle una respuesta directa.

Tenga en cuenta los 4 servidores de nombres que Route 53 asignó a la zona hospedada testing.example.com. Verifique que todos sean diferentes a los asignados a la zona alojada de example.com. (Para que cualquiera de ellos sea el mismo debería ser imposible, pero verifíquelo).

Ahora, de vuelta en la zona example.com, cree un nuevo registro de recursos, con nombre de host testing, usando el tipo de registro NS, e ingrese los 4 servidores de nombres que Route 53 asignó testing.example.com, en el cuadro a continuación.

Ahora, cuando una solicitud de testing.example.com y cualquier cosa debajo de ella llegue a uno de los servidores de Route 53 que manejan example.com, la respuesta no será la respuesta de testing.example.com: la respuesta le proporcionará al solicitante los 4 registros NS asociados con testing.example.com y una respuesta equivalente a "No sé, pero intente preguntarle a uno de estos tipos".

Asi es como se hace.

Creo que debe crear un testing.example.comregistro en la cuenta principal (principal) en el example.comdominio. Y si está utilizando ELB, copie el punto final ELB testingde la cuenta secundaria o se le puede asignar una IP pública para el testingdominio en su cuenta secundaria y actualícelo en la ruta 53 de la cuenta principal. Creo que el punto final ELB facilitaría la resolución de la dirección en lugar de usar IP elástica. También necesitaría crear todos los subdominios de testingla cuenta principal. Sugeriría usar puntos finales ELB en la cuenta secundaria para todos los subdominios del testingsitio. Asegúrese de que todos los puntos finales ELB deben tener un esquema como internet-facingen la consola aws.