Opportunity Name:
Lambda Architecture Retype to Graviton2 (Finder: LambdaRetypeGraviton)
AWS Resource Type:
AWS Lambda
Opportunity Description:
Lambda functions run on either Intel/AMD-based x86 processors or AWS Graviton2 (ARM64) processors. Graviton2 provides higher performance at a lower cost. This Finder identifies x86 Lambda functions that are already on a current, supported runtime and only need the architecture switched to Graviton2 — no runtime change is required.
Related article: if your Lambda function is on a deprecated runtime, CloudFix uses a separate finder that upgrades the runtime and re-types the architecture together in one fix — see Lambda Graviton Migration with Runtime Upgrade.
Criteria for identifying the opportunity:
- Only Lambda functions currently running on x86 (Intel/AMD) architecture are considered.
- Only functions deployed as a ZIP package are eligible. Container-image (OCI) Lambda functions are excluded, since there is no deployment package to re-type.
- The function's runtime must be a current, supported version in the Python, Node.js, or Java family. Functions on a deprecated runtime are handled instead by the companion runtime-upgrade finder linked above, not by this one.
- CloudFix's AI-assisted compatibility check reviews the function code, layers, and package dependencies for ARM64-incompatible native binaries before recommending the migration.
Potential savings (range in % on annual basis):
CloudFix calculates the recommendation using a 20% reduction of the function's current amortized cost. Separately, AWS's own Graviton2 Lambda benchmarks cite up to 34% better price-performance versus x86 — actual savings for a given function will depend on its workload.
What happens when the Fixer is executed?
The Fixer applies a direct, single-step update to the target Lambda function: it retrieves the function's current deployment package and calls the AWS Lambda UpdateFunctionCode API with Architectures set to arm64, then tags the resource. The runtime version itself is not changed.
This Fixer does not create a proxy Lambda, does not shift traffic gradually between an x86 and an ARM copy, and does not set up a CloudWatch alarm to auto-rollback the change — it is a direct in-place update, not a canary cutover.
Is it possible to rollback once CloudFix implements the fixer?
Rollback is manual. There is no automated, alarm-triggered rollback. If you need to revert, you can restore the function's previous architecture (x86_64) through the AWS Management Console, CLI, or by redeploying its prior published version.
Can CloudFix implement the fix automatically once I accept the recommendation?
Yes.
Does this fix require downtime?
This is a direct, single-step update (not a gradual or canary cutover), so it is not guaranteed zero-downtime. AWS Lambda briefly places the function in an updating state while the architecture change is applied; invocations that land during that short window may be delayed or retried by the caller.
Priyanka Bhotika
Comments