DEV Community: AWS Community Builders

What is AWS Blocks? How it differs from Amplify and App Studio, and what each one is aiming for

Kento IKEDA — Fri, 19 Jun 2026 22:12:14 +0000

On June 16, 2026, AWS announced AWS Blocks as a public preview. It is an open-source framework where the TypeScript you write for your backend becomes the AWS infrastructure that runs it.

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

The first thing many AWS users will think is "another full-stack tool." If you want a tool for frontend developers to build full-stack apps in TypeScript, Amplify Gen2 already exists. For people who don't write code, there is App Studio. I compared those three earlier in a write-up on App Studio, Amplify Gen1, and Amplify Gen2. Now Blocks joins them.

This article organizes what AWS Blocks is from the official docs and the open-source code, lines it up against Amplify and App Studio, and finally sketches a map of what each one is aiming for. Rather than stopping at a feature-diff table, I want to get at why AWS is offering multiple entry points into full-stack development.

A note: this is based on the official docs right after the preview announcement and on reading the open-source code. It is not based on long-term production use of Blocks. Read it with the understanding that implementation details may change.

What is AWS Blocks

Here is how the official docs define it. AWS Blocks is a backend toolkit for full-stack applications, where each Block is a self-contained backend capability that bundles the application code, a local development setup, and the infrastructure to run it. Pick the Blocks you need and compose them, and the infrastructure following AWS best practices is defined automatically.

Type safety doesn't stop inside the backend. Types flow from the backend all the way to the client, reaching web frameworks (Next.js, Nuxt, Astro, React, Vue, Svelte, Angular) and native targets (Swift, Kotlin, Dart/Flutter). From a single backend, you can generate typed client code for both web and mobile.

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

That said, at the time of the preview announcement the frontends officially listed are SPAs (Vite + React) and SSR frameworks (Next.js, Nuxt, Astro), with support expected to widen over time. Blocks itself adds no extra charge; you pay only for the AWS services you use, and you can deploy to all commercial AWS Regions.

https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview/

From here, let's walk through the concepts you can't skip to understand Blocks.

Block = an npm package bundling infrastructure, runtime, and local implementation

One Block is one npm package, holding the cloud resources, runtime code, and local implementation for a single capability. Instantiate one KVStore, for example, and you get all at once: a DynamoDB table auto-provisioned at deploy time, runtime code that runs on Lambda, and an in-memory implementation for local development.

https://docs.aws.amazon.com/blocks/latest/devguide/concepts.html

The available Blocks cover most backend needs: data (KVStore, DistributedTable, Database, DistributedDatabase, FileBucket), auth (AuthBasic, AuthCognito, AuthOIDC), async work (AsyncJob, CronJob), AI (Agent, KnowledgeBase), communication (Realtime, EmailClient), configuration (AppSetting), observability (Logger, Metrics, Tracer, Dashboard), and hosting (Hosting).

https://docs.aws.amazon.com/blocks/latest/devguide/what-is-blocks.html

What the official overview page doesn't give you, though, is a list of which AWS service each Block actually becomes inside. I was curious, so I read the open-source code (aws-devtools-labs/aws-blocks) to confirm the real services behind the main Blocks.

Block	AWS service inside
`KVStore` / `DistributedTable`	DynamoDB
`Database`	Aurora Serverless v2 (PostgreSQL 16.4)
`DistributedDatabase`	Aurora DSQL
`FileBucket`	S3
`AuthBasic`	no dedicated infrastructure
`AuthCognito` / `AuthOIDC`	Cognito
`AsyncJob`	SQS + Lambda
`CronJob`	EventBridge Scheduler
`Agent`	Strands Agents SDK + Bedrock
`KnowledgeBase`	Bedrock + S3 Vectors
`Realtime`	API Gateway v2 (WebSocket)
`EmailClient`	SES
`AppSetting`	SSM Parameter Store
`Logger` / `Metrics` / `Tracer` / `Dashboard`	CloudWatch
`Hosting`	CloudFront + S3 + WAF + Route 53 + ACM

A few findings the overview alone doesn't reveal:

DistributedDatabase is Aurora DSQL, so DSQL's own constraints surface directly in the development experience. You can't mix DDL and DML in the same transaction, and only one DDL statement is allowed per transaction. Blocks rejects these on the client side with validation.

KnowledgeBase uses S3 Vectors, which arrived in 2025, as the vector store for RAG.

Agent sits on top of Strands Agents SDK, AWS's open-source agent framework.

Hosting is less "CloudFront + S3" and more a heavier part that also bundles WAF, Route 53, and ACM.

IFC layer = the entry point where code becomes infrastructure

The backend entry point of Blocks lives in a single file, aws-blocks/index.ts. Instantiate Blocks and define your API there, and the infrastructure is derived directly from that code. No separate file for infrastructure definitions.

This idea of deriving infrastructure from code is called Infrastructure from Code (IFC), and in the source this backend part was named the IFC subpackage.

In other words, the code that describes infrastructure and the code that describes the app aren't separated. Infrastructure grows out of the app's code. This is the heart of Blocks' philosophy.

Conditional exports = the same import switches implementation by context

The reason a single file can play three roles at once, namely local development, deploy, and production runtime, is Node.js conditional exports, which route the same import statement to a different implementation per context.

Context	Resolved implementation	What happens
Local development	in-memory / filesystem	the app runs on localhost alone
CDK synthesis	CDK constructs	infrastructure is defined for CloudFormation
Lambda runtime	AWS SDK	real services are called in production
TypeScript / IDE	type definitions	completion and type checking work

The same line new KVStore(scope, 'todos') becomes a local store in development, a DynamoDB table at deploy time, and an SDK call in production. You never change the code. Without writing any configuration by hand, module resolution picks the implementation per context. Reading the source package.json, they are switched by conditions like cdk, aws-runtime, types, and default (the local mock).

ApiNamespace = type-safe RPC with no code generation

The part that calls the backend from the frontend is handled by ApiNamespace. The frontend imports and calls methods defined in the backend directly.

// Frontend: import the backend API directly
import { api } from '../aws-blocks/index.js';

const result = await api.greet('World');
// TypeScript knows the return type too

No code generation step, no API client initialization, no URL configuration. Change a backend method signature and the frontend gets a compile error instantly. Locally it goes through an HTTP server; in production it reaches Lambda through API Gateway.

The transport underneath is JSON-RPC 2.0. When you call a typed method, it is converted into a JSON-RPC request internally and delivered to the backend. The developer never assembles a payload by hand; the transport stays hidden behind the types.

Local-first = everything runs without an AWS account

Run npm run dev and the whole app starts locally. Blocks resolve to local implementations (an in-memory store, local auth, an embedded DB), running at http://localhost:3000 with hot reload. No AWS account, no internet connection, no cloud billing. Local data is persisted under .bb-data/ at the project root.

The "embedded DB" here turns out to be PGlite (a WebAssembly build of PostgreSQL). Not only Database but also DistributedDatabase, which uses Aurora DSQL, falls back to PGlite locally. It works because DSQL is PostgreSQL-compatible, so a near-real Postgres comes up locally without an AWS account.

When you want to check behavior against real cloud services, npm run sandbox deploys to a fast, disposable environment using hot-swap to Lambda. The mocks are swapped for real AWS services (DynamoDB, Aurora, S3, Lambda, and so on), and once you are done you can tear it all down with npm run sandbox:destroy. To ship to production, you run npm run deploy. The same backend code runs in all three.

Direct CDK access = if Blocks isn't enough, write it yourself

Every Blocks app is a CDK app. You can use arbitrary CDK constructs alongside Blocks, and you can embed Blocks into an existing CDK stack.

When you want to add a resource Blocks doesn't provide (SNS, Step Functions, and the like) or set up a custom domain, you write aws-blocks/index.cdk.ts and access CDK constructs directly. Normally the infrastructure is derived from the backend definition (aws-blocks/index.ts), so you don't need to touch CDK directly. When you do need it, you just write CDK and can build as far as you like, beyond the edges of the framework. By design, it is structurally hard to get trapped and stuck inside the abstraction.

AGENTS.md bundled = agents write correct code from the start

Blocks ships an agent-facing guide inside the npm package. Without adding a plugin, an AI coding agent is said to be steered toward writing correct code from the start.

Its actual form turned out to be an AGENTS.md placed in the project. Reading it, rather than carrying the full guide inline, it is a pointer to references. The detailed explanation, how to choose a Block, and how to use each Block live under node_modules/@aws-blocks/blocks/ in README.md, docs/index.md, and docs/.md, and it tells the agent to read those. Alongside, the Rules forbid anti-patterns: always use a Block for persistence (no local files, in-memory arrays, or local DBs), and don't assemble JSON-RPC payloads by hand.

Rather than pouring everything into the agent's context, you have it read only the docs it needs when it needs them. This pointer approach is sound as a design for agent-facing docs, and it is worth noting that an official AWS framework ships with it.

How it differs from Amplify and App Studio

Let me line up what we have covered against Amplify Gen2 and App Studio.

Amplify Gen2 is a development platform where you describe data models, business logic, and authn/authz in TypeScript and the appropriate cloud resources are auto-provisioned. It is built on CDK internally and offers categories like Data, Auth, Storage, and Functions out of the box. Per-developer cloud sandboxes, shared environments mapped one-to-one to Git branches, and the Amplify Console that bundles hosting and CI/CD are its hallmarks.

https://docs.amplify.aws/react/how-amplify-works/concepts/

App Studio sits on the low-code side, letting non-developers and beginners with little coding experience design and build apps. Where Amplify Gen2 and Blocks target developers, App Studio aims at a fundamentally different audience. I have organized the product details in the write-up I mentioned at the top.

https://zenn.dev/ikenyal/articles/c2c3ccf9fdd0cf

Lined up by aspect:

Aspect	App Studio	Amplify Gen2	AWS Blocks
Primary audience	non-developers	frontend developers	developers who also write backends
How infrastructure is handled	fully hidden	abstracted by category	derived from code (IFC)
Local development	cloud-first	per-developer cloud environment	fully local, no AWS account
Hosting / CI-CD	built in	bundled in the Amplify Console	Hosting is one Block, CI/CD is your own
How types flow	types aren't a concern	schema-driven Data types	type-safe RPC, no generation
Distance from CDK	far	used for extensions when needed	a CDK app from the start, write CDK directly
AI coding agents	out of scope	little explicit support	bundled AGENTS.md as a premise

A shared obsession with iteration speed shows up too. Amplify Gen2 advertises up to 8x faster iteration than Gen1, speeding up cloud-side reflection via hot-swap to per-developer sandboxes. Blocks, on the other hand, completes locally, so in many cases there is no round trip to the cloud at all. The direction of "faster" differs, but the aim of shortening the write-then-check loop is shared.

What each one is aiming for

Rather than feature diffs, let me put into words what the three are trying to achieve.

What App Studio aims for is delivering apps to people who don't write code. Its abstraction is the highest, and it minimizes the developer's involvement the most.

What Amplify aims for is freeing frontend developers from infrastructure. Even though Gen2 was rebuilt on CDK, what developers face day to day are categories like Data, Auth, and Storage, and that managed mass covers up the infrastructure underneath. It takes care of hosting and CI/CD together, freeing developers from stitching individual AWS services by hand. The key is to hide.

What Blocks aims for looks a little different. The entry point of making infrastructure tools unnecessary to learn is similar to Amplify, but its means leans toward making things transparent with code and types rather than hiding them. Infrastructure grows from the app's code, the same code runs both locally and in the cloud, and you can write CDK directly when needed. Rather than ease through concealment, it aims for reassurance through transparency and the absence of a ceiling.

In short, Amplify reaches the shared goal of making frontend developers' lives easier by keeping infrastructure out of mind, while Blocks does it by letting you stay aware of infrastructure without requiring you to. They take two routes to the same place. The former thickens the wall of abstraction; the latter makes it thin and transparent.

And Blocks carries one more premise that is distinctive of 2026. It takes for granted that AI agents write code, and the framework itself carries the correct way to write from the start. This is a design that lowers not only the cost of humans learning but the cost of agents making mistakes, and its starting point looks different from Amplify's design philosophy.

Where is Amplify headed

What follows is interpretation, not fact. I write it on the premise that none of it is certain.

The official docs explicitly call the relationship between Blocks and Amplify complementary. Amplify provides hosting, CI/CD, and a managed backend experience; Blocks focuses on type-safe infrastructure-from-code and local-first development.

Still, the overlap is not small. Amplify Gen2 also defines backends code-first in TypeScript, on top of CDK. Blocks' IFC layer and Amplify Gen2's backend definition are both a "write your backend in TypeScript" experience standing on CDK, so they sit close in philosophy.

The closeness shows on the implementation side too. Blocks' project-creation CLI auto-detects an existing Amplify Gen2 project and integrates with it, and there is even a dedicated amplify template. Adding Blocks to an Amplify Gen2 backend is an entry path assumed from the start. The complementary relationship is not just a line in the docs; it is implemented as tool behavior.

One possibility I read from this: Amplify shifts its center of gravity toward the hosting and managed-experience layer, while Blocks takes the composable-backend-parts and local-development layer. In fact, Hosting in Blocks is treated as one part bundling CloudFront, S3, and even WAF, and the integrated hosting and CI/CD experience remains a strength on Amplify's side.

What matters is that this doesn't necessarily mean Amplify is shrinking. It reads more naturally as AWS deliberately keeping multiple entry points into full-stack development. App Studio for non-developers, Amplify for those who want a managed experience, Blocks for those who want to command infrastructure with code and types. Rather than converging on a single right answer, it looks like a strategy of preparing a different door for each developer's stance.

Closing

AWS Blocks turned out to be not a replacement for Amplify but one more entry point into full-stack development. Amplify, which makes things easy by hiding; Blocks, which makes things transparent and hands you the controls. Which you choose is also a statement of how you want to relate to infrastructure.

AWS is not converging on a single answer. When the doors multiply, the question isn't which tool is better, but which kind of developer you want to be.

Going Serverless with Terraform - Deploying AWS Lambda Functions

Sarvar Nadaf — Fri, 19 Jun 2026 13:33:44 +0000

👋 Hey there, tech enthusiasts!

I'm Sarvar, a Cloud Architect with a passion for transforming complex technological challenges into elegant solutions. With extensive experience spanning Cloud Operations (AWS & Azure), Data Operations, Analytics, DevOps, and Generative AI, I've had the privilege of architecting solutions for global enterprises that drive real business impact. Through this article series, I'm excited to share practical insights, best practices, and hands-on experiences from my journey in the tech world. Whether you're a seasoned professional or just starting out, I aim to break down complex concepts into digestible pieces that you can apply in your projects.

"Servers are like pets you feed them, nurse them, and cry when they die. Lambda functions are like cattle spin them up, use them, forget them."

🎯 Welcome Back!

Remember in Article 7 when you deployed web servers with a load balancer? You built EC2 instances running 24/7 behind an ALB. That's great for high-traffic web apps. But what about workloads that only run occasionally?

Here's the reality: You've been paying for EC2 instances 24/7 even when nobody's using them. That internal tool that processes files once a day? Running on a t3.medium at $30/month for 5 minutes of actual work.

Lambda changes the equation:

Pay only when code runs
No servers to patch or maintain
Scales from zero to thousands automatically
IAM roles handle permissions (you know this now!)

By the end of this article, you'll:

✅ Deploy Lambda functions with Terraform
✅ Create API Gateway endpoints for HTTP access
✅ Trigger Lambda from S3 file uploads
✅ Configure IAM roles with least privilege
✅ Set up CloudWatch logging automatically
✅ Test everything with real invocations

Time Required: 45 minutes (20 min read + 25 min practice)

Cost: $0 (Lambda free tier)

Difficulty: Intermediate

Let's go serverless! 🚀

💔 The Problem: Paying for Idle Servers

The Wake-Up Call

Monthly AWS bill review. Something doesn't add up:

EC2 Instances:
- file-processor (t3.medium)  → $30.37/month
  Actual compute time: 12 minutes/day
  Utilization: 0.8%

- api-backend (t3.small)      → $15.18/month
  Actual requests: 200/day
  Utilization: 2.1%

- cron-worker (t2.micro)      → $8.47/month
  Runs one script at midnight
  Utilization: 0.03%

Total: $54/month for services used less than 1% of the time.

With Lambda, that same workload costs under $1/month. Not a typo. Under one dollar.

When EC2 Doesn't Make Sense:

❌ Event-driven processing: File uploaded → process it → done

❌ Low-traffic APIs: Dozen requests per hour

❌ Scheduled tasks: Run once a day or hour

❌ Webhook handlers: Wait for external events

❌ Data transformations: Input → transform → output

Sound familiar? Let's move these to Lambda.

🌟 What is AWS Lambda?

Simple Definition

Lambda = Your code runs only when triggered. No servers. No patching. No scaling configuration.

Think of it like this:

EC2 is renting an apartment you pay monthly whether you're home or not
Lambda is a hotel room you pay only for the nights you stay

How Lambda Works:

Trigger (API call, S3 upload, schedule)
    ↓
AWS spins up your function (milliseconds)
    ↓
Your code runs
    ↓
Result returned
    ↓
Function shuts down (you stop paying)

Lambda + Terraform = Perfect Match

Why Terraform for Lambda?

Version control your function configuration
Consistent deployments across environments
IAM roles defined alongside functions (Article 9 skills!)
Connected resources (API Gateway, S3, CloudWatch) in one config

📋 Prerequisites

Before starting:

✅ Terraform installed (Article 2)
✅ AWS credentials configured
✅ Understand VPCs and Security Groups (Article 6)
✅ Basic Python knowledge (for Lambda code)

🏗️ What We're Building

┌─────────────────────────────────────────────────────┐
│                    Our Architecture                 │
│                                                     │
│  ┌──────────┐       ┌──────────────┐                │
│  │   User   │──────▶│ API Gateway  │                │
│  └──────────┘       └──────┬───────┘                │
│                            │                        │
│                            ▼                        │
│                     ┌──────────────┐                │
│                     │ Hello Lambda │──▶ CloudWatch │
│                     └──────────────┘                │
│                                                     │
│  ┌──────────┐       ┌──────────────┐                │
│  │ S3 Upload│──────▶│S3 Processor  │──▶ CloudWatch │
│  │  (.txt)  │       │   Lambda     │                │
│  └──────────┘       └──────────────┘                │
└─────────────────────────────────────────────────────┘

Two Lambda functions:

Hello API - HTTP endpoint via API Gateway, returns JSON
S3 Processor - Triggered when .txt files are uploaded to S3

Source Code

The complete source code and Terraform configuration used in this article can be found on GitHub:

simplynadaf / terraform-by-sarvar

Terraform Series

🚀 Terraform By Sarvar

Complete Terraform tutorial series from basics to advanced concepts

📖 Read the Series • 🌐 Portfolio • 💼 LinkedIn

📚 Series Overview

This repository contains ONLY Terraform code examples for the Terraform By Sarvar tutorial series.

⚠️ IMPORTANT: This repo contains only .tf files and infrastructure code. Articles are published on dev.to, not stored here.

📖 Read the series on dev.to: https://dev.to/sarvar_04/series/36963

🎯 What You'll Learn

✅ Infrastructure as Code (IaC) fundamentals
✅ Terraform basics to advanced concepts
✅ AWS resource provisioning
✅ Best practices and real-world patterns
✅ Production-ready configurations

📊 Series Progress

📖 Article Series

📘 Foundation (Articles 1-5) ✅ Complete

Introduction to Terraform & IaC - ✅ Published
Installation & Setup - ✅ Published
Your First AWS Resource - ✅ Published
Understanding Terraform State - ✅ Published
Variables and Outputs - ✅ Published

📗 Real Infrastructure (Articles 6-10)

Building a VPC from Scratch…

View on GitHub

Getting Started

Follow these steps to run the project on your local machine:

Clone the repository:

git clone https://github.com/simplynadaf/terraform-by-sarvar.git

Navigate to the project directory:

cd terraform-by-sarvar/articles/08-lambda-serverless

🔧 Step 1: Write the Lambda Functions

Before Terraform, we need the actual code. Create a lambda/ directory:

mkdir -p lambda

lambda/hello.py - Simple API handler:

import json

def lambda_handler(event, context):
    """
    Simple Hello World Lambda function
    """
    print(f"Event received: {json.dumps(event)}")

    # Get name from query parameters or use default
    name = "World"
    if event.get('queryStringParameters'):
        name = event['queryStringParameters'].get('name', 'World')

    response_body = {
        'message': f'Hello, {name}!',
        'timestamp': context.aws_request_id,
        'function_name': context.function_name,
        'memory_limit': context.memory_limit_in_mb
    }

    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps(response_body)
    }

lambda/s3_processor.py - Processes uploaded files:

import json
import urllib.parse

def lambda_handler(event, context):
    """
    Process files uploaded to S3
    """
    print(f"Event received: {json.dumps(event)}")

    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key = urllib.parse.unquote_plus(record['s3']['object']['key'])
        size = record['s3']['object']['size']
        event_name = record['eventName']

        print(f"Processing file: {key}")
        print(f"Bucket: {bucket}")
        print(f"Size: {size} bytes")
        print(f"Event: {event_name}")

        result = {
            'status': 'processed',
            'file': key,
            'bucket': bucket,
            'size': size
        }

        print(f"Result: {json.dumps(result)}")

    return {
        'statusCode': 200,
        'body': json.dumps('File processed successfully')
    }

Key points:

lambda_handler is the entry point AWS calls
event contains trigger data (HTTP request, S3 event, etc.)
context has runtime info (request ID, function name, memory)
Always return a proper response with statusCode

🔧 Step 2: Terraform Configuration

main.tf - Here's the complete infrastructure:

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    archive = {
      source  = "hashicorp/archive"
      version = "~> 2.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

Notice the archive provider Terraform uses this to zip your Python files into deployment packages. No manual zipping.

Package the Lambda code:

data "archive_file" "hello_lambda" {
  type        = "zip"
  source_file = "${path.module}/lambda/hello.py"
  output_path = "${path.module}/lambda/hello.zip"
}

data "archive_file" "s3_processor_lambda" {
  type        = "zip"
  source_file = "${path.module}/lambda/s3_processor.py"
  output_path = "${path.module}/lambda/s3_processor.zip"
}

The archive_file data source creates zip files at plan time. When you change the Python code, Terraform detects the hash change and redeploys automatically.

🔧 Step 3: IAM Role (Applying Article 9 Knowledge)

resource "aws_iam_role" "lambda_role" {
  name = "${var.project_name}-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_policy" "lambda_s3" {
  name = "${var.project_name}-lambda-s3-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "s3:GetObject",
        "s3:PutObject"
      ]
      Resource = "${aws_s3_bucket.lambda_trigger.arn}/*"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_s3" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = aws_iam_policy.lambda_s3.arn
}

Key decisions:

AWSLambdaBasicExecutionRole AWS managed policy for CloudWatch Logs access. Every Lambda needs this.
Custom S3 policy Only GetObject and PutObject on our specific bucket. Least privilege from Article 9.
The assume role policy says "only Lambda service can use this role." No human, no other service.

🔧 Step 4: Lambda Functions

resource "aws_lambda_function" "hello" {
  filename         = data.archive_file.hello_lambda.output_path
  function_name    = "${var.project_name}-hello"
  role             = aws_iam_role.lambda_role.arn
  handler          = "hello.lambda_handler"
  source_code_hash = data.archive_file.hello_lambda.output_base64sha256
  runtime          = "python3.11"
  timeout          = 10
  memory_size      = 128

  environment {
    variables = {
      ENVIRONMENT = var.environment
      PROJECT     = var.project_name
    }
  }

  tags = {
    Name        = "${var.project_name}-hello"
    Environment = var.environment
  }
}

resource "aws_lambda_function" "s3_processor" {
  filename         = data.archive_file.s3_processor_lambda.output_path
  function_name    = "${var.project_name}-s3-processor"
  role             = aws_iam_role.lambda_role.arn
  handler          = "s3_processor.lambda_handler"
  source_code_hash = data.archive_file.s3_processor_lambda.output_base64sha256
  runtime          = "python3.11"
  timeout          = 30
  memory_size      = 256

  environment {
    variables = {
      ENVIRONMENT = var.environment
      PROJECT     = var.project_name
    }
  }

  tags = {
    Name        = "${var.project_name}-s3-processor"
    Environment = var.environment
  }
}

Why these settings:

source_code_hash Terraform redeploys when code changes. Without this, it won't detect updates.
timeout = 10 for Hello (API calls should be fast), timeout = 30 for S3 processor (file processing needs more time)
memory_size = 128 for Hello (minimal), 256 for S3 processor (more processing power)
handler = "hello.lambda_handler" format is filename.function_name

🔧 Step 5: CloudWatch Log Groups

resource "aws_cloudwatch_log_group" "hello_lambda" {
  name              = "/aws/lambda/${aws_lambda_function.hello.function_name}"
  retention_in_days = 7
}

resource "aws_cloudwatch_log_group" "s3_processor_lambda" {
  name              = "/aws/lambda/${aws_lambda_function.s3_processor.function_name}"
  retention_in_days = 7
}

Lambda creates log groups automatically, but Terraform-managed groups give you:

Controlled retention (7 days, not infinite)
Proper cleanup on terraform destroy
Cost control (old logs don't pile up)

🔧 Step 6: S3 Bucket with Lambda Trigger

resource "aws_s3_bucket" "lambda_trigger" {
  bucket = var.s3_bucket_name

  tags = {
    Name        = var.s3_bucket_name
    Environment = var.environment
  }
}

resource "aws_lambda_permission" "s3_invoke" {
  statement_id  = "AllowS3Invoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.s3_processor.function_name
  principal     = "s3.amazonaws.com"
  source_arn    = aws_s3_bucket.lambda_trigger.arn
}

resource "aws_s3_bucket_notification" "lambda_trigger" {
  bucket = aws_s3_bucket.lambda_trigger.id

  lambda_function {
    lambda_function_arn = aws_lambda_function.s3_processor.arn
    events              = ["s3:ObjectCreated:*"]
    filter_suffix       = ".txt"
  }

  depends_on = [aws_lambda_permission.s3_invoke]
}

Critical detail: The aws_lambda_permission must come before the bucket notification. The depends_on ensures this. Without it, S3 can't invoke your Lambda because the permission doesn't exist yet.

The filter_suffix = ".txt" means only .txt file uploads trigger the function. Upload a .jpg? Nothing happens. This prevents accidental infinite loops if your Lambda writes back to the same bucket.

🔧 Step 7: API Gateway

resource "aws_api_gateway_rest_api" "main" {
  name        = "${var.project_name}-api"
  description = "API Gateway for Lambda functions"

  endpoint_configuration {
    types = ["REGIONAL"]
  }
}

resource "aws_api_gateway_resource" "hello" {
  rest_api_id = aws_api_gateway_rest_api.main.id
  parent_id   = aws_api_gateway_rest_api.main.root_resource_id
  path_part   = "hello"
}

resource "aws_api_gateway_method" "hello_get" {
  rest_api_id   = aws_api_gateway_rest_api.main.id
  resource_id   = aws_api_gateway_resource.hello.id
  http_method   = "GET"
  authorization = "NONE"
}

resource "aws_api_gateway_integration" "hello_lambda" {
  rest_api_id             = aws_api_gateway_rest_api.main.id
  resource_id             = aws_api_gateway_resource.hello.id
  http_method             = aws_api_gateway_method.hello_get.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.hello.invoke_arn
}

resource "aws_api_gateway_deployment" "main" {
  rest_api_id = aws_api_gateway_rest_api.main.id

  triggers = {
    redeployment = sha1(jsonencode([
      aws_api_gateway_resource.hello.id,
      aws_api_gateway_method.hello_get.id,
      aws_api_gateway_integration.hello_lambda.id,
    ]))
  }

  lifecycle {
    create_before_destroy = true
  }

  depends_on = [aws_api_gateway_integration.hello_lambda]
}

resource "aws_api_gateway_stage" "main" {
  deployment_id = aws_api_gateway_deployment.main.id
  rest_api_id   = aws_api_gateway_rest_api.main.id
  stage_name    = var.environment
}

resource "aws_lambda_permission" "api_gateway" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.hello.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.main.execution_arn}/*/*"
}

API Gateway is verbose in Terraform. That's 7 resources for one endpoint. Here's what each does:

rest_api - The API itself
resource - The /hello path
method - GET on /hello
integration - Connect method to Lambda (always POST for Lambda proxy)
deployment - Snapshot of the API config
stage - Named deployment (dev, prod)
lambda_permission - Allows API Gateway to invoke the function

The triggers block on deployment ensures redeployment when any resource changes. Without it, API Gateway serves stale configurations.

🔧 Step 8: Variables and Outputs

variables.tf:

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Project name"
  type        = string
  default     = "terraform-lambda"
}

variable "environment" {
  description = "Environment"
  type        = string
  default     = "dev"
}

variable "s3_bucket_name" {
  description = "S3 bucket name for Lambda triggers"
  type        = string
  default     = "terraform-lambda-demo-2026"
}

outputs.tf:

output "api_gateway_url" {
  description = "API Gateway URL"
  value       = "${aws_api_gateway_stage.main.invoke_url}/hello"
}

output "hello_lambda_name" {
  description = "Hello Lambda function name"
  value       = aws_lambda_function.hello.function_name
}

output "s3_bucket_name" {
  description = "S3 bucket name"
  value       = aws_s3_bucket.lambda_trigger.id
}

🚀 Deploy and Test

# Initialize (downloads aws + archive providers)
terraform init

# Preview
terraform plan

# Deploy (creates ~18 resources)
terraform apply

Deployment takes about 2 minutes. Most of that is API Gateway.

✅ Testing

Test 1: API Gateway → Hello Lambda

# Get the API URL
API_URL=$(terraform output -raw api_gateway_url)

# Basic call
curl $API_URL

Expected output:

{
  "message": "Hello, World!",
  "timestamp": "abc123-def456",
  "function_name": "terraform-lambda-hello",
  "memory_limit": 128
}

# With query parameter
curl "$API_URL?name=Terraform"

Expected output:

{
  "message": "Hello, Terraform!",
  "timestamp": "xyz789",
  "function_name": "terraform-lambda-hello",
  "memory_limit": 128
}

Test 2: S3 Upload → Processor Lambda

# Create a test file
echo "Hello from Terraform Lambda demo" > test.txt

# Upload to S3 (triggers Lambda)
aws s3 cp test.txt s3://$(terraform output -raw s3_bucket_name)/test.txt


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zliyk4zjtqmkcmszsncp.png)


# Check CloudWatch logs (wait 10 seconds)
sleep 10
aws logs tail /aws/lambda/terraform-lambda-s3-processor --since 2m

Expected log output:

Processing file: test.txt
Bucket: terraform-lambda-demo-2026
Size: 35 bytes
Event: ObjectCreated:Put
Result: {"status": "processed", "file": "test.txt", ...}

Test 3: Verify Non-.txt Files Don't Trigger

# Upload a .jpg - should NOT trigger Lambda
echo "not a text file" > test.jpg
aws s3 cp test.jpg s3://$(terraform output -raw s3_bucket_name)/test.jpg

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7a3sdyjpcrqhf1rnxej9.png)


# Check logs - no new entries
aws logs tail /aws/lambda/terraform-lambda-s3-processor --since 1m

Nothing. The .txt filter works.

🔍 Understanding the Cost

Lambda pricing:

First 1 million requests/month: FREE
After that: $0.20 per million requests
Compute: $0.0000166667 per GB-second

Our usage estimate:

API: 1,000 requests/day = 30,000/month → FREE
S3 processor: 100 files/day = 3,000/month → FREE

Compare to EC2:

Approach	Monthly Cost	Maintenance
EC2 t3.medium (24/7)	$30.37	Patch, monitor, scale
Lambda (30K requests)	$0.00	Zero maintenance

That's not a typo. For low-traffic workloads, Lambda is effectively free.

🐛 Troubleshooting

Issue 1: "Unable to import module 'hello'"

Error:

Runtime.ImportModuleError: Unable to import module 'hello': No module named 'hello'

Cause: Handler doesn't match filename. If your file is hello.py, handler must be hello.lambda_handler.

Fix: Verify handler in Terraform matches filename.function_name.

Issue 2: S3 Trigger Not Firing

Symptoms: Upload file, nothing in logs.

Check:

Is the file suffix .txt? Other files are filtered out.
Did the permission deploy before the notification? Check depends_on.
Check Lambda permission: aws lambda get-policy --function-name terraform-lambda-s3-processor

Issue 3: API Gateway Returns 500

Cause: Usually a Lambda execution error.

Debug:

# Check Lambda logs directly
aws logs tail /aws/lambda/terraform-lambda-hello --since 5m

# Test Lambda directly (bypass API Gateway)
aws lambda invoke \
  --function-name terraform-lambda-hello \
  --payload '{"queryStringParameters":{"name":"Test"}}' \
  response.json

cat response.json

Issue 4: "AccessDeniedException" on S3

Cause: IAM policy doesn't include the bucket or action needed.

Fix: Verify the custom policy references the correct bucket ARN with /* suffix for object-level actions.

💡 Best Practices

Set source_code_hash - Without it, Terraform won't redeploy when code changes.
Use archive_file data source - Let Terraform handle zipping. Manual zip files drift.
Set retention on log groups - Default is infinite. At $0.03/GB stored, this adds up.
Timeout appropriately - API handlers: 10-30s. Processing: 30-300s. Never use the 900s max unless you know why.
Memory = CPU - Lambda allocates CPU proportionally to memory. 128MB gets minimal CPU. 1024MB gets significantly more. If your function is slow, increase memory before optimizing code.
Environment variables for config - Never hardcode bucket names, table names, or URLs in your Lambda code. Pass them through environment variables in Terraform.

🧹 Cleanup

# Remove S3 objects first (bucket must be empty)
aws s3 rm s3://$(terraform output -raw s3_bucket_name) --recursive

# Destroy everything
terraform destroy

S3 buckets can't be deleted if they contain objects. Empty it first, then Terraform handles the rest.

✅ Summary

Today you learned:

✅ Deploy Lambda functions with Terraform
✅ Package Python code with archive_file
✅ Create API Gateway endpoints
✅ Trigger Lambda from S3 uploads
✅ Apply least-privilege IAM (Article 9 skills!)
✅ Manage CloudWatch logs with retention
✅ Test functions via API and S3

The serverless mindset: Stop paying for idle servers. Lambda runs your code only when needed, scales automatically, and costs nearly nothing for typical workloads.

🚀 What's Next?

In the next article, we'll add:

Terraform modules for reusability
Package your Lambda + API Gateway as a reusable module
Share infrastructure patterns across projects

Coming Up: Article 9: Secure Database Deployment: RDS + Secrets Manager with Terraform

📌 Wrapping Up

Thank you for reading. I hope this article provided practical insights and a clearer understanding of the topic.

If you found this useful:

❤️ Like if it added value
🦄 Unicorn if you’re applying it today
💾 Save it for your next optimization session
🔄 Share it with your team

💡 What’s Next

More deep dives are coming soon on:

Cloud Operations
GenAI & Agentic AI
DevOps Automation
Data & Platform Engineering

Follow along for weekly insights and hands-on guides.

🌐 Portfolio & Work

You can explore my full body of work, certifications, architecture projects, and technical articles here:

👉 Visit My Website

🛠️ Services I Offer

If you're looking for hands-on guidance or collaboration, I provide:

Cloud Architecture Consulting (AWS / Azure)
DevSecOps & Automation Design
FinOps Optimization Reviews
Technical Writing (Cloud, DevOps, GenAI)
Product & Architecture Reviews
Mentorship & 1:1 Technical Guidance

🤝 Let’s Connect

I’d love to hear your thoughts. Feel free to drop a comment or connect with me on:

🔗 LinkedIn

For collaborations, consulting, or technical discussions, reach out at:

📧 simplynadaf@gmail.com

Found this helpful? Share it with your team.

⭐ Star the repo • 📖 Follow the series • 💬 Ask questions

Made by Sarvar Nadaf

🌐 https://sarvarnadaf.com

Investigate and Clean Up Unused Cloud Resources

Noureldin ehab — Fri, 19 Jun 2026 12:05:58 +0000

Overview

By the end of this tutorial, you'll learn how to use Stakpak to investigate zombie resources in a live AWS production account, identify every detached volume, idle load balancer, orphaned snapshot, and forgotten instance silently accruing charges, apply the right cleanups safely, validate that production stays healthy throughout, and configure Stakpak Autopilot to help detect similar resource sprawl automatically in the future.

Note: Stakpak is open source, vendor neutral, and works with any model you choose.

Problem

AWS environments naturally accumulate unused resources over time: detached volumes, old snapshots, idle load balancers, unassociated Elastic IPs, and forgotten S3 buckets.

Finding them is easy. Determining whether they're safe to delete is not.

A resource may look unused, but it could still support a production workload, backup process, or undocumented dependency. Safely cleaning up cloud waste requires connecting usage, ownership, and activity data across your environment before taking action.

Application

Northstar Commerce is a B2B ecommerce platform running on AWS, with workloads spread across EKS, ECS Fargate, Lambda, and
Vercel. The main components are:

storefront: Customer facing Next.js app on Vercel.
api-gateway: Public REST and GraphQL edge on EKS.
orders-service: Order lifecycle, Go on EKS, backed by Aurora PostgreSQL.
payments-service: Java on ECS Fargate, integrates with Stripe.
Inventory-worker: Celery workers on EKS draining an SQS queue.
search-indexer: Rust Lambda keeping OpenSearch in sync.
admin-console: React SPA on S3 behind CloudFront.

Shared infrastructure includes an EKS cluster, an Aurora cluster, an ElastiCache Redis, an MSK cluster, an OpenSearch domain, ECR, Route 53, ACM, and Secrets Manager.

Primary region is us-east-1, with us-west-2 as a disaster recovery region.

Every workload in the catalog is healthy and serving traffic. None of the recent deploys touched infrastructure.

The application itself is well understood and accounted for, but the AWS account it runs in has accumulated years of side projects, migrations, and experiments that nobody has audited. Anything we find outside of this catalog is a candidate for cleanup, as long as we can prove it isn't quietly supporting one of these workloads.

Now that we understand the app and architecture, we can start investigating the account.

Step-by-Step Guide

Prerequisites

Troubleshooting

Open Stakpak and ask it to audit our AWS account for unused and zombie resources.

Now lets let it do its magic

Stakpak audited the AWS account for unused and zombie resources across compute, network, storage, IAM, data, and operational categories and found a small but real pool of recurring waste with no business value attached to any of it.

It identified ~$97/month of avoidable spend spread across 15 zombie resources in us-east-1, none tied to any active application. The signals came from EC2 state checks, EBS volume status, ELB target health, CloudWatch metrics for S3 and Lambda, IAM credential reports, and tag/name pattern analysis (*-OLD, -DEPRECATED, rakesh-test-, marketing-campaign-2022, loadtest-runner-2024-q1).

Then it:

Terminated the stopped loadtest-runner-2024-q1 EC2 instance, abandoned since the Q1 2024 load test campaign
Deleted five unattached EBS volumes totaling 371 GB, including a 200 GB elasticsearch-data-node-3 orphan from the search-v1 deprecation and a 100 GB northstar-mysql-data-OLD volume
Deregistered the northstar-golden-image-v2-DEPRECATED AMI and removed its backing snapshot
Released four unassociated Elastic IPs, including old-nat-gateway-eip from a decommissioned NAT and jenkins-static-ip from the Jenkins-to-GHA migration
Deleted two abandoned ALBs (northstar-internal-tools with an empty target group, and a canary ALB with all targets unhealthy) and the northstar-legacy-clb Classic ELB tied to the deprecated checkout-v1 project
Removed the unused openclaw-sg security group and its orphan openclaw-key key pair
Emptied and deleted six zombie S3 buckets including northstar-marketing-campaign-2022, rakesh-test-bucket (employee left), tempdata-export, and northstar-checkout-v1-logs
Cleaned up two empty CloudWatch log groups (/aws/lambda/feedbackboard-server, /aws/lambda/feedbackboard-warmer) left behind by deleted Lambda functions

After the changes were applied, Stakpak verified that:

All 15 zombie resources are gone
No surviving production resources (bastion, api-canary, staging-app, prod-invoices bucket) were impacted
us-west-2 remained clean (only the default VPC, no workloads)
Projected monthly waste dropped from ~$97/month to $0, a 100% reduction on identified zombies

Now everything is cleaned up 🥳

Now its asking us if we want to sit up Stakpak Autopilot to avoid having zombie resources

Note: Stakpak Autopilot monitors your apps 24/7, detects unexpected changes, fixes what’s safe, and only alerts you when it actually matters.

Monitoring

First, it asks us about how often we want to run the checks

Then it asks if we want Stakpak to take action

Then it asks about where we want to get alerted

And that's it

Extra Resources:

Related Use Cases

and more ...

References

De cero a la nube: cómo dockericé mi feed de AWS y lo desplegué en ECS

Carolina Herrera — Fri, 19 Jun 2026 02:08:33 +0000

Hace unas semanas me cansé de entrar manualmente a la página de AWS What's New para ver qué habían lanzado. Así que hice lo que cualquier persona razonable haría: construí una app, la metí en Docker y la subí a ECS. En este artículo te cuento exactamente cómo, con todos los comandos y sin saltarme pasos.

¿Qué vamos a construir?

Una pequeña app web en Python (Flask) que consume el RSS público de AWS y muestra las últimas novedades clasificadas por categoría (AI/ML, Seguridad, Data, FinOps, CloudOps). Tiene modo oscuro y claro, animaciones de entrada y muestra hace cuánto tiempo se publicó cada novedad.

El flujo completo es:

Código local  →  Docker image  →  Amazon ECR  →  Amazon ECS (Fargate)  →  URL pública

Repositorio: github.com/carotechie/docker-ecs-feedaws

Lo que necesitas antes de empezar

Docker Desktop instalado y corriendo
AWS CLI configurada (aws configure)
Una cuenta de AWS con permisos para ECR y ECS
Python 3.12+ (solo para desarrollo local)

1. La app: Flask + feedparser

El código principal es minimalista. app.py hace tres cosas: consume el RSS de AWS, limpia el HTML que viene en los summaries y detecta la categoría de cada novedad según sus palabras clave.

# app.py (fragmento)
AWS_RSS_URL = "https://aws.amazon.com/about-aws/whats-new/recent/feed/"

@app.route("/")
def index():
    feed = feedparser.parse(AWS_RSS_URL)
    # ...procesa y clasifica cada entrada
    return render_template("index.html", items=items, fetched_at=fetched_at)

No hay base de datos, no hay caché. Cada vez que alguien entra a la URL, la app hace un request al RSS de AWS en ese instante. Simple y siempre actualizado.

Las dependencias van en requirements.txt:

flask==3.1.1
feedparser==6.0.11
gunicorn==23.0.0

2. El Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "app:app"]

Nada del otro mundo. Usamos python:3.12-slim para mantener la imagen liviana y gunicorn como servidor WSGI (más robusto que el servidor de desarrollo de Flask para producción).

Un detalle importante: copiamos requirements.txt antes que el resto del código. Esto aprovecha el caché de capas de Docker — si no cambias las dependencias, Docker reutiliza esa capa y el build es mucho más rápido.

3. Probar localmente

# Construir la imagen
docker build -t mifeed-aws .

# Correr el contenedor
docker run -d -p 8080:8080 --name mifeed mifeed-aws

# Verificar que levantó
curl http://localhost:8080/health
# → {"status": "ok"}

Abre http://localhost:8080 en tu navegador y deberías ver algo así:

Para detenerlo:

docker stop mifeed && docker rm mifeed

4. Subir la imagen a Amazon ECR

Amazon ECR (Elastic Container Registry) es el registro privado de imágenes Docker de AWS. Piénsalo como un Docker Hub pero dentro de tu cuenta de AWS.

4.1 Crear el repositorio en ECR

aws ecr create-repository \
  --repository-name demos/mifeed-aws \
  --region us-east-1

El comando devuelve un JSON. Copia el valor de repositoryUri, lo vas a necesitar. Se ve así:

url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws

4.2 Autenticarte con ECR

aws ecr get-login-password --region us-east-1 \
  | docker login \
    --username AWS \
    --password-stdin \
    url.dkr.ecr.us-east-1.amazonaws.com

Si ves Login Succeeded, estás lista para el siguiente paso.

4.3 Etiquetar y subir la imagen

ECR_URI=url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws

# Etiquetar la imagen local con el URI de ECR
docker tag mifeed-aws:latest $ECR_URI:latest

# Subir al registro
docker push $ECR_URI:latest

El push puede tardar unos minutos la primera vez. Verás las capas subiendo una por una.

5. Configurar y desplegar en Amazon ECS

ECS (Elastic Container Service) es el servicio administrado de AWS para correr contenedores. Usaremos Fargate, que es el modo serverless: no tienes que gestionar servidores ni instancias EC2.

El flujo en ECS tiene tres piezas:

Task Definition  →  Cluster  →  Service
(qué correr)        (dónde)     (cuántas copias y cómo)

5.1 Crear el Cluster

Ve a la consola de AWS → ECS → Clusters → Create Cluster.

Configuración:

Cluster name: mifeed-aws
Infrastructure: AWS Fargate (serverless)
Deja el resto por defecto y haz clic en Create

5.2 Crear la Task Definition

La Task Definition le dice a ECS qué imagen correr, cuánta CPU/memoria usar y en qué puerto escucha.

Ve a Task Definitions → Create new task definition.

Configuración:

Task definition family: mifeed-aws
Launch type: AWS Fargate
CPU: 0.25 vCPU
Memory: 0.5 GB
Container name: mifeed-aws
Image URI: url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws:latest
Container port: 8080
Protocol: TCP

Haz clic en Create.

5.3 Crear el Service

El Service mantiene corriendo el número de Tasks que definas y las reinicia si fallan.

En tu cluster mifeed-aws → pestaña Services → Create.

Configuración:

Family: mifeed-aws
Service name: mifeed-service
Desired tasks: 1
Launch type: Fargate
VPC: la VPC por defecto está bien para empezar
Subnets: selecciona al menos 2 subnets públicas
Security group: crea uno nuevo (o usa uno existente) con la siguiente regla de entrada:

Tipo	Puerto	Origen
Custom TCP	8080	0.0.0.0/0

Public IP: Enabled ← importante, sin esto no tendrás IP pública

Haz clic en Create Service y espera unos minutos a que el Task pase a estado RUNNING.

6. Conectarme a mi aplicación

Una vez que el Task está en RUNNING, la app ya está viva en internet.

Obtener la IP pública

En la consola: Clusters → mifeed-aws → Tasks → clic en el Task ID → busca la sección Network → copia la Public IP.

Abre en tu navegador:

http://<PUBLIC_IP>:8080

Y deberías ver tu feed funcionando en la nube:

Verificar el health check

curl http://<PUBLIC_IP>:8080/health
# → {"status": "ok"}

¿Y las actualizaciones automáticas?

La app no necesita ninguna configuración especial. Como el feed se parsea en cada request, cada vez que alguien carga la página obtiene los datos más recientes de AWS. El contenedor puede estar corriendo semanas sin ningún reinicio y el feed siempre estará actualizado.

Si quieres que ECS descargue automáticamente una nueva versión de tu imagen cuando hagas cambios:

Sube la nueva imagen a ECR con el mismo tag latest
En ECS → tu Service → Update service → activa Force new deployment
ECS descargará la nueva imagen y reemplazará el Task sin downtime

Reflexión final

Lo que me gustó de este ejercicio fue lo poco que tuve que tocar para pasar de "corre en mi máquina" a "corre en la nube":

El Dockerfile no cambió
La app no sabe si está en local o en ECS
La única diferencia real es de dónde viene la imagen (local vs ECR)

Eso es exactamente lo que hace valioso a Docker en un contexto de nube. El artefacto que pruebas localmente es el mismo artefacto que corre en producción.

Próximos pasos

Si quisieras llevar esto a producción real, los siguientes pasos serían:

Agregar un Load Balancer (ALB) para tener una URL fija en vez de una IP efímera
Dominio propio con Route 53 y un certificado SSL en ACM
CI/CD con GitHub Actions para que cada push a main actualice la imagen en ECR y fuerce un nuevo deploy en ECS
Auto Scaling para que el servicio escale según la carga

S3 annotations and the question of where object metadata should live

Kento IKEDA — Thu, 18 Jun 2026 23:59:16 +0000

On June 17, 2026, AWS Summit New York ran a long line of announcements that filled in the infrastructure for running agents in production. The official blog has the full roundup.

https://aws.amazon.com/blogs/aws/top-announcements-of-the-aws-summit-in-new-york-2026/

One of them reads as plain from the headline alone: S3 annotations. You can attach up to 1 GB of information directly to an object, so the first impression is "tags just got bigger."

Reading it as a capacity story misses the point. This changes a decision: where the information attached to an S3 object should live. For a long time, the answer was usually "outside the object." You kept it in an external database or a sidecar file and reconciled the two with a sync process. S3 annotations add another option to that answer: don't move it out. If you have kept data in S3 while managing its metadata off to the side, you know the cost of keeping the two in sync.

The official announcement is here:
https://aws.amazon.com/blogs/aws/amazon-s3-annotations-attach-rich-queryable-context-directly-to-your-objects/

The difference is character, not capacity

Line up annotations against the existing ways to describe an object, and what matters is the difference in character, not the numbers.

Mechanism	How much	Mutable	Character
System-defined metadata	Fixed fields	No	Intrinsic properties of the object
User-defined metadata	2 KB total, set at upload	Effectively no	Small incidental notes
Object tags	Up to 10	Yes	Labels for access control and lifecycle
annotations	Up to 1,000, 1 GB total	Yes, without rewriting	Structured knowledge that grows over time

The counts and sizes come from the official blog. The clear gap is in the bottom two rows. Tags are key-and-value labels, meant for access control and cost allocation. annotations carry structure in JSON or YAML, and you can rewrite them as often as you like without rewriting the object. They travel with the object on copy and replication, and they are removed when the object is deleted.

A different character means a different job. Tags describe how to handle an object. annotations hold what the object is and what is known about it, the kind of knowledge that accumulates after the fact: an AI-generated summary, an inference confidence score, processing history. That information does not fit in 2 KB, and you want to update it as the data changes. Until now, meeting that requirement meant moving the context outside the object.

What AWS says, and one step past it

The official blog describes annotations as removing the need for a separate metadata system. It is true that the pattern of double-writing to DynamoDB for cross-object search, syncing with Lambda, and watching for drift can be retired for some use cases. The annotations you attach flow through S3 Metadata into Apache Iceberg tables and become queryable from Amazon Athena.

But stopping at "you no longer need an external database" only repeats what AWS already said. The part worth pressing on is what else moves along with the location. When the context lived outside the object, who could touch it was decided directly by the access control on that external database. Once it sits on the object, you have to redesign who is allowed to change which context. Adding and reading annotations requires the IAM actions s3:PutObjectAnnotation and s3:GetObjectAnnotation. Coupling context tightly to data is the benefit. It also means tampering with the context turns directly into a misreading of the data.

The other thing that moves is responsibility for structure. Key-and-value tags left almost no room for design, but being able to hold structure means you have to decide which key represents what and at what granularity to split things. If an agent is meant to read it, that decision drives search quality. Dump everything in, and you end up with annotations that are useless in a later cross-object query. The freedom of capacity arrives bundled with the responsibility of design.

How much of your sync layer can you actually retire

"Then move everything to annotations" does not follow. There is a line on what you can move over.

In a verification by Classmethod, the Annotation Table took about 25 minutes to become active even in a small environment. That is a third-party measurement, but it lines up with the spec: reflection into the table is asynchronous. What you attach is not reflected into cross-object search the instant you write it.
https://dev.classmethod.jp/articles/s3-annotations-crud-athena-search/

The plain conclusion is about fit with low-latency reads. Information you want to pull in milliseconds on every screen render, or that needs a secondary-index lookup, still fits the older DynamoDB design better. Context that gets updated later but does not need immediacy, such as compliance status, history, or summaries, leans toward annotations. What you retire is part of the sync layer, not all of it.

Cost does not move in one direction either. You can let go of the sync layer that watches for drift, but storing and reading annotations is billed at the same rates as S3 Standard storage and requests, and the S3 Metadata and Annotation Tables behind cross-object search carry their own processing and storage charges. You weigh the cost you remove against the cost you add. The pricing page has the breakdown.
https://aws.amazon.com/s3/pricing/

Region coverage differs too. Per the official blog, attaching an annotation works in nearly all Regions, while the Annotation Table used for cross-object search is limited to Regions where S3 Metadata is available. S3 Metadata coverage has been expanding in waves.
https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-metadata-expands-22-regions/

Coverage and per-feature availability change, so the documentation is the reliable place to check the current state.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/annotations-overview.html

Is an agent a precondition

annotations are designed for agents, and the official explanation is written with that in mind. It is tempting to read "I don't run AI agents, so this isn't for me" and skip the rest, but hold off for a moment.

Agents or not, if you operate sidecar files or an external metadata database today, the shift in location is where the benefit shows up. What annotations really are is an improvement to metadata management itself: structured context attached close to the object, queryable across objects. Natural-language search can be added later through the S3 Tables MCP server, so retiring the sync layer first is a fine way in. The agent is a possible first reader of the context you place, not a precondition.

From object-level to organization-level context

Widen the view, and annotations look less like a standalone feature and more like part of a movement. At the same Summit, AWS previewed AWS Context, which maps the data relationships across an organization into a knowledge graph. Its availability is stated as forthcoming.
https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/

If S3 annotations are context at the object level, AWS Context is context at the organization level. Both are designed to surface in Apache Iceberg format in S3, so they read as continuous. The movement is from each team holding its own context for RAG toward a shared context layer with managed access for the whole organization. annotations cover the lowest layer of that, the part where context is attached close to the object.

Where to start

The first step is an inventory of the context you currently hold in external databases or sidecars. Pull out the context described above, the kind that gets updated later but does not need immediacy, and make it a candidate for annotations. For schema, deciding a handful of keys you want an agent to read on a single bucket is enough to begin. As long as you hold the premise that responsibility for structure is now yours, you lower the odds of getting stuck in a later cross-object query.

For a long time, keeping context outside the object was simply the premise. There is meaning in being able to question that premise at all. This is not a story about more capacity. It is a story about who is responsible for the context, and that answer has come back to the side of the object.

Investigate Why AWS Costs Suddenly Increased

Noureldin ehab — Thu, 18 Jun 2026 12:56:43 +0000

Overview

By the end of this tutorial, you'll learn how to use Stakpak to investigate zombie resources in a live AWS production account, identify every detached volume, idle load balancer, orphaned snapshot, and forgotten instance silently accruing
charges, apply the right cleanups safely, validate that production stays healthy throughout, and configure Stakpak Autopilot to help detect similar resource sprawl automatically in the future.

Note: Stakpak is open source and works with any model you choose.

Problem

Your AWS production application is healthy. The pipeline is green, the SLOs are green, the on call channel is quiet.

But your FinOps lead just pinged the team:

We're $4,300 over budget this month and trending 35% above last. Nothing in the apps catalog has changed.

You start the usual cost investigation loop, Cost Explorer by service and by tag, VPCs and NAT Gateways, unattached EBS volumes, stale snapshots, idle Elastic IPs, VPC endpoints, RDS instances, CloudWatch log retention, S3 lifecycle policies, CloudTrail events.

Cost Explorer shows the highest cost is from EC2, Other, EKS, and CloudWatch. The rest is scattered across eight services in chunks too small to feel urgent on their own. Tag breakdowns are messy because half the spend rolls up under (no tag) or Owner=unknown, and the biggest single CUR line item is a Fargate workload nobody on the current team recognizes.

Is the $890 NAT Gateway data line the orphaned VPC nobody decommissioned, or production traffic that should be flowing through a VPC endpoint?
Are the 1,400+ EBS snapshots load-bearing, or from a Lambda deprecated 18 months ago and never disabled?
Is the RDS instance tagged Environment=staging-old truly idle, or does some nightly job still touch it?
Which of the 12 likely cost drivers, if any, would be the wrong thing to delete?

Cost Explorer gives you part of the picture. AWS resource APIs give you the rest. But you still have to connect them, attribute them to owners, correlate them with utilization, and decide what is safe to remediate.

Application

Northstar Commerce is a B2B ecommerce platform running on AWS, with workloads spread across EKS, ECS Fargate, Lambda, and Vercel. The main components are:

storefront: Customer facing Next.js app on Vercel.
api-gateway: Public REST and GraphQL edge on EKS
orders-service: Order lifecycle, Go on EKS, backed by Aurora PostgreSQL.
payments-service: Java on ECS Fargate, integrates with Stripe.
inventory-worker: Celery workers on EKS draining an SQS queue.
search-indexer: Rust Lambda keeping OpenSearch in sync.
admin-console: React SPA on S3 behind CloudFront.

Shared infrastructure includes an EKS cluster, an Aurora cluster, an ElastiCache Redis, an MSK cluster, an OpenSearch domain, ECR, Route 53, ACM, and Secrets Manager.

Primary region is us-east-1, with us-west-2 as a disaster recovery region.

Every workload in the catalog is healthy and serving traffic. None of the recent deploys touched infrastructure. Which is what makes a 35% cost jump suspicious: the bill is growing faster than the application is.

Now that we understand the app and architecture, we can start investigating the cost spike.

Step-by-Step Guide

Prerequisites

Troubleshooting

Open Stakpak and ask it to investigate the cloud cost spike

Now lets let it do its magic

Stakpak traced the cost spike across billing, utilization, and infrastructure signals and identified multiple sources of unnecessary spend driving the 35% increase.

It found that the $4,270 June overage came from 12 distinct cost drivers totaling ~$6,800/month of avoidable spend, none caused by application changes. The signals were spread across Cost Explorer deltas, tag anomalies (staging-old +5,854%, intern-summer-2025 +9,677%), CUR line items, CloudWatch utilization, and CloudTrail provenance.

Then it:

Deleted the orphaned legacy VPC and its NAT Gateway, abandoned since the 2024 EKS migration
Terminated three m5.2xlarge legacy batch workers idling at 2% CPU
Deleted the forgotten eks-dev-intern cluster and its Fargate Spot profile, running since July 2025
Deleted the staging-old RDS instance after 30 days of zero connections
Removed five unattached EBS volumes, three idle Elastic IPs, and 1,400+ stale snapshots from a deprecated 2023 backup Lambda
Disabled GuardDuty in eu-west-1 and ap-southeast-1 where no workloads exist
Added an S3 Gateway VPC endpoint to the production VPC, eliminating $890/month of NAT data processing
Applied lifecycle rules to northstar-prod-edge-logs and 30-day retention to three "Never expire" log groups
Fixed cross-AZ traffic on orders-service
Deployed AWS Budgets with anomaly detection, tag-enforcement SCPs, and Config rules

After the changes were applied, Stakpak verified that:

All 12 driver resources are gone or reconfigured
Every production workload remained healthy with no SLO regressions
Projected run-rate dropped to ~$9,600/month, below the January baseline

Now everything is cleaned up 🥳

Now its asking us if we want to sit up stakpak Autopilot to avoid future cost spikes

Note: Stakpak Autopilot monitors your apps 24/7, detects unexpected changes, fixes what’s safe, and only alerts you when it actually matters.

Monitoring

Extra Resources:

Related Use Cases

References

Kiro V1.0.0 is out: migrate your hooks!

Davide De Sio — Thu, 18 Jun 2026 09:44:45 +0000

Kiro 1.0 is now publicly available and ready to use!

Fortunately, KiroGraph, my code intelligence graph for Kiro, relies heavily on Kiro's lifecycle components, making it a great real-world test case to verify whether all the features we loved during the beta are still working as expected.

davide-desio-eleva / kirograph

Semantic code knowledge graph for Kiro: fewer tool calls, instant symbol lookups, 100% local.

KiroGraph

Semantic code knowledge graph for Kiro: fewer tool calls, instant symbol lookups, 100% local.

Inspired by CodeGraph by colbymchenry for Claude Code, rebuilt natively for Kiro's MCP and hooks system.

Full support is for Kiro only. Experimental integrations for 34 other MCP-capable tools (Cursor, Copilot, Claude Code, Windsurf, Cline, and more) are available with auto-detection. See Integrations for the full list.

Why KiroGraph?

When you ask Kiro to work on a complex task, it explores your codebase using file reads, grep, and glob searches. Every one of those is a tool call, and tool calls consume context and slow things down.

KiroGraph gives Kiro a semantic knowledge graph that's pre-indexed and always up to date. Instead of scanning files to understand your code, Kiro queries the graph instantly: symbol relationships, call graphs, type hierarchies, impact radius, all in a single MCP tool call.

The result is fewer tool…

View on GitHub

Good News

Let's start with what didn't change:

Steering and Skills (using the SKILL.md format) continue to work exactly as before, with the same structure and frontmatter.
All MCP servers, both project-level and global, are automatically connected and immediately available after the upgrade.

So far, so good.

What's changed

Now for the interesting part.

Many of us have learned to love Kiro Hooks because they allow us to customize development workflows and lifecycle events.

For example, KiroGraph uses a hook to automatically synchronize the code graph at agent stop whenever files are modified.

If you open an existing project that still uses legacy hooks, you'll immediately notice that they're marked as V1 and inactive.

At first glance, this looks alarming.

Kiro migration pop up

The good news is that Kiro can actually help you migrate your hooks.

If you restart Kiro you'll probably see this migration popup which will assist you in a complete migration

Kiro will confirm the migration.

Be aware:

you'll still have older version, delete them
new version won't be active, you should activate them one by one

If the popup doesn't appear

This has happened to me in multiple projects, and I’ve also seen it affect other users working with KiroGraph or older hook formats: the expected popup doesn’t appear.

An IDE restart might be sufficient, but in some cases a fresh installation can help as well.

However, if you’re using a tool like KiroGraph or a CLI that generates hooks in the older format, you won’t see this popup.

Don’t worry: although the hook schema has changed and older hooks are no longer active, Kiro still understands both formats and can automatically generate the updated configuration for you.

In my case, the entire migration was completed with a single prompt.

The Prompt

Analyze the `.kiro/hooks` directory and identify all existing Kiro Hooks. These hooks use V1 format and are no longer active in the latest Kiro IDE V1.0.0.

Your tasks is:

1. Determine the differences between the legacy V1 hook format and the current hook format supported by Kiro IDE.
2. Migrate all existing V1 hooks to the new format.
3. Verify that the generated hooks are recognized and executed by the current Kiro IDE.

Kiro's Response

Now let me find where these hooks are. 
Now I have full understanding of the v1 format. 
Now I need to map the v1 triggers/actions to v2 format:

| v1 `when.type` | v2 `trigger` |
|---|---|
| `agentStop` | `Stop` |
| `preToolUse` | `PreToolUse` |

| v1 `then.type` | v2 `action.type` |
|---|---|
| `runCommand` | `command` |
| `askAgent` | `agent` |

| v1 `when.toolTypes: ["shell"]` | v2 `matcher` regex for shell tools |

Now write the new v2 hook files. 
All done. 
Here's what changed:

**`.kiro/hooks/`** — Replaced all 6 `.kiro.hook` files with their `.json` v2 equivalents.

After analyzing the existing hooks, Kiro identified the required mappings:

Legacy Format	New Format
`agentStop`	`Stop`
`preToolUse`	`PreToolUse`
`runCommand`	`command`
`askAgent`	`agent`

It then:

Migrated all existing .kiro.hook files to the new JSON format.
Verified that all migrated hooks were correctly recognized by Kiro IDE.

Before: old hooks format output

{
  "name": "KiroGraph Sync on Agent Stop",
  "version": "1.0.0",
  "description": "Sync the KiroGraph index when the agent stops, picking up any file edits, creates, or deletes from the session.",
  "when": {
    "type": "agentStop"
  },
  "then": {
    "type": "runCommand",
    "command": "kirograph sync --quiet 2>&1 > /dev/null"
  }
}

After: new hooks format output

{
  "version": "v1",
  "hooks": [
    {
      "name": "KiroGraph Sync on Agent Stop",
      "trigger": "Stop",
      "action": {
        "type": "command",
        "command": "kirograph sync --quiet 2>&1 > /dev/null"
      }
    }
  ]
}

KiroGraph

Maintainers of tools like KiroGraph, which automatically configure hooks for you, will likely update their installers and scripts.

KiroGraph is ready for Kiro v1.0.0 and ensures backward compatibility for users still on the beta version.

Just update it to v0.26.0

Final Thoughts

If you've been holding off on upgrading because you're worried about breaking your custom workflows, don't panic.

Steering, Skills, and MCP integrations continue to work seamlessly, and even hook migrations can be largely automated by Kiro itself.

Sometimes the best tool to fix a breaking change is the tool that introduced it.

🙋 Who am I

I'm D. De Sio and I work as a Head of Software Engineering in Eleva.
As of June 2026, I’m an AWS Certified Solution Architect Professional and AWS Certified DevOps Engineer Professional, but also a User Group Leader (in Pavia), an AWS Community Builder and, last but not least, a #serverless enthusiast.

Google Open Knowledge Format: Why Enterprise Agents Need a Knowledge Layer, Not Just More Tools

Amit Kayal — Thu, 18 Jun 2026 06:41:06 +0000

Google Open Knowledge Format: Why Enterprise Agents Need a Knowledge Layer, Not Just More Tools

Most enterprise AI conversations still start in the wrong place.

They start with the model.

Which model should we use? Which framework should we adopt? Which vendor has the best agent platform? Which tools should we connect next?

These are fair questions. But in real enterprise architecture, they are not the hardest questions.

The harder question is this:

Can our AI systems actually understand how our business works?

That is why Google Cloud’s article on Open Knowledge Format caught my attention. The article talks about a simple but important idea: representing knowledge in a way that humans can read and machines can use. In OKF, that means markdown for the content and structured metadata for context.

At first glance, that may sound too simple.

But that simplicity is the point.

Enterprises do not need another place where knowledge goes to die. We already have enough portals, catalogs, wikis, dashboards, folders, and internal tools. What we need is a practical way to package knowledge so it can be reviewed, versioned, governed, searched, and reused by both people and AI agents.

That is where this idea becomes very relevant for agentic AI.

The Real Enterprise AI Problem

Most organizations already have the knowledge their AI agents need.

They have it in databases, dashboards, tickets, architecture notes, runbooks, Confluence pages, data catalogs, code comments, incident reports, old project documents, and the heads of experienced employees.

The issue is not that knowledge does not exist.

The issue is that it is fragmented.

Some of it is outdated. Some of it is duplicated. Some of it is tribal. Some of it is locked inside tools. Some of it is written for humans but not structured enough for AI systems to use reliably.

This becomes a serious problem when we move from AI assistants to AI agents.

An assistant can give a helpful answer. An agent does more. It plans, selects tools, queries systems, executes steps, generates outputs, and sometimes triggers workflows.

That means the cost of wrong context is much higher.

A data agent may know how to generate SQL. But does it know which table is the source of truth?

A finance agent may calculate revenue. But does it know whether the business means booked revenue, invoiced revenue, recognized revenue, or collected cash?

A support agent may summarize a customer case. But does it know what customer information must be masked before anything is shared externally?

A delivery agent may review project status. But does it understand governance rules, escalation paths, release gates, and dependency risks?

A cloud cost agent may recommend savings. But does it know which environments are production-critical and which ones are safe to shut down?

Without this context, agents do not become enterprise-ready. They become fast, confident, and risky.

More Tools Will Not Solve This

One common mistake in agentic AI is assuming that more tool access means better capability.

Connect the database.
Connect the CRM.
Connect the ticketing system.
Connect the cloud APIs.
Connect the document repository.
Connect the workflow engine.

This improves reach, but not necessarily judgment.

An agent with many tools and weak context can still choose the wrong source, apply the wrong rule, query the wrong table, expose the wrong field, or automate the wrong step.

That is why I believe every serious enterprise agentic AI framework needs three layers:

A reasoning layer
A tool/action layer
A governed knowledge layer

Most teams are investing heavily in the first two. They are testing models, orchestration frameworks, prompts, tools, APIs, and agent workflows.

That work is needed.

But the third layer is where enterprise differentiation will come from.

The model can be changed.

The tools can be integrated.

But the organization’s internal knowledge — its definitions, operating rules, business logic, exceptions, ownership, architecture, and lessons learned — is unique.

That is the real asset.

What Google Open Knowledge Format Gets Right

What I like about the Open Knowledge Format idea is that it does not overcomplicate the problem.

It treats knowledge as something that should be readable, portable, structured, and maintainable.

Markdown makes it easy for humans to read and contribute. Structured metadata makes it easier for systems and agents to classify, retrieve, and use the knowledge. Version control makes review and audit possible.

This matters because traditional documentation is passive.

Someone writes it. Someone may read it. Eventually, it becomes stale.

Agentic AI needs active knowledge.

The knowledge has to be available at runtime. It should help the agent decide what to do, what not to do, which source to trust, which rule to apply, and when to escalate.

A database schema may say that a table has a column called segment.

That is useful, but not enough.

The agent also needs to know:

What does segment mean?
Who owns the definition?
Which values are valid?
Is the field reliable?
Can it be used for reporting?
Can it be exposed externally?
Are there legacy exceptions?
Which workflows are allowed to use it?

This is the gap between data access and enterprise intelligence.

How This Fits into an Agentic AI Framework

In our agentic AI framework, I would treat an OKF-like structure as the Enterprise Knowledge Layer.

This layer should sit between enterprise systems and agent execution.

The agent should not jump directly from a user request to a tool call. That is where many mistakes happen.

A better flow is:

User request
   ↓
Agent identifies intent and domain
   ↓
Agent retrieves relevant knowledge
   ↓
Agent checks source of truth, ownership, caveats, access rules, and usage guidance
   ↓
Agent plans the action
   ↓
Agent calls the right tool
   ↓
Agent produces the answer or executes the workflow
   ↓
Agent proposes a knowledge update if reusable learning is found

This changes the quality of execution.

Take a simple question:

“Show me revenue by customer segment.”

A weak agent will search for tables with names like revenue, customer, and segment, then generate SQL.

A stronger enterprise agent will first check the knowledge layer:

Which revenue table is approved?
Which revenue definition applies?
Which customer segment field is trusted?
Which join is valid?
Which date logic should be used?
Are there caveats for legacy accounts?
Is the user allowed to see this output?

Only after that should it query the database.

That is the difference between automation and governed intelligence.

Generating Open Knowledge Format from AWS SQL Databases

For AWS SQL environments such as Amazon RDS, Aurora, and Redshift, the starting point is metadata extraction.

We can automatically extract:

Database names
Schema names
Table names
Column names
Data types
Primary keys
Foreign keys
Indexes
Nullability
Row counts
Table comments
Column comments
AWS tags
Freshness indicators
Query usage patterns

AWS Glue Crawlers and the Glue Data Catalog can help discover and centralize metadata. Database-native sources like information_schema can provide table and column-level structure.

But metadata is not knowledge.

A pipeline can discover that a table has a column called revenue_amount. It cannot automatically know whether that means booked revenue, recognized revenue, invoiced revenue, or pipeline value. That meaning has to come from finance, sales operations, data owners, or approved documentation.

So OKF generation should be semi-automated.

Technical metadata should be generated automatically. Business meaning should be reviewed and approved by the right domain owners.

For every critical SQL table, the knowledge file should capture:

Business purpose
Source system
Source-of-truth status
Data owner
Data steward
Refresh frequency
Key columns
Approved joins
Common usage patterns
Prohibited usage
Data quality rules
Sensitivity classification
Agent usage guidance
Known caveats

A table-level knowledge file should not simply describe the table. It should tell an agent how to use that table safely.

Example:

---
id: sales.crm.customer_account
kind: table
system: aurora-postgresql
cloud: aws
database: crm_prod
schema: sales
table: customer_account
domain: sales
owner: revenue-operations
steward: data-platform-team
environment: production
classification: confidential
pii: true
freshness_sla: "15 minutes"
source_system: salesforce
agent_usage: allowed_with_row_level_controls
approval_status: approved
---

# customer_account

## Business Meaning

This table represents customer account records synchronized from Salesforce into the CRM production database.

It is the approved source for account ownership, account segment, customer lifecycle stage, and sales territory mapping.

## Agent Usage Guidance

Use this table for customer account analysis, sales ownership, account segmentation, and lifecycle stage reporting.

Do not use this table for audited revenue reporting, invoice reconciliation, or financial close reporting.

For revenue reporting, use the approved finance revenue table.

## Important Caveats

Some legacy accounts may have missing segment values. Agents must not infer missing segment values without confirmation.

This table contains confidential customer information. Agents must apply row-level access controls and masking rules where applicable.

This is much more useful than a raw schema.

The schema tells the agent what exists.

The knowledge file tells the agent how to use it.

Generating Open Knowledge Format from AWS NoSQL Databases

NoSQL systems need even more care.

In DynamoDB, the table name and attributes rarely tell the full story. The real design is usually in the access patterns.

A DynamoDB table may store multiple entity types. It may use composite keys. It may depend on global secondary indexes. It may be optimized for specific queries and unsuitable for others.

If an agent does not understand this, it can misuse the table, trigger inefficient scans, produce incomplete answers, or misunderstand the business process.

For DynamoDB, the knowledge file should capture:

Table purpose
Partition key
Sort key
Item types
Common item shapes
Global secondary indexes
Local secondary indexes
Streams
TTL rules
Primary access patterns
Anti-patterns
Sensitive attributes
Agent permissions
Operational caveats

The most important part is access pattern documentation.

For example:

Access pattern 1:
Get all events for an order
PK = order_id
SK = event_timestamp

Access pattern 2:
Get latest order status
PK = order_id
Sort descending by event_timestamp
Limit = 1

Access pattern 3:
Investigate failed payment events
Use event_type index if available

This tells the agent how the table is actually meant to be used.

Example:

---
id: commerce.dynamodb.order_events
kind: nosql_table
system: dynamodb
cloud: aws
table: order_events
domain: commerce
owner: order-platform-team
environment: production
partition_key: order_id
sort_key: event_timestamp
billing_mode: PAY_PER_REQUEST
stream_enabled: true
classification: confidential
pii: false
agent_usage: allowed_read_only
approval_status: approved
---

# order_events

## Business Meaning

This table stores the event history of customer orders.

Each item represents an event in the order lifecycle, such as order created, payment completed, shipment initiated, shipment delivered, cancellation requested, or refund completed.

## Primary Access Pattern

Retrieve the event timeline for a specific order.

PK = order_id  
SK = event_timestamp

## Agent Usage Guidance

Agents should use this table to reconstruct order history, check operational status, and investigate order workflow issues.

Agents should not use this table as the financial source of truth for revenue, refunds, or payment settlement.

## Caveats

This table is append-only.

The latest operational event should not be treated as financial completion. For accounting status, agents must check the finance ledger.

This prevents an agent from treating NoSQL like a normal relational model.

Generating Knowledge from Document Databases

For document databases such as Amazon DocumentDB or MongoDB-compatible systems, the main challenge is flexible structure and nested sensitive data.

A support case document may contain customer messages. A customer profile may contain personal data. A workflow document may include internal comments, commercial terms, or escalation notes.

Agents need clear rules before reading, summarizing, or exposing this type of content.

For document collections, the knowledge file should capture:

Collection purpose
Common document structure
Required fields
Optional fields
Nested arrays
Indexes
Query patterns
Sensitive fields
Masking rules
Retention rules
Allowed agent use cases
Prohibited use cases

Example:

---
id: support.documentdb.customer_cases
kind: document_collection
system: documentdb
cloud: aws
database: support_prod
collection: customer_cases
domain: customer-support
owner: support-platform-team
environment: production
classification: restricted
pii: true
agent_usage: allowed_with_masking
approval_status: approved
---

# customer_cases

## Business Meaning

This collection stores customer support cases raised through web, email, account manager, and internal escalation channels.

It is used to view case history, identify recurring issues, and prepare escalation summaries.

## Agent Usage Guidance

Agents can use this collection for internal case summaries, issue classification, support briefings, and next-action recommendations.

Agents must not expose raw customer messages externally without masking sensitive information.

## Sensitive Fields

- customer_email
- phone_number
- messages.message
- account_id
- internal_notes

## Caveats

Free-text messages may contain sensitive personal or commercial information. Agents should summarize the issue and intent rather than copying raw text.

This is not just documentation. It is a guardrail.

The AWS Pipeline I Would Build

I would not make this a manual documentation exercise.

That will not scale.

I would build a pipeline that generates draft knowledge files automatically, then routes critical content for human review.

A practical AWS-based pipeline would look like this:

AWS data sources
   ↓
Metadata extraction
   ↓
Profiling and classification
   ↓
Business enrichment
   ↓
OKF draft generation
   ↓
Human review and approval
   ↓
Git-based version control
   ↓
Indexing into agent knowledge retrieval
   ↓
Agent execution
   ↓
Feedback loop

The extraction layer would pull from:

AWS Glue Data Catalog
RDS and Aurora metadata
Redshift catalog tables
DynamoDB DescribeTable
DynamoDB exports to S3
DocumentDB collection profiling
AWS tags
CloudWatch metrics
IAM and Lake Formation policies
Existing documentation and runbooks

The enrichment layer would add:

Business definitions
Source-of-truth mapping
Ownership
Usage guidance
Sensitivity classification
Approved joins
Known caveats
Agent-specific instructions

The governance layer would make sure the knowledge is trusted before agents rely on it.

This is important.

If we automate everything without review, we risk creating wrong knowledge at scale.

If we manually write everything, we will never scale.

The practical answer is auto-generation with human governance.

Governance Is Not Optional

Enterprise agents need trust boundaries.

Every knowledge file should have ownership and lifecycle metadata.

At minimum:

owner: finance-operations
steward: data-platform-team
classification: confidential
approval_status: approved
agent_usage: allowed_internal_only
last_reviewed_at: "2026-06-18"
next_review_due: "2026-09-18"
confidence: high

This gives the framework accountability.

If an agent uses a revenue definition, we should know who approved it.

If an agent queries a customer table, we should know whether it contains PII.

If an agent summarizes a support case, we should know what masking rules apply.

Governance is not bureaucracy here.

Governance is what allows agentic AI to move from demo to production.

The Feedback Loop

The best part of this approach is that the knowledge layer can improve over time.

Agents should not only consume knowledge. They should help identify gaps in it.

For example:

A data agent discovers that two tables have conflicting definitions.
A support agent identifies a recurring customer exception.
A delivery agent finds that a release checklist is outdated.
A FinOps agent identifies an untagged resource pattern.
A sales agent finds that a metric definition is ambiguous.

But agents should not directly overwrite approved knowledge.

They should propose updates.

The workflow should be:

Agent identifies reusable learning
   ↓
Agent creates OKF update proposal
   ↓
Domain owner reviews
   ↓
Approved change is merged
   ↓
Knowledge index is refreshed
   ↓
Future agents use improved context

This turns agentic AI into a learning operating model, not just task automation.

Where I Would Start

I would not start by documenting the whole enterprise.

That sounds ambitious, but it is usually a bad execution plan.

It becomes a documentation program, not an AI acceleration program.

I would start with one high-value domain where correctness matters.

Good candidates are:

Revenue analytics
Customer support
Delivery governance
Cloud cost optimization
Sales operations
Data quality monitoring

For the first MVP, I would select 10 to 20 high-value datasets and generate knowledge files around them.

The MVP should include:

AWS metadata extraction
Draft OKF generation
Manual business enrichment
Data owner approval
Git-based versioning
Agent retrieval integration
Measurement of answer quality and tool accuracy

The goal is not to create perfect documentation.

The goal is to make agents more accurate, more governed, and more useful.

How I Would Measure Success

The wrong metric is “number of OKF files created.”

That only measures documentation volume.

The right metrics are:

Reduction in incorrect SQL generation
Reduction in wrong source-of-truth usage
Increase in agent answer accuracy
Reduction in human corrections
Increase in approved knowledge reuse
Reduction in deprecated table usage
Improvement in data discovery time
Fewer governance violations
Higher user trust in agent outputs

The question should always be:

Did the knowledge layer make the agent better?

If not, we are just creating another documentation repository.

Final View

Google Open Knowledge Format is not interesting because markdown and YAML are new.

They are not.

It is interesting because it points to one of the most important problems in enterprise AI: how to make organizational knowledge usable by agents without locking it inside one platform.

In an AWS environment, we already have many of the raw signals: RDS schemas, Aurora metadata, Redshift catalogs, DynamoDB keys and indexes, Glue Data Catalog, S3 exports, CloudWatch metrics, tags, IAM policies, Lake Formation rules, and existing documentation.

The opportunity is to convert these scattered signals into a governed Enterprise Knowledge Layer.

That layer becomes the memory and context foundation for agentic AI.

My view is simple:

Models give agents reasoning power.

Tools give agents execution power.

Knowledge gives agents enterprise judgment.

Without that knowledge layer, agentic AI will remain impressive in demos and fragile in production.

With it, enterprises can build agents that do not just act fast, but act correctly, safely, and in alignment with how the business actually works.

What happens when curiosity meets your AWS Credit?

Nadtakan — Wed, 17 Jun 2026 15:20:02 +0000

I recently had my AWS Community Builder membership extended for another year, and I'm excited to continue building alongside so many talented people in the community.

One of the benefits of the program is AWS credits. As developers, having the freedom to experiment and build without constantly worrying about costs is incredibly valuable.

When I received my credits, I started thinking about what I wanted to build next.

My first thought was Kiro.

Since AWS credits work with Kiro, I set up IAM Identity Center, connected my account, and was ready to go.

Done, right?

Not quite.

The next question immediately became:

"Now what?"

I knew I wanted to build something serverless, but I wasn't sure what.

I started thinking about writing a monthly article summarizing AWS releases and announcements. The challenge was figuring out how to keep up with everything AWS ships.

My first idea was simple:

"Just check the AWS announcements page every day."

Problem solved.

Or so I thought.

Not everyone has time to manually monitor AWS releases every day.

After some research, I discovered AWS RSS feeds that publish release announcements as they happen.

Now things got interesting.

The first version of the project was straightforward:

• Fetch announcements from RSS feeds
• Store them in Amazon S3
• Display them on a webpage

But I wanted more than a feed reader.

I wanted AI to help answer a question I personally care about:

"How does this announcement impact my daily work or personal projects?"

That changed everything.

Instead of simply storing content in S3, I moved toward DynamoDB so I could store structured data alongside each release:

• AI-generated summaries
• Impact analysis
• Categorization
• Additional metadata and insights

Over the course of a day, Kiro helped me build much of the foundation. My role shifted from writing every line of code to making architectural decisions and guiding the implementation.

That said, I still jump into the code regularly. Sometimes I tweak features, optimize workflows, or dig into the implementation to understand what’s happening under the hood. I enjoy coding, and I don’t want to lose that muscle. Tools like Kiro help me move faster, but staying hands-on keeps me sharp as an engineer.

One of the most interesting discussions wasn’t about code at all—it was about cost optimization.

Should the system write a new record every time it processes a release?

Or should it only write when a release doesn’t already exist?

Small decisions like these have a big impact on cost, scalability, and operational efficiency.

What started as "I have AWS credits to spend" evolved into an AI-powered AWS release analysis platform.

And honestly, that's one of my favorite parts of building.

You start with one idea, discover a better one, and keep iterating until the project becomes something you never originally planned.

Here's the evolution of the project from V1 to V2.

What started as a simple RSS-to-webpage pipeline evolved into an AI-powered AWS release analysis platform that helps me focus on the AWS services and topics I care about while also understanding how new releases might impact my work and personal projects.

V1 vs. V2 Architecture

The project is open source, and you can also explore the live version here.

Feel free to clone it, deploy it to your own AWS account, and make it your own.

Whether you want a quick way to stay on top of AWS releases or you're interested in extending the functionality, I hope it provides a useful starting point.

If you have ideas, suggestions, or improvements, I'd love to hear them. Open an issue, submit a PR, or send me a message.

I'm especially curious how others are using AI alongside serverless architectures.

How are you using AI in your side projects today?

Leave me a comment; until next time!

Nad

AWS Amplify builds broken after a GitHub rename? Here’s the fix the console can’t give you

Suzana Melo — Wed, 17 Jun 2026 12:29:23 +0000

My automated builds stopped working, and I had no idea why.

I had been hosting and managing my blog on AWS Amplify since I launched it last year, and I couldn't be happier with it. Amplify gave me all that it promised and more. Quick to connect to GitHub, effortless to deploy, CI/CD out of the box. Every push to the repository rebuilt and redeployed the site for me. Exactly what I wanted: ship fast, sort the details later. Except "later" arrived sooner than I expected.

In fact, I soon realised there are scenarios where Amplify doesn't tell you when you're starting, and I hit one of them when I decided to do what I thought was a simple thing. I updated my GitHub username. What followed was not what I expected.

What happened

When I updated my GitHub username from suzanamelomoraes to suzanamelo-m, I didn't think about the obvious: all repository URLs change with it.

What I also didn't know is that AWS Amplify stores a hard link to the original repository URL and cannot automatically follow username or repository renames.

For example, from my old repo URL:

https://github.com/suzanamelomoraes/suzanamelo

to my new repo URL:

https://github.com/suzanamelo-m/suzanamelo

The CI/CD stopped, and no updates I made on my application were going live. I was pushing my changes to my remote repository at https://github.com/suzanamelo-m/suzanamelo, while AWS Amplify was still reading from the previous URL.

What Amplify doesn't tell you when you're starting out

I jumped to AWS Amplify to try to learn how to fix the issue. I went to the AWS Amplify console to check item by item where a fix could be applied.

I consulted the Amplify documentation for troubleshooting suggestions. I didn't find anything related.

I tried to reconnect to the repository by going to the Branch settings dropdown in App settings and clicking the "Reconnect repository" button. When someone renames their GitHub username, GitHub creates a redirect from the old URL to the new one, but only for a while. I thought that Amplify would just follow it. It didn't.

GitHub's redirect is a browser-level courtesy. Amplify's webhook was registered against the original URL and doesn't follow it.

The finding

Finally, I searched the internet, asked AI for help, and found that I couldn't find the fix in the AWS Amplify console. Changing the repository URL directly in the Amplify Console is not supported; GitHub's automatic redirect doesn't fix Amplify's broken webhook. The hard link must be updated via CLI.

When you need to use the update-app command

I also found out that updating information via CLI was a fix not only for my problem. More scenarios share the same root cause and the same solution.

Scenario 1 — GitHub username change (my case): AWS Amplify cannot automatically follow username renames. When I renamed my username from suzanamelomoraes to suzanamelo-m, my automated builds stopped working.

Scenario 2 — Renaming a repository: Renaming a repository also changes the GitHub URL, and since Amplify is connected via that URL, auto-build stops working. The same CLI fix applies.

Scenario 3 — Moving from a personal to an organisation account: Multiple people have reported needing to move their repository from a personal GitHub profile to an organisation's profile, but there's no way to do it in the AWS Amplify UI console without creating a whole new app. This is a common scenario when a solo project grows into a team project.

Scenario 4 — Switching Git providers: People migrating from Bitbucket to GitHub also hit the same wall: the repository URL changes completely and Amplify breaks. The AWS CLI docs confirm the command works across providers, using oauthToken for Bitbucket and CodeCommit, and accessToken for GitHub (for this article, I'm covering only accessToken for GitHub as this is the one I use, but I'll include helpful links in the list of resources at the bottom).

Scenario 5 — Switching between Bitbucket accounts: Even switching between different Bitbucket accounts connected to Amplify requires the same update-app CLI workaround.

How to fix it

Since my repository is on GitHub, I'm describing the fix I made to it. I'll leave links in the Resources to help you if you're running into issues with other web-based Git repository hosting services.

1. Prerequisites

Before running the fix, you need:

The AWS Command Line Interface (AWS CLI) installed on your machine (you can check out how to do it here)
Access to the AWS Console (to find your App ID)
A GitHub Personal Access Token with repo scope (use oauthToken for Bitbucket and CodeCommit)
Your Amplify App ID

Note: If you set up your Amplify app some time ago, you may be using the older OAuth method rather than the GitHub App. Apps deployed via AWS Amplify using the older OAuth method continue to work for CI/CD, but AWS strongly recommends migrating to the GitHub App for new or updated connections.

2. Step-by-Step Fix

Step 1 — Generate a GitHub Personal Access Token

Go to: https://github.com/settings/tokens
Click Generate new token → Generate new token (classic)
Give it a name, e.g. Amplify Repo Update
Select the repo scope
Click Generate token and copy it immediately (you won't see it again)

Security tip: Delete this token after confirming the fix is working. It is only needed for the one-time update-app command.

Step 2 — Find Your Amplify App ID

Open the AWS Amplify Console
Select your app
Look for the App ID — it can be found in the Console Overview and starts with d followed by letters and numbers (e.g. d2x3uf5yeo5smt)
Also note the region from your console URL, e.g. us-east-1, eu-north-1 or ap-southeast-2

Step 3 — Set Up AWS CLI Credentials (`aws login`)

Before you can run any AWS CLI command in your terminal, you need to get AWS credentials for local development.
Credentials exist to authenticate your local machine or applications and authorise programmatic requests to Amazon Web Services.

The AWS CLI command aws login lets you start building immediately after signing up for AWS, as easily as you do in the AWS Console. Running aws login in your terminal opens your default web browser to authenticate as you would via console.

Once authorised in the browser, it creates short-lived, identity-based credentials for your command-line tasks, eliminating the need to use or store long-lived static access keys, which are always at risk of accidental exposure, leading to security breaches.

To get authenticated:

3a. Check your CLI version
To use AWS login, you need to have AWS CLI version 2, which must be 2.32.0 or later.
If you just installed the AWS CLI in the prerequisites step, jump to 3b below.

To check the version you have, run:

aws --version

If your version is older than 2.32.0, take a look at the Migration guide for the AWS CLI version 2 to learn about the differences between the versions and avoid any breakage.

If there are no breaking changes, follow the Migration guide for the AWS CLI version 2. It covers both uninstalling v1 and installing v2.

3b. Log in and set up your Region

To start the login process, run:

aws login

If it’s the first time you run aws login or you have not set a default Region, the CLI prompts you to specify the AWS Region of your choice. You will see a prompt like that in your terminal:

No AWS region has been configured. The AWS region is the geographic location of your AWS resources.
If you have used AWS before and already have resources in your account, specify which region they were created in. If you have not created resources in your account before, you can pick the region closest to you: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html.

You are able to change the region in the CLI at any time with the command "aws configure set region NEW_REGION".
AWS Region [us-east-1]:

Once you define your region, the CLI will open a sign-in session in your default browser, and you will see the sign-in options page.

Select “Continue with Root or IAM user” and log in to your AWS account as you would normally.

Even though you will see a button saying “Continue with Root or IAM user”, AWS best practices recommend avoiding using the Root account for those types of tasks. The recommendation is to create a user to manage your project and give it only the access it needs.

Once you finish the sign-in process, you will be directed to a screen confirming that your credentials have been shared successfully. You can close the browser tab and return to your terminal.

3c. Configure a named profile

You're now authenticated and ready to run CLI commands. If you're managing multiple projects or environments, you can also create a named profile to keep credentials organised. Choose a name that makes sense to you and your application. For this example, I’m going to call it “blog”.

To create a profile, run aws login and set a name for your profile. The same command works when you want to authenticate specifically for this application.

aws login --profile blog

3d. Update region later if needed

As you previously saw when you ran that aws login for the first time, you are able to change the region in the CLI at any time with the command:

aws configure set region NEW_REGION

If you are updating your region under your profile (step 3c)

aws configure set region NEW_REGION --profile blog

Step 4 — Update the Repository in AWS Amplify

Run the following command, replacing the placeholders with your actual values:

aws amplify update-app \
  --app-id YOUR_APP_ID \
  --repository https://github.com/NEW_USERNAME/REPO_NAME \
  --access-token YOUR_GITHUB_TOKEN \
  --region YOUR_REGION \
  --profile blog  # omit this line if you skipped step 3c

A successful response will include JSON output with your app details. Here is what the structure looks like, with sensitive values redacted:

{
  "app": {
    "appId": "YOUR_APP_ID",
    "appArn": "arn:aws:amplify:YOUR_REGION:YOUR_ACCOUNT_ID:apps/YOUR_APP_ID",
    "name": "your-app-name",
    "repository": "https://github.com/suzanamelo-m/suzanamelo",
    "platform": "WEB",
    "createTime": "...",
    "updateTime": "...",
    "environmentVariables": {},
    "defaultDomain": "your-app-id.amplifyapp.com",
    "enableBranchAutoBuild": true,
    "enableBranchAutoDeletion": false,
    "enableBasicAuth": false,
    "productionBranch": {
      "lastDeployTime": "2026-06-15T10:00:00.000Z",
      "status": "SUCCEED",
      "branchName": "main"
    }
  }
}

Two things to confirm from this output: the "repository" field now shows your new URL, and "status": "SUCCEED" confirms your last deployment is intact.

If you open the Amplify Console after running the command, you should also see the new repository URL reflected under App settings → Branch Settings.

Step 5 — Verify & Trigger a New Build

Option A — Via the Amplify Console:

Go to the Amplify Console and open your app
Click on your branch (e.g. main or prod)
Click the Run build button in the top right corner

Option B — Via the AWS CLI:

aws amplify start-job \
  --app-id YOUR_APP_ID \
  --branch-name main \
  --job-type RELEASE \
  --region YOUR_REGION \
  --profile blog

Step 6 — Delete the GitHub Token

Go to: https://github.com/settings/tokens
Find the token you created
Click Delete

The Amplify connection will continue to work after the token is deleted. The token was only needed for the one-time update-app command, not for ongoing builds.

Going further: managing multiple AWS environments

AWS profiles are named collections of credentials and settings that let you manage multiple AWS accounts or environments from your local machine, without mixing credentials.

Instead of constantly overwriting your default settings, profiles let you manage different environments, permission levels, and accounts without re-authenticating every time.

You can use AWS profiles for a variety of management cases, for example, to separate your [development], [staging], and [production] accounts to reduce the risk of accidental changes, handle different clients and projects in different regions, or, in my case, to create a separate environment specifically for my blog-related credentials.

Useful Commands

List all configured profiles:

If you authenticated using aws login, your credentials are temporary and won't appear here. Use aws sts get-caller-identity --profile blog to verify your active session instead.

cat ~/.aws/credentials
cat ~/.aws/config

Run any AWS command with a specific profile:

aws <command> --profile blog --region us-east-1

Set a profile as the default for a terminal session:

export AWS_PROFILE=blog

Verify which identity is active:

aws sts get-caller-identity --profile blog

Update a profile's region:

aws configure set region NEW_REGION --profile blog

Delete a profile — manually remove the relevant block from both files:

nano ~/.aws/credentials   # Remove [blog] block
nano ~/.aws/config        # Remove [profile blog] block

Wrapping up

AWS Amplify hosting is an incredible tool, especially when you want to benefit from the AWS infrastructure (CloudFront, Route 53, IAM). In my case, I already had my custom domain and Route 53, which made the setup even smoother.

It's also very handy when you want to avoid third-party services and rely on AWS native tools for authentication and databases.

AWS Amplify focuses on enhancing the user experience and making it even easier to manage your applications through its UI console. But not every issue can be sorted in the UI console. We just covered one issue that Amplify can't protect you from, but now you know exactly how to handle it when it happens.

This fix taught me more than I expected. Not just about how Amplify manages repository connections, but about how the AWS CLI has evolved. aws login is a genuinely useful addition, and I want to write more about it properly.
If you've hit a different Amplify wall or you're curious about more CLI basics, let me know. Your comments or questions might become the next article. 🤗

Resources

New to AWS Amplify hosting? Start here — From Procrastination to Publishing: How AWS Amplify Helped Me Finally Start Blogging
AWS CLI installation guide: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
AWS CLI update-app full reference: https://docs.aws.amazon.com/cli/latest/reference/amplify/update-app.html
GitHub Personal Access Tokens (classic): https://github.com/settings/tokens
AWS login: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html
Simplified developer access to AWS with ‘aws login’: https://aws.amazon.com/blogs/security/simplified-developer-access-to-aws-with-aws-login/
AWS Amplify Troubleshooting: https://docs.amplify.aws/react/build-a-backend/troubleshooting/
The start-job CLI reference: https://docs.aws.amazon.com/cli/latest/reference/amplify/start-job.html
Migrating from OAuth to the Amplify GitHub App (for users on older setups): https://docs.aws.amazon.com/amplify/latest/userguide/setting-up-GitHub-access.html
Bitbucket — changing accounts: https://repost.aws/questions/QU3ibFSag6QdmlrQA55tr4-g/amplify-bitbucket-sign-to-different-account
Migrating from Bitbucket to GitHub: https://www.isme.es/2023/09/10/migrate-blog-source-from-bitbucket-to-github.html

This article was originally published on my blog, suzanamelo.com, where I write about cloud, AWS, AI, and what it actually takes to change careers in tech.

AWS Blocks: A New Way to Build on AWS

Rishi — Wed, 17 Jun 2026 10:44:42 +0000

Just explored AWS Blocks today, and the idea is quite interesting.

If you've ever built a full-stack application on AWS, you know how quickly things get out of hand.

A simple Todo app can easily turn into creating DynamoDB tables >> wiring Lambda functions >> configuring API Gateway routes >> setting up Cognito >> debugging IAM permissions >> LocalStack for local testing

Before you've even written much business logic, you've already wired together half a dozen AWS services.

AWS Blocks aims to solve this with a concept called Infrastructure From Code (IFC). No separate infrastructure files. Infrastructure is inferred from the code you write.

Instead of writing application code in one place and infrastructure definitions in CDK/Terraform somewhere else, you work with higher-level building blocks such as:

• KVStore
• DistributedTable
• Auth
• Realtime
• FileBucket
• Agent

During local development, these blocks are simulated locally.

When deployed, the same blocks are translated into actual AWS resources such as DynamoDB, Cognito, S3, API Gateway, Bedrock, and more.

Have you tried AWS Blocks yet? What are your thoughts on Infrastructure From Code?

Building a Serverless, Multi-Backend Web Search Service for AI Agents on AWS

Matheus das Mercês — Wed, 17 Jun 2026 07:46:59 +0000

Introduction

From small ones to more complex agentic architectures, agents are everywhere. As more teams build AI-powered solutions, web search is becoming a fundamental capability: access current information, verify facts, and gather external context.

In this article, I'll walk through how we built a serverless, multi-backend web search service at PostNL, creating a foundation that can evolve from a single search backend to a centralized, provider-agnostic service on AWS.

Why web search as a shared capability

While integrating a search provider is relatively straightforward for a single app, the challenge becomes more interesting when multiple teams start building agents that need to access information beyond what the LLM already knows.

If teams have the freedom to implement their web search services independently, that can lead to fragmentation. Different providers, different APIs, some of them relying on public web search APIs, different cost models, etc.

At that point, web search is no longer just an application feature, but a shared capability. Providing a centralized web search service enables teams to consume a consistent interface while allowing platform owners to manage costs, operations, and future provider choices in a single place.

Designing a centralized web search service

At PostNL, the AI Center of Excellence (AI CoE) supports teams across the organization in adopting and scaling AI solutions. As more teams began experimenting with AI agents, the need for a web search service became clear.

Rather than recommending a specific provider, we decided to focus on a platform-oriented solution. Our goal was to provide a single web search capability that teams could easily consume, while keeping the underlying search implementation flexible and replaceable.

From the beginning, we defined a few key design principles:

A single interface for all consumers;
Support for multiple search backends;
Low operational overhead;
Cost-efficient operation;
The ability to evolve without impacting consumers;

These principles led us to an architecture centered around a lightweight routing layer that sits between AI applications and the underlying web search providers.

Why the backend doesn't matter to consumers

Perhaps the most important aspect of the design is that consumers never interact directly with the underlying web search providers.

Because all requests flow through the routing layer, the backend can evolve independently of the applications using the service. Today, the router forwards requests to the primary search backend; tomorrow it could route traffic to additional providers, apply failover policies, or make routing decisions based on cost, geography, or freshness requirements.

Initial architecture

The service is exposed through a private API Gateway, ensuring that only authorized consumers within the network can access it through a VPC endpoint.
Requests are routed to a lightweight Lambda-based router, which acts as the abstraction layer between clients and the underlying search backend.
The initial backend is a self-hosted SearXNG deployment running on ECS Fargate behind an internal Application Load Balancer, providing a scalable and centrally managed web search capability while keeping the architecture flexible for future providers.

Building the Router

The Router is the central component of the system. It enables future backend changes without impacting consumers.

The overall flow is fixed:

Receive requests from API Gateway
Forward requests to the primary backend
Return responses from the backend
Perform basic request validation if required

The Router follows a hexagonal architecture, also known as ports and adapters. The application core defines the web search behavior and interfaces, while infrastructure concerns such as API Gateway events, HTTP clients, and provider-specific integrations are implemented as adapters.

This keeps the core logic independent from any specific backend. Today, the Router forwards requests to SearXNG. In the future, additional adapters can be introduced for other providers without changing the public API or affecting consumers.

Runtime choice

For the runtime, we selected Go because the Router is mostly a lightweight HTTP orchestration component. It does not perform heavy computation; it validates requests, applies routing logic, calls a backend, and returns a response.

Go is a good fit for this type of workload because it provides:

Fast startup times
Low memory usage
Strong HTTP support in the standard library
Simple concurrency primitives
Easy deployment as a small Lambda binary

The reasoning behind Lambda

AWS Lambda was selected to keep the operational footprint small. The Router does not need long-running infrastructure, local state, or complex runtime management. Keeping it stateless allows Lambda to scale horizontally as request volume changes.

At first glance, introducing a Lambda-based router in the request path may raise scalability concerns, especially for a service that could be consumed by multiple applications. However, the router intentionally remains lightweight, performing only request validation, routing, and protocol translation. By keeping the component stateless and focused on orchestration rather than search execution, Lambda provides automatic scaling with minimal operational overhead while maintaining low latency.

This separation keeps the Router simple today while allowing it to evolve later with routing policies, fallback logic, circuit breakers, and additional backend adapters.

Deploying an open-source web search backend

After establishing the Router layer, the next decision was selecting the initial search backend.

Rather than immediately integrating commercial web search providers, we wanted a solution that was self-hosted, easy to experiment with, and replaceable in the future.

For the MVP, we selected SearXNG, an open-source metasearch engine.

Why SearXNG?

Requirement	SearXNG
Self-hosted	✅
Open source	✅
Aggregates multiple engines	✅
Easy container deployment	✅
Vendor independence	✅

SearXNG runs as a containerized service on ECS Fargate and is exposed internally through an Application Load Balancer. For this workload, ECS Fargate offered the simplest path to a production-ready deployment.

Consuming the service

As the service is exposed through a private API Gateway, teams at PostNL can consume the service through a standard HTTP interface, where authentication, quotas, and usage tracking are handled centrally. This provides clear visibility into adoption and usage patterns while ensuring that the platform can be governed consistently as more teams onboard.

The platform is intentionally focused on search retrieval. Responses consist of search results returned by the backend and are not interpreted or summarized by an LLM. Any reasoning or answer generation remains the responsibility of the consuming application.

Preparing for a multi-backend future

Although the initial implementation relies on a single backend, the service was designed from the beginning to support multiple search providers. The Router follows a hexagonal architecture, where the application core remains independent from backend-specific implementations through well-defined ports and adapters.

Potential future enhancements include:

Additional search providers
Provider failover and fallback mechanisms
Health-based routing
Query-specific routing policies
Configurable provider selection

By investing in the abstraction layer early, the service remains flexible and can evolve incrementally as requirements change, while continuing to provide a stable interface for consumers.

Conclusion

As AI agents become more common, capabilities such as web search are increasingly moving from individual applications into shared capabilities. By centralizing web search behind a consistent interface, teams can focus on building solutions rather than integrating and operating search providers.

The specific technologies and providers will likely evolve over time, but the underlying principle remains the same: common capabilities are often most valuable when they are provided once and consumed by many.