Retrospective: Adopting Green Software Practices with Graviton4 and Carbon Footprint Tools

As climate concerns push tech organizations to prioritize sustainability, our team at a mid-sized B2B SaaS provider embarked on a 12-month initiative to adopt green software practices, anchored by migrating to AWS Graviton4 processors and integrating carbon footprint measurement tools into our workflow. This retrospective outlines our goals, implementation process, outcomes, and lessons learned for teams pursuing similar sustainable engineering transformations.

Background and Motivation

Prior to this initiative, our infrastructure ran entirely on x86-based EC2 instances across three AWS regions. We had no systematic way to track carbon emissions, and internal audits revealed our compute workloads consumed 28% more energy than industry benchmarks for similar workloads. Our core goals were threefold: reduce operational carbon emissions by 40% year-over-year, maintain or improve application performance, and cut EC2-related infrastructure costs by 15%.

Why Graviton4?

We selected AWS Graviton4 as the cornerstone of our migration for its industry-leading performance-per-watt metrics: AWS reports Graviton4 delivers up to 40% better energy efficiency than comparable x86 instances for general-purpose workloads. Additional draws included native integration with AWS’s Carbon Footprint Tool, broad compatibility with our containerized microservices stack, and projected cost savings from reduced instance runtime for equivalent workloads.

Migration Process

We adopted a phased rollout to minimize risk:

1. Baseline Establishment: We used the AWS Carbon Footprint Tool and open-source Cloud Carbon Footprint to map emissions for all existing workloads, setting per-service emission targets.
2. Staging Validation: We migrated non-critical staging workloads to Graviton4 first, testing for compatibility issues with x86-specific dependencies (e.g., older versions of libc, custom C extensions).
3. Gradual Production Rollout: We shifted production workloads in batches, starting with stateless API services, then stateful data processing pipelines, and finally legacy monolithic applications.
4. Optimization: Post-migration, we tuned instance sizing, adjusted auto-scaling policies, and optimized container images to better leverage Graviton4’s ARM architecture.

Integrating Carbon Footprint Tools

We paired our Graviton4 migration with two core carbon tracking tools:

• AWS Carbon Footprint Tool: Used for high-level regional and service-level emission tracking, with native integration to our AWS Organization for consolidated reporting.
• Cloud Carbon Footprint: Open-source tool deployed in our internal Kubernetes cluster to track per-workload, per-team emissions, with custom dashboards integrated into our internal developer portal.

We also added carbon emission checks to our CI/CD pipeline: every deployment now logs estimated emissions for the target workload, with alerts triggered if deployments exceed pre-set emission thresholds.

Outcomes and Results

After 12 months of migration and optimization, we exceeded all initial targets:

• Carbon Emissions: 45% reduction in operational compute emissions, surpassing our 40% goal. Graviton4 workloads emitted 32% less CO2e per compute hour than our previous x86 instances.
• Performance: Average API latency dropped by 12%, and batch processing pipelines ran 18% faster per instance, thanks to Graviton4’s improved single-thread and multi-core performance.
• Cost: EC2 costs fell by 22%, driven by Graviton4’s lower per-hour pricing and reduced instance count from better performance efficiency.

Challenges Encountered

Our migration was not without hurdles:

• Legacy applications with hard-coded x86 dependencies required refactoring, adding 6 weeks to our timeline.
• Initial carbon tooling setup took 8 weeks, as we had to map AWS usage data to our internal service ownership structure.
• Aligning non-engineering teams (product, finance) on sustainability tradeoffs required regular cross-functional syncs.

Key Takeaways for Sustainable Engineering Teams

1. Always establish a carbon and performance baseline before starting migrations: you can’t improve what you don’t measure.
2. Test ARM compatibility early: containerized workloads simplify migration, but custom native dependencies require extra validation.
3. Integrate carbon tracking into existing developer workflows: adding emission checks to CI/CD pipelines drives accountability without adding friction.
4. Graviton4 is not a silver bullet: pair hardware upgrades with software optimizations (right-sizing, idle resource cleanup) for maximum impact.

Next Steps

We plan to migrate 100% of remaining x86 workloads to Graviton4 by Q3 2024, expand carbon tracking to cover data storage and networking emissions, and set a net-zero operational carbon goal for 2026. We also aim to open-source our custom carbon dashboard integrations to help other teams accelerate their green software journeys.

For organizations starting their own green software initiatives, Graviton4 and accessible carbon footprint tools lower the barrier to entry significantly. The business case is clear: sustainability wins align with cost savings and performance improvements, creating value for both the planet and your bottom line.