5 formas de optimiza la arquitectura AWS con Neteris

Todas las empresas buscan optimizar sus costes para aumentar margen o ser más competitivas en el precio de sus servicios, pero muchas veces no se dedica el esfuerzo necesario a optimizar la arquitectura de IT que soporta al negocio, generando problemas a medio/largo plazo.

En este blog evaluaremos algunas de las formas de optimizar un ecosistema AWS de manera sencilla, desde el punto de vista de la arquitectura.

IMG Principal Blog 5 formas optimizar arquitectura AWS

Los costes, la punta del iceberg

Previamente, en el blog “AWS cost optimization: 5 formas de ahorrar en AWS” hablamos de algunas metodologías que normalmente empleamos para optimizar los costes de un ecosistema AWS.

> AWS Cost Optimization: 5 formas de ahorrar en AWS

Comenzábamos comentando que el primer punto es la concienciación, es decir, analizar las necesidades y evaluar si el despliegue actual las satisface de manera óptima, vigilando que los costes sean los mínimos.

Sin embargo, para nuestro negocio no solamente es importante que los costes de IT sean óptimos, sino que se han de tener en cuenta otros muchos aspectos. Estos aspectos, si bien no contribuyen a decrementar costes e incluso pueden incrementarlos, son de igual o mayor importancia, ya que de ellos dependen aspectos como cumplimiento de SLA, cumplimiento normativo, disponibilidad del servicio o seguridad.

Cuando analizamos una arquitectura, aparte de los costes, tenemos que analizar:

Arquitectura de red y aislamiento de capas
Seguridad de los datos
Seguridad de acceso de los usuarios
Disponibilidad, Elasticidad y Agilidad
Continuidad de negocio

Digamos que estos 5 elementos pueden asemejarse a la parte del iceberg que está bajo el agua, y que solamente se perciben cuando chocamos con ella de manera inesperada y nuestro negocio se tambalea.

La parte oculta del iceberg y el Well Architected Framework

Imagino que habrás escuchado hablar, o conocerás, el AWS Well Architected Framework. Básicamente, marca una serie de pilares en base a los cuales es necesario analizar y tomar las decisiones de una arquitectura en la nube:

Excelencia Operacional
Seguridad
Fiabilidad
Eficiencia en Rendimiento
Optimización de costes
Sostenibilidad

Te invitamos, en el caso de que no estés familiarizado con ellos, a echarle un vistazo a nuestro blog sobre AWS Well Architected Framework:

> AWS Well Architected Framework optimiza tu estrategia en la nube

Una vez puestos en contexto, vamos a ir desgranando la manera en la que desde Neteris colaboramos con nuestros clientes a la hora de analizar esa parte oculta del iceberg al que comparamos con la Well Architected Framework.

1. Arquitectura de red y aislamiento de capas

A nivel de red, puede ser tan sencilla como todos los componentes de IT en una misma red pública, o tan compleja como una serie de subredes públicas y privadas que agrupan los elementos que han de relacionarse entre sí. Se acuerda quién puede comunicarse con quien basándonos en la filosofía least privilege, es decir, que siempre se asignen los mínimos permisos o se permitan el mínimo tipo de conexiones (origen y destino) necesarias para que cada uno de los aplicativos ofrezca el servicio.

AWS nos ofrece la posibilidad de desplegar elementos de red como gateways, NAT, endopints, de manera que podamos segmentar nuestro datacenter virtual (VPC – Virtual Private Network) en función de los requerimientos de nuestro aplicativo.

Algunos de estos servicios suponen un coste adicional, que se compensa ya que gracias a ellos aumentamos la seguridad de nuestra plataforma, especialmente al controlar quien puede acceder a que, reforzando el perímetro de seguridad.

Además, a nivel de operación, esta segregación en redes nos permite poder llevar a cabo una mejor gobernanza del ecosistema, puesto que facilitamos el mantenimiento y la gestión del ciclo de vida de los elementos que componen la arquitectura gracias a esa agrupación a nivel de red.

2. Seguridad de los datos

La seguridad del dato es fundamental, y es donde se implementa la última línea de defensa ante un ataque. Si el atacante consigue llegar al dato, como mínimo debemos asegurarnos de que:

El dato esté encriptado
Tengamos a nuestra disposición el dato en otro lugar (otra región, por ejemplo) de manera que si sufrimos un ataque como por ejemplo ransomware, podamos recuperar el dato limpio y nuestro negocio siga funcionando sin problemas.

Aquí mezclamos varios elementos de seguridad: Encriptación, Backup y Recuperación.

Por tanto, al analizar cómo se asegura una compañía de que su dato es resistente a ataques, estos factores son de obligada revisión.

3. Seguridad de acceso de los usuarios

Comparemos los siguientes escenarios:

Habilitar acceso desde internet directamente a una máquina virtual en la nube desplegada en una subred pública
Desplegar la máquina virtual en una subred privada, protegiéndola mediante elementos de red como Web Application Firewall (WAF) y Balanceador de carga

Seguramente pensemos que esta opción más segura tiene unos costes muy superiores a opción más sencilla, pero no, afortunadamente, no es así.

Los costes de un WAF, un balanceador, un API Gateway, o endpoints en AWS son muy bajos si analizamos su coste en función de los problemas que nos evitan. Por lo que no incluirlos en nuestra arquitectura es un error grave, ya que nos ahorrará un puñado de euros pero pondrá en peligro la seguridad de nuestro ecosistema.

4. Disponibilidad, elasticidad y agilidad

Está claro que desplegar el aplicativo en 2 máquinas en lugar de en una sola tiene un coste mayor, pero ¿qué pasa si una máquina cae? Si tenemos solamente una, nuestro negocio se resiente, nuestras ventas se paran (y puede que no consigamos recuperarlas), por lo que desplegar arquitecturas altamente disponibles es un aspecto a considerar.

Mecanismos como balanceo de carga y autoescalado hacen que no desperdiciemos capacidad de cómputo (y por tanto dinero) al mismo tiempo que nos garantizan que nuestra arquitectura será redundante a fallos y podrá satisfacer picos de demanda.

5. Continuidad de negocio

Tu arquitectura está impoluta, es infalible y tu negocio funciona perfectamente gracias a ella. ¡Enhorabuena! Pero ¿qué pasa si hay un problema grave, ya sea por motivos internos o externos? ¿Qué pasa si se comete un fallo irrecuperable o si la región donde está tu arquitectura sufre un problema?

Siempre queda el levantamiento manual en otra región, pero, aparte del tiempo que pueda tardarse en llevar a cabo esta proeza, si no tenías los datos fuera de la región que ha fallado o en una localización diferente a la que ha sufrido el problema, ¿cómo se ve impactado tu negocio?

Aquí abordamos la pregunta estrella: ¿cuáles son los requisitos RTO y RPO marcados por negocio? ¿Es posible cumplirlos con tu arquitectura actual?

Dentro de la revisión de la Well Architected Framework, también analizamos el plan de recuperación de desastres o de continuidad de negocio, para el cual tenemos una serie de soluciones que nos facilitan poder resistir ante problemas sin que negocio sufra.

Conclusión

En este blog hemos visto 5 maneras de optimizar la arquitectura en AWS, pero son solamente algunos de los ejemplos más sencillos que podemos encontrarnos comúnmente.

Desde Neteris realizamos este tipo de estudios con el objetivo de optimizar todos y cada uno de los pilares del Well Architected Framework de AWS, de manera que tu arquitectura de IT sea óptima en todos los sentidos, y tu negocio se base en la mejor arquitectura posible.

Te invitamos a que agendes reserves un hueco para que podamos comentar cómo podríamos ayudarte a realizar este análisis en tu infraestructura.