标签：#aws

AWS recently announced CDK Mixins, a new AWS CDK feature that lets developers add reusable capabilities like security, monitoring, and configuration to AWS resources. Mixins work across different construct types, making infrastructure code more flexible and reusable. By Renato Losio

A quick note on the links below. The DigitalOcean and Vultr links in this article are referral links. If you sign up via them, you get a free credit on your new account (currently $200 over 60 days for DigitalOcean and up to $300 for Vultr) and the author of this article gets a small referral credit too, at no extra cost to you. AWS does not run an equivalent referral program, so the AWS links are normal links. The review below is the author's own evaluation; the credits do not change the recommendations. If you have ever spent a workday watching your website refuse to load, you are not alone. In a recent outage , a single building in Northern Virginia hosting one of Amazon's availability zones (the cloud-industry term for one campus's worth of servers in one region ) got too hot. The hardware shut itself down. AWS calls this a thermal event. Customers around the world have other names for it. Big enterprises ride out outages like this. They have multi-region setups, dedicated SRE teams, and SLA credits that will refund a small fraction of their monthly bill. Small and mid-size businesses do not. They lose a day of revenue, scramble to reassure customers, and then read a post-mortem in a few weeks that explains what went wrong in language that does not help them recover the lost revenue. The cloud was supposed to make small businesses look big. After each new outage, it is fair to ask: is AWS actually the right cloud for small businesses at all? Two providers worth a serious look, DigitalOcean and Vultr , are simpler, cheaper at the entry level, and built around use cases that more closely match what a small business actually needs. Here is what each one does, where AWS is still the right answer, and how to decide. Why AWS hits small businesses harder than big ones When a giant company has an AWS outage, three teams kick into gear. There is the engineering team that fails workloads over to a backup region. There is the customer-success team that updates the status p

Did chatbot abandon mental health guardrails when a vulnerable user pushed back?

Shifting from traditional application testing to serverless TypeScript engineering is all about shifting your perspective: you stop testing a running server, and you start testing how your function responds to events and SDK states. Here is a simple, practical example for each testing, using modern AWS SDK v3 syntax. 1. Unit Testing: Jest + Mock Payloads & SDK Client Mocking In unit tests, you don't call real AWS services. You pass a simulated API Gateway event to your handler, and you mock the AWS SDK so it returns predictable data instead of hitting live infrastructure. The Code Under Test ( src/handler.ts ) import { APIGatewayProxyEvent , APIGatewayProxyResult } from ' aws-lambda ' ; import { DynamoDBClient } from ' @aws-sdk/client-dynamodb ' ; import { DynamoDBDocumentClient , GetCommand } from ' @aws-sdk/lib-dynamodb ' ; const ddbClient = new DynamoDBClient ({}); const docClient = DynamoDBDocumentClient . from ( ddbClient ); export const handler = async ( event : APIGatewayProxyEvent ): Promise < APIGatewayProxyResult > => { const userId = event . pathParameters ?. id ; if ( ! userId ) { return { statusCode : 400 , body : JSON . stringify ({ message : ' Missing ID ' }) }; } // Fetch from DynamoDB const result = await docClient . send ( new GetCommand ({ TableName : process . env . USERS_TABLE , Key : { id : userId } })); if ( ! result . Item ) { return { statusCode : 404 , body : JSON . stringify ({ message : ' User not found ' }) }; } return { statusCode : 200 , body : JSON . stringify ( result . Item ), }; }; The Jest Unit Test ( tests/unit.test.ts ) Instead of the legacy aws-sdk-mock , the modern standard for AWS SDK v3 is aws-sdk-client-mock . import { handler } from ' ../src/handler ' ; import { APIGatewayProxyEvent } from ' aws-lambda ' ; import { mockClient } from ' aws-sdk-client-mock ' ; import { DynamoDBDocumentClient , GetCommand } from ' @aws-sdk/lib-dynamodb ' ; const ddbMock = mockClient ( DynamoDBDocumentClient ); describe ( ' Lambda Handler Unit

On June 9, 2026 (US time), two big announcements landed on the same day. At the keynote of Datadog's annual event DASH 2026 in New York, the Bits AI family expanded significantly: Detection, Investigation, Remediation, Infrastructure, Code, Release, Testing, Data Analysis, Chat, Memories, and Evals. Counting by agent, that is more than ten, with over 100 new features announced together. The full picture is laid out in the keynote roundup. https://www.datadoghq.com/blog/dash-2026-new-feature-roundup-keynote/ The same day, AWS announced FinOps Agent as a public preview. It bundles four data sources, Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, and Compute Optimizer, and delivers automated cost-anomaly investigation, natural-language cost questions, periodic cost reports, and aggregated optimization opportunities straight into Slack and Jira. The details are in the AWS blog. https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-finops-agent-is-now-public-preview/ AWS DevOps Agent had already gone GA in March, handling incident response. With FinOps Agent now added, AWS-built standard agents line up across the main operational domains. That said, DevOps Agent also covers multicloud and on-premises environments, so its scope differs from FinOps Agent, which targets AWS cost data. https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/ On the surface, this looks like two separate stories: Datadog the monitoring platform, AWS the cloud provider. But read the two announcements side by side, and you see both reaching for the same territory, Ops, through different entrances. Line up their features and most of them overlap, so a surface spec comparison won't show the difference. This article sorts out the same-day releases by the two companies' positioning, asks what these very similar agent lineups are actually fighting over, and goes as far as the axes for telling them apart and the predictions that follow. This is writ

In the previous post , we talked about context windows. The model has a fixed-size desk and everything has to fit on it at once. When too much is on the desk, things in the middle get missed. I ended that post with a promise: what if there was a way to give the model just the right piece, at the right time, from a document you've never even pasted in? That's this post. We're giving the model a search system. The problem: your document is too long You have a 2000-page document. An employee handbook, a product manual, internal documentation. You need one specific answer from it. You can't paste the whole thing into the model's context window. And even if you found a model with a window big enough, we learned what happens: attention degrades, things in the middle get missed, and the model answers confidently from the wrong section. So you need something different. A step that happens before the model sees anything. Something that finds the 2-3 paragraphs that actually answer your question, and passes only those to the model. That's retrieval. The full technique is called RAG: Retrieval-Augmented Generation . Search first, then generate. Three words, one loop Let's break the name down. Each word is a step. Retrieval. Go find relevant information. Think of it like checking the index of a textbook before diving into a chapter. You don't re-read the whole book. You find the right page first. Augmented. Add that retrieved info to the prompt. You're supplementing the model's built-in knowledge with fresh, specific context. Like handing someone a cheat sheet right before they answer a question. Generation. The model writes its response, but with the retrieved context sitting right there in the conversation. It generates an answer grounded in your actual data, not just its training. "Grounded" means the model has real evidence to point to. It's not guessing from memory. It's answering from something you gave it. The whole loop in one sentence: find the right chunks of informat

Modern enterprise order processing architectures must decouple synchronous client demands from asynchronous backend dependencies. Here I'll detail a highly scalable, fault-tolerant design built on AWS. By utilizing an automated API Gateway entry point, specialized Amazon Cognito authentication, optimized AWS Lambda logic blocks, an engineered RDS Proxy connection layer, and an event-driven SQS/EventBridge core, the design guarantees isolation, cost efficiency, and sub-millisecond structural routing. The Scenario User places an order → payment is processed → inventory updated → confirmation email sent Client → API Gateway (Cognito auth + validation) → Order Lambda (business logic + DynamoDB write) → SQS (payment queue) → Payment Lambda → EventBridge → Inventory Lambda → Notification Lambda (SES) 1- Entry Point — API Gateway REST endpoint: POST /orders Request validation via API Gateway models (reject malformed payloads instantly, no Lambda invoked) Auth via Cognito User Pool Authorizer — validates JWT token on every request How It Works The Request Hits: A client sends a POST /orders request with a JWT token in the header. Auth Check: API Gateway automatically intercepts the request and validates the JWT against the Cognito User Pool. If expired or spoofed, it returns 410 Gone / 401 Unauthorized right there. Payload Check: Next, it compares the body against your JSON Schema Model. If a required field like customer_id is missing, API Gateway instantly drops it with a 400 Bad Request. The Win: Your downstream services (like Lambda) are never invoked for bad/unauthorized requests, saving compute costs and protecting against basic DDoS or bad actor spam. Gotchas Cognito Latency: While Cognito authorizers are native, they can add a slight latency overhead to your API's P99 metrics during peak traffic. For massive global scale, some enterprises migrate to custom Lambda Authorizers that cache tokens in ElastiCache (Redis). Model Validation Limits: API Gateway's built-in val

OpenAI's GPT-5.5, GPT-5.4, and Codex are now generally available on Amazon Bedrock, one month after OpenAI revised its exclusive Azure arrangement. Pricing matches OpenAI's direct rates with usage counting toward AWS commitments. Codex shifts to pay-per-token billing with no seat fees. GPT-5.4 is the first OpenAI model available in AWS GovCloud. By Steef-Jan Wiggers

Building a URL shortener with Cursor, ChatGPT, AWS Lambda, API Gateway, and Cloudflare taught me more about shipping software than writing code. Since last year, Cursor has been my go-to development assistant for daily tasks. But at the beginning of this year, just using it to generate snippets didn't feel like enough anymore. Having studied programming since 2011, I knew what modern AI tools could do, but I wanted to test their limits. I decided to build a full project—a URL shortener—without writing a single line of frontend or backend code myself. For the stack, I chose Node.js with TypeScript, React with Vite, and AWS Lambda to handle redirects. While I used ChatGPT to debate architectural trade-offs, Cursor generated the entire codebase. Watching a functional application take shape so quickly was the exact moment a line was crossed for me. It made me realize how fundamentally software development is shifting: our role is evolving from code writers to architectural decision-makers and problem-solvers. But truth be told, this project and this post represent a massive personal milestone. Like many developers, I have a graveyard of half-finished projects on my machine. This is one of the first times I've pushed a personal project all the way to production. Writing this and exposing my work to the community is a huge first step for me. This isn't just a story about code or AI—it's about the challenge of finally shipping something. The Stack Before asking Cursor to write a single line of code, I wanted to map out the architecture. I didn't need a massive enterprise system for a URL shortener, but I did want something flexible enough to support future features and experiments. To validate my ideas, I used ChatGPT to debate the pros and cons of different architectural approaches. We eventually settled on this stack: Backend: Node.js + TypeScript Frontend: React + Vite Database: MongoDB Atlas Redirects: AWS Lambda Entry Point: AWS API Gateway DNS / CDN: Cloudflare Secur

When you expose inventory or checkout endpoints to public-facing front-ends or third-party webhooks, safeguarding those APIs from brute-force scripts, scraping bots, and inventory hoarding algorithms becomes a critical requirement. Without defensive rate limiting, a single coordinated script can easily overwhelm your database connections. The Problem with Simple Counter Resets A common mistake when setting up basic API protection is using a rigid "Fixed Window" counter (e.g., allowing 100 requests per minute, resetting exactly at the turn of the clock). This creates a massive flaw where a developer can flood your server with 100 requests at 11:59:59 and another 100 requests at 12:00:01, effectively doubling your acceptable burst traffic and causing severe performance dips. To handle uneven burst traffic safely without crashing your database, the standard approach is implementing a token bucket algorithm. The Token Bucket Pattern The token bucket algorithm maintains a centralized bucket that holds a maximum capacity of tokens. Tokens are added back to the bucket at a constant, predictable rate over time. Each incoming API request consumes exactly one token. If the bucket is completely empty, the request is instantly rejected with a 429 Too Many Requests status code, protecting your core server threads. javascript // Quick Redis-based token bucket rate limiter concept async function isRateLimited(userId) { const key = `rate:${userId}`; const now = Date.now(); // Use a Redis multi-exec transaction to atomically check and update tokens const [tokens, lastRefill] = await redis.hmget(key, 'tokens', 'lastRefill'); // Calculate token replenishment based on time elapsed... // Return true if tokens <= 0, otherwise decrement tokens and update timestamp }

You asked Claude Code to add pagination to your order history endpoint. It generated a clean function — listOrdersByUser() — using a DynamoDB Scan with a Limit parameter. It compiled. Tests passed. You shipped it. Three days later your AWS bill had a line item you didn't recognize: 47 million read capacity units consumed in 72 hours. The Orders table has 50M rows. Scan reads every one of them regardless of Limit — Limit only controls how many results come back, not how many items DynamoDB reads. Claude Code didn't know your table had 50M rows. It didn't know you had a GSI on userId . It guessed, and the guess was expensive. infrawise · npm What AI Assistants Don't Know About Your Infrastructure AI coding assistants read your source files. They understand function signatures, TypeScript types, and import chains. What they cannot see is the infrastructure those functions run against. When Claude Code looks at a file that calls dynamoClient.scan({ TableName: "Orders" }) , it has no idea that: The Orders table has 50M items There is already a GSI named userId-index on the userId attribute Three other functions are already using Query against that same GSI The Sessions table is accessed by 6 separate code paths, making it a hot partition candidate Without that context, the assistant fills the gap with generic patterns. It recommends Scan because it has no reason not to. It suggests adding a GSI on status because it doesn't know one exists. It writes SELECT * because it has no idea which columns are expensive to pull. This isn't a bug in the model. It's a missing input. The model was never given your infrastructure. What Happens When infrawise Is in the Loop infrawise statically analyzes your codebase, your DynamoDB tables, and your PostgreSQL schemas, then exposes that context to your editor through MCP. Claude Code gets 15 tools that answer questions like: which tables exist, what are their partition keys and sort keys, which GSIs are already defined, which functions ar

I came to programming late — I didn't get into this world until I was past 35, and I'm 62 now, still writing code every day. This is a "build in public" post about a tool I just finished, and I'd genuinely love your feedback. The itch For years I watched infrastructure teams keep their AWS inventory in spreadsheets. It always worked — right up until it didn't. Nobody had time to keep it current, and every single one eventually drifted away from reality. Middleware EOL was the same story: a hand-maintained list, no alerts, no dashboard, quietly going stale. One day I asked the obvious question: we have tfstate, we have boto3 — why are we still doing this by hand? What I built SyncVey is a self-hosted web app that: Inventories your AWS resources into a System → Environment → Asset ledger (EC2, ECS, Lambda, RDS, S3, ALB, VPC, EBS), scanned live via boto3/AssumeRole Detects attribute-level drift between your tfstate and live AWS — including resources someone built by hand in the console that terraform plan never sees Tracks the app/middleware layer per environment and flags end-of-life runtimes The drift piece is the part I care about most. terraform plan only knows about resources Terraform already manages. The thing that actually bites teams is the resource someone spun up by hand in the console — plan is blind to it. SyncVey diffs your tfstate against the live AWS state, so those show up too. The stack (and why) Django + htmx + Postgres — server-rendered, no SPA, no Node build step MIT-licensed, no SaaS, no telemetry One docker compose up and your data stays inside your own infrastructure git clone https://github.com/MR-TABATA/SyncVey cd SyncVey docker compose up I deliberately leaned on htmx because, for a tool someone has to deploy and maintain themselves, "no frontend toolchain" matters more than a fancy client. I'd love your honest take It's AWS-only for now and very much a solo project, so I'm sure there are rough edges. I'm not an AWS specialist — I deliberatel

A few months ago I was trying to prepare for a cloud certification exam. I went looking for practice questions - good ones. Not just answer lists, but questions that actually trained the reasoning the exam tests. I found some scattered GitHub repos, a few YouTube playlists, sites with outdated question dumps. Nothing that felt structured. Nothing that explained why an answer was right, not just what it was. So I started building my own study tool. Mock questions, practice sets, AI-generated explanations. The kind of thing I wished existed. Six weeks later that became ArchReady - a certification prep platform for AWS, GCP, and PSM1. It's live now. What it does Practice questions across AWS (CCP, SAA, DVA, SAP), GCP ACE, and PSM1 Explanations for wrong answers - walks through the reasoning, not just the correct option AI-powered explanations coming soon Claude (Anthropic) Confidence tracking - shows which topics you're weak on Free to practice, no signup required. Pro unlocks full history and tracking. The stack Frontend: Next.js 14 (App Router) Backend: FastAPI (Python) AI: Claude (Anthropic) - explanations launching soon Payments: Dodo Hosting: Vercel (web) + Railway (API) Nothing exotic. I kept it boring on purpose - solo founder, 2-5 hrs/week, I can't afford interesting infrastructure problems. What I actually learned Ship before it feels ready. I had a list of 12 features I thought were "required for launch." I launched with 4. Nobody noticed the missing 8. Questions sourced from open-source + AI is good enough to start. Questions come from curated GitHub repos and AI-generated content built around official exam frameworks. That's enough to be useful. Perfection is a later problem. The hardest part isn't building - it's the first 10 users. The product exists. Getting people to try it is the actual work now. Where it is today Live at archready.io . Early stage. Still building. If you're prepping for AWS, GCP, or PSM1 - try it free, no account needed. Honest feedba

No trabalho, nenhum código mudou. O que mudou foi a forma como os clientes inserem os dados. E isso quebrou coisas que nenhum teste existente pegou. O bug que só aparece quando alguém usa A motivação pra montar E2E do zero veio de um problema específico. Você precisava acessar a aplicação pra quebrar. Não era um erro de lógica isolado que um teste unitário pegaria. Era uma combinação de dados reais num fluxo real produzindo um resultado errado que só aparecia na tela. Os clientes chegavam lá antes da gente. É uma categoria de problema que teste de código não resolve, porque o problema não está no código. Está na interação entre o código, os dados e o ambiente. A forma mais rápida de pegar antes é rodar o fluxo completo do jeito que o usuário roda. Ficou com smoke tests cobrindo os principais fluxos do produto, configuração pra rodar contra múltiplos ambientes, e notificação no Slack quando o nightly quebra. A parte mais útil não são os testes em si. É saber antes do cliente reportar. Autocrop: quando nenhuma ferramenta resolve tudo Num projeto paralelo que mantenho, passei o fim de semana montando autocrop automático pra imagens. A ideia inicial era usar o imgproxy Pro, que tem detecção de objeto embutida. Não ficou preciso o suficiente pra variedade de imagens que eu tinha. Fui pro Rekognition, que retorna bounding boxes. Mais controle, mas bounding box tem um limite: é um retângulo. Objetos não são retângulos. Aí descobri o rembg, que faz algo diferente. Em vez de delimitar uma área, ele cria uma máscara pixel por pixel usando uma rede chamada U2Net, treinada pra segmentação de primeiro plano. O resultado foi bem superior — ele recorta o objeto, não uma caixa em torno dele. Colocar isso em Lambda foi onde a semana ficou mais lenta. O modelo precisava estar acessível pro processo do Lambda, coloquei em /root , Lambda não lê de lá. Movi pro /opt , chmod 755. O NUMBA tentou escrever cache em diretório read-only, defini NUMBA_CACHE_DIR=/tmp . Depois OOM em imagens mai

I built InvoiceAI an AI powered invoice generator that lets you describe what you want to invoice in plain English and get a fully formatted invoice in seconds, complete with PDF download and a real payment link. Here's how I built it for the #H0Hackathon. The Problem Freelancers and small businesses waste time manually creating invoices. You know what you did, who you did it for, and how much it costs you shouldn't have to fill out a form to capture that. The Stack - Vercel v0 — scaffolded the entire UI in one prompt Next.js 16 — framework Groq (Llama 3.3 70B) — AI natural language to invoice fields AWS DynamoDB — stores every generated invoice Paystack — generates real payment links jsPDF — client-side PDF generation Vercel — deployment How It Works User types: "50 hours of mobile app development at $80/hr for TechLagos Ltd, 7.5% VAT" Groq parses the text and extracts structured invoice data Live preview updates instantly User downloads PDF — invoice is saved to DynamoDB automatically One click generates a real Paystack payment link to send to the client Building the UI with v0 I used Vercel v0 to scaffold the entire UI in one prompt. It generated a production-ready Next.js component with a split-panel layout form on the left, live invoice preview on the right. I just had to wire up the AI and database logic. Connecting AWS DynamoDB Using the AWS SDK v3, I connected DynamoDB directly from Next.js server actions. Every time a user downloads an invoice, it's saved to DynamoDB with the client details, line items, tax rate, and timestamp. This gives the app a real data foundation that scales from day one. await dynamo . send ( new PutCommand ({ TableName : ' invoices ' , Item : { invoiceId : data . invoiceNumber , clientName : data . clientName , clientEmail : data . clientEmail , items : data . items , createdAt : new Date (). toISOString (), }, })) The Result AI generates invoice from plain English in under 2 seconds Real PDF download (no print dialog) Real Paystack

Amazon Web Services has recently announced the general availability of the next generation of Amazon OpenSearch Serverless, with a redesigned architecture that enables 20 times faster resource provisioning than the previous serverless architecture, true scale-to-zero capability, and up to 60% lower cost than a provisioned cluster for peak loads. By Gianmarco Nalin

Senior Solution Architect Viktor Vedmich shares how engineering leaders can maximize application performance using Valkey. He discusses the open-source Redis fork's 100% API compatibility, explores advanced caching strategies like lazy loading, and explains how to implement powerful data structures for real-time analytics, rate limiting, and session stores to solve the thundering herd problem. By Viktor Vedmich

One of the first cloud concepts many people encounter while learning AWS is EC2 . The name sounds technical. The documentation is extensive. And the number of configuration options can make it feel like something fundamentally different from a regular computer. But while trying to understand cloud computing, I found myself repeatedly coming back to a simple thought: At the end of the day, an EC2 instance is just another computer. That realization helped me understand cloud infrastructure much more clearly. The Intimidation Factor When people first open the AWS console, they encounter terms such as: EC2 VPC Security Groups Elastic IPs Auto Scaling It is easy to feel that cloud computing is an entirely different world. But before diving into those concepts, it helps to ask a simpler question: What is an EC2 instance actually providing? Starting with the Name EC2 stands for: Elastic Compute Cloud The important word here is: Compute AWS is essentially renting computing resources. When you launch an EC2 instance, AWS allocates: CPU Memory (RAM) Storage Networking to a virtual machine that you can access. In other words: You are renting a computer that lives inside AWS's infrastructure. Comparing It to a Personal Computer Consider a typical laptop. It contains: A processor RAM Storage An operating system Network connectivity Now consider an EC2 instance. It also contains: Virtual CPUs RAM Storage An operating system Network connectivity The location is different. The concepts are the same. The Main Difference: Ownership The biggest difference is not technical. It is operational. With a personal computer: You own the hardware. The machine sits near you. You maintain it. With EC2: AWS owns the hardware. The machine runs in a data center. AWS manages the physical infrastructure. You only manage the virtual machine running on top of it. Why Linux Knowledge Transfers This was one of the most interesting observations during my learning. If an EC2 instance runs Linux, many of th

If you’ve ever spent hours debugging slow EC2 workloads or getting sticker shock from unexpected EBS IOPS charges, you’ve probably wondered if there’s a better storage option for temporary, high-performance data. AWS EC2 Instance Storage (also called Instance Store) is one of the most underutilized but powerful tools in the EC2 ecosystem—if you know how to use it correctly. This guide breaks down everything you need to know: core concepts, performance optimizations, use cases, limitations, and how it stacks up against EBS. By the end, you’ll be able to cut storage costs, boost workload performance, and avoid costly data loss mistakes. Table of Contents What Exactly Is AWS EC2 Instance Storage? Core Concepts of EC2 Instance Store Key Features That Make Instance Store Stand Out Which EC2 Instance Types Support Instance Store? Deep Dive: NVMe SSD Instance Store Volumes SSD Instance Store Performance Best Practices EC2 Instance Store vs EBS: Head-to-Head Comparison Top Real-World Use Cases for EC2 Instance Store Critical Limitations to Avoid Costly Mistakes Production-Grade Best Practices for Instance Store Root Volume Options: EBS-Backed vs Instance Store-Backed Instances EC2 Instance Store Pricing: No Hidden Costs Conclusion References What Exactly Is AWS EC2 Instance Storage? EC2 Instance Store is temporary block-level storage that is physically attached to the host server running your EC2 instance. Unlike standalone storage services like EBS, EFS, or S3, it is part of the EC2 service itself, with no network overhead between your instance and the storage disks. Its defining trait is its ephemeral nature: data stored on Instance Store only persists for the lifetime of the associated instance. If you stop, hibernate, or terminate your instance, all data on Instance Store volumes is permanently deleted. Core Concepts of EC2 Instance Store Before you start using Instance Store, make sure you understand these foundational rules: Device naming : Instance Store volumes are

A2A has become like a standard for enabling agent to agent communication, we could use the a2a-sdk for running and configuring the a2a server and its features such as agent card, agent skills, agent executor, request handler etc. However we are going to go with a simplified approach here with strands where the agent card will be fetched automatically. Let's get started! Server Initialize a uv project for the a2a server and switch to that directory. uv init ~/strands-a2a-server cd ~/strands-a2a-server Add the required packages. uv add python-dotenv == 1.2.2 strands-agents[a2a] == 1.42.0 Change the code in main.py to look like below. $ cat main . py from dotenv import load_dotenv from strands import Agent from strands.multiagent.a2a import A2AServer load_dotenv () def main (): agent = Agent ( callback_handler = None , description = " A sample strands agent " , model = " us.amazon.nova-micro-v1:0 " , ) a2a_server = A2AServer ( agent = agent ) a2a_server . serve () if __name__ == " __main__ " : main () I like the simplicity here, as you see above, it's quite simple to start a basic a2a server from with in strands, with just a couple of lines of code, we didn't have to install the a2a-sdk separately. Run the code, to start the a2a server. $ uv run main.py INFO: Started server process [18006] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:9000 (Press CTRL+C to quit) Client Let's now do the client part on a separate terminal. Initialize the project and switch the directory. uv init ~/strands-a2a-client cd ~/strands-a2a-client Modify main.py code to look as follows. import asyncio from strands.agent.a2a_agent import A2AAgent async def main (): agent = A2AAgent ( endpoint = " http://localhost:9000 " ) agent_card = await agent . get_agent_card () print ( " Invoking remote agent with agent card: " ) for key , value in agent_card : print ( key , " : " , value ) print ( ' - ' * 20 ) while True : prompt = input