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

¿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

Seguridad en AWS

Luis Fernando de León Ramírez — Wed, 04 Mar 2026 23:58:51 +0000

👮Gestión de identidad y accesos

🔒AWS IAM: Este servicio permite la creación de usuarios, roles y políticas, estos fortalecen el control de accesos a los recursos siendo parte fundamental para el cumplimiento del principio de privilegio mínimo.

🔑AWS SSO (identity Center): Este servicio facilita la administración de acceso a múltipes cuentas de AWS, proporcionando un inicio de sesión único para todas las cuentas y aplicaciones asignadas.

👓 AWS Cognito: Gestiona la autenticación, autorización e identidad de usuarios para aplicaciones web y móviles.

💻AWS Directory Service: Es una solución nativa en la nube que permite la integración de cargas de trabajos dependientes de Active Directory.

#Cloud #AWS #gt #IAM #CloudComputing #CloudArchitecture hashtag#Architecture #SSO #IdentityCenter #AWSCognito #AWSDirectoryService

Localstack

Luis Fernando de León Ramírez — Wed, 04 Mar 2026 23:53:50 +0000

💡¿Te encuentras iniciando en el mundo de AWS?

😱 Muchos consideran que iniciar puede ser complicado al no contar con herramientas que permitan realizar pruebas antes de llevar a cabo las pruebas en la capa gratuita, sin embargo actualmente existen herramientas que permiten emular diversos servicios de AWS en ambiente local, esto con la finalidad de reducir los costos en pruebas e implementar aplicaciones que se encuentren totalmente funcionales.

Localstack✌️
Es una herramientas que permite poder tener acceso a los recursos de diversas plataformas en ambiente local, teniendo control total de tu infraestructura, en la sección de AWS ofrece diversos planes los cuales ofrecen hasta 100 servicios para utilizar de forma local.

En el plan básico se ofrecen hasta 30 servicios los cuales pueden ser utilizados para pruebas de los servicios.

🛠 Un ejemplo rápido utilizando el método de instalación de docker compose

Sigue estos pasos para la instalación descargando el archivo de docker-compose.yml :
https://docs.localstack.cloud/aws/getting-started/installation/
Ten en cuenta que al utilizar el método de docker compose, debes indicar los servicios que utilizarás en las variables de ambiente
SERVICES: s3 ,sqs,dynamodb,lambda,iam,cloudwatch
Inicia el contenedor
docker compose up
Crea un archivo denominado index.js y realiza lo que necesitas en tu función lambda

Compilar y generar la función para su creación

Probar las función creada.

Ver la respuesta de la ejecución.

¿Ya habías probado esta herramienta?

#Cloud #AWS #localstack #gt #CI/CD #Lambda