Licensing PeopleSoft, JD Edwards, Siebel and Other Oracle Apps on AWS: Step-by-Step Guide

Oracle Applications and AWS: The Foundational Licensing Rules

Oracle certified its software for deployment on Amazon EC2 in 2010, establishing AWS as an authorised cloud environment for Oracle workloads. This authorisation is important: it means Oracle will provide technical support for Oracle software running on AWS, and it means the standard Oracle license terms apply to AWS deployments in the same way they apply to on-premises deployments. Oracle does not provide special licensing terms, discounts, or bundles for AWS — you bring your own licenses.

The core licensing principle is straightforward: every Oracle product you deploy on AWS must be covered by an existing Oracle license that you own. AWS does not sell Oracle licenses and does not bundle Oracle software with any EC2 instance type. If you are running Oracle E-Business Suite, PeopleSoft, JD Edwards, Siebel, or any other Oracle application on AWS, you need BYOL coverage for both the application itself and for all Oracle technology products that the application depends on — including Oracle Database, Oracle WebLogic, and any other Oracle Middleware components in the stack.

The vCPU Counting Rule

AWS EC2 instances are sized in vCPUs. Oracle's licensing rule for authorised public cloud environments — which explicitly includes AWS — is that two vCPUs equal one Oracle Processor license, provided hyper-threading is enabled (which it is on all modern EC2 instance types). An m5.4xlarge instance with 16 vCPUs therefore requires 8 Oracle Processor licenses for any Oracle software running on it. An r6i.8xlarge with 32 vCPUs requires 16 Processor licenses.

This 2:1 vCPU rule is Oracle's published policy for authorised cloud environments. It is more favourable than the on-premises calculation for many Intel-based servers, where the core factor of 0.5 applied to physical cores produces the same result but requires counting actual cores rather than virtual ones. The vCPU rule simplifies the arithmetic — but SAM managers should validate their calculations against specific instance type documentation, as the vCPU counts for complex instance configurations should always be confirmed against AWS's published specifications.

Step 1: Inventory All Oracle Products in Your AWS Deployment

The first step in any Oracle application licensing assessment for AWS is a complete inventory of every Oracle product installed or running in the target environment. This includes the application product itself (PeopleSoft, JD Edwards, Siebel, etc.), the Oracle Database instance used by the application, all Oracle Middleware components (WebLogic Server, Coherence, Oracle HTTP Server, Oracle Service Bus, etc.), and any Oracle database options enabled on the application's database.

This inventory step is frequently underestimated. Application teams often focus on the application license and overlook the Oracle technology stack underneath it. A PeopleSoft deployment, for example, may run on Oracle Database Enterprise Edition with WebLogic Server, Oracle Identity Governance, and Oracle Access Manager — each of which requires its own separate license coverage. An incomplete inventory produces an incomplete licensing assessment, and gaps discovered later become audit exposure.

The inventory should capture not just the product names but the specific editions, versions, and — for Oracle Database — the options and features that have been enabled or used. Refer to the Oracle LMS database script output process described earlier in this hub for the methodology to capture database-level option usage.

Step 2: Understand Application-Specific Licensing Models

Oracle's major application products are licensed differently from each other and from Oracle Database. SAM managers must understand the specific licensing model that applies to each application before calculating AWS deployment requirements.

PeopleSoft Licensing on AWS

PeopleSoft is licensed per module, per user. The licensing model uses Named User Plus (NUP) or Processor licensing depending on the specific modules and the negotiated terms. Most PeopleSoft deployments include restricted-use Oracle Database Enterprise Edition licenses — these are database licenses that Oracle includes with PeopleSoft specifically for hosting the PeopleSoft schema, and they are not general-purpose database licenses.

The restricted-use database license covers the Oracle Database instance that hosts the PeopleSoft schema — and that schema only. If you run any other database workload on the same Oracle Database instance (reporting databases, custom application tables not part of PeopleSoft's schema, ETL staging tables), that additional usage may not be covered by the restricted-use entitlement and could require a separate full Oracle Database license.

PeopleSoft also typically includes restricted-use licenses for Oracle WebLogic Server (used for PeopleSoft's Internet Architecture — PIA). The WebLogic restricted-use license covers PeopleSoft's web and application tier components. Using the same WebLogic installation for additional applications requires separate WebLogic licensing.

On AWS, PeopleSoft runs on EC2 instances. The vCPU rule applies to the Oracle Database license calculation. The user-based licenses (NUP) are independent of the AWS infrastructure and are calculated based on the number of named users accessing PeopleSoft, not the size of the EC2 instances. Processor-based PeopleSoft licenses — less common but present in some older contracts — require EC2 vCPU-based calculations.

JD Edwards Licensing on AWS

JD Edwards EnterpriseOne licensing is primarily user-based, using a model that distinguishes between Full-Use named users (who have access to all JDE functionality), Limited named users, and Self-Service users (for employee or manager self-service access). The user count basis is the number of named individuals who have been granted access to the JDE system, not the number of concurrent users.

Like PeopleSoft, JDE deployments typically include restricted-use Oracle Database licenses for the JDE schema. The same schema-restriction principles apply — the restricted-use database license covers JDE data, not general-purpose database workloads. JDE also requires Oracle WebLogic Server for its web tier, typically covered under a restricted-use WebLogic entitlement included with the JDE license.

On AWS, the JDE application tier and database tier are typically deployed on separate EC2 instances or instance groups. The database instances require BYOL Oracle Database coverage calculated on the vCPU basis. The application tier (JDE Business Services, Web tier) running on WebLogic requires BYOL WebLogic coverage if the restricted-use entitlement is insufficient for the deployment scale.

Siebel CRM Licensing on AWS

Siebel CRM licensing is based on named user or Processor metrics, with the specific model depending on your contract. Siebel deployments on AWS follow the same BYOL principles: Siebel application licenses, Oracle Database licenses for the Siebel schema, and any applicable Oracle Middleware licenses must all be brought from your existing entitlements.

A key Siebel-specific rule: Oracle does not require additional Oracle Database licenses when running Siebel CRM on AWS if the database is used exclusively for Siebel schemas. AWS EC2 hosting Siebel CRM with an Oracle Database instance used only for Siebel data falls within the restricted-use database entitlement included with Siebel. However, running custom applications or additional schemas on the same Oracle Database instance requires separate full Oracle Database licensing.

SAM managers should audit all database users and schemas on any Siebel database instance to confirm the exclusive Siebel use restriction is maintained. If any non-Siebel workload has been placed on that database instance — even temporarily, for testing or reporting purposes — the exclusive use restriction is broken and additional database licensing may be required.

Hyperion / Oracle EPM on AWS

Oracle Hyperion (now marketed as Oracle Enterprise Performance Management) is typically licensed per CPU or per user, with the specific metric depending on the Hyperion product module and contract vintage. Hyperion deployments often involve multiple Oracle technology components — Oracle Database, Oracle WebLogic, Oracle HTTP Server — each requiring separate BYOL coverage unless restricted-use entitlements are explicitly included in the Hyperion license agreement.

Hyperion Financial Management, Hyperion Planning, and Essbase each carry their own licensing requirements. SAM managers working with Hyperion on AWS should review the specific license agreements for each Hyperion product in use and map those entitlements carefully to the AWS deployment architecture before migration.

Step 3: Map Your License Entitlements to the AWS Architecture

Once you have completed your inventory and understand the specific licensing models for each product, the next step is mapping your existing license entitlements to the target AWS architecture. This mapping exercise answers a critical question: do your current Oracle licenses cover the workload you plan to deploy on AWS, or are there gaps?

Processor License Mapping

For Processor-licensed products (typically Oracle Database), the mapping exercise involves calculating the number of Oracle Processor licenses your target EC2 instances require and comparing that to your entitlement. Use the 2:1 vCPU rule to convert your planned EC2 instance sizes to Oracle Processor license requirements. Then compare that requirement to your current on-premises license entitlement.

Remember Oracle's license mobility provision: if you are migrating a workload from on-premises to AWS, you can apply the same on-premises licenses to the AWS deployment, provided the on-premises and AWS instances are not running simultaneously using the same license. A lift-and-shift migration where you decommission on-premises infrastructure as you bring up AWS instances is typically within the mobility provision.

A parallel run — where on-premises and AWS instances are both active during a migration period — creates a dual-use scenario that may require additional license coverage. SAM managers should document the parallel run period and confirm with their Oracle account team whether the planned overlap period falls within acceptable mobility provisions.

Named User Plus Mapping

For user-licensed products, the mapping focuses on the licensed user count rather than infrastructure sizing. Confirm that your current NUP entitlement covers all users who will access the application on AWS. If the migration includes adding new users, additional licenses may be required. If the migration reduces user access (for example, consolidating from multiple data centres to a single AWS deployment with fewer concurrent users), the license requirement should not change — NUP licenses are based on named individuals, not concurrent users or server capacity.

Step 4: Validate Oracle Database Options in the Application Environment

Many Oracle application environments — particularly PeopleSoft, JDE, and EBS — have Oracle Database options enabled that are not covered by the application's restricted-use database entitlement. This is one of the most common sources of unexpected compliance exposure in Oracle application AWS migrations.

Before migrating any Oracle application database to AWS, run the Oracle LMS database script (specifically the options script that queries DBA_FEATURE_USAGE_STATISTICS) against every database instance in scope. Identify any database options or management packs with non-zero detection counts. Cross-reference each detected feature against your license entitlements. If you have Diagnostics Pack detections on a PeopleSoft database, you need a separate Diagnostics Pack license — the PeopleSoft restricted-use database entitlement does not cover database management packs.

Remediating these option exposures before migration is strongly recommended. Options that are disabled before the AWS migration will not create compliance claims on the AWS side. Options carried forward into AWS with the migrated database remain a compliance exposure and are no more defensible in the cloud than on-premises.

Step 5: Confirm Active Oracle Support Requirements

Oracle's BYOL policy for authorised cloud environments explicitly requires that licenses deployed under BYOL maintain active Oracle support contracts. This requirement applies to all Oracle products deployed on AWS — the application licenses, the database licenses, and all middleware components. There are no exceptions.

If your organisation has cancelled Oracle support on some products — for example, by moving to a third-party support provider — those products cannot be used under BYOL on AWS without first reinstating Oracle support. Before any AWS migration, confirm the active support status of every Oracle product you plan to deploy. Organisations that have partially or fully dropped Oracle support must either reinstate that support or restructure their cloud architecture to avoid using the unsupported products in the AWS environment.

The Support Fee Compound Effect

Oracle support fees increase at 8% per year. For organisations that have been on Oracle support for several years, the current annual support bill is substantially higher than the original support cost at the time of license purchase. This compounding increase is a financial driver for some organisations to evaluate third-party support alternatives. However, the BYOL cloud requirement creates a constraint: if you want the flexibility to deploy Oracle applications in AWS without restricting yourself to full license purchases, you must maintain active Oracle support.

This creates a strategic dependency that SAM managers should model explicitly in any cloud business case. The cost of maintaining Oracle support for the sole purpose of preserving BYOL cloud deployment rights is a real and ongoing cost that should be included in cloud total cost of ownership calculations.

Step 6: Address Partitioning and Sub-Capacity Licensing

Oracle does not recognise any AWS-native partitioning mechanism as a valid basis for sub-capacity licensing. EC2 instance types are virtual machines — they do not constitute hard partitioning in Oracle's terms, and Oracle will not accept vCPU restrictions or EC2 instance size limits as a basis for licensing fewer than the full vCPU count of a given instance type.

The only practical approach to achieving sub-capacity licensing on AWS is through Oracle's Dedicated Hosts feature in combination with Oracle VM Server. This approach — deploying Oracle software on bare-metal EC2 instances using Oracle's own hypervisor — is technically supported by Oracle as a hard partitioning mechanism, but it is operationally complex, typically more expensive than standard EC2 deployment, and rarely used in practice. For the vast majority of AWS deployments, assume full-capacity licensing based on the total vCPU count of each EC2 instance running Oracle software.

Step 7: Document and Govern the AWS Oracle Deployment

Maintaining clear documentation of your AWS Oracle deployments is essential for ongoing compliance governance. For each EC2 instance running Oracle software, document the Oracle products installed, the instance type and vCPU count, the license metric and entitlement used, the active support contract details, and the date the instance was deployed. This documentation serves as your primary evidence base in the event of an Oracle license review.

Implement governance controls that prevent unauthorised Oracle software deployment in your AWS environment. In practice, this means including Oracle licensing review in your cloud deployment approval process, maintaining a CMDB or asset register that tracks Oracle instances in AWS, and conducting periodic self-assessments using Oracle LMS scripts to confirm compliance status. AWS Config rules or tagging policies can support automated detection of EC2 instances running Oracle software.

Common Compliance Traps to Avoid

Experience across hundreds of Oracle application cloud migrations identifies several compliance traps that SAM managers must actively guard against. First, expanding the application schema on a restricted-use database by adding custom tables or integrations outside the application's licensed scope breaks the restricted-use provision. Second, cloning the application database for development or testing without confirming that the clone environment is covered by the application license or a separate development license creates duplicate licensing exposure. Third, running Oracle Middleware on the same server as the application without confirming that the restricted-use middleware entitlement covers the deployment scale is a frequent oversight. Fourth, auto-scaling EC2 instances that temporarily expand to larger instance types during peak loads can create periods of under-licensing if the license entitlement is sized only for normal operating capacity.

Each of these traps is avoidable with proper governance design. The key is building Oracle licensing considerations into your AWS architecture decisions from the beginning rather than attempting to retrofit compliance onto a deployed environment.