DEV Community: Adrian

# ECS vs Kubernetes

Adrian — Tue, 14 Apr 2026 14:25:05 +0000

No toda plataforma de contenedores necesita la complejidad operativa de Kubernetes.

Cuando el objetivo es desplegar aplicaciones de forma rapida, segura y con bajo overhead operativo, Amazon ECS suele ofrecer una relacion mucho mas simple entre valor y esfuerzo:

Menor complejidad de operacion y mantenimiento.
Integracion nativa con servicios de AWS.
Curva de aprendizaje mas corta para equipos pequenos o medianos.
Menos componentes que administrar.
Menor tiempo de puesta en marcha.
Muy buena opcion para workloads HTTP, APIs internas, backends y procesos batch.

Kubernetes sigue siendo una excelente alternativa cuando hay requerimientos claros de portabilidad, ecosistemas multi-cluster complejos, operadores avanzados o estandares de plataforma muy maduros. Pero no deberia ser la eleccion por default.

La mejor decision no es "usar la tecnologia mas popular", sino elegir la que resuelve el problema con la menor friccion operativa posible.

Beneficios De Usar ECS

1. Menos carga operativa

Con ECS el equipo puede enfocarse mas en la aplicacion y menos en administrar el orquestador. En muchos casos no hace falta ocuparse de:

upgrades del control plane
administracion de etcd
networking avanzado entre multiples componentes
capas extra de observabilidad y add-ons solo para que el cluster funcione bien

Si ademas se usa AWS Fargate, tambien se elimina la administracion de nodos.

2. Mejor alineacion con AWS

ECS se integra de forma natural con:

Application Load Balancer
CloudWatch
IAM
ECR
Auto Scaling
Secrets Manager
VPC

Eso simplifica mucho el diseño de una plataforma estandar para publicar servicios.

3. Menor costo de complejidad

Muchas veces el costo mas alto no esta en la infraestructura sino en la complejidad operativa:

mas piezas para aprender
mas riesgos de configuracion
mas tiempo para diagnosticar incidentes
mas esfuerzo de onboarding

Si el caso de uso no necesita las capacidades avanzadas de Kubernetes, ese costo no siempre se justifica.

4. Time to market mas rapido

Para equipos que quieren publicar microservicios o aplicaciones internas con rapidez, ECS permite construir una plataforma repetible con menos decisiones tecnicas y menos puntos de falla.

5. Escala suficiente para muchisimos casos reales

Existe una idea comun de que "si hay contenedores, entonces tiene que haber Kubernetes". En la practica, muchisimas cargas productivas funcionan perfectamente sobre ECS, especialmente cuando:

el entorno ya vive mayormente en AWS
el equipo prioriza simplicidad
no existe necesidad real de portabilidad multi-cloud
los servicios comparten patrones de despliegue similares

6. Infraestructura y despliegues mas predecibles

Cuando la infraestructura se define como codigo y los despliegues se automatizan con GitHub Actions, el beneficio no es solo tecnico: tambien mejora la forma de operar del equipo.

Esto aporta:

entornos repetibles y versionados
menor riesgo de configuraciones manuales inconsistentes
trazabilidad completa de cambios
revisiones por pull request antes de modificar infraestructura o aplicaciones
despliegues mas rapidos y estandarizados
menos dependencia de pasos manuales y conocimiento tribal

La combinacion de ECS + Terraform + GitHub Actions permite construir una plataforma simple de entender y facil de escalar operativamente.

Cuando ECS Tiene Mucho Sentido

ECS suele ser una decision muy solida para:

APIs y backends de negocio
aplicaciones internas
microservicios HTTP
workers y jobs programados
equipos de plataforma pequenos o en crecimiento
organizaciones que quieren estandarizar despliegues sin operar una plataforma demasiado compleja

Cuando Kubernetes Puede Ser Mejor

Kubernetes puede ser la mejor opcion cuando hay necesidades concretas como:

portabilidad fuerte entre clouds o datacenters
ecosistema basado en operadores, CRDs o service mesh avanzado
requerimientos de plataforma multi-tenant mas sofisticados
estandarizacion corporativa ya consolidada sobre Kubernetes
equipos con experiencia profunda administrando clusters y sus componentes

La clave es que esas necesidades sean reales, no asumidas.

how to launch elastic cache with terraform

Adrian — Mon, 27 Nov 2023 22:42:56 +0000

A developer from the compañy I work asked me about the posibility of adding a new database for a new requirement. After asking some question about what he needs to do, we decided to moved to elastic cache.

First.
we need to crete a security group to permit port 6379

resource "aws_security_group" "allow_cache" {
  name        = "allow_cache-${local.app_name}-${terraform.workspace}"
  description = "Allow cache inbound traffic"
  vpc_id      = var.vpc-id

  ingress {
    description      = "cache from VPC"
    from_port        = 6379
    to_port          = 6379
    protocol         = "tcp"
    cidr_blocks      = [var.allowed_cidr_block-1]
   }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
   }

  tags = {
    Name = "allow_cache"
  }
}

Lambda role

resource "aws_iam_role" "lambda_vpc_role" {
  name = "lambda-vpc-role-${local.app_name}-${terraform.workspace}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

attachmet

resource "aws_iam_role_policy_attachment" "lambda_vpc_role_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"
  role       = aws_iam_role.lambda_vpc_role.name
}

Cluster elastic cache with output

resource "aws_elasticache_cluster" "hr_cache" {
  cluster_id           = "clusterforlambdatest-${local.app_name}-${terraform.workspace}"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  port                 = 6379
  #engine_version       = "3.2.10"
  subnet_group_name    = aws_elasticache_subnet_group.subnet-sg.id
  security_group_ids   = [aws_security_group.allow_cache.id]
    tags = {
    nombre  = "hr_cache"
    deploy  = "terraform"
  }
}


output "elasticache_endpoint" {
  value = aws_elasticache_cluster.hr_cache.cache_nodes.0.address
}

all code here:

resource "aws_security_group" "allow_cache" {
  name        = "allow_cache-${local.app_name}-${terraform.workspace}"
  description = "Allow cache inbound traffic"
  vpc_id      = var.vpc-id

  ingress {
    description      = "cache from VPC"
    from_port        = 6379
    to_port          = 6379
    protocol         = "tcp"
    cidr_blocks      = [var.allowed_cidr_block-1]
   }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
   }

  tags = {
    Name = "allow_cache"
  }
}


resource "aws_iam_role" "lambda_vpc_role" {
  name = "lambda-vpc-role-${local.app_name}-${terraform.workspace}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_vpc_role_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"
  role       = aws_iam_role.lambda_vpc_role.name
}


#resource "aws_subnet" "example" {
#  vpc_id     = aws_vpc.example.id
#  cidr_block = "10.0.0.0/8"
#
#  tags = {
#    Name = "my-subnet"
#  }
#}

resource "aws_elasticache_subnet_group" "subnet-sg" {
  name       = "my-cache-subnet"
  subnet_ids = [var.subnet-t-app-net]
}



resource "aws_elasticache_cluster" "hr_cache" {
  cluster_id           = "clusterforlambdatest-${local.app_name}-${terraform.workspace}"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  port                 = 6379
  #engine_version       = "3.2.10"
  subnet_group_name    = aws_elasticache_subnet_group.subnet-sg.id
  security_group_ids   = [aws_security_group.allow_cache.id]
    tags = {
    nombre  = "hr_cache"
    deploy  = "terraform"
  }
}


output "elasticache_endpoint" {
  value = aws_elasticache_cluster.hr_cache.cache_nodes.0.address
}

in order to test this, we can install a tool called redis comander

redis-commander --redis-host clusterforlambdatest-xxxx-prd.xxxxxxxxxx.cache.amazonaws.com

If we are saving data correctly into the Elastic Cache, we can see it here.