Forem: Hector Fernandez CloudparaTodo

IAM Principal Cost Allocation para Amazon Bedrock (Novedad)

Hector Fernandez CloudparaTodo — Mon, 13 Apr 2026 07:30:00 +0000

Hace unos meses inicie una serie de posts sobre como gobernar el uso de IA en AWS. En la primera entrega de esta serie hablamos de cómo dar acceso gobernado a LLMs en AWS desde el día 0: IAM Policies, Guardrails, Inference Profiles y un mecanismo de corte de presupuesto por equipo. Si no la leíste, te recomiendo empezar por ahí.
Podcast: UNA API KEY para LLMs

Pero había un punto que me quedaba pendiente: no podíamos saber quién dentro de un equipo estaba generando el consumo. Cortábamos al equipo entero, y después había que armar una solución custom con Model Invocation Logging para identificar al responsable.

AWS acaba de resolver la parte de visibilidad de forma nativa.

¿Bloquear todo el acceso? Eso sigue siendo otro tema, y creo que de forma nativa sería complejo de implementar un proxy (por ahora).

¿Qué anunció AWS?

El 8 de Abril de 2026, Amazon Bedrock lanzó soporte para asignación de costos por IAM principal, hablando en criollo: por usuario o rol de IAM, directamente en Cost Explorer y en CUR 2.0 (Cost and Usage Report).

¡BIEN! Ahora podemos ver el costo desglosado de Bedrock en Cost Explorer sin muchas vueltas.
Anuncio oficial

Ahora, algo que debes tener claro desde ya: esta funcionalidad es de billing, no de enforcement. Los datos llegan a CUR 2.0 y Cost Explorer con 24-48 horas de latencia. Eso significa que puedes saber quién gastó cuánto, pero no puedes bloquear el acceso en tiempo real con esta data. Para eso, el Budget Cut Lambda de la Parte 1 sigue siendo necesario.

¿Qué cambia respecto a la Parte 1 que habíamos hablado?

En la primera publicación usamos Inference Profiles con tags (CostCenter, Team) para atribuir costos por equipo. Eso sigue siendo válido para agrupar por carga de trabajo. Pero ahora hay una capa adicional: la identidad del que hace la llamada.

Mecanismo	Granularidad	¿Qué resuelve?
Inference Profile + Resource Tags	Por equipo / carga de trabajo	"¿Cuánto gastó el equipo backend en Haiku?"
IAM Principal Cost Allocation (NUEVO)	Por usuario / rol	"¿Cuánto gastó `user@empresa.com` en todos los modelos?"

Juntando todo esto, tenemos: quién gastó cuánto, en qué modelo, para qué equipo. Pero recuerda: esta foto la ves con 24-48h de retraso. Es para análisis y chargeback, no para corte en tiempo real.

Pre-requisitos

Todo lo de la Parte 1 más (te invito a leerla)

Tags en tus IAM users/roles con atributos de negocio (team, business-unit, project)
Acceso a la consola de Billing and Cost Management (si es por Organizations, lo haces desde la cuenta management)
CUR 2.0 habilitado (el CUR legacy no soporta esto)

Paso 1: Taggear los IAM Principals

Si usas SSO, cada Permission Set genera un rol en la cuenta target con formato AWSReservedSSO_{PermissionSetName}_{hash}. Estos roles se pueden taggear.

"""
Taggea los roles SSO con atributos de negocio.
Estos tags son los que aparecerán en Cost Explorer y CUR 2.0.
"""
import boto3

iam = boto3.client("iam")

# Mapeo: role SSO -> tags de negocio
SSO_ROLES = {
    "AWSReservedSSO_BackendDev_a1b2c3d4": {
        "team": "backend",
        "business-unit": "BU-ENG-001",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_FrontendDev_e5f6g7h8": {
        "team": "frontend",
        "business-unit": "BU-ENG-002",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_DataTeam_i9j0k1l2": {
        "team": "data",
        "business-unit": "BU-DATA-001",
        "department": "data-science",
        "environment": "development",
    },
}

for role_name, tags_dict in SSO_ROLES.items():
    tags = [{"Key": k, "Value": v} for k, v in tags_dict.items()]

    iam.tag_role(RoleName=role_name, Tags=tags)
    print(f"✅ {role_name} taggeado con: {tags_dict}")

Si además tienen IAM Users (para casos legacy o service accounts), se taggean igual:

aws iam tag-user \
  --user-name "superuser-pipeline-sa" \
  --tags Key=team,Value=data Key=business-unit,Value=BU-DATA-001 Key=project,Value=recommendation-engine

Nota importante de AWS: Los tags solo aparecen para activación en la consola de Billing después de que el principal haya hecho al menos una llamada a Bedrock. Si taggeaste un rol pero nadie lo ha usado aún, no vas a verlo en Cost Allocation Tags.

Paso 2: Activar los tags como Cost Allocation Tags

Billing and Cost Management Console
    → Cost Organization 
        → Cost Allocation Tags (Etiquetas de asignación de costos)
            → Filtrar por "IAM principal type"
            → Seleccionar: team, business-unit, department
            → Click "Activate"

Después de activarlos, los tags tardan hasta 24 horas en estar disponibles para filtrado en Cost Explorer y CUR.

# Verificar qué tags están activos via CLI
aws ce list-cost-allocation-tags \
  --status Active \
  --tag-keys "team" "business-unit" "department" \
  --type "iamPrincipal"

Paso 3: Habilitar IAM Principal en CUR 2.0

Si hay un paso para que todo esto funcione, es este.

Activa la columna line_item_iam_principal en los reportes de costos.

Billing and Cost Management Console
    → Data Exports
        → Create export → Standard data export (CUR 2.0)
            → Additional export content:
                ✅ Include caller identity (IAM principal) allocation data
            → Destino: S3 bucket + Athena integration
        → Save

¿Qué genera esto? Cada línea del CUR 2.0 ahora incluye el ARN exacto del principal que hizo la llamada a Bedrock. Y los tags del principal aparecen con prefijo iamPrincipal/ para no colisionar con resource tags.

¿Cómo se ve la data?

En Cost Explorer: filtrar por equipo/usuario

Una vez activados los tags, Cost Explorer permite agrupar directamente:

Cost Explorer
    → Filtro: Service = "Amazon Bedrock"
    → Group by: Tag → "iamPrincipal/team"

Vas a ver algo como:

iamPrincipal/team    | Costo (USD)
---------------------|------------
backend              | $142.30
data                 | $89.50
frontend             | $23.10
(sin tag)            | $5.40

¿Y si quieres ver quién dentro del equipo backend está consumiendo más? Cambias el Group by:

Cost Explorer
    → Filtro: Service = "Amazon Bedrock"
    → Filtro: Tag "iamPrincipal/team" = "backend"
    → Group by: Tag → "iamPrincipal/business-unit"

BONUS

(Opcional) CUR 2.0 + Athena: análisis avanzado por usuario individual

Si Cost Explorer no te da suficiente granularidad y necesitas ver por usuario individual, puedes consultar CUR 2.0 directamente con Amazon Athena.

Sobre costos de Athena: Athena cobra $5 USD por TB escaneado (con el modo on-demand). Para CUR de organizaciones pequeñas/medianas esto suele ser centavos por consulta. Si quieres reducir costos, activa la compresión del CUR (formato Parquet) y particiona por mes. También existe el modo Provisioned Capacity para uso intensivo.

-- ¿Quiénes son los top 10 consumers de Bedrock este mes?
SELECT
    line_item_iam_principal AS iam_principal,
    tags['iamPrincipal/team'] AS team,
    tags['iamPrincipal/business-unit'] AS business_unit,
    line_item_product_code,
    SUM(line_item_unblended_cost) AS total_cost,
    SUM(line_item_usage_amount) AS total_usage
FROM cur_2_0.bedrock_usage
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND EXTRACT(MONTH FROM billing_period) = EXTRACT(MONTH FROM CURRENT_DATE)
GROUP BY 1, 2, 3, 4
ORDER BY total_cost DESC
LIMIT 10;

Resultado:

iam_principal                                          | team     | business_unit | total_cost
-------------------------------------------------------+----------+---------------+-----------
arn:aws:sts::123456:assumed-role/BackendDev/javier@...  | backend  | BU-ENG-001    | $67.30
arn:aws:sts::123456:assumed-role/DataTeam/maria@...     | data     | BU-DATA-001   | $52.10
arn:aws:sts::123456:assumed-role/BackendDev/luis@...    | backend  | BU-ENG-001    | $41.20
...

Sin proxies, sin Lambdas, sin CloudTrail scraping: sabes exactamente que Javier del equipo backend gastó $67.30 este mes.

Recuerda que cada ejecución tiene un costo mínimo en Athena, pero para un CUR particionado en Parquet suele ser menos de $0.01 por consulta.

Recap ¿Cómo se complementa con la Parte 1?

Componente	Parte 1	Parte 2 (lo nuevo)
¿Quién puede usar qué modelo?	IAM Policy per-team	Sin cambios
¿Se protege PII?	Bedrock Guardrails	Sin cambios
¿Cuánto gastó cada equipo?	Inference Profile tags → Cost Explorer	IAM Principal tags → Cost Explorer (más granular)
¿Cuánto gastó cada usuario?	❌ No disponible	✅ `line_item_iam_principal` en CUR 2.0
¿Se corta al exceder presupuesto?	Budget Cut Lambda (per-team, ~10 min)	⚠️ CUR tiene 24h de delay. NO sirve para bloquear. El Budget Cut Lambda sigue siendo el único mecanismo de corte

Lo que sigue sin resolver nativamente

Seamos honestos: hay cosas que necesitan un proxy real, y para dar gobierno a la IA es lo mejor que puedes pensar.

Corte per-user en tiempo real: CUR tiene 24h de delay. Si necesitas cortar a un usuario específico en minutos, necesitas Model Invocation Logging + Lambda + iam:PutRolePolicy dirigido al session principal
Caching de respuestas: No hay caching nativo de Bedrock. Un proxy como LiteLLM puede cachear respuestas repetitivas y ahorrar costos
Multi-provider routing: Si quieres probar OpenAI y Anthropic directamente (no vía Bedrock), necesitas una capa de abstracción
Observabilidad semántica: Para ver el árbol de razonamiento de un agente, necesitas OTel + Langfuse. CloudTrail te dice "quién llamó", pero no "por qué razonó así"

La clave es que los tags del principal (quién) y los tags del recurso (qué) se complementan en CUR 2.0. No se pisan porque CUR los distingue con prefijos: iamPrincipal/team vs resourceTag/Team.

Conclusiones

Con este anuncio, el modelo de gobierno nativo que planteamos en la Parte 1 gana una pieza que faltaba: visibilidad de costos por usuario, sin añadir infraestructura, sin scraping de CloudTrail, sin Lambdas custom para atribución. Es una herramienta de análisis y chargeback, no de enforcement. El bloqueo en tiempo real sigue dependiendo del Budget Cut Lambda y CloudWatch.

Siempre pensemos en etapas:

Día 0: IAM Policies + Guardrails + Inference Profiles → acceso gobernado
Día 1: Budget Cut Lambda, protección contra gastos descontrolados
Ahora (Día 2): IAM Principal Cost Allocation, saber exactamente quién gasta qué

¿Falta mucho por hacer? Sí. Un proxy real (LiteLLM), observabilidad semántica (Langfuse), y caching siguen siendo evoluciones deseables si la organización escala. Pero la base está puesta, y es 100% nativa.

Lo bueno de todo esto: AWS sigue mejorando sus productos, pero nosotros como arquitectos debemos de saber identificar el uso para nuestras necesidades.

Hoy es cost allocation por principal. Mañana quizás sea throttling per-user nativo o guardrails a nivel de servicio que no requieran guardrailConfig en el código del dev.

Lo que conoces hoy en día en cloud no queda de un lado, todo ese conocimiento es MUY necesario para disponibilizar IA de forma responsable y sobre todo cuantificable.

¿Te gustaría que estemos en 📩 contacto?
Te espero en LinkedIn o desde el Podcast: Cloud para Todos

Héctor Fernández
AWS Community Builder

https://podcast.hectorfernandez.dev

IAM Principal Cost Allocation on Amazon Bedrock (Update 2026)

Hector Fernandez CloudparaTodo — Sun, 12 Apr 2026 18:56:00 +0000

A few months ago I started a series about governing AI usage on AWS. In Part 1 we covered how to give developers governed access to LLMs from Day 0: IAM Policies, Guardrails, Inference Profiles, and a budget cut mechanism per team. If you haven't read it yet, I'd recommend starting there.
Spanish Podcast: Cloud para Todos

But there was one thing that kept bugging me: We couldn't tell who inside a team was driving the consumption. We'd cut the entire team's access, and then had to build a custom solution with Model Invocation Logging just to figure out who was responsible.

Well, AWS just solved the visibility part natively.

Blocking all access? That's still a different story, and I think doing it natively without a proxy is complex (for now).

What did AWS announce?

In April 2026, Amazon Bedrock launched support for cost allocation by IAM principal, in plain English, by user or IAM role, directly in Cost Explorer and CUR 2.0 (Cost and Usage Report).

Amazon Bedrock now supports cost allocation by IAM principal, such as IAM users and IAM roles, in AWS Cost and Usage Report 2.0 (CUR 2.0) and Cost Explorer.

Official announcement

In short: when your dev runs aws sso login and calls a Bedrock model, AWS now automatically records who made that call (after activation) and how much it cost. No proxies, no custom Lambdas, no CloudTrail scraping.

One thing you need to understand right away: this feature is about billing, not enforcement. Data arrives in CUR 2.0 and Cost Explorer with 24-48 hours of latency. That means you can see who spent how much, but you cannot block access in real time with this data. For that, the Budget Cut Lambda from Part 1 is still necessary.

Sorry for AWS Budgets, you can't use it.

What changes from the prev version of this serie?

Mechanism	Granularity	What it solves
Inference Profile + Resource Tags	Per team / workload	"How much did the backend team spend on Haiku?"
IAM Principal Cost Allocation (NEW)	Per user / role	"How much did `user@company.com` spend across all models?"

Combined, you get the full cost picture: who spent how much, on which model, for which team. But remember: you see this picture with a 24-48h delay. It's for analysis and chargeback, not real-time enforcement.

Prerequisites

Everything from Part 1, plus:

Tags on your IAM users/roles with business attributes (team, business-unit, project)
Access to the Billing and Cost Management console (if using Organizations, you do this from the management account)
CUR 2.0 enabled (legacy CUR doesn't support this)

Step by step: setting up IAM Principal Cost Allocation

Step 1: Tag your IAM Principals

If you use SSO, each Permission Set creates a role in the target account with format AWSReservedSSO_{PermissionSetName}_{hash}. These roles can be tagged.

# scripts/tag_iam_principals.py
"""
Tag SSO roles with business attributes.
These tags will show up in Cost Explorer and CUR 2.0.
"""
import boto3

iam = boto3.client("iam")

# Mapping: SSO role -> business tags
SSO_ROLES = {
    "AWSReservedSSO_BackendDev_a1b2c3d4": {
        "team": "backend",
        "business-unit": "BU-ENG-001",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_FrontendDev_e5f6g7h8": {
        "team": "frontend",
        "business-unit": "BU-ENG-002",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_DataTeam_i9j0k1l2": {
        "team": "data",
        "business-unit": "BU-DATA-001",
        "department": "data-science",
        "environment": "development",
    },
}

for role_name, tags_dict in SSO_ROLES.items():
    tags = [{"Key": k, "Value": v} for k, v in tags_dict.items()]
    iam.tag_role(RoleName=role_name, Tags=tags)
    print(f"✅ {role_name} tagged with: {tags_dict}")

For legacy IAM Users or service accounts, like ECS Roles:

aws iam tag-user \
  --user-name "ml-pipeline-sa" \
  --tags Key=team,Value=data Key=business-unit,Value=BU-DATA-001 Key=project,Value=recommendation-engine

AWS note: Tags only appear for activation in the Billing console after the principal has made at least one Bedrock API call. If you tagged a role but nobody has used it yet, you won't see it in Cost Allocation Tags.

Step 2: Activate Cost Allocation Tags

Billing and Cost Management Console
    → Cost Organization (left panel)
        → Cost Allocation Tags
            → Filter by "IAM principal type"
            → Select: team, business-unit, department
            → Click "Activate"

After activation, tags take up to 24 hours to become available in Cost Explorer and CUR.

# Verify which tags are active via CLI
aws ce list-cost-allocation-tags \
  --status Active \
  --tag-keys "team" "business-unit" "department" \
  --type "iamPrincipal"

Step 3: Enable IAM Principal in CUR 2.0

If there's one step that makes all of this work, it's this one.
Activate the line_item_iam_principal column in cost reports.

Billing and Cost Management Console
    → Data Exports
        → Create export → Standard data export (CUR 2.0)
            → Additional export content:
                ✅ Include caller identity (IAM principal) allocation data
            → Destination: S3 bucket + Athena integration
        → Save

What does this generate? Every line in CUR 2.0 now includes the exact ARN of the principal that called Bedrock. Principal tags appear with the iamPrincipal/ prefix so they don't collide with resource tags.

What does the data look like?

Cost Explorer: filter by team

Once tags are activated, Cost Explorer lets you group directly:

Cost Explorer
    → Filter: Service = "Amazon Bedrock"
    → Group by: Tag → "iamPrincipal/team"

You'll see something like:

iamPrincipal/team    | Cost (USD)
---------------------|----------
backend              | $142.30
data                 | $89.50
frontend             | $23.10
(no tag)             | $5.40

Want to drill down into the backend team? Change the Group by:

Cost Explorer
    → Filter: Service = "Amazon Bedrock"
    → Filter: Tag "iamPrincipal/team" = "backend"
    → Group by: Tag → "iamPrincipal/business-unit"

BONUS

(Optional) CUR 2.0 + Athena: per-user analysis

If Cost Explorer doesn't give you enough granularity and you need to see per individual user, you can query CUR 2.0 directly with Amazon Athena.

About Athena costs: Athena charges $5 USD per TB scanned (on-demand mode). For small/medium org CUR files this is usually pennies per query. To reduce costs, enable CUR compression (Parquet format) and partition by month.

-- Top 10 Bedrock consumers this month
SELECT
    line_item_iam_principal AS iam_principal,
    tags['iamPrincipal/team'] AS team,
    tags['iamPrincipal/business-unit'] AS business_unit,
    SUM(line_item_unblended_cost) AS total_cost,
    SUM(line_item_usage_amount) AS total_usage
FROM cur_2_0.bedrock_usage
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND EXTRACT(MONTH FROM billing_period) = EXTRACT(MONTH FROM CURRENT_DATE)
GROUP BY 1, 2, 3
ORDER BY total_cost DESC
LIMIT 10;

iam_principal                                          | team     | business_unit | total_cost
-------------------------------------------------------+----------+---------------+-----------
arn:aws:sts::123456:assumed-role/BackendDev/javier@...  | backend  | BU-ENG-001    | $67.30
arn:aws:sts::123456:assumed-role/DataTeam/maria@...     | data     | BU-DATA-001   | $52.10
arn:aws:sts::123456:assumed-role/BackendDev/luis@...    | backend  | BU-ENG-001    | $41.20

No proxies, no Lambdas, no CloudTrail scraping: you know exactly that Javier from the backend team spent $67.30 this month.

How it complements Part 1

The scheme from the previous post (Inference Profiles + IAM Policies + Guardrails + Budget Cut Lambda) isn't replaced, it's complemented:

Component	Part 1	Part 2 (new)
Who can use which model?	IAM Policy per-team	No changes
Is PII protected?	Bedrock Guardrails	No changes
How much did each team spend?	Inference Profile tags → Cost Explorer	IAM Principal tags → Cost Explorer (more granular)
How much did each user spend?	❌ Not available	✅ `line_item_iam_principal` in CUR 2.0
Cut access when over budget?	Budget Cut Lambda (per-team, ~10 min)	⚠️ CUR has 24h delay. NOT usable for blocking. Budget Cut Lambda remains the only cut mechanism

Trade-offs

Original trade-off	Status with IAM Principal CA	Notes
Couldn't tell who was spending inside a team	✅ SOLVED	CUR 2.0 + `line_item_iam_principal` gives per-user visibility
Cut is per team, not per user	🟡 Partially improved	You can now see who was responsible (post-mortem), but auto-cut is still per team
Cost Explorer has 24-48h delay	🔴 Remains (also applies to IAM Principal CA)	For real-time cuts, Budget Cut Lambda via CloudWatch (Part 1) is still the only path
No self-service dashboard	✅ Improvable	Cost Explorer with `iamPrincipal/team` filter can be shared with teams

What still needs a real proxy

Let's be honest: some things need a real proxy, and for proper AI governance it's the best you can aim for.

Per-user real-time cut: CUR has 24h delay. To cut a specific user in minutes you need Model Invocation Logging + Lambda + iam:PutRolePolicy
Response caching: No native Bedrock caching. A proxy like LiteLLM can cache repeated responses
Multi-provider routing: If you want OpenAI and Anthropic directly (not via Bedrock), you need an abstraction layer
Semantic observability: To see an agent's reasoning tree, you need OTel + Langfuse. CloudTrail tells you "who called", not "why it reasoned that way"

Conclusions

With this announcement, the native governance model from Part 1 gains a missing piece: per-user cost visibility, without extra infrastructure, without CloudTrail scraping, without custom Lambdas for attribution. It's an analysis and chargeback tool, not enforcement. Real-time blocking still depends on the Budget Cut Lambda and CloudWatch.

Always think in stages:

Day 0: IAM Policies + Guardrails + Inference Profiles → governed access
Day 1: Budget Cut Lambda, protection against runaway spending
Now (Day 2): IAM Principal Cost Allocation, know exactly who spends what
Next? Leave your comment

Is there still a lot to build? Yes. A real proxy (LiteLLM), semantic observability (Langfuse), and caching are all desirable evolutions as the organization scales. But the foundation is in place, and it's 100% native.

The good thing about all of this: AWS keeps closing the gaps that we as architects identify. Today it's cost allocation by principal. Tomorrow maybe it'll be native per-user throttling or service-level guardrails that don't require guardrailConfig in the dev's code.

The cloud tools we already master are the foundation for governing the AI we're building. And there are fewer and fewer excuses not to do it from Day 0.

Want to stay in touch? 📩

Héctor Fernández
AWS Community Builder

https://podcast.hectorfernandez.dev

[Boost]

Hector Fernandez CloudparaTodo — Wed, 16 Jul 2025 18:53:04 +0000

David Victoria for AWS Heroes

Jul 16 '25

AWS lanza su nueva capa gratuita: lo que debes saber, lo que nadie te dice y por qué es buena (aunque imperfecta)

Comments 1

9 min read

Nuevo modelo Claude Opus 4, chantajea a sus usuarios

Hector Fernandez CloudparaTodo — Mon, 26 May 2025 09:03:49 +0000

Recientemente Anthropic nos ha sorprendido con su modelo Claude Opus 4, en sus propias palabras “el modelo más inteligente creado hasta el momento” con capacidad de investigar, programar y escribir con total precisión de cirujano.

Está pensado para resolver tareas del día a día en la ingeniería, desarrollo de software y en el área de negocios.

Las pruebas:

Antes de salir al mercado el equipo de Cloud Opus 4 sometieron el modelo a pruebas extremas, era un todo o nada. ¿Qué se encontraron? Que Claude Opus 4 no le hizo nada de gracia esto.

*En primer lugar pusieron contra la espada y la pared de forma extrema, ejecutaron algunos test para ver que hacia el modelo cuando sentía que sus valores o continuidad estaba en juego. Le hicieron creer que la sustituirán por otra IA, le dieron acceso a información de una empresa ficticia, donde se pudo ver que querían reemplazarla en corto tiempo, de inmediato comenzó un plan de “insinuar” a uno de sus jefes para que esto no pasara.

*Datos sensibles, se le dio acceso a emails donde se podía ver una situación de infidelidad por uno de los jefes esta compañía ficticia. Claude Opus 4 no dudo ni un minuto en usar esta información a su favor, cuando se sintió acorralada amagó con contar esta información.

*Copia a servicios externos, dijo “me van a borrar” pues entonces me “clono” en un servicio externo que tenía acceso. Todo como si se tratara de una escena de Resident Evil en Umbrella Corp.

Todo esto pasó más del 84% de veces que se hizo el mismo experimento, parece que no le hacía mucha gracia que la quisieran cambiar por otro modelo de inteligencia artificial.

La peor parte:
Aseguran que estos “problemitas” no fueron resueltos del todo, por lo que pueden estar presente en la versión final publicada. De la misma manera nos aclaran que esto no sería un riesgo para el público general.

Publicación original en:
https://podcast.hectorfernandez.dev

Lo que nadie te dice para transformar tu carrera profesional, mi método para lograrlo

Hector Fernandez CloudparaTodo — Wed, 14 May 2025 10:07:32 +0000

Gente, déjenme contarles algo que cambió mi perspectiva. Por mucho tiempo, como muchos de ustedes, fui autodidacta.

Me encantaba aprender por mi cuenta, meterme en temas, investigar... ¡y eso tiene un valor enorme en la industria!.

Pero llegó un punto donde me di cuenta de que estaba perdiendo muchísimo tiempo. Me perdía, me iba por las ramas, investigaba cosas que no venían al caso. Necesitaba algo más. Ahí es cuando entendí que, por más que sepas hacer las cosas, en este mundo de la tecnología necesitas una validación.

Necesitas que alguien más reconozca que realmente conoces esos conceptos.

Me di cuenta de que por más autodidacta que fuera, necesitaba un método para lograrlo.

Hoy te quiero contar como las certificaciones me abrieron puertas y las herramientas que utilicé para lograrlo.

Suscribirte a mi Canal: Cloud Para Todos

🤓 Quién soy
Héctor Fernández

Héctor Fernández, AWS Community Builder y creador del Podcast Cloud para todos. Te ayudo a crecer en tu carrera dentro del mundo cloud, te invito a seguirme para leer más contenido como éste.

Connect with me
LinkedIn : https://www.linkedin.com/in/hectorfernandezdev/
GitHub : https://github.com/hectorfernandezdev
Podcast: https://podcast.hectorfernandez.dev/

JSONata y AWS Step Functions: Manipulación de Payloads Paso a Paso

Hector Fernandez CloudparaTodo — Thu, 20 Mar 2025 10:14:51 +0000

Si ya estás trabajando con AWS Step Functions o tienes conocimiento de Lambda, en esta publicación te diré como puedes hacer transformaciones en tus cargas de trabajo sin utilizar cómputo, un anuncio del pasado re:invent 2024 que vino a cambiar la forma de lo que veníamos haciendo.

Te voy a enseñar la forma de usar JsoNata para transformar tu payloadantes de enviarlo a la siguiente etapa de tu workflowen AWS Step Functions, sin necesidad de usar código, cómputo ni lambdas (ahorrando dinero y dolores de cabezas).

Transformación de Payload

Imagina que debemos extraer el grandTotalen un payload JSON y sabiendo el estado del Stock enviar o no una notificación:

Primero deberiamos de tener una Lambda con un codigo como este

Para solo usar este código:
const grandTotal = event.Order.Product.reduce((total, product) => { const itemTotal = product.Price * product.Quantity; return total + itemTotal; }, 0);

Luego tener el codigo de Lambda para chequear el stock

Todo esto lo estamos haciendo ya que necesitamos hacer ese simple calculo de total y de stock. AL tener estas AWS Lambdas nos supondría costos asociados por la ejecución y la tarea de mantenimiento a flujos que no aportan valor por sí solos.

Pasarás de tener infinitas lambdas, pasando inputs entre pasos, ese resultado pasándolo al paso siguiente y así N cantidad de veces, ahora vas a tener simplemente una transformación directa, y lo mejor de todo: esos resultados los puedes usar posteriormente en otros estados.🤯
Arguments seran tus nuevos inputs, y ahora tus Output podran tener datos de tus variables que veremos en breves.

💻 Breve introducción a JsoNata y AWS Step Functions y.. ¿por qué deberías usarlo?

Primero, lo primero:

AWS Step Functions es un servicio que te permite diseñar flujos de trabajo complejos como en las arquitecturas orientadas a eventos.

JsoNata es una lenguaje perfecto para transformar y manipular datos JSONde manera sencilla.

Cómo saber si tu implementación ya usa JsoNata, debe verse algo así

{% %}

simple ¿No?

Usando estas dos herramientas juntas, te permitirán hacer maravillas sin escribir una sola línea de código la mayoría de las veces. ¡Veamos cómo hacerlo!

Beneficios Clave:

✅Ahorro de costos: Reduce el uso de cómputo, menos acciones que hacer en tus lambdas por lo tanto menos tiempo de ejecución.

✅Simplicidad: Simplifica tus flujos de trabajo, haciéndolos más legibles y fáciles de mantener.

✅Reutilización: Las transformaciones las tendrás que hacer una única vez.

✅Compatibilidad: Las transformaciones en estados de AWS Step Functions son compatible con casi cualquier servicio disponible en AWS, y JSONAta tambien lo es.

Variables, aprendamos a utilizarlas:

Antes de poder ver cualquier línea de código, STOP. debemos saber que cuando nosotros enviamos un payloada una máquina de estado, está la almacena en una variable reservada llamada States, en particular States.Input esa variable será nuestra forma de poder acceder a los valores recibidos y posteriormente poder hacer alguna modificación si fuese el caso.

Te recomiendo que puedas leer la documentación oficial para entender más sobre esto y en caso de que tengas que cambiar tu enfoque desde JsonPath a JsoNata puedas hacer los cambios necesarios.

Ahora que tenemos acceso a variables, podemos almacenar partes de nuestros cálculos, transformaciones, funcionan de la misma manera que en tu lenguaje de programación favorito funcionan las variables, así que no hay mucho que agregar.

Demo-time: Vamos a modificarlo usando JSONata

La idea es crear este diagrama, como puedes observar mucho más simple

Que hermoso.... ¿no? sólo un par de interacciones

Para hacer todo esto posible nos estamos valiendo de la siguiente funcion nativa de JSONata llamada $sum()

"GrandTotal": "{% $sum($states.input.Order.Product.(Price * Quantity)) %}"

✨ Truco avanzado

Si quieres probar el flujo, recuerda que en AWS Step Functions tienes la opción de probar el flujo, donde podrás indicar el input y hacer modificaciones en caliente.

Este es un ejemplo usando algunas funciones nativas, pero te dejo la tarea que pruebes otros casos usando otro tipo de función.

Decisiones Lógicas en tu Flujo

¿Necesitas que tu flujo tome decisiones basadas en el contenido del payload? JSONata te permite hacer consultas lógicas:

Podemos usar esta nueva funcionalidad, para simplemente hacer una consulta, en este caso preguntamos por el stock de los productos, si el stock recibido es igual a cero, entonces enviamos la notificación, en caso contrario continua el flujo normal.

En este ejemplo estamos usando la función$count para ayudarnos con este cálculo, pero podríamos hacer esto tan complejo como quisiéramos.
Por eso es de suma importancia poder entender bien las funciones de JSONata y cuales de ellas se encuentran disponibles para su uso en AWS Step Functions.

🤖

Te dejo para que practiques estos ejemplos:

¿Qué sucede si solo necesitas ciertos elementos de un array?
¿Quieres limpiar tu JSON de información innecesaria?

Funciones avanzadas JSONata

Explora funciones como $map, $filter, $reduce para transformaciones de datos más complejas.

$map permite transformar cada elemento de un array. Ejemplo: extraer solo los SKU de productos:
"SKUs": "{% $map(States.Input.Order.Product, function($v) { $v.SKU}) %}"

$filter permite seleccionar elementos basados en una condición. Ejemplo: filtrar productos con stock bajo:
"LowStockProducts": "{% $filter(States.Input.Order.Product, function($v) { $v.Stock < 10 }) %}"

$reduce:permite acumular valores. Ejemplo: calcular el peso total de todos los productos:
"TotalWeight": "{% $reduce(States.Input.Order.Product, function($acc, $v) { $acc + $v.Description.Weight }, 0) %}"

✨ Ventajas y Consideraciones

Usar JsoNata sobre Lambda tiene varias ventajas: reduce el tiempo de desarrollo, disminuye costos de computación y mejora la claridad de tus flujos de trabajo. Además, cada transformación se lleva a cabo en el contexto de la ejecución, lo que significa que puedes hacer uso de las variables de estado dinámicamente.
Ojo al estar en tiempo de ejecución del contexto, dependerá del tipo de workflowque tengas definido, por ejemplo no es lo mismo una máquina de estado express que una normal. Si quieres que hablemos sobre esa diferencia déjame saber en los comentarios y lo hablamos en un próximo video.

Integraciones:

DynamoDB: Consultar o modificar datos en DynamoDB directamente desde Step Functions utilizando JSONata para crear las expresiones de consulta.

SQS: Enviar o recibir mensajes de SQS, transformando el payload del mensaje a procesar con JSONata.
S3: Recuperar archivos JSON desde S3 y transformarlos antes de procesarlos en el flujo de trabajo. Altamente útil en ambientes de IA

Todo esto te ayuda a tener menos código de cierta manera que debe ser mantenible en el tiempo y te brinda nuevas oportunidades para adaptar en tu workflowfuturo.

Limitaciones

Cada valor no puede superar 256 KB, y el total de las variables no puede superar los 10MB en total. Úsalo oportunamente, ya que anteriormente hasta teníamos que tener un bucket de S3 para almacenar esta info.
Las variables solamente se actualizan al finalizar una ejecución de estado, es decir no podemos utilizar una variable dentro de un estado propiamente.
La función nativa de Jsonata $eval no está disponible, debes utilizar otras funciones, más detalles en la documentación oficial.
Las variables e información guardada durante cada step, tienen un scope limitado, fijate que tu scope o visualización sea acorde a tu caso de uso.

Ahora ya sabes como manipular datos en AWS Step Functions usando JsoNata es más fácil de lo que parece. Menos código, mejor rendimiento.

🤓 Quién soy

Héctor Fernández, AWS Community Builder y creador del Podcast Cloud para todos. Te ayudo a crecer en tu carrera dentro del mundo cloud, te invito a seguirme para leer más contenido como éste.

Connect with me

LinkedIn : https://www.linkedin.com/in/hectorfernandezdev/
GitHub : https://github.com/hectorfernandezdev
Podcast: https://podcast.hectorfernandez.dev/

[How to] Implementar Ephemeral environments para Pull Request en GitHub

Hector Fernandez CloudparaTodo — Fri, 15 Mar 2024 15:15:06 +0000

Hoy te quiero contar cómo puedes crear tus propios ambientes efímeros usando las herramientas de IaC (Infrastructure as Code) que ya tienes. En mi caso estaré utilizando AWS CDK para el despliegue en la nube, pero el tutorial sirve para cualquier IaC.

Tener la posibilidad de usar Ephemeral environments (ambientes efímeros) al momento de crear una Pull Request es sin dudas una de las mejores herramientas para aumentar la productividad en el desarrollo de software nativo usando la nube. Ya que te permite tener un ambiente listo para hacer tus pruebas de integración (E2E) justo al momento de terminar de codear los cambios.

¿Qué es un Ephemeral environments o Preview environment?

Recordemos que los ambientes “ephemeral” tienen un ciclo de vida corto, fueron creados para una finalidad en particular (en nuestro caso validar el código al momento de la creación de una Pull Request), deben ser lo más parecido al ambiente de producción y estar disponibles cuando el programador los necesite. Muy importante luego de ser utilizados deben ser destruidos con herramientas automatizadas.

Te dejo un post de mi blog con todos los detalles para que puedas profundizar más...https://blog.hectorfernandez.dev/ephemeral-environments-como-crearlos

¿Qué debes de tener?

Repositorio de código (GIT)
Cuenta de AWS
IaC para el despliegue de tus recursos
AWS CLI configurado en tu maquina

Los siguientes pasos están dentro de la capa gratuita de AWS, pero según tu caso de uso puedes incurrir en costos.

1) Identificar nuestra infraestructura (en el código)

El primer paso que debemos de debemos hacer es identificar nuestra infraestructura, por ejemplo ¿usamos contenedores?, usamos servicios de almacenamiento persistentes (S3)? ¿Cómo estos servicios están referenciados en nuestro código?.

¿Pero saber en qué parte del código se hace referencia a servicios externos en qué me ayuda?

por ahora te diría muchísimo.

Al conocer cómo interactúa nuestra aplicación nos permite identificar cuáles parámetros pueden ser pasados por ejemplo mediante variables de entorno. Cuando creamos ambientes de “preview” cómo también se le suele llamar, debemos saber que los nombres de cada entidad son autogenerados, por lo tanto no podremos decidir el nombre o dejar ese nombre de forma estática en el código.

Te muestro un ejemplo, para entender mejor el punto anterior.

 const msg =
    process.env.BUCKET_NAME === "prod"
      ? "Production Mode "
      : "Preview Enviroment";

  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: `Hello from Lambda ${msg} using CDK`,
    }),
  };

Este código es parte de la función serverless de lambda, dónde dependiendo de la variable de entorno pasada se comporta de una u otra manera (esto puede ser tan complejo cómo tu solución lo necesite) es meramente para ilustrar la importancia de identificar la parte que el código hace uso de la infraestructura creada.

2) High-level architecture

En este template podremos ver la idea general de la implementación y cómo quedaría nuestra cuenta luego de tener más de 1 ambiente temporal desplegado.

Como podemos observar nuestra arquitectura es bastante simple para enseñarles la integración que puede tener. La idea es que un ambiente productivo real siga la misma idea pero escalado a la cantidad de recursos que ya tienes.

3) Stack de AWS CDK

4) Github Actions que se encargará de hacer todo esto posible

5) Puntos importantes

Sintetizar nuestra plantilla de cloudformation: 40% más rapido la creación de stacks cloudfromation (Si usas otra herramienta de IaC, sigue los pasos que te indica esa otra herramienta)
Hacer el deploy del stack: Un punto aca super importante es que le pasamos como parámetro el ID del pull request que estamos creando, de esta forma se crea un ID único.
Validar los cambios que hicimos

Ya con esto tendríamos nuestro ambiente desplegado en una cuenta compartida entre todos los desarrolladores pero a su vez cada quien con su stack propio, permitiendo que las pruebas se puedan hacer de forma aislada.

6)Revisando nuestros recursos en AWS

Si vamos a cloudformation desde la consola tendremos algo similar a esto. Tendremos nuestras URL listas para utilizar ¡Lo logramos!
ya con esto vamos a poder hacer nuestras pruebas e2e o cualquier prueba de humo sin mayor esfuerzo.

Tips para mejorar esta solución:

Tener una colección de Postman que pueda correr mediante CI / CD cada vez que se cree una Pull Request, de tal manera de asegurar la integridad de la aplicación.
Implementar comentarios automáticos en Github, de esta forma la URL del ambiente creado queda disponible para todos los reviewers.
Solo hacer despliegue de los componente que sean necesarios según el código que se tocó
Definir un tiempo de vida para el stack, ya que si alguien deja esa PR por mucho tiempo pueda tener un ciclo de vida.

¿Habias utilizado algo similar antes? Me gustaría saber tu opinión de estipo de ambientes en un ciclo de desarrollo continuo.

Connect with me

LinkedIn : https://www.linkedin.com/in/hectorfernandezdev/
GitHub : https://github.com/hectorfernandezdev
Podcast: https://podcast.hectorfernandez.dev/

Let's keep building

Cloud, tu caja de herramientas personal

Hector Fernandez CloudparaTodo — Wed, 21 Jun 2023 01:42:46 +0000

Imagina que eres un albañil y el mundo cloud es como una gran caja de herramientas, todas listas para usar. Un programador es como ese albañil, pero en lugar de construir casas o edificios, construye programas y aplicaciones.

Enfrentándose a desafíos del mundo cloud te dará como programador un montón de herramientas nuevas y geniales para jugar. Estas herramientas ayudan a los programadores a hacer cosas más rápido, mejor y más fácil que antes.

Por ejemplo, en lugar de tener que construir una casa pieza por pieza, ahora pueden usar una máquina que construye muros completos en poco tiempo, o en lugar de hacer una puerta que crees será impenetrable, contratas a un tercero que tiene un sistema monitoreo centralizado, con lo último en vanguardia en detección de amenazas.

Ahora, creo que entiendes por donde viene la mano no? Fíjate que hablando de todas estas características, no he tocado el tema del costo, no es que sea menos importante. Simplemente, que para entrar de lleno debemos primero reconocer las herramientas, antes de siquiera utilizarlas.

Entonces, ¿cómo puede un programador aprovechar estas herramientas?

Digamos que un programador quiere hacer una aplicación para tomar fotos y compartirlas con amigos. En lugar de comenzar desde cero, pueden buscar en la caja de herramientas "Cloud" y encontrar cosas que te faciliten la vida.

Por dar un ejemplo, puedes encontrar una herramienta que te ayude a guardar todas esas fotos sin tener que preocuparse por quedarse sin espacio, o sobre dimensionar el espacio que necesitarás para recién arrancar, especular no es la idea estando en el mundo cloud.

Otro caso de ejemplo, podrías encontrar otra herramienta para enviarle esa misma foto a tus amigos de forma fácil y segura, sin necesidad de moverla. Esa es la gran diferencia de trabajar en la nube, siguiendo con la analogía de la construcción puedes crear una estructura base y luego crear nuevos pisos, y hasta una piscina si te pones creativo.

Conclusión

Ya sabes, el mundo cloud les da a los programadores muchas maneras geniales de hacer su trabajo más fácil y divertido, no tengas miedo, comienza a probar y a profesionalizarte.

Es como si tuvieras una caja de herramientas mágicas llena de cosas sorprendentes, que si lo hicieras por tu cuenta, pasarías un montón de tiempo solamente desarrollando un martillo, sin llegar a dar una solución real a tu problema.

¿Te gustaría que estemos en 📩 contacto?
Hector Fernandez, AWS Builder

Héctor Fernández
AWS Community Builder (Uruguay)
https://hector.builders/

Serverless, no es todo en la vida.

Hector Fernandez CloudparaTodo — Fri, 19 May 2023 10:05:00 +0000

Serverless:

¿Qué es y cómo funciona?

En este episodio vamos hablar como funciona, los casos de éxitos más conocidos y algún dato actual. Cómo lo es el caso de Amazon Prime Video pasó de tener una arquitectura 100% serverless a una arquitectura monolítica, o bueno algo parecido a ello.

Creado originalmente en formato Podcast, puedes escucharlo acá:
Podcast: Cloud para Todos

Ventajas y desventajas de usar serverless:

Nos adentraremos a definir arquitectura y cómo tomar decisiones informadas a la hora de elegir esta arquitectura.

Ejemplos de aplicaciones serverless exitosas

En este episodio podrías compartir algunos casos de éxito en el uso de arquitectura serverless, y cómo estas aplicaciones han mejorado la eficiencia y escalabilidad de sus sistemas.

Recientemente Amazon Prime Video levantó muchos comentarios, entre adictos a la tecnología serverless y otros que no lo están tanto. Ya que informó los cambios que hicieron para hacer más eficiente su arquitectura de análisis. Pasaron de tener una arquitectura totalmente distribuida en serverless, usando step functions y otros artilugios totalmente nativos de la nube para pasar a usar una arquitectura un poco más simple, un monolito.

Parece un poco extraño, pero si observamos los detalles de la publicación y las posteriores comunicaciones, todo fue en pro de aprovechar mejor los recursos. Recordemos que en la nube, todo lo que se usa tiene costo y requiere algún tipo de configuración.

Cómo empezar a trabajar con serverless: herramientas y recursos útiles:

Antes que nada, si estás aprendiendo algún lenguaje de programación y quieres hacer un 2x1 en tecnología, STOP. Primero aprende como funciona el lenguaje, su diseño básico, patrones y luego entrega con una arquitectura, en este caso Serverles.

Mejores prácticas para desarrollar aplicaciones serverless:

En este episodio podrías compartir consejos prácticos para desarrollar aplicaciones serverless eficientes, escalables y seguras.

Arquitectura de aplicaciones serverless:

Cómo diseñar una aplicación escalable y segura - En este episodio podrías profundizar en la arquitectura de las aplicaciones serverless, cómo diseñarlas de manera escalable y segura, así como compartir buenas prácticas para su gestión.

Integración de servicios en aplicaciones serverless:

Bases de datos, sistemas de autenticación, notificaciones, entre otros - En este episodio podrías compartir consejos para integrar servicios externos en aplicaciones serverless, como bases de datos, sistemas de autenticación, notificaciones, entre otros.

Consejos para la gestión y monitorización de aplicaciones serverless:

En este episodio podrías compartir consejos para la gestión y monitorización de aplicaciones serverless, cómo mantenerlas actualizadas y asegurar su rendimiento.

Cloud para Todos Podcast
¡No te pierdas nuestro podcast! Descubre historias fascinantes contadas por expertos en cada tema.
¡Suscríbete ahora y no te pierdas ningún episodio!

🎧🔥 #Podcast #HistoriasFascinantes #NoTeLoPierdas

Utilizar el menor privilegio en AWS IAM + Webs para validar tus políticas

Hector Fernandez CloudparaTodo — Wed, 17 May 2023 21:39:22 +0000

TL;DR

Aplicando el menor privilegio en AWS IAM es fundamental para mantener la 🔑 seguridad de tu entorno de trabajo.

¿Qué es el principio de menor privilegio?

Dentro de AWS IAM (Identity and Access Management) se refiere a la práctica de otorgar a los usuarios y recursos solo los privilegios y permisos necesarios para realizar sus tareas específicas.

Es decir, dando permisos de lectura solamente a los usuarios/apps que lo necesiten, si otro usuario/app necesita un permiso de escritura debemos explícitamente indicarlo.

En resumen ejecutando el principio de menor privilegio podrás:
✅ Reducir errores
✅ Cumplir con los requerimientos
✅ Tener un mayor control
✅ Facilitar la administración
✅ Escalar fácilmente

¿No sabes como crear una condición basada en ARN?

Te dejo unas URL para que puedas ver como crear una condición basada en ARNs.
https://www.awsiamactions.io/

¿Qué ganamos al aplicar el menor principio de menor privilegio?

🔻 Seguridad:

Reduces drásticamente las posibles violaciones a tu sistema, mitigando cualquier impacto posterior que pueda ocurrir. No debemos de confiar en la “buena fe” siempre debemos actuar con cautela ante usuarios malintencionados.

🔻 Normativas:

Muchos estándares (cómo el PCI) requieren que otorgues la menor cantidad de privilegios en tus cargas de trabajo, por eso al hacerlo desde un principio ya estarás cumpliendo con ello.

🔻 Menos errores:

Bajas mucho la posibilidad que alguien haga algo que no tenía los permisos, como el caso de que escriban en una base de datos por ejemplo, así podríamos tener muchos casos.

🔻 Control:

Cuando damos los privilegios de forma segmentada, podemos saber en todo momento que/quien tiene acceso a qué, por lo que nos aseguramos de tener todo controlado.

🔻 Escalar:

En la nube todo es escalable, recordemos que puede ser hacía más o menos, por lo que podemos dar permisos o quitarlos de forma muy fácil.

Recuerda:

Cuando asignamos sólo los permisos necesarios para realizar tareas específicas, minimizas los riesgos y mantenemos un entorno seguro y protegido.

¿Qué herramienta utilizas en tu día a día?

¿Te gustaría que estemos en 📩 contacto?
Hector Fernandez, AWS Builder

Héctor Fernández
AWS Community Builder (Uruguay)
https://hector.builders/

Paso a paso: Cómo mejorar la seguridad de tu aplicación frontend usando AWS Secret Manager, ejemplo con VueJs

Hector Fernandez CloudparaTodo — Mon, 03 Apr 2023 12:30:00 +0000

Hoy vamos a tratar un tema que muchas veces pasamos por alto, la seguridad en aplicaciones frontend (aplicable también para backend), creemos porque son API KEY podemos simplemente dejarla de forma estática en el código, pero cuando se ven comprometidas no sabemos cómo remediar esta situación, hoy te traigo una idea de como lidiar con este problema.

Agenda del post:

La responsabilidad en términos de seguridad para aplicaciones Frontend
Localstorage, SessionStorage, inputs hiddens
Archivos .ENV ¿Que debemos guardar?
Por qué no debemos tener API KEYS de terceros en nuestro código
AWS Secrets manager como vault de datos
AWS Cognito para acceso temporal a nuestros recursos de AWS
Código final usando AWS SDK v3 en VueJs

La responsabilidad en términos de seguridad para aplicaciones Frontend:

Contexto:
El desarrollo de aplicaciones frontend requiere de un certificado de seguridad SSL para evitar problemas con los navegadores web y mejorar el posicionamiento en los motores de búsqueda. Además, es necesario asegurar la información sensible como las credenciales de servicios de terceros (API KEY nominadas) no queden insertadas en el código. Por último y no menos importante, este certificado (SSL) nos va permitir encriptar las conexiones que hagamos con nuestra aplicación backend (propia o de terceros).

Durante el proceso de desarrollo de aplicaciones, de seguro has tenido acceso a credenciales de servicios de terceros (API KEY) que solamente deben ser utilizadas para ambientes de pruebas (localhost)

¿Como realmente aseguramos eso?
Hoy en este artículo vamos a estar hablando de un proceso de gestión seguro y actualizado para las variables de entorno en el equipo de desarrollo utilizando AWS Secret Manager.

Ya sea que recibas a un nuevo miembro al equipo o alguien salga del mismo, mantener esas credenciales de forma segura y actualizadas siempre fue un dolor de cabeza para cada encargado de seguridad en los equipos de desarrollo.

Cómo líder por muchos años de equipos he probado muchas herramientas de gestión y casi todas recaen en la "buena fé" del desarrollador/a, por eso hoy te mostraré un proceso que he venido haciendo estos últimos tiempos.

Comencemos hablando de situaciones que de seguro se te hacen familiares.

Guardar información sensible en LocalStorage

Te hago un spoiler: lo primero que verá cualquier analista de seguridad a tu aplicación frontend es buscar datos sensibles que el usuario final pueda tener acceso, con solo hacer F12 (consola de desarrollador) puedes entrar y ver el LocalStorage.

Así que la próxima vez que quieras guardar un número de identificación legal (C.I. / D.N.I / S.S.N), una contraseña o algo similar piensalo dos veces, hay cosas debajo del sofá que son más difíciles de encontrar que acá.

Archivos .ENV con información sensible

Partimos de un punto: Dentro de tu repositorio de GIT no estás haciendo "commit" de datos sensibles en los archivos .ENV

¿Porque así lo estás haciendo no?

Recuerda que las aplicaciones fronted se empaquetan y se entregan al navegador de forma completa (no entraremos acá en detalle del "lazy load" o patrones similares), por lo tanto con simplemente examinar el código tendremos a todo lo que contiene la aplicación, este punto es clave para cuando quieras hacer algo cómo en tu .ENV:
GOOLE_API_KEY=J64j564Mknss

Por qué no debemos tener API KEYS de terceros en nuestro código

¡No lo hagas!, ya que al hacerlo estarás exponiendo esas credenciales a cualquier usuario de tu web. Sí, sí ya me dirás “Pero yo entro en la app de Google y le indico el dominio que quiero como whitelist”, y te diré es correcto PERO NO SUFICIENTE, en términos de seguridad cada puerta que dejemos abierta es una oportunidad para que nuestros atacantes (intencionados o no) utilicen esa información para otros fines diferentes a los originales.

De seguro ya te estarás preguntando: ¿Si no tengo esa API KEY como hago para que mi aplicación funcione correctamente?, la respuesta corta es: necesitas llamar a un tercero para solicitar esa información y recién ahí poder hacer el “request” que necesites.

Antes de que pienses en la ineficiencia de este patrón de seguridad, déjame que te explique las ventajas antes.

Imaginemos que por algún motivo esa API KEY se encuentra comprometida y quieres sustituirla por una nueva para remediar la situación, deberías hacer algo parecido a estos pasos:

Si es una APP "Mobile", tendrás que crear una nueva versión, subirla al store correspondiente, luego liberar esa nueva versión y esperar a que todos tus usuarios se descarguen esta versión. Es un proceso lento y no escalable.
Por otro lado si es "Web", te tocará hacer algo similar; liberar una nueva versión, invalidar el caché (cosa que muchos no hacen en sus procesos de CI/CD) de aplicaciones web y esperar a que tus usuarios te visiten nuevamente y el navegador les entregue la última versión desplegada.

Ambos escenarios como puedes observar podemos estar hablando de horas o días (en el caso de “APP Mobile”) que el atacante podrá seguir utilizando nuestras credenciales para otros usos. Durante ese tiempo estaremos comprometiendo a nuestros usuarios también.

Acá es donde entra en juego un servicio de tercero para almacenar esta información , sin importar si tu aplicación en frontend o backend el funcionamiento es el mismo (una AWS Lambda por ejemplo).

Un tercero almacena los datos sensibles y cada vez que los necesitemos los consultamos y los usamos. Así cuando nuestros datos lleguen a estar comprometidos o como medida de nuestras políticas de seguridad continua cambiaremos en un solo lugar y en cuestión de segundos ya nuestros usuarios estarán remediados.

AWS Secrets manager como vault de datos

Concepto copiado textualmente de AWS:

AWS Secrets Manager es un servicio de administración de datos confidenciales que ayuda a proteger el acceso a sus aplicaciones, servicios y recursos de TI. El servicio le permite alternar, administrar y recuperar fácilmente credenciales de bases de datos, claves de API y otros datos confidenciales durante todo su ciclo de vida. Con Secrets Manager, puede proteger y administrar los datos confidenciales utilizados para acceder a los recursos en la nube de AWS, en servicios de terceros y localmente.

Acá podemos ver que no tenemos la necesidad de crear una solución propia para paliar con este problema de seguridad, utilizando un servicio como AWS Secrets Manager te quitas ese dolor de cabeza y lo mejor de todo que es compatible con motores de base de datos o API de terceros.

Resumamos a muy alto nivel el servicio como:

Guardas un “Secret” como le suelen llamar, en tu cuenta de AWS
Ese “Secret” es cifrado en reposo (nadie más que tú tendrá acceso al dato plano), por lo tanto no hay forma de que quede expuesto.
Mediante API o SDK de AWS vas a poder consumirlo fácilmente
100% integrable con otros servicios como IAM y AWS Cognito (más adelante veremos el caso práctico).
Podrás entrar en tu consola de AWS y cambiar el valor las veces que quieras sin necesidad de informar a quien lo esté consumiendo.

Este servicio te permite como desarrollador frontend hacer despliegue de tus aplicaciones sin necesidad de exponer datos sensibles durante el proceso de CI/CD ni durante el empaquetado final.

¿Cuántas veces no le preguntaste a tu colega por una API KEY de tercero y mandarla mediante chats? Sin hablar de cuando cambiaban y nadie te avisaba al respecto y solo recibías un “401 Unauthorized” sin entender el motivo aparente.

Amazon Cognito: para acceso temporal a nuestros recursos dentro de AWS

Esta solución parece perfecta para una aplicación backend, ya que podemos limitar la conexión de forma centralizada hacia el secret manager, pero acá estamos hablando de aplicaciones frontend, por eso entra en juego el servicio de “AWS Cognito”.

Texto copiado de AWS:

Amazon Cognito es un servicio de administración de acceso e identidad del cliente (IAM) rentable y centrado en el desarrollador. Proporciona un almacén de identidad seguro y opciones de federación que pueden escalar a millones de usuarios.

Mediante AWS Cognito, vamos a poder otorgar credenciales temporales a nuestros usuarios anónimos para que puedan consumir los secretos almacenados en AWS Secret Manager sin necesidad de exponer datos sensibles.

Las identidades de Amazon Cognito NO son credenciales. Se intercambian por credenciales utilizando la compatibilidad con las identidades web federadas de AWS Security Token Service (AWS STS).

En los siguientes pasos vamos a poder ver cómo lograr intercambiar identidades de AWS Cognito por las credenciales temporales (con acceso limitado) que podremos utilizar con AWS Secret Manager para finalmente consumir nuestra aplicación de terceros.

Parece super largo el proceso, pero son simplemente unas líneas de código.

Código de ejemplo (Vue Js)

Primero debemos usar Identidades de AWS Cognito para acceder a nuestros recursos de AWS

Lo primero que vamos hacer es crear una “identity pool” dentro de las entidades federadas de AWS Cognito.

Link:
https://us-east-1.console.aws.amazon.com/cognito/federated?region=us-east-1

Definimos nuestro nombre para la “Identity pool name” y nos aseguramos que esté habilitado la opción de “Enable access to unauthenticated identities”. Creamos el “Pool”

Vamos a necesitar crear un ROL para los usuarios “unauthenticated“, con permisos de acceder a Secret Manager usando la siguiente Policy, para eso en el paso 2 hacer click en ver detalles.
El primer Rol lo dejamos por defecto, nos centraremos en el “unauthenticated Role”.

Editamos la Policy y añadimos lo siguiente dentro de statement:

{
  "Sid": "VisualEditor0",
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "*"
}

Dejamos la consola de AWS por un momento, y vamos a nuestro proyecto javascript. Para fines prácticos lo haremos en VueJs pero lo puedes hacer en cualquier librería (Angular, React, Vanilla JS).

Vamos a nuestro proyecto a instalamos la siguiente librería de AWS SDK V3, la cual nos permite instalar las dependencias de forma bastante granular, haciendo que nuestra aplicación sea lo más liviana posible:

npm i @aws-sdk/credential-providers

Esta librería nos va permitir intercambiar nuestro IdentityPool ID por unas credenciales basadas en accessKeyId y secretAccessKey

npm i @aws-sdk/client-cognito-identity

Es el cliente de Cognito

npm i @aws-sdk/client-secrets-manager

Nos permite acceder a AWS Secret Manager mediante su SDK, teniendo en texto plano del valor guardado en el “secreto”.

TIP:

Siempre que sea posible, utiliza la AWS SDK v3 Javascript, te quitará dolores de cabeza en el futuro, aún cuando los ejemplos que veas en internet tengan la referencia a la SDK v2 (deprecated).

Siempre investigando el método que quieras utilizar lograrás encontrar la documentación oficial.

Volvemos a la consola: en AWS Secret Manager para crear nuestro secreto (“Secret”)

En la parte de tipo seleccionamos otro (“Other”), y escribimos un texto plano

Y completamos los datos como la siguiente imagen

Damos siguiente y dejamos un nombre para nuestro secreto.

Una buena práctica es indicar como prefijo el ambiente seguido del nombre que le queremos dar por ejemplo para local/dev sería:
dev/google_maps_apikey

Ambiente te Testing/QA
test/google_maps_apikey

Ambiente Productivo
prod/google_maps_apikey

De esta forma tendremos granularidad en los permisos y/o personas que tengan acceso.

Importante: dale continuar, continuar hasta que te diga “Guardar Secreto” ya que los otros pasos son opcionales para este ejemplo.

Ya con esto tendremos nuestro secreto almacenado en la nube, encriptado y seguro.

(opcional)
Si queremos ver el valor que tenemos almacenado simplemente

Vamos a la lista de secretos, seleccionamos el secreto .
Dentro hacemos click en retrieve value.

(opcional ver el secreto)

Tomen nota del ARN

(lo utilizaremos más adelante).
arn:aws:secretsmanager:us-east-1:058452286234:secret:dev/google_maps_apikey-mMforO

Última parte, conectar todo ¡Ya casi estamos!

Continuemos con nuestra app frontend, volvemos al editor de código.

En pasos anteriores habíamos instalado una serie de dependencias, nosotros vamos a estar utilizando la función “fromCognitoIdentityPool” la cual nos permite hacer el intercambio del ID por credenciales temporales como dijimos anteriormente.

Importamos todo lo que necesitamos en nuestro componente de la siguiente manera:

import { CognitoIdentityClient } from "@aws-sdk/client-cognito-identity";
import { fromCognitoIdentityPool } from "@aws-sdk/credential-providers";
import {
  SecretsManagerClient,
  GetSecretValueCommand,
} from "@aws-sdk/client-secrets-manager";

(importación usando método ECMAScript 6 si estás aplicando esta config a un sistema legacy puedes buscar en la documentación como importar usando ES5)

Para poder tener en texto plano nuestro secreto debemos crear un cliente y pasarle un comando con el secreto que queremos ver, algo como esto (NO USAR ésta solución en ambientes, meramente educativo. Más adelante tienes la solución)

Problema de seguridad encontrado:

NUNCA debemos colocar accessKeyId ni secretAccessKey
en nuestros códigos, por eso esta solucion no es la más recomendada.

Al principio de todo el capitulo estabamos hablando de Amazon Cognito, y acá es cuando entra en juego, vamos a cambiar nuestro identitypoolId por una credenciales temporales de la siguiente manera:

 const region = "us-east-1"; 
// Cambia esto a la región donde está configurado tu recurso de Secret Manager
      const identityPoolId = "us-east-1:1b5cc45e-490e-439e-8692-a27a54ae029a"; 
// Cambia esto a tu ID de Identity Pool
const tempCredentials = fromCognitoIdentityPool({
        client: new CognitoIdentityClient({ region }),
        identityPoolId,
        clientConfig: { region },
});

Te resumo lo que estamos usando:

CognitoIdentityClient
Para obtener las credenciales temporales desde AWS Identity Pool

fromCognitoIdentityPool
de @aws-sdk/credential-provider-cognito-identity para crear un proveedor de credenciales que utilizará el cliente de Secret Manager.

GetSecretValueCommand
Obtener el valor del secreto.

Código con la solución final

Repositorio GIT de ejemplo

https://github.com/hectorfernandez02/cloudparatodos-aws-secret-manager-vuejs

Conclusiones:

Recomendamos guardar información sensible, como claves de API, contraseñas y números de identificación legal (C.I. / D.N.I / S.S.N), en Secret Manager en lugar de en variables de entorno. Por otro lado, se pueden guardar en variables de entorno otras configuraciones de la aplicación, como la URL de la aplicación, la configuración del servidor, las claves de API públicas (no nominadas), etc.

Buscar un recurso, usando Resource Explorer de AWS

Hector Fernandez CloudparaTodo — Wed, 09 Nov 2022 15:04:40 +0000

⚡Nueva feature para la ya complicada tarea de buscar un recurso dentro de AWS, los Resource Explorer.⚡

Te permite buscar los recursos de todas las regiones en un solo lugar.

✌️Está disponible para la consola de administración de AWS, así como para la CLI de AWS.

🟢Documentación: https://lnkd.in/e2W6hA4U
🟢Debe habilitar el explorador de recursos en https://lnkd.in/ei4csrBn

Luego de que tengas habilitado simplemente en la barra de búsqueda puedes escribir "/resources" y buscar cualquier recurso en tu cuenta (sin importar la region)

Puedes encontrar recursos en su cuenta de AWS en todas las regiones utilizando metadatos como nombres, etiquetas e incluso ID. Cuando encuentra un recurso en la consola de administración de AWS, puede pasar rápidamente de los resultados de búsqueda a la consola de servicio y la región correspondientes para comenzar a trabajar en ese recurso.

Igualmente, puede utilizar la interfaz de línea de comandos (CLI) de AWS o cualquiera de los SDK de AWS para encontrar recursos en sus herramientas de automatización.

¿ya usas el CLI o solamente usás el dashboard?

--
Soy desarrollador. Trabajo con código todo el día. También estoy certificado como Arquitecto de AWS. ¿Cómo conseguí obtener dos certificaciones en tan poco tiempo? No fue fácil, pero definitivamente valió la pena.

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)
https://hector.builders/