Setting the file. One moment.
Subchapter 25.53
references/shared/graviton.mdMarkdown10 KBView on GitHub
Conditionally loaded. Load this file during Design, Estimate, and Generate when the inventory contains compute, database, or cache resources, OR when a
graviton_profileis present in discovery output. Do not load for billing-only or AI-only runs.
AWS Graviton (ARM64) instances cost ~15–20% less per hour than same-spec x86 instances and are the default target for eligible workloads. This file is the single source of truth for Graviton compatibility tiering, instance mapping, and per-phase behavior. Other files reference it; they do not duplicate its tables.
| Mechanism | Magnitude | Modeled in Estimate? |
|---|---|---|
| Instance-hour price discount | 15–20% lower per hour vs x86 at same vCPU/memory | Yes — this is the only savings counted in automated math |
| Performance uplift (may allow downsizing) | workload-dependent, up to ~25% more throughput/vCPU | No — mention in Design narrative only (“validate with load test; you may be able to downsize further”); never counted |
Why vCPU ≠ capacity: Graviton vCPUs are physical cores; x86 vCPUs are typically hyperthreaded logical cores. The instance mapping below is a starting point, not a capacity guarantee. Right-sizing requires benchmarking.
Discover assigns each compute service a tier. Design and Estimate branch on it.
| Tier | Meaning | Design behavior |
|---|---|---|
ready | arm64-native, no code changes (Python, Node.js, Go, PHP, Ruby, pure-JVM Java, .NET 6+ on Linux) | Default to Graviton; no Clarify question needed |
conditional | likely fine but needs verification (JNI deps, niche C extensions, Rust/C/C++ recompile, native gem extensions, vendor AMIs) | Default to Graviton with caveat noted; surface in Clarify if risk signals are strong |
incompatible | cannot run on Graviton (Windows/.NET Framework, GPU/CUDA → route to G5/G6, RDS SQL Server, heavy SSE/AVX SIMD without NEON port) | Keep x86; never recommend Graviton |
unknown | architecture not determinable (IaC-only or billing-only signal) | Treat as conditional; ask in Clarify before defaulting |
RDS (MySQL/PostgreSQL/MariaDB), Aurora, ElastiCache, OpenSearch, and MSK all support Graviton node/instance families and are ready by default. ECS Fargate and Lambda support ARM64 via a single config setting. RDS SQL Server is incompatible; RDS Oracle is conditional (version-dependent).
| GCP machine type | AWS x86 equivalent | AWS Graviton equivalent |
|---|---|---|
| e2-standard-4 / n2-standard-4 | m5.xlarge / m6i.xlarge | m7g.xlarge |
| e2-standard-8 / n2-standard-8 | m5.2xlarge / m6i.2xlarge | m7g.2xlarge |
| c2-standard-8 | c5.2xlarge / c6i.2xlarge | c7g.2xlarge |
| n2-highmem-4 | r5.xlarge / r6i.xlarge | r7g.xlarge |
| e2-micro / e2-small | t3.micro / t3.small | t4g.micro / t4g.small |
| e2-medium | t3.medium | t4g.medium |
Verify exact pricing per target via pricing-cache.md (dev-tier rows); set pricing_source: "unavailable" for any family/size not cached.
Emit a graviton_profile per compute service (schema in schema-graviton.md). Populate tier, signals[], and caveats[] from the detection signals in schema-graviton.md. GPU/CUDA → tier: "incompatible", caveat "route to G5/G6".
Default-when-compatible: if ALL compute services are tier: ready, do NOT ask — default to Graviton (consistent with existing db.t4g defaults). Only ask the Graviton question when any service is conditional/unknown with risk signals. Question wording lives in clarify-compute.md.
Branch on preferences.design_constraints.cpu_architecture:
graviton (or absent + all-ready): emit Graviton instance types in every eligible mapping; Lambda arm64; Fargate ARM64; managed-service Graviton families.conditional services: emit Graviton and record caveats + “validate after migration” in the design.incompatible services: emit x86, record why.graviton block (schema in schema-graviton.md) to each compute service in aws-design.json.Model only the hourly price discount. Use pricing-cache.md Graviton rows when present; otherwise set pricing_source: "unavailable" for the affected rows. Emit an architecture_comparison block (schema in schema-graviton.md). Do not add Graviton as a fourth pricing tier — it is the architecture within Balanced/Premium/Optimized. Balanced tier uses Graviton pricing when selected.
design-refs/compute.md branches on cpu_architecture. Managed databases and caches already default to Graviton families (db.t4g, cache.t4g) regardless, so there is no compatibility risk — but an explicit x86/mixed choice does not yet flow into design-refs/database.md or the cache mapping. Follow-up: have those refs honor cpu_architecture for full consistency. (Graviton on managed DB/cache has no code impact, so this is a consistency gap, not a correctness one.)graviton_profile (see schema-graviton.md § Billing only). The Q11b decision table covers billing-sourced compute by asking when no profile exists.The cost report should surface Graviton savings, but the report generator and its validator (generate-artifacts-report.md, shared/validate-migration-report.md, scripts/validate-migration-report.py) do not yet carry it. A follow-up should:
architecture_comparison in the report’s cost breakdown / decision summary (a “Graviton savings” line: graviton_monthly vs x86_equivalent_monthly, savings_percent), reusing the report’s existing section-ID and table conventions.validate-migration-report.py that the rendered Graviton savings match estimation-infra.json → architecture_comparison (savings_amount / savings_percent). That validator is intentionally structural-only today, so this is a net-new check, not a modification of existing behavior.Until then, numeric agreement between report and architecture_comparison is a manual self-check.
Emit ARM64 in Terraform:
instance_type = "m7g.xlarge" (etc.)runtime_platform { cpu_architecture = "ARM64", operating_system_family = "LINUX" }architectures = ["arm64"]docker build --platform linux/arm64 (not multi-arch by default)
Include a “Graviton Migration Notes” section in the output docs: services moved to arm64, any conditional caveats, and the recommendation to validate with a load test post-migration.Default to Graviton (no Clarify question) when ALL services are ready — containerized Python/Node/Go/PHP/Ruby/pure-JVM Java, Lambda with no native binary layer, or a Graviton-supported managed service, and the user has not opted out.
Ask in Clarify when any service is conditional with risk signals (JNI, niche C extensions, native gems, vendor AMIs, recompile-required languages).
Never recommend Graviton for Windows/.NET Framework, GPU/CUDA (route to G5/G6), RDS SQL Server, or x86-only native dependencies without an arm64 alternative — or when the user opted out in Clarify.