Despliega una Infraestructura de Red AWS Robusta con Terraform

En este post, aprenderás a crear una arquitectura de red multinivel y de alta disponibilidad (multi-AZ) utilizando VPC en AWS con Terraform (Infraestructura como Código).

Escenario del Proyecto

La compañia BuyTech opera una plataforma de comercio electrónico de alto tráfico en AWS. La aplicación es crítica para los ingresos de la empresa, y la arquitectura debe abordar los requisitos de red específicos para los niveles web, de aplicación o backend, y de base de datos. La compañía gestiona una plataforma de comercio electrónico a gran escala, que maneja pedidos de clientes, administración de catálogos de productos y procesamiento de pagos.

El Director de Tecnología (CTO) te ha proporcionado una lista de requisitos que, como cloud engineer/devops, debes considerar cuidadosamente para construir una VPC multinivel y de alta disponibilidad para satisfacer las necesidades de la aplicación de la empresa. El diseño de la VPC debe permitir una gestión eficiente del tráfico y el flujo de datos, cumpliendo con los requisitos de red únicos de cada nivel.

Existe la necesidad de una configuración sencilla y la replicación de los mismos componentes de red; por lo tanto, deberás utilizar Infraestructura como Código (IaC) para desplegar la infraestructura de red.

Necesidades de BuyTech

• La alta disponibilidad es un requisito crítico para garantizar que la plataforma de comercio electrónico esté siempre accesible para los clientes sin interrupciones.
• La aplicación contiene información sensible de los clientes, y la seguridad de los datos es una prioridad máxima.
• La plataforma experimenta patrones de tráfico variables, con picos durante eventos de ventas y vacaciones.

Nivel Web (Subred Pública)

• El nivel web aloja los componentes frontend de la plataforma de comercio electrónico, incluyendo el catálogo de productos, la autenticación de usuarios y el procesamiento de pedidos.
• Este nivel requiere accesibilidad desde Internet público para servir páginas web a los usuarios.
• El nivel web se implementa en dos Zonas de Disponibilidad (AZ) para alta disponibilidad.
• Las subredes públicas en cada AZ están configuradas para permitir el tráfico de entrada y salida de Internet. Una puerta de enlace de Internet habilita la comunicación con Internet.

Nivel de Aplicación o Backend (Subred Privada)

• El nivel de Aplicación/Backend aloja la lógica de la aplicación, los motores de procesamiento de pedidos y otros servicios backend.
• Este nivel no necesita acceso directo desde Internet público, pero debe ser accesible desde el nivel web.
• Implementado en dos Zonas de Disponibilidad, las subredes privadas en cada AZ alojan los servidores backend.
• Los grupos de seguridad están configurados para permitir el tráfico de entrada desde el nivel web, mientras que el acceso a Internet de salida permanece deshabilitado.

Nivel de Base de Datos (Subred Protegida)

• El nivel de base de datos almacena datos de clientes, información de productos y registros de transacciones. Es el nivel más sensible y vulnerable de la aplicación.
• Las bases de datos no deben ser directamente accesibles desde Internet público o el nivel web, pero deben ser accesibles desde el nivel de Aplicación o Backend para el procesamiento de datos.
• Implementado en dos Zonas de Disponibilidad, las subredes protegidas en cada AZ alojan los servidores de bases de datos.
• El acceso de entrada desde Internet está completamente deshabilitado en estas subredes, y solo el nivel de Aplicación/Backend tiene permiso de acceso al nivel de Base de Datos.

Alta Disponibilidad (HA) y Escalabilidad

• La implementación de cada nivel en dos Zonas de Disponibilidad (AZ) proporciona alta disponibilidad. Si una AZ experimenta problemas, la otra AZ puede manejar el tráfico entrante.
• El Auto Scaling y los balanceadores de carga se pueden integrar en el nivel web para manejar patrones de tráfico variables, asegurando que la plataforma se escale hacia arriba o hacia abajo según la demanda (no construiremos ni lanzaremos ninguna instancia en este taller).

Políticas de Enrutamiento y Seguridad Personalizables

• Las tablas de enrutamiento están configuradas para controlar el flujo de tráfico entre diferentes subredes según los requisitos de la empresa.
• Los grupos de seguridad y las ACL de red están finamente ajustados para controlar el acceso entre niveles, asegurando que solo se permita la comunicación necesaria mientras se mantiene un entorno seguro.

En este proceso se va a requerir los archivos de terraform:

# Ubicarse en el folder de estos archivos
# para realizar el terraform flow
provider.tf
main.tf
01-vpc.tf

provider.tf

terraform { required_version = ">= 1.2.0" required_providers { aws = { source = "hashicorp/aws" version = ">= 4.9" # verifiy version on https://registry.terraform.io/providers/hashicorp/aws/latest } }
} provider "aws" { profile = "demo-aws" # cambiar por el profile correspondiente
}

main.tf

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}
data "aws_availability_zones" "available" {}
data "aws_subnets" "public" {} locals { aws_account_id = data.aws_caller_identity.current.account_id aws_region = data.aws_region.current.name
}

01-vpc.tf

module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "5.1.1" name = "vpc-buytech-demo" cidr = "172.16.0.0/16" azs = slice(data.aws_availability_zones.available.names, 0, 2) private_subnets = ["172.16.0.0/24", "172.16.1.0/24"] public_subnets = ["172.16.2.0/24", "172.16.3.0/24"] database_subnets = ["172.16.4.0/24", "172.16.5.0/24"] enable_nat_gateway = true single_nat_gateway = false enable_dns_hostnames = true map_public_ip_on_launch = true public_subnet_tags = { BuyTech-public-sb = "public-subnet" } private_subnet_tags = { BuyTech-private-sb = "private-subnet" }
}

ℹ️ Resumen del Módulo VPC Terraform

Este código Terraform utiliza el módulo “terraform-aws-modules/vpc/aws” para crear una VPC en AWS.

⚙️ Configuración del Módulo:

• Nombre: La VPC se nombra “vpc-buytech-demo”.
• CIDR: La VPC utiliza el rango de direcciones IP 172.16.0.0/16.
• Zonas de Disponibilidad: Se utilizan las primeras dos zonas de disponibilidad disponibles en la región.
• Subredes Privadas: Se definen subredes privadas en los rangos 172.16.0.0/24 y 172.16.1.0/24.
• Subredes Públicas: Se definen subredes públicas en los rangos 172.16.2.0/24 y 172.16.3.0/24.
• Subredes de Base de Datos: Se definen subredes para bases de datos en los rangos 172.16.4.0/24 y 172.16.5.0/24.
• Habilitar Puerta de Enlace NAT: Se habilita la puerta de enlace NAT para permitir que las instancias privadas accedan a Internet.
• Puerta de Enlace NAT Única: No se utiliza una única puerta de enlace NAT para todas las subredes privadas.
• Habilitar Nombres de DNS: Se habilitan los nombres de host de DNS para las instancias de la VPC.
• Mapeo de IP Pública en Lanzamiento: Se asignan direcciones IP públicas a instancias lanzadas en subredes públicas.

🏷️ Etiquetas de Subred:

• Se asignan etiquetas a las subredes públicas y privadas para facilitar su identificación.

Este código proporciona una configuración básica para crear una VPC en AWS con subredes públicas y privadas.

Ahora que estamos ubicado en el folder de los archivos terraform, se tiene el siguiente workflow:

1. init:

   • Inicializa el directorio de trabajo.
   • Descarga y configura los proveedores.
   • Crea un archivo de estado inicial.

2. validate:

   • Verifica la sintaxis y validez de los archivos.
   • Detecta errores y problemas potenciales.

3. plan:

   • Genera un plan detallado de los cambios.
   • Muestra los recursos a crear, modificar o eliminar.
   • Proporciona una estimación de los cambios.

4. apply:

   • Aplica los cambios planificados en la infraestructura.
   • Crea, modifica o elimina recursos según el plan.
   • Actualiza el archivo de estado.

Nota:
Se puede adicionar un paso adicional usando infracost para ver el costo de la creación de los recursos:

──────────────────────────────────
30 cloud resources were detected:
∙ 4 were estimated
∙ 26 were free

En resumen, el código proporciona una configuración básica de un VPC de alta disponibilidad en dos zonas de disponibilidad. Sin embargo, esta configuración puede mejorarse agregando monitoreo, listas de control de acceso de red (NACL), y otras características según las necesidades específicas del proyecto. Además, gracias a la modularidad y flexibilidad de Terraform, esta configuración puede desplegarse fácilmente en múltiples cuentas de AWS o regiones para adaptarse a diferentes entornos y escenarios de implementación.