DEV Community: Mwanza Simi

S3 Files Killed My Least Favorite Lambda Pattern

Mwanza Simi — Thu, 21 May 2026 10:26:47 +0000

Every Lambda function I have written that touches S3 has the same three lines of plumbing:

s3.download_file(bucket, key, "/tmp/input.csv")
process("/tmp/input.csv", "/tmp/output.csv")
s3.upload_file("/tmp/output.csv", bucket, output_key)

Download. Process. Upload. Clean up /tmp. Handle the edge case where /tmp is full from a previous invocation. Handle the edge case where the download fails halfway. Handle the edge case where you run out of the 10 GB ephemeral limit because someone uploaded a file larger than you expected.

S3 Files makes all of that go away. You mount the bucket at /mnt/workspace and use open(). The file is right there. You write the output. It syncs to S3.

The Problem It Solves

Lambda functions that process files from S3 have always followed the same ritual:

Download the object from S3 to /tmp
Process it with whatever tool expects a file path
Upload the result back to S3
Clean up /tmp so the next invocation doesn't run out of space

This works. It also creates problems.

/tmp is ephemeral. It's limited to 10 GB. It's not shared between invocations on different execution environments. If your function fails halfway through processing, you retry the entire download. If multiple functions need the same reference file, each one downloads its own copy.

For a single CSV transform, the overhead is tolerable. For a pipeline that processes PDFs, images, video, or runs tools like ffmpeg, imagemagick, trivy, or semgrep, the download-process-upload loop becomes the majority of your code and the majority of your execution time.

S3 Files eliminates the loop. Your function mounts the bucket and reads files directly.

How It Works

S3 Files is a managed NFS v4.1+ file system built on Amazon EFS that presents your S3 bucket as a directory tree. When you mount it on a Lambda function, the function sees files and directories at /mnt/your-path. Under the hood, the data still lives in S3.

The architecture uses what AWS calls "stage and commit":

Your function reads and writes files through the NFS mount
An EFS caching layer stores actively accessed data for low-latency access (~1ms)
Changes written through the mount are exported back to S3 within minutes
Changes made directly through the S3 API appear in the file system within seconds (sometimes longer)

The two layers are explicitly separate. The file system side gives you NFS close-to-open consistency. The S3 side gives you standard strong consistency. Each preserves its own semantics.

For large sequential reads (1 MiB or larger), S3 Files bypasses the cache entirely and streams data directly from S3 using parallel GET requests. This means ML training data, large CSVs, media files, and Parquet datasets get full S3 throughput without paying the cache premium. Files smaller than 128 KB (configurable) are the ones that get stored on the high-performance layer for low-latency access.

What It Looks Like

The old way:

import boto3
import csv
import os

s3 = boto3.client("s3")

def handler(event, context):
    bucket = event["bucket"]
    key = event["key"]
    output_key = key.replace("incoming/", "processed/")

    s3.download_file(bucket, key, "/tmp/input.csv")

    with open("/tmp/input.csv", newline="") as src, \
         open("/tmp/output.csv", "w", newline="") as dst:
        reader = csv.DictReader(src)
        writer = csv.DictWriter(dst, fieldnames=["email", "account_id"])
        writer.writeheader()
        for row in reader:
            writer.writerow({
                "email": row["email"].strip().lower(),
                "account_id": row["account_id"].strip()
            })

    s3.upload_file("/tmp/output.csv", bucket, output_key)

    os.remove("/tmp/input.csv")
    os.remove("/tmp/output.csv")

    return {"output": output_key}

The new way:

import csv
from pathlib import Path

WORKSPACE = Path("/mnt/workspace")

def handler(event, context):
    source = WORKSPACE / event["relative_input_path"]
    target = WORKSPACE / event["relative_output_path"]
    target.parent.mkdir(parents=True, exist_ok=True)

    with source.open(newline="") as src, target.open("w", newline="") as dst:
        reader = csv.DictReader(src)
        writer = csv.DictWriter(dst, fieldnames=["email", "account_id"])
        writer.writeheader()
        for row in reader:
            writer.writerow({
                "email": row["email"].strip().lower(),
                "account_id": row["account_id"].strip()
            })

    return {"output_path": str(target)}

No boto3. No temporary files. No cleanup. The output is written directly to the mounted S3 bucket and syncs back to S3 automatically.

The real win shows up when the processing step isn't a simple CSV transform. If your function shells out to git, ripgrep, ffmpeg, trivy, or any tool that expects a filesystem path, a mounted workspace is simpler than teaching every tool to speak S3.

The Setup

S3 Files on Lambda requires more infrastructure than a plain S3 trigger. Here's what you need:

Requirements:

An S3 file system created on a general purpose bucket (S3 versioning must be enabled)
Mount targets in the same VPC and Availability Zones as your Lambda function
Security groups allowing NFS traffic on port 2049
Lambda function connected to the VPC
Execution role with s3files:ClientMount (and s3files:ClientWrite for write access)
s3:GetObject and s3:GetObjectVersion for direct read optimization
Function memory set to 512 MB or higher (required for direct reads from S3)

The SAM template:

Resources:
  ProcessingFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: FileProcessorFunction
      CodeUri: ./src
      Handler: index.handler
      Runtime: python3.13
      MemorySize: 512
      Timeout: 300
      VpcConfig:
        SecurityGroupIds:
          - !Ref LambdaSecurityGroup
        SubnetIds:
          - !Ref PrivateSubnet1
          - !Ref PrivateSubnet2
      FileSystemConfigs:
        - Arn: !GetAtt S3FilesAccessPoint.Arn
          LocalMountPath: /mnt/workspace
      Policies:
        - Statement:
            - Effect: Allow
              Action:
                - s3files:ClientMount
                - s3files:ClientWrite
              Resource: "*"
            - Effect: Allow
              Action:
                - s3:GetObject
                - s3:GetObjectVersion
              Resource: !Sub "arn:aws:s3:::${BucketName}/*"

The VPC requirement is the biggest change from a standard Lambda + S3 setup. If your function isn't already in a VPC, you need to add subnets, security groups, and NAT gateways (if the function also needs internet access). That's not trivial for existing deployments.

When to Use S3 Files vs. the Old Pattern

Use S3 Files when:

Your function processes files with tools that expect filesystem paths (ffmpeg, imagemagick, PDF libraries, git, security scanners)
Multiple Lambda functions need shared access to the same working directory
You are tired of managing /tmp size limits and cleanup logic
The function reads large reference datasets that don't change between invocations
You want to eliminate the download-process-upload ceremony

Keep using GetObject + /tmp when:

Your function reads one object, transforms it in memory, and writes one object back
The function is a simple event handler that processes JSON payloads
You need the lowest possible cold start latency (VPC adds ~100-200ms)
Your function doesn't need filesystem semantics at all
The workload is latency-sensitive and can't tolerate the VPC mount dependency

The mental model is straightforward. If your code has download_file followed by upload_file and the processing step uses file paths, S3 Files removes that plumbing. If your code streams objects through memory without touching the filesystem, S3 Files adds complexity for no benefit.

What You Pay

S3 Files pricing has three layers on top of your existing S3 storage costs:

Component	Rate	What triggers it
S3 Standard storage	~$0.023/GB-month	All data in the bucket (unchanged)
High-performance cache	~$0.30/GB-month	Only actively cached data, not the whole bucket
Data access (reads)	~$0.03/GB	Small file reads from cache
Data access (writes)	~$0.06/GB	Writes through the mount

The critical detail: large sequential reads (1 MiB+) bypass the cache entirely and cost only standard S3 GET request pricing. No S3 Files surcharge.

Practical example: You have a 1 TB bucket. Your Lambda functions actively work with 50 GB of files through the mount. Most reads are large Parquet files.

Component	Cost
S3 storage (1 TB)	$23.55
Cache storage (50 GB active)	$15.00
Data access (small file reads)	~$0.50
Data access (writes, 20 GB)	~$1.20
Total	~$40/month

The same 1 TB on EFS would cost ~$300/month. S3 Files costs a fraction because you only pay the cache premium on the active working set, not the entire dataset.

Small operations have metering minimums. Data access operations are metered at a minimum size (reported as 32 KB in early testing). Reading a 1-byte config file gets metered for more than 1 byte. For workloads with millions of tiny metadata-heavy operations, those minimums add up.

Things to Know Before You Build

The sync window isn't instant. Changes written through the mount are exported back to S3 within minutes. Changes made directly in S3 appear in the file system within seconds, but can take a minute or longer. If your downstream system polls S3 for new objects, account for this lag. There's no manual flush API.

Renames are expensive. S3 has no native rename. Renaming a file through the mount means copy + delete at the S3 layer. For a single file, fine. For a directory with 50,000 files, that's 50,000 copy-and-delete operations. Write final output paths directly. Don't use directory renames as workflow commits.

S3 versioning is required. You can't create an S3 file system on a bucket without versioning enabled. This increases storage costs from additional versions.

Glacier storage classes are incompatible. S3 Standard, Intelligent-Tiering, and Infrequent Access all work. Glacier does not.

No hard links. Symbolic links work. If your tool relies on hard links (some build systems and package managers do), it will break.

1,024-byte key length limit. Deeply nested directories with long filenames can hit this ceiling. Measure your path lengths before committing to a directory structure.

Conflicts: S3 wins. If the same file is modified through both the mount and the S3 API simultaneously, the S3 version is treated as the source of truth. The file system version goes to a lost+found directory. Pick one writer per path.

Custom S3 metadata isn't visible. If your application sets x-amz-meta headers through the S3 API, those values don't appear as extended attributes on mounted files. POSIX attributes only.

Cache expiration defaults to 30 days. Data stays in the high-performance layer for 30 days after last access. For batch workloads that touch files once, drop this to 1-2 days to reduce cache storage costs.

S3 Files vs. EFS vs. Mountpoint

Lambda already supported EFS mounts. And S3 Mountpoint exists for read-heavy workloads. Here's when each makes sense:

If you need...	Use this	Why
File paths backed by S3 data	S3 Files	S3 stays the source of truth, cache only for active data
General shared POSIX storage independent of S3	EFS	Mature, no sync lag, all data is hot
Read-only high-throughput access to S3	Mountpoint for S3	Simpler, no EFS layer, no write support needed
Enterprise NAS features (ONTAP, Windows)	FSx	Protocol-specific workloads

The key difference between S3 Files and EFS: with EFS, you pay $0.30/GB for everything stored. With S3 Files, you pay $0.30/GB only for the active working set and $0.023/GB for everything else in S3. The cost advantage grows as total data increases relative to the active subset.

The key difference between S3 Files and Mountpoint: Mountpoint is a FUSE client with limited write support and no caching layer. S3 Files gives you full read-write NFS semantics with a managed cache. If you only need to read large files from S3, Mountpoint is simpler and cheaper.

A Practical Example: Image Processing Pipeline

A common Lambda pattern: S3 trigger fires when an image is uploaded, function generates thumbnails and optimized versions.

The old way requires downloading the source image, processing it with Pillow or ImageMagick, writing multiple outputs to /tmp, then uploading each one back to S3:

import boto3
from PIL import Image
import os

s3 = boto3.client("s3")
SIZES = {"thumb": (150, 150), "medium": (800, 600), "large": (1920, 1080)}

def handler(event, context):
    bucket = event["Records"][0]["s3"]["bucket"]["name"]
    key = event["Records"][0]["s3"]["object"]["key"]

    s3.download_file(bucket, key, "/tmp/source.jpg")
    img = Image.open("/tmp/source.jpg")

    for name, size in SIZES.items():
        resized = img.copy()
        resized.thumbnail(size)
        output_path = f"/tmp/{name}.jpg"
        resized.save(output_path, "JPEG", quality=85)
        s3.upload_file(output_path, bucket, f"processed/{name}/{key}")
        os.remove(output_path)

    os.remove("/tmp/source.jpg")
    return {"processed": list(SIZES.keys())}

With S3 Files:

from PIL import Image
from pathlib import Path

WORKSPACE = Path("/mnt/workspace")
SIZES = {"thumb": (150, 150), "medium": (800, 600), "large": (1920, 1080)}

def handler(event, context):
    key = event["Records"][0]["s3"]["object"]["key"]
    source = WORKSPACE / key

    img = Image.open(source)

    for name, size in SIZES.items():
        output = WORKSPACE / "processed" / name / key
        output.parent.mkdir(parents=True, exist_ok=True)
        resized = img.copy()
        resized.thumbnail(size)
        resized.save(output, "JPEG", quality=85)

    return {"processed": list(SIZES.keys())}

Half the code. No boto3 import. No temporary file management. The source image is read directly from the mount. The outputs are written directly to the mount and sync to S3 within a minute.

Multi-Function Shared Workspace

The pattern that makes S3 Files most interesting isn't single-function file processing. It's multiple functions sharing a workspace.

Before S3 Files, if three Lambda functions needed to collaborate on the same set of files, each one had to download from S3, do its work, upload results, and the next function would download those results. With S3 Files, they all mount the same bucket and read each other's output directly.

Function A (security scan)
  reads  /mnt/workspace/repo/
  writes /mnt/workspace/reports/security.json

Function B (test analysis)
  reads  /mnt/workspace/repo/
  writes /mnt/workspace/reports/tests.json

Function C (merge reports)
  reads  /mnt/workspace/reports/*.json
  writes /mnt/workspace/final/summary.md

No intermediate S3 uploads between steps. No coordination logic to pass object keys between functions. The workspace is the coordination mechanism.

The rule for shared workspaces: one writer per file path. Don't have two functions writing to the same file. Use worker-specific output paths and let the orchestrator merge.

Who This Is For

S3 Files is for Lambda functions that have been pretending S3 objects are files. If your code downloads an object, gives it a file path, processes it with a tool that expects a file, and uploads the result, S3 Files removes the pretending.

The strongest use cases:

Media processing. Image resizing, video transcoding, audio conversion. These tools all expect file paths.

Document processing. PDF extraction, Office document conversion, OCR pipelines. Libraries like pdfplumber, python-docx, and Tesseract work with files.

Code analysis. Security scanners, linters, dependency checkers. Tools like trivy, semgrep, bandit, and eslint expect a directory to scan.

ML inference with reference data. Models that load large reference files (embeddings, lookup tables, feature stores) benefit from the shared mount. Load once, use across invocations.

AI agent workspaces. Agents that use filesystem tools (cat, grep, ls, find) can work directly on S3 data without custom S3 API wrappers.

The weakest use cases: simple JSON transforms, single-object streaming, anything that never touches the filesystem.

Getting Started

# Create the file system on your bucket (verify exact CLI syntax against docs)
aws s3api create-file-system --bucket my-bucket --file-system-name my-workspace

# Create mount targets in your VPC subnets
aws s3api create-mount-target \
  --file-system-id fs-abc123 \
  --subnet-id subnet-xyz \
  --security-groups sg-nfs-access

# Attach to your Lambda function via console or IaC
# Configuration > File systems > Add file system > S3 Files

The Lambda S3 Files documentation covers the full setup. The S3 Files user guide covers file system creation, access points, and synchronization configuration.

Should You Migrate?

For 20 years, the answer to "can I mount S3?" was no. Now it's yes, and the implementation is good enough for production Lambda workloads.

The download-process-upload pattern isn't gone from every codebase. It still makes sense for simple object transforms. But for file-heavy Lambda functions that spend more lines on S3 plumbing than on actual processing logic, S3 Files is a real simplification.

Mount the bucket. Read the file. Write the output.

Your Pen Test Takes 6 Weeks. Attackers Take 4 Minutes

Mwanza Simi — Wed, 06 May 2026 13:43:28 +0000

The 2026 CrowdStrike Global Threat Report recorded the fastest lateral movement at 27 seconds after initial access. In one case, data exfiltration started four minutes after entry. Most organizations still schedule penetration tests quarterly, if they're lucky, and wait weeks for the report. By the time the PDF lands in your inbox, the findings are stale.

You ship features weekly. Your security review happens annually. Somewhere in between, you're shipping code that hasn't been tested, because the pen test backlog is six applications deep and the next slot is in Q3.

A 2025 Checkmarx report found that 81% of organizations knowingly deploy vulnerable code to meet delivery deadlines. Not because they don't care about security, but because the process can't keep up with the release cycle.

AWS Security Agent was built to close that gap.

The Pen Test Bottleneck

The bottleneck isn't finding vulnerabilities. It's everything around it.

Traditional pen testing is a project. You scope it. You negotiate a contract, somewhere between $15,000 and $50,000 per engagement, sometimes six figures for enterprise. You wait for the consultant's calendar to open up. They test for a week or two, constrained by time and budget, making trade-offs about what to test and how deeply. Three weeks later, you get a PDF.

Your team works to fix the findings. But you rarely have the budget to bring the testers back to validate the fixes. So you hope. The report starts aging the moment it's delivered. New code gets pushed. New endpoints go live.

It's the difference between a single photograph and a live video feed of your security posture.

Automated scanners have their own problem though: they don't understand your application. SAST looks at code without runtime context. DAST pokes at a running app without understanding what it's supposed to do. Neither knows your business logic or your security policies. They generate hundreds of findings, most of which are noise, and miss the ones that matter.

An Agent That Reads Your Code Before Breaking Your App

AWS Security Agent is an autonomous agent. It reads your design docs, studies your source code, ingests your API specs, and then figures out how to break your application the way a skilled human pen tester would. On demand. Hours instead of weeks.

What separates it from scanners is that it chains vulnerabilities together. Traditional tools find individual issues in isolation. AWS Security Agent connects them.

The GA blog post tells a story worth retelling:

A stored XSS in a comment field. CVSS 6.1, medium severity. Every tool flags it. Nobody prioritizes it.
That XSS captures an admin's session cookie. No tool detects this step. SAST analyzes code, not sessions. DAST crawls as a standard user. EDR sees valid HTTPS traffic.
The hijacked admin session accesses /admin/config, which returns the production database connection string with credentials in plaintext. CVSS 9.8. No other tool discovered it because the code works exactly as designed.

Individually: a medium, an invisible, and a "functioning as intended." Chained together: a full customer data breach. The agent tested each step, proved the full attack works, and elevated the entire sequence to critical.

Setting It Up

Setup takes about 30 minutes, one time.

You start by creating an Agent Space in the AWS Security Agent console. An Agent Space is a container for one application. The first time you create one, AWS spins up the Security Agent Web Application, a separate interface where your team runs reviews and tests.

For access, you pick between SSO via IAM Identity Center (good for teams) or IAM-only (simpler, no SSO config needed).

Then you define your security requirements. AWS provides managed ones based on industry standards, but the real value is in custom requirements. "All PII access must have session timeouts under 15 minutes." "Customer-managed KMS keys required for data at rest." You define them once, and they apply across every design review and code review in every Agent Space.

Connect your GitHub repos by installing the AWS Security Agent GitHub App. That gives the agent source code context for pen testing, automated security review on pull requests, and the ability to open remediation PRs when it finds something.

Last step: verify your domains. DNS TXT record or HTTP verification file, one time per domain, so the agent knows you own what it's about to test.

Running a Pen Test

Open the web app. Select your Agent Space. Create a new penetration test.

You give it a target URL, public or private via VPC. Authentication credentials for different roles, standard user, admin, service account. Sign-in instructions for complex auth flows like OAuth or SAML (the agent uses LLM-based navigation to handle them). And documentation: API specs, architecture docs, threat models. Context makes the findings better.

The agent does reconnaissance, enumerates endpoints, builds a custom attack plan, and runs multi-step attack scenarios across 13 risk categories. It adapts based on what it discovers, status codes, error messages, new endpoints, unexpected behaviors.

Hours later, you have validated findings. A CVSS score. The full attack path, what the agent tried, what payloads it used, how it verified exploitation. Reproduction steps. Impact analysis in business terms ("attackers can modify product prices during checkout"). Code fixes ready to implement.

From Finding to Fix

You review a finding. Click "remediate." The agent opens a PR in your GitHub repo with the fix. Your developer reviews and merges. Re-run the pen test to verify. Ship.

Compare that to the traditional loop: find a vulnerability, write a report, send it to the dev team, wait for a fix, try to get budget for a retest, hope it worked. Months between "found" and "verified."

The agent compresses that to hours.

Cost

	Traditional Pen Test	AWS Security Agent
Time to results	3 to 6 weeks	Hours
Cost per test	$15,000 to $50,000+	~$400 to $2,400
Frequency	Annual or quarterly	On demand
Remediation validation	Separate engagement	Re-run immediately
Coverage	Top 3 to 5 critical apps	Entire portfolio
Multicloud	Varies	AWS, Azure, GCP, on-prem

$50 per task-hour, metered per second. An average test runs about 24 task-hours, roughly $1,200. There's a 2-month free trial.

Design reviews (up to 200/month) and code reviews (up to 1,000/month) are free.

It's Also a Design and Code Review Tool

Pen testing gets the attention, but the other two capabilities change the day-to-day workflow more.

Design review catches security issues before code is written. Upload your architecture doc, and the agent checks it against your organizational requirements. "Your design doesn't specify network segmentation between the payment processing layer and the user-facing tier." Flagged before sprint planning, not after the incident.

Code review runs on every pull request. If your org requires 90-day log retention and a developer configures 365 days, the agent comments on the PR. Traditional tools miss this because the code is technically correct. The agent catches it because it knows your rules. It also checks for OWASP Top 10 vulnerabilities alongside your custom policies.

What It Won't Do

GitHub only for code review integration. No GitLab, Bitbucket, or CodeCommit.

Web apps and APIs only. Not your mobile app binary or IoT firmware.

It's an agent, not a security program. You still need threat modeling, incident response, and the rest.

Available in 6 AWS regions: us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-2, ap-northeast-1.

Where This Leaves Us

The security industry has spent a decade telling developers to "shift left." The problem was never willingness. It was tooling. You can't shift left with a 6-week engagement, a $30K budget, and a PDF that's outdated before the ink dries.

AWS Security Agent makes pen testing something you can run on a Tuesday afternoon and act on by Wednesday morning. Whether that replaces the annual engagement entirely or just fills the gaps between them depends on your org. But the gap between "how fast we ship" and "how fast we test" just got a lot smaller.

AWS Security Agent Console | Documentation | Pricing

Google Uses the Same AI Stack It Sells You. That's Either Brilliant or a Problem.

Mwanza Simi — Wed, 29 Apr 2026 14:09:20 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Sundar Pichai dropped a line during the NEXT '26 opening keynote that most people scrolled past. "A big focus of ours is to always be customer zero for our own technologies." The same unified stack that powers Search, YouTube, Chrome, and Android is the one Google is selling to enterprises.

A wild claim if you stop and think about it. Google isn't just building cloud tools and hoping customers find them useful. They're running Search and YouTube on the same infrastructure they're asking you to bet your business on.

Nobody else does this across so many different workloads.

What "Customer Zero" actually means

AWS runs Amazon's retail operations. Microsoft runs Office 365 on Azure. Both are serious dogfooding. But Google's internal usage spans a wider range of problems: search ranking, video streaming, email spam filtering, mobile OS services, browser infrastructure. Search alone processes around 8.5 billion queries a day. YouTube serves over a billion hours of video daily. These aren't side projects, they're stress tests across fundamentally different workload types that no single enterprise customer could replicate.

When Google ships a new TPU generation or updates Gemini, they're not testing it on a staging environment and hoping for the best. They've already run it against Search ranking and YouTube recommendations before it ever reaches your console.

That's the pitch, anyway.

The part Google doesn't talk about

Being customer zero cuts both ways. If Google is the biggest user of its own stack, the stack gets optimized for Google's problems. Search needs low-latency inference at planetary scale. YouTube needs massive throughput for video processing. These are specific, unusual workloads.

Your workload probably looks nothing like that. You might need steady, predictable performance for a few thousand concurrent users, not burst capacity for billions. You might care more about cost predictability than raw throughput. The features that get prioritized and the edge cases that get fixed first follow Google's internal needs before they follow yours.

This isn't hypothetical. In 2022, Google announced it was killing Cloud IoT Core, giving enterprises about a year to migrate their IoT workloads somewhere else. The service launched in 2017, never got the investment it needed, and got axed because it didn't align with where Google was heading. If Google doesn't use a product internally, it's always at risk. killedbygoogle.com exists for a reason, and enterprise customers know it. The "customer zero" pitch is partly Google trying to counter that reputation. If they run it themselves, they won't kill it. Probably.

There's a resource question too. Google announced eighth-generation TPUs at NEXT, with the TPU 8t scaling to 9,600 chips. But when demand spikes and capacity gets tight, who gets priority, YouTube or your production cluster? Google says over half their ML compute investment goes to the Cloud business. That still leaves a lot going to internal products that compete for the same silicon.

The 75% number makes this more interesting

Pichai also mentioned that 75% of all new code at Google is now AI-generated and approved by engineers. Up from 25% in October 2024, then 50% by fall 2025. Google is using its own AI tools to build its own products at a pace that's hard to comprehend.

This is where the customer zero argument gets compelling. If Gemini is writing three-quarters of the code that runs Search and YouTube, and those products are still working at scale, that's a stronger endorsement than any case study. Forget "Company X saved 30% on deployment time." Google rebuilt how they write software and the products you use every day didn't break.

But it also means Google's AI tools are being shaped by how Google writes software and the patterns in their codebase. Whether those tools work as well for a 50-person startup or a bank with legacy Java everywhere, nobody's shown that yet.

Why this matters more than the feature announcements

NEXT '26 had plenty of product launches. The Gemini Enterprise Agent Platform got the most attention, but there was also the Agentic Data Cloud and new security offerings with Wiz. All worth paying attention to. But the customer zero framing is the thing that ties them together and the thing that separates Google's pitch from everyone else's.

AWS says "we have the most services." Azure says "we integrate with your existing Microsoft stack." Google is saying something different: "we use this stuff to run the biggest internet products on the planet, and now you can use it too."

That's a strong argument. It's also a bet. You're betting that what works for Google's scale and Google's problems will translate to yours. For some workloads, especially anything involving large-scale AI inference, that bet probably pays off. Google has been doing this longer than anyone. For others, you might find yourself paying for optimization you don't need while the features you actually want sit lower on the roadmap.

The honest take

Google being customer zero is probably a net positive for most enterprises adopting their AI stack. Battle-tested infrastructure is better than theoretical infrastructure. The Gemini models being forged against products that billions of people use daily is a real advantage.

But "customer zero" also means "customer with the most influence over the product roadmap." And that customer's needs aren't your needs. The question isn't whether Google's stack is good. It obviously is. The question is whether being second in line behind the world's largest internet company is a comfortable place to build your business.

Building Reverse Engineering Reality with Google Gemini

Mwanza Simi — Wed, 04 Mar 2026 10:40:30 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built an app called "Reverse Engineering Reality." You upload a photo of any everyday object, and it gives you detailed instructions for assembling or disassembling it. The instructions are fictional but surprisingly detailed complete with materials, tools, step-by-step guides, and custom illustrations for each step.

The idea came from that moment when you look at something and wonder how it's made. Instead of just wondering, you get an actual blueprint. It's part educational, part creative experiment. You can take a photo of your coffee maker or a lamp and get a full breakdown of how you'd theoretically build it from scratch.

I used gemini-2.5-flash for the core analysis and text generation, and imagen-4.0-generate-001 for creating the step illustrations. The app analyses your photo, identifies objects in it, lets you pick which one you want instructions for, then generates everything. After that, there's a chat assistant that knows about the blueprint you just created, so you can ask followup questions.

The structured output feature was critical here. I defined a JSON schema that tells Gemini exactly what format I need, object name, materials list, tools, numbered steps, image prompts for each step. Without that, I'd be parsing unstructured text and hoping for consistency. With it, I get clean, predictable data every time.

For the illustrations, each step includes a text prompt that gets sent to Imagen. So the AI analyzes your photo, writes instructions, writes prompts for diagrams, then generates those diagrams. It's a full multimodal pipeline image to text to image.

Demo

Here is the embedded app you can play with:

What I Learned

Structured outputs changed how I think about building with AI. Instead of treating the model like a black box that returns text you have to wrangle, you can define exactly what you need and get it reliably. That makes the difference between a demo and something you can actually build a UI around.

I also learned that chaining models works better than I expected. Using one model for understanding and another for generation gave me more control over each part of the process. The chat feature was straightforward to add once the main pipeline worked just pass the generated instructions as context and let users ask questions about them.

The biggest surprise was how good the generated illustrations turned out. I wasn't sure if Imagen could handle technical diagram style images from text prompts, but it consistently produced clear, relevant visuals that actually help explain the steps.

Google Gemini Feedback

The structured output feature worked great. No complaints there it did exactly what I needed and made the whole project possible.

The multimodal capabilities were solid. Image understanding was accurate enough for object detection and analysis, and the integration between models felt smooth. I didn't have to do much work to get them talking to each other.

The main friction was prompt tuning. Getting the right balance between creative and practical in the instructions took some iteration. Too vague and the steps weren't useful, too rigid and they felt robotic. System instructions helped, but it still took testing to find the sweet spot. AI Studio made that easier since I could experiment with prompts before writing code.

Reverse Engineering Reality with Google AI

Mwanza Simi — Sun, 14 Sep 2025 16:14:26 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I've created an application called "Reverse Engineering Reality." It's a creative tool that allows users to upload a photo of any everyday object and, using the power of AI, receive a detailed, imaginative set of instructions for either assembling it from scratch or disassembling it.

The app solves the problem of curiosity and creativity. It transforms a passive observation of an object ("I wonder how that's made?") into an active, engaging, and educational experience. It provides users with a fictional "blueprint" for the world around them, complete with materials, tools, step-by-step guides, and custom illustrations, fostering a deeper appreciation for design and engineering.

Demo

Try Out the applet here on a deployed cloudrun instance

How I Used Google AI Studio

This app is built directly on the Gemini API, the same technology that powers Google AI Studio. The development process mirrors the iterative prompting and schema design one would perform in the Studio.

Here's how I leveraged its capabilities:

Model Selection: I primarily use gemini-2.5-flash for its speed and powerful reasoning capabilities, which are perfect for analyzing images, generating structured text, and powering the chat assistant. For image generation, I use imagen-4.0-generate-001.

Structured Output (JSON Mode): This is a critical feature. I provide the Gemini model with a strict JSON schema to ensure the output for the instructions (object name, materials, tools, steps, etc.) and object detection (bounding boxes) is predictable and machine-readable. This allows me to easily parse the AI's response and render it into a structured, user-friendly interface without complex string manipulation.

System Instructions: I use system instructions to set the context for the AI. For instruction generation, the AI is prompted to act as an "expert reverse engineer and master craftsman." For the chat feature, it's prompted to be a helpful "AI Assembly Assistant," ensuring its responses are focused on the provided blueprint.

Chat Functionality: The app uses the Gemini API's chat capabilities (ai.chats.create) to create a conversational assistant that has memory of the generated instructions, allowing users to ask follow-up questions in a natural way.

Multimodal Features

The app is fundamentally multimodal, combining image and text inputs and outputs to create a rich, interactive experience.

Image-to-Text (Core Analysis): The primary multimodal feature is the app's ability to understand an image uploaded by the user. It takes visual data (a photo of an object) and outputs structured text (a JSON object containing the full assembly/disassembly blueprint). This demonstrates a deep visual reasoning capability.

Object Detection from Image: Before generating instructions, the app first analyzes the image to identify and locate distinct objects, returning their names and bounding box coordinates. This is another form of image-to-text functionality that enhances user control by allowing them to select the specific object of interest.

Text-to-Image (Illustrations): To make the instructions more intuitive and engaging, the app uses a powerful text-to-image workflow. For each step in the generated blueprint, the AI also creates a descriptive imagePrompt (text). This text is then fed to the imagen-4.0-generate-001 model to generate a custom, diagram-style illustration for that specific step. This combination—analyzing an image to produce text, then using that text to create a new image—is a sophisticated multimodal pipeline that greatly enhances the final product.

Together, these features allow a user to seamlessly translate a real-world object into a fully illustrated, interactive digital guide.

"Kiro" Why This Name Perfectly Captures the AI Development Crossroads

Mwanza Simi — Tue, 15 Jul 2025 22:08:22 +0000

When AWS unveiled Kiro, its new AI-powered IDE, many developers likely honed in on its main features of it being an AI co-pilot, for spec driven development, and agent hooks. But have you ever wondered about the meaning behind the name itself? "Kiro" holds a deep significance, particularly in Japanese, that beautifully captures where AI stands in software development right now.

Diving into "Kiro"

In Japanese, "Kiro" translates to "circuit," "pathway," or "route." This might seem simple, but it carries powerful symbolism when you think about a groundbreaking AI development environment.

Consider this, Circuits are the core of computing. They're where logic unfolds, where inputs transform into outputs, and where intelligence takes shape physically. As an AI IDE its building and refining these digital circuits.

Then there are pathways and routes. These words speak to direction, a journey, and progress. In development, we're always navigating tricky problems, searching for the most efficient way to a solution, and creating paths for data and how users interact with our software. It aims to light up these pathways, guiding developers and even charting new ones on its own, getting from a raw idea to a finished product, while helping you pave that very clear route.

At the Crossroads, Where Human Ingenuity Meets AI Automation

The elegance of the name truly shines when we look at the current landscape of software development. For a long time, many AI coding assistants have focused on completing small code snippets or suggesting individual lines. This often led to what some call "vibe coding," where the big picture, the overall architecture, or the original intent could easily get lost, by emphasizing files like requirements.md and design.md, encourages a more structured approach. It's steering developers onto a clearer "pathway" instead of just helping them wander aimlessly.

Think of it like a well designed circuit taking your high level goals as inputs and processes them. But you, the developer, remain the architect and the ultimate controller. You lay out the "circuit board," and getting the help to wire it up efficiently. The name subtly reinforces this collaboration, the intricate dance between human creativity and AI execution within a defined system.

Modern cloud applications are incredibly intricate, with distributed systems, microservices, and vast AWS ecosystems, with a "route" through this complexity, breaking down intimidating tasks into manageable "circuits" of work, from generating code to writing tests and documentation. It's like having a map and a compass for your cloud native journey.

Precision, Connection, and Evolution

Beyond its primary meaning, the concept of a "circuit" in Japanese also brings to mind the Precision as circuits are designed with incredible care, every single connection matters. Aiming for this exact level of precision. Producing structured designs, thorough tests, and up-to-date documentation that are all interconnected and spot on.

Connection of a circuit is essentially a network of linked components. With a true understanding these connections, within your codebase, between your services, and even between your big-picture ideas and the nitty-gritty implementation details. It fosters a more connected and complete development process.

Evolution of circuits themselves have evolved with new technologies like old vacuum tubes to tiny microchips, software development is constantly changing. Representing the next big leap in developer tools, adapting to new ways of thinking and pushing the boundaries of what you can achieve with AI.

The name Kiro is a fantastic choice and a statement of purpose, guiding you through the intricate circuits of code and along the clearest paths to innovation.

What are your initial thoughts, and how do you imagine it will shape the way you approach your development projects?

AWS GuardDuty vs. Inspector vs. Shield, What’s the Difference?

Mwanza Simi — Sun, 09 Mar 2025 21:56:17 +0000

Securing your AWS environment can feel daunting as there are so many tools out there, and it’s not always clear which one does what. Take AWS GuardDuty, Inspector, and Shield, for example. At first glance, they might seem like they’re all doing the same thing of keeping your cloud safe. But dig a little deeper, and you’ll see they each have their own power. So, how do you know which one to use, What makes GuardDuty different from Inspector, and when does Shield come into play?

Your Cloud Detective,AWS GuardDuty

Think of AWS GuardDuty as a detective that’s always on the lookout for suspicious activity. It’s a threat detection service that continuously monitors your AWS environment for signs of trouble. it uses machine learning and analyzes data from various sources, like AWS CloudTrail logs, VPC Flow Logs, and DNS logs, to spot unusual behavior.

For example, if someone tries to log in to your account from a strange location or if an EC2 instance starts communicating with a known malicious IP address, it will flag it. It’s like having a security guard who’s always watching and ready to raise the alarm.

If you want to detect potential threats in real time, like unauthorized access, compromised instances, or suspicious network activity, GuardDuty is your tool.

The Vulnerability Scanner, AWS Inspector

AWS Inspector is designed to find vulnerabilities in your applications and infrastructure. It automatically assesses your resources, such as EC2 instances, and checks for common security issues, like open ports, missing patches, or misconfigurations.

By running automated security assessments, it provides a detailed report with recommendations on how to fix the issues it finds. It’s not a real time like GuardDuty but a more of a periodic check-up to make sure everything is secure.

If you’re looking to identify and fix vulnerabilities in your applications or infrastructure, Inspector is the right choice. It’s especially useful before deploying new applications or after making significant changes to your environment. Think of it as a way to ensure your systems are secure before they go live.

Your DDoS Bodyguard, AWS Shield

AWS Shield is all about protecting your applications from Distributed Denial of Service (DDoS) attacks. These attacks can overwhelm your systems with traffic, making them unavailable to legitimate users. Shield comes in two versions: Standard and Advanced.

Shield Standard is automatically included with all AWS accounts and provides basic protection against common DDoS attacks.
Shield Advanced is a paid service that offers enhanced protection, including 24/7 access to the AWS DDoS Response Team, detailed attack reports, and financial protection against scaling costs during an attack.

If you’re running applications that need to be highly available and you’re concerned about DDoS attacks, Shield is a must. Shield Advanced is ideal for businesses that need extra protection and support, especially if they’re running critical workloads.

How They Work Together

While they all serve different purposes, they can work together to provide a comprehensive security strategy. Here’s how:

GuardDuty monitors for threats in real time, helping you detect and respond to suspicious activity.
Inspector identifies vulnerabilities in your applications and infrastructure, giving you a chance to fix them before they’re exploited.
Shield protects your applications from DDoS attacks, ensuring they stay online and available.

For example, Inspector might find an open port on one of your EC2 instances. You close the port, but GuardDuty later detects unusual traffic from that instance, indicating a potential compromise. Meanwhile, Shield is protecting your application from being taken offline by a DDoS attack. Together, these tools create a layered defense that keeps your AWS environment secure.

Deploying a simple HTML on Nginx using AWS

Mwanza Simi — Wed, 29 Jan 2025 17:19:19 +0000

This blog post documents my experience setting up a web server using Nginx, from spinning up an EC2 instance to configuring the server to serve a custom HTML page. It details the process, the challenges I faced, and the valuable lessons I learned.

EC2 and Nginx Installation:

I began by launching an Amazon EC2 instance. I chose an Amazon Linux 2 AMI, as it's a stable and readily available option. I selected a t2.micro instance for this simple setup, as it fits within the free tier. Once the instance was running, I connected to it via SSH.

The next step was installing Nginx. Since I was using Amazon Linux 2, I used the yum package manager:

sudo yum update -y  
sudo yum install nginx -y 
sudo systemctl start nginx 
sudo systemctl enable nginx

After installation, I verified that Nginx was running by accessing the instance's public IP address in my browser. The default Nginx welcome page confirmed a successful installation.

Creating the Custom Web Page:

With Nginx up and running, it was time to create the custom HTML page. I created a directory to hold my website's files:

sudo mkdir -p /var/www/html

Then, I created the index.html file within this directory:

sudo nano /var/www/html/index.html

Inside index.html, I added the following content, my name:


<!DOCTYPE html>
<html>
<head>
    <title>Welcome</title>
</head>
<body>
    <h1>Welcome to DevOps Stage 0 - [Your Name]/[SlackName]</h1>
</body>
</html>

Challenges and Learning Opportunities:

While the process was relatively straightforward, I encountered a challenge

Firewall Configuration: Initially, I couldn't access my webpage even after Nginx was running. I realized that the EC2 instance's security group (firewall) wasn't configured to allow inbound traffic on port 80 (HTTP). This taught me the importance of properly configuring security groups to allow access to the necessary ports. I learned how to add a rule to the security group to open port 80.

Setting up a web server with Nginx on EC2 was a valuable learning experience. I gained practical knowledge of EC2 instances, Nginx installation, and basic web server configuration. The challenges I faced reinforced the importance of understanding these fundamental concepts. I am excited to continue exploring more advanced DevOps tools and skills.

For more check out HNG internship, They offer resources for hiring various tech experts, including:

Amazon S3 Just Gave Us a Million Reasons to Smile

Mwanza Simi — Sun, 26 Jan 2025 18:29:13 +0000

Big news for anyone who uses Amazon S3, you can now create up to 1 million buckets in your AWS account. That’s right, what used to be a limit of 100 buckets has now been bumped to 10,000 by default, and if you need more, you can request up to a million. Whether you’re a small business or a huge enterprise, this change is a big deal. Let’s break it down in simple terms and see how it can make your life easier.

What’s Changed?

Before this update, AWS accounts were limited to 100 buckets by default. Now, that number has jumped to 10,000 buckets automatically, and you can request to go all the way up to 1 million buckets if you need to. The best part? Your first 2,000 buckets are free. After that, there’s a small monthly fee, but it’s a small price to pay for the flexibility this brings.

Why Should You Care?

More buckets mean more ways to organize, secure, and manage your data. Here’s why this matters:

Better Organization: Instead of dumping everything into a few buckets, you can now create separate buckets for different projects, clients, or types of data. Think of it like having more drawers in a filing cabinet, it just makes life easier.
Stronger Security: With more buckets, you can apply specific security settings to each one. For example, you can enable encryption for sensitive data or set strict access controls for confidential files.
Easier Backups and Replication: Need to back up data or replicate it across regions? More buckets let you do this more efficiently, without mixing things up.
Scalability: Whether you’re a startup or a big company, this update ensures your storage can grow with your needs.

Fun and Practical Ways to Use More Buckets

Here are some everyday scenarios where having more buckets can make a real difference:

1. Keep Your Data Neat and Tidy

A marketing team can create a bucket for each client’s campaigns. No more digging through one giant bucket to find what you need. It’s like having a labeled folder for everything, saves time and reduces stress.

2. Stay Compliant Without the Headache

A healthcare company can use separate buckets for patient records, billing data, and general files. Each bucket can have its own security settings to meet compliance rules.Makes audits easier and keeps sensitive data safe.

3. Backups Made Simple

A tech team can create a bucket for each day’s database backups. If something goes wrong, finding the right backup is a breeze. No more scrambling to find the right file in a sea of backups.

4. Boost Your Machine Learning Projects

A data science team can use separate buckets for raw data, cleaned data, and finished models. This keeps everything organized and easy to access.

5. Run a Multi-Tenant App Like a Pro

A SaaS company can create a bucket for each customer. This keeps their data separate and secure. Customers get better security, and you get happier users.

6. Track Events and Logs Effortlessly

A gaming company can create a bucket for each game session, storing logs and player data separately. Troubleshooting and analysis now is way easier.

7. Save Money on Storage

A media company can use different buckets for active files (like videos being edited) and archived files (like old projects). Each bucket can use the most cost-effective storage option. Keeps costs down without sacrificing performance.

How to Get Started

Check Your Account: The new default of 10,000 buckets is already applied to your AWS account. No need to do anything.
Request More if Needed: If you need more than 10,000 buckets, just request a quota increase through the Service Quotas console. You can go up to 1 million buckets.
Start Creating Buckets: Your first 2,000 buckets are free. After that, there’s a small monthly fee, but it’s worth it for the flexibility.

Tips for Naming Your Buckets

With so many buckets, it’s important to stay organized. Here’s how:

Use clear, consistent names (e.g., project-name-data-type-region).
Add tags like dev or prod to show the environment.
Avoid using sensitive info in bucket names (e.g., customer names or account numbers).

Why This Update Rocks

This change is all about giving you more freedom and flexibility. Whether you’re a solo developer or part of a huge team, having more buckets means you can work smarter, not harder. It’s like upgrading from a tiny closet to a walk-in wardrobe, you’ll wonder how you ever managed before.

What’s the first thing you’ll do with your new buckets? Let me know in the comments