DEV Community: Bianca Torres

EKS Auto Mode: correr Kubernetes sin andar peleando con los nodos

Bianca Torres — Fri, 04 Sep 2026 18:54:26 +0000

Si algo aprendí gestionando EKS en producción, es que mantener los nodos se lleva más tiempo del que uno imagina. Managed node groups, Karpenter, el EBS CSI driver, actualizar AMIs, y el clásico "¿por qué este pod lleva 10 minutos en Pending?" a la hora menos pensada. No es lo más entretenido del rol, pero es parte de lo que nos toca hacer para mantener un cluster sano en producción.

Por eso, cuando probé EKS Auto Mode, me hice esta pregunta: "si dejo que AWS haga todo esto por mí, ¿qué gano y qué pierdo?". Este artículo es esa respuesta, con un laboratorio que puedes seguir tú mismo en menos de 30 minutos.

Mantener nodos es casi un segundo trabajo

Antes de vender la solución, hablemos del problema de verdad. En un EKS "clásico", tú te encargas de un montón de cosas:

Crear y dimensionar los node groups. ¿m5.large? ¿c6i.xlarge? ¿Spot u On-Demand? Cada decisión te la cobra el futuro.
Instalar y afinar un autoscaler. Cluster Autoscaler o Karpenter. Los dos piden configuración, permisos IAM y mantenimiento.
Cuidar los add-ons. CoreDNS, kube-proxy, EBS CSI, VPC CNI... instalarlos, versionarlos, actualizarlos.
Parchear las AMIs. Cada vez que aparece una vulnerabilidad de seguridad en el sistema operativo del nodo (CVE), es nuestro trabajo subsanarlo.
Debuggear el scheduling. Ese 0/3 nodes are available: Insufficient memory que aparece justo cuando ya te ibas a desconectar.

Lo irónico es que nada de eso hace tu producto mejor. Es puro "impuesto de plataforma". Trabajo que haces para que Kubernetes exista, no para que tu app sea mejor.

Entonces, ¿Qué es EKS Auto Mode?

AWS se hace cargo del cómputo, el almacenamiento y el networking del cluster por ti. Por dentro usa Karpenter y nodos con Bottlerocket, pero todo eso queda tras bambalinas. Tú ya no administras node groups ni instalas add-ons uno por uno.

Tú declaras tus apps, AWS decide y levanta la infraestructura para correrlas. Los nodos aparecen cuando tus pods los necesitan, y se van cuando ya no.

Lab: de cero a app corriendo, con nodos que aparecen solos

Lo que necesitas:

AWS CLI v2 configurado (aws configure)
eksctl v0.195.0 o más
kubectl
Permisos IAM sobre EC2, EKS, IAM y VPC

Paso 1: Crear el cluster con Auto Mode

eksctl create cluster \
  --name demo-automode \
  --region us-east-1 \
  --enable-auto-mode

Ese único comando te crea el cluster, la VPC, las subredes, activa Auto Mode y deja los add-ons esenciales gestionados por AWS. Tarda aproximadamente unos 15 minutos.

Paso 2: Mirar el cluster recién creado

kubectl get nodes

kubectl get nodepools

Auto Mode crea dos node pools automáticamente:

system arranca con 1 nodo desde el inicio. Ese nodo corre los componentes internos del propio cluster (CoreDNS y los add-ons gestionados). Por eso kubectl get nodes sí te muestra un nodo apenas creas el cluster.
general-purpose arranca con 0 nodos. Este es el pool donde van a caer tus aplicaciones, y ahí es donde se ve la magia: se queda vacío hasta que despliegas algo que necesite cómputo.

Así que el cambio de chip es este: ver el pool de tus cargas en cero no significa que algo se rompió. Significa que todavía no hay nada tuyo que correr, y AWS no está cobrándote nodos de más.

Paso 3: Desplegar una app

# nginx-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
spec:
  type: LoadBalancer
  selector:
    app: nginx-demo
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f nginx-demo.yaml

Paso 4: Ver Auto Mode en acción

kubectl get nodes

En unos 30 segundos vas a ver aparecer un nodo nuevo en el pool general-purpose (ese que estaba en cero) sin que tú lo hayas pedido. AWS se dio cuenta de que tus pods necesitan cómputo y levantó una instancia EC2 solo.

Paso 5: Escalar y mirar qué pasa

kubectl scale deployment nginx-demo --replicas=10
kubectl get nodes

Al escalar en numero de replicas de nuestra app, tener un solo nodo será insuficiente. Si la capacidad de ahora no alcanza, Auto Mode levanta más. No tocaste ningún autoscaler, no editaste ningún node group.

Paso 6: Destruir

eksctl delete cluster --name demo-automode --region us-east-1

Es super importante que al finalizar nuestro laboratorio destruymos todos los recursos creado, para evitar costos innecesarios. Un cluster olvidado es una sorpresa fea en la factura.

Clásico vs Auto Mode

Qué	EKS clásico	EKS Auto Mode
Gestión de nodos	Manual / tu propio Karpenter	AWS
Add-ons (CoreDNS, CSI, etc.)	Los instalas y versionas tú	Gestionados
Actualizar AMIs	Lo gestionas tú	AWS
Autoscaling	Configuras CA o Karpenter	Automático
Tu tiempo operando	Mucho	Poco
Personalización	Total	Acotada
Curva de arranque	Empinada	Suave

Cuándo usarlo y cuándo no (Según mi opinión)

Úsalo si:

Arrancas un cluster nuevo y quieres velocidad sin construir toda una plataforma.
Tu equipo es chico y no quieres tener a alguien dedicado a cuidar nodos.
Tus workloads son bastante estándar: APIs, workers, web.

Piénsalo dos veces si:

Dependes de configuraciones muy específicas de nodo (kernels custom, DaemonSets exigentes, GPUs con drivers a medida).
Ya tienes un Karpenter afinado que te ahorra dinero y no lo quieres soltar.
Necesitas control total del ciclo de vida de la AMI por temas de compliance.

Auto Mode te cambia control por simplicidad. Ganas horas de operación, cedes algunos grados de personalización. Para la mayoría, ese cambio vale muchísimo la pena. Para casos muy puntuales, todavía no.

¿Y cuánto me va a costar?

Auto Mode suma un pequeño cargo de gestión encima del costo del EC2 que corre por debajo. Pero no te quedes solo con "cuánto cuesta el add-on". La cuenta real es: cuánto cuesta el add-on menos las horas de ingeniería que dejas de gastar cuidando nodos, autoscalers y parches. Cuando sumas ese tiempo, el número se ve muy distinto.

En conclusión

EKS Auto Mode no es magia. Es AWS haciendo el trabajo de plataforma que muchos veníamos haciendo a mano. Si gestionas clusters en producción, pruébalo con un workload que no sea crítico y mide cuánto tiempo dejas de invertir en cosas que no hacen mejor tu producto.

Nunca más hardcodees un token: Seguridad en GitHub para DevOps

Bianca Torres — Wed, 10 Jun 2026 21:41:47 +0000

El pasado sábado 6 de junio tuve la oportunidad de participar como speaker en el GitHub Community Day Perú 2026, donde compartí una charla sobre un tema que sigue siendo una de las causas más frecuentes de incidentes de seguridad: la exposición accidental de credenciales.

Durante la sesión hablamos de herramientas gratuitas que muchos equipos ya tienen disponibles dentro de GitHub, pero que no siempre aprovechan al máximo. Usamos GitHub todos los días para gestionar código, colaborar con nuestros equipos y automatizar despliegues, pero en muchas ocasiones solo utilizamos una pequeña parte de todo lo que la plataforma nos ofrece.

La buena noticia es que GitHub incorpora múltiples funcionalidades de seguridad que pueden ayudarnos a prevenir filtraciones de credenciales, proteger nuestros pipelines y mejorar nuestra postura de seguridad sin necesidad de adquirir herramientas adicionales.

En este artículo recopilo los principales conceptos que vimos durante la charla, junto con una demostración práctica de cómo desplegar una aplicación en AWS sin almacenar una sola credencial permanente.

El problema

Todos lo hemos hecho.

Hardcodear un API key “solo por ahora”, pushear un .env por accidente o compartir un token por Slack para salir de un apuro.

Son errores comunes, pero las consecuencias pueden ser graves: desde una factura inesperada en AWS hasta una filtración de información sensible.

En 2025, De acuerdo al reporte de GitGuardian, GitHub detectó más de 28 millones de secretos expuestos en repositorios públicos. Access Keys de AWS, tokens de GitHub, webhooks de Slack y muchas otras credenciales quedaron visibles para cualquiera que quisiera utilizarlas.

El flujo típico suele verse así:

Un developer necesita desplegar una aplicación.
Crea una Access Key y Secret Key.
Las almacena en un archivo .env o directamente en el código.
El archivo termina llegando al repositorio.
Un bot detecta las credenciales y comienza a utilizarlas en cuestión de segundos.

La solución no es simplemente “tener más cuidado”.
La solución es construir mecanismos que hagan mucho más difícil que estos errores lleguen a producción.

GitHub nos ofrece varias capas de protección que pueden ayudarnos precisamente con eso.

Las 5 capas de Seguridad en Github

1. GitHub Secrets

La primera línea de defensa es evitar almacenar información sensible dentro del código.

GitHub Secrets permite guardar valores cifrados que pueden ser consumidos por GitHub Actions durante la ejecución de un workflow.

Características:

Encriptados mediante libsodium.
Ocultos automáticamente en los logs.
No pueden visualizarse nuevamente después de guardarse.
Disponibles a nivel de repositorio, environment u organización.

Además, los Environments agregan controles adicionales como:

Aprobaciones manuales para producción.
Restricciones por branch.
Wait timers.
Protección de despliegues críticos.

Si todavía tienes credenciales hardcodeadas en tu código, este debería ser el primer cambio que realices.

2. OIDC con AWS (Zero Credentials)

OIDC es un protocolo de autenticación que permite que dos servicios se reconozcan sin compartir credenciales.

Tradicionalmente, muchos pipelines almacenan Access Keys de AWS dentro de GitHub Secrets.
Aunque esto es mejor que hardcodearlas, seguimos dependiendo de credenciales permanentes que pueden ser filtradas o comprometidas.

Con OpenID Connect (OIDC) podemos eliminar completamente ese problema.

¿Cómo funciona?

GitHub Actions inicia la ejecución del workflow.
GitHub genera un token JWT temporal.
AWS valida el token mediante un OIDC Provider.
AWS verifica que el repositorio tenga permiso para asumir un rol específico.
AWS entrega credenciales temporales.
Las credenciales expiran automáticamente

No hay keys. No hay tokens permanentes. Nada que pueda leakearse.

Paso 1 — Crear el OIDC Provider en IAM:
Provider URL: token.actions.githubusercontent.com

Paso 2 — Crear un IAM Role con trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:MI-ORG/MI-REPO:*"
        }
      }
    }
  ]
}

La condición StringLike es clave: solo TU repo puede asumir este rol. Si alguien forkea tu repo, no puede deployar.

Paso 3 — Usar en el workflow de Github Actions:

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ vars.AWS_ROLE_ARN }}
      aws-region: us-east-1

Eso es todo. Cero secrets de AWS en GitHub.

3. Secret Scanning

Incluso con buenas prácticas, los errores siguen ocurriendo.

Por eso GitHub incorpora Secret Scanning.
Esta funcionalidad analiza automáticamente los commits buscando patrones asociados a credenciales conocidas.

Actualmente puede detectar más de 200 tipos de secretos pertenecientes a más de 100 proveedores.
Ejemplo: AWS, GitHub, Slack, Stripe, Twilio, npm, etc.

Para habilitarlo:
Settings → Code security and analysis → Secret scanning → Enable

Cuando GitHub detecta una credencial:

Genera una alerta.
Muestra exactamente dónde se encuentra.
En algunos casos coordina la revocación automática con el proveedor.

Es una capa reactiva, pero extremadamente útil.

4. Push Protection

Mientras Secret Scanning detecta problemas después del commit, Push Protection intenta detenerlos antes.

Cuando GitHub detecta una credencial durante un push, simplemente bloquea la operación.

El secret nunca llegó al repo. Nunca se expuso. Protección proactiva.

Para habilitarlo:
Settings → Code security and analysis → Push protection → Enable

5. Dependabot

La seguridad no se limita únicamente a las credenciales.
Muchas vulnerabilidades provienen de dependencias desactualizadas.

Cuando se publica un CVE crítico que afecta una librería utilizada por nuestro proyecto, Dependabot puede:

Detectar la vulnerabilidad.
Generar una alerta.
Crear automáticamente un Pull Request con la actualización.

Configuración (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Además de dependencias de aplicación, Dependabot también ayuda a mantener actualizadas las GitHub Actions utilizadas por nuestros pipelines.

Demo: Deploy completo sin credenciales

Para demostrar cómo funcionan varias de estas capas trabajando juntas, preparé una aplicación sencilla que lee un secreto desde una variable de entorno y lo muestra en una página web.

El código relevante:

const SECRET_MESSAGE = process.env.SECRET_MESSAGE || 'No secret configured'

La aplicación no conoce el valor del secreto.
Simplemente espera encontrar una variable de entorno durante la ejecución.

La demostración consistió en desplegar esta aplicación en Amazon ECS Fargate, utilizando GitHub Actions para automatizar todo el proceso y OIDC para autenticarnos en AWS sin necesidad de almacenar Access Keys permanentes.

El flujo:

GitHub Secret (SECRET_MESSAGE)
       ↓
GitHub Actions (OIDC → sin AWS keys)
       ↓
Build Docker image → Push a ECR
       ↓
Update ECS Task Definition (inyecta el secret)
       ↓
Deploy a ECS Fargate
       ↓
App muestra el secret

Resultado: El secret se muestra en la app, pero si buscas en todo el repositorio, no lo vas a encontrar. Se inyecta en runtime a través de la Task Definition de ECS. Nunca existió en el código fuente.

Qué puedes hacer hoy

Si te llevas algo de este artículo, que sea esto:

Habilita Push Protection: Protección inmediata contra leaks accidentales.
Migra de AWS access keys a OIDC: Eliminas el riesgo más grande de tu pipeline.
Agrega dependabot.yml: Un archivo y tus dependencias se mantienen actualizadas automáticamente.
Mueve secrets hardcodeados a GitHub Secrets: Revisa tu código, busca tokens hardcodeados, y muévelos.

Conclusión

La seguridad de credenciales no tiene que ser complicada.

GitHub nos proporciona múltiples capas de protección que abarcan desde la prevención de errores humanos mediante Push Protection, hasta la detección de credenciales expuestas con Secret Scanning y la eliminación completa de credenciales permanentes mediante OIDC.

La principal reflexión que quise transmitir durante mi charla en el GitHub Community Day Perú 2026 es que muchas veces utilizamos GitHub todos los días, pero no aprovechamos todo el potencial que nos ofrece en materia de seguridad.

Con unas pocas configuraciones podemos reducir significativamente el riesgo de exposición de credenciales y fortalecer nuestros pipelines sin añadir complejidad innecesaria.

Las diapositivas utilizadas para la presentación están disponibles en: https://speakerdeck.com/bnktch13/seguridad-en-github-para-devops
Y el código completo del ejemplo utilizado durante la demostración está disponible en: https://github.com/BnkTCh/secure-deploy-demo

Te invito a explorarlo, probarlo y adaptarlo a tus propios proyectos.

Y si estuviste presente en la charla durante el GitHub Community Day Perú 2026, gracias por acompañarme y por todas las preguntas y conversaciones que hicieron la sesión aún más interesante.

Prompts que construyen: cómo dominar Amazon Q Developer en tu día a día

Bianca Torres — Mon, 05 Jan 2026 02:22:14 +0000

¿Sabías que el 40% del tiempo de un desarrollador se va en tareas repetitivas como leer documentación, generar boilerplate y debuggear errores?

Como DevOps Engineer, he descubierto que Amazon Q Developer puede transformar estas tareas tediosas en procesos eficientes. No es solo "otra IA más": es un asistente especializado que entiende el ecosistema AWS.

En este artículo te muestro cómo usarlo de forma práctica y, más importante, cómo escribir prompts que generen resultados reales, no respuestas genéricas.

Este artículo está basado en una charla que di sobre Amazon Q Developer y Prompt Engineering.

Si prefieres el formato video, aquí puedes verla completa:
https://www.youtube.com/live/M3sr0p8G5OU?si=YI9GLC-6PN8ygRql

¿Qué es Amazon Q Developer?

Amazon Q Developer es un asistente de IA generativa enfocado en:

Desarrollo de software
Administración de AWS
Mejores prácticas oficiales

Se integra directamente en:

IDEs como VS Code
AWS Console
CLI

A diferencia de otras herramientas genéricas, Amazon Q está entrenado con:

Documentación oficial de AWS
Ejemplos reales
Buenas prácticas del ecosistema cloud

¿Cómo funciona Amazon Q Developer?

Amazon Q Developer funciona sobre Amazon Bedrock, utilizando distintos Large Language Models (LLMs), entre ellos:

Amazon Titan
GPT (y otros modelos disponibles)

Algunos puntos clave:

No usa un único modelo fijo
Cuanto más popular es un lenguaje o framework, mejor entrenado estará el modelo.
Más datos de entrenamiento → mejores sugerencias

Por eso, tecnologías comunes como Terraform, Kubernetes o Python suelen tener respuestas de muy buena calidad.

¿Qué podemos hacer con Amazon Q Developer?

En el día a día, Amazon Q puede ayudarte a:

Autocompletar código más rápido
Obtener soluciones simples sin salir del IDE
Explicar y documentar código
Explicar mensajes de error
Generar pruebas
Crear código base (boilerplate)
Mejorar tu productividad en general

La clave no es solo qué hace, sino cómo se lo pides.

Casos de uso reales donde Amazon Q brilla

Para DevOps Engineers:

Infraestructura como código: Generar templates de CloudFormation/Terraform
Troubleshooting: Interpretar logs de CloudWatch y errores de servicios AWS
Automatización: Crear scripts de CI/CD y pipelines

Para Developers:

SDK de AWS: Generar código para interactuar con servicios AWS
Serverless: Crear funciones Lambda con mejores prácticas
Containerización: Dockerfiles optimizados para ECS/EKS

Para Cloud Architects:

Diseño de arquitecturas: Sugerir patrones y servicios apropiados
Optimización de costos: Identificar oportunidades de ahorro
Seguridad: Implementar controles y políticas IAM

¿Qué es un prompt?

Un prompt es simplemente:
La instrucción que le das a la IA para que realice una tarea.
Pero la diferencia entre frustración y productividad está en la calidad del prompt.

Prompt vago vs Prompt bueno

Prompt vago:

Explícame este error

Prompt bueno:

Explícame este error que ocurre en un pod de Kubernetes en EKS cuando intento 
desplegar una aplicación Spring Boot en Java 17 y el pod entra en estado 
CrashLoopBackOff.

👉 El contexto lo es todo.

Buenas prácticas de Prompt Engineering

La regla de las 4 C:

Estas son las prácticas que mejor resultado me han dado usando Amazon Q Developer:

Claro
Sé específico sobre lo que quieres.
Contexto
Incluye información clave como:
Lenguaje
Versión
Servicio
Entorno
Conciso
Evita el ruido innecesario.
Continuo
Itera. Ajusta el prompt según la respuesta que recibes.

Checklist antes de enviar un prompt

Antes de presionar Enter, pregúntate:

¿Qué quiero exactamente? (tarea + resultado esperado)
¿Dónde corre? (lenguaje, versión, servicio, entorno)
¿Es claro y corto?
¿Qué siguiente paso pediré si no es perfecto?

Prompt engineering es un diálogo, no una orden única.

Conclusión
Amazon Q Developer puede ahorrarte mucho tiempo si sabes cómo hablarle.

No se trata de escribir prompts "bonitos", sino prompts útiles, con intención clara, contexto técnico y capacidad de iteración.

Si eres DevOps Engineer, Cloud Engineer o Developer y trabajas con AWS, aprender a usar Amazon Q Developer bien es una ventaja real, no solo hype.

Próximos pasos:

Instala Amazon Q Developer en tu IDE favorito:
https://docs.aws.amazon.com/es_es/amazonq/latest/qdeveloper-ug/q-in-IDE-setup.html
Practica con un proyecto real - empieza con tareas simples
Documenta tus prompts exitosos - crea tu propia biblioteca
Comparte con tu equipo - la productividad se multiplica

¿Y tú?
¿Ya usas Amazon Q Developer en tu día a día?