Moving from AWS to Build
Still deciding? Build vs AWS compares the two platforms and where each one fits. This page covers what changes technically when you move.
AWS supplies infrastructure building blocks from which a team assembles its own platform. Build is that platform already assembled. Moving is less a migration of the application than a replacement of the services around it. The same applies to GCP and Azure.
What replaces what
Section titled “What replaces what”| On AWS | On Build |
|---|---|
| EC2, ECS, EKS | Dynos, with VMs and kubectl access to your own namespaces available |
| RDS, ElastiCache | First-party managed add-ons on Build infrastructure |
| VPC, load balancers, Route 53 | Platform networking, private by default |
| IAM | Platform-level role-based access control |
| CloudWatch | Built-in metrics, logs and activity history |
| CodePipeline, CodeDeploy | Pipelines, review apps and one-click rollback |
| AWS WAF | Per-application web application firewall, included |
| Inspector, ECR scanning | SPDX SBOM per build and image vulnerability scanning, included |
| SSM Session Manager logging | Recorded, replayable shell sessions |
| AWS Artifact | SOC 2 report, included on every plan |
Containerized applications deploy from a Dockerfile without a rewrite. The work is in the surrounding services, not the application.
What you keep control of
Section titled “What you keep control of”Build is more opinionated than AWS, but the lower layers remain reachable:
- Direct kubectl access to your own Kubernetes namespaces
- Virtual machines alongside standard dyno workloads
- Dockerfile builds and configurable runtime behavior, covered in Configuration
AWS services can still be used alongside Build where something exists nowhere else.
What you give up
Section titled “What you give up”- Service breadth. AWS’s catalog is unmatched. An application that depends on a specialist AWS service may be better keeping that service, or staying.
- Regions. Build operates in the US, Europe and Japan. AWS’s footprint is far larger. See Regions.
- Per-service control. Build sets platform-level defaults where AWS lets you configure each service independently.
Security and compliance
Section titled “Security and compliance”AWS provides every primitive and free SOC reports through AWS Artifact. Compliance is then an outcome of how you configure them.
On Build, SOC 2 certification, private networking, audit logs, a per-application WAF, per-build SPDX SBOMs, image vulnerability scanning and recorded shell sessions are configured and included on every plan. There is no per-service configuration step for any of them. See Security.
Billing model
Section titled “Billing model”AWS meters compute, databases, storage, networking, data transfer and observability separately, per service, per unit and per region. Build bills one monthly pool of dyno-hours with add-on credits and unlimited seats included.
The practical change is that capacity is planned once, monthly, rather than tuned per service. Cost optimization work such as instance right-sizing, reserved capacity and data-transfer review does not carry over, because there is nothing per-service left to optimize.
For the total cost argument, including engineering time, see Build vs AWS. For plan capacity, see Build pricing.
Migrating
Section titled “Migrating”Containerized applications deploy from a Dockerfile without a rewrite, and kubectl access to your own namespaces means the lower-level escape hatch remains available. Engineer-led migration support is included for every Enterprise customer. See migrating to Build.
Does Build run on AWS?
No. Build runs on bare metal it owns and operates, through to the application runtime, rather than on rented hyperscaler capacity.
Can I use AWS services alongside Build?
Yes. Running an application on Build does not prevent using an AWS service that exists nowhere else.
What is the AWS equivalent of a Build dyno?
Closest is an ECS task or an EC2 instance, though neither includes the delivery, observability and compliance layers that come with a Build dyno.
Does this also apply to GCP or Azure?
Yes. Both provide infrastructure building blocks and leave the platform above them to the team.
Does Build provide Kubernetes access?
Yes, kubectl access to your own namespaces, on every plan.
What happens to my IAM policies?
They do not carry over. Access control on Build is platform-level role-based access control, configured once for the account rather than per service.
Last reviewed: 7 September 2026