DEV Community: Augusto Valdivia

# En progreso. iam-least-priv-lambda-s3/ README.md .gitignore lambda/ lambda_function.py requirements.txt terraform/ versions.tf provider.tf variables.tf main.tf outputs.tf

Augusto Valdivia — Wed, 31 Dec 2025 14:52:20 +0000

El error de seguridad más común es “Dale Admin y Ya” Cómo solucionarlo con Terraform

Augusto Valdivia for AWS Español ・ Dec 22

#terraform #awsseguridad #awsdevops #awsespañol

iam-least-priv-lambda-s3/ README.md .gitignore lambda/ lambda_function.py requirements.txt terraform/ versions.tf provider.tf variables.tf main.tf outputs.tf ---In progress---

Augusto Valdivia — Wed, 31 Dec 2025 14:51:09 +0000

IAM Least Privilege: What Everyone Gets Wrong (and How to Fix It with Terraform)

Augusto Valdivia for AWS Community Builders ・ Dec 17

#terraform #awssecurity #aws #devops

Optimiza tus recursos con un monitoreo efectivo de costos en AWS Lambdas usando Terraform ¡Descubre cómo puedes maximizar la eficiencia de tus aplicaciones serverless!

Augusto Valdivia — Mon, 29 Dec 2025 19:49:49 +0000

Augusto Valdivia for AWS Español

Oct 15 '24

Monitoreo de Costos de AWS Lambdas con Terraform.

#awslambdacost #terraform #awscost #awscloudwatchdashboard

Comments

3 min read

Cómo solucionarlo con Terraform?

Augusto Valdivia — Tue, 23 Dec 2025 13:13:18 +0000

Augusto Valdivia for AWS Español

Dec 22 '25

El error de seguridad más común es “Dale Admin y Ya” Cómo solucionarlo con Terraform

#terraform #awsseguridad #awsdevops #awsespañol

Comments

2 min read

El error de seguridad más común es “Dale Admin y Ya” Cómo solucionarlo con Terraform

Augusto Valdivia — Mon, 22 Dec 2025 21:28:18 +0000

Cuando estamos bajo presión, casi siempre gana la solución más rápida. Algo falla, alguien necesita acceso, hay una entrega cerca. Entonces hacemos lo típico: damos permisos amplios “por ahora”.

El problema es que lo temporal suele quedarse para siempre.

Menor privilegio no es paranoia. Es intención. Damos solo lo necesario para que los errores tengan un impacto pequeño y la seguridad sea más predecible.

Qué significa menor privilegio de verdad

Menor privilegio significa:

Solo las acciones necesarias
Solo los recursos necesarios
Solo cuando se necesita
Solo para la identidad correcta

Una buena política responde:

Qué necesita hacer este sistema
En qué recursos lo hará
Qué cosas nunca debería poder hacer

IAM no es solo seguridad. IAM también es estabilidad. Un rol con demasiado poder puede romper más cosas más rápido.

Por Qué Importa a Gran Escala

En entornos pequeños, los permisos amplios tal vez no exploten de inmediato. En entornos grandes, tarde o temprano sí.

Menor privilegio te protege de:

Impacto masivo si una credencial se compromete
Borrados accidentales en producción
Roles antiguos que nadie recuerda
Auditorías difíciles de explicar

Además, ayuda a depurar. Si algo falla, sabemos que los límites de acceso son reales.

Dónde Fallamos Normalmente

Los patrones más comunes son:

Wildcards como *:*
Políticas copiadas sin limpieza
Un rol para todo
Permisos temporales que nunca se quitan
No separar permisos de despliegue y ejecución

Esto les pasa a equipos buenos también. La solución es un patrón claro.

Ejemplos: Mala Política vs Buena Política

Ejemplo 1: Acceso a S3

❌ Mala política (demasiado amplia)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

✅ Buena política (limitada y práctica)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucketInPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["public/*"]
        }
      }
    },
    {
      "Sid": "ReadObjectsInPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-data/public/*"
    }
  ]
}

Un Sistema Simple para Diseñar IAM Bien

Separar roles
Empezar mínimo y crecer cuando sea necesario
Usar guardrails como SCPs y boundaries
Revisar y limpiar permisos regularmente

🧪 Mini Proyecto: Rol de Menor Privilegio para Lambda + S3 usando Terraform.

Objetivo

Crear:

Un bucket S3
Un rol de ejecución de Lambda
Una política de menor privilegio
Adjuntar la política al rol

La Lambda podrá:

Leer solo de public/
Escribir solo en results/
Escribir logs en CloudWatch

¿Quieres verlo todo en acción?

Completa este despliegue arquitectónico utilizando este repositorio de GitHub - Demostración de IAM Least Privilege. Siéntete libre de explorar otros proyectos en los que he trabajado.

Si este artículo te ayudó, aquí está lo que puedes hacer después:

Sígueme en X y YouTube para más contenido de AWS, DevOps y Terraform,para principiantes o expertos. También comparto miniproyectos en nuestro newsletter ☕ Cloud Café Subscríbete en LinkedIn.

Adding one more thought here. Least privilege is not about locking everything down. It’s about making failure predictable. That shift alone changed how I design IAM policies.

Augusto Valdivia — Mon, 22 Dec 2025 15:11:02 +0000

Augusto Valdivia for AWS Community Builders

Dec 17 '25

IAM Least Privilege: What Everyone Gets Wrong (and How to Fix It with Terraform)

#terraform #awssecurity #aws #devops

Comments

3 min read

IAM Least Privilege: What Everyone Gets Wrong (and How to Fix It with Terraform)

Augusto Valdivia — Wed, 17 Dec 2025 15:29:39 +0000

When we’re under pressure, the fastest solution often wins. Someone needs access, something is failing, and a deadline is approaching. So we do the classic move: grant wide permissions “temporarily.”

The problem is that temporary permissions have a habit of becoming permanent.

Least privilege isn’t about being paranoid. It’s about being intentional. We grant only what’s needed, so mistakes stay small, and security remains predictable.

What does least privilege actually mean?

Least privilege means:

Only the actions needed (not everything)
Only the resources needed (not “any resource”)
Only when needed (not forever)
Only for the right identity (role, user, or service)

With these points in mind, I always ask myself the following questions:

What does this workload need to do?
Where does it need to do it?
What should never be allowed?

This mindset matters because IAM is not just about security; it’s also about reliability.
A role with too much power can break more things, faster.

Why Least Privilege Matters at Scale

In small environments, wide permissions might not cause immediate problems.
At scale, they usually do.

Here’s what least privilege protects you from:

A larger blast radius: one compromised key can impact everything
Accidental deletions: someone runs the wrong command in production
Shadow access: old roles retain permissions nobody remembers granting
Audit headaches: difficult questions like “Why does this role have this access?”

When permissions are tight, debugging becomes easier as well.
If something fails, we know the access boundary is real and meaningful.

Where Teams Usually Go Wrong

These are the most common patterns we see in real AWS environments:

Wildcards like:*
Policies copied from the internet and never cleaned up
A single role reused across multiple systems
“Temporary” permissions that quietly become permanent
No separation between deployment permissions and runtime permissions

This happens to good teams as well. It usually comes from moving fast.
The fix isn’t blame; the fix is adopting the right patterns.

Bad Policy vs Good Policy Examples

Example 1: S3 access
❌ Bad policy (too broad)

This allows any S3 action on any bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

Why This Is Risky

Can delete any bucket
Can read data that should be private
No limits on specific paths or environments

✅ Good Policy (Tight and Practical)

This policy grants read-only access to a single bucket, limited to a specific prefix.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucketInPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["public/*"]
        }
      }
    },
    {
      "Sid": "ReadObjectsInPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-data/public/*"
    }
  ]
}

Why This Is Better

Limited to a single bucket
Limited to a specific path
No delete permissions

Example 2: Lambda Logging
❌ Bad Policy

This policy allows writing logs anywhere, which is unnecessary and risky.

{
  "Effect": "Allow",
  "Action": "logs:*",
  "Resource": "*"
}

✅ Good Policy

This policy allows only log stream creation and log writing for one specific log group.

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/my-function:*"
}

A Simple System to Design IAM the Right Way

Here’s a pattern that works in real projects:

Separate roles

Use different roles for different responsibilities:

One for deployment
One for runtime
One for monitoring

Start narrow, expand only when needed

When an action fails, add only the minimum permission required to fix it.

Use guardrails

Apply SCPs and permission boundaries to enforce “this must never happen” rules.

Review regularly

If a permission hasn’t been used in months, remove it.
Least privilege is not a one-time setup.
It’s a maintenance habit.

🧪 Mini Project: Least-Privilege IAM Role for Lambda + S3

(Terraform Coming-Soon)

Goal

We will create:

One S3 bucket
One Lambda execution role
One least-privilege IAM policy
Attach the policy to the role
The Lambda will be able to:
Read only from s3://bucket/public/*
Write only to s3://bucket/results/*
Write logs to CloudWatch

Want to see it all in action?

Complete this architectural deployment using this GitHub repository - IAM Least Privilege Demo. Feel free to explore other projects I've worked on.

If this article helped you, here’s what you can do next:

Follow me on X and YouTube for more AWS, DevOps, and Terraform content that’s beginner-friendly.

Leave a comment with your thoughts, your own AWS journey, or questions you’d like me to cover next.

AWS Summit Toronto 2025: De la Supervisión Humana a la IA Agéntica

Augusto Valdivia — Fri, 12 Sep 2025 17:59:56 +0000

La semana pasada tuve la oportunidad de asistir al AWS Summit Toronto 2025.

Este año el evento se dividió en dos partes:

Día 1 – Partner Summit, dedicado a los socios de AWS.
Día 2 – Open Summit, abierto a toda la comunidad de AWS.

Fueron dos días llenos de aprendizaje, inspiración y anuncios sobre el futuro. Pero más que nada, fue una oportunidad para conectar — con colegas, líderes y con toda la comunidad de AWS.

Día 1 – Lo más Destacado del Partner Summit

El primer día estuvo enfocado en los socios y en un repaso profundo del portafolio más reciente de AWS. Algunos de los temas tratados fueron:

La Anatomía de la Velocidad
Soluciones Industriales y Seguridad
Generative AI y Migración/Modernización
Evolución del AWS Marketplace

El mayor foco estuvo en la IA Agéntica (Agentic AI). AWS presentó un portafolio que conecta herramientas como Amazon Q, AWS Transform, Amazon Connect, modelos Nova y Bedrock, todo unificado con nuevos SDKs y servicios para construir agentes inteligentes.

Temas clave:

Flexibilidad con OSS e integraciones de partners.
Guardrails de personalización para construir de manera responsable.
Soluciones verticales para industrias como SAP, Oracle y mainframes.
AWS Transform como el primer servicio de IA agéntica para migración y modernización, mostrando resultados impresionantes como evaluaciones de documentación más rápidas y reducción de costos de licencias.

Día 2 – Temas del Open Summit

El segundo día amplió la visión hacia el futuro de la nube. La evolución fue clara:

De asistentes de IA generativa → a agentes de IA generativa → hasta sistemas de IA agéntica.
Menos supervisión humana, más automatización y sistemas multiagente capaces de razonar como humanos.

Este cambio hacia la IA agéntica marca el próximo capítulo en la nube — donde las cargas de trabajo no solo corren en AWS, sino que también toman decisiones, automatizan flujos de trabajo y se adaptan en tiempo real.

Aprendizajes y Conclusiones

Varias sesiones destacaron por sus ideas prácticas y su mirada hacia adelante:

Serverless & Analítica en Tiempo Real: Las mejores prácticas para Lambda y pipelines de datos en streaming siguen evolucionando, con un fuerte enfoque en optimización del rendimiento y reducción de latencia.
IA + Datos de IoT: La necesidad de datos limpios y unificados es cada vez más crítica a medida que las industrias confían en la IA para manejar enormes volúmenes de datos de IoT. Los principios de la manufactura inteligente ya se aplican en edificios inteligentes y más allá.
Chatbots Agénticos & Serverless AI: Los talleres prácticos de Lambda y las sesiones sobre chatbots y analítica dejaron claro que AWS está impulsando aplicaciones de IA agéntica que no solo responden, sino que también actúan.
GenAI + Digital Twins: La IA generativa sigue dominando. Un tema central fue cómo integrarla con datasets existentes para potenciar soluciones de digital twins, especialmente en industrias como AEC, donde las lecciones de sectores más maduros en IA aceleran la adopción.

La dirección general: AWS está invirtiendo fuertemente en IA, datos en tiempo real y estrategias de modernización que atraviesan todas las industrias.

Comunidad y Conexiones

Uno de los momentos más gratificantes llegó al final del Summit: reencontrarme con líderes de la comunidad de AWS, volver a conectar con colegas del AWS Community Builders program y compartir una cena donde hablamos sobre la próxima gran iniciativa que queremos organizar juntos.

Momentos como este me recuerdan que AWS no se trata solo de tecnología. Se trata de personas, colaboración y de construir juntos una comunidad más fuerte.

El AWS Summit Toronto 2025 nos mostró hacia dónde se dirige la nube: más rápida, más inteligente y más agéntica que nunca.

Me encantaría escuchar de otros que asistieron: ¿Cuáles fueron sus principales aprendizajes?

Y si no pudieron participar este año, síganme para más reflexiones sobre AWS, DevOps y Terraform — seguiré compartiendo aprendizajes y el espíritu de la comunidad.

AWS Summit Toronto 2025: From Human Oversight to Agentic AI

Augusto Valdivia — Fri, 12 Sep 2025 17:42:08 +0000

Last week I had the chance to attend the AWS Summit Toronto 2025.

This year’s event was split into two parts:

Day 1 – Partner Summit, dedicated to AWS partners.
Day 2 – Open Summit, welcoming the entire AWS community.

Both days were packed with learning, inspiration, and future-looking announcements. But more than anything, it was a chance to connect with peers, with leaders, and with the wider AWS community.

Day 1 – Partner Summit Highlights

Day one was all about partners and the deep dive into AWS’s latest portfolio. Topics included:

The Anatomy of Speed
Industry Solutions & Security
Generative AI and Migration/Modernization
AWS Marketplace evolution

The biggest spotlight was on Agentic AI. AWS introduced a portfolio that connects tools like Amazon Q, AWS Transform, Amazon Connect, Nova models, and Bedrock, all tied together with new SDKs and services to build intelligent agents.

⚡ Key themes:

Flexibility with OSS and partner integrations.
Customization guardrails to build responsibly.
Vertical solutions for industries like SAP, Oracle, and mainframes.
AWS Transform as the first agentic AI service for migration and modernization, with impressive results like faster documentation assessment and reduced licensing costs.

Day 2 – Open Summit Themes

The second day zoomed out into the future of cloud. The evolution was clear:

From Generative AI assistants → Generative AI agents → to Agentic AI systems.
Less human oversight, more automation, and multi-agent systems capable of reasoning like humans.

This shift toward agentic AI signals the next chapter in cloud, where workloads don’t just run in AWS, but make decisions, automate workflows, and adapt in real time.

Key Learnings and Takeaways

Several sessions stood out for their practical insights and forward-looking themes:

Serverless & Real-Time Analytics: Best practices for Lambda and streaming data pipelines continue to evolve, with a strong focus on performance optimization and reducing latency.
AI + IoT Data: Clean, unified data structures are becoming critical as industries rely on AI to manage massive IoT datasets. Smart manufacturing principles are now being applied to smart buildings and beyond.
Agentic Chatbots & Serverless AI: Hands-on Lambda workshops and sessions on analytics and chatbots made clear that AWS is pushing hard toward agentic AI applications that don’t just respond, but act.
GenAI + Digital Twins: Generative AI continues to dominate. A major theme was integrating GenAI with existing datasets to power digital twin solutions, especially in industries like AEC, where lessons from more mature tech sectors can accelerate adoption.

The overall direction: AWS is investing heavily in AI, real-time data, and modernization strategies that cut across industries.

Community and Connections

One of the most rewarding moments came at the end of the Summit: meeting leaders from the AWS community, reconnecting with peers from the AWS Community Builders program, and sharing a dinner where we talked about the next big thing we want to organize together.

Moments like these remind me that AWS isn’t just about technology. It’s about people, collaboration, and building a stronger community together.

The AWS Summit Toronto 2025 showed us where cloud is heading: faster, smarter, and more agentic than ever before.

👉 I’d love to hear from others who attended: What were your top takeaways?

And if you couldn’t make it this year, follow me for more AWS, DevOps, and Terraform reflections — I’ll keep sharing the lessons and the community spirit. 🚀

Cómo Aprobar el Examen de AWS Solutions Architect Professional Como un Verdadero Pro

Augusto Valdivia — Tue, 02 Sep 2025 18:47:07 +0000

Imagina esto: después de meses de estudio, exámenes de práctica y algunos momentos de duda, finalmente presionas el botón de enviar. Entonces la pantalla muestra las palabras que has estado esperando:

“¡Felicidades! Has aprobado el AWS Certified Solutions Architect – Professional.” 🎉

Eso me pasó no hace mucho, y déjame decirte, la sensación fue como terminar una gran comida después de horas en la cocina — llena de alivio, orgullo y quizás hasta un poco de cansancio.

Esta certificación no es cualquier cosa — se trata de dominar:
🌐 Diseño de arquitecturas complejas en AWS
🔒 Seguridad, cumplimiento y gobierno a escala
⚙️ Optimización de costo, rendimiento y resiliencia
🛠️ Migración y modernización de cargas de trabajo
📊 Equilibrar decisiones con necesidades reales de negocio

Pero aquí está el detalle: aprobar el examen no se trata solo de memorizar preguntas. Se trata de entender realmente cómo funciona AWS a gran escala. Y para mí, dos temas destacaron más que cualquier otro:

✅ Service Control Policies (SCPs) – las barandillas que mantienen tus cuentas de AWS seguras y consistentes.
✅ Migraciones – las estrategias que ayudan a mover cargas de trabajo a AWS sin interrumpir el negocio.

En este artículo compartiré mis ideas sobre estas dos áreas. Lo mantendré simple, con analogías y ejemplos del mundo real que realmente puedes usar — Sé que muchos de ustedes están aprendiendo AWS en inglés, pero resulta mucho más fácil si lo estudiamos en nuestro idioma, o quizás apenas están comenzando en la nube. Y si ya eres un experto, piénsalo como un repaso refrescante con una nueva perspectiva.

Service Control Policies (SCPs) – La Parte Técnica

Muy bien, veamos lo que dice la documentación de AWS sobre Service Control Policies (SCPs) pero de una forma más fácil de digerir:

Parte de AWS Organizations

Las SCPs viven dentro de AWS Organizations, el servicio que usas para manejar múltiples cuentas de AWS en un solo lugar.
Importante: las SCPs solo funcionan si activas “todas las características”. Si solo tienes la facturación consolidada, las SCPs no estarán disponibles.

Las SCPs No Otorgan Permisos

Esto es lo más importante: las SCPs no dan acceso.
Simplemente definen los límites máximos de permisos que una cuenta puede tener.
Ejemplo: si IAM dice “sí” pero SCP dice “no”, el resultado es no.

Jerarquía y Herencia

Las SCPs se pueden aplicar en el root, a Organizational Units (OUs) o a cuentas individuales.
Las reglas bajan en cascada: una SCP en root afecta todo; una SCP en un OU afecta todas las cuentas dentro de ese OU.
Los permisos efectivos = la intersección de SCPs + IAM. Para que una acción funcione, debe estar permitida en toda la cadena.

Lista de Permitir vs Lista de Denegar

Lista de Permitir (denegar por defecto): Todo está denegado a menos que lo permitas. Muy estricto, mucho trabajo.
Lista de Denegar (permitir por defecto): Todo está permitido a menos que lo deniegues. Más fácil de manejar y lo más común.

Impacto en Permisos

Las SCPs afectan a usuarios y roles IAM en cuentas miembro, incluso al usuario root.
No afectan la cuenta de administración ni a los roles vinculados a servicios.

Control Centralizado

Las SCPs ayudan a mantener las cuentas bajo control:
- Bloqueando servicios específicos
- Restringiendo regiones
- Asegurando cumplimiento

Buenas Prácticas

No empieces en root. Haz pruebas en un OU primero para evitar bloquear servicios críticos.
Usa IAM last accessed data o CloudTrail para revisar uso antes de aplicar restricciones.

🏠 La Analogía de la Casa Familiar (Root, OUs, SCPs)

Root = la casa de los padres.
Cada OU = un dormitorio diferente.
Cada cuenta = el niño que vive en ese dormitorio.

Escenario 1: Denegar en Root (mala idea)

Los padres ponen candado al refri: “Nadie puede comer helado.”
Aunque las reglas del niño digan que sí, la regla de la casa aplica → nadie come helado.
Eso pasa si niegas en root: no hay excepciones.

Escenario 2: Root Full Access + Denegar en OU (mejor práctica)

Los padres dicen: “Todos pueden comer lo que sea.” (FullAWSAccess por defecto).
Cada dormitorio (OU) pone sus propias reglas:
- Niño #1 → No helado.
- Niño #2 → No dulces.
- Niño #3 → Acceso completo.
Si Niño #1 de repente necesita helado para un proyecto de la escuela, lo mueves al cuarto del Niño #3.
Eso es denegar a nivel OU: flexible y más fácil de manejar.

Escenario 3: Lista de Permitir en Root (demasiado estricto)

Los padres ponen un pizarrón gigante: “Solo pizza y manzanas permitidas.”
Cada comida nueva = actualizar el pizarrón. Demasiado trabajo.
Eso es una lista de permitir en root → alto mantenimiento.

✅ La estrategia ganadora: Root = deja FullAWSAccess. OU = aplica listas de denegar. Excepciones = mueve cuentas.

Migraciones – Lo Que Necesitas Saber para el Examen AWS SAP

1. Planeación de Migración

Cuando AWS habla de migraciones, no significa solo “mueve todo a la nube y espera que funcione.” Quieren que lo hagas como un pro:

Descubre lo que tienes (servidores, bases de datos, apps).
Agrupa las cosas lógicamente (aplicaciones, dependencias).
Elige la estrategia correcta de migración (las famosas 6 R’s).

Esta etapa es como planear una mudanza familiar grande. No agarras cajas al azar — haces una lista, decides qué se va, qué se queda y qué se actualiza.

2. AWS Application Discovery Service (ADS)

Esta herramienta es tu inventario antes de la mudanza. Escanea automáticamente tu entorno on-premises y recoge detalles de servidores, VMs, bases de datos e incluso conexiones de red.

Tiene tres formas principales de recolectar datos:

Agentless Collector:
- No requiere instalar nada en cada servidor.
- Ideal para entornos VMware.
- Recolecta datos básicos: hostname, IP, CPU, RAM, uso de disco.
- Limitación: no ve procesos ni dependencias de red.
Discovery Agent (basado en agente):
- Instalado en cada servidor.
- Da datos detallados: procesos, flujos de red, rendimiento.
- Perfecto para entender cómo se comunican los servidores.
Importación basada en archivos:
- Cuando ya tienes un inventario de otro sistema.
- Lo importas directo a Migration Hub.

📊 ¿Qué pasa después del descubrimiento?

Los datos van a tu Migration Hub Home Region.
Puedes agrupar servidores en aplicaciones.
Exportar los datos a S3, Athena o QuickSight para análisis de costos.
Usar la info para dimensionar bien EC2s y planear costos.

3. Servicios de Migración: De VMware u On-Prem a AWS

Cuando ya tienes el plan, es hora de mover las cajas. Para el examen SAP, necesitas conocer estos servicios clave:

AWS Application Migration Service (MGN)
- El campeón del lift-and-shift.
- Replica servidores en AWS y los convierte en EC2s.
- Minimiza downtime.
- Funciona con Migration Hub para seguimiento.
- Bonus: después de rehost, puedes replatform o refactor fácilmente.
AWS Database Migration Service (DMS)
- Especial para bases de datos.
- Soporta migraciones homogéneas (Oracle → Oracle) y heterogéneas (SQL Server → Aurora).
- Integra con Fleet Advisor para planear migraciones de DB.
AWS Migration Hub
- El panel central de todos los proyectos de migración.
- Muestra el estado de servidores y apps, sin importar qué herramienta uses.
- Piensa en él como el coordinador de la mudanza que rastrea cada camión y caja.

4. Estrategias de Migración (Las 6 R’s)

Estas seguro aparecen en el examen:

Rehost (Lift & Shift): Mover tal cual. Ej: VM → EC2.
Replatform: Pequeños cambios. Ej: App → Elastic Beanstalk, DB → RDS.
Refactor (Re-arquitectar): Cambios grandes. Ej: Monolito → microservicios con Lambda.
Repurchase: Reemplazar con SaaS. Ej: CRM on-prem → Salesforce.
Retire: Dar de baja apps que no se usan.
Retain: Mantener on-prem por ahora.

✅ Conclusiones

Service Control Policies (SCPs): Son las barandillas de AWS Organizations. No dan acceso, pero definen los límites máximos de permisos. La mejor práctica: dejar FullAWSAccess en root y aplicar listas de denegar en OUs para flexibilidad y seguridad.
Migraciones: No es solo levantar y mover servidores. Requiere planeación, descubrir con ADS, mover con MGN o DMS, dar seguimiento con Migration Hub y finalmente aplicar la estrategia adecuada de las 6 R’s. Así la migración es predecible y costo-eficiente.

¡Eso es todo! 🎬 Ya viste dos de los temas más pesados del examen AWS SAP: SCPs y Migraciones. Ambos son críticos no solo para aprobar el examen, sino también para trabajar como un verdadero Solutions Architect en el mundo real.

Si este artículo te ayudó, aquí está lo que puedes hacer después:

Sígueme en X and YouTube para más contenido de AWS, DevOps y Terraform, amigable para principiantes pero también útil para el examen.
Deja un comentario con tus pensamientos, tu propio camino en el AWS SAP o preguntas que quieras que cubra después.
Pronto crearé un repositorio en GitHub. donde compartiré recursos y ejemplos de práctica.

¡Éxito en tu camino al AWS SAP, y recuerda: preparación + práctica = aprobar como un pro! 🚀

How to Pass the AWS Solutions Architect Professional Certification Like a Real Pro

Augusto Valdivia — Tue, 02 Sep 2025 17:20:50 +0000

Imagine this: after months of studying, practice exams, and a few moments of doubt, you finally hit that submit button. Then the screen flashes with the words you’ve been waiting for:

“Congratulations, you have passed the AWS Certified Solutions Architect – Professional.” 🎉

That was me not long ago, and let me tell you, the feeling was just like finishing a big meal after hours in the kitchen. Full of relief, pride, and maybe even a little exhaustion.

This certification is no small feat it’s all about mastering:

🌐 Designing complex architectures on AWS
🔒 Security, compliance & governance at scale
⚙️ Cost, performance & resilience optimization
🛠️ Migration & modernization of workloads
📊 Balancing trade-offs for real business needs

But here’s the thing: passing the exam isn’t just about memorizing questions. It’s about really understanding how AWS works at scale. And for me, two topics stood out more than anything else:

✅ Service Control Policies (SCPs) – the guardrails that keep your AWS accounts safe and consistent.
✅ Migrations – the strategies that help move workloads to AWS without breaking the business.

In this article, I’ll share my insights on these two areas. I’ll keep it simple, using real world analogies and examples that you can actually apply. Because I know many of you are learning AWS as a second language, or maybe just getting started in the cloud. And if you’re already an expert, consider this a refreshing walk through with a new perspective.

✅ Service Control Policies (SCPs) – the guardrails that keep your AWS accounts safe and consistent.
✅ Migrations – the strategies that help move workloads to AWS without breaking the business.

Service Control Policies (SCPs) – The Technical Part

Alright, let’s break down what AWS documentation says about Service Control Policies (SCPs) in a way that’s easier to digest:

Part of AWS Organizations

SCPs live inside AWS Organizations, which is the service you use to manage multiple AWS accounts in one place.
Important: SCPs only work if you enable “all features”. If you only have consolidated billing, SCPs won’t be available.

SCPs Do Not Grant Permissions

This is the most important thing: SCPs don’t give access.
They simply define the maximum permissions an account can ever have.
Example: if IAM says “yes” but SCP says “no,” the result is no.

Hierarchy and Inheritance

SCPs can be attached at the root, to Organizational Units (OUs), or to individual accounts.
Rules flow downward: a root SCP impacts everything; OU SCPs impact all accounts inside that OU.
Effective permissions = intersection of SCPs + IAM. For an action to work, it must be allowed everywhere.

Allow List vs Deny List

Allow List (deny by default): Everything is denied unless you allow it. Very strict, lots of overhead.
Deny List (allow by default): Everything is allowed unless you deny it. Easier to manage and most common.

Impact on Permissions

SCPs affect IAM users and roles in member accounts, including the root user.
They do not affect the management account or service-linked roles.

Centralized Control

SCPs help organizations keep accounts under control by:
- Blocking specific services
- Enforcing regional restrictions
- Ensuring compliance

Best Practices

Don’t start at the root. Test in an OU first to avoid blocking critical services.
Use IAM last accessed data or CloudTrail to check usage before applying restrictions.

🏠 The Family House Analogy (Root, OUs, SCPs)

Root = the parents’ house.
Each OU = a different child’s bedroom.
Each account = the kid who lives in that bedroom.

Scenario 1: Root Deny (bad idea)

Parents put a lock on the fridge: “Nobody can eat ice cream.”
Even if one kid’s rules say they can, the house rule applies → no ice cream for anyone.
That’s what happens if you deny at root: no exceptions possible.

Scenario 2: Root Full Access + OU Deny (best practice)

Parents say: “Everyone can eat anything.” (default FullAWSAccess).
Each bedroom (OU) adds its own rules:
- Kid #1 → No ice cream.
- Kid #2 → No candy.
- Kid #3 → Full access.
If Kid #1 suddenly needs ice cream for a school project, just move them into Kid #3’s room.
That’s OU-level deny: flexible and easier to manage.

Scenario 3: Allow List at Root (too strict)

Parents put a giant whiteboard: “Only pizza and apples allowed.”
Every new food = update the board. Too much work.
That’s an allow list at root → high overhead.

✅ In plain English:

Root deny = fridge locked for all, no exceptions.
OU deny = bedroom rules, exceptions possible.
Allow list = whiteboard nightmare.

👉 The winning strategy: Root = leave FullAWSAccess. OU = apply deny lists. Exceptions = move accounts.

Migrations What You Need to Know for the AWS SAP Exam

Migration Planning

When AWS talks about migrations, they don’t just mean “move everything to the cloud and hope it works.” They want you to plan like a pro:

Discover what you have (servers, databases, apps).
Group things logically (applications, dependencies).
Choose the right migration strategy (the famous 6 R’s).

This planning stage is like preparing for a big family move. You don’t just grab boxes randomly. You will make a list, decide what goes, what stays, and what needs upgrading. Right?

AWS Application Discovery Service (ADS)

This tool is your inventory manager before moving day. It automatically scans your on premises environment and collects details about servers, VMs, databases, and even network connections.

It has three main ways to discover data:

Agentless Collector:
- No need to install anything on each server.
- Great for VMware environments.
- Collects basic info: hostname, IP, CPU, RAM, disk usage.
- Limitation: cannot see running processes or network dependencies.
Agent-based Discovery Agent:
- Installed directly on each server.
- Provides deep insights: processes, network flows, performance data.
- Best if you need to understand how servers talk to each other.
File-based Import:
- For when you already have an inventory from another system.
- You can import that data straight into Migration Hub.

📊 What happens after discovery?

Data is sent to your Migration Hub Home Region.
You can group servers into applications.
Export the data to S3, Athena, or QuickSight for cost analysis.
Use the info to right size EC2 instances and plan costs more accurately.

Migration Services: Moving from VMware or On-Prem to AWS

Once planning is done, it’s time to move the boxes. For SAP exam purposes, you need to know the main AWS services:

AWS Application Migration Service (MGN)
- Think of this as the lift and shift champion.
- It replicates servers into AWS and automatically converts them into EC2 instances.
- Great for minimizing downtime.
- Works with Migration Hub so you can track progress.
- Bonus: after rehosting, you can later replatform or refactor easily.
AWS Database Migration Service (DMS)
- Specifically for migrating databases.
- Supports homogeneous migrations (Oracle → Oracle) and heterogeneous (SQL Server → Aurora).
- Also integrates with Fleet Advisor to discover and plan DB migrations.
AWS Migration Hub
- The central dashboard for all migration projects.
- Shows the status of servers and applications, regardless of which tool you use.
- Think of it like the moving company coordinator that tracks every truck and box.

Migration Strategies (The 6 R’s)

You’ll definitely see these on the exam:

Rehost (Lift & Shift): Move as-is. Example: VM → EC2.
Replatform: Small changes. Example: App → Elastic Beanstalk, DB → RDS.
Refactor (Re-architect): Big changes. Example: Monolith → microservices with Lambda.
Repurchase: Replace with SaaS. Example: On-prem CRM → Salesforce.
Retire: Decommission unused apps.
Retain: Keep it on-prem for now.

✅ Conclusions

Service Control Policies (SCPs): They are the guardrails of AWS Organizations. SCPs don’t give access but define the maximum boundaries of permissions. The best approach is to leave FullAWSAccess at the root and apply deny lists at the OU level for flexibility and safer management.
Migrations: A successful migration is not just lifting and shifting servers. It requires planning, discovering your environment with ADS, moving workloads with MGN or DMS, tracking with Migration Hub, and finally applying the right strategy from the 6 R’s. With the right approach, migrations become predictable and cost-efficient.

That’s a wrap! 🎬 You’ve now seen two of the heaviest topics for the AWS SAP exam: SCPs and Migrations. Both are critical to not just passing the exam, but also working as a real Solutions Architect in the field.

If this article helped you, here’s what you can do next:

Follow me on X and YouTube for more AWS, DevOps, and Terraform content that’s beginner-friendly but also exam-ready.
Leave a comment with your thoughts, your own AWS SAP journey, or questions you’d like me to cover next.
Coming soon, a GitHub repo where I’ll be sharing supporting resources and examples to practice with.

Good luck with your AWS SAP journey, and remember: preparation + practice = passing like a pro!

Secure Your AWS Pipeline: Step-by-Step Guide to VPC Integration-part 2

Augusto Valdivia — Thu, 20 Mar 2025 21:23:46 +0000

Welcome back!

I hope you still have an appetite for learning more about CICD and how to secure your deployments. In Part 1, you built your first AWS CICD pipeline. Awesome job, but as any great chef knows, it’s not just about making a delicious dish; you must also keep your kitchen organized and safe.

Now that your pipeline is up and running, it’s time to take the next step: securing access to your private resources within a VPC and setting up proper permissions.

In this part, we’ll cover:

What is a VPC and why does it matter?
How to securely connect your pipeline to a production environment in a private subnet?

Let’s dive right in! 🍽️

What is a VPC and Why Does It Matter?

Before we start securing things, let’s talk about what a VPC (Virtual Private Cloud) is. Imagine your AWS environment as a massive restaurant kitchen. A VPC is like having separate workstations one for chopping, one for cooking, and one for plating. Each station (or subnet, I'll elaborate on this further shortly.) has its purpose, and you decide who gets access to each.

A VPC allows you to create an isolated section in AWS where you can launch your resources securely. It’s like having a private kitchen that only your team can enter, keeping unwanted guests or security risks out. Within a VPC, you can set up public and private subnets to control where traffic flows, ensuring that sensitive infrastructure like databases stays protected from the outside world.

Now that we’ve got a basic idea, let’s move on to securely connecting our pipeline to a private subnet. If you’re looking for a more technical explanation, I will include all the necessary documentation for further study in the sources section of this article series.

How to Securely Connect Your Pipeline to a Production Environment in a Private Subnet?

Let's imagine that your pipeline is like a chef sending prepared dishes to the right station. But what if the final plating area is in a private section of the restaurant? You need a secure way to get the food there without letting unauthorized people in. That’s where private subnets come in.

You might be wondering, "What is a private subnet?"

A private subnet is an isolated area within your VPC that doesn’t have direct internet access. To allow your pipeline to deploy into a private subnet, you’ll need:

A NAT Gateway or VPC Endpoint, This acts like a secure delivery pass, letting the pipeline reach private resources without exposing them to the public internet.
Proper Security Group Rules, Think of these as access control rules that decide which resources can talk to each other.
IAM Roles and Policies, You don’t want just anyone making changes in your environment. IAM roles ensure only the right processes have access to deploy inside the VPC.

In this second part, we will focus on building and using a NAT Gateway to enable secure updates for an application within a Private Subnet.

So, your application lives in a private subnet, safe from the public internet, but wait, How do you update it? Private subnets don’t have direct internet access, which is great for security but tricky for getting updates. This is where a NAT Gateway comes in, acting like a controlled exit door.

Think of it like a high end restaurant’s storage room. Only authorized staff can go in and out, ensuring that only fresh ingredients (updates) make their way into the kitchen without letting unwanted visitors (security threats) sneak in.

By adding a NAT Gateway, your private instances can access the internet to download updates, pull dependencies, etc. while being shielded from direct exposure. Sounds exciting,Doesn't it? and here’s how it works:

The NAT Gateway sits in a public subnet and has an Elastic IP assigned to it.
A route table is configured so that private subnets send outbound traffic to the NAT Gateway instead of directly to the internet.
The pipeline (running in CodePipeline) can now deploy updates to your private resources securely.

Credits to AWS documentation[1].

At this point, you should have a solid high-level understanding of what a VPC is and how to protect your private resources. Now, let's explore how Terraform can enhance this configuration, making it even more secure with just a few lines of code.

Here’s what to expect when using this Terraform template:

✅ Sets up a VPC
✅ Creates public and private subnets
✅ Configures a NAT Gateway for internet access from private subnets
✅ Sets up route tables for proper traffic flow
✅ Specifies Security Groups

# Create a VPC
resource "aws_vpc" "main_vpc" {
  cidr_block = "10.0.0.0/16"
}

# Create Public and Private Subnets
resource "aws_subnet" "public_subnet" {
  vpc_id                  = aws_vpc.main_vpc.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private_subnet" {
  vpc_id     = aws_vpc.main_vpc.id
  cidr_block = "10.0.2.0/24"
}

# Create an Internet Gateway for Public Subnet
resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main_vpc.id
}

# Create a NAT Gateway for Private Subnet
resource "aws_eip" "nat_eip" {}

resource "aws_nat_gateway" "nat_gw" {
  allocation_id = aws_eip.nat_eip.id
  subnet_id     = aws_subnet.public_subnet.id
}

# Route Table for Public Subnet (Direct Internet Access)
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }
}

resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.public_rt.id
}

# Route Table for Private Subnet (Internet Access via NAT Gateway)
resource "aws_route_table" "private_rt" {
  vpc_id = aws_vpc.main_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gw.id
  }
}

resource "aws_route_table_association" "private_assoc" {
  subnet_id      = aws_subnet.private_subnet.id
  route_table_id = aws_route_table.private_rt.id
}

What’s Next?

With this setup, your CICD pipeline can securely deploy updates to resources in a private subnet while still having controlled internet access via a NAT Gateway. This means your private environment stays protected while getting the latest updates just like a top tier restaurant keeping its ingredients fresh without letting anyone walk in off the street.

Want to see it all in action?

Complete this architectural deployment utilizing the full GitHub Repository - Create a CICD Pipeline with Terraform AWS-Pipeline-Step-by-Step-Guide-to-VPC-Integration. You're welcome to browse through other projects I've worked using this link. And don’t forget to:

✅ Follow me on X and YouTube for more AWS, DevOps, and Terraform tips 
✅ Comment below with any questions or suggestions 
✅ Check out the GitHub repo for the full Terraform setup

🚀 Happy building!

Sources:

[1] https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html
[2] https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html