April 3, 2026 · Cloud · 4 min read

AWS CodeBuild: The Serverless Command Runner You're Not Using

Most people think of AWS CodeBuild as a CI/CD tool. You push code, it builds, it deploys. That's the typical use case.

But here's something worth knowing: CodeBuild is really just a container that runs commands. And that makes it useful for a lot more than building software.

The Problem

Let's say you need to run a Python script once a day. Maybe it scans your AWS accounts for unused resources, generates a report, and drops it in S3. Simple enough.

What are your options?

You could spin up an EC2 instance. But now you have a server to manage. You need to patch it, monitor it, and pay for it even when it's sitting idle 23 hours a day. That's a lot of overhead for a script that runs for 2 minutes.

You could use Lambda. But Lambda has a 15-minute timeout. If your script takes longer, you're stuck. And if it needs tools that aren't in the Lambda runtime (like a custom CLI or a specific binary), you're dealing with layers and custom runtimes. That gets messy fast.

You could use ECS Fargate. But now you need a task definition, a cluster, VPC configuration, and a container image. That's a lot of infrastructure for "run this script and exit."

You could use EKS. But that's even more overhead. You're not deploying a microservice. You just want to run a command.

So What Do You Actually Need?

If you think about it, the requirement is simple:

That's it. No long-running process. No API to serve. No traffic to handle. Just run and exit.

CodeBuild Does Exactly This

CodeBuild spins up a container, runs whatever commands you give it in a buildspec file, and shuts down when it's done. You pay only for the minutes it runs.

Here's what makes it a good fit:

A Simple Example

Say you want to scan all your S3 buckets and find the ones that are publicly accessible. You write a small Python script that uses boto3 to list buckets, check their policies, and output a report.

Your buildspec looks like this:

version: 0.2
phases:
  install:
    commands:
      - pip install boto3
  build:
    commands:
      - python scan_public_buckets.py
      - aws s3 cp report.csv s3://my-reports-bucket/$(date +%Y-%m-%d)/report.csv

You create a CodeBuild project, point it at this buildspec, attach an IAM role with the right permissions, and trigger it. CodeBuild spins up a container, installs boto3, runs your script, uploads the report to S3, and shuts down. Done.

If you want it to run daily, you set up an EventBridge rule to trigger the CodeBuild project on a schedule. No cron servers, no EC2 instances sitting around.

When CodeBuild Makes Sense

When It Doesn't

If your script runs in under a minute and fits in Lambda's runtime, just use Lambda. It's simpler and cheaper for short tasks.

If you need a long-running process that serves traffic, use ECS or EKS. CodeBuild is for run-and-exit, not for services.

The Mental Model

Think of CodeBuild as a serverless terminal session. You give it commands, it runs them in a container with the tools and permissions you specify, and it goes away when it's done. No infrastructure to manage before or after.

Next time you catch yourself spinning up an EC2 instance just to run a script, consider whether CodeBuild could do the job with zero infrastructure overhead.

← Back to all posts