From GCP to a Production AWS HPC Platform in 10 Weeks

Chip design is compute-intensive. Runs of Cadence and Innovus through Slurm-orchestrated parallel clusters can spike to hundreds of cores on demand, sit idle for hours between jobs, and resume at full throttle when a designer submits the next simulation. The cost curve for that workload shape matters more than almost anything else in the infrastructure budget.

This customer had built that workload on Google Cloud Platform. It ran. But as their roadmap scaled and their usage of AWS-native HPC services became more attractive — AWS ParallelCluster, FSx for high-performance storage, EC2 c7a compute, and MAP funding to offset the transition — they wanted to know what a clean GCP-to-AWS migration would actually cost, perform like, and take to execute.

They wanted the numbers and a working landing zone.

We started with a fixed-scope, three-week AWS Migration Acceleration Program (MAP) assessment: migration readiness, Well-Architected review, and a cost analysis with the right target architecture for the workload shape.

The assessment produced three things the customer’s leadership actually needed:

• A Migration Readiness Assessment naming the workloads in scope and the sequencing risk, account by account.
• A Well-Architected findings report across security, reliability, performance, cost, operational excellence, and sustainability.
• A cost model comparing GCP run-rate to a modeled AWS run-rate with specific instance families (c7a.large compute), Spot-instance headroom, FSx + EFS + S3 storage sizing, and networking costs priced in (NAT, Route 53, VPN).

With the numbers and the plan in hand, they greenlit the next phase.

The engagement ran as a sequence of fixed-scope phases — assessment, proof of concept, migration, pilot expansion, and post-cutover support — each with its own scope and success criteria. The migration itself executed in ten weeks; the surrounding work shaped the architecture going in and stabilized it after.

Assessment (3 weeks). MAP business case, readiness report, Well-Architected review, cost analysis.

Proof of Concept (2 weeks). A working AWS environment for the HPC workload: Cadence License Server stood up, RES stack configured, ParallelCluster (Slurm) wired in, Innovus and Exostellar Infrastructure Optimizer overlay validated. End-state: a running cluster and a concrete cost breakdown.

Migration (10 weeks). Four sub-phases — Discovery & Planning, Design, Build (Infrastructure as Code), Go-Live & Handoff. The landing zone, the production-ready infrastructure, and the documentation handed over to the customer’s engineering team.

Pilot Expansion (4 weeks). Scaling to production with up to 20 workloads migrated, Terraform and CloudFormation for IaC, ParallelCluster provisioning extended, Slurm database in place.

Post-Cutover Stabilization (6 weeks). The real-world issues that only surface after cutover — Exostellar compatibility with a new software update, Spot-instance migration problems, parallel-cluster reconfiguration. Addressed and returned to IaC.

The target was not a lift-and-shift. It was an AWS-native architecture designed around the specific behavior of EDA workloads: bursty compute, heavy-IO shared storage, license-server dependencies, and engineer access from distributed locations.

Compute via AWS ParallelCluster and Slurm. The scheduler stayed Slurm — familiar to the engineering team — but underneath, ParallelCluster managed EC2 provisioning and autoscaling against the job queue. Jobs pulled c7a.large instances on demand; the cluster scaled down when the queue emptied. Spot instances added cost headroom where job restart tolerance allowed.

Shared high-performance storage on FSx and EFS. Innovus and other EDA tools lean hard on shared filesystem semantics. We used FSx for OpenZFS where performance and feature parity mattered, and EFS where POSIX semantics and elastic scaling fit better. S3 Standard served as the durable object tier behind both.

RES for engineer desktops. Remote Engineering System gave distributed designers secure, authenticated access to the Linux environment where the EDA tools ran — no VPN gymnastics, no per-desktop SSH sprawl.

License servers on EC2 with Secrets Manager. Cadence and related licensing moved to dedicated EC2 instances with Secrets Manager holding the Slurm munge keys and other sensitive material. No credentials in code, no shared SSH keys.

A custom VPC with proper zoning. Public and private subnets, NAT gateway, Route 53 for DNS, AWS Organizations separating dev, staging, and production. Systems Manager Session Manager replaced SSH for administrative access.

Exostellar Infrastructure Optimizer for cost tuning. The Exostellar overlay handled workload-aware cost optimization on top of the AWS primitives — moving work between Spot and on-demand capacity without the engineering team managing it by hand.

A production-ready environment, delivered as IaC. The full landing zone, networking, identity, HPC cluster, shared storage, licensing, and observability — all deployed from Terraform and CloudFormation. The customer’s engineering team can reproduce, modify, and extend the environment without re-engaging us.

Twenty workloads migrated in pilot expansion, ready for scale-out. The pilot phase moved up to twenty workloads onto the new AWS platform with the ParallelCluster + Slurm setup validated under real jobs.

Well-Architected-compliant by design. The environment was designed against the six Well-Architected pillars from the assessment forward — not retrofitted under audit pressure later.

MAP-funded. The program qualified for MAP funding with the right tagging strategy in place for cost tracking. Eligibility for AWS funding programs is entirely AWS’s call; this engagement qualified.

Post-cutover issues, addressed. When a third-party optimizer update broke compatibility and Spot-instance migration hit problems, we came back in to update the IaC, reconfigure the cluster, and return the environment to steady state.