Forem: Sergio Jiménez

DevSecOps en las pipelines de Terraform

Sergio Jiménez — Sun, 21 Jul 2024 18:35:28 +0000

En el mundo de la computación en la nube, la automatización y la agilidad son fundamentales para mantenerse competitivo. Terraform, una herramienta de código abierto para la provisión de infraestructura como código (IaC), ha ganado una gran popularidad debido a su capacidad para administrar y aprovisionar recursos en múltiples proveedores de nube de manera eficiente y consistente. Sin embargo, a medida que las organizaciones adoptan Terraform en sus flujos de trabajo de DevOps, es crucial integrar prácticas de seguridad desde el principio para garantizar una postura de seguridad sólida en entornos de nube.

DevSecOps, la integración de la seguridad en el ciclo de vida de desarrollo de software, es fundamental para abordar los desafíos de seguridad en entornos de nube dinámicos y distribuidos. Al incorporar la seguridad en las pipelines de Terraform, las organizaciones pueden identificar y mitigar los riesgos de seguridad desde las primeras etapas del ciclo de vida de la infraestructura, reduciendo así la superficie de ataque y cumpliendo con los requisitos de cumplimiento normativo.

Una de las prácticas clave de DevSecOps en las pipelines de Terraform es la implementación de análisis de código estático y escaneos de seguridad. Estas herramientas pueden detectar problemas de seguridad, como configuraciones inseguras, permisos excesivos y vulnerabilidades conocidas en los módulos de Terraform. Al integrar estos escaneos en las etapas tempranas de la canalización de CI/CD, los equipos pueden identificar y corregir los problemas de seguridad antes de que se implementen en entornos de producción.

Otra práctica importante es la implementación de pruebas de seguridad automatizadas. Estas pruebas pueden verificar que los recursos aprovisionados por Terraform cumplan con las políticas y los estándares de seguridad establecidos. Por ejemplo, las pruebas pueden validar que los recursos de almacenamiento estén correctamente cifrados, que los grupos de seguridad tengan reglas de entrada y salida apropiadas, y que se hayan aplicado los controles de acceso adecuados.

Además, la integración de herramientas de gestión de secretos y credenciales en las pipelines de Terraform es crucial para proteger la información sensible. Estas herramientas garantizan que las claves de acceso, las contraseñas y otros secretos se almacenen y gestionen de manera segura, reduciendo el riesgo de exposición accidental o mal uso.

Otro aspecto clave de DevSecOps en las pipelines de Terraform es el seguimiento y la auditoría. Las herramientas de monitoreo y registro pueden proporcionar visibilidad sobre los cambios realizados en la infraestructura, lo que facilita la detección de actividades sospechosas y el cumplimiento de los requisitos normativos. Además, la implementación de controles de acceso basados en roles (RBAC) y la separación de tareas pueden ayudar a mitigar los riesgos de acceso no autorizado y garantizar la integridad de la infraestructura.

Al adoptar prácticas de DevSecOps en las pipelines de Terraform, las organizaciones pueden aprovechar los beneficios de la automatización y la agilidad de la nube, al tiempo que mantienen una postura de seguridad sólida. Esto no solo reduce los riesgos de seguridad y el cumplimiento normativo, sino que también fomenta una cultura de seguridad integrada en todo el ciclo de vida del desarrollo de software y la infraestructura.

En resumen, a medida que las empresas continúan adoptando la nube y herramientas como Terraform, es fundamental incorporar prácticas de DevSecOps para garantizar una postura de seguridad cloud-native sólida. Al integrar la seguridad desde el principio en las pipelines de Terraform, las organizaciones pueden mitigar los riesgos, cumplir con los requisitos normativos y aprovechar al máximo los beneficios de la nube de manera segura y confiable.

Postura de seguridad cloud-native

Sergio Jiménez — Sun, 21 Jul 2024 18:33:43 +0000

Abordando los nuevos riesgos en entornos de nube

A medida que las empresas migran a entornos de nube, es crucial comprender los nuevos desafíos de seguridad que surgen en estos entornos dinámicos y distribuidos. Si bien la nube ofrece numerosos beneficios, como escalabilidad, agilidad y reducción de costos, también introduce nuevos riesgos inherentes que deben abordarse de manera proactiva.

Uno de los principales cambios en la seguridad cloud-native es el enfoque en la protección de cargas de trabajo y servicios en lugar de sistemas y dispositivos físicos. En entornos on-premises tradicionales, las organizaciones se centraban en asegurar el perímetro de la red y los servidores físicos. Sin embargo, en la nube, las cargas de trabajo se distribuyen en múltiples servicios y recursos, lo que requiere un enfoque de seguridad más granular y basado en políticas.

Otro aspecto clave es la naturaleza dinámica y efímera de los recursos en la nube. Las instancias de cómputo, los contenedores y los servicios se crean y destruyen constantemente, lo que dificulta el seguimiento y la aplicación de controles de seguridad tradicionales. Esto resalta la necesidad de adoptar enfoques de seguridad automatizados e integrados en el ciclo de vida de las aplicaciones, como la seguridad de la canalización de CI/CD y la implementación de políticas de seguridad como código.

Además, la nube introduce nuevos vectores de ataque y superficies de ataque más amplias. Las configuraciones incorrectas de los servicios en la nube, como los permisos excesivos en los buckets de almacenamiento o las reglas de seguridad de grupos de seguridad mal configuradas, pueden exponer datos sensibles y recursos críticos. Esto subraya la importancia de implementar prácticas de higiene en la nube, como el escaneo continuo de configuraciones y el endurecimiento de la postura de seguridad.

Sin embargo, la nube también ofrece oportunidades para mejorar la seguridad en comparación con los entornos on-premises. Los proveedores de servicios en la nube invierten enormes recursos en la seguridad de sus plataformas, ofreciendo características de seguridad integradas, como el cifrado de datos en reposo y en tránsito, la autenticación reforzada y la protección contra amenazas. Además, la nube facilita la implementación de arquitecturas de seguridad modernas, como el acceso a red de confianza cero (ZTNA) y la seguridad de acceso al servicio en la nube (SASE), que pueden mejorar la postura de seguridad general.

Para aprovechar al máximo los beneficios de la nube y mitigar los riesgos asociados, las organizaciones deben adoptar un enfoque de seguridad cloud-native. Esto implica adoptar principios como la seguridad como código, la automatización de la seguridad, la implementación de controles de seguridad granulares basados en políticas y la integración de la seguridad en todo el ciclo de vida de las aplicaciones en la nube. Además, es fundamental contar con personal capacitado en seguridad en la nube y establecer una cultura de seguridad sólida en toda la organización.

En resumen, mientras que la nube introduce nuevos desafíos de seguridad, también ofrece oportunidades para mejorar la postura de seguridad general. Al adoptar un enfoque de seguridad cloud-native y aprovechar las capacidades de seguridad integradas de los proveedores de servicios en la nube, las organizaciones pueden mitigar los riesgos y aprovechar al máximo los beneficios de la nube de manera segura y confiable.

La nube difumina el perímetro de seguridad

Sergio Jiménez — Sun, 21 Jul 2024 18:28:34 +0000

¿Por qué las VPN ya no son suficientes? La necesidad de adoptar soluciones ZTNA

En la era de la computación en la nube y el acceso remoto, el concepto tradicional de un perímetro de seguridad bien definido se ha vuelto cada vez más difuso. Las empresas ya no pueden confiar en un enfoque de "castillo y foso" para proteger sus recursos, ya que los empleados, socios y clientes acceden a aplicaciones y datos desde una variedad de ubicaciones y dispositivos. En este entorno en constante evolución, las redes privadas virtuales (VPN) tradicionales, que fueron diseñadas para extender el perímetro de la red corporativa, ya no son suficientes para abordar los desafíos de seguridad actuales.

Una de las principales limitaciones de las VPN es que, una vez que un usuario se autentica y se conecta a la red corporativa, se le otorga un nivel de confianza y acceso excesivo a recursos que pueden no ser necesarios para su función. Esto amplía innecesariamente la superficie de ataque, exponiendo a la organización a riesgos de seguridad significativos. Además, las VPN a menudo requieren configuraciones complejas y pueden ser propensas a vulnerabilidades y ataques, como el robo de credenciales o la interceptación de tráfico.

En contraste, el enfoque de Acceso a Red de Confianza Cero (ZTNA, por sus siglas en inglés) ofrece una solución más segura y escalable para el acceso a recursos en la nube y aplicaciones SaaS (Software as a Service). ZTNA se basa en el principio de "nunca confiar, siempre verificar", lo que significa que cada solicitud de acceso a un recurso se autentica, autoriza y aplica políticas de seguridad antes de permitir la conexión.

Al adoptar ZTNA, las empresas pueden reducir significativamente su superficie de ataque al limitar el acceso solo a los recursos específicos que un usuario necesita para realizar su trabajo. Esto se logra mediante la aplicación de políticas granulares basadas en identidad, contexto y riesgo, en lugar de confiar en una conexión de red de confianza implícita. Además, ZTNA ofrece una mayor visibilidad y control sobre quién accede a qué recursos, lo que facilita el cumplimiento normativo y la auditoría.

Otra ventaja clave de ZTNA es su capacidad para integrarse de manera transparente con aplicaciones en la nube y SaaS, lo que elimina la necesidad de enrutar todo el tráfico a través de una ubicación central. Esto no solo mejora el rendimiento y la experiencia del usuario, sino que también reduce la complejidad y los costos asociados con el mantenimiento de una infraestructura de red tradicional.

En un mundo donde la nube y el trabajo remoto son la norma, las empresas deben adoptar enfoques de seguridad modernos que se adapten a esta nueva realidad. Al abandonar las VPN obsoletas y adoptar ZTNA, las organizaciones pueden proteger mejor sus recursos críticos, reducir su superficie de ataque y mantenerse a la vanguardia en un entorno de amenazas en constante evolución.

Proteger mediante CloudFlare un sitio alojado en S3

Sergio Jiménez — Wed, 17 Jul 2024 09:22:17 +0000

Cuando creamos un sitio web, como por ejemplo una landing page estática, y queremos alojarla en un sitio rápido y rentable sin servidor, podemos utilizar directamente un bucket de aws s3.

Esta funcionalidad es bien conocida, pero por si acaso te dejo la propia documentación de aws dónde explica cómo hacerlo: aws hosting s3

En esa documentación se indica que directamente podremos hacer accesible el contenido del bucket de forma pública, adjuntando una politica tal que así:

CDN y WAF de Cloudflare

Si queremos añadir capacidades de CDN y WAF podríamos utilizar el servicio de CloudFront de AWS, o alguna alternativa como puede ser Cloudflare que nos permite también empezar con un nivel gratuito de protección para nuestro site, además de otras capacidades de protección en email y DNS.

El problema es que si alguien accede al bucket de s3 directamente, podrá acceder como un bypass sin la protección de Cloudflare. Es decir, en vez de acceder por el dominio protegido por Cloudflare www.example.com podría usar http://www.example.com.s3-website.eu-central-1.amazonaws.com que como tiene una politica de permitir todo es accesible igualmente.

¿Cómo podemos evitarlo?

Cloudflare publica una lista de Ips desde las que accede a los servicios:
IP List Cloudflare

Podemos crear una política que permita solo esas ip's para el acceso a S3 dando un 403 si no llamas desde cloudflare.

La política viene a sustituir a la anterior por defecto, y os dejo el código json para que podáis copiar y pegar:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFlareIP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:getObject",
            "Resource": [
                "arn:aws:s3:::Bucket-Name",
                "arn:aws:s3:::Bucket-Name/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "2c0f:f248::/32",
                        "2a06:98c0::/29",
                        "2803:f800::/32",
                        "2606:4700::/32",
                        "2405:b500::/32",
                        "2405:8100::/32",
                        "2400:cb00::/32",
                        "198.41.128.0/17",
                        "197.234.240.0/22",
                        "190.93.240.0/20",
                        "188.114.96.0/20",
                        "173.245.48.0/20",
                        "172.64.0.0/13",
                        "162.158.0.0/15",
                        "141.101.64.0/18",
                        "131.0.72.0/22",
                        "108.162.192.0/18",
                        "104.16.0.0/12",
                        "103.31.4.0/22",
                        "103.22.200.0/22",
                        "103.21.244.0/22"
                    ]
                }
            }
        }
    ]
}

Sustituid Bucket-Name por el nombre de vuestro bucket.

Esta es una forma sencilla de alojar y proteger un sitio estático ya de por sí tremendamente seguro y rápido. Añadiendo capacidad de CDN y WAF haremos que nuestro site literalmente vuele.

Espero que haya sido útil, y nos vemos en otros post.

AWS Config para análisis de seguridad

Sergio Jiménez — Tue, 20 Feb 2024 09:34:24 +0000

AWS Config puede ayudarte a alcanzar los siguientes objetivos de gobierno de seguridad:

Definir reglas de seguridad y requisitos de cumplimiento
Monitorear la infraestructura en función de las reglas y requisitos
Detectar violaciones de cumplimiento
Actuar rápidamente sobre las violaciones mediante la automatización.

AWS Config funciona con reglas personalizadas o predefinidas por Amazon.

A continuación podeís encontrar las Managed Rules: disponibles: https://docs.amazonaws.cn/en_us/config/latest/developerguide/managed-rules-by-aws-config.html

Funciona de la siguiente manera:

Cada regla está asociada a una función de AWS Lambda, que contiene la lógica de evaluación de la regla. Cuando AWS Config evalúa sus recursos, invoca la función de AWS Lambda de la regla, que devuelve el estado de conformidad de los recursos evaluados. Si un recurso infringe las condiciones de una regla, AWS Config marca el recurso y la regla como no conformes. Cuando cambia el estado de conformidad de un recurso, puede implementar opcionalmente una regla de corrección automatizada o utilizar una notificación SNS para otros tipos de automatización.

La remediación automática es una de las formas más efectivas de mantener nuestro entorno conforme al cumplimiento establecido en las reglas.

AWS Config dispone de un Dashboard dónde podremos monitorizar el estado de conformidad de nuestros recursos.

Decisiones informadas basadas en los datos 🎬 Serie: ⚡ Cloud Superpower ⚡ 2.06

Sergio Jiménez — Tue, 06 Feb 2024 10:57:48 +0000

Diría que hay muchas opciones actualmente y es difícil escoger una de entrada.

La misión de Cloud Superpower, es facilitarte la vida, así que voy a presentar una opción que a mí me gusta particularmente por su potencia y sencillez.

Cada día los equipos deben tomar decisiones basadas en datos.
Disponer de herramientas que permitan visualizar los datos se ha convertido en algo indispensable en las organizaciones.

Para esta tarea Amazon cuenta con su producto QuickSight que permite que los equipos puedan comprender los datos realizando preguntas en lenguaje natural y mediante la exploración de paneles (Dashboards).

Las tripas de QuicksSight si nos ponemos un poco más técnicos, funcionan con SPICE (Super-fast, Parallel, in-memory Calculation Engine), permitiendo escalar a cientos de miles de usuarios.

La inteligencia empresarial (BI), se convierte en algo trivial gracias al motor de Q con tecnología de ML, que facilita la visualización de datos y el ahorro de tiempo en prepararlos para su consumo.

También es posible generar pronósticos precisos y fáciles de comprender.

QuickSight permite agregar datos a escala de diferentes nubes y varias fuentes sin necesidad de administrar servidores (Serverless).

¿Qué fuentes de datos permite Quicksight?

• Redshift
• Aurora / RDS
• Archivos S3 o locales (Excel, CSV, TSV, logs)

Seguridad:

Además, los datos se cifran en reposo y ofrece una seguridad y control granular de acceso, haciendo fácil la conformidad con diferentes regulaciones como HIPAA, PCI, ISO 27001, etc…
Y si esto te parece poco, también permite conectividad a nivel de VPC privada y DirectConnect.

¿Para qué uso yo QuickSight?

Pues para crear paneles de Cost Intelligence multi-cloud.
Básicamente lo que hago es exportar los datos del CUR y las consolas de billing de diferentes proveedores, de forma que pueda generar vistas personalizadas en QuickSight.

Si alguien está interesadom aquí hay un enlace dónde se pueden encontrar diferentes implementaciones: https://wellarchitectedlabs.com/cloud-intelligence-dashboards/

Cloud Superpower⚡ Recap

Sergio Jiménez — Wed, 31 Jan 2024 11:27:49 +0000

Empezamos a escribir hace ya unos meses y quería tomar notas para lo que tenga que venir sin olvidar de dónde venimos.

A continuación voy a listar los enlaces a los diferentes post de la serie Cloud Superpower:

Temporada 1:

Ep1: Root accounts con la cuenta no cuenta #aws

Ep2: Cómo dejar de malgastar dinero en la nube 💸 y contratarme con lo que te ahorres #finops

Ep3: Aurora no es la prima de Alexa #aws #aurora

Ep4: Kubernetes el nuevo old school #aws #kubernetes

Ep5: Ventajas del Cloud frente a un ataque de tipo Ransomware #aws #security

Ep6: Almacenamiento en la nube para tu entorno local #aws #storage

Ep7: Cómo tener HA en tu BD y no morir en el intento #aws #ha #database

Ep8: La nube como entorno de recuperación ante desastres #aws #rdp

Ep9: Explorando AWS Saving Plans #aws #savingplans

Ep10: ¡Ventajas para tu Pyme con estos Cloud Superpowers! #cloud #pymes

Ep11: Estandarización y homologación dentro de los departamentos de IT #wellarchitected

Ep12: FinOps integrado en Terraform #finops

Ep13: Security integrada en Terraform #security #terraform

Temporada 2:

Ep1: Cloud Billing Attack - Cuentas robadas de AWS 😈 #security #aws

Ep2: Migrar o no migrar - Coste vs Beneficio Cloud vs OnPrem #finops #costoptimization

Ep3: 🚨 Prowler la tool de cloud security que necesitas probar ya! #security #cloud

Ep4: Recopilación de AWS networking Tips #aws #networking

Ep5: 🌪 AWS EC2 vs Hetzner Dedicated Server #cloud #onprem

AWS EC2 vs Hetzner Dedicated Server 🎬 Serie:⚡ Cloud Superpower⚡ 2.05

Sergio Jiménez — Fri, 26 Jan 2024 20:45:52 +0000

Comparativa basada en un ejercicio real, y enumerando pros y contras.

Enunciado:

Hetzner es un proveedor aleman lowcost con diferentes ofertas de hosting, vps y servidores dedicados (hierro).

AWS Es un proveedor global de cloud que precisamente no compite en precio, pero si en prestaciones.

Con calculadora en mano Hetzner se lleva la palma, si solo comparamos cpu, ram, y disco. Se terminó la comparativa.

Siempre asumimos la calculadora de AWS comparando desde un escenario dónde hay un entorno Onprem empresarial a migrar y dónde existe una inversión y amortización a medio plazo. Gastos de electricidad y mantenimiento, pero Hetzner es pago mensual sin compromisos.

Vamos a comparar el Servidor Dedicado:
https://www.hetzner.com/dedicated-rootserver/dx182/configurator/#/

AMD EPYC™ 9454P 48-Core
128 GB DDR5 ECC
2x 1.92 TB NVMe SSD Datacenter Edition
Ubicación: Finlandia o Alemania
Total: 370 €/mes impuestos incluidos (+90 euros setup 1 vez).
Precio sin competencia

Empieza la comparativa

Ahora vamos a buscar la alternativa en AWS, y ver con que argumentos podemos competir.

En Hetzner tenemos 2 discos de 1.92 TB, pero al configurar un RAID1 no tendremos 4 TB disponibles si no la mitad.
Partimos de la base que este servidor físico instalaremos un hypervisor, para disponer de capacidades de virtualización.
Usaremos KVM/Proxmox o cualquier solución opensource para no añadir en la ecuación precios de licencias.
El servidor esta ubicado en una sola región. No hay tolerancia a fallos ni de hardware ni de localización.
No tenemos mecanismo de backup.

Entonces en la calculadora de AWS necesitaremos cotizar 2 TB de EBS ssd y las EC2 instances hasta completar los 128 Gb de RAM y los 48 cpu. Para simplificar el ejercicio vamos a particionar ese supuesto entorno de virtualización de Hetzner en instancias de EC2.

Partiendo en 8 partes iguales, dispondremos de instancias EC2 con 6vCPU, 16 Gb RAM, EBS 256 Gb cada una, que suman 128 Gb RAM, 48 Cores, 2TB de Hetzner.

(Estamos siendo generosos, porque estamos asumiendo que el 100% de los recursos en Hetzner serán utiles, pero seguro que un 20% se los va a comer el hypervisor, ... pero es igual).

La instancia más cercana a esa configuración podría ser:
c6gd.2xlarge 8vCPU, 16Gb RAM, 474 SSD en 104,43 EUR/mes reserva 3 años x 8 = 835 €

(Fuente: https://instances.vantage.sh/aws/ec2/c6gd.2xlarge?filter=c6gd.2xlarge%7Cc6g.2xlarge&region=eu-central-1&cost_duration=monthly&reserved_term=Standard.noUpfront&compare_on=true&selected=c6gd.2xlarge%2Cc6g.2xlarge&os=linux)

Resultado de las estimaciones:
AWS Capacidad de computo total: 64 vCPU, 128 RAM, 3,7 TB SSD NVMe
vs
Hetzner Capacidad de computo total: 48 CPU, 128 RAM, 2 TB SSD NVMe

En AWS tenemos

85% más de disco
33% más de CPU
Misma RAM
125% más caro

AWS 835€ reservando a 3 años vs Hetzner 370€ sin compromiso.

¿Porque pagar 125% más?

Argumentos a favor:

Tendremos más recursos en general.
Podemos distribuirlos en diferentes AZ (mayor tolerancia a fallos)
Dispondremos de mecanismo de snapshot y recuperación en otra region (menor tiempo de recuperación ante desastres).
No perdemos recursos de computo por el hypervisor
No tenemos que instalar (horas hombre) ni mantener el hypervisor (horas hombre y gestión de vulnerabilidades).
Si necesito más recursos en el futuro incrementará en las unidades necesarias, y si en algún momento dispongo de menos demanda podré ajustar los recursos.

Argumentos en contra:

Pagar 125% más en proyectos de corta duración, pilotos, sandbox, no se justifica.
En entornos no-productivos no necesito resiliencia ni redundancia.
Podría pagar 2 servidores en Hetzner y todavía pagaría un 25% menos.

Conclusión:
Si queremos capacidades de entornos empresariales productivos, los argumentos a favor pueden ser argumentos suficientes para justificar el incremento de precio.

Si nuestro proyecto es un piloto o entorno no productivo el incremento de precio no se justifica.

¿Que opinas?
¿Que estimaciones o cálculos harías tu?

¿Hay alguna forma de conseguir bajar el precio en AWS?
Podemos usar instancias Spot y en algunos casos conseguiremos precios cercanos a Hetzner, pero este tipo de instancias no es adecuado para todo tipo de usos.

Podríamos asumir la perdida de recursos de hypervisor en Hetzner y ajustar el tamaño de las EC2.
O analizar el porcentaje de uso de recursos, los periodos picos y valles, saber si el cliente que contrata ese servidor en Hetzner lo tendra 99% del tiempo idle como suele pasar, o sobre dimensionado, lo que ayudaría a ajustar el tamaño en las EC2. Aunque sinceramente no llegaremos nunca a precios de Hetzner y Hetzner no podrá igualar las prestaciones de AWS.

¿Entonces AWS no sirve para entornos de sandbox o pilotos?
Si podemos ajustar los recursos de computo en entornos no productivos a la mínima expresión si, si nuestro piloto necesita alta demanda de recursos. No veo la forma.

¿Sirve Hetzner para entornos productivos?
Pues francamente opino que no. Carece de de los mínimos requisitos que debes plantearte a la hora de dar un servicio con un SLA.

¿Te digo un secreto?

No estamos comparando lo mismo.
AWS no es CPU, RAM y disco, es un ecosistema empresarial:

Gestión de identidades (IAM).
Servicios administrados PaaS (Bases de datos, Kubernetes, Lambda, Backup, IA, Data Analitycs, Arquitecturas basadas en eventos).
Herramientas de CI/CD, repositorios GIT.
Soporte para (Infraestructura como Código) IaC
Seguridad avanzada (Control Policies, Cumplimiento, gestión de secretos, identidades, Auditoria (CloudTrail), Monitorización (CloudWatch), Gestión de configuración (AWS Config), Recomendador de seguridad (Trusted Advisor), Threat Intelligence (GuardDuty), Firewall, WAF..., Gestión de configuración y acceso seguro (AWS System Manager).

Y ahora, aún piensas que AWS es solo CPU, RAM y DISCO?
Al escoger un proveedor lowcost como Hetzner estas renunciando a todo lo anterior y eso obviamente tiene un precio menor. Nadie regala duros a cuatro pesetas.

Tenlo en cuenta, todo tiene un precio, y hay servicios y prestaciones de las que dispones en AWS (o en un cloud provider de primer nivel), que no dispones en un proveedor de hosting de tercera regional, por muy bien que funcione.

Por cierto, AWS dispone de diferentes programas de descuentos y créditos para sandbox, y pruebas de concepto. ¡Informate con tu partner local!

Y ya para otro ejercicio:

Pruebas de rendimiento

Spoiler: El rendimiento en vm sobre ese entorno en Hetzner, se verá penalizado por la carga del servidor, y aún cuando el entorno este bien de carga, penalizará en rendimiento, IOPS, latencia, etc etc.... ¿Apuestas?

AWS networking Tips 🎬 Serie: ⚡ Cloud Superpower ⚡ 2.04

Sergio Jiménez — Mon, 22 Jan 2024 12:33:39 +0000

Lo prometido es deuda! A petición popular, hoy os voy a dar algunos tips a la hora de configurar nuestras VPC en AWS.

Configurar la red siempre es una tarea particularmente compleja y que requiere un estudio sobre los requisitos de cada proyecto y organización, pero a nivel general me he permitido recopilar estos tips para vosotros.

Nota del autor: Voy a ir actualizando este post a medida que vaya recopilando nuevos tips. Considera esta la version 1.0

Vamos a ir enumerando y desarrollando algunos de ellos.
Partimos de un escenario de AWS Multi-cuenta, ya que es el más extendido a nivel empresarial. No tiene mucho sentido algunos de ellos en un entorno Single-account o sandbox.

✅ 1. Tamaño de las VPC, número de subnets:

A la hora de planificar una red primero debemos escoger el tamaño CIDR de nuestra red, para eso debemos escoger un tamaño que nos permita crecer y para eso debemos conocer que esperamos colocar en ella. Igualmente no te martirices con este punto, siempre puedes agregar bloques CIDR adicionales.

Yo uso https://visualsubnetcalc.com/ para calcular los rangos y hacer las subdivisiones.

A la hora de definir las subnets, es importante aprovechar las AZ's para repartir tus workloads y hacerlas más robustas.

Lo que sí hago es reservarme un rango para cada cloud provider y redes on-prem que pueda tener en nuestra organización, de forma que evitemos a toda costa el solapamiento IP. (gestionar solapamiento ip me parece un drama y es evitable con planificación). Cuando digo drama, me refiero a conjunto de chapuzas de mitigación de solapamiento. Así que mejor prevenir que curar, recuerda esto!

✅ 2. Centraliza la gestión de la red:

Mi tip preferido es usar VPC Sharing para centralizar la gestión de la red, de las cuentas que las consumen. A nivel de seguridad es muy buena idea.

Esta función permite crear las VPC en una cuenta de Networking y compartir esas redes con cuentas miembros de una misma AWS Organization (cuentas consumidoras de la VPC).

Siguiendo con esta idea de centralizar, también puedes centralizar el Egress de nuestra red con NAT Gateway y es un punto a considerar.

✅ 3. Diagrama tu red
Dibuja lo que quieres hacer, te va a permitir tener una visión global y conceptual de la topología de la red y será más fácil detectar y evolucionar tu configuración.

Es un tip muy básico, pero os lo dejo porque para mi es importante, sin diagrama no salgo de casa 😅 , y existen muchas herramientas para diagramar tu red yo uso draw.io

✅ 4. Privatiza el acceso con VPC Endpoints

Consumir servicios como s3 sin private Link, significa salir a internet (estrictamente solo vamos hasta el backbone de AWS, pero con direccionamiento público para mi eso es internet). y es algo controvertido, si estamos consumiendo el resto de servicios dentro de una subnet. Por eso VPC Endpoints es la forma de consumir esos servicios de AWS con un direccionamiento privado.

✅ 5. Evita el uso de Public IPs

Es otro tip básico. No solamente por la escasez de IPv4, si no por que estaremos aumentando nuestra superficie de exposición.
Hay servicios como AWS SSM que permite conectarnos a las EC2 directamente sin IP pública, es una buena práctica de seguridad.

También existen las VPC IPv6 cada vez más soportadas y que no tienen coste como IPv4, recuerda que ahora AWS cobra por cada IP pública que utilices, así que evitar y optimizar su uso, también ahorra dinero.

✅ 6. Monitoriza el tráfico de red con VPC Flow Logs

Para hacer troubleshooting, es importante habilitar el log de tráfico IP, además puedes combinarlo con CloudWatch para consultarlos y filtrarlos.
También puede ser requerido por alguna norma de cumplimiento que debamos seguir en nuestra compañia.

✅ 7. Evita el uso de host bastiones
O también conocidos como máquinas de salto. Son un riesgo para la seguridad, y al igual que en el tip 5, puedes usar AWS SSM sin necesidad de usar un host bastion. Son demasiado old-school para la nube.

✅ 8. Evalúa usar AWS Transit Gateway
Muchas veces una VPC necesita acceder a otra, y para ello tradicionalmente se ha usado VPC Peering, para intercambiar tráfico entre dos VPC. Es una solución económica pero que escala francamente mal.

Transit gateway viene a resolver esto, y aunque a priori es una solución más cara, creo que resuelve mucho la gestión de la red, por eso yo recomiendo su uso en entornos empresariales.

¡Gracias por llegar hasta aquí!

Bien por ahora estos son los tips más frecuentes que yo utilizo y puedo compartir contigo.

¿Los conocías? ¿Que opinas? ¿Quieres compartir alguno que no has visto aquí? Dejalo en los comentarios.