DEV Community: Henry Niama

I built the AWS platform that every DevOps engineer would want to have

Henry Niama — Wed, 04 Mar 2026 20:07:32 +0000

The Discovery

A few months ago, while talking with a DevOps Engineer friend, he shared one of his frustrations:

"In some of the companies and projects I've worked on, I've had to build all the infrastructure: VPCs, subnets, EKS... plus set up the deployment pipeline, both for the platform and the microservice. But as a DevOps Engineer, what I really want is to focus on deploying the microservice. My dream would be to simply run kubectl apply... and have everything work."

That's when it became clear: the DevOps Engineer ends up fighting with VPCs and subnets when they should really be focusing on automating application deployments.

That reflection changed everything.

The Missing Separation of Responsibilities

This project was born precisely to solve that clash of responsibilities.

We assume the role of Cloud/Platform Engineer and build the base infrastructure shell so that the DevOps/App Delivery team can then deploy applications on an already prepared platform.

In our approach:

Cloud/Platform Engineering (this repository) builds the foundation: network, infrastructure, identity, remote state, cluster, registry, and infrastructure pipeline.
DevOps/App Delivery (application repository, later) consumes outputs from this foundation to deploy microservices with speed and less risk.

It's not bureaucracy. It's organizational and technical design for scaling. As a Cloud/Platform Engineer, my job isn't for every DevOps Engineer to recreate infrastructure. My job is to build the platform once and have them consume it.

What I Built

I decided to materialize this vision in a real project:

A complete, reusable, and open source AWS platform.

See full diagram on GitHub

As you can see, we take responsibility for preparing the complete infrastructure shell so that a DevOps/App team can then focus on deploying product, not fighting with base infrastructure.

Specifically, we leave ready:

AWS networks separated by environment (test and prod).
EKS clusters per environment.
ECR repositories per environment for images.
Secure authentication via OIDC in GitHub Actions.
Terraform remote state with locking.
Infrastructure CI/CD with clear rules per environment.

We're not trying to "do everything in one repo". We're trying to collaborate better: platform on one side, applications on the other, with a clear contract between both.

Technologies we use to build this foundation

AWS: VPC, EKS, ECR, IAM, S3, DynamoDB
Terraform: to build AWS resources with reusable modules
GitHub Actions: to run the infrastructure pipeline per environment
OIDC: Federated authentication without static Access Keys
EKS Access Entries: to control who enters the cluster without relying only on manual configurations

The 4 Pillars That Make the Difference

1. Environment Separation (For Real)

Most say "we have TEST and PROD separated" but they share a VPC.

I went further:

TEST → VPC 10.110.0.0/16
PROD → VPC 10.111.0.0/16

Completely independent Terraform states per environment and separate variables per tfvars.

The pipeline dynamically selects backend and variables based on the branch, avoiding collisions between environments and zero shared resources.

Why?

Because on a Friday at 6 PM, someone is going to make a change in TEST. And if they share resources, PROD goes down.

With this separation, I can destroy/modify TEST without fear. That peace of mind is priceless.

2. OIDC: The Security Innovation That Changes Everything

Here's the gem of the project.
The problem everyone has:

AWS credentials stored in GitHub Secrets
Example:
- AWS_ACCESS_KEY_ID: AKIAXXXXX
- AWS_SECRET_ACCESS_KEY: xxxxx

If someone commits those keys; it's a disaster

My solution: OIDC

No static keys in GitHub.

This directly improves:

Operational security.
Credential expiration.
Control via trust policy.
Reduced attack surface.
Zero permanent credentials: Zero risk.

And the best part: the Trust Policy ensures that only my repository can assume the role.

3. Outputs: The Bridge Between Platform and Applications

This is where the separation of roles comes to life.
The platform doesn't deliver "raw infrastructure", but ready-to-use outputs:

Output	Example
ECR_URL	123456.dkr.ecr.us-east-1.amazonaws.com/app
EKS_CLUSTER	eksdevops1720testXX
EKS_ENDPOINT	https://XXXXX.eks.amazonaws.com
REGION	us-east-1

See Outputs on GitHub

How the DevOps Engineer consumes them in their repo (pipeline):

# Pipeline that leverages platform outputs
docker push $ECR_URL/mi-app:latest
aws eks update-kubeconfig --name $EKS_CLUSTER
kubectl apply -f k8s/

Direct console example:

aws eks update-kubeconfig --name eksdevops1720testXX
kubectl apply -f deployment.yaml
# and it works... No additional configuration.

That's it.

The DevOps Engineer,

Doesn't need to deeply understand how the VPC is configured.
Doesn't need to fully understand route tables.
Doesn't need to be an expert in EKS cluster setup.

They only need to deploy their application on the previously deployed platform.

4. Intelligent Pipeline: Fast in TEST, Safe in PROD

I designed the pipeline thinking about speed vs control:
TEST (Speed)

git push origin dev/**.
Terraform deploys automatically.
No approvals.
Feedback in ~15 minutes.

PROD (Control)

Pull Request to main.
Terraform plan (team review).
Mandatory manual approval - Merge → deployment

What's innovative:

OIDC authentication (no keys).
Remote state with locking (no conflicts).
Saved artifacts (easy rollback).
Approvals only where they matter.

This enables clean deployments with valuable artifacts:

Cluster Access: EKS Access Entries

AWS launched something revolutionary: Access Entries. Instead of manually editing ConfigMaps, you can now define Cluster access directly in Terraform:

eks_access_entries = {
  platform_engineer = {
    principal_arn = "arn:aws:iam::123456:user/henry"
    policies = {
      admin = {
        policy_arn = "AmazonEKSClusterAdminPolicy"
      }
    }
  }

  devops_team = {
    principal_arn = "arn:aws:iam::123456:role/gh-oidc-role"
    policies = {
      deploy = {
        policy_arn = "AmazonEKSClusterAdminPolicy"
      }
    }
  }
}

What changes with Access Entries?

AWS-managed - No more manual ConfigMaps.
Native IAM integration - Roles and users directly in AWS.
Automatic validation - Terraform validates before applying.
Complete audit - CloudTrail logs every action.

What it means in practice

When a DevOps Engineer needs cluster access, I simply:

Add their IAM role in Terraform (in our case, in the module).
Run terraform apply
Done: They have immediate cluster access.

EKS Clusters:

Cluster Access (as DevOps Engineer):

List of configured EKS Access Entries (example):

This is what we implemented in the project. Where the separation of responsibilities comes into action:

I as Cloud/Platform Engineer manage WHO has access.
They use that access to deploy.
Nobody touches ConfigMaps without risk of breaking anything.
Everything versioned in Git.

Real Scope of This Project

This repository doesn't deploy microservices directly. Its purpose is to build the solid foundation for that to happen well later.

It also doesn't include yet:

complete workload observability,
app ingress/controller,
application layer autoscaling.

What it does:

Defines networks, clusters, repositories (ECR), and infrastructure pipeline.
Publishes ready-to-use outputs for other repos to deploy applications.
Establishes modern security (OIDC, temporary IAM roles).

What it doesn't include (by design):

Complete workload observability
Application ingress/controller
Application layer autoscaling

This is not an accidental gap.
It's a conscious scope decision:

The base platform ensures security and governance.
Application delivery is managed in separate repos.
Separation of responsibilities avoids friction and chaotic scaling.

Considerations Before Using in Production

This foundation is solid, but for real production it's worth reinforcing:

Observability: EKS control plane logs, metrics, and alerts.
EKS endpoint hardening: restrict public_access_cidrs or private-only endpoint in prod.
More granular IAM: reduce broad permissions and lock down to specific resources.
CI security: IaC/policy/image checks.
Workload autoscaling: HPA + Cluster Autoscaler/Karpenter.
HA/cost architecture: evaluate NAT per AZ based on RTO/RPO and budget.

Who This Platform Is For

If You're a Cloud/Platform Engineer:

Use it as a foundation for your organization or projects.
Adapt the modules to your needs.
Contribute improvements to the project.

If You're a DevOps Engineer:

Use it as a reference for what you need.
Focus on deploying applications, not infrastructure.

What's Next

This platform is the starting point, not the final destination.

Next evolutions:

Multi-region (disaster recovery)
Service Mesh (advanced observability)
GitOps (ArgoCD/FluxCD)
Security policies (OPA)

But the fundamentals are already here:

Separation of responsibilities
Security by design
Real automation
Reusability

And it's ready to use today.

Repository

Everything is documented, tested, and with steps to build and deploy:

📦 Repository: github.com/hsniama/infra-devops-aws

*Clone. Adapt. Deploy. Contribute. *

Open Source and Collaboration

If you're interested in this line of work, you can collaborate with ideas or PRs:

IAM hardening per resource.
End-to-end observability.
Policy-as-code in pipeline.
Blueprint of the application repo that consumes outputs.

Remember that The best platform is built together.

Final Reflection

The best automation isn't the one that does more things. It's the one that better defines responsibilities and reduces systemic risk.

This project is about that: as a platform team, first designing the right shell so that deploying applications later is simpler, safer, and more repeatable.

⭐ Give it a star on GitHub
🔄 Share with your team
💬 Leave me your comments
🤝 Contribute to the project

Let's build better platforms, together.

Tags: AWS, Terraform, PlatformEngineering, DevOps, CloudArchitecture, OpenSource, OIDC, Kubernetes, AWS, Cloud

Author: Henry Niama
Role: Systems Engineer
GitHub: @hsniama
LinkedIn: Henry Niama

Construí la plataforma AWS que todos los DevOps querrían tener

Henry Niama — Wed, 04 Mar 2026 17:42:56 +0000

El Descubrimiento

Hace unos meses, mientras conversaba con un amigo DevOps Engineer, me contaba una de sus frustraciones:

"En algunas de las empresas y proyectos en los que he trabajado, me ha tocado construir toda la infraestructura: VPCs, subnets, EKS… además de armar el pipeline de despliegue, tanto de la plataforma como del microservicio. Pero como DevOps, lo que realmente quiero es enfocarme en desplegar el microservicio. Mi sueño sería simplemente hacer kubectl apply… y que todo funcione."

Ahí lo vi claro: el DevOps Engineer termina peleando con VPCs y subnets cuando en realidad debería enfocarse en automatizar despliegues de aplicaciones.

Esa reflexión cambió todo.

La Separación de Responsabilidades que Falta

Este proyecto nace justamente para resolver ese choque de responsabilidades.

Nosotros asumimos el rol de Cloud/Platform Engineer y construimos el cascarón-base de infraestructura para que luego el equipo de DevOps/App Delivery despliegue aplicaciones sobre una plataforma ya preparada.

En nuestro enfoque:

Cloud/Platform Engineering (este repositorio) construye la base: red, infraestructura, identidad, estado remoto, clúster, registro y pipeline de infraestructura.
DevOps/App Delivery (repositorio de aplicaciones, después) consume outputs de esta base para desplegar microservicios con velocidad y menos riesgo.

No es burocracia. Es diseño organizacional y técnico para escalar. Como Cloud/Platform Engineer, mi trabajo no es que cada DevOps recree infraestructura. Mi trabajo es construir la plataforma una vez y que ellos la consuman.

Lo Que Construí

Decidí materializar esta visión en un proyecto real:

Una plataforma AWS completa, reutilizable y open source.

Ver diagrama completo en GitHub

Como se observa, tomamos la responsabilidad de preparar el cascarón completo de infraestructura para que luego un equipo DevOps/App pueda enfocarse en desplegar producto, no en pelear con infraestructura base.

En concreto, dejamos listo:

Redes en AWS separadas por ambiente (test y prod).
Clústeres EKS por ambiente.
Repositorios ECR por ambiente para imágenes.
Autenticación segura por OIDC en GitHub Actions.
Estado remoto de Terraform con bloqueo.
CI/CD de infraestructura con reglas claras por ambiente.

No buscamos “hacer todo en un repo”. Buscamos colaborar mejor: plataforma por un lado, aplicaciones por otro, con un contrato claro entre ambos.

Tecnologías que usamos para construir esta base

AWS: VPC, EKS, ECR, IAM, S3, DynamoDB
Terraform: para construir recursos de AWS con módulos reutilizables
GitHub Actions: para ejecutar el pipeline de infraestructura por ambiente
OIDC: Autenticación federada sin Access Keys estáticas
EKS Access Entries: para controlar quién entra al clúster sin depender solo de configuraciones manuales

Los 4 Pilares que Hacen la Diferencia

1. Separación de Ambientes (De Verdad)

La mayoría dice "tenemos TEST y PROD separados" pero comparten VPC.

Yo fui más allá:

TEST → VPC 10.110.0.0/16
PROD → VPC 10.111.0.0/16

Estados de Terraform totalmente independientes por ambiente y variables separadas por tfvars.

El pipeline selecciona dinámicamente backend y variables según la rama, evitando colisiones entre entornos y cero recursos compartidos.

¿Por qué?

Porque un viernes a las 6 PM, alguien va a hacer un cambio en TEST. Y si comparten recursos, PROD se cae.

Con esta separación, puedo destruir/modificar TEST sin miedo. Esa tranquilidad no tiene precio.

2. OIDC: La Innovación de seguridad que cambia todo

Aquí está la joya del proyecto.
El problema que todos tienen:

Credenciales AWS guardadas en GitHub Secrets
Ejemplo:
- AWS_ACCESS_KEY_ID: AKIAXXXXX
- AWS_SECRET_ACCESS_KEY: xxxxx

Si alguien hace commit de esas keys; es un desastre

Mi solución: OIDC

Sin llaves estáticas en GitHub.

Esto mejora de forma directa:

Seguridad operativa.
Caducidad de credenciales.
Control por trust policy.
Reducción de superficie de ataque.
Cero credenciales permanentes: Cero riesgo.

Y lo mejor: el Trust Policy asegura que solo mi repositorio puede asumir el rol.

3. Outputs: El Puente Entre Plataforma y Aplicaciones

Aquí es donde la separación de roles cobra vida.
La plataforma no entrega “infraestructura cruda”, sino outputs listos para usar:

Output	Ejemplo
ECR_URL	123456.dkr.ecr.us-east-1.amazonaws.com/app
EKS_CLUSTER	eksdevops1720testXX
EKS_ENDPOINT	https://XXXXX.eks.amazonaws.com
REGION	us-east-1

Ver Outputs en GitHub

Cómo los consume el DevOps Engineer en su repo (pipeline):

# Pipeline que aprovecha los outputs de la plataforma
docker push $ECR_URL/mi-app:latest
aws eks update-kubeconfig --name $EKS_CLUSTER
kubectl apply -f k8s/

Ejemplo directo en consola:

aws eks update-kubeconfig --name eksdevops1720testXX
kubectl apply -f deployment.yaml
# y funciona... Sin configuración adicional.

Eso es todo.

El DevOps Engineer,

No necesita saber profundamente cómo está configurada la VPC.
No necesita entender por completo route tables.
No necesita ser experto en el levantamiento del cluster EKS.

Solo necesita desplegar su aplicación en la plataforma previamente desplegada.

4. Pipeline Inteligente: Rápido en TEST, Seguro en PROD

Diseñé el pipeline pensando en velocidad vs control:
TEST (Velocidad)

git push origin dev/**.
Terraform despliega automáticamente.
Sin aprobaciones.
Feedback en ~15 minutos.

PROD (Control)

Pull Request a main.
Terraform plan (revisión del equipo).
Aprobación manual obligatoria - Merge → despliegue

Lo innovador:

Autenticación OIDC (sin keys).
Estado remoto con locking (sin conflictos).
Artifacts guardados (rollback fácil).
Aprobaciones solo donde importan.

Esto permite tener despliegues limpios con artifacts de valor:

Acceso al Cluster: EKS Access Entries

AWS lanzó algo revolucionario: Access Entries. En lugar de editar ConfigMaps manualmente, ahora se puede definir el acceso al Cluster directamente en Terraform:

eks_access_entries = {
  platform_engineer = {
    principal_arn = "arn:aws:iam::123456:user/henry"
    policies = {
      admin = {
        policy_arn = "AmazonEKSClusterAdminPolicy"
      }
    }
  }

  devops_team = {
    principal_arn = "arn:aws:iam::123456:role/gh-oidc-role"
    policies = {
      deploy = {
        policy_arn = "AmazonEKSClusterAdminPolicy"
      }
    }
  }
}

¿Qué cambia con Access Entries?

Gestionado por AWS - No más ConfigMaps manuales.
Integración nativa con IAM - Roles y usuarios directamente en AWS.
Validación automática - Terraform valida antes de aplicar.
Auditoría completa - CloudTrail registra cada acción.

Lo que significa en la práctica

Cuando un DevOps Engineer necesita acceso al cluster, yo simplemente:

Agrego su rol IAM en Terraform (en nuestro caso, en el módulo).
Ejecuto terraform apply
Listo: Tiene acceso inmediato al cluster.

EKS Clusters:

Acceso al Cluster (como DevOps Engineer):

Lista de EKS Access Entries configurados (ejemplo):

Esto es lo que implementamos en el proyecto. En donde la separación de responsabilidades entra en acción:

Yo como Cloud/Platform Engineer gestiono QUIÉN tiene acceso.
Ellos usan ese acceso para desplegar.
Nadie toca ConfigMaps sin riesgo de romper nada.
Todo versionado en Git.

Alcance real de este proyecto

Este repositorio no despliega microservicios directamente. Su propósito es construir la base sólida para que eso ocurra bien después.

Tampoco incluye todavía:

observabilidad completa de workloads,
ingress/controller de apps,
autoscaling de capa aplicación.

Lo que sí hace:

Define redes, clústeres, repositorios (ECR) y pipelin de infraestructura.
Publica outputs listos para que otros repos desplieguen aplicaciones.
Establece seguridad moderna (OIDC, IAM roles temporales).

Lo que no incluye (por diseño):

Observabilidad completa de workloads
Ingress/controller de aplicaciones
Autoscaling de la capa aplicación

Esto no es una carencia accidental.
Es una decisión consciente de alcance:

La plataforma base asegura seguridad y gobernanza.
La entrega de aplicaciones se gestiona en repos separados.
La separación de responsabilidades evita fricción y escalamiento caótico.

Consideraciones antes de usarlo en producción

Esta base es sólida, pero para producción real conviene reforzar:

Observabilidad: logs de control plane EKS, métricas y alertas.
Hardening de endpoint EKS: restringir public_access_cidrs o endpoint privado-only en prod.
IAM más granular: reducir permisos amplios y cerrar a recursos concretos.
Seguridad en CI: checks de IaC/policies/images.
Autoscaling de workloads: HPA + Cluster Autoscaler/Karpenter.
Arquitectura HA/costos: evaluar NAT por AZ según RTO/RPO y presupuesto.

Para Quién Es Esta Plataforma

Si Eres Cloud/Platform Engineer:

Úsala como base para tu organización o proyectos.
Adapta los módulos a tus necesidades.
Contribuye mejoras al proyecto.

Si Eres DevOps Engineer:

Úsalo como referencia de lo que necesitas.
Enfócate en desplegar aplicaciones, no en infraestructura.

Lo Que Viene

Esta plataforma es el punto de partida, no el destino final.

Próximas evoluciones:

Multi-región (disaster recovery)
Service Mesh (observabilidad avanzada)
GitOps (ArgoCD/FluxCD)
Políticas de seguridad (OPA)

Pero lo fundamental ya está:

Separación de responsabilidades
Seguridad por diseño
Automatización real
Reutilización

Y está listo para usar hoy.

Repositorio

Todo está documentado, probado y con los pasos para armar y desplegar:

📦 Repositorio: github.com/hsniama/infra-devops-aws

*Clona. Adapta. Despliega. Contribuye. *

Open source y colaboración

Si te interesa esta línea de trabajo, puedes colaborar con ideas o PRs:

Hardening IAM por recurso.
Observabilidad end-to-end.
Policy-as-code en pipeline.
Blueprint del repo de aplicaciones que consuma outputs.

Recordemos que La mejor plataforma se construye entre todos.

Reflexión Final

La mejor automatización no es la que hace más cosas. Es la que define mejor responsabilidades y reduce riesgo sistémico.

Este proyecto va de eso: como equipo de plataforma, diseñar primero el cascarón correcto para que luego desplegar aplicaciones sea más simple, seguro y repetible.

⭐ Dale estrella en GitHub
🔄 Comparte con tu equipo
💬 Déjame tus comentarios
🤝 Contribuye al proyecto

Construyamos mejores plataformas, juntos.

Tags: AWS, Terraform, PlatformEngineering, DevOps, CloudArchitecture, OpenSource, OIDC, Kubernetes, AWS, Cloud

Autor: Henry Niama
Rol: Systems Engineer
GitHub: @hsniama
LinkedIn: Henry Niama