Boosting ECS Costs Savings: Moving to Graviton with Fargate Spot

Introduction

Reducing cloud costs is always the top priority and biggest headache for Devops Engineers, especially when using managed AWS services like ECS Fargate. For one of our Ad-Tech clients at TO THE NEW, we were already utilising Fargate Spot to reduce the ECS bill significantly. But we found that we could save even more money if we moved their ecs application to AWS Graviton (ARM) tasks and ran the workload on the spot at the same time. We will explore the process step-by-step in this brief blog.

AWS Fargate

Graviton: But Why?

Comparing AWS Graviton to standard x86 processors, ARM-based AWS Graviton processors are more efficient per dollar. Using Graviton to run ECS Fargate Tasks allows us to save more money while maintaining the same or even better performance.

Since we were already using Fargate Spot Tasks to manage workloads at up to 90% less cost than On-Demand, combining Graviton with Spot promised even greater savings.

AWS Graviton

Problem Statement

Most of our applications were written in Java, and JAR files are created as artifacts by the Maven build process. In the past, Docker images were designed specifically for the x86 architecture, and all Maven builds were carried out on x86 Jenkins agents (EC2 nodes). Compatibility, performance, and a smooth deployment process had to be ensured for moving to Graviton.

Key considerations included:

• Workload could still operate correctly on Docker images based on ARM.
• The new Graviton Docker images are being incorporated into ECS Task Definitions (TDs) correctly.
• Graviton performance is evaluated in non-prod environments before production rollout.
• Update the sidecar (fluentbit in our case) container image to arm64 compatible, as well that the entire task can either be arm-based or x86.
• Strategic and careful rollout in production to avoid service downtime.
• Observing cost reductions and monitoring the performance.

Steps

Step 1: Build Process

The Java build remained on x86 nodes because the JAR compilation process is architecture-independent. However, for the container images build, we created new Graviton-based build Jenkins agents.

Following this approach allowed us to:

• Keep the code build part consistent on x86 nodes.
• Package the final container image on ARM (Graviton), ready for ECS deployment. For this, we used base Java Docker images that are either multi-architecture or ARM-based.
• Keeping the existing CI/CD pipelines mostly unchanged while introducing Graviton image builds. For moving artifacts across x86 and Graviton agents, we used the stash/unstash feature provided by Jenkins.

Step 2: Updating Task Definitions

In ECS, we have to modify Task Definitions to support the ARM architecture:

• Referenced to the new Graviton-based Docker images, which were pushed to ECR after the build process.
• Specify the runtime platform to tell ECS that the container should run on ARM64 Linux:

"runtimePlatform": {
    "cpuArchitecture": "ARM64",
    "operatingSystemFamily": "LINUX"
}

• Existing environment variables, secrets, and configurations were kept the same.
• Ensure logging, memory, and CPU parameters were still appropriate for ARM architecture.

By updating the TDs, we ensured that the same ECS services could now run Graviton containers without any runtime changes.

Step 3: Performance Testing

Before moving to production, we performed performance/load testing in lower environments.

We observed:

• CPU and memory utilization under normal and peak loads.
• Response Time and throughput of critical APIs.
• Logs and metrics from ECS and CloudWatch to identify any architecture-specific issues.
• The outcomes were positive: Graviton-based containers used fewer resources and performed on par with or better than x86 images.

Step 4: Production Deployment

We used a canary deployment approach for production:

• Graviton containers were deployed for a limited portion of the traffic initially.
• Tracked error rates, logs, and metrics.
• Upgrades were implemented for all ECS services once confidence was high.

By shifting the workload to Graviton, this strategy guaranteed zero downtime and decreased risk.

Step 5: Cost Impact

• Combining Fargate Spot with Graviton led to a noticeable reduction in production costs.
• Spot tasks continued to handle most traffic at a fraction of the On-Demand cost.
• ARM-based images further improved performance per dollar.
• ECS services maintained high availability and responsiveness, with Spot interruptions handled automatically.
• The result: optimized infrastructure cost without sacrificing reliability or performance.
  

  cost savings

Conclusion

For cost-conscious companies, switching to Graviton for ECS applications is a great move. The approach we followed shows that you can save money without compromising performance or stability. With appropriate testing, updated task definitions, and a controlled deployment strategy, production workloads can fully benefit from ARM-based architectures while still utilising Spot pricing for maximum savings.

This migration demonstrates TTN’s commitment to optimising cloud costs without sacrificing reliability by guaranteeing that our clients receive both performance and efficiency in their production workloads. To learn more about how TO THE NEW can improve performance and reduce cloud costs for your business, get in contact with us. We would be happy to help you with your cloud optimisation endeavours.

Key Takeaways

• Java JARs can still be built on x86 nodes; final Docker images can be built on ARM nodes.
• Updating ECS Task Definitions is straightforward yet important for the successful rollout.
• Performance testing in lower environments is important for validating Graviton’s performance.
• Using deployment strategies like Canary and rolling deployments reduces the risk of production downtime.
• Combining Graviton with Fargate Spot gives significant cost savings.