Introduction

A key consideration when deploying Azure API Management Standard v2 or Premium v2 is that outbound networking behavior differs from the classic tiers. This applies both when customers manually rebuild an existing solution on one of these tiers and when they create a new deployment based on assumptions formed from classic-tier behavior.

In classic tiers, dedicated outbound IP addresses are available and are commonly used by backend services for source-IP allowlisting. With Standard v2 and Premium v2, customers should instead design outbound connectivity explicitly when a predictable public source IP is required. This article applies only to Standard v2 with virtual network integration and Premium v2 with either virtual network integration or virtual network injection.

The Challenge

Many backend systems still validate the source IP address of incoming traffic. Common examples include:

• Partner APIs
• Payment providers
• Legacy applications
• On-premises systems
• Third-party SaaS platforms

When designing a new APIM v2 service, or manually rebuilding a solution previously hosted on a classic tier, backend teams often ask:

“Which IP address should we allowlist?”

Unlike a classic-tier design that relies on the service’s dedicated outbound IP addresses, an APIM v2 service may require an explicit egress pattern. Virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for outbound traffic that traverses the integrated subnet.

Architecture

Before: Classic APIM

The backend allowlist contains the outbound public IP address associated with the APIM instance.

After: APIM v2 Service with NAT Gateway

The backend allowlist contains the public IP address assigned to the NAT Gateway. APIM outbound traffic uses the virtual network integration path, and the NAT Gateway provides the predictable public source IP for internet-bound connections from the associated subnet.

Configuration Steps

Prerequisite - Create an APIM v2 Service

The portal walkthrough in this article uses a Standard v2 instance configured for outbound virtual network integration.

As shown in the service overview, the dedicated public IP address information available in the classic tiers is not displayed for this APIM v2 instance.

Step 1 - Create a Virtual Network

Create or select the virtual network that will be used for APIM outbound virtual network integration.

Step 2 - Create a Dedicated APIM Subnet

Create a subnet dedicated to the APIM v2 instance. The integration subnet must meet the documented requirements for outbound virtual network integration.

Reference: Integrate an API Management instance with a virtual network for outbound connectivity

For APIM v2 outbound virtual network integration, delegate the subnet to Microsoft.Web/serverFarms.

Step 3 - Associate a Network Security Group

Associate a Network Security Group (NSG) with the APIM integration subnet. Configure the required rules according to the documented APIM networking dependencies, while also applying the outbound controls required by your environment.

Reference: APIM outbound virtual network integration requirements

Step 4 - Configure APIM Virtual Network Integration

In the Azure portal, open the API Management instance and navigate to Networking > Virtual network integration. Select the virtual network and dedicated subnet, and then save the configuration.

Virtual network integration can also be configured when creating the APIM instance.

References: Outbound virtual network integration | API Management v2 service tiers overview

Test the Current Outbound IP

This example uses a second APIM instance as the backend, although any backend service that records the request source IP can be used.

Before NAT Gateway is configured, the backend can observe different Azure source IP addresses. The Azure IP Ranges and Service Tags - Public Cloud file is available from the Microsoft Download Center: Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center

Step 5 - Create a NAT Gateway

Create an Azure NAT Gateway and associate it with one or more Standard public IP addresses or a public IP prefix. The assigned public IP becomes the predictable source address used for applicable outbound connections through the integrated subnet.

For this example, the NAT Gateway uses a Standard public IP address resource.

Step 6 - Associate the NAT Gateway with the APIM Subnet

Open the NAT Gateway configuration and associate it with the APIM integration subnet.

After the association is applied, validate that the effective network configuration matches the intended routing, NSG, and outbound connectivity design.

Step 7 - Validate

Send a test request through APIM to an endpoint that returns the caller’s public IP address, or inspect the destination backend logs. Confirm that the observed source IP matches the public IP assigned to the NAT Gateway.

As expected, the source IP address observed by the backend now matches the NAT Gateway public IP address.

When to Use This Pattern

This pattern is useful when:

• Backend teams require source-IP allowlisting.
• Third-party vendors support only IP-based network controls.
• Legacy integrations cannot be changed quickly.
• A manual rebuild of a solution previously hosted on an APIM classic tier must preserve predictable outbound addressing.

Recommendations

A predictable source IP can simplify firewall integration, but it should not replace strong service-to-service authentication. Where supported, combine or replace IP-based controls with mechanisms such as:

• Mutual TLS (mTLS)
• OAuth 2.0
• Client certificates
• Managed identity
• Private endpoints and Private Link

Treat IP allowlisting as an additional network control rather than the primary authentication mechanism. Also validate capacity, resiliency, routing, DNS, NSG rules, and dependency access for the complete solution before production deployment.

Conclusion

APIM v2 services use a different outbound networking model from the classic tiers. For new deployments or manually rebuilt solutions, outbound virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for applicable outbound traffic and simplify integration with backend firewall rules.

A successful Copilot trial opens the door to a much bigger customer conversation and a bigger role for partners. Once users experience the value of AI in their daily work, partners can guide customers to extend that value across teams, workflows, and business processes while maintaining the security, governance, and cost controls needed to scale.

In my recent post, From AI curiosity to Copilot adoption in 30 Days, I introduced how Cloud Solution Provider (CSP) partners can use a guided, 25-user trial to bring Microsoft 365 Copilot Business to small and medium-sized business (SMB) customers. That initial experience creates momentum, but sustaining it requires a structured approach to adoption, governance, and expansion.

The opportunity is growing with the new Copilot, which brings Home, Code, and Autopilot together in one connected experience. Combined with a commercial model that supports subscriptions and usage-based billing, these advances create new ways for customers to move from AI assistance to delegated work and agent-powered business processes.

For partners, this expands opportunities across the customer lifecycle, from guiding adoption and securing environments to developing agents, managing AI consumption, and delivering ongoing services. The key is connecting these capabilities into a repeatable practice that evolves alongside customer needs.

Build on the momentum of Copilot in 30

The first 30 days give customers a practical foundation for working with AI. Through Copilot in 30, users explore how Microsoft 365 Copilot Business can improve everyday productivity across Outlook, Teams, Word, Excel, and PowerPoint before progressing to agents and more advanced scenarios.

The Copilot Success Planner gives partners a structured way to guide this experience. It creates personalized learning plans for the 25 trial users, along with a roadmap for the customer sponsor. The guided journey builds skills progressively. If the sponsor enables Copilot Cowork, Weeks 3 and 4 add Cowork prompts that introduce the possibilities of delegated work.

At the end of the trial, partners can use the sponsor's Day 30 value readout to identify where Copilot delivered results, which users and teams are ready to expand, and where additional capabilities could create business value.

That conversation now has a broader destination. With the new Copilot, customers can move through connected experiences:

• Home brings Chat, Copilot Cowork, and Office together, so users can ask questions, create content, and delegate more complex work.
• Code extends AI-powered solution development, so users can turn natural-language ideas into apps, dashboards, automations, and workflows.
• Autopilot introduces a persistent, proactive personal agent designed to keep work moving within organizational permissions.

Home and Code are rolling out through the Frontier program, and Autopilot is in private preview. They expand what customers can explore as their AI maturity grows, building on the foundation of everyday Copilot adoption.

For partners, the next step is to turn early success into a longer-term customer roadmap. The Microsoft 365 Copilot + Agents SMB Guided Experience (download kit) provides a ready-to-deliver, 90-minute engagement to reinforce value, explore new scenarios, and guide the transition toward broader adoption.

Continue reading here

We're introducing the public preview of the Logic Apps Standard extension for the Azure command-line interface (CLI). It brings local project creation, connector discovery, connection configuration, runtime management, and execution diagnostics into az logicapp.

Why a CLI for Logic Apps Standard?

The designer remains useful for understanding and editing workflows visually. The CLI gives you another interface to the development work around that workflow: checking dependencies, discovering operations, validating definitions, starting the local host, and inspecting runs without switching tools at every step.

You can use those commands yourself, put them in a script, or let a coding agent invoke them with your approval. Existing Azure CLI app-management and app-settings commands remain a separate part of the same CLI surface. This extension adds Standard developer workflows; it doesn't replace the designer or reinterpret existing resource-management commands.

Your coding agent needs more than workflow JSON

A coding agent can propose a plausible connector action. Plausible isn't authoritative. The operation identifier, required inputs, and authentication parameters need to come from the connector catalog for your target, not from the agent's recollection of a similar example.

That's where deterministic tools matter. The CLI gives the agent a defined operation to execute and evidence to inspect: discover the connector, read its operation schema, author the workflow, validate it, then examine execution results. It reduces guesswork and avoids making the agent reconstruct platform calls it doesn't have available by default.

The CLI doesn't make the agent's decisions deterministic, and a successful command doesn't prove your business process is correct. You still review the workflow and its effects. But now that review is grounded on the same type of information the extension and runtime's have.

Install the public preview

The preview package is logicapp version 1.0.0b1. It declares Azure CLI 2.67.0 or later and Python 3.10 or later for the interpreter hosting Azure CLI. Install it through the public Azure CLI extension mechanism:

az extension add --name logicapp --allow-preview true
az extension show --name logicapp --query version --output tsv
az logicapp --help

For later releases, use az extension update --name logicapp --allow-preview true. Local runtime dependencies are separate from extension installation.

What can you do with the extension?

The preview registers 59 extension-owned commands. Every group below follows az logicapp; inherited core commands aren't included.

Walkthrough: save email attachments to Blob Storage

Use Office 365 Outlook as the managed connector and Azure Blob Storage as the in-process service-provider connector. The workflow runs on your workstation; the mailbox, managed connection, and storage account remain in Azure and Microsoft 365. Local doesn't mean offline.

Use a test mailbox, a storage container, and an existing non-production Standard app with an assigned identity and valid connections.json. You need permissions for connection creation, consent, access policies, and storage data access. The PowerShell examples use placeholders: replace them before execution. Don't run them against production.

1. Create the project and check the environment

From a new solution directory, keep the host under app and create a sibling artifacts folder for exports and packages.

az logicapp project create --path .\app --workflow save-attachments --workflow-kind Stateful
az logicapp context create --name attachments-local --path .\app --port 7071 --use
az logicapp dependency check --path .\app
az logicapp runtime doctor --path .\app --port 7071

Install only missing supported tools with dependency install --kind <kind>. The command doesn't install the .NET SDK. Read the doctor's findings: exit code 2 can mean compatibility is unknown, not that everything needs reinstalling. Contexts save coordinates, not your Azure subscription or credentials.

2. Discover both connector catalogs

Use az login and check az account show before querying the Azure catalog. These are standard Azure CLI commands.

az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90
az logicapp runtime show --port 7071
az logicapp connector list --local --port 7071
az logicapp connector show --local --port 7071 --connector "<blob-connector-id>"
az logicapp connector operation list --local --port 7071 --connector "<blob-connector-id>" --search "upload"
az logicapp connector managed show --location "<region>" --connector office365
az logicapp connector managed operation list --location "<region>" --connector office365 --kind trigger
az logicapp connector managed operation show --location "<region>" --connector office365 --operation OnNewEmailV3
az logicapp connector operation show --local --port 7071 --connector "<blob-connector-id>" --operation uploadBlob

Take the Blob connector identifier from connector list. Runtime catalogs describe the service provider; the regional managed catalog describes Outlook. They aren't interchangeable. Use each family's operation show command to inspect the selected operation before authoring it.

This is a useful agent task: "Read both connector schemas. Identify an email trigger, attachment retrieval, and Blob upload. Show me the required inputs and authentication before changing the workflow." The Outlook reference documents attachment retrieval through GetAttachment_V2; the Blob service-provider reference documents uploadBlob.

3. Create Outlook access, then wire the local project

Stop the discovery host with az logicapp runtime stop --port 7071 before changing settings. Then create the managed connection:

az logicapp connection managed create --resource-group "<group>" --logic-app-name "<nonproduction-app>" --name outlook-local --connector office365 --location "<region>" --auth-mode oauth
az ad signed-in-user show --query id --output tsv
az logicapp connection acl add --resource-group "<group>" --connection outlook-local --object-id "<developer-object-id>" --tenant-id "<tenant-id>"

Approve mailbox consent in the browser. Creation also adds the app's access policy and changes the deployed app's connection wiring. The additional policy authorizes your local developer principal. These are real Azure changes, even though the example workflow stays local. Failed creation can retain resources; inspect them and the wiring before retrying.

The CLI doesn't write local managed-connector wiring. Read the created entry with connection show against that app and deliberately use --show-runtime-urls for this setup step. Manually merge its API identifier, connection identifier, runtime endpoint, and ManagedServiceIdentity authentication into the local managedApiConnections.outlook-local entry. Keep the runtime endpoint in a private app setting, referenced with @appsetting('OUTLOOK_RUNTIME_URL'); don't paste returned URLs into the post or shared logs.

The documented local identity feature requires the Standard VS Code extension 5.961.19 or later and workflow bundle 1.165.52 or later. Merge this value into both the project's local.settings.json and its workflow-designtime\local.settings.json, preserving existing settings:

"WORKFLOWS_AUTHENTICATION_METHOD": "managedServiceIdentity"

After completing the connection configuration, start the local runtime as shown in step 5 so it loads the updated settings. Make sure the local runtime authenticates as the developer identity you granted access to the managed connection.

4. Configure Blob access without an account key

Read the service provider's managed-identity parameter set and endpoint parameter from discovery. Don't reuse the managed Blob connector's parameter-set name. Substitute those discovered values in this local wiring command:

az logicapp connection create --path .\app --name blob-local --connector "<blob-connector-id>" --parameter-set "<discovered-identity-set>" --% --parameter "<endpoint-parameter>=@appsetting('BLOB_ENDPOINT')" authProvider.Type=ManagedServiceIdentity --app-setting BLOB_ENDPOINT=https://<storage-account>.blob.core.windows.net

Keep this PowerShell command on one line. The --% marker preserves the app-setting expression through az.cmd; variables don't expand after it. Review the discovered identity fields before using the command.

Grant the local developer Storage Blob Data Contributor at the intended container scope, using your approved Azure role-assignment process. In Azure, grant the app's managed identity its own required access. A workstation doesn't impersonate that identity, and assigning an identity to an app doesn't grant storage permissions.

5. Author and validate the workflow

Replace the scaffold's starter definition with Outlook's polling When a new email arrives (V3) trigger, OnNewEmailV3, an attachment loop, GetAttachment_V2, and the Blob upload action. Configure the trigger's recurrence and message splitting from its schema. Bind Outlook operations to outlook-local and Blob operations to blob-local. Set includeAttachments to false and retrieve attachments separately. Map each message and attachment identifier explicitly.

For uploadBlob, supply containerName, blobName, and content. Decode Outlook's base64 contentBytes before writing binary content; use a unique blob name so repeated filenames don't overwrite unrelated attachments. These are workflow-authoring decisions, not generated business logic from the CLI.

For an attachment action named Get_attachment, the upload content expression is @base64ToBinary(body('Get_attachment')?['contentBytes']). Match action names to your authored definition.

Validate offline, restart with the new settings, then validate against that host:

az logicapp workflow validate --path .\app --workflow save-attachments
az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90
az logicapp runtime show --port 7071
az logicapp workflow validate --path .\app --all --with-runtime --local --port 7071

Check that the host is running, readiness.managementEndpointReachable is true, and the workflow is registered. Validation doesn't establish connector authorization or business correctness. Static reference warnings can remain after runtime validation and block --fail-on-warning; don't remove configuration references to manufacture a pass.

6. Send a test email and inspect the run

Send a synthetic email with one harmless attachment. Identify the matching execution by timing and message correlation, not by assuming the newest run is yours.

az logicapp run list --local --port 7071 --workflow save-attachments --max-items 10 --query "value[].{runId:runId,status:status,startTime:startTime}" --output table
az logicapp run wait --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --timeout 300
az logicapp run action list --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>"
az logicapp run action show-content --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --action "<actual-action-name>" --max-bytes 16384

For Stateful runs, run wait exits 0 only after observing success. Its timeout doesn't cancel execution. If outputs are absent, use run action show for failure metadata. Bounded content can still contain private data. Verify the saved blob's bytes independently; a green status isn't an attachment-integrity check.

7. Stop and package

az logicapp runtime stop --port 7071
az logicapp deployment package --path .\app --output-path .\artifacts\attachments.zip

Verify shutdown, including unshared CLI-owned Azurite processes. Review the package manifest and ZIP: exclude local settings, design-time files, editor content, reports, and private fixtures through .funcignore. Don't confuse it with .gitignore. Packaging is deterministic archive creation, not validation, deployment, or a guarantee that no secrets exist.

Add the Logic Apps skill to GitHub Copilot

The azure-logic-apps-standard-cli skill is now available on Awesome Copilot. It gives Copilot procedures for using the CLI: inspect the project first, discover connector schemas, preserve existing layouts, prefer managed identity for new connections, and distinguish validation from actual execution. It covers Logic Apps Standard, not Consumption-only development.

Install the complete skill package

With GitHub CLI 2.90.0 or later, preview the skill and review its bundled references before installing. The following commands install it for your personal Copilot use across projects:

gh skill preview github/awesome-copilot azure-logic-apps-standard-cli
gh skill install github/awesome-copilot azure-logic-apps-standard-cli --agent github-copilot --scope user

For a repository-specific installation, run the install command from that repository with --scope project instead. The installer places the package in the appropriate skills directory. Alternatively, download the complete skill folder and place it under .github\skills in your repository or .copilot\skills in your home directory. Keep SKILL.md, README.md, and all five references files together; copying only SKILL.md leaves required procedures unavailable.

The skill is guidance, not the Azure CLI extension or a runtime installer. Install the extension separately as described above; runtime and test dependencies still need their own checks and approval.

Use it in Copilot CLI

Start copilot from your project directory. If a session is already open, reload skills, then check that the package is available:

/skills reload
/skills info azure-logic-apps-standard-cli

Copilot can select relevant skills automatically. To request this one explicitly, name it in your prompt:

Use the /azure-logic-apps-standard-cli skill to inspect this existing Standard project and validate its workflows offline. Preserve its layout, workflow kinds, and authentication. Do not start a host, install dependencies, or access Azure. Report any checks you cannot complete.

To approach the attachment walkthrough with Copilot, begin with a plan rather than authorizing every operation at once:

Use the /azure-logic-apps-standard-cli skill to plan an Outlook-to-Blob workflow for this project. Identify the connector discovery steps, authentication requirements, and permissions needed. Separate offline work from host startup and Azure changes, and wait for approval before those operations.

Review proposed commands and their effects before approving them. The skill requires operation-specific bundled procedures and explicit authorization for cloud changes, replay, and native-test prerequisites; it doesn't replace Copilot's permission controls or prove that a workflow works. See GitHub's Copilot CLI skills guide for installation and usage details.

Beyond this walkthrough

Use workflow list/show/export against a running host to inspect or save a definition. Against Azure, connection list/show/test, connection acl list, and identity show expose wiring and access. A connection with no available test remains unverified. For compatible callable triggers, run start invokes a workflow; it doesn't manufacture an incoming Outlook email.

Cancellation and replay are explicit operations with external effects. Guarded workflow replacement and state changes also need deliberate approval; they aren't transactional shortcuts.

Before you build: preview realities and what comes next

Commands and outputs can change during preview. Testing commands already provide scaffolding, planning, approved SDK execution, and result inspection, but the current SDK/engine combination has a reported typed-output limitation. They aren't part of this walkthrough. Proposed improvements include testing, local connection inspection, trigger/history discovery, and managed-connection deployment export. These are areas of work, not delivery commitments or commands you can use today.

Try it with a workflow you know

Take a non-production workflow and ask your coding agent to discover its connectors before editing it. Compare the proposal with the catalog, then inspect the actual execution. If a command is missing or the results don't help you diagnose a failure, tell us which step broke and what you needed instead. Giving us feedback early will help us getting the features ready to you faster!

Regulated industries like banking, healthcare, and government face non-negotiable requirements for data localization, privacy, operational control, and compliance. Building on the controls already in Oracle AI Database@Azure, the Oracle Azure Resource Provider now supports the EU Data Boundary, so customers can deploy in the European Union (EU) and the European Free Trade Association (EFTA) with less friction, and Azure Policy support makes sure every deployment follows the rules from day one.

Oracle AI Database@Azure runs Oracle database services in Azure datacenters, with an Oracle-operated control plane in Oracle Cloud Infrastructure (OCI). So sovereignty spans both clouds: the Azure region you deploy in, the connected OCI tenancy, and how you set up the services around your database.

Use the Azure controls you already trust

Keep data where it belongs. Oracle databases deploy in the Azure region you choose. The EU Data Boundary covers all EU member states plus the four EFTA countries: Iceland, Liechtenstein, Norway, and Switzerland. Backups stay in Azure when you pick it as the Oracle Database Autonomous Recovery Service location, and Oracle Data Guard between two Azure regions in the same geography keeps standby and replication traffic inside it too.

Own your encryption. Encryption at rest is enforced automatically on Exadata, and connections use Transport Layer Security (TLS). Customer-managed keys work with Azure Key Vault Standard, Premium, and Managed HSM (hardware security module), so you control the key lifecycle. Revoke the key and the database can't use it to start, recover, or restore a backup.

Stay private by default. Oracle AI Database@Azure runs inside your Azure Virtual Network on private IP addresses. With advanced networking on new deployments, your Network Security Groups, user-defined routes, Azure Firewall, and VNet flow logs apply to the database subnet.

Enforce the rules automatically. Azure Policy and Sovereign Landing Zone guidance let you codify requirements such as approved regions or mandatory customer-managed keys, so every Oracle AI Database@Azure deployment stays compliant from day one.

Be ready for an audit at any time. Azure Monitor captures database and infrastructure telemetry, and OCI Audit keeps up to 365 days of administrative activity. Send both to Microsoft Sentinel or the security information and event management (SIEM) tool you already use, and give security teams read-only roles.

Stay in control of the Oracle-managed side

Decide who gets operator access, and see everything they do. Oracle Operator Access Control lets you approve, time-limit, and revoke Oracle operator access to your infrastructure, with keystroke and activity logs and audit reports for every request.

Decide when maintenance happens. For Exadata Database Service on Dedicated Infrastructure, you set and can reschedule the quarterly maintenance window, and Oracle posts monthly security maintenance at least a week ahead.

Control where your tenancy can expand. OCI permissions and an Allowed regions rule in OCI Organizations limit which new regions a tenancy can subscribe to. They don't remove regions you're already subscribed to, so check the home region and existing subscriptions. OCI's Default identity domain also replicates to every subscribed region, so the tenancy's footprint matters even when the database sits inside the EU Data Boundary.

Keep databases running if the control plane is unreachable. If the OCI control plane is unreachable, existing databases keep serving reads and writes. Provisioning, scaling, configuration changes, and maintenance wait until it's back.

Govern your data with Oracle Data Safe. Sovereignty also means knowing what sensitive data you hold and who touches it. Oracle Data Safe, included with Exadata Database Service, finds and classifies sensitive data, masks it for development and test copies, flags risky configurations and users, and audits database activity. It reaches your databases through a secured private endpoint.

Know what the boundary cover. The EU Data Boundary applies within its documented service scope and exceptions. On its own, it doesn't mean every data flow tied to the connected OCI tenancy stays in the EU and EFTA. Where backups, diagnostic and support data, operational data, and your own exports end up, depends on your configuration and the applicable terms.

Oracle subscription, multicloud link, and resource anchor resources are global, so keep personal or confidential information out of their names and labels. Oracle's contract and privacy terms govern Oracle processing and support.

Controls you can't check directly, like back-end operations and physical security, are covered by Oracle and Microsoft assurance reports and certifications, including SOC 1, 2, and 3, ISO 27001, PCI DSS, CSA STAR, and C5. There's no single sovereign certification, so map these to your own requirements.

Plan your deployment

Confirm the supported database service and Azure region, review your OCI tenancy's home region, subscriptions, and identity setup, check where backups and exports land, and register your databases with Data Safe.

Oracle AI Database@Azure gives customers cloud-scale innovation along with the sovereignty assurances their regulators and customers expect.

Learn more

• Read what's new for Oracle AI Database@Azure at Oracle AI World 2026: [Add link to Oracle AI World blog]
• Microsoft EU Data Boundary overview: https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn
• Microsoft EU Data Boundary continuing transfers: https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-transfers-for-all-services
• Oracle Database@Azure security and compliance guidance: https://docs.oracle.com/en-us/iaas/Content/database-at-azure/azusr-security-compliance.html
• Oracle Data Safe: https://docs.oracle.com/en/cloud/paas/data-safe/
• OCI organization governance (Allowed regions): https://docs.oracle.com/en-us/iaas/Content/General/organization/add-governance.htm
• Oracle AI Database@Azure compliance programs: https://docs.oracle.com/en-us/iaas/Content/database-at-azure/compliance.htm