Talently
Talently
Ingeniero Cloud

Ingeniero Cloud

Diseña y opera la infraestructura cloud que permite a los productos escalar de forma confiable, segura y eficiente en costo.

Un Cloud Engineer diseña, implementa y mantiene la infraestructura y los servicios en la nube que sustentan las aplicaciones y operaciones de la organización. Su trabajo abarca desde la arquitectura de redes y cómputo en cloud hasta la automatización de la infraestructura, la gestión de costos y la implementación de controles de seguridad. A diferencia del DevOps Engineer con foco en pipelines y entrega continua, el Cloud Engineer tiene mayor especialización en la plataforma cloud: conoce en profundidad los servicios del proveedor elegido, sus límites, sus costos y las mejores prácticas de arquitectura cloud-native. Trabaja en estrecha colaboración con equipos de desarrollo, seguridad y operaciones.

AWSTerraformKubernetesNetworkingFinOpsSeguridad cloud

Recluta al mejor Ingeniero Cloud aquí

Empieza ahora

Responsabilidades Principales

  • •Diseñar arquitecturas cloud-native escalables, resilientes y seguras usando los servicios del proveedor cloud según las necesidades del producto.
  • •Implementar y mantener la infraestructura como código con Terraform o Pulumi garantizando reproducibilidad, versionado y gestión del estado.
  • •Gestionar redes cloud: VPCs, subnets, security groups, route tables, NAT gateways y conectividad híbrida con entornos on-premise.
  • •Implementar controles de seguridad cloud: IAM con mínimo privilegio, cifrado en reposo y tránsito, logging de auditoría y gestión de secretos.
  • •Optimizar el costo de la infraestructura cloud identificando recursos subutilizados y diseñando estrategias de rightsizing y reserved instances.
  • •Garantizar la alta disponibilidad y la resiliencia del sistema diseñando para fallos: multi-AZ, failover automático y disaster recovery.

Habilidades Clave

Technical Skills

  • Profundidad en al menos un proveedor cloud (AWS, GCP o Azure): servicios de cómputo, red, almacenamiento, base de datos y seguridad
  • Infraestructura como código con Terraform: módulos, state management, workspaces y testing de infraestructura
  • Kubernetes para orquestación de contenedores: deployments, services, ingress, RBAC, persistent volumes y gestión de recursos
  • Networking cloud avanzado: diseño de VPCs, segmentación de redes, peering, Transit Gateway y conectividad híbrida
  • Seguridad cloud: IAM, SCPs, config rules, Security Hub y herramientas de CSPM para postura de seguridad
  • FinOps: herramientas de cost management, estrategias de Reserved Instances y Savings Plans, y análisis de anomalías de costo

Soft Skills

  • Mentalidad de ingeniería de confiabilidad: diseñar para el fallo antes de diseñar para el caso nominal
  • Documentación rigurosa de decisiones de arquitectura para que otros puedan operar y evolucionar la infraestructura
  • Colaboración con equipos de desarrollo para diseñar aplicaciones que aprovechan las capacidades cloud sin crear dependencias excesivas
  • Criterio de costos: evaluar el trade-off entre rendimiento, disponibilidad y costo en cada decisión de arquitectura
  • Comunicación del riesgo técnico de infraestructura en términos de impacto de negocio para stakeholders no técnicos
  • Proactividad para identificar problemas de capacidad, seguridad o costos antes de que se conviertan en incidentes

Casos de uso reales

Contexto

Las aplicaciones con usuarios globales o requisitos de alta disponibilidad necesitan arquitecturas que toleran el fallo de una región completa sin interrumpir el servicio.

Ejemplos reales

  • Arquitectura activa-pasiva con failover automático ante la caída de una región completa
  • Distribución de tráfico global con Route 53 o Cloud Load Balancing según latencia y disponibilidad
  • Replicación de datos entre regiones con RPO y RTO definidos y probados periódicamente
  • CDN para assets estáticos con edge caching que reduce la carga en los servidores de origen

Contexto

El costo cloud puede escalar desproporcionadamente si no se gestiona proactivamente. Las organizaciones sin FinOps frecuentemente descubren facturas inesperadamente altas cuando el uso crece.

Ejemplos reales

  • Auditoría de recursos subutilizados: instancias idle, volúmenes sin adjuntar y snapshots antiguos
  • Implementación de Reserved Instances y Savings Plans para workloads predecibles reduciendo costos un 30-60%
  • Tagging strategy completa que atribuye costos por equipo, entorno y producto
  • Alertas de anomalías de costo que detectan incrementos inesperados antes de que impacten la factura mensual

Contexto

Una red cloud mal diseñada es la superficie de ataque más amplia de la infraestructura. El aislamiento de red correcto limita el radio de impacto de cualquier compromiso.

Ejemplos reales

  • Diseño de VPCs con subnets públicas, privadas y de datos con segmentación por función
  • Implementación de Security Groups y NACLs con el principio de mínimo privilegio
  • Conectividad privada con servicios cloud sin exponer el tráfico a internet (VPC Endpoints)
  • Arquitectura hub-and-spoke con Transit Gateway para gestionar conectividad entre múltiples VPCs

Contexto

La infraestructura como código es el prerequisito de cualquier operación cloud reproducible, auditable y escalable. Sin IaC, cada entorno es un copo de nieve difícil de replicar.

Ejemplos reales

  • Módulos Terraform reutilizables para los patrones de infraestructura más frecuentes del equipo
  • Pipelines de CI que ejecutan plan, validate y security checks antes de cada apply
  • Gestión de múltiples entornos (dev, staging, prod) con el mismo código y distintos valores de variables
  • Detección automática de drift entre el estado declarado en Terraform y los recursos reales en cloud

Contexto

Los planes de DR que no se prueban regularmente son hipótesis, no garantías. Un Cloud Engineer diseña y prueba los mecanismos de recuperación antes de que sean necesarios.

Ejemplos reales

  • Definición y validación del RTO y RPO reales mediante simulacros de DR programados
  • Estrategias de backup con point-in-time recovery para bases de datos críticas
  • Runbooks automatizados para los escenarios de failover más probables
  • Chaos engineering controlado para validar que los mecanismos de resiliencia funcionan en producción

Preguntas básicas

Una región es un área geográfica con múltiples centros de datos. Una zona de disponibilidad (AZ) es un centro de datos o grupo de centros de datos dentro de una región con energía, red y conectividad independientes. Para alta disponibilidad dentro de una región: desplegar recursos en al menos dos o tres AZs para tolerar el fallo de una AZ completa. Para resiliencia ante el fallo de una región: arquitectura multi-región con replicación de datos y failover de tráfico. La alta disponibilidad multi-AZ cubre la mayoría de los casos; la multi-región solo se justifica cuando los requisitos de disponibilidad o las regulaciones de residencia de datos lo exigen dado su mayor complejidad y costo.
Mínimo privilegio significa que cada usuario, rol o servicio tiene solo los permisos necesarios para su función específica, nada más. Implementación práctica: roles IAM por función (developer read-only en producción, deploy role para el pipeline de CI/CD, database admin role restringido a RDS), sin usuarios IAM individuales con acceso de larga duración cuando hay alternativa más segura, Service Control Policies en AWS Organizations para establecer límites que ningún rol en la cuenta puede superar, y auditoría periódica con IAM Access Analyzer para detectar permisos no usados. La revisión del Access Advisor de cada rol muestra los servicios que no se han usado en los últimos 90 días y son candidatos para eliminar del policy.
Habilitar automated backups con retención de al menos 7 días para point-in-time recovery. Habilitar Multi-AZ para alta disponibilidad síncrona con failover automático en segundos ante fallo del primario. Para DR entre regiones, configurar Cross-Region Automated Backups que replican los snapshots a una región secundaria con el lag definido por el RPO. Probar la restauración periódicamente midiendo el tiempo real de recuperación para verificar que el RTO es alcanzable. Los backups que nunca se han restaurado son hipótesis, no garantías.
Reserved Instances (RIs) comprometen un tipo de instancia específico en una región por 1 o 3 años a cambio de descuentos del 30-60% sobre on-demand. Savings Plans ofrecen un descuento similar pero a cambio de comprometerse con un gasto mínimo por hora en cómputo, con mayor flexibilidad para cambiar el tipo de instancia. RIs son óptimas cuando el workload tiene un tipo de instancia estable y predecible. Savings Plans son preferibles cuando hay variabilidad en el tipo de instancia o cuando se usan múltiples servicios de cómputo (EC2, Lambda, Fargate). Para instancias Spot: workloads tolerantes a interrupciones como batch processing, CI/CD runners o stateless workers que pueden ahorrar hasta un 90%.
Activar inmediatamente AWS Cost Explorer con granularidad diaria para identificar en qué servicio y en qué cuenta comenzó el incremento. Revisar el Cost and Usage Report para identificar el recurso específico con mayor cambio. Causas frecuentes: instancias no terminadas después de un experimento, un bucket S3 con transferencia de datos masiva (data egress), un loop de código que hace llamadas a APIs de AWS en exceso, o credenciales comprometidas usadas para minar criptomonedas. Contener el costo inmediatamente si es un recurso no necesario. Configurar alertas de presupuesto con notificaciones al 80% y al 100% del gasto mensual esperado para que esto no vuelva a detectarse a fin de mes.
Un VPC Endpoint permite que los recursos dentro de una VPC se comuniquen con servicios de AWS (S3, DynamoDB, SecretsManager) a través de la red privada de AWS sin que el tráfico salga a internet. Sin VPC Endpoints, las instancias en subnets privadas necesitan un NAT Gateway para acceder a estos servicios, exponiendo el tráfico a la red pública y añadiendo costo de transferencia. Con VPC Endpoints: el tráfico nunca sale de la red de AWS, los bucket policies pueden restringir el acceso solo desde la VPC específica, y se elimina el costo del NAT Gateway para ese tráfico. Son especialmente críticos para el acceso a S3 y DynamoDB desde instancias que manejan datos sensibles.
La opción más segura es usar AWS Secrets Manager o Parameter Store integrado con Kubernetes a través del Secrets Store CSI Driver: los secretos se almacenan en AWS, se accede a ellos a través de IAM roles asignados a los pods con IRSA (IAM Roles for Service Accounts), y se montan como archivos en el filesystem del pod sin pasar por etcd de Kubernetes donde los Kubernetes Secrets nativos se almacenan en Base64 (no cifrado real). Evitar hardcodear secretos en variables de entorno del deployment manifest que se almacenan en git. Habilitar la rotación automática de secretos en Secrets Manager para que la aplicación siempre use credenciales frescas.
Implementar AWS Organizations con una estrategia de cuentas por equipo o entorno para aislamiento de billing. Tagging obligatorio de todos los recursos con tags de equipo, proyecto y entorno usando SCPs que rechacen la creación de recursos sin los tags requeridos. Configurar AWS Budgets por cuenta con alertas a los owners de cada cuenta. Publicar un dashboard compartido de costos en Cost Explorer accesible para cada equipo mostrando solo sus cuentas. Revisiones mensuales de FinOps donde cada equipo reporta sus optimizaciones y anomalías. La responsabilidad de costos solo funciona cuando los equipos tienen visibilidad de su gasto y la capacidad de actuar sobre él.

Preguntas técnicas

VPC con al menos tres capas de subnets: pública (solo ALB y NAT Gateway), privada de aplicación (instancias EC2 o ECS tasks), y privada de datos (RDS, ElastiCache). Security Groups en cascada: el ALB acepta tráfico de internet (80/443), las instancias de aplicación solo aceptan tráfico del security group del ALB en el puerto de la aplicación, y las bases de datos solo aceptan tráfico del security group de la aplicación en el puerto del motor. NACLs como segunda línea de defensa a nivel de subnet. VPC Endpoints para S3 y Secrets Manager. VPC Flow Logs habilitados para auditoría de tráfico. Esta arquitectura garantiza que ningún componente de la capa de aplicación o datos es accesible directamente desde internet.
Para ECS: Application Auto Scaling con políticas basadas en métricas de CloudWatch. Las métricas de negocio (número de mensajes en una cola SQS, peticiones por segundo de la aplicación, latencia percentil) se publican como métricas custom en CloudWatch. La política de scaling reactiva ajusta el número de tasks cuando la métrica cruza el umbral. Para Kubernetes: HPA (Horizontal Pod Autoscaler) consume métricas de la API de métricas del cluster o de adaptadores de métricas externas (Prometheus Adapter, KEDA). KEDA es especialmente potente: permite escalar directamente en función del lag de una cola de Kafka, el número de mensajes en SQS, o cualquier métrica externa sin escribir código de scaling propio.
AWS Secrets Manager con rotación automática gestiona este proceso. Cuando se activa la rotación, Secrets Manager crea nuevas credenciales en la BD, las guarda como la nueva versión del secreto, verifica que son válidas, y marca la versión anterior como AWSPREVIOUS. Durante el período de transición, ambas versiones son válidas simultáneamente. Las aplicaciones que recuperan el secreto en cada conexión obtienen automáticamente las nuevas credenciales. Para las aplicaciones con connection pools persistentes, implementar un mecanismo de refresh del pool cuando la autenticación falla con las credenciales actuales: el cliente obtiene las nuevas credenciales y reconecta. Este patrón garantiza zero-downtime durante la rotación.
Los tres pilares en el ecosistema AWS. Métricas: CloudWatch Metrics para las métricas de infraestructura de AWS y métricas custom de la aplicación, con dashboards por servicio y alarmas con acciones automáticas. Logs: CloudWatch Logs con grupos de logs estructurados por servicio, Log Insights para queries ad-hoc, y exportación a S3 para retención de largo plazo. Trazas: AWS X-Ray para distributed tracing entre servicios, con correlation de traces con logs usando el trace ID. Para organizaciones que prefieren herramientas agnósticas al proveedor, OpenTelemetry como capa de instrumentación que envía a X-Ray, Datadog, o cualquier backend OTLP. La clave es que el correlation ID del trace debe propagarse en todos los requests entre servicios para poder seguir el camino completo de una petición.
Implementar just-in-time access con herramientas como AWS IAM Identity Center (SSO) con acceso temporal mediante elevación de privilegios. El ingeniero solicita acceso elevado temporal (máximo 1-4 horas), el sistema registra la solicitud con la razón, y el acceso se otorga automáticamente o con aprobación. Session Manager de AWS Systems Manager permite acceso SSH a instancias EC2 sin exponer puertos SSH, con logging completo de la sesión en S3 o CloudWatch Logs. Para bases de datos: acceso a través de un bastion administrado o RDS Proxy con autenticación IAM temporal. Todos los accesos a producción deben quedar registrados con la identidad del usuario, la hora, la duración y las acciones realizadas para auditoría.
Separar en tres niveles. Módulos de infraestructura base (repositorio compartido): abstracciones reutilizables para los recursos más frecuentes como VPC estándar, cluster de ECS, RDS con las mejores prácticas de seguridad baked in. Los equipos consumen estos módulos sin poder sobrescribir los controles de seguridad. Módulos de entorno (repositorio por equipo): composición de los módulos base con los valores específicos del equipo (tamaños, regiones, configuración). Root modules por entorno: dev, staging, prod con sus propios state files en S3 y locking en DynamoDB. Las variables sensibles no se hardcodean nunca en el código: se inyectan como variables de entorno en el pipeline o se leen desde Secrets Manager. Versionar los módulos con semantic versioning para que los teams controlen cuándo adoptan cambios de los módulos base.
Lambda para la capa de cómputo: escala de cero a miles de instancias concurrentes en segundos sin gestión de servidores. API Gateway para la capa HTTP con rate limiting, autenticación y throttling. DynamoDB para almacenamiento con on-demand billing que escala automáticamente sin provisioning. SQS para desacoplar la ingesta de eventos del procesamiento cuando los picos son muy abruptos. EventBridge para orquestación de workflows entre funciones Lambda. Consideraciones críticas: cold starts en Lambda (mitigables con provisioned concurrency para funciones críticas), límites de concurrencia por función y por cuenta (configurar reserved concurrency para funciones críticas), y el costo por invocación que puede superar al de instancias persistentes si el tráfico es muy alto y constante.
Lambda: para workloads event-driven de corta duración (menos de 15 minutos), con tráfico muy variable o esporádico, y donde la gestión de servidores es un overhead no justificado. ECS Fargate: para aplicaciones containerizadas sin experiencia de Kubernetes, con carga predecible y donde la abstracción del servidor es deseada. EKS: cuando se necesita Kubernetes para portabilidad entre clouds, ecosistema rico de herramientas (service mesh, GitOps, KEDA) o cuando el equipo ya tiene expertise. EC2: para workloads con requisitos específicos de hardware, que necesitan acceso directo al sistema operativo, o cuando el costo es la prioridad absoluta con Reserved Instances. La decisión también tiene en cuenta la expertise del equipo: el mejor servicio es el que el equipo puede operar con confianza.

Preguntas avanzadas

PCI-DSS requiere aislamiento del entorno de datos de tarjetas (CDE) del resto de la infraestructura. Arquitectura en capas con segmentación estricta: el CDE en una VPC separada con acceso exclusivo desde la capa de aplicación de pagos, nunca directamente desde internet. Controles obligatorios: cifrado de datos en reposo con CMKs gestionadas por KMS, TLS 1.2+ en tránsito, logging completo de todos los accesos al CDE en CloudTrail y envío inmutable a S3. Para el 99.99% de disponibilidad (menos de 53 minutos de downtime anuales): multi-AZ activo-activo para todos los componentes del path crítico, multi-región activo-pasivo con failover automatizado sub-minuto, circuit breakers para las dependencias externas, y pruebas de chaos engineering mensuales que verifican que los mecanismos de failover funcionan.
Comenzar con un inventario y clasificación de aplicaciones usando las 7 Rs de migración: Retire (sistemas que se van a retirar), Retain (sistemas que se quedan on-premise por ahora), Rehost (lift-and-shift a EC2), Replatform (pequeñas optimizaciones: RDS en lugar del motor on-premise), Refactor/Re-architect (rediseñar para cloud-native). La mayor parte del valor con menor riesgo está en Rehost y Replatform: migrar rápido con AWS Migration Service y optimizar después. Las aplicaciones más críticas o que se benefician más de cloud-native merecen Refactor pero requieren más tiempo y riesgo. Establecer un Landing Zone con las cuentas, redes y controles de seguridad correctos antes de migrar la primera aplicación. Definir criterios claros de éxito para cada wave de migración.
Seguridad en múltiples capas. Tiempo de desarrollo: tfsec o Checkov en el pipeline de Terraform que bloquea planes con misconfigurations críticas (bucket S3 público, security group con 0.0.0.0/0 en puertos sensibles). Tiempo de deploy: AWS Config Rules o Security Hub evaluando el estado de seguridad en continuo con alertas automáticas ante desviaciones. En producción: AWS GuardDuty para detección de amenazas en logs de CloudTrail y VPC Flow Logs, Macie para identificación de datos sensibles en S3, y AWS Security Hub como panel centralizado que agrega findings de todos los servicios de seguridad. Para multi-cuenta: AWS Organizations con SCPs que previenen a nivel organizacional las configuraciones prohibidas más críticas. El objetivo es que los problemas de seguridad sean detectados y bloqueados en el pipeline, no descubiertos en producción.
Una reducción del 30% en una plataforma a esa escala requiere un programa de FinOps estructurado, no solo ajustes puntuales. Análisis por servicio: identificar los cinco servicios que representan el 80% del gasto. Para cada uno, evaluar: ¿es el tamaño correcto para la carga real? ¿hay workloads que pueden moverse a Spot o Savings Plans? ¿hay datos que pueden moverse a tiers de almacenamiento más baratos? Típicamente las mayores oportunidades son: rightsizing de instancias sobredimensionadas (20-30% del ahorro), Reserved Instances para workloads predecibles (15-25%), eliminación de recursos huérfanos y data transfer optimization. Instrumentar el costo como una métrica de producto: cada equipo ve su gasto semanal con tendencia. La responsabilidad distribuida del costo produce optimizaciones continuas sin necesitar un equipo central dedicado.
El desafío del GDPR a escala es la proliferación de copias de datos de usuarios. Implementar un registro central de datos personales que mapea qué datos de qué usuario viven en qué bucket, tabla y partición. Para el right to be forgotten: diseñar los datos con crypto-shredding donde los datos del usuario se cifran con una clave única por usuario en KMS. Al recibir una solicitud de eliminación, eliminar la clave del usuario en KMS: los datos permanecen físicamente pero son irrecuperables. Para datos en backups históricos donde el crypto-shredding no estaba implementado desde el inicio: documentar el período de retención máximo de los backups y garantizar que se purgan según la política. AWS Macie para descubrimiento automático de datos personales en S3 que no estaban catalogados.
El lock-in tiene costos reales pero también beneficios: los servicios nativos frecuentemente ofrecen mejor integración, operación más simple y menor costo que las alternativas agnósticas al proveedor. La evaluación correcta no es eliminar el lock-in sino gestionar el riesgo estratégicamente. Para cada servicio propietario evaluar: ¿existe un equivalente en otros proveedores cloud? ¿cuánto costaría migrar si fuera necesario? ¿la funcionalidad justifica la dependencia? Estrategias de mitigación sin eliminar los beneficios: abstraer las dependencias en capas de servicio propias que pueden reimplementarse para otro proveedor (una interfaz de storage que hoy usa S3 puede mañana usar GCS), usar OpenTelemetry para instrumentación agnóstica, y evitar el lock-in en los componentes de datos críticos donde la migración sería más costosa.

Errores comunes en entrevistas

Cada decisión de arquitectura cloud tiene un costo. Un Cloud Engineer que propone multi-AZ, multi-región y alta redundancia para todos los componentes sin evaluar si el nivel de disponibilidad requerido justifica ese costo demuestra falta de criterio FinOps. Los entrevistadores con responsabilidad de presupuesto preguntan siempre cuánto costaría la arquitectura propuesta.
Los security groups demasiado permisivos, los buckets S3 públicos por defecto y los roles IAM con acceso amplio son los errores más frecuentes y más costosos de corregir después. Un Cloud Engineer que no menciona el principio de mínimo privilegio, el cifrado y la segmentación de red en su diseño está proponiendo arquitecturas que requerirán trabajo de remediación posterior.
Terraform sin una estrategia de gestión del estado en equipo produce conflictos, corrupción del estado y pérdida de recursos. Un candidato que describe su uso de Terraform sin mencionar el backend remoto, el locking con DynamoDB y la organización de módulos demuestra experiencia con Terraform en proyectos individuales, no en equipos.
Un plan de DR que no se ha ejecutado nunca en condiciones controladas es una hipótesis. Los entrevistadores con experiencia en operaciones preguntan cuándo fue la última vez que se probó el failover de la base de datos, cuánto tardó realmente, y qué problemas inesperados aparecieron durante la prueba. No tener respuesta a esa pregunta es una señal de alerta operacional.
Kubernetes resuelve problemas reales a escala pero añade una capa de complejidad operacional significativa. Un Cloud Engineer que propone EKS para una aplicación que podría correr perfectamente en ECS Fargate o incluso en Lambda demuestra preferencia por la tecnología sobre el criterio de adecuación al problema. Los entrevistadores de equipos con costos de operación reales preguntan por qué Kubernetes y no la alternativa más simple.
Una arquitectura cloud que no tiene métricas, logs y alertas configuradas no está lista para producción. Un Cloud Engineer que describe su arquitectura sin mencionar cómo sabe que está funcionando correctamente, cómo detecta un problema antes de que el usuario lo reporte, y cómo diagnostica la causa demuestra una visión incompleta de la operación de sistemas en producción.

Las mejores oportunidades de trabajo para Ingeniero Cloud

Todas las ofertas de internet en un solo lugar

EMA Salud
EMA Saludhace 3 semanas

Director de Ingenieria

Si eres CTO, esta oferta es para ti. Se requiere conocimientos en Stakeholder Management, Arquitectura de Software.

$5,700 - $7,400/mes Hibrido Inglés avanzado