标签：#AWS

Most S3 bills are wrong, and the fix takes an afternoon. The data sits in the most expensive class AWS offers (S3 Standard, $0.023/GB-month), nobody set a lifecycle policy, incomplete multipart uploads are silently billing for storage you can't even see in the console, and every byte your EC2 fleet pulls from S3 is routed out through a NAT Gateway when a free VPC Gateway Endpoint would do the same job for $0. None of this needs an architecture rewrite. It needs a checklist run in the right order. Here is the order. The savings depend entirely on your access pattern — I will not promise you a number I can't see — but the mistakes below are so common that the question is usually how much , not whether . One number is just arithmetic: cold data that moves from S3 Standard ($0.023/GB-month) to Glacier Deep Archive ($0.00099/GB-month) drops about 96% on the storage line for those bytes, and on an observability platform I ran — logs aged past 90 days into Deep Archive — that is exactly the lever that did the work. S3 cost optimization is the same boring discipline as the rest of the bill: see it, then decide what each byte should actually cost. First, see the bill before you touch it You cannot optimize what you cannot measure, and S3's default billing view tells you nearly nothing useful. Turn on S3 Storage Lens before anything else. The free tier gives you 62 metrics at the bucket level with 14 days of history, and crucially it includes cost-optimization metrics out of the box — including "Incomplete multipart upload bytes greater than 7 days old," which is the single most common source of money disappearing into storage nobody knows exists ( AWS S3 Storage Lens docs , accessed 2026-06-18). Storage Lens free metrics answer the three questions that decide everything that follows: Which buckets hold the most bytes? What storage class is that data sitting in right now? Where are the incomplete multipart uploads? For deeper per-prefix analysis or a longer history, Advanced

For AWS Savings Plans vs Reserved Instances, the default answer is: buy a Savings Plan, not a Reserved Instance. The exception is OpenSearch, Redshift, and (until December 2025) databases, which still need the older Reserved model. That is the whole decision. For most teams a Compute Savings Plan is the right default: same discount as a Convertible Reserved Instance, far less to manage, and it follows your workload across instance families, regions, Fargate, and Lambda. The cases where a Reserved Instance still wins are narrow and specific, and the December 2025 launch of Database Savings Plans shrank them further. This post is the decision — RI vs Savings Plan, when each wins. It is not a deep-dive on how Savings Plans work under the hood; I cover the mechanics — how the $/hour commitment gets applied, the billing-hour math, the queue order against On-Demand — in a separate post. Here I only want to answer the question you actually have when the Cost Explorer recommendation pops up: which one do I buy? (Commitments are step three of a full bill audit — where they sit in the order is in what I'd audit first on a $50K AWS bill .) The short version Both Reserved Instances and Savings Plans are the same trade: you promise AWS a one- or three-year commitment, AWS gives you a discount over On-Demand. The difference is what you commit to . A Reserved Instance commits you to a specific instance configuration — family, and depending on type, size, region, OS, tenancy. A Savings Plan commits you to a dollar amount of usage per hour (e.g. "$10/hour of compute"), and AWS applies that discount to whatever matching usage you actually run. The Savings Plan is the more flexible instrument at the same discount level, which is why AWS itself now recommends Savings Plans over Reserved Instances for compute. ( AWS, Compute Savings Plans and Reserved Instances , accessed June 2026.) The Reserved Instance has not gone away — but for EC2 compute, it is mostly the legacy choice now. The d

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Give me read access to a $50,000/month AWS account and I will tell you within a day where the first 20-30% is hiding, because on a mid-size bill it is almost always hiding in the same four places, in the same order: data transfer you can't see in the console, instances sized for a load test that ran two years ago, on-demand pricing on a baseline that never moves, and storage rotting in the most expensive class AWS sells. None of this needs an architecture rewrite. AWS cost optimization, at least the first and biggest pass of it, is just the bill read in the right order by someone who knows where AWS buries the meter. This is the order I work. It is the same audit I run on every account I'm handed, and it is the offer — if you want me to run it on yours, the post ends with how. But you can run most of it yourself today, and you should, because nobody is going to care about your bill as much as you do. A note before the recipe: I deal in ranges, not promises. The exact saving on your account depends on what you've built. What I can promise is that the mistakes below are common enough that the question is usually how much , not whether . Hour zero: get the real bill, not the dashboard Before touching a single resource, I want the granular data. The AWS console's cost dashboard rounds, groups, and hides the things that matter. Two tools give you the truth. Cost Explorer , with rightsizing recommendations turned on, is the fast view — group by service, then by usage type, and the bill stops being one big number and starts being a list of decisions. Resource-level and hourly granularity costs extra ($0.01 per 1,000 usage records per month), but for one audit pass it's worth pennies. The Cost and Usage Report (CUR) is the ground truth — line-item, hourly, every charge AWS makes, delivered to your own S3 bucket. Generating it is free; you pay only the few cents of S3 storage. If you're going to do this seriously, set up CUR (now delivered via AWS Data Exports) on day one. E

Most guides for connecting Spark to Amazon MSK assume the two live in the same cloud and authenticate with IAM. That covers a lot of cases. It does not cover the one that keeps showing up in large enterprises: the Kafka cluster is in AWS, the compute is Azure Databricks, IAM is off the table because the identity system is a corporate PKI, and the traffic never touches the public internet. This walks through that setup end to end. Certificates from a private CA, a private network path between the two clouds, and a Structured Streaming job that actually keeps running on a multi-node cluster instead of only on the driver. Why mTLS instead of IAM MSK offers four authentication modes: plaintext, TLS with client certificates, SASL/SCRAM, and IAM. IAM is the easiest and the best choice when your consumers run in AWS. Cross-cloud, IAM stops being convenient. Azure Databricks executors have no AWS identity. You can bolt one on with OIDC federation and assumed roles, but in most regulated enterprises the decision has already been made elsewhere: there is a corporate PKI, every service-to-service hop uses client certificates issued from it, and the security architecture review is going to ask why this one connection is different. mTLS is the path of least resistance, not the clever choice. One important constraint before you start. MSK will only accept client certificates issued by an AWS Private CA (ACM PCA) that is associated with the cluster. If your corporate PKI is not that CA, you have two options: stand up an ACM PCA subordinate signed by your corporate root, or issue the Databricks client certificate from a dedicated ACM PCA and treat it as a separate trust domain. The subordinate route is usually what security wants, and it takes longer to get approved than everything else in this article combined. Start that conversation first. Network path Three ways to get private connectivity between an Azure VNet and an AWS VPC: Site-to-site VPN. IPsec tunnel between an Azure VPN

Level 300 Some time ago we created a blog showing the capabilities of AI DLC and SDD to create quick and efficient prototypes as a MVP, the results were amazing, however, we omitted something: DevSecOps best practices and CICD for the workload. The prototype was built with a serverless framework and modern cloud-native application patterns. However, moving from a working MVP to a production-ready solution requires stronger alignment with DevSecOps, CI/CD, and operational excellence. That transition leaves several important questions open: Security posture • What security vulnerabilities exist in the solution? • Is the platform ready to withstand common web attacks? Code quality and production readiness • What is the overall quality of the code? • Is this truly an example of an enterprise-ready solution? Cloud compliance and misconfiguration risk • Which cloud security compliance gaps still need to be addressed? • Are there misconfigurations that could create operational or security risk? The other side of this challenge is organizational readiness. Many companies are enabling development teams with assistants such as Kiro, Claude, Cursor, and similar tools. However, without a mature process to review, scan, govern, and manage code at scale, these tools can introduce high costs, expand security risks, and growing technical debt. For the Agentic AI era, DevSecOps maturity is no longer optional. A secure software development lifecycle, policy-driven development, and zero-trust principles must become core operating requirements rather than afterthoughts. Open loop – Starter point a classical DevSecOps CICD system Suppose that the company already has a continuous integration and delivery framework and tools for that kind of workload with classical tools, in terms of maturity level and L3 Defined and Managed here we have Security gates integrated in CI/CD; SAST/SCA/secrets/IaC; centralized findings; quality gates. The maturity model we use We measure against a five-level

So now that you have a basic understanding of how Terraform works , before you start running any terraform command against a real AWS account, two things need to happen: you need an identity Terraform can authenticate as, and you need a mental picture of what you're about to create, so the plan output in Part 4 isn't just a list of unfamiliar resource names. Never Use Your AWS Root User! The root user (the email/password you signed up to AWS with) can do anything , including closing the account. It should basically never be used day-to-day. Instead, create a dedicated IAM user just for this project. In real life you would create a dedicated IAM user for your CI/CD pipeline to automate deployments: AWS Console → IAM → Users → Create user (e.g. terraform-voting-app ). Do not enable AWS Console access, this user only needs programmatic access, i.e. an API key pair. The AWS managed policy AdministratorAccess is the path of least friction, and is what you should use for the IAM user to test things out. but in real life you would go with least privilege approach, learn more about it in AWS EKS IAM policy examples . On the user's Security credentials tab → Create access key → choose "Command Line Interface (CLI)". You'll get an Access Key ID and a Secret Access Key , store them somewhere safe, we will be needing them later. Give Terraform those Credentials The rule: credentials never go inside a .tf file, and never inside terraform.tfvars . So in your local machine or CI/CD pipeline you need to export AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , and AWS_REGION as environment variables in the shell. Then you won't be needing aws configure or aws login step anywhere, the aws provider has no access_key / secret_key arguments of its own, so it falls back to the AWS SDK's standard credential chain, which checks these exact environment variables first. The AWS CLI and, later kubectl read the same variables. In my local machine I do export an env variable files using a shell scrip

Ved Prajapati Principal Generative AI Architect | Founder, Vedaris Abstract The increasing reasoning capabilities of large language models (LLMs) create opportunities to extend DevOps automation beyond deterministic pipelines toward systems capable of interpreting context, delegating tasks, evaluating outputs, and coordinating decisions. However, relying on a single autonomous agent introduces challenges in task specialization, context management, reliability, security, and workflow control. This paper presents the architecture and implementation of an autonomous multi-agent DevOps automation platform designed to coordinate specialized artificial intelligence agents across code review, security analysis, and deployment workflows. The system uses LangGraph to provide stateful agent orchestration and inter-agent communication, the Groq API for model inference, AWS Lambda for serverless execution, Amazon DynamoDB for persistent workflow state, and Amazon EventBridge for event-driven workflow initiation. Rather than assigning an entire DevOps lifecycle to a single general-purpose agent, the proposed architecture decomposes the workflow into specialized agents operating within a shared orchestration layer. Each agent is responsible for a defined domain and contributes its findings to the overall workflow state before subsequent actions are taken. The architecture demonstrates how multi-agent specialization, stateful orchestration, and event-driven cloud infrastructure can be combined to create extensible AI-assisted DevOps workflows. It also identifies important production considerations including agent reliability, authorization boundaries, observability, failure recovery, human approval, model hallucination, and the appropriate boundary between probabilistic AI reasoning and deterministic automation. Keywords: Generative AI, Agentic AI, Multi-Agent Systems, DevOps Automation, LangGraph, Large Language Models, AWS Lambda, Amazon DynamoDB, Amazon EventBridge, Cloud Archi

Who hasn't built a full-stack app on AWS before, we all know the drill. You need an API (usually Lambda with API Gateway), a frontend, some authentication (Cognito) wired up, and IaC (CDK) to help deploy the app. On their own, none of that is hard, but wiring it up all together, especially in a team where every developer has their own style, always takes an amount of time before you even get to write a single line for the business logic. Nx Plugin for AWS ( @aws/nx-plugin ), an AWS Labs open source project, tackles that problem with code generators built on top of Nx . Instead of once again writing out boilerplate for every new service or website, you can just run a generator (CLI), answer a few questions, and get production-ready application code plus the CDK or Terraform to deploy it. This article introduces what the plugin does, the core concepts, and how to scaffold a complete full-stack app. What sets Nx Plugin apart from just another scaffolding tool? A note on versioning: at time of this article the plugin was pre-1.0, currently working through a 1.0.0-rc.x release candidate series with regular updates. Commands and generator names below were accurate at time of writing, check npm view @aws/nx-plugin version before you start, given the pace, it's likely to have moved on since this article published. A quick primer on Nx For the uninitiated Nx is a toolkit specifically for monorepos. Two things define Nx: A dependency graph across projects. Nx knows how the individual parts of your projects relate to each other (which website depends on which API, which library is shared where), and it uses that graph to only build, test, or lint the things actually affected by a change, with results cached so recurring CI/CD runs should be fast. Generators. Nx has a plugin system where a package can register generators, scripts that scaffold or modify code in your workspace, invoked via the nx g (or nx generate ) command. This is the bit @aws/nx-plugin builds on. Nx is not AW

Who hasn't built a full-stack app on AWS before, we all know the drill. You need an API (usually Lambda with API Gateway), a frontend, some authentication (Cognito) wired up, and IaC (CDK) to help deploy the app. On their own, none of that is hard, but wiring it up all together, especially in a team where every developer has their own style, always takes an amount of time before you even get to write a single line for the business logic. Nx Plugin for AWS ( @aws/nx-plugin ), an AWS Labs open source project, tackles that problem with code generators built on top of Nx . Instead of once again writing out boilerplate for every new service or website, you can just run a generator (CLI), answer a few questions, and get production-ready application code plus the CDK or Terraform to deploy it. This article introduces what the plugin does, the core concepts, and how to scaffold a complete full-stack app. What sets Nx Plugin apart from just another scaffolding tool? A note on versioning: at time of this article the plugin was pre-1.0, currently working through a 1.0.0-rc.x release candidate series with regular updates. Commands and generator names below were accurate at time of writing, check npm view @aws/nx-plugin version before you start, given the pace, it's likely to have moved on since this article published. A quick primer on Nx For the uninitiated Nx is a toolkit specifically for monorepos. Two things define Nx: A dependency graph across projects. Nx knows how the individual parts of your projects relate to each other (which website depends on which API, which library is shared where), and it uses that graph to only build, test, or lint the things actually affected by a change, with results cached so recurring CI/CD runs should be fast. Generators. Nx has a plugin system where a package can register generators, scripts that scaffold or modify code in your workspace, invoked via the nx g (or nx generate ) command. This is the bit @aws/nx-plugin builds on. Nx is not AW

A tool claiming "up to 15x faster than cdk deploy" showed up in my feed a while back. Drop-in replacement, it said: keep your CDK app exactly as it is, just swap cdk deploy for cdkd deploy . I've learned to be skeptical of "Nx faster" claims. So I actually deployed something real to AWS with both tools and timed it. Short version: it really is that fast. What cdkd actually is cdkd deploys an existing AWS CDK app without going through CloudFormation. It calls the AWS SDK directly instead. It's built by go-to-k (Kenta Goto), an AWS DevTools Hero and CDK top contributor who also maintains cls3 (a fast S3 bucket emptier) and delstack (for cleaning up stuck CloudFormation/CDK stacks) — tools that quietly fix the annoying parts of working with AWS. cdkd feels like the biggest one yet, and I mean that as a compliment grounded in actually using it, not a throwaway one. The mechanism is straightforward. cdkd runs the exact same CDK synth step as the CDK CLI, producing the same CloudFormation template. What changes is everything after that: instead of handing the template to CloudFormation, cdkd's own engine reads the resource dependency graph ( Ref , Fn::GetAtt ), builds a DAG, and fires AWS SDK / Cloud Control API calls directly, in parallel, as soon as each resource's dependencies are satisfied. Worth saying up front: cdkd calls itself not production-ready, dev/test only. This isn't a "replace CloudFormation in prod" pitch. I actually ran both, on real AWS cdkd's own README backs up the 15x number with a VPC + Lambda + SQS + CloudFront benchmark. So I wrote that same stack as a CDK app and deployed it twice — DeployRaceCfn via cdk deploy , DeployRaceCdkd via cdkd deploy — to the same AWS account, same region (ap-northeast-1). The stack: VPC (2 AZ + NAT Gateway) with a Lambda inside it, fronted by a Function URL CloudFront, origin set to that Function URL SQS + EventSourceMapping + a consumer Lambda First attempt failed. The account had hit its VPC limit (five, the default)

TL;DR I recently finished a project from Udacity's Future AWS Agent Engineer Nanodegree Program,...

AI apps have moved past simple chat boxes. Today's AI systems need agents, tools, memory, data, security, monitoring, and scale. The hard part is not calling an LLM API. The hard part is building a reliable system around that API call. 1. From LLM Demo to Production System A demo is simple: flowchart LR A[Prompt] --> B[Model] --> C[Response] A real production system looks very different: flowchart TD U[User] --> API[API] API --> APP[Application Layer] APP --> ORCH[AI Orchestration] ORCH --> LLM[LLM] ORCH --> TOOLS[Tools] ORCH --> RAG[RAG] ORCH --> MEM[Memory] ORCH --> GUARD[Guardrails] ORCH --> DATA[Data + Infrastructure] DATA --> OBS[Observability] Each box matters. If you skip Guardrails , bad input can hijack your system. If you skip Memory , every message re-explains itself and costs more tokens. If you skip Observability , you won't know why the system failed until a user tells you. The rest of this article walks through each box. 2. Where AWS Fits Instead of listing AWS services, let's match each one to a real problem. Problem AWS Service Why Need a foundation model Amazon Bedrock Managed access to multiple LLMs, no infra to run Store documents and files S3 Cheap, durable, scales easily Store app data RDS / Aurora / DynamoDB Structured data, users, sessions, transactions Search by meaning (retrieval) OpenSearch / pgvector Vector search for RAG Run code Lambda / ECS Serverless or container compute for your app logic Handle async work SQS / EventBridge Queue jobs, decouple slow tasks, avoid lost requests Watch the system CloudWatch Logs, metrics, alarms Keep it secure IAM / Secrets Manager Access control and safe storage of keys flowchart LR subgraph Compute L[Lambda / ECS] end subgraph Data S3[(S3)] DB[(RDS / DynamoDB)] VEC[(OpenSearch / pgvector)] end subgraph AI BR[Bedrock] end subgraph Ops CW[CloudWatch] SEC[IAM / Secrets Manager] end L --> BR L --> S3 L --> DB L --> VEC L --> CW L --> SEC 3. AI Agents Change the Architecture An agent doesn't just answer — i

The US government wrote a letter in support of OpenAI’s argument that training AI on others' intellectual property is fair use.

I spent years supporting WorkMail and SES at AWS, and even became a Subject Matter Expert in both services. Here's how I moved my own mail off it, start to finish... and got sentimental doing it. Level: 200 (intermediate). Assumes you're comfortable with the AWS CLI, IAM roles, S3, and KMS. Amazon WorkMail is winding down... AWS has announced end of support for March 31, 2027. If you're running a mailbox or two on WorkMail, now is a good time to think about where that mail is going to live next. In my case, I'm moving my domain's mail over to Google Workspace, and I wanted to bring years of old email along for the ride. I'll be straight with you up front, though... this one's personal, and writing a guide to leave WorkMail behind is genuinely bittersweet. I'll get into why at the end... but first, let's do the work. Here's the important part... WorkMail gives you a clean, supported way to get your mail out: the StartMailboxExportJob API. It drops every message into an S3 bucket as a KMS-encrypted .zip of standard .eml files. From there, getting those messages into Gmail is just a matter of speaking IMAP. In this post, we're going to walk through the whole path... exporting the mailbox, wiring up the IAM and KMS pieces the export needs, downloading and inspecting the archive, uploading everything into Gmail with a small Python script, bringing the calendar over, tearing WorkMail down when you're done, and finally locking the domain down with SPF, DKIM, and DMARC so your new Gmail-hosted mail actually lands. Along the way I'll call out the gotchas that cost me time, so they don't cost you any. The shape of the solution Before we touch a command, let's set the mental model. There are two halves to this migration: Get the mail out of WorkMail. StartMailboxExportJob writes an encrypted .zip to S3. This needs a KMS key and an IAM role the WorkMail export service can assume. Get the mail into Gmail. Gmail speaks IMAP, and IMAP has an APPEND command that uploads a raw messa

The outage that teaches you deployment A service passes every test locally. It fails in staging because the API calls localhost:5432 for Postgres — but Postgres is in another container, reachable only as db:5432 . This is not a Docker problem. It is a boundary problem: your code assumed an environment it does not own. Engineers who have shipped on AWS Lambda already avoid a class of these mistakes. They never SSH into a function to hot-fix. They inject config at deploy time. They treat each invocation as disposable. Containers reward the same discipline with different vocabulary. This article maps what transfers, what breaks, and what I require before any Python backend goes to production in a container. What serverless already taught you Immutable deployments Lambda versions are replaced, not patched. Container images work the same way: build a new image, roll out, roll back by tag. If your incident runbook includes "edit files inside the running box," you have a design problem. Configuration at runtime Secrets belong in Secrets Manager or injected env vars — not in source control, not in the image layer cache. Docker does not change the rule; it changes where you mount the values. Single responsibility per unit One Lambda, one job. One container, one main process. Compose and Kubernetes add orchestration; they do not remove the rule. Cold start awareness Slim packages on Lambda map to slim base images ( python:3.12-slim , multi-stage builds). Startup time affects autoscaling and health-check windows the same way cold starts affect user-facing latency. If you understand why a Lambda deployment package should stay small, you understand why a 2 GB container image is a liability. Where the mental model breaks 1. Network identity Inside Compose or Kubernetes, localhost is the container itself. Services discover each other by DNS name ( api , db , redis ). This is the most common first-production failure I see in teams moving from bare metal or single-host deploys. 2. P

AWS has announced revisions to two of its most popular certifications: Solutions Architect – Professional (SAP-C02 → SAP-C03) and Developer – Associate (DVA-C02 → DVA-C03) . This article collects what is publicly known right now, from the official blog post and the certification pages. Neither exam guide is published yet. The official blog states that the full exam guide, including detailed task statements, will be released on October 27, 2026, when registration opens. Everything below is based solely on the official blog (English and Japanese editions) and the certification pages. I'll update this article once the guides are out. 1. SAP-C03 (Solutions Architect – Professional) Dates and format Item Detail Registration opens October 27, 2026 (all languages) Last day to take SAP-C02 November 16 — see note below SAP-C03 available November 17 Duration 180 minutes Questions 75 Price 300 USD The format is unchanged from the current exam. Why the revision The blog states that today's architects "don't just design highly available, cost-effective systems — they integrate generative AI and agentic architectures and implement post-quantum cryptography." What's being added Area New skills Content Generative AI and agentic AI 11 Generative AI integration design with Amazon Bedrock, AI agent architectures with Amazon Bedrock AgentCore , RAG architectures, content filtering with Bedrock Guardrails , human-oversight workflows for AI operations Resilience engineering — AWS Fault Injection Service, AWS Resilience Hub, Application Recovery Controller, automated runbooks with Systems Manager Cloud-native patterns 7 Serverless data pipelines, durable workflows with Step Functions, service mesh with VPC Lattice and ECS Service Connect , container image security, multi-tenant architectures, real-time data architectures DevSecOps and observability 6 Pipeline vulnerability scanning, multi-account deployment pipelines, container monitoring, AI/ML metrics monitoring, synthetic monitoring an

While building HarvestIQ , I started paying much more attention to how backend architecture affects the way a product can be built, deployed, and scaled. HarvestIQ is an agriculture platform designed to help smallholder farmers access post-harvest intelligence, including market prices and buyer opportunities. One of the interesting parts of the project is that a farmer can interact with the system through USSD , without requiring a smartphone or an internet connection. The backend is built around a serverless architecture using AWS services. This article breaks down how that architecture works and what I have learned from building it. What does "serverless" actually mean? The name can be misleading. Serverless does not mean that there are no servers. The servers still exist. AWS manages the underlying infrastructure, while I focus on writing and deploying the application code. Instead of maintaining an always-running backend server, different parts of the application can run when they are needed. For HarvestIQ, this works particularly well because many operations are event-driven. A farmer makes a request. A function executes. Data is retrieved or updated. The function finishes. Another event can trigger another function later. HarvestIQ's Serverless Architecture The simplified architecture looks like this: Farmer | USSD | v Africa's Talking | v AWS Lambda / \ / \ v v DynamoDB Response EventBridge | v AWS Lambda | v Price / Alert Logic | v SNS | v SMS | v Farmer Each AWS service has a specific responsibility. AWS Lambda handles application logic. DynamoDB stores application data. EventBridge triggers scheduled operations. SNS handles notifications. Africa's Talking provides the USSD and SMS connectivity layer. Let's look at each part. 1. USSD as the Entry Point One of the design goals of HarvestIQ is accessibility. A farmer should not necessarily need: A smartphone A mobile application Mobile data A web browser A basic mobile phone with cellular connectivity can be

The AWS API has become infrastructure's common language, and a whole ecosystem has grown up around running it somewhere other than AWS. Some tools mock it for testing. Others implement it for real. Knowing which is which saves you from deploying a dev tool to production or wiring a production platform into your CI pipeline. Two categories The tools split into emulators and real cloud platforms. Emulators intercept AWS API calls and return plausible responses without provisioning real infrastructure, where state is usually ephemeral, VMs never boot, and the goal is behavioural approximation fast enough for a developer's inner loop. Real cloud platforms provision actual infrastructure where EC2 calls boot real virtual machines and block storage carries real persistence guarantees. Emulators Moto Moto ( github.com/getmoto/moto , Apache 2.0, 8,400+ stars) has been around since 2013, making it the oldest option here. It works differently from the rest because rather than running a local server, it patches boto3 calls in-process through a test decorator. A function wrapped in @mock_aws intercepts all AWS SDK calls and returns mock responses without any network traffic. This makes it fast and easy to drop into Python test suites, but it only works for Python. Teams using the AWS CLI, Terraform, or Go SDKs need a server-based option. LocalStack LocalStack ( github.com/localstack/localstack , 64,000+ stars) is the dominant name in local AWS development. It runs as a Docker container exposing the AWS API on localhost:4566 and covers over 120 services. In March 2026, LocalStack archived its Community Edition repository and moved core services behind a paid plan. A free tier remains for non-commercial use and open source projects, but the Base plan covering Cloud Pods persistent state costs $39 per month and the Ultimate plan runs $89 per month. Teams that depended on CE for commercial CI pipelines are now evaluating alternatives. Floci Floci ( floci.dev , github.com/floci-io/f

This article provides a step by step comparison of three Gemma 4 deployments on a single AWS hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of each deployment, and one benchmark harness is shared across all three so that the runtime is the only variable. https://github.com/xbill9/gemma4-dev The whole exercise cost under three dollars, and that is the part worth keeping. Nineteen instances and about four and a half instance-hours bought three serving sweeps, nine timed boots and a handful of A/B restarts. It also bought five wrong claims, each caught by measuring instead of reasoning. On hardware where a run is expensive, the cheapest of those five would have shipped with a caveat attached. What is this project trying to Do? Three rigs in this monorepo serve google/gemma-4-E2B-it on an AWS G5g instance. One runs vLLM, one runs a pure JAX port, one runs PyTorch with transformers. The hardware is identical and only the runtime slot moves, so this should be the cleanest A/B available. For months it was not, because each rig measured itself with its own harness and quoted its own number. Three harnesses computing three statistics is not a comparison. Prerequisites An AWS account with G-family quota in us-east-1 . Each g5g.2xlarge is 8 vCPU, so 16 vCPU of spot quota runs two at once. A subnet, a security group opening TCP 8000, and an instance profile carrying AmazonSSMManagedInstanceCore plus read on the Hugging Face token secret. A Hugging Face token in Secrets Manager. It is fetched at boot into a root-only EnvironmentFile and never appears in user data. boto3 and the standard credential chain. No AWS CLI shell-outs, no inbound SSH rule, and no private key anywhere in the flow. AWS EC2 G5g Instance g5g.2xlarge — 8 vCPU, 16 GiB host Host CPU AWS Graviton2, aarch64 GPU 1x NVIDIA T4G, Turing, SM 7.5 GPU memory 15,360 MiB per nvidia-smi ; AWS lists 16,384 nominal G5g is the only family AWS ships that puts an NVIDIA GPU behind a Gravi