En pleno año 2021, con el journey-to-cloud echando humo en todo tipo de empresas del mundo entero, es más que habitual encontrarse con organizaciones que abogan por realizar una separación de cuentas entre entornos, proyectos o incluso aplicativos. Al fin y al cabo, esto garantiza un aislamiento total de todos los recursos, incluyendo los equipos encargados de gobernarlos.
Ahora bien, esto también presenta grandes retos operacionales, entre los que se encuentra la gestión de aquellos servicios que deban ser compartidos entre todas las cuentas. Si bien este es un tema que merece un escrito propio, el presente artículo tiene un ámbito mas reducido y se focaliza en como centralizar la administración de DNS vía AWS Route53 en un entorno con múltiples cuentas.
Caso de uso
Se dispone de una organización compuesta por 4 cuentas de AWS: Una para cada uno de los entornos en los que se alojan los aplicativos de negocio que ofrece la compañía y una última para aquellos servicios de la nube que deben ser compartidos entre todas ellas. Así, se desea adquirir un único dominio wildcard “*.company.com”, a través de Route53, que pueda ser utilizado a lo largo de todas las cuentas de la organización.
Route53
Tal y como reza la documentación oficial de AWS, Route 53 es un servicio de DNS web escalable y de alta disponibilidad en la nube, que conecta de forma efectiva las solicitudes del usuario con la infraestructura en ejecución en AWS, como instancias EC2, balanceadores de carga o buckets S3, entre otros, si bien también puede utilizarse para redirigir a los usuarios a infraestructuras externas. En este caso, no hay mucho aclarar.
Sus principales virtudes son la facilidad de uso, su reducido coste (0,50 USD por zona alojada al mes para las primeras 25 zonas alojadas y 0,10 USD para las siguientes + 0,40 USD por el primer millardo de consultas mensual y 0,20 USD para las siguientes) y como no podía ser de otra forma, su integración con los servicios propios de la nube.
Si bien no es el tema que atañe al presente artículo, merece la pena destacar lo fácil y bien que se compenetra con el AWS Certificate Manager, servicio que permite aprovisionar, administrar e implementar con facilidad certificados de transporte (SSL/TLS) tanto públicos como privados, de forma totalmente gratuita.
Route53 Configuration
Dejando de lado una propaganda no planificada, y una vez descrito que es Route53, es hora de abordar el tema que atañe al escrito, es decir, cómo configurar dicho servicio para funcionar en una organización multi cuenta.
Así, la solución pasa por registrar el dominio raid “*.company.com” en la cuenta shared services y delegar la resolución parcial de los subdominios a las zonas de Route53 ubicadas en el resto de las cuentas de AWS, de tal forma que cada una de ellas sea responsable de gestionar el DNS de sus aplicativos.
Es decir, todas las solicitudes de resolución de nombres las recibe inicialmente la zona del Route53 de la cuenta shared services y posteriormente las redirige a la cuenta de AWS correspondiente, en este caso, en función del entorno. De esta forma, cada cuenta es responsable de gestionar la resolución de los dominios dentro su ámbito, lo que a fin de cuentas simplifica su gobierno.
Pero… ¿Que es una zona de Route53? De nuevo, tal y como señala la documentación oficial de AWS, una zona no es mas que una agrupación de registros, en la que cada uno de ellos contiene información sobre cómo redireccionar el tráfico hacia un dominio específico. Así, existen dos tipos de registros:
- Públicos: contienen registros que especifican cómo desea redireccionar el tráfico en Internet.
- Privados: contienen registros que especifican cómo desea redireccionar el tráfico en una VPC de Amazon.
¡Llego la hora de ponerlo en practica!
El primer paso consiste en registrar el dominio wildcard, lo cual es posible realizar a través de la web de AWS en Services → Route53 → Registered Domains → Register Domain. En este punto, se pedirá introducir el nombre dominio solicitado, así como una serie de datos personales de contacto.
Una vez adquirido, el dominio debería aparecer en la sección de Registered Domains.
Al hacer click sobre el nombre de dominio, se mostrará toda la información referida al mismo, y lo mas importante, un conjunto de name servers, que no son mas que las direcciones encargadas de resolver las peticiones sobre el dominio adquirido. Los name servers deberían ser direcciones similares a estas:
- ns-8726.awsdns-64.co.uk
- ns-24.awsdns-91.com
- ns-8601.awsdns-25.org
- ns-718.awsdns-99.net
Con los name servers en mano, es hora de crear una hosted zone pública en la cuenta de shared services, lo cual es posible realizar a través de la web de AWS en Services → Route53 → Hosted Zones → Create hosted zone. En este punto, se nos pedirá introducir el nombre dominio base, así como una breve descripción opcional.
Una vez creado, debería aparecer en la sección de hosted zones. Al hacer click sobre el nombre de dominio, se mostrarán los records asociados, teniendo que sustituir los name servers del record de type NS, por los obtenidos previamente en la compra del dominio.
El siguiente paso consiste en crear una hosted zone pública asociada al entorno, en cada una de las cuentas que albergan los aplicativos de negocio, de la misma manera que antes. Es decir, a través de la web de AWS en Services → Route53 → Hosted Zones → Create hosted zone. En este punto, se nos pedirá introducir el nombre dominio base junto a un prefijo que indetifíque el entorno, así como una breve descripción opcional.
Una vez creado, debería aparecer en la sección de hosted zones. Al hacer click sobre el nombre de dominio, se mostrarán los records asociados, pero en esta ocasión no habrá que sustituir los name servers del record de type NS, simplemente guardarlos para utilizarlos a continuación.
Finalmente, solo queda crear un nuevo record por entorno en la cuenta de shared services, dentro de la hosted zone pública creada previamente, lo cual es posible realizar a través de la web de AWS en Services → Route53 → Hosted Zones → company.com -> Create record. En este punto, es necesario introducir el nombre del record o subdominio, configurar el tipo de record como NS e introducir el listado de name servers obtenidos en el paso anterior en el campo value.
De esta forma, las cuentan que albergan los aplicativos de negocio pasan a estar enlazadas con la shared services y son independientes tanto para crear records propios dentro de su public hosted zone <environment>.company.com, como para resolver las solicitudes de los usuarios.
Conclusiones
En conclusión, la administración de DNS vía AWS Route53 en un entorno con múltiples cuentas es mas simple de lo que a priori podría parecer. Basta con registrar el dominio raid en la cuenta shared services y delegar la resolución parcial de los subdominios a las zonas de Route53 ubicadas en el resto de las cuentas de AWS.
Un último apunte antes de acabar: Aunque en el presente articulo, por simpleza, se haya realizado el proceso a través de la web de Amazon, la recomendación es llevarlo a cabo mediante IaC, de tal forma que sea fácilmente gestionable y por supuesto, reutilizable.
Referencias
Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:
- https://aws.amazon.com/blogs/security/how-to-centralize-dns-management-in-a-multi-account-environment/
- https://aws.amazon.com/blogs/security/simplify-dns-management-in-a-multiaccount-environment-with-route-53-resolver/
- https://medium.com/@gavinlewis/managing-route-53-in-a-multi-account-environment-5d95a3cb67c5
Mikel's TechBlog 