DEV Community: Luis Fernando de León Ramírez

AWS Lambda MicroVMs: Cómo crear entornos de código aislados por usuario

Luis Fernando de León Ramírez — Tue, 07 Jul 2026 16:00:00 +0000

AWS Lambda MicroVMs

💡 AWS lanzó Lambda MicroVMs: máquinas virtuales aisladas con Firecracker, arranque en milisegundos y sin infraestructura que administrar.

📝 En este artículo comparto mi experiencia creando un laboratorio de codificación donde cada usuario obtiene su propio VS Code en la nube para resolver ejercicios de Python con pruebas automatizadas — todo corriendo sobre Lambda MicroVMs.

"AWS Lambda MicroVMs: Cómo crear entornos de código aislados por usuario"

AWS Lambda MicroVMs es una tecnología utilizada para virtualización ligera, permitiendo la creación de ambientes de forma segura y aislada con duración de hasta 8 horas y se suspenden sin costo de cómputo cuando están inactivas.

En este artículo exploraremos las experiencias y retos que tuve al crear un laboratorio para evaluar el conocimiento sobre funciones en Python, proporcionando a cada usuario una interfaz de code-server (VS Code web), que le permitiera realizar ajustes en su código y pruebas automatizadas.

1. Beneficios

Ejecución de código aislada utilizando Firecracker: No son contenedores, cuando inicias a conocer el servicio podrías confundirlo con contenedores, pero no es así, son maquinas virtuales con su propio kernel y aislamiento a nivel de hardware.
Serverless: Tendrás disponibles servidores aislados, sin redes o balanceadores para su acceso, solamente definirás el Dokerfile y empiezas a usarlo.
Escalado vertical flexible: Hasta 4x los recursos base configurados.
Arranque en milisegundos: Se restaura de un snapshot pre construido, en segundos tu app ya está corriendo.
No pagas por cómputo mientras se encuentre en estado suspendido: Cuando no existe tráfico la aplicación se suspende preservando disco y memoria.
Autenticación JWE: Permite que cada endpoint este protegido por token con una expiración configurable.
El modelo básico de construcción: Dockerfile > Código > Snapshot > Lanzar N microVMs desde esa imagen base

2. Casos de aplicación

Plataformas de desarrollo aisladas por usuario
Aislamiento de pruebas de seguridad y escaneos de seguridad, impidiendo que el código malicioso pueda afectar otros recursos
Ambientes aislados con configuraciones específicas para análisis de datos

3. ¿Contenedores corriendo dentro de Lambdas?

La respuesta es no, al utilizar un Dockerfile, podríamos confundirnos pensando que es así, sin embargo acá este archivo cumple con un rol distinto. Lambda lo utiliza únicamente para definir el listado de lo que necesita instalar y como iniciar la aplicación durante la fase de construcción, El resultado no será una imagen de docker, que pueda ser utilizada desde un contenedor, sino un snapshot de Firecracker.

4. ¿Qué sucede detrás del modelo de construcción?

El Dockerfile define qué instalar y cómo inicia la aplicación
Lambda provisiona una VM, ejecuta las instrucciones del Dockerfile y arranca tu app con CMD
Se captura un snapshot del estado completo de la VM (disco, memoria y procesos en ejecución)
Al lanzar una MicroVM, Lambda restaura ese snapshot. Tu aplicación reanuda exactamente donde quedó, sin repetir el arranque

5. Estructura de los archivos

Proyecto: Puedes utilizar cualquier lenguaje o framework que pueda ser ejecutado en Linux
Dockerfile: Las instrucciones que necesito para preparar el entorno de ejecución

6. Manos a la obra

Vamos a definir un entorno adecuado para que se puedan hacer ejercicios con un entorno aislado con la finalidad de que el usuario que ingrese pueda realizar un ejercicio de codificación personalizado sin afectar las pruebas de otros.

Nota: Desactivamos la autenticación propia de code-server (auth: none) porque el acceso a la MicroVM ya está protegido por el token JWE a nivel del endpoint. Nadie puede llegar al puerto 8080 sin un token válido.

Dockerfile

FROM codercom/code-server:latest

USER root

# Instalar Node.js (para hook server) y Python con pytest
RUN apt-get update && apt-get install -y \
    nodejs \
    python3 python3-pip \
    && rm -rf /var/lib/apt/lists/* \
    && pip3 install pytest --break-system-packages

# Instalar extensión de Python para code-server
RUN code-server --install-extension ms-python.python

# Config sin auth
RUN mkdir -p /root/.config/code-server && \
    echo "bind-addr: 0.0.0.0:8080" > /root/.config/code-server/config.yaml && \
    echo "auth: none" >> /root/.config/code-server/config.yaml && \
    echo "cert: false" >> /root/.config/code-server/config.yaml

# Copiar ejercicio al workspace
COPY ejercicio/ /home/coder/workspace/
RUN chown -R coder:coder /home/coder/workspace

COPY hook_server.js /hook_server.js
COPY start.sh /start.sh
RUN chmod +x /start.sh

EXPOSE 8080 8081

CMD ["/start.sh"]

Ejercicio en Python

main.py

def suma(a, b):
    """TODO: Retorna la suma de a y b"""
    pass


def es_palindromo(texto):
    """TODO: Retorna True si el texto es un palíndromo"""
    pass


def fibonacci(n):
    """TODO: Retorna los primeros n números de Fibonacci"""
    pass

tests/test_main.py

from main import suma, es_palindromo, fibonacci


def test_suma():
    assert suma(2, 3) == 5
    assert suma(-1, 1) == 0


def test_palindromo():
    assert es_palindromo("ana") == True
    assert es_palindromo("hola") == False


def test_fibonacci():
    assert fibonacci(5) == [0, 1, 1, 2, 3]
    assert fibonacci(1) == [0]

7. ¿Cómo construir un snapshot?

Creo los archivos base
- Proyecto
- Dockerfile
Empaquetar en zip

   zip -r bootcamp-lab.zip Dockerfile start.sh hook_server.js README.md ejercicio/

Subirlo a un bucket de S3

   aws s3 cp bootcamp-lab.zip s3://mi-bucket/bootcamp-lab.zip

Creo el snapshot

Nota: Al crear el snapshot, puedes elegir un rol por defecto que Lambda genera automáticamente. Este rol incluye los permisos necesarios para leer del bucket S3 que especificaste. Para pruebas iniciales, te recomiendo usar esta opción y no complicarte con roles personalizados.

8. Vamos a correr nuestra primera Lambda MicroVM

Le daremos al botón "Run MicroVM"

Creación de token: a través de este podremos acceder a la URL de la MicroVM

Iniciar microVM

Con el endpoint utilizado podremos acceder desde el navegador. Toda petición requiere el header X-aws-proxy-auth con el token que generamos en el paso anterior, el cual deberás agregar al navegador. Para este caso utilicé la extensión de Chrome ModHeader.

Al ingresar al endpoint generado podré ver el ambiente aislado. De esta forma podré crear los ambientes que necesite exactamente con la misma estructura para que los usuarios puedan realizar sus pruebas sin afectar los recursos existentes ni los ambientes de otros usuarios.

9. Probar usando un IDE para base de datos

La estructura utilizada para este caso puede ser adaptada para otros escenarios que puedan llegar a utilizar un IDE, por ejemplo una MicroVM que sea utilizada para ejercicios de base de datos (CloudBeaver, PgAdmin, Workbench, etc). Es la misma estructura, utiliza un Dockerfile para configurar el ambiente , crea el snapshot y lanza la ejecución.

En mi repositorio podrás encontrar el código completo:
https://github.com/lfdeleonramirez/aws-lambda-microvms

Sobre el autor

Luis Fernando de León — AWS Community Builder 🇬🇹

📸 Instagram: instagram.com/luisenlanube
📝 DEV: dev.to/luisferdeleon
👤 Facebook: facebook.com/luisenlanube
💼 LinkedIn: linkedin.com/in/luisfdeleonramirez

Recursos
📖 Documentación oficial — AWS Lambda MicroVMs

AWS Lambda MicroVMs: How to create isolated code environments per user

Luis Fernando de León Ramírez — Mon, 06 Jul 2026 10:37:00 +0000

AWS Lambda MicroVMs is a lightweight virtualization technology that enables the creation of secure, isolated environments with a duration of up to 8 hours, which suspend at no compute cost when idle.

In this article we'll explore the experiences and challenges I faced while building a lab to evaluate Python function knowledge, providing each user with a code-server interface (VS Code web) where they could edit their code and run automated tests.

1. Benefits

Isolated code execution using Firecracker: These are not containers. When you first discover the service you might confuse it with containers, but they are actually virtual machines with their own kernel and hardware-level isolation.
Serverless: You get isolated servers with no networks or load balancers to configure — just define your Dockerfile and start using them.
Flexible vertical scaling: Up to 4x the configured base resources.
Millisecond startup: It restores from a pre-built snapshot; in seconds your app is already running.
No compute charges while suspended: When there is no traffic, the application suspends preserving disk and memory.
JWE Authentication: Each endpoint is protected by a token with configurable expiration.
Basic build model: Dockerfile > Code > Snapshot > Launch N MicroVMs from that base image

2. Use cases

Isolated development platforms per user
Security testing and scanning isolation, preventing malicious code from affecting other resources
Isolated environments with specific configurations for data analysis

3. Containers running inside Lambdas?

The answer is no. When using a Dockerfile, we might assume that's what's happening, but the Dockerfile plays a different role here. Lambda uses it only to define what needs to be installed and how to start the application during the build phase. The result is not a Docker image that runs as a container, but a Firecracker snapshot.

4. What happens behind the build model?

The Dockerfile defines what to install and how the application starts
Lambda provisions a VM, executes the Dockerfile instructions, and starts your app with CMD
A snapshot of the VM's full state is captured (disk, memory, and running processes)
When launching a MicroVM, Lambda restores that snapshot. Your application resumes exactly where it left off, without repeating the startup

5. File structure

Project: You can use any language or framework that can run on Linux
Dockerfile: The instructions needed to prepare the execution environment

6. Hands-on

We're going to define an environment suitable for isolated coding exercises, so that each user can complete a personalized coding challenge without affecting other users' tests.

Note: We disable code-server's built-in authentication (auth: none) because access to the MicroVM is already protected by the JWE token at the endpoint level. Nobody can reach port 8080 without a valid token.

Dockerfile

FROM codercom/code-server:latest

USER root

# Install Node.js (for hook server) and Python with pytest
RUN apt-get update && apt-get install -y \
    nodejs \
    python3 python3-pip \
    && rm -rf /var/lib/apt/lists/* \
    && pip3 install pytest --break-system-packages

# Install Python extension for code-server
RUN code-server --install-extension ms-python.python

# Config without auth
RUN mkdir -p /root/.config/code-server && \
    echo "bind-addr: 0.0.0.0:8080" > /root/.config/code-server/config.yaml && \
    echo "auth: none" >> /root/.config/code-server/config.yaml && \
    echo "cert: false" >> /root/.config/code-server/config.yaml

# Copy exercise to workspace
COPY ejercicio/ /home/coder/workspace/
RUN chown -R coder:coder /home/coder/workspace

COPY hook_server.js /hook_server.js
COPY start.sh /start.sh
RUN chmod +x /start.sh

EXPOSE 8080 8081

CMD ["/start.sh"]

Python Exercise

main.py

def suma(a, b):
    """TODO: Return the sum of a and b"""
    pass


def es_palindromo(texto):
    """TODO: Return True if the text is a palindrome"""
    pass


def fibonacci(n):
    """TODO: Return the first n Fibonacci numbers"""
    pass

tests/test_main.py

from main import suma, es_palindromo, fibonacci


def test_suma():
    assert suma(2, 3) == 5
    assert suma(-1, 1) == 0


def test_palindromo():
    assert es_palindromo("ana") == True
    assert es_palindromo("hola") == False


def test_fibonacci():
    assert fibonacci(5) == [0, 1, 1, 2, 3]
    assert fibonacci(1) == [0]

7. How to build a snapshot?

Create the base files
- Project
- Dockerfile
Package into a zip

   zip -r bootcamp-lab.zip Dockerfile start.sh hook_server.js README.md ejercicio/

Upload to an S3 bucket

   aws s3 cp bootcamp-lab.zip s3://my-bucket/bootcamp-lab.zip

Create the snapshot

Note: When creating the snapshot, you can choose a default role that Lambda generates automatically. This role includes the necessary permissions to read from the S3 bucket you specified. For initial testing, I recommend using this option instead of dealing with custom roles.

8. Let's run our first Lambda MicroVM

Click the "Run MicroVM" button

Token creation: through this we can access the MicroVM URL

Start the MicroVM

With the generated endpoint we can access it from the browser. Every request requires the X-aws-proxy-auth header with the token we generated in the previous step, which you'll need to add to the browser. For this case I used the Chrome extension ModHeader.

Once you navigate to the generated endpoint you'll see the isolated environment. This way I can create as many environments as needed with the exact same structure so that users can run their tests without affecting existing resources or other users' environments.

9. Testing with a database IDE

The structure used for this case can be adapted for other scenarios that use an IDE — for example, a MicroVM used for database exercises (CloudBeaver, pgAdmin, Workbench, etc.). It's the same pattern: use a Dockerfile to configure the environment, create the snapshot, and launch the execution.

You can find the complete code in my repository:
https://github.com/lfdeleonramirez/aws-lambda-microvms

About the author

Luis Fernando de León — AWS Community Builder 🇬🇹

📸 Instagram: instagram.com/luisenlanube
📝 DEV: dev.to/luisferdeleon
👤 Facebook: facebook.com/luisenlanube
💼 LinkedIn: linkedin.com/in/luisfdeleonramirez

Resources
📖 Official documentation — AWS Lambda MicroVMs

¿Y si construir un chatbot con IA fuera tan fácil como armar con LEGO? — AWS Blocks"

Luis Fernando de León Ramírez — Sat, 04 Jul 2026 05:02:56 +0000

1. ¿Qué es Blocks?

Es un marco de trabajo de código abierto lanzado recientemente que facilita la implementación de proyectos en AWS; tú solamente te encargarás de desarrollar tu proyecto como lo haces normalmente en TypeScript. El marco de trabajo se encargará de convertir tu código en servicios de AWS.

2. Beneficios

Desarrollo sin necesidad de una cuenta de AWS.
Puedes probar tu código en local y tendrás la certeza de que el funcionamiento será igual en producción.
Orientado a costo bajo utilizando la tecnología serverless.
Experiencia de desarrollo con IA al incluir guías que permiten hacer uso de herramientas de IA para codificación, como Kiro, ya que el framework orienta al agente sobre cómo mejorar tus arquitecturas.
Tendrás un ambiente de desarrollo aislado y totalmente funcional.

3. ¿Qué es un Block?

Un Block es una pieza de funcionalidad que encapsula lógica + infraestructura AWS en una sola abstracción que usas con una a tres líneas de código.

Analogía:
Piensa en un Block como un módulo de LEGO: cada pieza tiene una forma y función específica, y las combinas para construir lo que quieras. No te preocupas de cómo está hecha internamente.

4. ¿Qué Blocks puedo utilizar?

Datos y almacenamiento
Autenticación
Cómputo y trabajos en segundo plano
Inteligencia artificial
Comunicación
Configuración
Observabilidad
Alojamiento y despliegue

5. ¿Cómo inicio con mi proyecto?

Con un comando de npm podemos crear la estructura principal del proyecto. Para entender cómo funciona todo desde cero, creé un repositorio que cuenta con una plantilla en blanco la cual puedes utilizar para crear tu proyecto. Ejecuta lo siguiente:

npx @luisfdeleonramirez/create-aws-blocks-base chatbot-ia
cd chatbot-ia
npm install
npm run dev

Al ejecutar estos comandos tendremos un servicio local corriendo en http://localhost:3000 donde podrás realizar tus pruebas.

6. ¿Qué vamos a construir?

Desarrollé una app que funciona como un agente que usa Amazon Nova Lite (amazon.nova-lite-v1:0) y responde consultas de los usuarios. Luego de varias pruebas, considero que un flujo adecuado para organizar el desarrollo es el siguiente:

"Primero defino qué hace mi app (index.ts)"
"Luego defino dónde corre (index.cdk.ts)"
"Finalmente defino cómo se ve para el usuario (app.tsx)"

7. ¿Qué Blocks utilicé?

Originalmente pensé que utilizaría los bloques únicamente del lado del backend, pero en la interfaz web terminé utilizando funciones propias de Blocks para el manejo de conversaciones.

Scope

Para la agrupación de recursos.

const scope = new Scope('chatbot');

AuthBasic

Para la configuración de autenticación utilizando correo y contraseña.

const auth = new AuthBasic(scope, 'auth');

Agent

Bloque para el agente de IA con Bedrock, que incluye configuración, streaming y tools. Algo sumamente interesante es que solamente en un par de líneas puedes configurar el comportamiento de tu agente para su interacción.

const agent = new Agent(scope, 'chat', {
  model: { deployed: { provider: 'bedrock', modelId: 'amazon.nova-lite-v1:0' } },
  systemPrompt: `Eres un agente amigable que se encargará de solucionar dudas a los usuarios sobre tecnología.
Debes responderles en el mismo idioma que te hagan las preguntas.
Cuando el usuario pregunte sobre la empresa, productos, precios o información específica, 
usa la herramienta searchKnowledge para buscar en la base de conocimiento antes de responder.
Si no encuentras información relevante en la base de conocimiento, responde con tu conocimiento general.`,
  tools: (tool) => ({
    searchKnowledge: tool({
      description: 'Busca información relevante en la base de conocimiento de la empresa. Usa esta herramienta cuando el usuario pregunte sobre productos, precios, servicios o información específica de la empresa.',
      parameters: z.object({
        query: z.string().describe('Consulta de búsqueda en lenguaje natural'),
      }),
      handler: async ({ input }) => {
        const results = await kb.retrieve(input.query, { maxResults: 3 });
        if (results.length === 0) {
          return 'No se encontró información relevante en la base de conocimiento.';
        }
        return results.map(r => r.text).join('\n\n---\n\n');
      },
    }),
  }),
});

KnowledgeBase

Base de conocimiento RAG con documentos propios que el agente usará para responder.

const kb = new KnowledgeBase(scope, 'docs', {
  source: './knowledge',
  description: "'Documentación y base de conocimiento del chatbot',"
});

ApiNamespace

Para la comunicación de la API mediante JSON-RPC.

export const api = new ApiNamespace(scope, 'api', (context) => ({}));

8. Desarrollo

Luego de ajustar el código para que fuera funcional, quise probar si funcionaba totalmente en local y la respuesta es que sí: tenía un funcionamiento básico que podía simular usando datos mock en el código. Sin embargo, la funcionalidad del agente sí requiere que al menos hagamos la prueba en el sandbox. Teniendo algo listo, pasé al sandbox.

9. Configuración de IAM

Para poder realizar esto bajo el principio del privilegio mínimo, hice pruebas con los permisos mínimos que debería tener el usuario que ejecutará los deploys. Te dejo a continuación la política:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSBlocksCloudFormationAndIAM",
      "Effect": "Allow",
      "Action": [
        "cloudformation:*",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies",
        "iam:PassRole",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:TagRole"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AWSBlocksAllPossibleFrameworkServices",
      "Effect": "Allow",
      "Action": [
        "lambda:*",
        "dynamodb:*",
        "apigateway:*",
        "s3:*",
        "bedrock:*",
        "events:*",
        "sqs:*",
        "ecr:*",
        "ssm:*",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

10. Bootstrap

Inicié con la prueba de sandbox, sin embargo, para esto necesitaba tener el bootstrap listo. El bootstrap es una preparación base para que las aplicaciones de Blocks puedan funcionar correctamente. Esta preparación se realiza una sola vez por cuenta y región. La realizas de esta forma:

npx cdk bootstrap aws://{id_de_tu_cuenta}/{region}

El resultado de esta ejecución es la creación de un CloudFormation y la pregunta más grande: ¿esto genera costos? La respuesta es no, únicamente crea un bucket de S3 vacío, los roles en IAM y un parámetro en SSM. El costo se genera cuando el CDK sube los assets del código estático durante los deploys. Toma en cuenta que para el sandbox el CDK no copia estos archivos, ya que la interfaz sigue corriendo en tu ambiente.

11. Sandbox

Durante la creación del sandbox, encontré diversos retos. Al ser una nueva tecnología, es posible encontrar detalles que puedan generar un funcionamiento inesperado. Puedes iniciar el sandbox ejecutando:

npm run sandbox

Opté por probar el sandbox en la región de us-west-2. La experiencia fue buena y fortalecí mis conocimientos sobre el framework. Te dejo algunos consejos:

1. Crea tags en tu proyecto

Para tener control sobre tus recursos, así como el monitoreo de tus costos.

index.cdk.ts:

import * as cdk from 'aws-cdk-lib';

cdk.Tags.of(blocksStack).add('Project', 'blocks-chatbot-ia');
cdk.Tags.of(blocksStack).add('Environment', sandboxMode ? 'sandbox' : 'production');
cdk.Tags.of(blocksStack).add('Team', 'dev');
cdk.Tags.of(blocksStack).add('CostCenter', 'chatbot-ia');

2. Nombres de stack cortos

En ocasiones los recursos no podrán crearse si el nombre de tu proyecto es muy largo, por lo cual puedes cambiar el nombre base de tu stack, ya que los recursos se crean con este prefijo. Para este caso hice cambios para que el stack fuera el nombre del proyecto definido en el package:

index.cdk.ts:

const stackName = sandboxMode ? pkg.name + `-sandbox` : pkg.name + 'prod';

export const blocksStack = await BlocksStack.create(app, stackName, {
  backendHandlerPath: join(__dirname, 'index.handler.ts'),
  backendCDKPath: join(__dirname, 'index.ts')
});

3. Cuotas de Bedrock en Organizations

Si tu cuenta forma parte de una organización, recuerda que debes establecer las cuotas en los modelos de Bedrock, de lo contrario no podrás verificar la respuesta de los modelos.

4. Bug de región en @strands-agents/sdk

El bloque @aws-blocks/bb-agent usa internamente el módulo @strands-agents/sdk en su última versión disponible hasta la fecha de la prueba (1.7.0), para guardar las conversaciones del agente en S3. Sin embargo, este módulo por defecto apunta a la región us-east-1, por lo que al intentar hacer uso del agente en otra región podrías tener problemas. Para eso únicamente debes hacer el siguiente cambio:

node_modules/@strands-agents/sdk/dist/src/session/s3-storage.js:

this._s3 = config.s3Client ?? new S3Client({ region: config.region ?? process.env.AWS_REGION ?? 'us-east-1' });

Con este cambio, por defecto ahora revisará la variable de ambiente de la región para que puedas ver el histórico de tus conversaciones. Esta solución es para esa versión. Hice el reporte #120 al equipo de mantenimiento del framework de AWS Blocks y fue resuelto, así que ya es poco probable que encuentres ese error. Te dejo detalles de la corrección que aplicaron:

https://github.com/aws-devtools-labs/aws-blocks/issues/120

Al finalizar las pruebas del sandbox, pude ver un CloudFormation con los diversos recursos creados. En este caso es posible darles un mejor seguimiento gracias a los tags, que identifican a qué proyecto pertenece cada recurso.

12. Despliegue

Al haber realizado las pruebas en el sandbox, solamente queda hacer el deploy para que la aplicación sea accesible para todo el mundo. Es una experiencia satisfactoria, ya que este framework permite llevar a producción aplicaciones estables y seguras utilizando arquitecturas serverless. Para este paso, la diferencia con el sandbox es que se genera el hosting estático almacenado en S3 y distribuido por CloudFront. El tiempo de despliegue fue de 12 minutos.

A continuación podemos ver el funcionamiento del chatbot en ambiente productivo.

13. Limpieza de recursos

Posterior a las pruebas y para no incurrir en gastos, destruí la infraestructura creada. Esto es tan sencillo como ejecutar los siguientes comandos:

Borrar Sandbox:

npm run sandbox:destroy

Borrar despliegue:

npm run destroy

Borrar el CDK (tomar en cuenta que no genera gasto mientras no se transfieran assets):

aws s3 rm s3://cdk-hnb659fds-assets-xxxxx-{region} --recursive --region {region}
aws cloudformation delete-stack --stack-name CDKToolkit --region {region}

Sobre el autor

Luis Fernando de León — AWS Community Builder 🇬🇹

📸 Instagram: instagram.com/luisenlanube
📝 DEV: dev.to/luisferdeleon
👤 Facebook: facebook.com/luisenlanube
💼 LinkedIn: linkedin.com/in/luisfdeleonramirez

What if building an AI chatbot was as easy as snapping LEGO bricks together? — AWS Blocks

Luis Fernando de León Ramírez — Fri, 03 Jul 2026 02:38:38 +0000

1. What is Blocks?

It is a recently launched open-source framework that simplifies deploying projects to AWS; you only need to develop your project as you normally do in TypeScript. The framework takes care of converting your code into AWS services.

2. Benefits

Development without needing an AWS account.
You can test your code locally with the certainty that it will work the same in production.
Low-cost oriented using serverless technology.
AI-powered development experience by including guides that enable the use of AI coding tools, such as Kiro, since the framework guides the agent on how to improve your architectures.
You will have an isolated and fully functional development environment.

3. What is a Block?

A Block is a piece of functionality that encapsulates logic + AWS infrastructure in a single abstraction that you use with one to three lines of code.

Analogy:
Think of a Block as a LEGO module: each piece has a specific shape and function, and you combine them to build whatever you want. You don't worry about how it's made internally.

4. What Blocks can I use?

Data and storage
Authentication
Compute and background jobs
Artificial intelligence
Communication
Configuration
Observability
Hosting and deployment

5. How do I start my project?

With a single npm command we can create the main project structure. To understand how everything works from scratch, I created a repository with a blank template that you can use to create your project. Run the following:

npx @luisfdeleonramirez/create-aws-blocks-base chatbot-ia
cd chatbot-ia
npm install
npm run dev

After running these commands, we will have a local service running at http://localhost:3000 where you can run your tests.

6. What are we going to build?

I developed an app that works as an agent using Amazon Nova Lite (amazon.nova-lite-v1:0) and responds to user queries. After several tests, I consider that an adequate flow to organize development is the following:

"First I define what my app does (index.ts)"
"Then I define where it runs (index.cdk.ts)"
"Finally I define how it looks for the user (app.tsx)"

7. What Blocks did I use?

Originally I thought I would only use blocks on the backend side, but on the web interface I ended up using Blocks' own functions for conversation management.

Scope

For resource grouping.

const scope = new Scope('chatbot');

AuthBasic

For authentication configuration using email and password.

const auth = new AuthBasic(scope, 'auth');

Agent

Block for the AI agent with Bedrock, which includes configuration, streaming, and tools. Something really interesting is that in just a couple of lines you can configure your agent's behavior for its interactions.

const agent = new Agent(scope, 'chat', {
  model: { deployed: { provider: 'bedrock', modelId: 'amazon.nova-lite-v1:0' } },
  systemPrompt: `You are a friendly agent that will help users solve their questions about technology.
You must respond in the same language the user asks the question.
When the user asks about the company, products, prices or specific information,
use the searchKnowledge tool to search the knowledge base before responding.
If you don't find relevant information in the knowledge base, respond with your general knowledge.`,
  tools: (tool) => ({
    searchKnowledge: tool({
      description: 'Searches for relevant information in the company knowledge base. Use this tool when the user asks about products, prices, services or specific company information.',
      parameters: z.object({
        query: z.string().describe('Search query in natural language'),
      }),
      handler: async ({ input }) => {
        const results = await kb.retrieve(input.query, { maxResults: 3 });
        if (results.length === 0) {
          return 'No relevant information found in the knowledge base.';
        }
        return results.map(r => r.text).join('\n\n---\n\n');
      },
    }),
  }),
});

KnowledgeBase

RAG knowledge base with custom documents that the agent will use to respond.

const kb = new KnowledgeBase(scope, 'docs', {
  source: './knowledge',
  description: "'Documentation and chatbot knowledge base',"
});

ApiNamespace

For API communication via JSON-RPC.

export const api = new ApiNamespace(scope, 'api', (context) => ({}));

8. Development

After adjusting the code to make it functional, I wanted to test if it worked entirely locally and the answer is yes: it had basic functionality that I could simulate using mock data in the code. However, the agent functionality does require that we at least run the test in the sandbox. Having something ready, I moved on to the sandbox.

9. IAM Configuration

To accomplish this under the principle of least privilege, I tested with the minimum permissions that the user running the deploys should have. Here is the policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSBlocksCloudFormationAndIAM",
      "Effect": "Allow",
      "Action": [
        "cloudformation:*",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies",
        "iam:PassRole",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:TagRole"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AWSBlocksAllPossibleFrameworkServices",
      "Effect": "Allow",
      "Action": [
        "lambda:*",
        "dynamodb:*",
        "apigateway:*",
        "s3:*",
        "bedrock:*",
        "events:*",
        "sqs:*",
        "ecr:*",
        "ssm:*",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

10. Bootstrap

I started with the sandbox test, however, I needed to have the bootstrap ready first. The bootstrap is a base preparation so that Blocks applications can work correctly. This preparation is done once per account and region. You do it like this:

npx cdk bootstrap aws://{your_account_id}/{region}

The result of this execution is the creation of a CloudFormation stack and the biggest question: does this generate costs? The answer is no, it only creates an empty S3 bucket, IAM roles, and an SSM parameter. The cost is generated when CDK uploads the static code assets during deploys. Keep in mind that for the sandbox, CDK does not copy these files since the interface keeps running in your local environment.

11. Sandbox

During the sandbox creation, I encountered several challenges. Being a new technology, it is possible to find details that may cause unexpected behavior. You can start the sandbox by running:

npm run sandbox

I chose to test the sandbox in the us-west-2 region. The experience was good and I strengthened my knowledge of the framework. Here are some tips:

Create tags in your project

To have control over your resources, as well as cost monitoring.

index.cdk.ts:

import * as cdk from 'aws-cdk-lib';

cdk.Tags.of(blocksStack).add('Project', 'blocks-chatbot-ia');
cdk.Tags.of(blocksStack).add('Environment', sandboxMode ? 'sandbox' : 'production');
cdk.Tags.of(blocksStack).add('Team', 'dev');
cdk.Tags.of(blocksStack).add('CostCenter', 'chatbot-ia');

Short stack names

Sometimes resources cannot be created if your project name is too long, so you can change the base name of your stack since resources are created with this prefix. In this case, I made changes so the stack would be the project name defined in the package:

index.cdk.ts:

const stackName = sandboxMode ? pkg.name + `-sandbox` : pkg.name + 'prod';

export const blocksStack = await BlocksStack.create(app, stackName, {
  backendHandlerPath: join(__dirname, 'index.handler.ts'),
  backendCDKPath: join(__dirname, 'index.ts')
});

Bedrock quotas in Organizations

If your account is part of an organization, remember that you must set the quotas for Bedrock models, otherwise you won't be able to verify the model responses.

Region bug in @strands-agents/sdk

The @aws-blocks/bb-agent block internally uses the @strands-agents/sdk module in its latest version available at the time of testing (1.7.0), to save agent conversations in S3. However, this module by default points to the us-east-1 region, so when trying to use the agent in another region you might encounter issues. To fix this, you only need to make the following change:

node_modules/@strands-agents/sdk/dist/src/session/s3-storage.js:

this._s3 = config.s3Client ?? new S3Client({ region: config.region ?? process.env.AWS_REGION ?? 'us-east-1' });

With this change, it will now check the region environment variable by default so you can see the history of your conversations. This fix is for that version. I filed report #120 to the AWS Blocks framework maintenance team and it was resolved, so it's unlikely you'll encounter this error anymore. Here are the details of the fix they applied:

https://github.com/aws-devtools-labs/aws-blocks/issues/120

After finishing the sandbox tests, I could see a CloudFormation with the various created resources. In this case, it is possible to better track them thanks to the tags, which identify which project each resource belongs to.

12. Deployment

Having completed the tests in the sandbox, the only thing left is to deploy so the application is accessible to everyone. It is a satisfying experience, since this framework allows you to take stable and secure applications to production using serverless architectures. For this step, the difference from the sandbox is that static hosting is generated, stored in S3 and distributed by CloudFront. The deployment time was 12 minutes.

Below we can see the chatbot working in the production environment.

13. Resource Cleanup

After testing and to avoid incurring costs, I destroyed the created infrastructure. This is as simple as running the following commands:

Delete Sandbox:

npm run sandbox:destroy

Delete deployment:

npm run destroy

Delete CDK (keep in mind that it does not generate costs as long as no assets are transferred):

aws s3 rm s3://cdk-hnb659fds-assets-xxxxx-{region} --recursive --region {region}
aws cloudformation delete-stack --stack-name CDKToolkit --region {region}

About the author

Luis Fernando de León — AWS Community Builder 🇬🇹

📸 Instagram: instagram.com/luisenlanube
📝 DEV: dev.to/luisferdeleon
👤 Facebook: facebook.com/luisenlanube
💼 LinkedIn: linkedin.com/in/luisfdeleonramirez

¿Para que sirve Kubernetes (k8s)?

Luis Fernando de León Ramírez — Mon, 18 May 2026 03:31:32 +0000

Kubernetes es una plataforma de código abierto para la orquestación de contenedores, en muchos casos es una tecnología que no tiene mucha aceptación por la complejidad que puede representar, sin embargo, en escenarios donde las arquitecturas pueden llegar a crear demasiado, puede ser un aliado estratégico para la administración de estos ambientes.
AWS provee el servicio de EKS, el cual permite el uso de Kubernetes de forma sencilla al administrar por nosotros el plano de control, lo cual permite que podamos ir directo al despliegue de nuestras aplicaciones y para conocer más sobre este servicio estaré realizando un proyecto que pueda hacer uso de la mayor parte de sus características.

¡Acompáñame durante estas semanas a ir conociendo más a fondo de este servicio!

Application Load Balancer de EKS se desvincula de WAF

Luis Fernando de León Ramírez — Wed, 15 Apr 2026 03:40:57 +0000

La creación de recursos fuera de infraestructura como código suele darnos sorpresas, regularmente muchos dan mantenimiento a su infraestructura a través de cloudformation, sin embargo en algunos servicios es recomendable que se tome en cuenta la documentación oficial para prevenir imprevistos que puedan ponernos en aprietos.

Hace unos días revisando mi infraestructura la cual se compone de varios clústeres de kubernetes, los cuales aún utilizan ingress controler para definir los paths que dirigen a los servicios publicados, dentro de estos ingress utilicé la función de que automáticamente al crearlos se generara un balanceador de aplicaciones dentro de la infraestructura de AWS, todo había ido muy bien, hasta que hice la actualización de versión de kubernetes.

Todo funcionó correctamente, hice mi actualización a la versión 1.33 de Kubernetes en EKS y todo fue sencillo como siempre, inicialmente hice la actualización de mi plano de control, tratando de ser muy ordenado (En lo personal me gusta realizarlo desde el cli), de la siguiente forma.

1. Verifiqué la versión actual del clúster: 
       aws eks describe-cluster --name eks-cluster-infraestructura --query cluster.version --output text

2. Actualicé el plano de control:
       aws eks update-cluster-version --name eks-cluster-infraestructura  --kubernetes-version 1.33 --output json

3. Actualicé los grupos de nodos:
      aws eks update-nodegroup-version --cluster-name eks-cluster-infraestructura --nodegroup-name ng-cluster-infraestructura --kubernetes-version 1.33

4. Y finalmente actualicé los complementos del clúster:
     aws eks update-addon --cluster-name eks-cluster-infraestructura  --addon-name coredns --addon-version v1.13.2-eksbuild.1 --configuration-values '{}'
     aws eks update-addon --cluster-name eks-cluster-infraestructura   --addon-name vpc-cni --addon-version v1.21.1-eksbuild.5  --configuration-values '{}'
     aws eks update-addon --cluster-name eks-cluster-infraestructura  --addon-name kube-proxy --addon-version v1.33.9-eksbuild.2   --configuration-values '{}'
     aws eks update-addon --cluster-name eks-cluster-infraestructura   --addon-name amazon-cloudwatch-observability --addon-version  v5.2.2-eksbuild.1   --configuration-values '{}'
     aws eks update-addon --cluster-name eks-cluster-infraestructura  --addon-name eks-pod-identity-agent --addon-version  v1.3.10-eksbuild.2 -  --configuration-values '{}'

Como dato adicional les recomiendo esta actualización del complemento de amazon-cloudwatch-observability, acá ya podrán integrar el uso de applications signals (APM) el cual permite un monitoreo a detalle de lo que puede estar pasando en cada carga de trabajo dentro de tu clúster de EKS.

Hasta el momento todo iba muy bien, la actualización fue exitosa, no hubo necesidad de realizar cambios adicionales, sin embargo para revisar que todo estuviera bien hice algunas pruebas y vaya sorpresa, resulta que el web ACL que tenía vinculado el balanceador del cluster, ya no tenía recursos vinculados, luego de leer a fondo la documentación pude observar que es necesario que dentro de la definición de mi recurso Ingress debo vincular el ARN del web ACL, y esto sucede porqué cuando se vincula manualmente el balanceador desde la consola de AWS esa configuración termina siendo efímera, solamente existirá mientras no hayan cambios en el clúster, el archivo yaml de tu ingress no tiene idea de que en algún momento vinculaste el balanceador a un WAF, por lo que al actualizar el clúster este toma la definición inicial del YAML del ingress y al no estar declarado el vinculo al WAF asume que no debe estar ahí.

Es por eso que para que no te suceda esto, te dejaré la forma en la cual debes agregar el ARN del WAF a tu ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mi-app-web
  annotations:
    # En esta línea debes agregar el ARN de tu web ACL 
    alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:region:123456789012:regional/webacl/nombre-waf/a1b2c3d4...
spec:
  ingressClassName: alb

La propiedad en el recurso de ingress ha sido permitida desde hace varios años, sin embargo el adoptar infraestructura que no fue creada por nosotros puede generar inconvenientes como este que en muchos casos genera confusión.

Billing and Cost Manager (Administración de facturación y costos)

Luis Fernando de León Ramírez — Thu, 19 Mar 2026 05:28:43 +0000

Cuando inicie a conocer sobre los servicios de AWS, me generaba miedo el no saber utilizar los créditos de la capa gratuita y tener que pagar una factura muy costosa solamente por hacer pruebas, por lo que cada vez que pensaba en crear una cuenta recordaba eso y no lo hacía, sin embargo existe un servicio dentro de la consola de AWS llamado "Gestión de facturación y costes de AWS", a través de este es posible la generación de reportes y el monitoreo constante de los costos que estamos generando en la consola, cuando descubrí el uso de esto tuve paz al saber que no tendría que pagar cuando estuviera utilizando la capa gratuita, a continuación te dejo un artículo donde te explico cómo crear estos presupuestos.

Al iniciar sesión en tu cuenta debes ingresar al servicio de "Billing and Cost Manager (Administración de facturación y costos".
Selecciona la opción de "Budgets" (Presupuestos)
Para este ejercicio crearemos un presupuesto, el cual nos permitirá saber el total gastado hasta el momento, tomando como referencia que el máximo a gastar por mes serán 50 dólares, para esto utilizaremos la opción de plantillas simplificadas, lo cual utilizará las configuraciones recomendadas, pudiendo cambiar algunas de estas después de haber creado el presupuesto (Alertas configurables).
Al finalizar la creación del presupuesto se listarán los presupuestos disponibles en esta sección daremos clic sobre el presupuesto creado para realizar la configuración de las alertas.
Al editar el presupuesto, en el paso 1 se visualizará el presupuesto creado, en esta sección se deberá indicar el periodo para el cual se asignará el presupuesto, así como el mes en el cual se iniciará la evaluación del presupuesto.
En el paso 2 se configurarán tres alertas las cuales nos informarán cuando alguna de estas se cumpla, las condiciones serán las siguientes:
- Cuando el total del consumo exceda el 25%
- Cuando el total del consumo exceda el 50%
- Cuando el total del consumo exceda el 90%
A cada alerta podremos indicarle un máximo de 10 direcciones de correo electrónico a las cuales se notificará, con la finalidad de mantener un control sobre los recursos que podamos dejar encendidos por equivocación, y poder tomar acciones correctivas de forma manual para evitar el incremento de gastos.
En el paso 3 se presentará un resumen de las alertas y las acciones que se tendrán cuando estas se cumplan (tomar en cuenta que el uso de acciones personalizadas podría incurrir en un gasto adicional, por lo cual con fines de prueba únicamente se establece la notificación por correo electrónico).
En el paso 4 se generará un resumen con todas tus configuraciones realizadas en el presupuesto, al dar clic en guardar todas las configuraciones se aplicarán, de esta forma se habrá creado el presupuesto para monitorear el total consumido en tu cuenta.

Bonus

Si prefieres tener un resumen de lo que recopilan las alertas podrás configurar reportes diarios que lleguen a tu correo electrónico en el cual tendrás el detalle del consumo hasta el final del día.

Ingresa a la opción "Budgets reports (Reportes de presupuesto)" y dar clic sobre la opción de crear reporte, al visualizar la configuración inicial podrás seleccionar el presupuesto al cual deseas dar seguimiento y establecer la frecuencia del envío, para este ejercicio se seleccionará diario, para que el correo sea enviado al final del día con los datos recopilados por la alerta.
Al final del día recibirás un correo en el cual tendrás el resumen de tus gastos.

Recuerda que el crear presupuestos para seguimiento de costos no tendrá ningún valor en tu factura, siempre y cuando sean alertas básicas y con notificación a un máximo de 10 correos electrónicos y sin el uso de acciones correctivas de forma automática.

Accede al siguiente enlace para leer la documentación oficial: Documentación AWS Cost Management

Dockerfile

Luis Fernando de León Ramírez — Tue, 10 Mar 2026 02:29:42 +0000

El traslado de aplicaciones entre ambientes sigue siendo un problema constante, ya que pueden utilizar diversos tipos de servidores, sistemas operativos, dependencias, etc.

Pero esto tiene una solución muy sencilla, el uso de contenedores facilita el traslado de entornos de trabajo generando copias inmutables, las cuales no pueden tener cambios posteriores a su compilación, para realizar esto se hace uso de un archivo de texto plano en el cual se establecen las condiciones para la generación del contenedor.

Dockerfile, este archivo contiene una serie de instrucciones en este caso nuestro robot ensamblador, que se encarga de la construcción del contenedor siguiendo paso a paso las indicaciones proporcionadas, este proceso consiste en la creación de diversas capas que contienen los elementos que serán utilizados.

Es importante conocer estas instrucciones y las acciones que pueden realizar, esto facilitará la administración de la infraestructura de las aplicaciones sin afectar el funcionamiento interno de las aplicaciones, las instrucciones más comunes son:

FROM: Define una base para la imagen, normalmente acá se hacen uso de sistemas operativos optimizados, normalmente se dividen en sistemas operativos completos y mínimos
RUN: A través de esta instrucción ejecuta un comando sobre una capa nueva, también es posible utilizarla para le ejecución de comandos shell.
WORKDIR: Permite situarse sobre un directorio específico.
COPY: Copia nuevos archivos a la imagen del contenedor.
CMD: Permite que puedan ejecutarse comandos al iniciar el contenedor.

Ahora crearemos un ejemplo sencillo para que puedas interactuar con docker.

NOTA: Para este ejercicio haremos uso del Subsistema de Windows para Linux (WSL) con docker instalado.

Crearemos una carpeta en la cual desarrollaremos la creación de nuestra imagen
Creamos un archivo sin extensión llamado Dockerfile

Agregaremos las siguientes líneas dentro del archivo

# Usa una imagen mínima - Alpine Linux
FROM alpine:latest

# Ejecuta un comando para identificar el progreso de la construcción
RUN echo "Construyendo mi primera imagen desde el Dockerfile..."

# Define el comando por defecto que se ejecutará al iniciar el contenedor
CMD ["echo", "¡Hola mundo desde mi primer imagen en docker!"]

Generaremos la imagen por primera vez a través del siguiente comando:
docker build -t mi-hola-mundo .
Deberíamos ver algo similar a esta salida.

Verificaremos que la imagen fue creada correctamente a través del siguiente comando:
Docker images
Deberemos ver nuestra imagen lista para ser utilizada
Ejecutaremos la imagen, cabe mencionar que usaremos la opción --rm para que docker elimine la imagen cuando esta termine de utilizarse.
docker run --rm mi-hola-mundo
Obtendrás la siguiente salida:

¡Hola mundo desde mi primera imagen en docker!

Acá habrás creado tu primera imagen de Docker, esto será el inicio de muchas imágenes que crearas, las cuales podrás modificar para mejores resultados.

¿Quieres saber más de docker?, ingresa al siguiente enlace: Link

En la nube de AWS podrás hacer uso los contenedores que crees en diferentes servicios como ECS y EKS, te invito a que puedas conocer estos servicios
ECS: Link
EKS: Link

Y recuerda que puedes obtener hasta 200 dólares en la capa gratuita de AWS para hacer tus pruebas, si quieres conocer más de esto, ingresa al siguiente enlace: Link

#Containers #Dockerfile #AWS #AWSComunityBuilders #ECS #EKS

¿Qué es un contenedor?

Luis Fernando de León Ramírez — Thu, 05 Mar 2026 01:09:16 +0000

Los contenedores son elementos de transporte o cajas de almacenamiento que son utilizadas para facilitar el traslado de diversos objetos.

¡Ahora imaginate hacer todo esto con software!

En muchas ocasiones necesitamos trasladar software a un ambiente productivo, sin embargo las versiones de dependencias o sistemas operativos generan comportamientos distintos al trasladarlo, es por ello que en 2013 buscando solucionar este problema se lanzó una tecnología llamada Docker que buscaba empaquetar el software haciendo uso de sistemas operativos ligeros para aumentar la eficiencia de los servidores y manteniendo las versiones de dependencias utilizadas.

Quieres conocer más sobre esta tecnología, puedes leer el artículo completo acá: Link

💡☁️ Ciclo de operaciones en la nube

Luis Fernando de León Ramírez — Thu, 05 Mar 2026 00:12:41 +0000

📈La creciente incursión de la tecnología en empresas y organizaciones requiere la administración adecuada de las cargas de trabajo, para poder destacarse frente a sus competidores, es necesario fomentar la innovación y optimización de procesos, promoviendo la eficiencia en el desarrollo e implementación de software en producción.

Es por ello que es importante conocer el ciclo de operaciones en la nube, el cual se desarrolla a través de las siguientes etapas:
🚀 Despliegue.
📊 Monitoreo.
🔧 Mantenimiento.
🔏 Seguridad.
✅ Optimización.

¿Quieres conocer más sobre el ciclo de operaciones en la nube?

Puedes seguir el curso gratuito de AWS CloudOps Engineer en Skillbuilders, a través del siguiente enlace:
Link

AWS cloud Adoption Framework

Luis Fernando de León Ramírez — Thu, 05 Mar 2026 00:10:18 +0000

🚀☁️¿Trabajas on-premises y te preguntas como iniciar con el traslado de cargas de trabajo a la nube?

Es una pregunta muy común; Para llevar a cabo una migración es necesario definir una planificación que contribuya a la transformación digital y la entrega de resultados empresariales de forma eficiente.

AWS Cloud Adoption Framework (AWS CAF) provee una serie de buenas prácticas que se enfocan en proveer conocimientos que faciliten a las organizaciones una migración eficaz a la nube de AWS.

El CAF se enfoca en seis perspectivas principales:
💰 Comercial
🙋 Personas
⚖ Gobernanza
💻 Plataforma
🔐 Seguridad
⚒ Operaciones

¿Quieres conocer más sobre AWS Cloud Adoption Framework ?

Puedes leer el artículo completo acá
Link

#Cloud hashtag#AWS #gt #AWSCAF #CloudComputing #CloudArchitecture #Architecture #AWSCloudAdoptionFramework

AWS Identity and Access Managment (IAM)

Luis Fernando de León Ramírez — Thu, 05 Mar 2026 00:01:15 +0000

🔐 AWS Identity and Access Managment (IAM) fortalece el control de los recursos en AWS, al crear una cuenta se establece un usuario raíz que tendrá acceso ilimitado a todos los servicios en la cuenta.

Dentro del servicio de IAM existen identidades, las cuales pueden asociarse a diversas políticas que definen acciones a realizar con los servicios, los tipos de identidades son:

🙋 Usuarios
👨‍👩‍👦‍👦 Grupos de usuarios
👮Roles

📜 Las políticas permiten establecer a detalle los permisos que tendrán las identidades para la interacción con los servicios de AWS

➡️ Si quieres conocer más sobre IAM el sitio de AWS SkillBuilder ofrece una introducción a IAM en 10 minutos, ¿Quieres verlo?
Link

➡️ Quieres saber más sobre IAM: Link

#Cloud #AWS #gt #SkillBuilder #IAM #CloudComputing #CloudArchitecture #Architecture