Software licensing is one of the most overlooked cost drivers in cloud migration projects. It’s not mentioned in AWS pricing calculators, it’s buried in vendor-specific terms, and getting it wrong can mean six-figure compliance gaps discovered during audits. This post explains how licensing works when you move to AWS, what Bring Your Own License (BYOL) actually means in practice, how license servers fit into cloud architecture, and which decisions have the biggest financial impact.
Why licensing costs change in the cloud
On-premise licensing is typically based on physical cores, physical sockets, or named users. You buy a server with 2 sockets and 16 cores total, your license covers that hardware. Simple.
Cloud changes the model because:
- Virtual cores don’t map 1:1 to physical cores. Most vendors define their own conversion ratios. Oracle counts each vCPU as 0.5 cores for licensing purposes on AWS (but only on approved instance types). Microsoft has different rules depending on the product.
- Multi-tenancy complicates things. On shared infrastructure (default EC2), you don’t control which physical host your instance runs on. Some license agreements require you to know and declare the physical hardware.
- Elasticity conflicts with fixed licenses. If you scale from 4 to 16 instances during peak traffic, do you need licenses for 16? What about auto-scaling groups?
- License mobility rights vary by vendor. Some vendors allow you to move licenses to the cloud freely. Others require additional agreements or restrict which cloud providers qualify.
The result: what looked like a straightforward compute cost comparison becomes significantly more complex once you factor in licensing.
Bring Your Own License (BYOL) on AWS
BYOL means using your existing software licenses on AWS infrastructure instead of purchasing new cloud-specific licenses or using AWS-included licensing (which is baked into the hourly instance cost).
When BYOL makes financial sense
BYOL is typically advantageous when:
- You have active Software Assurance (SA) or equivalent maintenance agreements that grant mobility rights
- Your licenses are not fully utilised on-premise (you’re paying for them anyway)
- The license-included AWS pricing is significantly more expensive than your existing per-core cost
- You’re running workloads on Dedicated Hosts for other reasons (compliance, performance isolation)
When license-included is better
License-included (paying AWS hourly rate that bundles the software license) is often better when:
- You don’t have existing licenses to bring
- Your workloads are small or variable (pay only for hours used)
- You want to avoid license compliance tracking entirely
- The cost difference is marginal and operational simplicity has value
Key licensing scenarios by software vendor
Microsoft Windows Server and SQL Server
Microsoft licensing on AWS has specific rules that directly affect your migration cost:
Windows Server:
- License-included: Available on standard EC2 instances. The Windows surcharge is baked into the hourly rate (typically 30-50% more than the equivalent Linux instance).
- BYOL: Requires Dedicated Hosts or Dedicated Instances. You need Windows Server licenses with active Software Assurance. Each Dedicated Host is licensed based on its physical core count.
SQL Server:
- License-included: Available on RDS for SQL Server (Express, Web, Standard, Enterprise editions). Hourly pricing includes the license.
- BYOL on EC2: Requires Dedicated Hosts for SQL Server Standard and Enterprise. You assign core licenses to the physical host. Minimum of 4 core licenses per physical core.
- BYOL on RDS: Available under the “License Included” and “Bring Your Own License” models in RDS. The BYOL RDS option reduces the hourly rate because you supply the license.
Cost impact example: A db.m5.4xlarge RDS SQL Server Enterprise (license-included) costs approximately $5.50/h. The same instance as RDS BYOL is approximately $1.40/h. If you already hold Enterprise core licenses with SA, that’s ~$4,100/month savings per instance.
Oracle Database
Oracle licensing on AWS is notoriously complex but follows these principles:
- Oracle counts vCPUs, not physical cores. Each vCPU = 0.5 processor license (on “Authorized Cloud Environments” which includes AWS).
- Only certain instance types are approved. Oracle’s cloud licensing policy specifies which instance types and series are permitted for BYOL. Running on non-approved types can mean your license is non-compliant.
- Standard Edition 2 (SE2) is limited to instances with max 8 vCPUs (4 processor licenses). Exceed this and you need Enterprise Edition.
- Named User Plus (NUP) minimums apply: 10 NUP per processor license for SE2.
Options on AWS:
- RDS for Oracle (license-included or BYOL) - managed service, limited to approved instance classes
- EC2 BYOL - full control, you manage the database, licensed per vCPU
- Dedicated Hosts - gives you visibility into physical core count for license compliance
Critical consideration: If you currently run Oracle on-premise with unlimited license agreements (ULA), those typically cannot be extended to cloud. Check your ULA terms before assuming cloud coverage.
Other common commercial software
- SAP: Requires certified AWS instance types. SAP BYOL is well-documented through the SAP on AWS programme. Licensing is per-user or per-engine, not typically per-core.
- Red Hat Enterprise Linux: BYOL via Dedicated Hosts or subscription transfer. Cloud Access programme allows existing subscriptions to be used on AWS.
- VMware: Cloud on AWS runs on dedicated VMware infrastructure, and your existing vSphere licenses can apply depending on your agreement (VMware Customer Purchasing Programme terms).
AWS Dedicated Hosts: the BYOL enabler
Dedicated Hosts are physical servers allocated exclusively to your AWS account. They’re the primary mechanism for BYOL compliance because they give you:
- Visibility into physical core count - required by most per-core license agreements
- Consistent host placement - your instances always run on the same physical hardware
- License compliance tracking - AWS License Manager integrates with Dedicated Hosts to track license consumption
Cost implications
Dedicated Hosts are billed per host per hour, regardless of how many instances you run on them. A c5.large Dedicated Host (which can run multiple c5.large instances) costs the same whether it’s at 10% or 100% utilisation.
This means:
- High utilisation = BYOL wins. If you fill a Dedicated Host with instances, the per-instance cost drops significantly below license-included pricing.
- Low utilisation = license-included wins. A half-empty Dedicated Host with BYOL licenses is more expensive than using standard instances with license-included pricing.
The break-even calculation: compare your existing license amortised cost + Dedicated Host cost against the license-included hourly rate × expected hours.
License servers in cloud architecture
Many enterprise software products use license servers (FlexLM, RLM, Sentinel, Reprise) to manage floating licenses. These need special consideration during migration.
Architecture patterns for license servers on AWS
Pattern 1: License server on EC2 (simple)
Run the license server on a small EC2 instance (t3.medium is typically sufficient) in a private subnet. Configure security groups to allow license check-out traffic from application instances.
Considerations:
- Requires a static private IP (assign an Elastic Network Interface)
- Many license servers use MAC-address-locked dongles - works with ENI (the MAC address persists across stop/start)
- High availability: use an ENI that can be moved between instances in an Auto Scaling group of 1
Pattern 2: License server with host-locked licenses
Some vendors lock licenses to a specific hardware identifier. On AWS, this maps to either:
- The ENI MAC address (most flexible - survives instance stop/start and can be moved)
- The instance ID (less flexible - lost on termination)
- A USB dongle via host-based licensing (requires Dedicated Host with USB passthrough - rare and complex)
Pattern 3: Hybrid license server
Keep the license server on-premise and allow cloud instances to check out licenses over VPN or Direct Connect. This works well during phased migrations where some workloads remain on-premise.
Trade-offs:
- Adds latency to license check-out (usually acceptable - typically happens at application start)
- Creates dependency on VPN/DirectConnect availability
- Simpler licensing: no need to re-host the license server or request new host IDs from the vendor
License server high availability
License servers are often single points of failure. On-premise, this is tolerated because the server rarely changes. In the cloud, you need to design for instance failures:
- ENI-based failover: Attach the license server’s ENI to an Auto Scaling Group of size 1. If the instance fails, ASG launches a new one and the ENI (with its MAC and IP) reattaches.
- Redundant license servers: Some license managers (FlexLM) support redundant triads. Deploy 3 instances across AZs.
- EBS snapshot recovery: Regular EBS snapshots of the license server volume allow rapid recovery.
AWS License Manager
AWS License Manager is a free service that helps track and manage software licenses across your AWS environment. It’s particularly valuable for BYOL scenarios:
- Define license rules - set core/vCPU limits, instance type restrictions, and tenancy requirements
- Automatic enforcement - prevent launches that would exceed license limits
- Usage tracking - dashboard showing current consumption vs. entitlements
- Integration with Dedicated Hosts - automatically tracks host allocation and instance placement
- Cross-account support - manage licenses across an AWS Organisation
Setting up License Manager is something we include in every migration project that involves BYOL. It’s the difference between hoping you’re compliant and knowing you are.
Common licensing pitfalls in cloud migration
1. Assuming on-premise licenses automatically transfer
Most licenses don’t transfer to cloud by default. You need specific mobility rights (Microsoft SA), cloud access programmes (Red Hat), or vendor approval. Running software without verifying cloud rights is a compliance risk.
2. Ignoring the vCPU-to-core conversion
AWS vCPUs don’t equal physical cores. An m5.4xlarge has 16 vCPUs but runs on a host with hyper-threading enabled - so it’s 8 physical cores. Licensing based on vCPU count when your agreement says “per core” means you might be over-licensing (paying too much) or under-licensing (compliance risk).
3. Forgetting about auto-scaling
If your application auto-scales from 2 to 10 instances and each needs a commercial license, you need licenses for the peak. This makes BYOL with fixed license pools less attractive for elastic workloads. Consider license-included for highly variable workloads.
4. Not re-evaluating during migration
Migration is the best time to ask: do we still need this software? Could PostgreSQL replace Oracle for this workload? Could Linux replace Windows Server for this service? Re-platforming to open-source alternatives eliminates licensing costs entirely.
5. Missing the Dedicated Host utilisation math
BYOL on Dedicated Hosts only saves money at high utilisation. A Dedicated Host running 2 small instances when it could fit 16 is wasting the host cost across too few workloads. Consolidate workloads per host to maximise the financial benefit.
Decision framework: license-included vs. BYOL
Use this framework when evaluating each workload:
How licensing fits into your migration cost model
When we deliver a cloud migration, licensing analysis is part of the initial assessment phase. We map every commercial software component, verify cloud rights, and model the cost under different scenarios (BYOL vs. license-included vs. re-platform to open source).
For most SMB migrations, the answer is straightforward: use license-included for Windows and SQL Server unless you have large deployments with existing SA. For enterprise migrations with Oracle, SAP, or large Microsoft estates, the licensing analysis alone can identify six-figure annual savings through proper BYOL strategy.
The licensing decision also influences architecture:
- BYOL Oracle may push you toward Dedicated Hosts → affects instance placement and availability design
- Re-platforming from SQL Server to PostgreSQL eliminates licensing entirely → requires application changes but reduces long-term TCO
- Windows to Linux migration removes the 30-50% Windows surcharge → feasible for .NET applications running on .NET 6+ (cross-platform)
How we can help
Licensing analysis is included in every cloud migration assessment we deliver. We identify commercial software in your environment, verify cloud rights with each vendor, model the cost scenarios, and recommend the optimal strategy. For complex Microsoft or Oracle estates, we work with the vendors’ cloud licensing specialists to confirm compliance before migration begins.
If you’re planning a migration and unsure how your current licenses transfer, that’s exactly the kind of question we answer in the assessment phase.
Unsure about your licensing costs on AWS?
Book a free 30-minute call. We'll discuss your software estate and identify the best licensing strategy for your migration.
FAQ
Can I use my existing Windows Server licenses on AWS?
Yes, but only on Dedicated Hosts or Dedicated Instances, and only if your licenses include active Software Assurance. Standard EC2 instances use shared hardware where BYOL Windows licensing is not permitted by Microsoft’s terms. For most small deployments, the license-included option (paying the Windows surcharge per hour) is simpler and often cheaper.
What is the difference between license-included and BYOL on RDS?
License-included means the software license cost is bundled into the RDS hourly rate. BYOL means you supply your own license and pay a reduced hourly rate for the managed infrastructure only. BYOL on RDS is available for Oracle and SQL Server, and requires you to maintain valid licenses independently.
Do I need Dedicated Hosts for all BYOL scenarios?
No. Some products (like Oracle on RDS BYOL, or certain Red Hat subscriptions) can be used on shared infrastructure. However, per-core or per-socket licenses for Windows Server and SQL Server typically require Dedicated Hosts because you need to know and declare the physical hardware. Always verify with the specific vendor’s cloud licensing policy.
What happens to Oracle licenses when migrating to AWS?
Oracle permits BYOL on AWS under their “Authorized Cloud Environment” policy. Each vCPU counts as 0.5 processor licenses. Only certain instance types are approved. Standard Edition 2 is limited to 8 vCPUs. If you have an Unlimited License Agreement (ULA), check whether it covers cloud deployments - most do not by default.
Is it cheaper to re-platform to open source than to bring licenses to the cloud?
Often, yes - in the long term. Migrating from SQL Server to PostgreSQL or from Oracle to Aurora PostgreSQL eliminates licensing costs entirely. The trade-off is upfront migration effort: schema conversion, query rewriting, application testing. For large Oracle estates, the 2-3 year TCO comparison almost always favours re-platforming, but it requires investment in the migration itself.
