AWS in Switzerland and Austria (Alps)
How Pix4D Cut Infrastructure Costs by 20% with AWS Graviton
Cloud infrastructure costs remain a crucial focus for organizations of all sizes. In this blog post, we’re sharing the journey of Pix4D, who successfully reduced their AWS compute costs by 20% through a strategic migration to AWS Graviton processors. Their story offers valuable insights for teams considering similar cost optimization initiatives.
The Challenge: Rising Infrastructure Costs
Pix4D, a leading provider of photogrammetry software and end-to-end mapping solutions that handles millions of daily image processing transactions, was experiencing the typical growing pains of cloud infrastructure scaling. As their customer base expanded, so did their AWS bill-particularly for the compute resources powering their containerized microservices architecture.
When considering their cloud infrastructure strategy, Pix4D aimed to balance performance with cost efficiency. The customer was running their containerized services on Amazon Elastic Container Service (ECS). While their application was performing well on x86-based EC2 instances, they were looking for ways to optimize costs without sacrificing performance.
Enter AWS Graviton
After evaluating multiple cost-reduction strategies, the Pix4D team identified AWS Graviton processors as a promising solution. AWS Graviton is a custom-built ARM-based CPU developed by AWS, and it is designed to deliver the best price performance for a broad range of cloud workloads running on Amazon EC2. Graviton-based instances provide up to 40% better price performance while using up to 60% less energy than comparable EC2 instances.
The shift from x86 to ARM architecture presented both opportunities and challenges. ARM processors utilize a different instruction set, which can require recompilation of applications and dependencies. However, many modern programming languages and frameworks have added ARM support, making transitions increasingly feasible. For containerized applications like Pix4D’s, this architectural difference meant carefully testing compatibility across their technology stack.
To validate these potential benefits for their specific workloads, Pix4D needed to verify compatibility with their existing application stack and quantify the real-world performance impact. This led the team to develop a structured migration approach that would minimize risk while maximizing the cost benefits.
The Migration Journey
1. Proof of Concept
The team started with a small proof-of-concept, selecting two non-critical microservices to test on Graviton: one implemented in Python with standard dependencies and one implemented in Golang. This phase revealed several important considerations:
- Python application with C extensions required recompilation
- There were no incompatible extensions for the ARM cross-compilation
- Golang application was already compatible with the ARM architecture (as only configuration modifications were applied)
- No code changes were needed
With these findings in mind, the team proceeded to implement cross-architecture building capabilities within their existing CI/CD infrastructure.
2. Cross-Building Applications for ARM
The Pix4D team implemented a multi-architecture build strategy in their continuous integration (CI) pipeline using Concourse OCI build by adding a single attribute:
IMAGE_PLATFORM: linux/arm64,linux/amd64
Alternatively, you can achieve this by leveraging two jobs, each building their own target platform.
This approach allowed them to build ARM-compatible containers even from x86 development environments thanks to cross-compilation.
Both Buildah and Docker provide capabilities to build container images for different architectures (like ARM64, ARMv7, etc.) while working on an x86 platform. This cross-architecture building is crucial for developing applications that need to run across diverse hardware environments.
Existing Technology Stack Compatibility
One of the most surprising aspects of the migration was how smoothly the existing technology stack adapted to ARM64 architecture. The team was using a containerized environment with several applications that included C dependencies, specifically:
- Python web applications using Django
- PostgreSQL connectivity through the Psycopg2 C module
- Bjoern WSGI server (a fast, lightweight WSGI server implemented in C)
Despite these compiled C dependencies, the team did not need to modify their Dockerfile or adjust any Python dependencies. They simply used their existing Dockerfile with Python (UV) dependencies and built it for ARM64 architecture without any modifications. The cross-compilation process handled all the necessary adaptations for the new architecture transparently.
This seamless compatibility demonstrated that modern build tools have significantly matured in their multi-architecture support, making architecture transitions much more straightforward than they were in the past. The fact that compiled C extensions-traditionally a common source of architecture-specific issues-“just worked” showcases how container ecosystems have evolved to facilitate cross-architecture deployments.
3. Creating Multi-Architecture Manifest Files
To simplify deployment, they created multi-architecture manifest files that could point to the appropriate image based on the underlying hardware. For example, for their separate build jobs, they wanted to maintain a single manifest file:
This technique provided a single image link that automatically served the correct architecture picked at runtime by the container runtime.
4. Validating the Multi-Architecture Build
At Pix4D, most of the developers are working either on macOS with ARM-base Apple silicon processors, or Linux x86-based laptops.
Emulation warning on Docker Desktop for Apple silicon:
One of the goals was also to provide native containers runtime to developers in their local environment when working on their service by pulling pre-built services. The developers could immediately see the speed increase when running their tests.
Being able to validate it without any configuration change, was key to show the ease of migration and gain support to proceed further.
5. Infrastructure as Code Modifications
Pix4D used Terraform to manage their ECS clusters and needed to modify their configurations to support running their task on AWS Fargate instances powered by AWS Graviton processors (the bold part was the only needed change):
resource "aws_ecs_task_definition" "pandora" {
family = "pandora"
cpu = 256
memory = 512
network_mode = "awsvpc"
requires_compatibilities = ["FARGATE"]
task_role_arn = aws_iam_role.appserver.arn
execution_role_arn = aws_iam_role.appserver_task_execution.arn
container_definitions = jsonencode([
local.python_container_definition,
local.golang_container_definition,
])
runtime_platform {
operating_system_family = "LINUX"
cpu_architecture = "ARM64"
}
lifecycle {
create_before_destroy = true
}
}To be exact, Pix4D had defined only 1 ECS cluster while having 2 separate Task Definitions with different runtime_platform configurations and 2 ECS services (1 for each task definition). One Task Definition had the extra runtime_platform attributes to be executed on an ARM64 CPU architecture. The ECS service was duplicated, pointing to the ARM64 Task Definition, and linked to the existing ECS cluster.
6. Implementation Strategy
Pix4D designed a phased migration approach to minimize risk while transitioning to Graviton processors. They began by creating a mixed-architecture ECS cluster that incorporated both x86 and ARM-based tasks, allowing existing workloads to continue running alongside new Graviton instances.
Full x86 initial service architecture
The team prioritized their services for migration, starting in their staging environment to run equal numbers of task instances. They have used a static task instance count and divided it equally between x86 and arm64 task instances onto two ECS services served through the same Application Load Balanber (ALB). This allowed them to observe the performance difference (if any) between the two services.
For their service, Pix4D employed a blue/green deployment approach-launching the ARM-compatible task alongside the existing x86 version, gradually scaling in the x86 version to the same number of tasks as 64-bit ARM, after confirming stability. This methodology significantly reduced the risk of service disruption and allowed it to quickly revert back to a full x86 service.
Dual x86 and arm64 platforms parallel run
The deployment pipeline was also adapted to deploy code changes onto both services simultaneously to ensure developers could continue delivering daily changes. That provided an opportunity to continue developing features while using time to validate the performance indicators.
As confidence grew, the team took another step to migrate their production workload to the dual mode platform. High-traffic customer-facing services were migrated following the same approach with expanded monitoring and support staff on standby.
After two months of dual traffic observability in production, Pix4D completed their infrastructure transformation by migrating all remaining x86 ECS tasks to ARM-based Graviton processors. This gradual approach not only ensured continuous service availability but also provided development teams with a demonstration on how to perform a low level platform transformation with multi-steps environment rollouts.
Moving fully to ARM-based Graviton instances
“We saw absolutely no performance discrepancy between the two clusters of our service handling our customers’ traffic. We were totally confident that we could switch all traffic to Graviton powered instances, and would continue to move more of our services to Graviton,” said Marc-Aurèle Brothier.
Monitoring and Validation
Pix4D implemented a comprehensive monitoring strategy to ensure their Graviton migration delivered no performance impact. The team extended their existing Grafana dashboards to create side-by-side comparisons between x86 and ARM instances, tracking key performance indicators across both architectures.
Monitoring in staging during the parallel run of both platforms
The customer implemented metrics that specifically measured application response times, throughput, and error rates on both platforms. This comparative data proved essential for validating that each service maintained or improved its performance profile after migration.
The monitoring approach also included detailed resource utilization tracking to understand how workloads behaved differently on Graviton processors. CPU utilization patterns, memory consumption, and I/O operations were all closely observed to identify opportunities for further optimization.
Cost optimization was the primary driver of Pix4D’s Graviton migration. Finance and Engineering teams collaborated to build comprehensive cost dashboards that tracked compute spending by instance type and workload, providing immediate visibility into realized savings as services transitioned. These dashboards became critical tools for demonstrating ROI to business stakeholders, with concrete metrics showing the 20% cost reduction achieved across migrated workloads. This financial transparency helped secure continued executive support and established the business case that justified the engineering effort required for the migration.
Results: 20% Cost Reduction with Improved Performance
After fully transitioning to AWS Graviton processors, Pix4D conducted a thorough analysis comparing six months of production metrics before and after the migration. The results were compelling and exceeded their initial expectations.
The company realized an overall 20% reduction in their ECS compute infrastructure costs, translating to significant annual savings. One, often underlooked, performance improvement that came along with this change was the developer productivity gain. All their developers were now developing using native image runtimes in their local multi-service cluster.
“We initially approached the Graviton migration as a pure cost-saving measure,” said Marc-Aurèle. “What we didn’t anticipate was that it would make our developers happier on their Apple silicon platform transparently.”
The migration also simplified their container management processes. With multi-architecture images in place, their operations team did not have to maintain separate deployment processes for different hardware types. The single multi-architecture image approach provided the flexibility to deploy to any node type without additional configuration, making their infrastructure more resilient and adaptable to future changes.
“The combination of reduced costs and improved performance has been transformative for our business,” added Marc-Aurèle Brothier. “It’s allowed us to pass some of those savings on to customers while reinvesting the rest into developing new features for our photogrammetry platform.”
Key Lessons Learned
- Start small: Begin with simple services to identify any compatibility issues.
- Invest in CI/CD enhancements: Multi-architecture builds require some upfront pipeline adjustments but pay dividends later.
- Test thoroughly: While most applications work seamlessly on ARM-based infrastructure, comprehensive testing is essential, especially for applications with dependencies on compiled libraries.
- Monitor carefully: Detailed performance metrics help build confidence in the migration and identify any optimization opportunities.
- Leverage infrastructure as code: Terraform made it easier to manage mixed-architecture environments during the transition.
Conclusion
AWS Graviton processors offered Pix4D a compelling option for optimizing their cloud infrastructure costs without sacrificing performance. By following a methodical approach to multi-architecture container builds, CI pipeline integration, and gradual deployment, Pix4D achieved significant cost savings while actually improving their application performance.
For most workloads, the technical barriers to ARM migration are lower than many teams expect, making Graviton adoption one of the most straightforward ways to reduce AWS compute costs.
Ready to transform your cloud economics? Check out the re:Invent talk and AWS Graviton Migration Guide to start your journey today and reach out to your AWS account team and Solutions Architect to develop a customized migration strategy that aligns with your business goals.