18/11/2024 / Última actualización : 03/01/2025 Israel AWS

Auto Scaling Group en AWS usando Terraform

Hello World 🙂

En el artículo anterior, exploramos los diferentes tipos de balanceadores de carga que AWS ofrece, destacando a Elastic Load Balancing (ELB) como uno de los servicios más utilizados. También vimos algunas características específicas de cada tipo de balanceador e implementamos un ejemplo práctico creando un Application Load Balancer (ALB) con Terraform. Pudimos acceder al ALB desde un navegador y observar cómo distribuía el tráfico entre distintas instancias EC2, una solución muy común en muchas empresas.

En esta entrada, continuando con el tema, aprenderemos cómo configurar un Auto Scaling Group (ASG) y asignarle un ALB. Este caso de uso aporta mayor robustez a nuestra infraestructura, permitiéndonos aprovechar las ventajas del ASG, como la capacidad de reemplazar instancias no saludables automáticamente y de escalar o desescalar la cantidad de instancias en función de métricas como el uso de CPU. Así, aseguramos que el servicio esté siempre disponible sin degradaciones.

Pero primero vamos a definir que es un Auto Scaling Group (ASG), según la documentación de AWS;

Amazon EC2 Auto Scaling lo ayuda a asegurarse de tener la cantidad correcta de instancias EC2 disponibles para manejar la carga de su aplicación.

Al igual que en la entrada anterior, usaremos Terraform para implementar estos recursos, ya que es una forma fácil y eficiente de gestionar nuestra infraestructura, también nos permite replicar entre distintas regiones y cuentas, si es necesario.

Requisitos

  • Tener una cuenta de AWS.
  • Tener instalado Terraform.

El proyecto estará organizado en una única carpeta, dentro de la cual definiremos todos los archivos de Terraform necesarios para crear los recursos.

1- Primero necesitamos exportar nuestras credenciales de AWS en nuestra consola local;

  • export AWS_ACCESS_KEY_ID="XXXXXXXXXX"
    export AWS_SECRET_ACCESS_KEY="XXXXXXXXXX"
  • Comprobamos que estemos conectados de forma correcta
    • aws sts get-caller-identity

2- En el archivo 0-provider.tf, definiremos los proveedores que utilizaremos en este proyecto. Estos proveedores son esenciales, ya que permiten a Terraform interactuar con los distintos servicios de infraestructura en la nube necesarios para desplegar los recursos correctamente.

  • provider "aws" {
      region = local.region
      default_tags {
        tags = local.tags
      }
    }
    terraform {
      required_version = ">= 1.0"
      required_providers {
        aws = {
          source  = "hashicorp/aws"
          version = ">= 4.47"
        }
      }
    }

3- En el archivo 1-locals.tf, definiremos las variables locales del proyecto. Estas variables ayudan a centralizar valores que se utilizarán en múltiples recursos, simplificando la configuración y facilitando el mantenimiento del código.

  • locals {
      region  = "us-west-1"
      tags    = {
        Environment   = "POC",
        Terraform     ="True"
      }
    }

4- En el archivo 2-vpc.tf, definiremos todo lo necesario para crear nuestra VPC, que servirá como la base de la infraestructura del proyecto. Aquí, definiremos subredes y demás componentes claves que permitirán una red segura y eficiente para los recursos que desplegaremos más adelante.

  • module "vpc" {
      source  = "terraform-aws-modules/vpc/aws"
      name = "demo-vpc"
      cidr = "10.0.0.0/16"
      azs             = ["us-west-1a", "us-west-1b"]
      private_subnets = ["10.0.0.0/19", "10.0.32.0/19"]
      public_subnets  = ["10.0.64.0/19", "10.0.96.0/19"]
      enable_dns_hostnames = true
      enable_dns_support   = true
      enable_nat_gateway     = true
      single_nat_gateway     = true
      one_nat_gateway_per_az = false
    }

5- En el archivo 3-alb.tf, configuraremos todos los elementos necesarios para crear el Application Load Balancer (ALB), el cual luego se asociará con el Auto Scaling Group (ASG) para manejar el tráfico de manera eficiente. También definiremos el Target Group y el Listener, esenciales para el correcto funcionamiento del balanceador, permitiendo así una distribución de carga óptima entre las instancias y asegurando alta disponibilidad para nuestra aplicación.

  • resource "aws_lb" "demo_lb" {
      load_balancer_type        = "application"
      name                      = "demo-alb"
      security_groups           = [aws_security_group.alb_sg.id]
      subnets                   = module.vpc.public_subnets
    }
    resource "aws_lb_target_group" "demo" {
      name     = "demo-alb-target-group"
      port     = 80
      vpc_id   = module.vpc.vpc_id
      protocol = "HTTP"
      health_check {
        enabled   = true
        matcher  = "200"
        path     ="/"
        port     = var.puerto_servidor
        protocol = "HTTP"
      }
    }
    resource "aws_lb_listener" "this" {
      load_balancer_arn = aws_lb.demo_lb.arn
      port              = var.puerto_lb
      protocol          = "HTTP"
      default_action {
        target_group_arn = aws_lb_target_group.demo.arn
        type             = "forward"
      }
    }

6- En el archivo 4-asg.tf, configuraremos todos los elementos necesarios para crear el Auto Scaling Group (ASG), asegurando que nuestras instancias se ajusten automáticamente según la demanda. Además, vincularemos el ASG con el Application Load Balancer (ALB) para distribuir eficientemente el tráfico entre las instancias. En esta demo, configuraremos el Auto Scaling Group (ASG) con una capacidad deseada de 2 instancias, asegurando una base operativa mínima. Estableceremos un límite inferior de 1 instancia para garantizar disponibilidad mínima y un máximo de 5 instancias para manejar picos de demanda, optimizando así tanto el rendimiento como los costos.

  • resource "aws_autoscaling_group" "demo" {
      name                      = "Demo-ASG"
      vpc_zone_identifier = module.vpc.private_subnets
      desired_capacity   = 2
      min_size           = 2
      max_size           = 5
      launch_template {
        id      = aws_launch_template.demo_launch_template.id
        version = "$Latest"
      }
      tag {
        key                 = "Name"
        value               = "Demo"
        propagate_at_launch = true
      }
      tag {
        key                 = "Environment"
        value               = "POC"
        propagate_at_launch = true
      }
    }
    resource "aws_autoscaling_attachment" "example" {
      autoscaling_group_name = aws_autoscaling_group.demo.id
      lb_target_group_arn    = aws_lb_target_group.demo.arn
    }

7- En el archivo 4.1-asg_notification.tf, configuraremos todo lo necesario para recibir notificaciones cuando el Auto Scaling Group (ASG) lance o termine una instancia. Estas notificaciones son esenciales para mantener el monitoreo en tiempo real de los cambios en la infraestructura, permitiendo que el equipo esté informado de cada ajuste automático en el número de instancias y pueda responder rápidamente a cualquier situación inesperada.

  • resource "aws_autoscaling_notification" "asg_notifications" {
      group_names = [
        aws_autoscaling_group.demo.name
      ]
      notifications = [
        "autoscaling:EC2_INSTANCE_LAUNCH",
        "autoscaling:EC2_INSTANCE_TERMINATE",
        "autoscaling:EC2_INSTANCE_LAUNCH_ERROR",
        "autoscaling:EC2_INSTANCE_TERMINATE_ERROR",
      ]
      topic_arn = aws_sns_topic.topic_sns.arn
    }

8- En el archivo 4.2-asg_policy.tf, configuraremos las políticas necesarias para el escalado automático del Auto Scaling Group (ASG). Estas políticas permitirán que el ASG aumente o reduzca la cantidad de instancias EC2 según los umbrales de utilización de CPU que definamos. De esta manera, el sistema podrá responder dinámicamente a cambios en la carga de trabajo, garantizando que haya suficientes recursos en momentos de alta demanda y optimizando los costos al reducir instancias cuando la carga disminuya.

  • resource "aws_autoscaling_policy" "asg_policy_up" {
      name = "asg_policy_up"
      scaling_adjustment = 1
      adjustment_type = "ChangeInCapacity"
      cooldown = 120
      autoscaling_group_name = aws_autoscaling_group.demo.name
    }
    resource "aws_cloudwatch_metric_alarm" "asg_high_cpu" {
      alarm_name = "asg_high_cpu"
      comparison_operator = "GreaterThanOrEqualToThreshold"
      evaluation_periods = "1"
      metric_name = "CPUUtilization"
      namespace = "AWS/EC2"
      period = "60"
      statistic = "Average"
      threshold = "70"
    dimensions = {
        AutoScalingGroupName = aws_autoscaling_group.demo.name
      }
    alarm_description = "This metric monitor EC2 instance CPU utilization"
      alarm_actions = [aws_autoscaling_policy.asg_policy_up.arn, aws_sns_topic.topic_sns.arn]
    }
  • resource "aws_autoscaling_policy" "asg_policy_down" {
      name = "asg_policy_down"
      scaling_adjustment = -1
      adjustment_type = "ChangeInCapacity"
      cooldown = 120
      autoscaling_group_name = aws_autoscaling_group.demo.name
    }
    resource "aws_cloudwatch_metric_alarm" "asg_low_cpu" {
      alarm_name = "asg_low_cpu"
      comparison_operator = "LessThanOrEqualToThreshold"
      evaluation_periods = "1"
      metric_name = "CPUUtilization"
      namespace = "AWS/EC2"
      period = "60"
      statistic = "Average"
      threshold = "30"
    dimensions = {
        AutoScalingGroupName = aws_autoscaling_group.demo.name
      }
    alarm_description = "This metric monitor EC2 instance CPU utilization"
      alarm_actions = [aws_autoscaling_policy.asg_policy_down.arn, aws_sns_topic.topic_sns.arn]
    }

9- En el archivo 4.3-asg_schedule.tf, configuraremos cron job para el Auto Scaling Group (ASG) . Este configuración permitirá agregar o eliminar instancias EC2 en horarios específicos. Este enfoque es especialmente útil en entornos de desarrollo o prueba, donde las instancias solo necesitan estar disponibles durante el horario laboral, ayudando así a reducir costos al mantenerlas apagadas fuera de este horario.

  • resource "aws_autoscaling_schedule" "demo_asg_schedule_stop" {
      scheduled_action_name  = "demo-asg-schedule-stop"
      min_size               = 0
      max_size               = 0
      desired_capacity       = 0
      recurrence             = "0 20 * * 1-5"  # De lunes a viernes a las 20:00 (hora UTC)
      autoscaling_group_name = aws_autoscaling_group.demo.name
    }
    resource "aws_autoscaling_schedule" "demo_asg_schedule_start" {
      scheduled_action_name  = "demo-asg-schedule-start"
      min_size               = 1
      max_size               = 2
      desired_capacity       = 1
      recurrence             = "0 6 * * 1-5"  # De lunes a viernes a las 06:00 (hora UTC)
      autoscaling_group_name = aws_autoscaling_group.demo.name
    }

10- En el archivo 5-lt.tf, configuraremos todos los recursos necesarios para crear nuestro Launch Template. Aquí especificaremos las configuraciones que tendrán las instancias EC2 cuando sean lanzadas por el Auto Scaling Group (ASG). Este Launch Template permite estandarizar y automatizar el aprovisionamiento de instancias, asegurando que cada una esté lista con las configuraciones necesarias.

  • resource "aws_launch_template" "demo_launch_template" {
      name          = "demo-launch-template"
      image_id      = data.aws_ami.ubuntu.id
      instance_type = var.instance_type
      key_name      = aws_key_pair.terraform_demo.id
      vpc_security_group_ids      = [aws_security_group.ec2_sg.id]
      iam_instance_profile {
        name = "${aws_iam_instance_profile.demo_profile.name}"
      }
      block_device_mappings {
        device_name = "/dev/sda1"
        ebs {
          volume_size = 20
          volume_type = "gp3"
        }
      }
      block_device_mappings {
        device_name = "/dev/sdb"
        ebs {
          volume_size = 20
          volume_type = "gp3"
        }
      }
      user_data = base64encode(<<-EOF
      #!/bin/bash
      echo "*** Installing apache2"
      sudo apt update -y
      sudo apt install apache2 -y
      echo "*** Completed Installing apache2"
      echo "*** Starting apache2"
      sudo systemctl start apache2
      echo "*** Enable apache2"
      sudo systemctl enable apache2
      echo "*** Edit file index.html"
      echo "<h1>Hello world from $(hostname -f)</h1>" | sudo tee /var/www/html/index.html
      EOF
      )
      lifecycle {
        create_before_destroy = true
      }
       monitoring {
        enabled = true
      }
      tag_specifications {
        resource_type = "instance"
        tags = {
          Name = "Demo"
          Environment   = "POC",
          Terraform     = "True"
        }
      }
      tag_specifications {
        resource_type = "volume"
        tags = {
          Name = "Demo"
          Environment   = "POC",
          Terraform     = "True"
        }
      }
    }
    resource "aws_key_pair" "terraform_demo" {
      key_name   = "terraform_demo"
      public_key = "${file(var.public_key)}"
    }
    data "aws_ami" "ubuntu" {
      most_recent = true
      filter {
        name   = "name"
        values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-*-20*"]
      }
      filter {
        name   = "architecture"
        values = ["x86_64"]
      }
      owners = ["amazon"]
    }

11- En el archivo 6-security.tf, configuraremos detalladamente todos los grupos de seguridad necesarios para el proyecto. Estos grupos de seguridad establecerán las reglas de entrada y salida que controlarán el tráfico hacia y desde nuestros recursos, asegurando una protección adecuada en cada nivel. Al definir estas reglas aquí, podremos gestionar de forma centralizada y eficiente los permisos de red requeridos por nuestras instancias y el Application Load Balancer.

  • resource "aws_security_group" "ec2_sg" {
      name          = "SG-EC2"
      description   = "SG-EC2"
      vpc_id        = module.vpc.vpc_id
      ingress {
        security_groups = [aws_security_group.alb_sg.id]
        description = "Acceso al puerto 80 desde el exterior"
        from_port   = var.puerto_servidor
        to_port     = var.puerto_servidor
        protocol    = "TCP"
      }
      ingress {
        cidr_blocks = ["${var.home_ip}/32"]
        description = "Acceso al puerto 22 solo desde la IP de casa"
        from_port   = var.puerto_ssh
        to_port     = var.puerto_ssh
        protocol    = "TCP"
      }
      egress {
        cidr_blocks = ["0.0.0.0/0"]
        description = "Salida full internet"
        from_port   = 0
        to_port     = 0
        protocol    = "-1"
      }
    }
    resource "aws_security_group" "alb_sg" {
      name          = "SG-ALB"
      description   = "SG-ALB"
      vpc_id        = module.vpc.vpc_id
      ingress {
        cidr_blocks = ["0.0.0.0/0"]
        description = "Acceso al puerto 80 desde el exterior"
        from_port   = var.puerto_lb
        to_port     = var.puerto_lb
        protocol    = "TCP"
      }
      egress {
        cidr_blocks = ["0.0.0.0/0"]
        description = "Salida full internet"
        from_port   = 0
        to_port     = 0
        protocol    = "-1"
      }
    }

12- En el archivo 7-iam.tf, definiremos todos los elementos relacionados con la gestión de identidad y acceso (IAM) en el proyecto. Esto incluirá la creación de roles específicos, la definición de políticas de permisos, y la asociación de estas políticas a los roles correspondientes.

  • resource "aws_iam_role" "demo_role" {
      name = "demo_role"
      assume_role_policy = <<EOF
        {
        "Version": "2012-10-17",
        "Statement": [
            {
            "Action": "sts:AssumeRole",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Effect": "Allow",
            "Sid": ""
            }
        ]
        }
        EOF
    }
    resource "aws_iam_policy_attachment" "attach_amazon_full_access-demo_role" {
      name       = "attach-amazon-full-access-demo_role"
      roles      = [aws_iam_role.demo_role.name]
      policy_arn = "arn:aws:iam::aws:policy/AmazonSSMFullAccess"
    }
    resource "aws_iam_policy_attachment" "attach_amazon_ec2_role_for-demo_role" {
      name       = "attach-amazon-ec2-role-for-demo_role"
      roles      = [aws_iam_role.demo_role.name]
      policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM"
    }
    resource "aws_iam_instance_profile" "demo_profile" {
      name = "demo_profile"
      role = "${aws_iam_role.demo_role.name}"
    }

13- En el archivo 8-variables.tf, definiremos todas las variables que necesitaremos para parametrizar el proyecto. Estas variables permitirán una mayor flexibilidad y reutilización del código, facilitando la personalización de los recursos y haciendo que el despliegue sea más adaptable a diferentes entornos y requisitos específicos.

  • variable "puerto_servidor" {
      description = "Puerto para las instancias"
      type        = number
      default     = 80
      #Forma de validar una variable
      validation {
        condition     = var.puerto_servidor > 0 && var.puerto_servidor <= 65535
        error_message = "El valor del puerto debe estar comprendido entre 1 y 65535."
      }
    }
    variable "puerto_lb" {
      description = "Puerto para el LB"
      type        = number
      default     = 80
    }
    variable "puerto_ssh" {
      description = "Puerto SSh para acceder a la instancias"
      type        = number
      default     = 22
    }
    variable "instance_type" {
      description = "Tipo de instancia EC2"
      type        = string
    }
    variable "public_key" {
      description = "Public key path"
      default     = "~/.ssh/id_rsa.pub"
    }
    variable "home_ip" {
      description = "IP pública de la casa"
    }

14- En el archivo 9-output.tf, definiremos las salidas que Terraform nos mostrará tras ejecutar terraform apply. Estas salidas incluirán detalles de los recursos creados, que nos ayudarán a verificar rápidamente el estado del despliegue y a acceder fácilmente a los recursos configurados en el proyecto.

  • output "dns_ALB" {
        description = "DNS pública del load balancer"
        value = "http://${aws_lb.demo_lb.dns_name}:${var.puerto_lb}"
    }
    output "sns_topic_arn" {
      value = aws_sns_topic.topic_sns.arn
    }

15- En el archivo 10-sns.tf, configuraremos todos los recursos necesarios para crear nuestro topic de Amazon SNS (Simple Notification Service), que se encargará de enviarnos notificaciones por correo electrónico sobre los distintos eventos que ocurran en el grupo de Auto Scaling (ASG). Esto nos permitirá mantenernos informados en tiempo real sobre el estado y los cambios en el ASG, facilitando la administración y respuesta a cualquier situación que pueda surgir.

  • resource "aws_sns_topic" "topic_sns" {
      name = "topic-sns"
      display_name = "Test From SNS"
    }
    resource "aws_sns_topic_subscription" "user_updates_mail_target" {
      topic_arn = aws_sns_topic.topic_sns.arn
      protocol  = "email"
      endpoint  = "tu-email@gmail.com"
    }

16- En el archivo 11-demo.auto.tfvars, estableceremos los valores de las variables para el entorno que estamos generando. Este archivo es esencial, ya que permite personalizar la configuración según las necesidades específicas de cada ambiente. Ten en cuenta que los valores pueden variar dependiendo de si estamos trabajando en un entorno de desarrollo, pruebas o producción, lo que brinda flexibilidad y adaptabilidad a nuestra infraestructura.

  • puerto_lb       = 80
    puerto_servidor = 80
    puerto_ssh      = 22
    instance_type   = "t2.medium"
    home_ip = "IP"

17- En el script get_public_ip.sh, al ejecutarlo, se actualizará automáticamente el archivo 11-demo.auto.tfvars con la dirección IP pública de nuestra ubicación actual. Esta IP se utiliza luego en la configuración del ingress del grupo de seguridad de las instancias, permitiendo el acceso desde nuestra red de manera segura y controlada

  • #!/bin/bash
    PUBLIC_IP=$(curl -s http://checkip.amazonaws.com)
    if grep -q "home_ip" 11-demo.auto.tfvars; then
      sed -i "s/^home_ip.*/home_ip = \"$PUBLIC_IP\"/" 11-demo.auto.tfvars
    else
      echo "home_ip = \"$PUBLIC_IP\"" >> demo.auto.tfvars
    fi
    echo "La IP pública de la casa es: $PUBLIC_IP"

Con todos los archivos configurados, ya estamos listos para ejecutar Terraform y desplegar la infraestructura.

  • terraform init
  • terraform plan
  • terraform apply
  • Podemos ver el output que definimos;

Comprobar en la consola de AWS que los recursos fueron creados correctamente.

  • ASG
    •  
  • Launch template
  • Targuet group
  • ALB
  • Instancias EC2
  • Alarmas en CloudWatch
  • Asi llega la subscripcion SNS a nuestro mail.

Una vez que hemos verificado que todos los recursos se han creado correctamente, el siguiente paso es acceder al balanceador de carga. Desde allí, comprobaremos que este enruta el tráfico hacia las instancias de manera adecuada, asegurando que la configuración sea funcional.

El siguiente paso será acceder a cualquiera de las instancias desde la consola de AWS utilizando AWS Systems Manager (SSM). Una vez dentro, instalaremos la herramienta stress, la cual nos permitirá simular una alta carga en la CPU de las instancias. Esto es útil para probar y verificar que el Auto Scaling Group (ASG) responde adecuadamente a las métricas configuradas, creando automáticamente más instancias cuando se alcanza el umbral definido.

  • Actualizar e instalar stress:
    • sudo apt update && sudo apt install stress
  • Ejecutar stress para saturar la CPU, este comando ejecutará una carga en los 4 núcleos de la instancia, elevando el uso de la CPU.
    • stress -c 4 &
  • Monitorear el consumo de CPU, para observar la carga en tiempo real, utiliza el comando:
    • htop

Resultado esperado

Una vez que el uso de CPU alcance el umbral configurado, las políticas del ASG se activarán automáticamente y se comenzarán a lanzar nuevas instancias para equilibrar la carga. Este proceso asegura que la infraestructura pueda manejar de forma dinámica los picos de demanda, manteniendo la disponibilidad y el rendimiento.

Cuando el uso de CPU alcanza el umbral configurado, las alarmas previamente definidas en CloudWatch se disparan. Esto genera un evento visible en el panel de métricas de CloudWatch, mostrando el cambio en el estado de la alarma (de OK a ALARM). En este punto, las políticas asociadas al Auto Scaling Group (ASG) se ejecutan automáticamente, iniciando el proceso de escalado para agregar más instancias EC2 y garantizar la estabilidad del sistema.

Estas visualizaciones no solo confirman que las alarmas están funcionando correctamente, sino que también son fundamentales para realizar un monitoreo efectivo de tu infraestructura y tomar decisiones informadas para futuras optimizaciones.

Así se ven las notificaciones por correo electrónico cuando se activan las alarmas debido a un alto o bajo consumo de CPU, así como cuando el Auto Scaling Group (ASG) crea o elimina instancias:

Notificaciones de Alarmas por CPU

Cuando el uso de CPU supera o cae por debajo de los umbrales definidos, recibirás correos electrónicos detallados con información como:

  • Nombre de la alarma: Identificando qué alerta fue activada.
  • Estado de la alarma: Indicando si se trata de un uso alto o bajo.
  • Métricas relacionadas: Valores específicos que desencadenaron la alerta.
  • Hora del evento: Momento exacto en que se activó la alarma.

Notificaciones del ASG

Además, cada vez que el ASG escala hacia arriba (creando una nueva instancia) o hacia abajo (eliminando una instancia), se envía un correo con detalles como:

  • Acción realizada: Creación o eliminación de instancias.
  • Cantidad de instancias afectadas: Número de instancias agregadas o removidas.
  • Motivo de la acción: Por ejemplo, alcanzar un umbral definido en las políticas del ASG.

Estas alertas por correo proporcionan visibilidad inmediata sobre el comportamiento de nuestra infraestructura, permitiéndote:

  1. Confirmar que las políticas de escalado están funcionando correctamente.
  2. Realizar ajustes si las métricas o acciones no coinciden con lo esperado.

Este flujo de notificaciones garantiza un monitoreo proactivo, ayudándonos a mantener la estabilidad y el rendimiento de nuestro entorno en AWS.

Aquí podemos observar cómo el Auto Scaling Group (ASG) ha comenzado a crear nuevas instancias de forma automática. Cada nueva instancia es aprovisionada y registrada automáticamente en el Target Group asociado al Balanceador de Carga, garantizando una distribución eficiente del tráfico y la continuidad del servicio.

Terraform destroy

  • Como siempre, al finalizar tus pruebas, recuerda eliminar todos los recursos creados ejecutando terraform destroy --auto-approve. Este paso es crucial para evitar sorpresas desagradables en tu factura a final del mes. No subestimes la importancia de esta tarea, ya que la acumulación de recursos no utilizados puede generar costos innecesarios. Tómate el tiempo para limpiar tu entorno, eso te ahorrará dolores de cabeza en el futuro 🙂

Conclusiones

Hemos llegado al final de una entrada muy interesante. Como mencionamos al inicio, la arquitectura que exploramos hoy representa una mejora significativa respecto a la presentada en la entrada anterior. El uso de un Auto Scaling Group (ASG) nos garantiza siempre contar con una capacidad deseada, un límite inferior para garantizar disponibilidad mínima y un máximo para manejar picos de demanda. Esto asegura que nuestra infraestructura esté operativa en todo momento, adaptándose automáticamente a los cambios en la demanda.

Por ejemplo, durante eventos de alto tráfico como el Black Friday o promociones especiales, nuestra arquitectura será capaz de escalar de forma dinámica, manteniendo la eficiencia y disponibilidad de la aplicación. Además, al trabajar con Launch Templates, garantizamos que todas las instancias lanzadas por el ASG sean idénticas, lo que simplifica la gestión, mejora la consistencia y reduce errores.

Aprovechar servicios como estos no solo optimiza los costos operativos, sino que también aumenta la eficiencia y la resiliencia de nuestras soluciones. Al integrar herramientas como Terraform, podemos desplegar esta arquitectura en múltiples ambientes y cuentas de AWS con facilidad, garantizando replicabilidad y un mayor control de la infraestructura.

En resumen, la demo que hemos revisado hoy no solo es práctica, sino altamente utilizada en empresas modernas por su capacidad de garantizar la escalabilidad, disponibilidad y eficiencia de los sistemas en la nube.

¡Nos vemos en la próxima entrada!

Nota: Todo el código lo pueden encontrar en el siguiente repositorio.

Categorías
AWS y Terraform
Etiquetas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

AWS

Artículo anterior

Diferentes tipos de balanceadores de carga en AWS
02/11/2024
AWS

Siguiente artículo

Buenas Prácticas de Seguridad en AWS
30/11/2024