DEV Community: Augusto Valdivia

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.

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

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

Augusto Valdivia — Thu, 23 Jan 2025 17:04:59 +0000

Why Automate?

Picture this: Your team just kicked off a brand new project. Everyone’s excited, but one big question is hanging over your head how will you deploy all this code? You’ve been asked to set up a pipeline to handle the process. At first, it sounds straightforward, but you start thinking about what’s involved: testing, building, and deploying every time someone pushes a change.

Do you do it manually? That’s going to get messy fast.

This is where automation steps in to save the day. With a CICD pipeline, all those repetitive tasks like testing and deploying are handled for you. It’s like having a reliable assistant who never gets tired or makes mistakes. And as someone stepping into a DevOps role, knowing how to set this up isn’t just helpful it’s essential.

In this article, you’ll gain hands on experience building your first CICD pipeline using AWS CodePipeline and GitHub. Once your pipeline is set up, it will connect to private resources inside a VPC, ensuring secure deployment. You’ll also configure monitoring and an alarming system with CloudWatch and SNS topics to receive email notifications if a build fails, giving you a solid and dependable workflow from start to finish.

Now, let’s explore what CICD is all about. What is CICD?

CICD stands for Continuous Integration and Continuous Deployment.

Let’s break it down:

Continuous Integration (CI): This is about automatically integrating code changes from multiple developers into a single project. Every time you push new code, the system checks if it works with the existing codebase by running tests.

Continuous Deployment (CD): This step takes it further. After your code passes all tests, it gets deployed automatically to a live environment or staging environment.

Think of CICD as a chef in a busy restaurant. You prepare the ingredients (your code), and instead of making each dish from start to finish yourself, you have a kitchen team (the pipeline) handling the repetitive tasks like chopping, cooking, and plating. The result? Your dishes are prepared faster, consistently, and ready to be served (deployed) to your customers without any unnecessary delays or errors. And hey, unlike a real kitchen, this pipeline never burns the toast 😎. Now that we’ve got the basics, let’s dive deeper into AWS CodePipeline.

What is AWS CodePipeline?

AWS CodePipeline is an AWS service that helps you automate the software release process. It’s like having a reliable kitchen team working behind the scenes while you focus on crafting your signature dish.

Here’s why it’s a big deal:

Automation: It takes care of repetitive tasks like building, testing, and deploying code for you.

Speed: CodePipeline helps you roll out features and updates faster than ever.

Integration: It plays nicely with tools like GitHub, CodeBuild, and other AWS services, making your workflow seamless and efficient.

With AWS CodePipeline, you don’t need to worry about manually deploying changes. Instead, you can focus on improving your code and delivering value to your users. Think of it like having a sous chef who handles all the prep work for you, so you can focus on perfecting the final dish.

Why Should You Care?

Now, you might be wondering, Why does all this matter? Well, as someone stepping into a DevOps role, your goal is to bridge the gap between development and operations. Knowing how to set up a CICD pipeline is critical because:

It saves you time: Automated pipelines handle repetitive tasks, so you can focus on creating better features.
It reduces errors: By automating testing and deployment, you minimize the risk of human error.
It ensures consistency: Every build and deployment follows the same process, leading to more reliable results.

By understanding CICD and CodePipeline, you’re not just learning a skill; you're building a foundation for smoother, faster, and more reliable deployments. And here’s the exciting part: you’ll be using Terraform from start to finish to build this project, giving you a hands on experience with infrastructure as code. Before we jump in, let’s take a moment to understand the monitoring tools we’ll be using:

CloudWatch: Think of this as the monitoring dashboard for your AWS resources. It keeps track of metrics, logs, and events, helping you spot and troubleshoot issues before they become bigger problems.

SNS (Simple Notification Service): This is the messenger. When something goes wrong like a pipeline build failure CloudWatch triggers an alarm, and SNS sends you an email (or another type of notification) to alert you. It’s like having an always on assistant keeping you in the loop.

With these tools in place, we’ll keep an eye on operations and get immediate notifications if something breaks. Let’s get hands on and start building your first pipeline.

GitHub Repository - Create a CICD Pipeline with Terraform Step-by-Step-Guide Set a reminder for the update or revisit this page in a few days. You're welcome to browse through other projects I've worked on in the meantime using this link.

Digram:

Code Previous:

resource "aws_codebuild_project" "my_project" {
  name          = "my-codebuild-project"
  description   = "My CodeBuild project"
  service_role  = aws_iam_role.codebuild_role.arn
  source {
    type      = "GITHUB"
    location  = "https://github.com/your-repo.git"  # Replace with your GitHub repository
  }
  artifacts {
    type = "NO_ARTIFACTS"
  }
  environment {
    compute_type                = "BUILD_GENERAL1_SMALL"
    image                       = "aws/codebuild/standard:5.0"
    type                        = "LINUX_CONTAINER"
    environment_variable {
      name  = "ENV_VAR_NAME"
      value = "value"
    }
  }
}

resource "aws_codepipeline" "my_pipeline" {
  name     = "my-codepipeline"
  role_arn = aws_iam_role.codepipeline_role.arn

  artifact_store {
    location = "my-artifact-store"  # Replace with your S3 bucket name
    type     = "S3"
  }

  stage {
    name = "Source"
    action {
      name            = "Source"
      category        = "Source"
      owner           = "ThirdParty"
      provider        = "GitHub"
      version         = "1"
      output_artifacts = ["source_output"]

      configuration = {
        Owner  = "your-github-username"
        Repo   = "your-repo"
        Branch = "main"
        OAuthToken = "your-oauth-token"  # Replace with your GitHub OAuth token
      }
    }
  }

  stage {
    name = "Build"
    action {
      name            = "Build"
      category        = "Build"
      owner           = "AWS"
      provider        = "CodeBuild"
      version         = "1"
      input_artifacts = ["source_output"]
      output_artifacts = ["build_output"]

      configuration = {
        ProjectName = aws_codebuild_project.my_project.name
      }
    }
  }
}

You’ve done an awesome job getting through this. Give yourself a break—you’ve earned it. And here’s the exciting part: this is just the beginning. In the next part of this series, we’ll dive into how to securely connect your pipeline to a production environment inside a subnet in a VPC. Plus, you’ll learn how to take security and automation to the next level.

Meanwhile, follow me on X and YouTube for more content about AWS, DevOps, and Terraform. I’d love to see what you create, so don’t hesitate to share your projects and questions.

See you in the next part!

Lee esto antes de implementar S3 y CloudFront usando Terraform.

Augusto Valdivia — Tue, 31 Dec 2024 15:38:57 +0000

En este artículo, imaginaremos que trabajas para una empresa que está a punto de lanzar una gran campaña de marketing para uno de sus productos más nuevos y esperan que miles de clientes visiten su sitio web. Tu gerente se puso en contacto contigo y compartió esta información, expresando que le gustaría que pensaras en cómo construir un diseño arquitectónico para este sitio web.

Hechos a considerar

La campaña de marketing es solo por unos días.
La empresa no sabe cuántos espectadores atraerá esta campaña a su sitio web, pero pronostican miles para los primeros días después del lanzamiento de la campaña.
Hay una gran preocupación por los ataques DoS/DDoS.
Debe estar dentro de su presupuesto.
Necesita ser accesible rápidamente desde cualquier lugar del mundo.
Para el propósito de este artículo, te enfocarás más en el diseño arquitectónico donde puedes alojar tu sitio web para cumplir con los requisitos asignados para esta tarea y no tanto en el desarrollo del sitio web en sí.

Tener un sitio web es un tema candente, ya que cada negocio necesita uno.

Podrías preguntarte, ¿dónde puedo alojar este sitio web?

Permíteme presentarte dos poderosos servicios de AWS que pueden ayudarte a comenzar este proyecto asegurando una distribución global del contenido del sitio web:

AWS CloudFront
AWS S3

Diagrama: CloudFront y S3.

¿Qué método utilizaremos para desplegar esta infraestructura?

Desplegaremos esta infraestructura como código (IaC) utilizando Terraform.

¿Qué es Terraform y por qué es tan útil?

"Terraform es una herramienta para construir, cambiar y versionar infraestructura de forma segura y eficiente. Terraform puede gestionar proveedores de servicios existentes y populares, así como soluciones personalizadas internas."

Terraform es una poderosa herramienta declarativa que nos ayuda a gestionar una gran mayoría de servicios en la nube, además de proporcionar consistencia y visibilidad de los cambios en la infraestructura que ocurren en diferentes espacios de trabajo y entornos. Esta funcionalidad no solo mejora la calidad de vida de nuestros proyectos, sino que también mantiene informados a los ingenieros de software y a otros miembros del equipo.

Ten en cuenta que podemos crear o configurar cualquier servidor de AWS a través de la consola de gestión de AWS, pero el problema es que lleva tiempo si haces lo mismo una y otra vez. Al usar Terraform, no necesitamos iniciar sesión en la consola de gestión de AWS y podemos terminar nuestro trabajo solo con la línea de comandos.

En este proyecto encontrarás dos módulos. Un módulo te ayudará a desplegar un bucket S3 para almacenar tus archivos web y también utilizará el punto final del sitio web del bucket S3 desde la función de alojamiento de sitios web estáticos, sirviendo como origen con CloudFront como CDN.

El segundo te ayudará a desplegar buckets S3 para almacenar tus archivos web, pero esta vez CloudFront servirá como CDN así como un origen. Recomiendo el segundo módulo, ya que no necesitarías habilitar el alojamiento de sitios web estáticos en tu bucket porque esta infraestructura utilizará un punto final de API REST del bucket en lugar del punto final del sitio web de la función de alojamiento de sitios web estáticos.

Plantillas de Terraform:

# --- s3_module main file

resource "random_string" "bucket_rs" {
  count   = var.s3_count
  length  = 4
  special = false
  upper   = false

}
resource "aws_s3_bucket" "exos_bucket" {
  count = var.s3_count
  bucket = join("-", ["exos-bucket", random_string.bucket_rs[count.index].result])
  acl    = "public-read-write"
}

resource "aws_cloudfront_distribution" "exos_distribution" {
  count = var.s3_count
  origin {

    custom_origin_config {
      http_port = "80"
      https_port = "443"
      origin_protocol_policy = "match-viewer"
      origin_ssl_protocols = ["TLSv1", "TLSv1.1", "TLSv1.2"]

    }

    domain_name = aws_s3_bucket.exos_bucket[count.index].bucket_regional_domain_name
    origin_id = "exos_distribution"

  }

  enabled = true
  default_root_object = "index.html"

  default_cache_behavior {
    viewer_protocol_policy = "redirect-to-https"
    compress = true
    allowed_methods = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods = ["GET", "HEAD"]
    target_origin_id = "exos_distribution"
    min_ttl                = 0
    default_ttl            = 86400
    max_ttl                = 31536000




    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

  }

  price_class = "PriceClass_All"

  restrictions {
    geo_restriction {
      restriction_type = "whitelist"
      locations        = ["US", "CA", "GB", "DE"]
    }

  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

¿Qué es CloudFront?

"CloudFront es un servicio de Red de Entrega de Contenido (CDN) rápido. CloudFront proporcionará a nuestro proyecto una red distribuida global que servirá como caché de contenido, como imágenes, videos y archivos estáticos desde centros de datos distribuidos llamados ubicaciones de borde."

Mientras CloudFront mejora la experiencia del usuario al entregar contenido estático, también puede ser utilizado para gestionar múltiples solicitudes de usuarios mientras entrega excelentes servicios a los clientes. Pero las características de CloudFront no terminan aquí. Tiene increíbles características de seguridad integradas, como la mitigación de ataques DoS/DDoS, la Identidad de Acceso de Origen (OAI), que utilizaremos para controlar sin problemas el acceso a nuestros buckets S3. También podemos usar la función de geolocalización en la distribución de CloudFront, que puede ayudarnos a servir nuestro contenido dentro de ciertas regiones o países. Hay más características que esto, pero para el propósito de este artículo mencionaré solo algunas.

Un punto interesante a mencionar es que entregar contenido a través de CloudFront será más rentable cuando el número de solicitudes crezca en comparación con S3, así como cuando los datos transferidos entre los servicios de AWS y CloudFront no estén sujetos al costo de transferencia de datos.

¿Qué es S3?

"Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos que ofrece escalabilidad, disponibilidad de datos, seguridad y rendimiento líderes en la industria."

Además de ser un servicio de almacenamiento de objetos, S3 también puede alojar sitios web estáticos con técnicas del lado del cliente, como HTML, CSS y JavaScript, que no requieren scripts del lado del servidor, como PHP o ASP.NET.

El aspecto más fácil de tener S3 como un bucket de alojamiento de sitios web es que no necesitaremos solicitar un formulario para alojar nuestro sitio web estático ni pagar ningún costo inicial. Una vez que el sitio web estático de S3 esté configurado, se generará automáticamente un punto final de sitio web de Amazon S3 para el bucket. Utilizaremos el punto final del sitio web para probar la velocidad y el rendimiento.

Otro punto importante de ahorro de costos es que, en lugar de ejecutar servidores web como Nginx o Apache en instancias EC2, que pueden ser costosos, podemos alojar los archivos estáticos en S3.

Enlace al calculador mensual simple de S3 aquí

Velocidad de entrega de DNS de contenido utilizando el punto final del sitio web de CloudFront frente al punto final del sitio web de S3.

Usando AWS CloudFront name.cloudfront.net frente a bucketname-x23x.s3.amazonaws.com puntuación de rendimiento.

El mapa de solicitudes muestra cada una de las ubicaciones desde las cuales se perfiló el sitio web.

Puntuaciones de rendimiento promedio proporcionan una visión básica del tiempo de ida y vuelta de cualquier ubicación.

Conclusión

Ambos servicios, AWS CloudFront y AWS S3, se complementan entre sí y pueden ofrecerte un espacio poderoso para alojar tu sitio web y vale la pena intentarlo.

Beneficios de usar S3 y CloudFront:

Velocidad CDN más rápida con CloudFront.
Bajo costo de almacenamiento con S3 y transferencia de datos gratuita a CloudFront. Fuerte seguridad para ambos.

Es importante señalar que esta infraestructura puede ser más robusta al agregar otros servidores como AWS WAF, AWS Shield o Route53, que probablemente agregaré en un artículo posterior 😊.

Tener Terraform en la mezcla facilita la creación, destrucción de recursos, pruebas y depuración de tus proyectos.

Este proyecto de Terraform está diseñado dinámicamente para desplegar uno o más buckets S3 según tus requisitos. También crea una asociación de CDN de CloudFront para cada bucket.

Encuentra el repositorio de Terraform y las direcciones para este proyecto aquí

¿Listo para optimizar tus implementaciones de AWS?

Comienza a usar Terraform para gestionar tu infraestructura como código. Experimenta con el código proporcionado y comparte tus experiencias en los comentarios. Si te gustó este artículo, sígueme para más contenido sobre AWS y Terraform.

Tu participación es valiosa, y me encantaría saber de tus comentarios.

Lee esto antes de implementar S3 y CloudFront usando Terraform.

Augusto Valdivia — Tue, 31 Dec 2024 15:31:49 +0000

Hechos a considerar

La campaña de marketing es solo por unos días.
La empresa no sabe cuántos espectadores atraerá esta campaña a su sitio web, pero pronostican miles para los primeros días después del lanzamiento de la campaña.
Hay una gran preocupación por los ataques DoS/DDoS.
Debe estar dentro de su presupuesto.
Necesita ser accesible rápidamente desde cualquier lugar del mundo.
Para el propósito de este artículo, te enfocarás más en el diseño arquitectónico donde puedes alojar tu sitio web para cumplir con los requisitos asignados para esta tarea y no tanto en el desarrollo del sitio web en sí.

Tener un sitio web es un tema candente, ya que cada negocio necesita uno.

Podrías preguntarte, ¿dónde puedo alojar este sitio web?

Permíteme presentarte dos poderosos servicios de AWS que pueden ayudarte a comenzar este proyecto asegurando una distribución global del contenido del sitio web:

AWS CloudFront
AWS S3

Diagrama: CloudFront y S3.

¿Qué método utilizaremos para desplegar esta infraestructura?

Desplegaremos esta infraestructura como código (IaC) utilizando Terraform.

¿Qué es Terraform y por qué es tan útil?

Plantillas de Terraform:

# --- s3_module main file

resource "random_string" "bucket_rs" {
  count   = var.s3_count
  length  = 4
  special = false
  upper   = false

}
resource "aws_s3_bucket" "exos_bucket" {
  count = var.s3_count
  bucket = join("-", ["exos-bucket", random_string.bucket_rs[count.index].result])
  acl    = "public-read-write"
}

resource "aws_cloudfront_distribution" "exos_distribution" {
  count = var.s3_count
  origin {

    custom_origin_config {
      http_port = "80"
      https_port = "443"
      origin_protocol_policy = "match-viewer"
      origin_ssl_protocols = ["TLSv1", "TLSv1.1", "TLSv1.2"]

    }

    domain_name = aws_s3_bucket.exos_bucket[count.index].bucket_regional_domain_name
    origin_id = "exos_distribution"

  }

  enabled = true
  default_root_object = "index.html"

  default_cache_behavior {
    viewer_protocol_policy = "redirect-to-https"
    compress = true
    allowed_methods = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods = ["GET", "HEAD"]
    target_origin_id = "exos_distribution"
    min_ttl                = 0
    default_ttl            = 86400
    max_ttl                = 31536000




    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

  }

  price_class = "PriceClass_All"

  restrictions {
    geo_restriction {
      restriction_type = "whitelist"
      locations        = ["US", "CA", "GB", "DE"]
    }

  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

¿Qué es CloudFront?

¿Qué es S3?

"Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos que ofrece escalabilidad, disponibilidad de datos, seguridad y rendimiento líderes en la industria."

Otro punto importante de ahorro de costos es que, en lugar de ejecutar servidores web como Nginx o Apache en instancias EC2, que pueden ser costosos, podemos alojar los archivos estáticos en S3.

Enlace al calculador mensual simple de S3 aquí

Velocidad de entrega de DNS de contenido utilizando el punto final del sitio web de CloudFront frente al punto final del sitio web de S3.

Usando AWS CloudFront name.cloudfront.net frente a bucketname-x23x.s3.amazonaws.com puntuación de rendimiento.

El mapa de solicitudes muestra cada una de las ubicaciones desde las cuales se perfiló el sitio web.

Puntuaciones de rendimiento promedio proporcionan una visión básica del tiempo de ida y vuelta de cualquier ubicación.

Conclusión

Ambos servicios, AWS CloudFront y AWS S3, se complementan entre sí y pueden ofrecerte un espacio poderoso para alojar tu sitio web y vale la pena intentarlo.

Beneficios de usar S3 y CloudFront:

Velocidad CDN más rápida con CloudFront.
Bajo costo de almacenamiento con S3 y transferencia de datos gratuita a CloudFront. Fuerte seguridad para ambos.

Es importante señalar que esta infraestructura puede ser más robusta al agregar otros servidores como AWS WAF, AWS Shield o Route53, que probablemente agregaré en un artículo posterior 😊.

Tener Terraform en la mezcla facilita la creación, destrucción de recursos, pruebas y depuración de tus proyectos.

Este proyecto de Terraform está diseñado dinámicamente para desplegar uno o más buckets S3 según tus requisitos. También crea una asociación de CDN de CloudFront para cada bucket.

Encuentra el repositorio de Terraform y las direcciones para este proyecto aquí

¿Listo para optimizar tus implementaciones de AWS?

Tu participación es valiosa, y me encantaría saber de tus comentarios.

Una Guía para Principiantes sobre la Autenticación usando API Gateway y Lambda Authorizer

Augusto Valdivia — Sat, 21 Dec 2024 17:15:56 +0000

Entender cómo autenticar usuarios a través de un API Gateway puede ser un desafío, pero es una habilidad esencial para los desarrolladores, especialmente cuando se trata de proveedores de identidad (IdPs) como Okta o Active Directory. Esta guía proporciona una explicación clara, paso a paso, del flujo de autenticación utilizando un Lambda Authorizer, facilitando su comprensión para los principiantes.

Historia

Imagina que te estás preparando para una entrevista de trabajo en una empresa de tecnología, y el entrevistador te pregunta cómo manejar la autenticación de usuarios en una arquitectura sin servidor. Conocer el flujo de autenticación con un API Gateway y un Lambda Authorizer es crucial. Vamos a desglosarlo en partes manejables.

El Flujo de Autenticación

Autenticación del Usuario:

El proceso comienza cuando un usuario ingresa su ID de usuario y contraseña en un formulario de inicio de sesión. Envía estas credenciales a un IdP, como Okta o Active Directory.
Si las credenciales son válidas, el IdP autentica al usuario y devuelve un token (a menudo un JSON Web Token, o JWT). Este token sirve como prueba de que el usuario ha sido autenticado con éxito.

Llamada a la API con Token:

A continuación, el usuario desea acceder a un recurso a través del API Gateway. Para hacerlo, incluye el token recibido en el encabezado de su solicitud a la API.

Este token es esencial porque le dice al API Gateway que el usuario es quien dice ser. Sin este token, la solicitud será denegada.

Lambda Authorizer para Validación:

Dado que no estás utilizando AWS Cognito y en su lugar dependes de un IdP, se utiliza un Lambda Authorizer. Este es un código personalizado que escribes para validar el token.
Cuando el API Gateway recibe la solicitud, invoca el Lambda Authorizer. El autorizer extrae el token del encabezado de la solicitud y verifica su validez comunicándose con el IdP.

Autorización con Políticas IAM:

Una vez que se valida el token, el Lambda Authorizer también determina qué acciones puede realizar el usuario. Esto se hace especificando políticas IAM dentro del autorizer.

Estas políticas IAM dictan qué recursos de AWS puede acceder el usuario y qué acciones puede realizar. Por ejemplo, un usuario podría tener permiso para leer datos de una base de datos, pero no para escribir en ella. Luego, el API Gateway verifica estas políticas con AWS IAM para asegurar el cumplimiento.

Invocación del Backend:

Si la política IAM permite la acción solicitada, el API Gateway procede a invocar el servicio backend previsto, que podría ser otra función Lambda, un servicio de AWS o cualquier otro recurso.
En esta etapa, la solicitud del usuario se procesa y recibe la respuesta deseada.

Nota Especial

Es importante recordar que el Lambda Authorizer no necesita validar el token para cada llamada a la API. Para mejorar el rendimiento y reducir la latencia, puedes implementar un caché para las respuestas del autorizer. Esto significa que una vez que se valida un token, las solicitudes posteriores con el mismo token pueden procesarse más rápido.

Comprender este flujo de autenticación es vital para cualquier persona que trabaje con arquitecturas sin servidor. Tómate el tiempo para familiarizarte con cada paso, practica explicar el proceso y considera construir un pequeño proyecto que implemente estos conceptos. Este conocimiento no solo te ayudará en las entrevistas, sino que también te empoderará en aplicaciones del mundo real.

Plantilla de Terraform

Para ayudarte a implementar este flujo, aquí tienes una plantilla básica de Terraform que configura un API Gateway con un Lambda Authorizer:

  provider "aws" {
    region = "us-west-2"
  }
  resource "aws_lambda_function" "authorizer" {
    function_name = "LambdaAuthorizer"
    handler       = "authorizer.handler"
    runtime       = "nodejs14.x"
    role          = aws_iam_role.lambda_exec.arn
    source_code_hash = filebase64sha256("authorizer.zip")
  }
  resource "aws_iam_role" "lambda_exec" {
    name = "lambda_exec_role"
    assume_role_policy = jsonencode({
      Version = "2012-10-17"
      Statement = [{
        Action = "sts:AssumeRole"
        Principal = {
          Service = "lambda.amazonaws.com"
        } Effect = "Allow"
        Sid    = ""
      }]
    })
  }
  resource "aws_api_gateway_rest_api" "api" {
    name        = "MyAPI"
    description = "API Gateway con Lambda Authorizer"
  }
  resource "aws_api_gateway_resource" "resource" {
    rest_api_id = aws_api_gateway_rest_api.api.id parent_id = aws_api_gateway_rest_api.api.root_resource_id
    path_part   = "example"
  }
  resource "aws_api_gateway_method" "method" {
    rest_api_id   = aws_api_gateway_rest_api.api.id resource_id = aws_api_gateway_resource.resource.id http_method = "GET" authorization = "CUSTOM"
    authorizer_id = aws_api_gateway_authorizer.authorizer.id } resource "aws_api_gateway_authorizer" "authorizer" {
    rest_api_id = aws_api_gateway_rest_api.api.id name = "MyLambdaAuthorizer"
    authorizer_uri = "${aws_lambda_function.authorizer.invoke_arn}"
    type        = "REQUEST"
    identity_source = "method.request.header.Authorization"
  }
  output "api_endpoint" {
    value = "${aws_api_gateway_rest_api.api.invoke_url}/example"
  }

Aquí encontrarás el repositorio de GitHub que contiene el código y las instrucciones.

Repositorio de GitHub - ¡Próximamente!

¿Listo para optimizar tus implementaciones de AWS?

Tu participación es valiosa, y me encantaría saber de ti.

A Beginners Guide to Serverless API Gateway Authentication with Lambda Authorizer

Augusto Valdivia — Sat, 21 Dec 2024 16:51:56 +0000

Understanding how to authenticate users via an API Gateway can be a challenging yet essential skill for developers, especially when dealing with third-party identity providers (IdPs) like Okta or Active Directory. This guide provides a clear, step-by-step explanation of the authentication flow using a Lambda Authorizer, making it easy for beginners to grasp.

The Authentication Flow

User Authentication:

The process begins when users enter their user ID and password into a login form. They send these credentials to a third-party IdP, such as Okta or Active Directory.
If the credentials are valid, the IdP authenticates the user and returns a token (often a JSON Web Token, or JWT). This token serves as proof that the user has been successfully authenticated.

API Call with Token:

Next, the user wants to access a resource via the API Gateway. To do this, they include the received token in the header of their API request.
This token is essential because it tells the API Gateway that the user is who they claim to be. Without this token, the request will be denied.

Lambda Authorizer for Validation:

Since you are not using AWS Cognito and are instead relying on a third-party IdP, a Lambda Authorizer comes into play. This is a custom piece of code that you write to validate the token.
When the API Gateway receives the request, it invokes the Lambda Authorizer. The authorizer extracts the token from the request header and checks its validity by communicating with the third-party IdP.

Authorization with IAM Policies:

Once the token is validated, the Lambda Authorizer also determines what actions the user is allowed to perform. This is done by specifying IAM policies within the authorizer.
These IAM policies dictate what AWS resources the user can access and what actions they can perform. For example, a user might have permission to read data from a database but not to write to it. The API Gateway then checks these policies against AWS IAM to ensure compliance.

Backend Invocation:

If the IAM policy allows the requested action, the API Gateway proceeds to invoke the intended backend service, which could be another Lambda function, an AWS service, or any other resource.
At this stage, the user’s request is processed, and they receive the desired response.

Special Note

It’s important to remember that the Lambda Authorizer does not need to validate the token for every single API call. To enhance performance and reduce latency, you can implement caching for the authorizer’s responses. This means that once a token is validated, subsequent requests with the same token can be processed faster.

Understanding this authentication flow is vital for anyone working with serverless architectures. Take the time to familiarize yourself with each step, practice explaining the process, and consider building a small project that implements these concepts. This knowledge will not only help you in interviews but will also empower you in real-world applications.

Terraform Template

To help you implement this flow, here’s a basic previous Terraform template that sets up an API Gateway with a Lambda Authorizer:

  resource "aws_api_gateway_rest_api" "api" {
    name        = "MyAPI"
    description = "API Gateway with Lambda Authorizer"
  }
  resource "aws_api_gateway_resource" "resource" {
    rest_api_id = aws_api_gateway_rest_api.api.id parent_id = aws_api_gateway_rest_api.api.root_resource_id
    path_part   = "example"
  }
  resource "aws_api_gateway_method" "method" {
    rest_api_id   = aws_api_gateway_rest_api.api.id resource_id = aws_api_gateway_resource.resource.id http_method = "GET" authorization = "CUSTOM"
    authorizer_id = aws_api_gateway_authorizer.authorizer.id } resource "aws_api_gateway_authorizer" "authorizer" {
    rest_api_id = aws_api_gateway_rest_api.api.id name = "MyLambdaAuthorizer"
    authorizer_uri = "${aws_lambda_function.authorizer.invoke_arn}"
    type        = "REQUEST"
    identity_source = "method.request.header.Authorization"
  }
  output "api_endpoint" {
    value = "${aws_api_gateway_rest_api.api.invoke_url}/example"
  }

Here you will find the GitHub repository containing the code and instructions.

GitHub Repository - Coming Soon!

Ready to streamline your AWS deployments?

Start using Terraform to manage your infrastructure as code. Experiment with the provided code and share your experiences in the comments. If you liked this article, follow me for more content on AWS and Terraform.

Your participation is valuable, and I would love to hear from you.