If you’ve spent any significant time managing Oracle E-Business Suite (EBS), there’s an uncomfortable truth that EBS teams know well: it’s not a workload you casually split across network boundaries. Latency gets blamed most often, but the real reason EBS has historically stayed anchored on-prem is a three-part trap: punishing licensing math, rigid VM sizing, and the non-negotiable requirement for tier co-location. Get any one of these wrong, and the business case collapses\u2014or worse, you end up paying more in the cloud than you did on-prem.<\/p>\n\n\n\n
This series focuses on EBS 12.2 running on Oracle Database 19c\u2014the current supported release and the standard deployment target for Database@Azure. <\/p>\n\n\n\n
EBS isn\u2019t just an app and a database. It\u2019s an ERP gravity well. Consider the “satellites” that orbit the core system:<\/p>\n\n\n\n
These satellites aren’t optional, and the architecture assumes everything lives in the same low-latency domain. Split the ERP island, and you don’t just risk slower forms\u2014you risk operational coupling failures that show up at the worst possible times: month-end close, payroll runs, order-to-cash cycles that depend on sub-second round-trip times between the application tier and the database.<\/p>\n\n\n\n
In Azure, Virtual Machines come in “T-shirt sizes.” For typical stateless web workloads, that’s convenient. For EBS databases, it can be punishing.<\/p>\n\n\n\n
EBS databases are notoriously memory-hungry and I\/O intensive. The VM family that finally meets your memory target almost always drags a massive CPU footprint along with it. If your Oracle licensing is core-based, you end up paying steep Oracle software costs for “ghost” CPUs you didn’t actually need\u2014just to buy the RAM you did.<\/p>\n\n\n\n
Consider a mid-size EBS database that requires 768GB of RAM and moderate CPU utilization\u2014say, 16 cores of actual sustained demand. On Azure, meeting that memory requirement pushes you into an M-series VM with 96 vCPUs. Under Oracle’s Authorized Cloud Environment licensing policy, every 2 vCPUs equals 1 processor license. That’s 48 processor licenses\u2014for a workload that genuinely needs 16 cores of compute. You’re licensing at 3x your actual CPU requirement, purely because of the memory-to-CPU ratio of the available VM shapes.<\/p>\n\n\n\n
There is a second nuance that makes the math even more painful\u2014especially for customers migrating from Unix platforms. On-prem, many infrastructure teams rely on the Oracle Processor Core Factor Table to reduce license counts. Customers running on SPARC (core factor 0.25) or POWER (core factor 1.0) platforms have historically benefited from favorable multipliers that significantly reduce the number of processor licenses required.<\/p>\n\n\n\n
When moving to Azure VMs, Oracle’s Authorized Cloud Environment policy applies a fixed counting rule: 2 vCPUs = 1 processor license (for hyper-threaded x86). Customers migrating from non-x86 platforms with favorable core factors can see their license requirements increase significantly\u2014sometimes doubling\u2014for the same effective compute capacity. And unlike on-prem, where hard partitioning (Oracle VM, Solaris Zones) can limit the licensable footprint, Azure VMs require you to license every vCPU allocated to the instance.<\/p>\n\n\n\n
\nThe Constrained vCPU “Gotcha”:<\/strong> Azure offers constrained vCPU VM variants\u2014instances that retain full memory allocation while reducing the active vCPU count (for example, a 96-vCPU class VM constrained to 48 active vCPUs). These look like the perfect technical fix for memory-heavy databases.<\/p>\n\n\n\n
Oracle’s cloud licensing policy does reference vCPU counts as the licensing basis, and recent guidance suggests constrained counts may be recognized. However, interpretations have shifted over time, and enforcement can vary. Most enterprise customers treat this as a conversation to have with Oracle licensing specialists before<\/em> committing to a deployment model\u2014not an assumption to build a business case on.<\/p>\n<\/blockquote>\n\n\n\n
That\u2019s the CPU tax: in the wrong architecture, your Oracle software cost will rapidly eclipse your infrastructure cost.<\/p>\n\n\n\n
The Shift: Oracle Database@Azure is Not “Oracle on a VM”<\/h4>\n\n\n\n
Attempts to split the difference\u2014running the EBS application tier in Azure and the database elsewhere\u2014tend to fail in production reality. EBS must move as a cohesive unit.<\/p>\n\n\n\n
This is why Oracle Database@Azure fundamentally changes the playbook. It is Oracle delivering OCI-managed database services\u2014on Exadata infrastructure\u2014physically colocated inside Azure datacenters. You provision the infrastructure through the Azure portal and Azure APIs; it appears as a native Azure resource, billed on your Azure invoice. Deeper database management\u2014patching, Data Guard configuration, performance diagnostics\u2014is handled through the OCI console, accessible directly from the Azure portal.<\/p>\n\n\n\n
For EBS, this means you can move the entire ERP island into an Azure region without violating the physics of tier co-location, and without forcing your database into generic VM sizing patterns that create licensing waste.<\/p>\n\n\n\n
And for Azure-first organizations with existing Microsoft commitments, there’s a commercial detail that matters: Database@Azure spend counts toward your Microsoft Azure Consumption Commitment (MACC). Your Oracle database infrastructure cost draws down the same Azure commitment you’re already managing\u2014no separate Oracle infrastructure contract required. We’ll cover the commercial mechanics in detail in Part 2.<\/p>\n\n\n\n
How It Actually Connects: The Network Architecture<\/h4>\n\n\n\n
Understanding why Database@Azure delivers sub-millisecond latency to the EBS application tier requires a look at how the networking works\u2014because this is fundamentally different from the older OCI\u2013Azure Interconnect model.<\/p>\n\n\n\n
In the Interconnect model (still available, but not what we’re discussing in this series), traffic between Azure and OCI traversed a cross-cloud network link between separate datacenters. Latency was typically 1.5\u20132ms\u2014workable for some applications, but too high for EBS forms, concurrent managers, and high-frequency PL\/SQL calls that can generate thousands of database round trips per user session.<\/p>\n\n\n\n
Database@Azure eliminates that gap entirely. Oracle Exadata infrastructure is physically deployed inside<\/em> Azure datacenters. Connectivity between your Azure VMs (running the EBS application tier) and the Database@Azure instance uses a delegated subnet<\/strong> within your existing Azure Virtual Network (VNet). Traffic never leaves the Azure datacenter fabric. Measured latency is typically under 0.5ms<\/strong>\u2014comparable to what you’d see between two Azure VMs in the same VNet.<\/p>\n\n\n\n
\n
- Your Azure VNet contains your standard subnets for EBS application tier VMs, bastion hosts, load balancers, and any adjacent services (tax engines, reporting, integration runtimes).<\/li>\n\n\n\n
- A\u00a0delegated subnet<\/strong>\u00a0is created within the same VNet, specifically for Database@Azure. This subnet is delegated to the\u00a0
Oracle.Database\/networkAttachments<\/code>\u00a0resource provider.<\/li>\n\n\n\n- The EBS application tier connects to the database using standard Oracle Net (TNS) over this private network path. No public endpoints, no internet traversal, no VPN tunnels.<\/li>\n\n\n\n
- Network Security Groups (NSGs) can be applied to control traffic flow, and standard Azure routing and DNS resolution apply.<\/li>\n<\/ul>\n\n\n\n
The practical result: your entire EBS estate\u2014application tier, database tier, and all adjacent satellite systems\u2014lives within a single Azure VNet in a single Azure region. From a network topology perspective, it looks and behaves like a fully Azure-native deployment. The fact that the database tier runs on Oracle-managed Exadata hardware is transparent to the application layer.<\/p>\n\n\n\n
Right-Sizing the Estate: Choosing Your Service Tier<\/h4>\n\n\n\n
It\u2019s important to say this plainly: Exadata isn\u2019t the right starting point for every EBS customer. For smaller enterprises or smaller database estates, Exadata capacity and cost can be overkill.<\/p>\n\n\n\n
Exadata Database Service for Large Estates:<\/strong> For large EBS environments\u2014those with databases exceeding multiple terabytes, heavy concurrent user loads, and demanding batch processing windows\u2014Exadata Database Service (ExaDB-D) on Database@Azure is the natural fit. You get dedicated Exadata infrastructure with the I\/O performance, Smart Scan offloading, and storage compression that EBS database workloads benefit from. Compute and storage scale independently, which directly addresses the T-shirt sizing trap: you allocate the memory and OCPUs your workload actually needs, not what a generic VM shape forces on you.<\/p>\n\n\n\n
Base Database Service for Smaller Estates and Non-Prod: <\/strong>This is where Oracle Base Database Service on Database@Azure<\/strong> becomes a highly pragmatic option. It provides broader choices across Oracle database services natively in Azure. The key advantage\u2014especially for Bring Your Own License (BYOL) customers\u2014is that you provision the database capacity you actually<\/em> intend to license, rather than being forced into an oversized Azure VM. Base Database Service utilizes BYOL consumption pricing (ECPU-based) and is positioned specifically as a lower-cost, highly flexible way to run Oracle Database. You still get the integrated Database@Azure operating model, but with a service tier that naturally aligns to the size of your environment.<\/p>\n\n\n\n
We’ll explore the full service catalog\u2014including Exadata Database Service on Exascale, which introduces elastic, granular scaling for mid-size estates\u2014in Part 5.<\/p>\n\n\n\n
Operations: Azure Teams Don\u2019t Have to Become OCI Experts<\/h4>\n\n\n\n
A common operational fear is: \u201cDo my Azure engineers now need to learn OCI?\u201d<\/em><\/p>\n\n\n\n
The short answer is no. Microsoft and Oracle have established a clear division of labor. You provision Oracle Database@Azure using the Azure portal and Azure APIs, and the infrastructure\/cluster resources are managed natively in Azure. Meanwhile, deeper database management tasks can be performed using the OCI console or using your current familiar tools.<\/p>\n\n\n\n
This split maps perfectly to how real enterprise teams actually work:<\/p>\n\n\n\n
\n
- Azure Cloud Engineers<\/strong>\u00a0stay in Azure for provisioning, network routing, monitoring, and broader operational workflows. Database@Azure resources appear as native Azure resource types, manageable through the Azure portal, CLI, ARM templates, and Terraform AzureRM provider.<\/li>\n\n\n\n
- DBAs<\/strong>\u00a0use OCI-side tooling when they need deeper database performance troubleshooting, patching, and Oracle-native diagnostics. This is accessed directly from the Azure portal via a linked OCI console\u2014no separate OCI tenancy setup or credential management required for basic operations.<\/li>\n<\/ul>\n\n\n\n
OEM for EBS Operations<\/h5>\n\n\n\n
For EBS-specific operations, Oracle Enterprise Manager (OEM) remains the primary management tool\u2014and it works with Database@Azure exactly as it does with any other Oracle database. OEM runs on an Azure VM alongside the EBS application tier and connects to the Database@Azure instance over the same low-latency private network. Your EBS DBAs’ existing OEM workflows\u2014concurrent manager monitoring, workflow mailer management, EBS patching and cloning operations, AD\/TXK administration\u2014carry forward unchanged.<\/p>\n\n\n\n
A Note on Identity and Governance<\/h5>\n\n\n\n
One operational detail worth flagging early: Database@Azure operates across two control planes. Azure Entra ID (formerly Azure AD) governs portal access and resource-level RBAC. OCI IAM governs database-level administration policies. In practice, this means your cloud platform team manages access and governance in Azure as they do for any other Azure resource, while your DBA team gets a linked OCI tenancy for database operations. We’ll cover the identity and governance model in detail in Part 5.<\/p>\n\n\n\n
It’s a practical workflow that maps to how real enterprise teams actually work\u2014and it prevents the “everyone must retrain on everything” fear from blocking your cloud migration.<\/p>\n\n\n\n
The Bottom Line<\/h4>\n\n\n\n
EBS becomes \u201clegacy\u201d when it is trapped behind aging hardware and a cloud sizing model that punishes memory-heavy databases. The blocker was never “the cloud” itself\u2014it was the mismatch between EBS reality and generic VM economics.<\/p>\n\n\n\n
Oracle Database@Azure\u2014whether Exadata Database Service for large production estates or Base Database Service for smaller environments\u2014finally creates a credible Azure-first path to move EBS forward: without splitting tiers, without paying for capacity you don’t actually use, and with your Oracle database spend counting toward the Azure commitments you’re already managing.<\/p>\n\n\n\n
In Part 2, we’ll put real numbers behind this\u2014comparing the total cost of ownership for EBS on Azure VMs versus Database@Azure, and showing where the economics decisively shift.<\/p>\n\n\n\n
\nE-Business Suite on Azure with Oracle Database@Azure \u2014 Series<\/strong><\/p>\n\n\n\n
\n
- Introduction:<\/strong> The Last Datacenter Exit: Migrating Oracle E-Business Suite to Azure with Database@Azure<\/a><\/em><\/li>\n\n\n\n
- Part 1:<\/strong> The EBS Cloud Reality Check \u2014 Why “Lift and Shift to VMs” Doesn’t Work for ERP<\/a><\/li>\n\n\n\n
- Part 2:<\/strong> Oracle EBS Economics: Oracle on Azure VMs vs Oracle Database@Azure \u2014 A Real TCO Comparison<\/a><\/li>\n\n\n\n
- Part 3:<\/strong> Resilient ERP \u2014 Backup, Recovery, and Cyber-Resiliency with Database@Azure<\/a><\/li>\n\n\n\n
- Part 4:<\/strong> EBS Platform Move \u2014 Unix to Azure Linux with Smaller Cutovers<\/a><\/li>\n\n\n\n
- Part 5:<\/strong> Picking the Right Database@Azure Service for EBS \u2014 Dedicated Exadata, Exascale, Base DB, and How to License Them<\/a><\/li>\n<\/ul>\n<\/div><\/div>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Managing Oracle E-Business Suite (EBS) is challenging, particularly with cloud migration due to licensing complexities, rigid VM sizing, and co-location requirements. EBS relies on interconnected systems that necessitate low-latency environments. Oracle Database@Azure addresses these issues by offering managed services on Exadata infrastructure, allowing for cohesive migration without excessive costs. Smaller enterprises benefit from the Base Database Service, which aligns capacity with actual licensing needs, enabling effective operations without requiring Azure teams to become OCI experts.<\/p>\n","protected":false},"author":1,"featured_media":3196,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[129,10],"tags":[130,111,153,154],"class_list":["post-3195","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-multicloud-hybrid","category-ebs","tag-database-azure","tag-multicloud","tag-oracle-ebs","tag-platform-migration"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/bijoos.com\/oraclenotes\/wp-content\/uploads\/2026\/02\/ODBA-Part1-Cover.png?fit=1536%2C1024&ssl=1","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3195","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/comments?post=3195"}],"version-history":[{"count":4,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3195\/revisions"}],"predecessor-version":[{"id":3261,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/posts\/3195\/revisions\/3261"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/media\/3196"}],"wp:attachment":[{"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/media?parent=3195"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/categories?post=3195"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bijoos.com\/oraclenotes\/wp-json\/wp\/v2\/tags?post=3195"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}