The Problem

I run a production SaaS on AWS Lambda (Python 3.12, 7 source files, boto3 + MCP dependencies). All functions on x86_64. AWS Graviton2 offers 20% cheaper duration charges — but switching without
verifying ARM64 compatibility is risky.

The manual audit process:

• Check every pip dependency for native C extensions
• Verify no inline assembly or architecture-specific intrinsics
• Confirm container base images support linux/arm64
• Cross-reference AWS docs for runtime support

For a small codebase, this takes a few hours. For larger projects with numpy, pandas, or compiled extensions — days.

The Setup: Kiro Web + Graviton Migration Power

Kiro Web is AWS's agentic IDE in public preview. It runs an autonomous agent in a remote sandbox with Docker support, MCP servers, and installable "Powers" (domain-
specific tool packages).

Step 1: Install the Graviton Migration Power

From the AWS Agent Toolkit, I installed:

• Graviton Migration Power (includes arm-mcp Docker container)
• AWS MCP server (for account access)

The Power adds these tools to the agent:

• migrate_ease_scan — scans code for ARM64 compatibility issues
• check_image (skopeo) — verifies container images support linux/arm64
• knowledge_base_search — queries Arm documentation

Step 2: Connect your repo

Fork/connect your GitHub repo to Kiro Web. The agent checks out your code in the sandbox.

Step 3: Run the analysis

Prompt:
Run the full Graviton Migration Power analysis on this codebase.
If required, install Docker in the sandbox.

What the Agent Did (Autonomously)

1. Verified Docker was running in the sandbox
2. Found the arm-mcp container active
3. Sent JSON-RPC requests to the MCP server:

json
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"capabilities":{}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"migrate_ease_scan","arguments":{"path":"/workspace","language":"python","target":"armv8-a"}}}

1. Scanned all Python files for:

   • PythonPackageIssue (native extensions)
   • PythonLinkLibraryIssue (linked libraries)
   • PythonInlineAsmIssue (inline assembly)
   • PythonIntrinsicIssue (architecture intrinsics)

2. Checked python:3.12-slim base image:
   Architectures: amd64, arm64, arm, 386, ppc64le, riscv64, s390x

3. Queried knowledge base for Lambda Graviton pricing data

The Results

Scanner: Python (armv8-a target)
Files scanned: 7
Total issues found: 0
PythonPackageIssue: 0
PythonLinkLibraryIssue: 0
PythonInlineAsmIssue: 0
PythonIntrinsicIssue: 0

All dependencies verified:

The Migration: 1 Line

yaml

CloudFormation

ApiFunction:
Type: AWS::Lambda::Function
Properties:
Architectures:
- arm64 # This is the entire migration
Runtime: python3.12
Handler: handler.handler

Or in CDK:
typescript
new lambda.Function(this, 'Api', {
architecture: lambda.Architecture.ARM_64, // Add this
runtime: lambda.Runtime.PYTHON_3_12,
handler: 'handler.handler',
});

Cost Impact

From AWS documentation:
│ Duration charges are 20% lower than x86 pricing with millisecond granularity. Up to 34% better price-performance.

For functions with 900-second timeouts running complex reviews, this is meaningful savings with zero code changes.

When This Gets Interesting

My codebase was pure Python — easy case. The Graviton Power becomes truly valuable when you have:

• numpy/pandas — need to verify wheels exist for linux_aarch64
• Compiled extensions (cryptography, lxml) — may need different build
• Custom Docker images — need multi-arch builds
• Inline assembly — rare in Python, common in C extensions

The scanner catches all of these. That's the point — you don't need to know what to look for.

TL;DR

References:

• Kiro Web
• AWS Agent Toolkit
• AWS Lambda Graviton2