Multicloud VDI Across OCI, AWS & Azure with Thinfinity

Summary

• Oracle Cloud Infrastructure (OCI) has built one of the strongest multicloud strategies in the industry, and Thinfinity complements it at the workspace layer: multicloud VDI means running your virtual desktop and application-delivery layer across more than one cloud, so full desktops and published Windows apps can live on OCI, AWS, Azure, GCP, or on-premises while users get one consistent, secure way in.
• Oracle has pushed multicloud hard at the data and infrastructure layer with Oracle AI Database@AWS, @Azure, and @Google Cloud, plus Oracle Interconnect and Multicloud Universal Credits. That momentum stops at the database unless the desktop-and-app layer follows.
• Thinfinity Workspace is cloud-agnostic: it delivers VDI (full desktops) and VDA (published Windows apps) over the RDC protocol, plus Linux/Java apps, Remote Browser Isolation, and containerized delivery on Kubernetes/OKE, on any cloud or on-prem.
• Users reach everything through any HTML5 browser or native client under one Universal ZTNA; a host agent dials outbound to a reverse Gateway on 443/TLS 1.3, so there are zero inbound ports and endpoints receive only a pixel stream.
• You can run the Thinfinity control plane on OCI as a hub and broker workspaces to hosts on other clouds under one concurrent license, given network reachability (Oracle Interconnect, VPN, or peering). Architecture enables good latency and cost outcomes; it does not guarantee them.

What is multicloud VDI, and why does it matter now?

Oracle Cloud Infrastructure (OCI) has built one of the strongest multicloud strategies in the industry, and Thinfinity extends that same philosophy to the workspace layer. Multicloud VDI is the practice of delivering virtual desktops and applications from more than one cloud provider under a single, consistent access and management model. Instead of committing every desktop, published app, and session host to a single hyperscaler, a multicloud VDI approach lets you place workloads wherever they belong for cost, compliance, latency, or data-gravity reasons, while your users experience one workspace and your administrators work from one control plane. In plain terms: the desktop or app a person opens might be hosted on Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), or Microsoft Azure, and they should neither know nor care which one it is. The point of this article is simple: multicloud shouldn’t stop at the database, and with OCI as the hub, Thinfinity delivers multicloud VDI and published apps across clouds.

This article explains what multicloud VDI is, why the workspace layer deserves the same multicloud treatment the database layer already gets, and how Thinfinity Workspace delivers desktops and published apps across OCI, AWS, and Azure. It is written to be self-contained: every concept is defined in-page, and the external links are citations you can follow, not required reading. We will use Oracle’s own multicloud direction as context, walk through a concrete cross-cloud scenario, compare a single-cloud approach with a multicloud one, and, importantly, be honest about what this architecture does and does not give you.

What does multicloud look like today at the database layer?

Oracle Cloud Infrastructure (OCI) has built one of the strongest multicloud strategies in the industry, and most of that momentum so far has concentrated on data. Oracle’s execution here is worth crediting (and summarizing, attributed clearly to Oracle) because it sets the standard the rest of the stack should follow: the workspace and VDI layer should be multicloud too, and Thinfinity delivers exactly that.

According to Oracle’s Oracle Multicloud “What’s New” blog, Oracle has extended its database estate directly into the other hyperscalers’ data centers. Through Oracle AI Database@AWS, Oracle AI Database@Azure, and Oracle AI Database@Google Cloud, Oracle runs Exadata and Autonomous Database on OCI-managed infrastructure that physically sits inside AWS, Azure, and Google Cloud regions. The idea is to keep the Oracle database a customer already depends on, but co-locate it next to the applications and analytics services running in whichever hyperscaler the customer prefers.

Two supporting pieces make that practical. First, Oracle Interconnect provides private, low-latency cross-cloud networking; for example, Oracle Interconnect for Microsoft Azure connects OCI FastConnect directly with Azure ExpressRoute, giving application tiers on one cloud a fast, private path to data on another. Oracle documents these patterns on its Oracle Multicloud AI Database page, including split-stack and app-to-app architectures spanning OCI, AWS, and Azure. Second, Multicloud Universal Credits address the commercial friction: Oracle describes them as a way to procure Oracle AI Database across AWS, Google Cloud, Azure, and OCI under one contract with a unified rate card, so consumption can be allocated across clouds without juggling separate commitments.

The strategic message from Oracle is consistent: your database should run everywhere your business runs, with OCI acting as the anchor and private interconnects stitching the clouds together. That is a compelling direction for data. But data is not the only layer that has to be multicloud for a multicloud strategy to actually feel seamless to the people using it. To be explicit: none of Oracle’s work here is about virtual desktops, and nothing in it endorses or references Thinfinity. It is context, a well-executed example of multicloud at one layer, and Oracle remains a respected partner whose direction the workspace layer can complement.

Why should the workspace and VDI layer be multicloud too?

Here is the disconnect. An organization can spread its data and application back ends thoughtfully across clouds (Oracle database on OCI, analytics on Azure, microservices on AWS) and then hand its employees a desktop-and-application experience that is stubbornly single-cloud. The database is multicloud; the desktop is not. That mismatch shows up as inconsistent logins, cloud-specific access tooling, duplicated identity and security policy, and administrators who manage one console for AWS-hosted apps and a different one for Azure-hosted desktops.

The workspace layer, VDI (virtual desktop infrastructure, meaning full remote desktops) and VDA (virtual application delivery, meaning individual published apps), is where employees, contractors, and partners actually touch the business. If that layer is locked to one hyperscaler, several problems compound. You inherit that provider’s regional footprint whether or not it matches where your users sit. You accept per-cloud licensing and access models that do not translate. You create lock-in precisely at the point of daily productivity, which is the hardest place to unwind later. And you undercut the entire rationale for going multicloud below the surface: if the front door is single-cloud, the flexibility you bought at the data layer never reaches the end user.

Organizations with higher monthly cloud spend are more likely to run hybrid estates, suggesting greater sophistication and a stronger need for workload placement flexibility.

flexera.com

A multicloud VDI approach resolves this by treating desktop and application delivery the way Oracle treats the database: as something that should run wherever it makes sense, with a consistent way in. The desktop that consumes an Oracle database on Azure can be brokered from the same control plane as the published app that consumes a service on AWS. Users get one workspace; administrators get one management surface; and the placement of any given host becomes an engineering decision rather than a lock-in decision.

How does Thinfinity deliver VDI and VDA across clouds?

Thinfinity Workspace is built to be cloud-agnostic, which is the property multicloud VDI actually requires. It delivers full desktops (VDI) and published Windows applications (VDA) over the RDC protocol, and it also delivers Linux and Java applications, Remote Browser Isolation, and containerized app or session delivery on Kubernetes and Oracle Kubernetes Engine (OKE). The same platform runs on OCI, AWS, Azure, GCP, or on-premises. That single trait (one platform, any cloud) is what lets you standardize the workspace layer instead of re-platforming it per provider.

OCI as the control-plane hub

A natural pattern, and the one this article recommends, is to run the Thinfinity control plane (the Gateway and broker) on OCI as the hub, then deliver and broker secure workspaces to desktop and application hosts wherever they run: OCI, AWS, Azure, GCP, or on-premises. This pairs cleanly with Oracle’s OCI-as-multicloud-anchor direction. The Gateway becomes the consistent entry point; the hosts can sit next to whatever data or services they need. If you are already standardizing on OCI for the reasons Oracle articulates at the database layer, extending that anchor role to the workspace control plane keeps your architecture coherent. For teams building specifically on Oracle Cloud, Cybele also documents native OCI VDI for enterprises.

RDC, zero inbound ports, and how the connection actually flows

The security model is what makes cross-cloud brokering safe to operate. The connection path is: client → a reverse Gateway on 443/TLS 1.3. On the host side, a host agent dials outbound over RDC and streams the session up to the Gateway. Because the host initiates the connection outward, there are zero inbound ports to open on the firewall or on the host itself. No inbound RDP, no exposed management ports, no VPN concentrator standing between the user and the resource.

This matters doubly in a multicloud setting. Every cloud you add is another network boundary you would otherwise have to poke holes in. With outbound-only host agents, adding an AWS or Azure host to an OCI-hosted broker does not mean opening that host to the internet; it means letting it dial out to the Gateway. The endpoint, meanwhile, receives only a pixel stream. There is no endpoint management burden and no network or resource access granted to the device: the browser or client renders pixels and sends back keyboard and mouse input, nothing more.

Any client under one Universal ZTNA

Users reach their desktops and apps through any HTML5 browser and native Windows, Linux, and mobile clients, all under one Universal ZTNA (zero trust network access). Zero trust here means access is brokered per user and per resource rather than by dropping the device onto a network. One identity and policy model governs every session regardless of which cloud hosts the target. You can read more about the model on the Universal ZTNA page. The practical payoff for multicloud is that you do not maintain a separate access story for each provider; the same ZTNA front door covers an OCI desktop, an Azure-hosted app, and an on-prem legacy system.

Zero trust provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.

cisa.gov

Concurrent, single-license commercials

Thinfinity uses concurrent single-licensing: you license simultaneous sessions, not named users. This is a meaningful difference in a multicloud world, where the same person may touch resources on several clouds in a day. You are not multiplying per-named-user costs across providers; you are counting concurrent sessions once, wherever the hosts happen to live. The platform is also white-label and multi-tenant, with a single management plane, which suits managed service providers and enterprises running many business units.

Containers on OKE and automated scaling with Cloud Manager

For teams standardizing on containers, Thinfinity can deliver app and session workloads on Kubernetes and Oracle Kubernetes Engine (OKE), so desktop and app delivery fits the same orchestration model as the rest of a modern estate. And Thinfinity Cloud Manager automates provisioning and scaling, so host pools can grow and shrink without hand-built runbooks per cloud. Together, OKE support and Cloud Manager mean the workspace layer can be operated with the same infrastructure-as-code and autoscaling discipline you already apply to application back ends.

What does a concrete cross-cloud scenario look like?

Consider an organization that has followed Oracle’s multicloud direction at the data layer. It runs Oracle AI Database@AWS for one business unit and Oracle AI Database@Azure for another, because each unit’s surrounding applications and analytics live in those respective clouds. The database is now multicloud. The question is: how do people securely use the applications and desktops that consume that data, without a different access model per cloud?

With multicloud VDI, the answer is one model. You run the Thinfinity control plane (Gateway and broker) on OCI as the hub. The Windows desktops and published applications that read and write the AWS-hosted Oracle database run on session hosts in AWS, close to that data. The desktops and apps for the Azure-hosted database run on hosts in Azure. Each host agent dials outbound to the OCI Gateway on 443, so no inbound ports are opened in either AWS or Azure. Users, on a browser or a native client, sign in once through the Universal ZTNA and see their assigned resources, unaware of which cloud is serving each one.

Where private, low-latency paths matter (say, a published app on OCI that must talk back to an OCI-hosted service while the user session is brokered across clouds), Oracle Interconnect can provide the private connectivity between OCI and AWS or Azure, the same interconnect fabric Oracle uses for its own database patterns. The synergy is clean and layered: Oracle keeps the data consistent and well-connected across clouds; Thinfinity keeps the desktops and apps that consume that data consistently and securely accessible, regardless of which cloud the workload sits in. Neither layer depends on the other’s vendor, and each reinforces the multicloud rationale of the other.

How does multicloud VDI compare to single-cloud VDI?

The table below contrasts a typical single-cloud or first-party VDI service with a multicloud approach built on Thinfinity. The point is not that first-party services are bad (they are often excellent within their own cloud) but that they are, by design, anchored to one provider.

What does multicloud VDI actually give you, and what doesn’t it?

Honesty about limits is what separates architecture from marketing. Multicloud VDI is genuinely powerful, but it is enabled by good design and connectivity; it is not magic. Three areas deserve precision.

Connectivity: cross-cloud brokering depends on reachability

Thinfinity is genuinely cloud-agnostic, Cloud Manager automates provisioning, and the broker can serve hosts across clouds and on-premises. But cross-cloud brokering and management depend on network reachability between the OCI-hosted control plane and the hosts on other clouds. That reachability comes from Oracle Interconnect, a VPN, or VPC/VNet peering, and the exact behavior depends on your deployment. The accurate way to frame the capability is: deploy the control plane on OCI and deliver or broker workspaces running on OCI, AWS, Azure, GCP, or on-premises, given connectivity. Do not read this as a magic single pane that manages every host on every cloud with no network in place. The precise scope of cross-cloud brokering and management from an OCI-hosted control plane (and any specific Oracle Interconnect dependency) is a product-confirm item for your architecture; validate it with the Cybele team against your topology before you commit designs.

Latency and egress: the architecture enables, it does not guarantee

Distributing hosts across clouds can improve proximity to data and users, but the architecture enables good latency and cost outcomes; it does not by itself guarantee them. Outcomes depend on where you place hosts, how you connect them, and how much data crosses cloud boundaries. Cross-cloud egress and latency should be planned, not assumed. If a session host on one cloud constantly pulls large volumes from a data service on another, you will pay egress and feel latency no matter how elegant the broker is. The design principle is simple: keep each desktop or app close to the data it uses most, and use private interconnects for the paths that matter. For a worked example of how placement drives cost predictability, see Cybele’s analysis of predictable-cost banking VDI on OCI versus Azure and AWS.

Scope: what stays your responsibility

Multicloud VDI removes the front-door inconsistency and the inbound-exposure problem, and it consolidates access and licensing. It does not remove the need to run and patch the underlying host operating systems, size your host pools, or govern identity sources. Thinfinity gives you one secure delivery and access layer across clouds; your teams still own the guest workloads and the cloud accounts they run in. That is the right division of labor, but it should be stated plainly so expectations match reality.

How do you choose and get started with multicloud VDI?

If you are weighing a multicloud VDI approach, a few questions clarify the decision quickly. Do you already run (or plan to run) workloads on more than one cloud, including any Oracle database estate spread across hyperscalers? Do different users or business units have data-gravity or compliance reasons to sit on different clouds? Are you feeling per-cloud licensing sprawl or maintaining separate access tooling per provider? If the answer to any of these is yes, the workspace layer is a strong candidate to consolidate.

A sensible sequence looks like this. First, decide on your hub: for organizations aligned with Oracle’s OCI-anchor direction, running the Thinfinity Gateway and broker on OCI is the natural choice. Second, inventory where your desktops and apps should live based on data gravity, latency, and compliance, not on which cloud you happen to have started with. Third, establish connectivity between the OCI control plane and any hosts on other clouds using Oracle Interconnect, VPN, or peering, and confirm the cross-cloud brokering scope for your specific topology. Fourth, standardize access on the Universal ZTNA and consolidate to concurrent licensing. Fifth, use Cloud Manager and OKE to automate provisioning and scaling so the workspace layer operates like the rest of your infrastructure-as-code estate. Throughout, plan egress and latency deliberately, and validate the product-confirm items above with an architect rather than assuming them.