Cuando hablamos de aplicaciones web alojadas en la nube tenemos múltiples opciones para exponer nuestras apps, lo mejor es usar un nombre de dominio memorable y de fácil escritura para que nuestros usuarios y consumidores puedan acceder a nuestra lógica sin problema alguno.
AWS Route 53 es el servicio de DNS de AWS, este nos ayuda a gestionar nuestros dominios, aqui podremos configurar diferentes tipos de registros A, CNAME, TXT, entre otros para que nuestros servicios sean visibles y accesibles.
A lo largo de este curso de Serverless Framework en AWS creamos diferentes funciones lambda que son accesibles mediante un dominio que API Gateway nos entrega, este dominio lo puedes encontrar en los detalles de cada Stage del tu API. Sin embargo estos APIs tienen una URL que no sigue una convención de nombres y ademas entrega algo de información sensible ante posibles usuarios mal intencionados, como dar detalles del Cloud Provider que usas y la región en la que alojas tus servicios, adicionalmente usar la URL de API Gateway directamente en tus consultas desde internet puede indicar que posiblemente no tienes una protección a nivel de CDN y Cache, estas ultimas las puedes lograr usando servicios como Cloudfront para disponer tus APIs en los Edge Location de AWS o incluso usando servicios de terceros como Cloudflare para proteger tus endpoints.
Vamos a configurar el Custom Domain Name para que resuelva los llamados HTTP a nuestro API mediante la URL slscourse.platzi.com.
A continuación vas a encontrar una guia detallada de como crear un Custom Domain Name y enlazarlo a un API Gateway para que tus endpoints tengan mejores practicas a nivel de seguridad y cache. En esta guia vamos a usar AWS API Gateway que es el servicio que nos permite exponer nuestra logica de negocio y Cloudflare como capa de CDN y DNS.
Paso 1: Creación del certificado en AWS ACM
Entramos a AWS Certificate Manager (ACM) y solicitamos un certificado, en mi caso es la opción de Request a Certificate
Posteriormente, nos preguntara por el tipo de certificado (Publico o Privado), en nuestro caso dado que no tenemos ningun Certificate Authority (CA) privado, seleccionamos la primera opcion
A continuación, podras completar la información asociada al nombre de dominio, el metodo de validación y el algoritmo de encripción. En este caso nuestro FQDN sera el asociado al curso de Serverless Framework en AWS (slscourse.platzi.com). El metodo de validación sera mediante DNS, el cual exige tener control sobre nuestro nombre de dominio, esto para poder crear registros que permitan validar que es un dominio de nuestra propiedad. Finalmente, en cuanto al algoritmo de encripción, AWS usa por defecto para ACM el algoritmo RSA 2048, te dejamos la documentación donde puedes encontrar mas información sobre las características de cada algoritmo y de los certificados ACM.
Nota: Al final de la pagina encontraras una sección de Tags, estos te van a permitir definir etiquetas que son de utilidad en diferentes aspectos, tales como inventario de recursos, costos asociados, entre otros. Como buena practica te recomendamos crear Tags que te permitan diferenciar los proyectos a los que se asociada cada recurso, recuerda que como buena practica entre mas segregados puedas tener tus recursos o puedas visualizarlos mejor, asi podras tener una vista global de tu infraestructura (Propietario o Owner, Proyecto o Vertical, Centro de costos, entre otros.)
Despues de presionar el boton de Request, podemos ver que AWS nos informa el estado del certificado y la información necesaria para poder crear los registros CNAME en nuestro gestor de DNS.
Paso 1.5: Validación del nombre de dominio con DNS
La validación podemos lograrla agregando un registro CNAME en nuestro gestor de DNS, al entrar al certificado que tiene Status Pendiente de validación(Pending Validation) vemos los siguientes detalles.
Debemos copiar el nombre y el valor del CNAME, y los registramos en el DNS (En nuestro caso sera Cloudflare).
Después de aproximadamente 5 o 10 minutos ya debe haberse replicado el registro CNAME en los multiples DNS y AWS ya mostrara nuestro certificado como Issued (Emitido).
Paso 2: Creación del Custom Domain Name en AWS
Después de tener nuestro certificado validado/issued ya puedes usarlo en la creación de un Custom Domain Name, para esto entramos a API Gateway, click en el submenu de Custom domain names, presionamos el boton Create.
Al presionar la opcion Create, podremos completar la información asociada a nuestro nombre de dominio y certificado (Creado previamente).
En esta vista notaras dos formas de configurar nuestro endpoint, uno de forma regional y otro optimizado en el borde (Edge Optimized). El primero sera un endpoint que AWS usara para apuntar a recursos especificos en una región, y el segundo sera accesible mediante una distribución de Cloudfront directamente desde los Edge Location de la infraestructura de AWS. Cada uno tiene diferentes ventajas y desventajas, pero deberíamos escoger el que mas convenga dependiendo del caso de uso. En nuestro ejemplo, seleccionaremos un endpoint de tipo Regional, el cual nos va a permitir a futuro agregar compatibilidad multi-region a nuestra aplicación, y generar políticas de enrutamiento basado en latencia.
Después de presionar el botón Create domain name podremos ver el dominio personalizado creado y asociado a nuestro certificado. De esta vista es importante resaltar el valor de API Gateway domain name, el que inicia con “d-….”
Después de tener configurado nuestro Custom Domain, debemos hacer un mappeo de nuestro dominio a nuestro API Gateway, esto lo logramos mediante la sección de API Mappings.
Aqui debemos presionar la opcion Configure API mappings, y posteriormente podremos seleccionar nuestro API, el Stage, y de forma opcional
Paso 4: Configurar nuestro nombre de Dominio
Hasta este momento ya hemos creado nuestro certificado, hemos creado un nombre de dominio personalizado (Custom Domain Name), sin embargo este dominio sigue sin ser disponible desde internet. Esto por que ningún servidor de DNS del mundo sabe a donde debe dirigir cada peticion cuando entremos a slscourse.platzi.com. Recuerda que la configuracion que hicimos fue solo para validar el certificado, sin embargo no hemos configurado ningún registro DNS para enviar trafico a nuestro Custom Domain Name.
Para esto debemos crear un registro CNAME en nuestro DNS apuntando slscourse a la ruta del API Gateway domain name, es el valor que inicia con “d-”
**Registro CNAME**
**Name**: slscourse
**Value**: [d-by0ua7r9w4.execute-api.us-east-1.amazonaws.com](http://d-by0ua7r9w4.execute-api.us-east-1.amazonaws.com/)**TTL**: Auto
***Proxy status**: Esta propiedad solo aplica si usas Cloudflare*
Nota: La propiedad Proxy status: Proxied nos permite definir que Cloudflare aplicara todas las capas de seguridad y cache a cualquier usuario que intente acceder a nuestro target mediante slscourse.platzi.com
Paso 5: Enlazar API Gateway
Esto lo vamos a ver con mas detalle en la siguiente clase, en la cual vamos a aprender como usar Custom Domain Names para nuestro proyecto.
El paso de enlazar es relativamente corto y sencillo, despues de tener nuestro dominio configurado y el custom domain name creado, debemos hacer un mapeo para enlazar nuestro API Gateway a una ruta de nuestra preferencia. Esto lo logramos mediante la opción Configure API mappings, y luego Add new mapping (agregar un nuevo mapping) y save (Guardar)
Con esta configuración todos los llamados que hagamos a slscourse.platzi.com/api/users/ seran atentidos mediante nuestro API Gateway y todas las lambdas desarrolladas hasta este momento serán accesibles mediante ese nombre de dominio.
En la siguiente clase veras una explicación mas a detalle de como lograr esta configuración, tambien realizaremos pruebas con Postman, validando que los API Keys sigan siendo validos mediante el Custom Domain Name.
En esta clase de lectura hemos configurado este dominio personalizado para que nuestros recursos sean accedidos mediante el path: /api/, en la próxima clase configuraremos este nombre de dominio mediante un plugin de Serverless Framework, también usaremos un mapeo totalmente diferente para que notes la flexibilidad de estos nombres de dominio y los mappings.
