aws-amplify / aws-amplify/amplify-hosting
Support ARM64 build environments for Amplify Hosting custom build images
- Dominant language
- Dockerfile
- Stars
- 481
- Forks
- 123
- PR merge metrics
- No merged PRs in 30d
Description
### Before opening, please confirm:
- [x] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [x] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [x] I have removed any sensitive information from my code snippets and submission.
### Amplify Hosting feature
Custom build image
### Is your feature request related to a problem? Please describe:
The Amplify Hosting custom build image documentation explicitly requires images to be
compiled for the x86-64 architecture. This creates a significant problem for teams
building AWS Lambda container images that must target ARM64 (aws/codebuild/amazonlinux2-aarch64-standard).
When producing ARM64 Lambda container images inside an Amplify build, the entire build
runs under x86-to-ARM64 cross-platform emulation (QEMU). This substantially increases
build time and makes the CI/CD workflow inefficient.
Observed behavior during testing:
- Amplify build environment: x86-64 (Standard: 8GiB Memory, 4 vCPUs)
- ARM64 Lambda container image build via QEMU emulation: significantly slower than native
- AWS CodeBuild already supports ARM_CONTAINER with amazonlinux2-aarch64-standard:3.0
natively, confirming the underlying infrastructure exists
The Amplify Gen 2 custom functions documentation also confirms that Docker is not
available in branch deployments by default, and even when a custom Docker-enabled image
is provided, the host remains x86-64. There is currently no supported path to build
ARM64 container images natively within an Amplify CI/CD pipeline.
The existing Amplify API already exposes a jobConfig.buildComputeType field
(e.g. STANDARD_8GB), indicating the architecture for ARM64 compute types could be
added without a breaking API change.
### Describe how you'd like this feature to work
Add ARM64 build environment support to Amplify Hosting, specifically:
1. Allow custom build images compiled for the ARM64 (aarch64) architecture in addition
to the current x86-64 requirement.
2. Expose an ARM64 compute option in the build instance type configuration
(alongside the existing Standard / Large / XLarge x86-64 types), for example:
- Standard ARM64: 4 vCPUs, 8 GiB memory
- Large ARM64: 8 vCPUs, 16 GiB memory
3. Expose the compute architecture selection via:
- Amplify Console (Build settings → Build instance type)
- AWS CLI (amplify update-app / update-branch)
- amplify.yml (env.computeType field)
Expected amplify.yml syntax:
version: 1
env:
computeType: BUILD_GENERAL1_SMALL_ARM64
frontend:
phases:
build:
commands:
- docker build --platform linux/arm64 -t $ECR_REPO_URI:latest .
This would allow ARM64 Lambda container images to be built natively inside Amplify
CI/CD with no emulation, matching the capability already available in AWS CodeBuild
(ARM_CONTAINER + amazonlinux2-aarch64-standard:3.0).
Verified during testing: a Lambda function built natively on CodeBuild ARM_CONTAINER
returns "architecture": "aarch64" confirming zero emulation overhead. The same build
inside Amplify x86-64 requires QEMU and is significantly slower.
AWS CodeBuild already supports this infrastructure. Exposing it through Amplify Hosting
would close the gap and make Amplify a viable CI/CD platform for ARM64 Lambda workloads
without requiring external workarounds.
Contributor guide
Research direction
Start by tracing the existing custom build image requirements and the jobConfig.buildComputeType configuration, then compare the current Amplify Console, AWS CLI, and amplify.yml build-instance entry points. Check how AWS CodeBuild exposes ARM_CONTAINER and determine the compatibility and API implications. Done means ARM64 custom images and compute types are supported consistently across those interfaces, with native ARM64 builds verified without QEMU.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, docker
- Domain
- ci-cd, cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100