Architecture Championship: AWS Essentials: Un Recorrido Profundo por los Core Services

Architecture Championship es AWS Essentials, un recorrido profundo por los Core Service. Muy bien, entonces si pasamos a la siguiente diapositiva por favor. ¿Y el día de hoy nos está acompañando el ingeniero Mario Palato, líder de parte del equipo de preventa, consultor de soluciones de aquí de CompuCloud y también la ingeniera Cecilia Rodríguez que forma parte del equipo de implementaciones del equipo compañero Y quién es CompuCloud? Tal vez algunos de ustedes ya nos conocen, entonces les platico rápidamente. Nosotros formamos parte de lo que es los partners de AWS. Tenemos un nivel que es Partner Advance, Existen diferentes niveles en AWS en cuanto a lo que son los partners existentes y el Advanced justamente es uno de los más importantes en cuanto a niveles de partners. Nosotros estamos en México principalmente, pero también trabajamos con empresas de Centroamérica y recientemente algunas empresas del extranjero. Tenemos desde el 2012 100 especialistas en diseño y modernización de arquitecturas de AWS. Solo trabajamos con la nube de AWS y es por eso que tenemos diferentes certificaciones desde competencias, SDPS, estas certificaciones individuales que tiene cada uno de los ingenieros, esto para que se especialicen en ciertos temas. Entonces esto nos ayuda tanto a mejorar nosotros como equipo en conocimiento de AWS como para ayudar a nuestros clientes actuales a modernizarse a través de la nube. En el tema que hoy estaremos platicando, entraremos primero a lo que son los Core Service. Los Core Service son básicamente cuando una empresa quiere iniciar con la nube de AWS, por lo general empieza con estos servicios para que empiecen a conocer cómo funcionaría una infraestructura on premise en la nube. Entonces aquí el equipo de ingenieros nos va a estar explicando cuáles son los Core Service, qué es lo que sustituye ese Core Service, por ejemplo en un espacio on premise y lo trabajaremos a través de lo que es un caso. Aquí el equipo nos va a presentar un caso X de una empresa que se acerca hacia nosotros, nos pide la ayuda de lo que está buscando y y cómo es que la consultoría que realizamos primeramente con ellos les ayuda a ver este mundo de Core Service y que prueben lo que es la nube. Entonces al final les voy a platicar un poquito más, pero esta sesión es para mostrarles a ustedes cómo nosotros realizamos pocs que se llaman pruebas de concepto, que estas cuando ustedes inician un un proyecto en la nube de AWS, pero no están seguros, quieren saber cómo funciona antes de invertir en lo que sería tal vez un cambio o un nuevo proyecto en su infraestructura DTI, pues hacemos una POC. Nosotros como CompuCloud, al ser un partner de AWS, tenemos estos beneficios de realizar pruebas en la nube, en donde ustedes tienen acceso a estas pruebas para que vean cómo se vería su proyecto montado en la nube, cómo funcionaría, cuál sería el costo, porque como saben en la nube pagas por lo que usas. Entonces estas box le sirven a aquellas empresas que quieren saber cómo funciona la nube a hacer una prueba sin costo, sin costo, sin compromisos de compra, solo para que sepan cómo funciona y ya más adelante tomen la decisión si lo quieren utilizar de esa manera o incluso hacer otro escenario parecido al que se presentó. Y pues bueno, ya para pasar ahora sí a la parte práctica, los dejo igual con mi compañera Cecilia Rodríguez, quien nos estará platicando un poco más sobre el caso que veremos hoy. Adelante Ceci.

Hola, qué tal, buen día. Pues bueno, mi nombre es Cecilia Rodríguez, tal cual pertenezco al departamento de implementaciones, como bien lo mencionaba mi compañera Gio. Y pues bueno, para comenzar lo que es el Architecture Championship, voy a estarles dando lo que es el contexto del caso. En este contexto o en este caso, nosotros prácticamente nos presentamos con una compañía que tiene el nombre de smartdob. Esta compañía tal cual nos comenta que tiene un proyecto el cual quiere migrar a la infraestructura de AWS, tal cual migrar su infraestructura a AWS, esto pues para aprovechar tanto los beneficios que ofrece esta nube, como también las buenas prácticas de seguridad. Nos mencionan dentro de esta comunicación que tenemos con el cliente, que sus desarrolladores tienen experiencia manejando sistemas operativos Linux y también nos mencionan que este proyecto en específico que quieren migrar, tal cual utiliza tecnologías como lo que es PHP, MySQL, GitHub y Apache. Entonces este es principalmente el concepto. En base a esta sesión que tenemos con el cliente, nosotros descatamos los siguientes requerimientos. El primero, tal cual igual, el primero es en base a lo que es la base de datos. Se nos solicita una solución para una base de datos que sea totalmente administrada por AWS, tal cual la empresa, la compañía no quiere dedicarse a actividades manuales como la parte de generación de parches, generación de respaldos, la instalación de software, prácticamente quiere dejar todo a mano de AWS y enfocarse en lo que es su negocio y sus clientes. Igual si puedes poner el siguiente requerimiento. El siguiente requerimiento pues tal cual quiere un servidor web el cual esté conectado con la base de datos previamente mencionada y pues que tal cual tenga la conexión para que todo funcione de manera correcta. El siguiente requerimiento se busca que tal cual ambos servidores, el servidor de base de datos, más que nada el servidor web, crezca en base a la demanda o disminuya en base a esta misma. Como siguiente requerimiento se pide que tanto la base de datos como el servidor web tengan la información encriptada en reposo y a la hora de hacer solicitudes hacia la aplicación se utilice lo que es la encriptación en tránsito y para eso pues se utilizaría un certificado SCL o TLS. Y como último requerimiento tal cual de este ejemplo vendría siendo la parte de que actualmente ellos ya tienen una consola de administración de AWS en la cual tienen un dominio y tal cual un subdominio y quisieran que éste diera respuesta a lo que es el aplicativo. Y pues básicamente esto sería lo que rescatamos de esa comunicación con el cliente. A continuación mi compañero Mario Palato les estaría compartiendo cómo en base a estos requerimientos se crea un diagrama de.

Muy bien, muchas gracias Ceci por la introducción. ¿Qué tal? Sean bienvenidos todos a este nuevo Architecture Championship. Vamos a explicar un poquito cómo estamos planeando esta infraestructura en este diagrama de infraestructura en la nube de AWS en base a los requerimientos que hemos escuchado anteriormente. Muy bien, vamos a comenzar de izquierda a derecha, es un diagrama bastante sencillo utilizando como énfasis los servicio score que nos ofrece AWS. Tal cual vamos a hacer uso del servicio de Ruta 53. Este servicio nos ofrece una administración de dominios para crear en base a los requerimientos diferentes zonas hosteadas o récords como se le conoce, que apunten a ciertas a ciertas aplicaciones web. En este caso vamos a necesitar también de un certificado SCL como mencionábamos anteriormente, este certificado lo podemos expedir de forma gratuita con el servicio del Application Ad Balancer en AWS y pues tal cual lo vamos a estar utilizándolo para encriptar la información en tránsito. Vamos a hacer también uso de un servicio que se conoce como Application Ad Balancer. Este servicio nos ayuda como su nombre lo dice a balancear el tráfico que recibe nuestro proyecto web. En este caso este este servicio también nos ayuda a mantener nuestro ambiente privado. Si hacemos énfasis en el sistema o en el ambiente de red que estamos utilizando, vemos que tenemos subredes públicas y privadas, en este caso lo que recomendamos siguiendo las mejores prácticas que nos dicta AWS es mantener siempre nuestros servidores privados y exponerlo a través de un balanceador de cargas. El balanceador de cargas nos entrega un DNS tal cual con el cual podemos consultar nuestro aplicativo, entonces este servicio pues tendría esas dos funciones, mantener nuestro ambiente privado y otorgarnos un DNS para que el mismo servicio balancee las cargas en caso de que llegamos a en caso de que el tráfico sea muy alto y lleguemos a requerir más de un servidor. También pues vamos a utilizar el servicio conocido como Autoescaling que es un servicio de autoescalamiento como les mencionaba anteriormente que hace muy bien match con el servicio de application la Balance, ya que este servicio se encarga de incrementar o decrementar el número de instancias dependiendo de nuestra distribución o requerimiento de tráfico que tengamos en la aplicación. También vamos a utilizar el servicio de KMS, este servicio que está brillando aquí de color rojo es un servicio de seguridad que nos sirve para encriptar nuestros volúmenes en reposo, es decir, sabemos que nuestros servidores van a tener un disco por detrás donde contiene toda nuestra información y con ayuda de este servicio de KMS vamos a estar encriptando esta información. También vamos a utilizar un servicio que se conoce como Aurora, Aurora es un motor de base de datos desarrollado por AWS, este servicio es compatible para motores como lo es MySQL y Postgres SQL, pero AWS lo que hizo fue mejorarlo, este motor alcanza a ser hasta cinco veces más rápido que un motor tradicional de MySQL y tres veces más RÁPIDO que un motor tradicional de PostgreSQL, entonces es por eso que AWS pues no lo recomienda utilizar en este caso que nuestro esquema está hecho en MySQL también adicionalmente y servicios que ya van más como complementarios estamos utilizando los Security Groups, son estos cuadrados de color rojo que actúan como una especie de firewall para permitir ciertos orígenes hacia diferentes puertos, es decir, pongamos un ejemplo, en el Security Group de nuestro aplication ad balancer solamente queremos permitir el tráfico en el puerto 443 o en el puerto 80, no ocupamos que ningún otro puerto esté abierto para el balanceador de cargas. Igual siguiendo esta misma idea para el servidor del aplicativo solamente necesitamos que esté abierto el puerto 80 porque el aplicativo se va a estar ejecutando en el servidor de Apache y solamente requiere de este puerto por cuestiones de seguridad y por cuestiones para, ahora sí que para evitar ataques no vamos a abrir otro puerto porque no es necesario que ingrese tráfico, ¿Sale? Igualmente para la base de datos, pues solamente vamos a necesitar que esté abierto el puerto 3306 que es el puerto de MySQL y un firewall virtuales que se conocen como Security Group, vamos a poder realizar esa configuración. Siguiendo también el concepto de alta disponibilidad de AWS, imaginemos que cae una zona de disponibilidad, pues seguimos manteniéndonos arriba ya que nuestros, Nuestros. Nuestros servicios están siendo replicados a través de diferentes zonas de disponibilidad. También hacemos uso del servicio de NAT Gateway, que es un traductor de direcciones de red, tal cual nosotros nuestros servidores que van a estar privados sabemos que no van a tener acceso y desde Internet, entonces, como si nosotros llegamos a requerir que nuestro servidor del aplicativo descargue algún paquete de software, sabemos que no tiene acceso hacia Internet directamente con ayuda del NAT Gateway nosotros le podemos otorgar acceso a Internet hacia estos servidores que están en un ambiente privado. Igual ahorita en la demostración pues lo vamos a ver más a detalle y vamos a ver cómo poco a poco vamos llegando a esta solución que hemos arquitectado como tal. A continuación va a hablar mi compañera Ceci sobre algunos requerimientos que necesitamos para levantar la base de datos. Adelante.

Gracias Mario. Este sí, como siguiente paso igual nosotros vamos a mencionar los requerimientos, digámoslo así, previos para la creación de nuestro servidor de base de datos. Y pues para comenzar en cuanto a información es muy importante tener en cuenta qué motor de base de datos se va a utilizar y su versión, esto más que nada para verificar que la versión esté disponible en lo que vendría siendo la nube de AWS. Enseguida también para contar ya con la creación de nuestro servidor, ocupamos tener el entorno de red. Para esta práctica nosotros ya tenemos tal cual creado nuestro entorno de red, igual lo vamos a estar explicando en el procedimiento cómo se está implementando esto. Y la parte de una KMS para la encriptación en reposo, que bien ya lo comentó mi compañero Mario, es el servicio que nos permite la encriptación y el grupo de seguridad tal cual el cual pues como mencionó mi compañero, nos va a permitir abrir el puerto MySQL hacia lo que es el servidor web. Y pues bueno, otro de los recursos que se requieren previamente antes de la creación del servidor de base de datos es el Subnet Group, que este básicamente lo que hace o su función es definir en qué subnedes, grupo de subnedes, pueden ser dos, pueden ser tres, en qué grupo de subnedes nosotros vamos a estar colocando nuestro servidor de base de datos, es tal cual como su nombre lo dice, un grupo de subnedes, el Parameter Groups, que aquí básicamente nos muestran las configuraciones tal cual que va a traer nuestro motor, nuestro servidor de base de datos. Más adelante, ahorita en la práctica les voy a mostrar bien cuáles opciones son las que les menciono, igual por ejemplo el Timezone o configuraciones de ese estilo y pues también el Option Groups, que este AWS ya tiene por defecto algunos creados, nosotros simplemente por cuestiones de buena práctica vamos a crearlos. Bueno ya los tenemos creados, igual los vamos a mostrar en la parte de la creación, en la parte del handson. Y pues estos serían los requerimientos para nuestro servidor de base de datos. A continuación le cedo la palabra a mi compañero.

Muchas gracias Ceci. Muy bien, así como vimos algunos requerimientos para la RDS, vamos a ver algunos que necesitamos para levantar nuestras instancias EC o nuestros servidores que van a estar actuando como el host de nuestro proyecto que está desarrollado en PHP, pues tal cual es información muy básica que nosotros necesitamos, como la versión de sistema operativo, qué distribución de Linux vamos a utilizar en este caso el tipo de instancia, es decir, qué cantidad de CPU y de memoria RAM nosotros ocupamos para que nuestro servidor esté en un óptimo performance y no vaya a tener fallos en ese sentido, también ocupamos saber pues qué cantidad de almacenamiento vamos a requerir. En otra información que requerimos ya un poco más personalizada en estos ambientes de AWS son el entorno de red, una keypay que actúa como una contraseña para podernos conectar a nuestro servidor web a través del protocolo SSH, también ocupamos la clave KMS que va a ser la clave que va a estar encriptando nuestros volúmenes como mencionábamos anteriormente y el firewall virtual del que ya hemos hablado un poco. Vamos nosotros a crear una plantilla de lanzamiento, nosotros requerimos de todos estos conceptos o de toda esta información previa para poder crear una plantilla de lanzamiento y así decirle al auto scaling group que es el que vamos a estar utilizando, que queremos que todas nuestras instancias ya sea para incrementar o para decrementar las lance con estos parámetros como tal, ¿Sí? Entonces a continuación pues vamos a comenzar con la demo, va a compartir primero mi compañera Cecilia y pues cualquier duda que tengan y en cualquier momento nos pueden compartir por el chat. Sí, adelante Ceci.

Muchas gracias. Permítanme compartir mi pantalla, igual me confirman cuando ya la vean.

Listo, ya se ve.

OK, perfecto. Bueno, pues prácticamente ahorita ya estoy dentro de lo que es la consola de administración de AWS. Para comenzar con la demo, lo primero que vamos a hacer es irnos al servicio de KMS, que es la parte de crear la clave de encriptación tal cual para el servicio. En este caso yo voy a estarles presentando la parte de la creación del servidor de base de datos, tanto de su KMS como de su grupo de seguridad. Y pues bueno, lo primero que voy a crear va a ser la KMS, igual aquí pueden buscar la barra de búsqueda, yo aquí ya los tengo tal cual filtrados como favoritos. Y bien, ahorita me encuentro tal cual en el servicio de KMS, aquí podemos crear tanto, bueno KMS, podemos utilizar tanto KMS personalizadas y administradas por nosotros o podemos utilizar KMS que ya están de hecho creadas y administradas por AWS. En este caso pues nosotros vamos a crear una y para más que nada nosotros administrarla, entonces en el menú lateral izquierdo vamos a seleccionar en Custom Manage Case y en Create Key, aquí las primeras configuraciones que se nos solicitan tal cual es la parte de qué tipo de clave vamos a crear, una simétrica o una simétrica para cuestiones prácticas, nosotros vamos a dejar la simétrica está básicamente para que sea la misma tanto para desencriptar y encriptar. Entonces dejaríamos estas dos configuraciones tal cuales, aquí vienen opciones avanzadas, como si nosotros queremos que nuestra KMS se distribuye o se permite el uso tanto en otras regiones tal cual de la región de este de la consola, por ejemplo aquí nosotros nos encontramos en Ohio, prácticamente nuestra infraestructura va a estar en Ohio, lo que vamos a crear, pero si nosotros quisiéramos darle permisos a otros recursos de nuestra KMS que se encuentran en otra región aquí nosotros tendríamos que definirlo igual en esta parte de aquí son otras configuraciones relacionadas a la parte de HCM que también es referente a la creación tal cual de claves administradas por nosotros mismos, nada más, eso pues es costo más que nada, aumento de costo, entonces por este caso vamos a dejarlas así y enseguida pues vamos a colocar un alias de nuestra KMS, en este caso nosotros vamos a poner KMS y r y pues aquí podemos colocar una descripción de nuestra KMS y enseguida la parte de tax, esto nosotros lo recomendamos, pero básicamente es para nosotros identificar o juntar grupos de recursos e incluso para la parte de costos, poder verificar cuánto se gasta al mes o incluso en días de determinados costos de determinados recursos que tengan un ataque en específico. Nosotros vamos a crear tal cual la de la de fecha de creación y entonces como siguiente configuración a agregar es la parte de quiénes van a ser administradores de esta KMS, quiénes van a tener permisos administrativos sobre esta KMS, por ejemplo la eliminación de esta KMS, nosotros ahorita por defecto vamos a colocar nuestros usuarios, el mío, el de Mario y uno que tenemos con el que también interactuamos ambos. ¿Y bueno enseguida ahora qué usuarios van a tener permisos de esta KMS, de utilizar esta KMS, es decir desencriptar y encriptar? Bien, voy a poner el mío, el de Mario, el coordinador, pero aquí algo muy importante, si queremos que nuestro servidor web tenga permisos sobre nuestro servidor de base de datos, es necesario aquí colocar el rol que va a tener nuestro servidor web, previamente nosotros ya lo hemos creado, este se llama rol s scm demo ac y bueno básicamente ¿Por qué lo agregamos aquí? Porque si nosotros no lo agregáramos en el momento en el que nosotros quisiéramos capturar información de nuestra base de datos desde nuestro servidor web, tendríamos que obtenerla y tener permiso sobre la desencriptación tal cual, entonces por eso lo agregamos aquí. Aquí otra opción adicional es si nosotros trabajamos con cuentas, con varias cuentas tal cual en la nube de AWS y queremos que se tenga permiso sobre esta KMS en otras cuentas, por el momento lo vamos a dejar así y ahora se nos muestra un resumen básicamente de lo que hemos creado nosotros, nomás le damos en Finish. ¿Bien, ya está creada tal cual nuestra KMS, Lo siguiente es crear el grupo de seguridad y para ello nos vamos a ir al servicio de EC y en el apartado de Security Group o grupos de seguridad, ahorita pues actualmente nomás se encuentran los de default, vamos a crear un grupo de seguridad, en este caso le voy a poner demo.

Y.

Como es para la R vamos a poner igual aquí una descripción, pueden poner tal cual la que ustedes gusten, yo en este caso voy a copiar el mismo nombre, aquí se define en qué VPC, esto pues igual importante los grupos de seguridad deben de estar y son a nivel de VPC, igual nosotros ya tenemos como bien mencionábamos nuestro entorno de red ya configurado y para esto nuestra VPC es la VPC usted demoase aquí los grupos de seguridad cuentan como tanto reglas de salida como reglas de entrada, por defecto siempre se crean con una regla de salida hacia todo público, esto básicamente no quiere decir que nuestros servidores vayan a estar expuestos, no, sino que básicamente en base a las reglas de entrada los que puedan entrar van a salir, entonces nosotros aquí podemos restringir desde las reglas tal cual definimos qué protocolo se va a estar permitiendo, en este caso pues el mysql y hacia que por el momento yo voy a dejar hacia cualquier IP versión 4, esto no es lo adecuado e igual pues más adelante mi compañero Mario va a estar mostrando cómo vamos a tal cual restringirlo a que nuestro servidor web nada más tenga permisos y pues una descripción referente a lo que es este puerto y pues las tags, nosotros siempre recomendamos aquí en los grupos de seguridad colocar una tag de name y pues la de creación, la fecha de creación no? Igual y aquí ya se nos puede ver y bien listo y ahora sí vamos a crear nuestro grupo de seguridad, igual si nosotros no le hubiéramos puesto la tag de nombre no afectaría pero no se vería aquí, aquí básicamente se vería una línea igual ya está creado nuestro grupo de seguridad, lo que se sigue tal cual es dirigirnos a servicio de R para crear nuestro y ahora si nuestro servidor. Bien ya me encuentro dentro del servicio de AIR, Algo muy importante es antes de crear nuestro servidor de base de datos es que quiero mencionar que ya tenemos el subnet group que ya lo había mencionado previamente en las diapositivas, este pues básicamente define en qué VPC va a estar nuestro servidor y en qué subnet se puede se van a estar utilizando para él tal cual es lo que se muestra en Parameter Groups como bien les mencionaba, este pues define como las configuraciones iniciales de nuestro servidor de base de datos, por ejemplo aquí podemos ver estas configuraciones, por ejemplo la Time Zone o por ejemplo el formato de semana tal cual defecto y todas estas opciones tal cual aquí las podemos visualizar, es recomendable utilizar y crear uno para cada servidor que vayamos a estar realizando, ya AWS tiene creados unos por defecto, pero nosotros pues recomendamos crear sus propios tanto Parameter Groups como Option Groups que aquí ya están. Entonces ahora nos vamos ahora sí a la parte de Database en el menú lateral izquierdo y a crear nuestra base de datos. Como primera opción de configuración es tal cual si queremos que nuestra base de datos sea estándar o que sea literal, poder configurar y personalizar nuestra creación. Si nosotros queremos irnos a modo fácil se nos van a autocompletar muchas de las configuraciones, para este caso nosotros vamos a ver todas estas configuraciones y lo vamos a dejar en modo de creación estándar. Lo primero pues elegir el motor, Vamos a elegir Aurora MySQL, enseguida la versión, por eso es importante y mencioné pues también en las diapositivas verificar que la versión esté disponible en AWS, por esta ocasión vamos a seleccionar esta. Ahora viene la parte de si nuestra base de datos va a ser de producción o va a ser de desarrollo, en este caso nosotros la vamos a dejar de producción, aquí en el nombre del clúster pues nosotros vamos a poner R demo AC Clúster y bueno, ah bueno es que esto se lo va a autocompletar, entonces bien le voy a dejar este nombre. Enseguida viene la parte del usuario máster, en este caso nosotros vamos a dejar este usuario admin y la contraseña de este usuario máster, esta se puede cambiar en cualquier momento, en cualquier punto, en este caso ahorita la coloco bien, ahora la siguiente configuración es la de tal cual almacenamiento, aquí tenemos dos opciones, como estamos utilizando Aurora, sabemos que Aurora pues tal cual tiene estos beneficios de que pues nos va a estar tal cual escalando este almacenamiento de 10 en 10 GB, es una de las configuraciones que nos proporciona el estar trabajando con Aurora MySQL, entonces nosotros por defecto vamos a dejar Aurora estándar, esto para la parte de COSEffective tal cual más económica que utilizar optimización de iOS y pues enseguida viene la parte del tamaño de nuestra clase, tal cual definir la clase de nuestra base de datos que vendría siendo cuántos V, CPUs y RAM queremos, aquí actualmente ya existe en Aurora la parte de serverless y aquí se trabaja por acos en serverless, pero ahora pues por cuestiones prácticas nosotros nos vamos a ir a la familia de tipo T y pues aquí vamos a dejar la medium, igual aquí podemos visualizar otros tipos de familia, otros tipos, otras clases de instancia y aquí se muestra abajo la capacidad tal cual, nosotros vamos a dejar 2 vcpus y 4 gb de ram Enseguida la parte de disponibilidad, nosotros podemos crear como bien sabemos con Amazon Aurora varias red réplicas, en este caso nosotros pues por cuestiones prácticas vamos a dejar únicamente el nodo de escritura tal cual y enseguida viene la configuración de red, aquí nosotros podemos desde ahorita definir que va a estar conectándose a una instancia EC, como nosotros vamos a mostrar todo el proceso vamos a dejarlo como que no queremos crear esta conexión desde ahorita con una instancia EC y vamos a dejar en cuanto al tipo de red la IPV, enseguida pues en qué VPC vamos a colocar nuestra base de datos, sabíamos que teníamos un subnet group, entonces si nosotros aquí seleccionamos la VPC en la que vamos a estar trabajando, si verifican aquí automáticamente se auto selecciona el subnet group que hemos creado y enseguida la parte de si queremos pública o privada nuestra base de datos, esto básicamente es asignarle o no asignarle una IP, en este caso todo lo tenemos en ambiente privado, el subnet group tiene tal cual definidas subnets privadas, nosotros vamos a dejarlo como no y podemos aquí la parte de la creación, podemos crear un grupo de seguridad en el momento de creación de nuestra base de datos o podemos seleccionar uno que nosotros ya hayamos creado, en este caso caso aquí está el que creamos hace un momento y podemos elegir si nosotros queremos una zona en específico en la cual se cree o podemos decir que no tenemos preferencia sobre esto, en este caso pues nosotros podemos seleccionar cualquiera de las dos y la parte de configuración de Airds Proxy, que en este caso no nos vamos a meter porque es un tema bastante abundante en cuanto a conocimiento y por cuestiones también de tiempo vamos a dejarlo así, en adicional configuración solamente se nos va a mostrar el puerto, igual lo abro para que lo vean y la parte de red réplicas, Write Forwarding, básicamente es que lo recomendable es que dentro del código que se va a estar utilizando para el aplicativo se coloque cuando se trabaja con nodos de lectura y nodos de escritura. Nodos de lectura cuando nada más se va a leer en la aplicación y nodo de escritura únicamente cuando se va a escribir en caso de que nosotros queramos escribir o que al escribir en nodo de lectura se mande a nuestro nodo de escritura, para esto es esta configuración, en este caso nosotros no más vamos a crear el nodo de escritura, no lo veríamos necesario Y la parte de Database Autenticación vamos a dejarlo por allá. La parte de monitoreo por defecto viene 60 segundos, aquí se podrá configurarse entre menos tiempo, nosotros Vamos a dejarle 60 segundos. Y en adicional configuración aquí viene lo que mencionaba del Parameter Group y del Subnet Group, en este caso nosotros tal cual dejamos este de defecto y este de remo R Demo AC sería el que nosotros creamos y aquí por si nosotros queremos desde un instante de creación de nuestro servidor poner o crear una base de datos con un nombre en específico, podemos seleccionarlo, en este caso nosotros ya traemos nuestro esquema de base de datos, entonces más adelante vamos a estar mostrando cómo hacer para que este esquema que tenemos colocarlo dentro de nuestro servidor de base de datos, entonces por el momento lo dejamos así. En siguiente la parte de Failover Priority, que aquí básicamente es cuando haya un punto de falla a cuál de los nodos tanto de lectura se va a estar utilizando para esta recuperación, en este caso nosotros podemos dejarle el 1. ¿Y bueno la parte de Backup no? ¿Esto nosotros siempre la de defecto recomendamos al menos siete días no? ¿Esto va a ser respaldos diarios con una retención de 7 días, siempre vamos a tener los 7 respaldos de los últimos 7 días, entonces pues prácticamente aquí estamos definiendo esto no? ¿Si queremos que nada más sean los últimos 3 días, únicos 3 días, ahí nosotros lo definimos no? Y que se copien las tablas de nuestra base de datos. En cuanto a encriptación, como bien ya creamos nuestra KMS, aquí nada más la seleccionamos y pues tal cual aquí lo de backtrack, esto básicamente es que Aurora nos permite una gran funcionalidad de que no es necesario nosotros restablecer en un punto hacia atrás con un respaldo, básicamente si nosotros habilitamos esto podemos regresarnos a un punto en específico nuestra base de datos sin tener que realizar un respaldo, volverla a lanzar, digámoslo así, que creamos una o que eliminamos por accidente información, ¿Que haríamos? Agarrar un respaldo de la fecha donde se tenía la información y listo. Con esta opción pues básicamente no es necesario ir a generar el respaldo o ir a buscar los respaldos. Está básicamente nos deja regresarnos a un punto en específico, en este caso no lo voy a seleccionar. Y la parte de logs, ¿Que logs queremos tal cual nosotros tener de nuestra base de datos? Nosotros aquí pues vamos a seleccionar todos. La parte de mantenimiento, aquí nosotros podemos ponerle que no tenemos preferencia de cuánto se realice e incluso podemos quitar esta parte de ventanas de mantenimiento, que es que prácticamente si nosotros definimos una ventana de mantenimiento en una fecha en específico, por ejemplo el domingo a las 3 de la mañana, porque esto está en UETC, pues en esa hora AWS generaría, digámoslo así, crearía la parte de actualizaciones, Actualizaciones pendientes, cosas por el estilo, se realizarán en esta ventana de mantenimiento. Y la parte de Delete on termination, básicamente esta es una opción de seguridad, se recomienda siempre tenerla habilitada en cuestión de que tú quieras eliminar tu base de datos, no la puedes eliminar si tienes habilitado esto, tendrías que venir a deshabilitarla y ahora sí eliminarla. Nosotros la vamos a dejar aquí habilitada. Y por último, como es una aurora aquí y no entra dentro de la capa gratuita de AWS, aquí se nos muestra un presupuesto de lo que se estaría gastando mensualmente. Ahora sí, vamos a crear nuestra base de datos y por este momento les dedo la palabra a mi compañero Mario para que continúe con el proceso.

Muchas gracias, Ceci. Voy a compartir yo también por aquí mi pantalla para continuar con el proceso de la implementación de la arquitectura que hemos previsto. Muy bien, me avisan por favor cuando ya se vea, por favor.

Listo Mario, ya lo vemos.

Listo, muchas gracias. Muy bien, pues vamos a continuar. Nosotros también nos encontramos aquí en la consola de AWS, vamos a crear nuestra segunda CMK que vamos a utilizar para encriptar nuestros volúmenes de nuestras instancias. Así que nos vamos a ir al servicio de KMS y quiero comentarles que mientras nosotros hacemos toda esta configuración, el clúster de la base de datos se va a estar creando, es decir, no podemos avanzar en la base de datos porque toma su tiempo en levantarse la infraestructura, ¿Sale? Muy bien, vamos a crear una llave muy similar a esta, la que creó mi compañera Ceci, vamos a crearla también de tipo asimétrica y lo vamos a utilizar para encriptar y desencriptar. Vamos a ponerle también por aquí un nombre nada más que le vamos a cambiar aquí lo vamos a poner que es para las EC o para nuestros servidores. Le vamos a poner también por aquí una descripción y por aquí también le vamos a poner el name y le vamos a dar continuar. Nuestros usuarios administradores para esta key también van a ser nuestros usuarios y nuestro rol que utilizamos para interactuar también con la consola. Ahora viene algo muy importante aquí ¿Quién va a poder utilizar esa llave para encriptar y desencriptar? Vamos a poner roles que son los que van a permitir o que el servicio de KMS va a permitir que puedan utilizar, es aquí en este caso vamos a poner el rol de las instancias EC que va a tener que se llama rol s scm demo ac. Con este rol le vamos a decir que nuestras instancias e van a poder desencriptar, o sea van a poder utilizar la llave para encriptar y desencriptar nuestros discos. También vamos a poner el rol que va a utilizar el auto scaling, a esto se le conoce como service linked roll, que es un servicio que ya viene por defecto en las cuentas de AWS. Y si se fijan por aquí tenemos algunos, en este caso nosotros vamos a utilizar el del auto scaling porque cuando nosotros lancemos el auto scaling, el auto scaling va a lanzar instancias, entonces también ocupa permiso para esta llave y lo vamos a buscar que sería este que está aquí. Y por último vamos a poner a nuestros usuarios también y al rol que estamos utilizando le vamos a dar next y vamos a ver el review de la key que vamos a crear, le vamos a dar en finalizar. Muy bien, ya hemos creado también la llave o la CMK que va a encriptar nuestros volúmenes de EBS. Ahora vamos a continuar creando nuestro Security Group para el balanceador de cargas y para nuestras instancias EC. Para eso pues nos vamos a ir al servicio de EC y nos vamos a ir al apartado de grupos de seguridad. ¿Como vemos aquí está el que acaba de crear mi compañera Ceci, nosotros vamos a crear dos, uno para el balanceador como se veía en el diagrama y uno para nuestras instancias DC le vamos a dar crear en Security Group, le vamos a poner un nombre similar, en este caso primero vamos a crear el del balanceador de carga y le vamos a decir que es un Security Group para el balanceador de cargas, vamos a crearlo a nivel de VPC, en este caso la que estamos utilizando y ojo aquí, esto es muy importante porque qué regla vamos a permitir inicialmente? Inicialmente vamos a poner la regla en el puerto HTTP, ya que aún no hemos incorporado el certificado SCL, de momento vamos a dejar que solamente reciba peticiones en el puerto 80 y desde cualquier origen, o sea le vamos a decir que esta regla permite el puerto HTTP desde Internet y vamos a poner nuestra etiqueta de nombre. ¿Vamos a crear este grupo de seguridad Ahora vamos a crear el grupo de seguridad que estaría actuando como el firewall para nuestras instancias de Sí, aquí también viene algo muy importante, vamos a permitir la regla en el puerto 80 pero desde qué origen? Muy bien, voy a ponerle por aquí nomás la descripción, selecciono la VPC. Ahora vamos a permitir, como nuestro proyecto se va a ejecutar en Apache en el puerto 80 en los servidores, vamos a permitir el tráfico de entrada en el puerto 80, sí, pero desde qué origen, no queremos que esté expuesto al Internet, podríamos dejarlo así y sin ningún problema funcionar, pero siguiendo las mejores prácticas que AWS nos recomienda, solamente debemos permitir a los usuarios o al servicio autorizado hacia este puerto, en este caso sería el balanceador. ¿Qué es lo que debemos hacer aquí? Especificarle que sólo el grupo de seguridad del balanceador va a poder ingresar a través del puerto 80, en este caso voy a seleccionar el grupo de seguridad que acabo de crear y aquí la descripción que voy a poner es Permitir HTTP desde el balanceador de cargas, no desde Internet y también le vamos a poner la etiqueta de nombre. Muy bien, si recuerdan mi compañera Ceci, como no teníamos creados los otros dos grupos de seguridad, el puerto de la RDS lo dejó abierto en el puerto de MySQL hacia cualquier desde cualquier origen, o sea desde Internet. Vamos a ir a editar esa regla para decirle que solamente el grupo de seguridad de las instancias EC va a poder ingresar al puerto 3306 de la base de datos, entonces por aquí vamos a dar en Actions y le vamos a dar en Editar reglas de entrada. ¿No podemos por alguna razón AWS no nos deja modificar de una dirección IP a un grupo de seguridad, por aquí nos marca un error, si la ponemos dice que nosotros no podemos hacer ese cambio directamente así que tenemos que crear una regla nueva, la vamos a crear, vamos a decirle que es el puerto de mysql otra vez pero que no queremos que accedan.

Bien, ahora la siguiente configuración es la de tal cual almacenamiento, aquí tenemos dos opciones, como estamos utilizando Aurora sabemos que Aurora pues tal cual tiene estos beneficios de que pues nos va a estar tal cual escalando este almacenamiento de 10 en 10 GB es una de las configuraciones que nos proporciona el estar trabajando con Aurora MySQL, entonces nosotros por defecto vamos a dejar Aurora estándar, esto para la parte de cost effective tal cual más económica que utilizar optimización de iOS y pues enseguida viene la parte del tamaño de nuestra clase, tal cual definir la clase de nuestra base de datos que vendría siendo cuántos V, CPU y RAM queremos, aquí actualmente ya existe en Aurora la parte de serverless y aquí se trabaja por acos en serverless pero ahora pues por cuestiones prácticas nosotros nos vamos a ir a la familia de tipo t y pues aquí vamos a dejar la medium, igual aquí podemos visualizar otros tipos de familia, otras clases de instancia y aquí se muestra abajo la capacidad tal cual, nosotros vamos a dejar 2 vcpus y 4 gb de ram Enseguida la parte de disponibilidad, nosotros podemos crear como bien sabemos con Amazon Aurora varias red réplicas, en este caso nosotros pues por cuestiones prácticas vamos a dejar únicamente el nodo de escritura tal cual y enseguida viene la configuración de red, aquí nosotros podemos desde ahorita definir que va a estar conectándose a una instancia ec, como nosotros vamos a mostrar todo el proceso vamos a dejarlo como que no queremos crear esta conexión desde ahorita con una instancia s y vamos a dejar en cuanto al tipo de red la ip versión 4 enseguida pues en qué VPC vamos a colocar nuestra base de datos, sabíamos que teníamos un subnet group, entonces si nosotros aquí seleccionamos la VPC en la que vamos a estar trabajando, si verifican aquí automáticamente se autoselecciona el subnet group que hemos creado y enseguida la parte de si queremos pública o privada nuestra base de datos, esto básicamente es asignarle o no asignarle una IP, en este caso todo lo tenemos en ambiente privado, el subnet group tiene tal cual definidas subnets privadas, nosotros vamos a dejarlo como no y podemos aquí la parte de la creación, podemos crear un grupo de seguridad en el momento de creación de nuestra base de datos o podemos seleccionar uno que nosotros ya hayamos creado, en este caso aquí está el que creamos hace un momento y tiene tal cual definidas subnets privadas, nosotros vamos a dejarlo como no y podemos aquí la parte de la creación, podemos crear un grupo de seguridad en el momento de creación de nuestra base de datos o podemos seleccionar uno que nosotros ya hayamos creado, en este caso aquí está el que creamos hace un momento y podemos elegir si nosotros queremos una zona en específico en la cual se cree o podemos decir que no tenemos preferencia sobre esto, en este caso pues nosotros podemos seleccionar cualquiera de las dos y la parte de configuración de Airds Proxy, que en este caso no nos vamos a meter porque es un tema bastante abundante en cuanto a conocimiento y por cuestiones también de tiempo vamos a dejarlo así en adicional configuración solamente se nos va a mostrar el puerto, igual lo abro para que lo vean y la parte de Red Réplicas Write Forwarding, básicamente es que lo recomendable es que dentro del código que se va a estar utilizando para el aplicativo se coloque cuando se trabaja, podemos elegir si nosotros queremos una zona en específico en la cual se cree con nodos de lectura y nodos de escritura, nodos de lectura cuando nada más se va a leer en la aplicación y nodo de escritura únicamente cuando se va a escribir en caso de que nosotros queramos escribir o que al escribir en un nodo de lectura se mande a nuestro nodo de escritura, para esto es esta configuración o podemos decir que no tenemos preferencia sobre esto, en este caso pues nosotros podemos seleccionar cualquiera de las dos y la parte de configuración de Airds Proxy, que en este caso nos vamos a meter porque es un tema bastante abundante en cuanto a conocimiento y por cuestiones de caso nosotros nomás vamos a crear el nodo de escritura, no lo veríamos necesario y la parte de Database autenticación vamos a dejarlo por allá la parte de monitoreo por defecto viene 60 segundos, aquí se podrá configurarse entre menos tiempo, nosotros vamos a dejarle 60 segundos y en adicional configuración aquí viene lo que mencionaba del parámetro group y del subnet group, en este caso nosotros tal cual dejamos este de defecto y este de remo R demo AC sería el que nosotros creamos y aquí por si nosotros queremos desde un instante de creación de nuestro servidor poner o crear una base de datos con un nombre en específico es también de tiempo, vamos a dejarlo así en adicional configuración solamente se nos va a mostrar el puerto, igual lo abro para que lo vean y la parte de Red Réplica write Forwarding, básicamente es que lo recomendable es que dentro del código podemos seleccionarlo en este caso nosotros ya traemos nuestro esquema de base de datos que se va a estar utilizando para el aplicativo se coloque cuando se trabaja entonces más adelante vamos a estar mostrando cómo hacemos para que este esquema que tenemos colocarlo dentro de nuestro servidor de base de datos entonces por el momento lo dejamos así en siguiente la parte de Failover priority que aquí básicamente es cuando haya un punto de falla de los nodos tanto de lectura se va a estar utilizando para esta recuperación, en este caso nosotros podemos dejarle el 1 y bueno la parte de backup, esto nosotros siempre la de defecto recomendamos al menos siete días no? ¿Esto va a ser respaldos diarios con una retención de 7 días siempre vamos a tener los 7 respaldos de los últimos 7 días entonces pues prácticamente aquí estamos definiendo esto no? Si queremos que nada más sean los últimos 3 días únicos 3 días ahí nosotros lo definimos y que se copien las tags de nuestra base de datos En cuanto a encriptación como bien ya creamos nuestra KMS aquí nada más la seleccionamos y pues tal cual aquí lo de backtrack, esto básicamente es que Aurora nos permite una gran funcionalidad de que no es necesario nosotros restablecer en un punto hacia atrás con un respaldo básicamente si nosotros habilitamos esto podemos regresarnos a un punto en específico nuestra base de datos sin tener que realizar de un respaldo volverla a lanzar, digámoslo así que creamos una o que eliminamos por accidente información que haríamos agarrar un respaldo de la fecha donde se tenía la información y listo con esta opción pues básicamente no es necesario ir a generar el respaldo o ir a buscar los respaldos está básicamente nos deja regresarnos a un punto en específico, en este caso no lo voy a seleccionar y la parte de logs, qué logs queremos tal cual nosotros tener de nuestra base de datos nosotros aquí pues vamos a seleccionar todos, la parte de mantenimiento, aquí nosotros podemos ponerle que no tenemos preferencia de cuánto se realice e incluso podemos quitar esta parte de ventanas de mantenimiento que es que prácticamente si nosotros definimos una ventana de mantenimiento en una fecha en específico, por ejemplo el domingo a las 3 de la mañana porque esto está en UTC, pues en esa hora AWS generaría, digámoslo así, crearía la parte de actualizaciones, actualizaciones pendientes, cosas por el estilo se realizarían en esta ventana de mantenimiento y la parte de LED on termination, básicamente esta es una opción de seguridad, se recomienda siempre tenerla habilitada en cuestión de que tú quieras eliminar tu base de datos no la puedes eliminar si tienes habilitado esto, tendrías que venir a deshabilitarla y ahora sí eliminar.