EDA Licensing on AWS: Vendor Models and License-Aware Scheduling
A practical guide to running EDA license servers on AWS — covering vendor-specific binding methods, high-availability failover patterns, and license-aware job scheduling to prevent compute waste when licenses are exhausted.
Electronic Design Automation (EDA) workloads are among the most license-intensive in cloud computing. A single tape-out run can consume hundreds of concurrent licenses across multiple tools — and those licenses typically cost 3–5× or more than the underlying compute (varies by tool and contract). This guide covers how the three major EDA vendors handle licensing on AWS, how to architect for high availability, and how to prevent your scheduler from wasting compute waiting for a license that isn't available.
Cost consideration: The AWS infrastructure described in this guide (EC2 instances, Amazon FSx, ParallelCluster, CloudWatch, Lambda) incurs ongoing charges while running. Stop or terminate resources when not in use, and review the Resource Cleanup section at the end of this guide to avoid unexpected charges.
Prerequisites
Before you begin: This guide assumes the following are already in place.
- EDA vendor license agreement — active Synopsys SolvNet, Cadence support, or Siemens license portal access
- AWS account — VPC with private subnets configured, IAM permissions for EC2, ENI management, Route 53, and CloudWatch
- HPC scheduler — Slurm (via AWS ParallelCluster) or IBM Spectrum LSF installed and configured
- AWS CLI v2 — installed and configured with appropriate credentials
- Basic familiarity with FlexLM or SALT licensing concepts and HPC job scheduling
The Universal Model: Bring Your Own License (BYOL)
All three major EDA vendors — Synopsys, Cadence, and Siemens — use the same fundamental approach on AWS: you bring your existing licenses and run a license server on an EC2 instance within your VPC. The licenses are bound to a host identifier — which may be a VM UUID, Elastic IP, Machine Fingerprint (MFP), or MAC address depending on the vendor and your contract terms. This is what makes cloud deployment possible — the identifier persists independently of the physical host, so you can fail over without re-keying your licenses.
Binding method matters for HA: The host identifier you use determines your failover strategy. Confirm with your EDA vendor which binding method is officially supported for your cloud deployment before designing your HA architecture.
| Binding Method | Vendor Support | Failover Strategy |
|---|---|---|
| VM_UUID | Synopsys (official for all clouds) | Copy/restore VM image — UUID travels with the image |
| AMZN_EIP (Elastic IP) | Synopsys (AWS-specific) | Reassign Elastic IP to standby instance (note: requires public IP — may not meet enterprise security requirements) |
| MFP (Machine Fingerprint) | Cadence (official for cloud) | Re-register MFP on standby or use Cadence HA mechanism |
| MAC address (ENI) | All vendors (commonly used, not officially recommended for cloud by ISVs) | Detach ENI → attach to standby (same MAC preserved) |
| Composite ID / Hostid | Siemens SALT (per contract) | Triad architecture with quorum-based failover |
Obtaining Your Host Identifier
Before requesting license files from your EDA vendor, you need to determine the correct host identifier for your cloud environment. The method varies by vendor:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Synopsys — VM UUID (all clouds, verify installer name with your SCL version)
sudo install_fnp.sh --cert # Install FlexNet Licensing Service first
lmhostid -ptype VM -uuid
# Output: VM_UUID=42122EC8-299B-FAB0-43EA-3AF23BDA6D57
# Synopsys — AWS Elastic IP (AWS only)
lmhostid -ptype AMZN -eip
# Output: AMZN_EIP=13.59.206.200
# Cadence — Machine Fingerprint
./mfp # Run the Cadence MFP utility
# Output: machine fingerprint hash (provide to Cadence support)
# MAC address (legacy/contract-dependent — works but not ISV-recommended for cloud)
aws ec2 describe-network-interfaces \
--network-interface-ids eni-xxxxx \
--query 'NetworkInterfaces[0].MacAddress' \
--output textImportant: Confirm with your vendor which binding method is supported under your contract before requesting license files. Using an unsupported method may work technically but won't be covered by vendor support.
Synopsys — SCL (Synopsys Common Licensing)
| Attribute | Detail |
|---|---|
| License technology | FlexLM (lmgrd + snpslmd vendor daemon) |
| Binding mechanism | VM_UUID or AMZN_EIP (officially supported for cloud); MAC via ENI also works but is not ISV-recommended |
| Default ports | 27000 (lmgrd) + vendor daemon port (configurable; commonly pinned to 27020 via VENDOR snpslmd port=27020) |
| HA strategy | EIP reassignment or VM image restore (UUID-bound); ENI failover if MAC-bound |
| Queuing | SNPS_MAX_WAITTIME=300 (jobs wait up to 5 min); SNPS_LICENSE_QUEUE=1 |
| Monitoring | lmstat -a -c 27000@synopsys-lic.eda.internal |
| Idle reclaim | TIMEOUT=3600 in options file reclaims idle licenses after 1 hour |
| AWS deployment | Strictly BYOL — no AWS Marketplace option |
How to get started: Synopsys licenses are obtained through your existing SolvNet agreement. When ordering license files, provide the MAC address of your AWS ENI. Install tools on shared storage (typically Amazon FSx for NetApp ONTAP) and point compute nodes to the license server via the
LM_LICENSE_FILE environment variable.Cadence — CDS License Manager
| Attribute | Detail |
|---|---|
| License technology | FlexLM (lmgrd + cdslmd vendor daemon) |
| Binding mechanism | Machine Fingerprint (MFP) for cloud deployments; MAC via ENI may work per contract but is not the official method |
| Default port | 5280 (lmgrd) + dynamic vendor daemon port (pin with VENDOR cdslmd port=5281; verify with your Cadence support representative) |
| HA strategy | MFP re-registration on standby or ENI failover if MAC-bound (automate with CloudWatch alarm + Lambda) |
| Queuing | CDS_LIC_QUEUE_POLL=30 (poll every 30s); CDS_LIC_QUEUE_TIMEOUT=3600 (wait up to 1 hr) |
| Monitoring | lmstat -c 5280@cadence-lic.eda.internal — usage by tool and user |
| AWS Marketplace | Cadence Managed Cloud Service is available — pre-packaged deployment with BYOL |
| Installation | Installscape batch installer (iscape.sh -batch) |
Key difference from Synopsys: Cadence offers a managed cloud deployment model where the tool infrastructure is pre-packaged, simplifying deployment. However, you still bring your own license — the managed offering doesn't change the licensing economics, only the operational overhead of standing up the environment.
Siemens EDA — SALT (Siemens Advanced Licensing Technology)
| Attribute | Detail |
|---|---|
| License technology | SALT (proprietary — not FlexLM) |
| Binding mechanism | Hostid per triad member (MAC, Composite ID, or vendor-specific — per contract) |
| Default port | 29000 (lmgrd) + 29001 (saltd vendor daemon) |
| HA strategy | Triad configuration — 3 servers (primary + 2 secondaries) with quorum-based automatic failover |
| Queuing | SALT_QUEUE_TIMEOUT=600 (wait up to 10 min) |
| License borrowing | Engineers can borrow licenses for 1–30 days for offline or remote work |
| Monitoring | saltutil -status for current usage |
| Failover | Automatic — if primary fails, secondaries elect a new primary (requires 2 of 3 available) |
Key difference: Siemens uses a triad architecture that provides automatic failover without manual intervention or Lambda automation. Deploy each triad member in a different Availability Zone for maximum resilience. Failover is typically fast (seconds, not minutes) because the quorum election is built into the SALT protocol.
Common Architecture Pattern
Regardless of vendor, the deployment pattern on AWS follows the same structure:
Failover patterns by binding type: For MAC-bound licenses: detach the ENI from the failed instance and attach to a standby (same MAC = same license). For EIP-bound (Synopsys on AWS): reassign the Elastic IP to the standby instance. For UUID-bound (Synopsys): restore the VM image on a new host — the UUID travels with the image. For MFP-bound (Cadence): re-register the Machine Fingerprint on the standby. Automate any of these with an Amazon CloudWatch alarm on the StatusCheckFailed metric triggering an AWS Lambda function.
Vendor Comparison
| Dimension | Synopsys (SCL) | Cadence (CDS) | Siemens (SALT) |
|---|---|---|---|
| License technology | FlexLM | FlexLM | SALT (proprietary) |
| HA approach | EIP reassignment or VM restore (UUID); ENI failover (MAC) | MFP re-registration or ENI failover (MAC) | Triad with automatic failover |
| Typical failover time | ~2 minutes | ~2 minutes | Seconds (quorum election) |
| AWS Marketplace option | No | Yes (Cadence Managed Cloud Service) | No |
| License borrowing | Limited | Limited | Native (1–30 days) |
| Binding | VM_UUID, AMZN_EIP, or MAC (per contract) | MFP or MAC (per contract) | Hostid: MAC, Composite ID (per contract) |
| Idle reclaim | TIMEOUT in options file | CDS_LIC_QUEUE_TIMEOUT | SALT_QUEUE_TIMEOUT |
License-Aware Job Scheduling
The Problem
Without license-aware scheduling:
- Engineer submits 1,000 simulation jobs
- Scheduler launches 1,000 EC2 instances (paying immediately)
- Only 500 VCS licenses available
- 500 jobs fail or spin-wait — burning compute cost polling for a license
The fix: Make the scheduler treat licenses as a consumable resource. Jobs only dispatch when both compute AND licenses are available.
Slurm: License-Aware Configuration
Step 1: Define licenses in slurm.conf
1
2
3
# slurm.conf — License definitions
# Format: Licenses=tool:count,tool:count,...
Licenses=vcs:500,dc_shell:200,primetime:300,innovus:150,calibre:100,xcelium:400,genus:100Apply changes: After modifying slurm.conf, restart the Slurm controller:
sudo systemctl restart slurmctld. On AWS ParallelCluster, run this on the head node. Verify with: sudo systemctl status slurmctldStep 2: Jobs request licenses at submission
1
2
3
4
5
6
7
8
# Single-license job (one VCS license for unit simulation)
sbatch --licenses=vcs:1 -p simulation run_sim.sh
# Multi-license job (4 VCS licenses for multi-core partitioned compilation)
sbatch --licenses=vcs:4 -p simulation run_partcomp.sh
# Multi-tool job (synthesis needs DC Shell + PrimeTime for timing closure)
sbatch --licenses=dc_shell:1,primetime:1 -p synthesis run_synth.shStep 3: Slurm holds jobs until resources are available
Jobs stay in
PD (pending) with reason Licenses until one becomes available — no wasted compute.Step 4: Align ParallelCluster MaxCount with license count
1
2
3
4
5
6
7
8
9
# ParallelCluster config — cap compute to match license availability
SlurmQueues:
- Name: simulation
ComputeResources:
- Name: sim-nodes
InstanceType: c7i.8xlarge
MinCount: 0
MaxCount: 500 # Matches VCS license count — no point launching more
CapacityType: SPOTLSF License Scheduler
IBM Spectrum LSF's License Scheduler goes beyond Slurm's static tracking:
1. Real-time FlexLM integration
1
2
3
4
5
6
# lsf.licensescheduler — FlexLM integration
Begin Parameters
HOSTS = synopsys-lic.eda.internal
PORT = 27000
LM_STAT_INTERVAL = 30 # Query FlexLM every 30 seconds
End Parameters2. Priority-based preemption
1
2
3
4
5
6
7
# lsb.queues — preemption configuration
Begin Queue
QUEUE_NAME = tapeout
PRIORITY = 100
PREEMPTION = PREEMPTIVE[regression exploration]
LICENSE_PREEMPTION = Y # Preempt licenses from lower-priority queues
End Queue3. Idle session harvesting
1
2
3
4
5
6
# lsf.licensescheduler — harvesting
Begin Feature
NAME = innovus
IDLE_TIMEOUT = 3600 # Reclaim after 1 hour idle
HARVEST_POLICY = SUSPEND # Suspend idle session, don't terminate
End FeaturePriority Queues for EDA Workloads
Structure queues so tape-out sign-off always gets licenses before exploratory work:
| Queue | Priority | Use Case | Spot Eligible | Preemptable |
|---|---|---|---|---|
| tapeout | Highest | Sign-off DRC/LVS, final timing | No | No |
| critical | High | Timing closure, ECO iterations | No | No |
| development | Normal | Active design work | No | By tapeout only |
| regression | Low | Nightly regression suites | Yes | By critical+ |
| exploration | Lowest | Design space exploration | Yes | By all above |
1
2
3
4
5
6
# slurm.conf — partition priorities
PartitionName=tapeout Priority=100 PreemptMode=OFF
PartitionName=critical Priority=80 PreemptMode=OFF
PartitionName=development Priority=50 PreemptMode=REQUEUE
PartitionName=regression Priority=20 PreemptMode=REQUEUE
PartitionName=exploration Priority=10 PreemptMode=REQUEUEDAG Workflows: Chaining EDA Steps
EDA flows are sequential — synthesis before place-and-route, before timing analysis. Use Slurm job dependencies so each step only requests its license when the previous step succeeds:
1
2
3
4
5
# Submit synthesis → P&R → STA → DRC as a dependency chain
SYNTH_ID=$(sbatch --licenses=dc_shell:1 -p synthesis synth.sh | awk '{print $4}')
PNR_ID=$(sbatch --dependency=afterok:$SYNTH_ID --licenses=innovus:1 -p pnr pnr.sh | awk '{print $4}')
STA_ID=$(sbatch --dependency=afterok:$PNR_ID --licenses=primetime:1 -p sta sta.sh | awk '{print $4}')
DRC_ID=$(sbatch --dependency=afterok:$STA_ID --licenses=calibre:1 -p verification drc.sh | awk '{print $4}')Monitoring Tool Utilization
You can't optimize what you can't measure. Push license utilization metrics to Amazon CloudWatch and set alarms on key thresholds:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# license-monitor.sh — run via cron every 60 seconds
TOTAL=$(lmstat -a -c 27000@synopsys-lic.eda.internal | grep "Total of" | awk '{print $3}')
IN_USE=$(lmstat -a -c 27000@synopsys-lic.eda.internal | grep "Total of" | awk '{print $6}')
aws cloudwatch put-metric-data \
--namespace "EDA/Licenses" \
--metric-name "VCSLicensesInUse" \
--value "$IN_USE" \
--unit Count
aws cloudwatch put-metric-data \
--namespace "EDA/Licenses" \
--metric-name "VCSLicenseUtilization" \
--value "$(echo "scale=2; $IN_USE/$TOTAL*100" | bc)" \
--unit PercentRecommended alarms:
- >90% utilization for 30+ minutes — license shortage, not compute shortage
- Queue wait >30 minutes due to licenses — scaling more instances won't help
- <50% utilization during business hours — over-provisioned on compute relative to licenses
Key Takeaways
| Principle | Implementation |
|---|---|
| Never launch compute without a license | Slurm --licenses flag or LSF License Scheduler |
| Cap MaxCount to license count | No point scaling 1,000 nodes if you have 500 licenses |
| Preempt for tape-out | Tape-out jobs always get licenses first — configure preemption policies |
| Reclaim idle licenses | Timeout policies (1–2 hours) on interactive sessions |
| Monitor utilization | CloudWatch metrics from FlexLM/SALT, alarm on >90% and queue wait |
| Right-size the ratio | If license utilization is consistently <70%, you're over-provisioned on compute |
| Architect for failover | Failover strategy depends on binding type: ENI for MAC-bound, EIP reassignment for Synopsys, VM restore for UUID, MFP re-registration for Cadence, triad for Siemens SALT |
Resource Cleanup
Delete resources when no longer needed: (1) ParallelCluster stack via
pcluster delete-cluster, (2) EC2 license servers (detach ENI first to preserve it), (3) Lambda failover functions, (4) CloudWatch alarms, (5) FSx file systems (warning: permanent data loss), (6) Route 53 hosted zone, (7) orphaned ENIs and EBS volumes.Considerations
- Single point of failure: Even with HA, license servers remain a critical dependency — test failover regularly
- Vendor contract restrictions: Confirm your license agreement explicitly permits cloud deployment before architecting HA
- Operational overhead: License monitoring, idle reclaim policies, and failover automation require ongoing maintenance
- Multi-region latency: License checkout adds network round-trip time — place servers in the same region as compute
As agentic AI workflows begin submitting EDA jobs at machine speed, license-aware scheduling becomes even more critical — an AI agent can exhaust a license pool in seconds without proper guardrails. Getting licensing right on AWS is a direct lever on engineering productivity: compute scales to what your licenses support, tape-out jobs never wait behind regressions, and idle licenses get reclaimed automatically.
# application-resilience# scheduled-events# application-integration# architecture-patterns# commercial-solutions
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article