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:
- Spin up a container
- Run some commands
- Write the output somewhere
- Shut down
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:
- No servers to manage. It's fully managed. You don't patch anything, you don't monitor uptime, you don't deal with scaling.
- It supports any runtime. Python, Node, Go, Bash, or bring your own Docker image with whatever tools you need.
- It has built-in IAM integration. You attach a role to the CodeBuild project, and your script can call AWS APIs without managing credentials.
- No time limit like Lambda. CodeBuild can run for up to 8 hours.
- Output goes to CloudWatch Logs automatically, and you can write files to S3.
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
- One-off or scheduled scripts that need AWS API access
- Tasks that take longer than Lambda's 15-minute limit
- Scripts that need tools or binaries not available in Lambda
- Cleanup jobs, inventory scans, audit reports, data exports
- Anything where the pattern is "run commands, write output, exit"
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.