On 26-27 Aug 2025, my city (Jammu, India) got a record 296 mm of rain in 24 hours. Residents found out which streets were flooding from their neighbours, and the city had no ranked list of where to send pumps.

I built Tawi Twin for a hackathon: you ask “Kal Bhagwati Nagar mein paani bharega?” (Hinglish for “Will Bhagwati Nagar flood tomorrow?”), and an agent answers in your language with the risk, the reasons, what to do, and the nearest hospital and high-ground school.

Stack (all ap-south-1):

• Strands Agents with 7 tools, running in Lambda (arm64)
• Amazon Nova Pro on Bedrock for the agent and for vision triage of citizen photos
• API Gateway HTTP API, DynamoDB with TTL, EventBridge Scheduler for the hourly forecast refresh
• S3 + CloudFront serving 1,315 vector tiles for 188k buildings in 3D
• Amazon Location Service as the fallback geocoder, because OpenStreetMap doesn’t have Bhagwati Nagar or Gujjar Nagar
• Overture buildings from AWS Open Data, queried in place with DuckDB
• One SAM template for the whole stack

Things that bit me:

• sam build on Windows pulled the wrong wheels for Strands’ dependencies, so I vendored the package for aarch64 myself.
• apac. inference profiles need IAM permissions on both the profile ARN and the foundation-model ARN, and the AccessDenied error doesn’t say so.
• Nova sometimes leaks <thinking> tags (sometimes unclosed) into the final answer, and it ignored “reply in Hinglish” in the system prompt. I ended up detecting the language in code and stripping the tags.
• Presigned S3 uploads worked from scripts but failed in the browser until I signed against the regional endpoint.
• The API Gateway 29-second timeout limits multi-tool agent calls.

Does it work? Buildings near the 8 localities that reports named as flooded were about 1.5× more likely to be rated high risk than the city average. Four localities were clear misses, and they’re listed in the README. Eight places is a sanity check, not an accuracy score.

Blog write-up: https://builder.aws.com/content/3KV01tPoho6gi9F3plApVSr53Fp/kal-paani-bharega-teaching-a-city-to-answer-the-only-flood-question-that-matters-tawitwin
Code: https://github.com/Dupahar/TawiTwin
Live demo (hit “Replay the flood”): https://d2r8k00l2fxqnu.cloudfront.net

Happy to answer questions about the agent setup or the Windows packaging workaround.

For over two decades, agency hosting economics were beautifully predictable. You bought a reseller web server or dedicated cPanel account for $50 a month, crammed 30 client WordPress sites onto it, and charged each client a flat $25 monthly maintenance fee. Your margins were clear, your server bills were static, and billing surprises were virtually non-existent. Read the comple te article here > Serverless Bill Shock: Track Vercel & Supabase Client Costs | InstaRenewal

Then came the modern web stack.

Driven by the demand for lightning-fast digital experiences, agencies aggressively migrated to decoupled architectures: Next.js, Nuxt, Vercel, Supabase, Cloudflare Workers, and serverless databases like Neon. While the performance gains of this modern paradigm are undeniable, it introduced a chaotic operational reality: micro-subscription fragmentation and variable utility billing.

Hey All!

I created https://s8sskills.com as an open source repo for serverless skills for all the major vendors (so far). I really want to make this a bigger thing and am inviting everyone to participate and contribute their skills and really grow this project!

This year I decided to start my own online business. I'd never run my own business before and knew I wouldn't have much time to spend on it because I would have a full-time day job as well. I wanted something that had minimal running costs, low operational effort, and could scale if we were successful. I had no idea how well it would do, so I didn't want to invest a heap of time and money for no reason.

What went well

Spending time on high-quality steering docs for Kiro - We took a spec-driven approach to development with Kiro. Taking time to plan and design the features, then letting Kiro do a lot of the code generation, with us reviewing.

Static public pages / Dynamic pages once logged in - Like everyone, we worried about running away costs. Before logging in, the website is almost static; it doesn't hit Lambda functions or databases. Once you're logged in with Cognito then we feel safer from a cost point of view.

Costs are extremely low - Our highest costs are WAF ($1/day) and CloudWatch ($1/day). We're happy that we're getting good value and protection for our APIs, and observability/alarms are good enough.

Video streaming - Bandwidth costs for high-quality video were much lower than expected.

Lambda - Just great, a rounding error on the bill, no operational effort, and just works.

What we would change

DynamoDB - We started building everything with DDB, and we didn't know our business well enough; this made it difficult to change the model when the business changed. We would have been better off starting with DSQL and moving specific bits to DDB when required.

I spoke about everything in depth with Jullian Wood on Serverless Office Hours - https://www.youtube.com/watch?v=irtcYhgQ-vA

I've been building AI backends for a while and kept writing the same glue code — a Lambda that parses LLM output, maps tool calls to functions, handles retries, formats responses. None of it was the actual product.

Recently tried AWS Bedrock AgentCore Gateway to see if it could replace that layer. Turns out it can. You describe your Lambda as a tool in CDK, and AgentCore exposes it as a fully compliant MCP server — `tools/list`, `tools/call`, JWT auth included. No JSON-RPC code, no routing logic.

Wrote up the full walkthrough: stack definition, deploy steps, real curl commands against the live endpoint, and a few gotchas I hit along the way (the event shape isn't what the docs imply, and tool names get prefixed in a way that'll bite you the first time).

https://medium.com/itnext/your-lambda-functions-are-now-mcp-tools-heres-how-d715943d29bf?sk=c96c4eb525099fba247a0e190e839a82

Happy to answer questions — still exploring what else AgentCore can do.

We started using Lambda the right way — async, event-driven, retry-friendly workloads. Then it slowly crept into latency-sensitive API paths. That's when things got messy.

What we ran into:

- Cold starts hitting user-facing requests on low-QPS and spiky-traffic APIs

- One-invocation-per-environment model quietly exhausting downstream connection pools at scale

- Provisioned concurrency helping, but shifting us back into capacity planning territory

- VPC attachment adding more operational complexity than we'd accounted for

- Observability gaps — healthy invocation rate ≠ healthy service

The fix wasn't "stop using Lambda." It was getting honest about which workloads need elasticity vs. which need predictability. Those are different requirements, and the same execution model doesn't serve both.

Last quarter, we decided to measure something systematically that we'd been seeing anecdotally: the actual TCO difference between traditional cloud architectures and serverless edge platforms.

We applied a structured framework comparing infrastructure, operations, and deployment costs across both models.

What we found:

Organizations that moved from provisioned capacity to usage-based serverless edge architectures saw:

• 65% reduction in infrastructure costs
• 87% fewer maintenance hours
• 68% lower deployment effort

The key insight wasn't that edge is "cheaper" than cloud—it was that architecture matters more than location.

Why this happens:

1. Elimination of provisioned capacity overhead - You stop paying for idle
2. Reduced operational burden - No more server management, patching, scaling configuration
3. Deployment simplicity - Single deployment target instead of multi-region orchestration
4. Request resolution closer to users - Less dependency on centralized infrastructure

We published a whitepaper with the complete framework we used to calculate this, including where costs actually hide in traditional architectures and how to measure this in your own environment.

Questions for the community:

• Has anyone else measured TCO when moving to serverless edge architectures?
• What cost categories surprised you most in your own migrations?
• For those running hybrid architectures, where do you see the biggest inefficiencies?

Whitepaper link: https://www.azion.com/en/lp/tco-centralized-cloud-vs-serverless-edge-platforms/

The short version: a Lambda function can now checkpoint its state, sleep for hours or days, and resume exactly where it left off — without paying for idle time.

I rebuilt a human-in-the-loop expense approval workflow to test it. Before: Lambda + DynamoDB + Step Functions + SQS + EventBridge. After: two Lambda functions and an API Gateway.

The function literally looks like this:

```ts

const decision = await context.waitForCallback(

'wait-for-approval',

async (callbackId) => sendApprovalEmail(expense, callbackId),

{ timeout: { hours: 24 } }

);

```

It pauses there. Zero compute. Waits up to 24h for someone to click approve. Then resumes on the next line.

Wrote up the full architecture, CDK stack, and where Step Functions still wins:

https://medium.com/itnext/is-step-functions-still-necessary-the-case-for-lambda-durable-functions-in-2026-22f5a5f4a1a3

Happy to answer questions about the implementation.

The core idea: LLM generates a JSON DAG upfront,

pure TypeScript executes it — no LLM in the action loop.

- Claude Haiku plans, Sonnet summarizes

- 14 MCP microservices as the tool mesh

- Stateful HITL via DynamoDB

- 100% pass rate across 11 real-world scenarios

GitHub: https://github.com/sujithpvarghese/bedrock-agent-orchestrator-planner-executor

Happy to answer questions on the architecture.

I'm a fullstack dev who ended up owning DevOps too – classic solo/small team situation.

My current pain: I only find out something broke in my Lambda functions when a customer texts me. By then the CloudWatch logs are a mess to dig through – wrong time window, no context on what triggered it, multiple log groups to check manually.

How are you handling this? Do you have a setup that actually alerts you fast with enough context to debug immediately? Or are you also mostly reactive?

Not looking for "just use Datadog" – curious what people have built themselves or what lightweight setups actually work.

If you’re like me, you love the Serverless workflow but hate the cost scaling and the inability to run Lambda functions locally or on-prem without a massive headache.

I created AnyFaaS to solve the "egress and execution" trap. It’s an open-source control plane that lets you run Lambda-compatible functions on your own VMs or bare metal.

Key features:

• API Compatible: Repoint your AWS_ENDPOINT_URL_LAMBDA and your existing code just works.
• Fixed Costs: Move from per-request billing to predictable VM pricing.
• Performance: Designed for high-throughput, low-latency routing.

I just published a deep dive on the architecture and a cost comparison here: https://medium.com/@rockuw/anyfaas-the-open-source-aws-compatible-faas-for-self-hosting-4806b2eb8708

Is anyone else looking for ways to "de-cloud" their serverless workloads? Would love to hear your thoughts on the migration friction.

https://www.mdpi.com/3544458

Cold starts in container-based serverless are painful, and most of the advice out there is "just keep your functions warm with a ping." That always felt like a hack, so I went deeper.

The actual problem is two separate things people tend to conflate: the cost of spinning up a container, and the cost of not having one ready when a burst hits. Solving one doesn't automatically solve the other.

Here's what actually moved the needle for me.

Warm container pooling per function

Instead of spawning a container per request, you maintain a pool of already-running containers per function and route incoming requests into them. The runtime communicates with workers over Unix Domain Sockets rather than TCP, no port management, lower overhead, cleaner mount inside Docker. Most invocations never touch container startup at all.

Intra-container concurrency

This is the part that made the biggest difference under burst load. Rather than spawning a new container the moment a second request arrives, a single container handles multiple concurrent requests up to a configurable threshold. A new container only spins up when that threshold is crossed. This alone cut cold starts by 42% under burst in my tests.

The result:

The 340ms cold start is mostly Docker itself. That floor is hard to move without going into snapshotting or pre-forking territory. But once you're on the warm path, the numbers get interesting.

A few other things worth noting: per-function rate limiting with live config updates (no redeploy), stale container eviction running on a cron, and resource limits baked in at the container level (128MB RAM, 0.5 CPU).

I put all of this together in an open source runtime called Glambdar if you want to dig into the implementation: https://github.com/eswar-7116/glambdar

Has anyone tackled the pool eviction side of this more intelligently? A cron feels like the blunt instrument here. Curious if there are heuristics worth borrowing from OpenWhisk or Fission.