Static IPs for Azure Functions, Data Factory, and Power Automate

Use a static-egress path that matches the protocol and the Azure runtime. An Azure Function making an HTTP request can use QuotaGuard directly. A managed Data Factory SFTP connector cannot. Power Automate usually needs an HTTP relay when a destination will not accept Microsoft’s shared service ranges.

The important correction is that one proxy setting does not cover every Azure service or protocol. HTTP proxy settings route compatible HTTP and HTTPS clients. They do not automatically route SFTP, SSH, database drivers, or every managed connector.

Choose the Route Before You Configure Anything

Azure Function making HTTP or HTTPS requests: Configure the function’s HTTP client to use QuotaGuard for the protected destination.

Azure Data Factory using managed Azure Integration Runtime: The runtime uses Microsoft-managed regional addresses. You cannot insert an arbitrary proxy into every managed connector.

Azure Data Factory connecting by SFTP: Use a Self-hosted Integration Runtime with a stable Azure egress path, or have Data Factory orchestrate a customer-controlled transfer worker that can use QuotaGuard SOCKS5 or QGTunnel.

Power Automate calling an HTTP API: Use Microsoft service tags if the destination accepts them. If it requires one or two dedicated addresses, call a customer-controlled HTTPS relay that sends the outbound request through QuotaGuard.

Azure Functions: Selective Static Egress for HTTP Calls

Azure Functions exposes possible outbound addresses, but those addresses are platform-managed and can change after infrastructure or configuration changes. Microsoft documents a transition process that may require allowlisting both old and new addresses. That is different from assigning a dedicated outbound identity to one integration.

For HTTP and HTTPS calls, route only the requests that need an allowlisted source address through QuotaGuard:

import os
import requests

proxy_url = os.environ["QUOTAGUARDSTATIC_URL"]

response = requests.get(
   "https://api.partner.example/data",
   proxies={
       "http": proxy_url,
       "https": proxy_url,
   },
   timeout=30,
)

response.raise_for_status()


Add QUOTAGUARDSTATIC_URL to the Function App’s application settings using the complete connection URL from your QuotaGuard dashboard:

http://username:password@<your-quotaguard-proxy-host>:9293

This is selective routing. Only the HTTP client calls configured with the proxy use QuotaGuard. Other Function traffic continues to use its normal Azure route.

Proxy support belongs to the HTTP library, not automatically to the Function runtime. Confirm that the library you use supports an authenticated HTTP proxy and apply the proxy to the exact client making the protected request.

Verify the Function Route

Temporarily call https://ip.quotaguard.com through the same client configuration. The returned address should match one of the two static IPs in your QuotaGuard dashboard. Ask the destination administrator to allowlist both addresses.

The Azure-Native Alternative for Functions: VNet Integration and NAT Gateway

Azure’s native pattern is to integrate the Function App with a virtual network and route outbound traffic through an Azure NAT Gateway. This can be the right choice when your team already operates Azure networking or needs one network-wide egress path.

Current Azure networking support is broader than older guidance suggests. Microsoft’s current Functions networking documentation describes VNet integration for supported configurations including Flex Consumption, Elastic Premium, and Dedicated hosting. Exact eligibility and cost depend on the hosting plan, region, subnet design, and other Azure resources, so check Microsoft’s current documentation instead of relying on a fixed monthly estimate.

Choose native Azure NAT when centralized VNet routing is already part of your architecture. Choose QuotaGuard when you want managed static proxy infrastructure, selective application-level routing, two allowlistable addresses, and no NAT Gateway deployment to operate for a small number of outbound integrations.

Azure Data Factory: HTTP and SFTP Need Different Answers

Managed Azure Integration Runtime

Microsoft’s Integration Runtime guidance explains that Azure Integration Runtime uses shared static public IP ranges. A destination can allowlist the published range or service tag if its security policy accepts shared Azure infrastructure. Microsoft also notes that broad regional allowlisting is not desirable for highly secure production environments.

Managed connectors do not expose one universal field where you can paste a QuotaGuard URL. For example, Microsoft’s managed SFTP connector documentation describes Azure Integration Runtime and Self-hosted Integration Runtime as its network paths; it does not document an arbitrary external proxy field. Check the exact connector and activity before promising a proxy route.

Self-hosted Integration Runtime

Self-hosted Integration Runtime runs on Windows compute that you provide and maintain. That gives you control over its network path. For direct SFTP or database connections, the straightforward Azure-native design is to give that host stable egress with a fixed VM address, NAT Gateway, or Azure Firewall.

Microsoft documents the proxy configuration in the Self-hosted Integration Runtime Configuration Manager for supported HTTP and HTTPS connections to cloud sources and destinations. It does not turn an HTTP proxy into an SSH or SFTP proxy. Setting HTTP_PROXY or HTTPS_PROXY on the host is not proof that an SFTP transfer uses QuotaGuard.

Using QuotaGuard for Data Factory SFTP

To use QuotaGuard for SFTP, put the transfer in a runtime you control:

Data Factory
   -> customer-controlled Function, container, or worker
   -> QuotaGuard SOCKS5 or QGTunnel
   -> trading-partner SFTP server


Data Factory orchestrates the job. The customer-controlled worker performs the SFTP transfer with a compatible SOCKS5 client or through QGTunnel. The trading partner sees the two QuotaGuard addresses.

This is not a claim that Data Factory’s managed SFTP connector accepts a QuotaGuard proxy directly. If you prefer the managed connector, use Azure Integration Runtime ranges where the partner accepts them, or use Self-hosted Integration Runtime with a native stable Azure egress path.

Power Automate: Service Tags First, Relay When Necessary

Microsoft publishes service tags and outbound ranges for Power Automate and managed connectors. If the destination accepts Microsoft’s shared ranges and your team can maintain the allowlist, that is the first-party solution.

Some partners accept only a small dedicated list. In that case, make the Power Automate flow call an authenticated HTTPS relay that you control. The relay then calls the protected API through QuotaGuard:

Power Automate
   -> authenticated HTTPS relay
   -> QuotaGuard
   -> partner API


The relay can run in an Azure Function, container, or another application runtime that supports an authenticated HTTP proxy. QuotaGuard gives the relay a stable outbound identity. You remain responsible for the relay’s authentication, authorization, request validation, deployment, and application security; QuotaGuard operates the static proxy infrastructure.

If the relay already runs on a fixed VM with suitable static egress, you may not need QuotaGuard for that connection.

What QuotaGuard Replaces and What It Does Not

QuotaGuard can replace the work of provisioning and operating proxy or NAT infrastructure for compatible outbound traffic. That includes availability, proxy maintenance, monitoring, and responding when the egress layer has a problem.

It does not make every Azure connector proxy-aware. The customer-controlled application, relay, or transfer worker still needs an insertion point: an HTTP proxy setting, authenticated SOCKS5 support, or QGTunnel.

The decision is not only a price comparison. Consider who owns the runtime, which protocols must pass through it, whether all traffic or only one destination should use the route, and who handles infrastructure updates, failover, monitoring, and incidents.

QuotaGuard Static or Shield?

QuotaGuard Static is the usual starting point for IP-allowlisted HTTP APIs. Its customer-to-proxy connection uses the plaintext HTTP proxy protocol. For an HTTPS destination, the application’s TLS session passes through a blind CONNECT tunnel to the destination, and QuotaGuard does not decrypt the HTTPS payload.

QuotaGuard Shield wraps the customer-to-proxy connection in TLS while the destination’s TLS protection remains in place. Choose Shield when a security review or an approved regulated-data configuration requires encryption on that first hop. The presence of HTTPS or SFTP alone does not mean Static decrypts the payload.

Plans and Regions

QuotaGuard Static starts at $19 per month. QuotaGuard Shield starts at $29 per month. Both provide the pair of static outbound IP addresses used in these architectures; see the current plans page for included usage and features.

Choose the nearest of 12 AWS regions when you sign up to reduce latency. Region changes for an existing subscription go through QuotaGuard support.

Common Questions

Can I allowlist the addresses shown in the Azure portal?

Yes, if the destination accepts the complete Azure-managed set and your team has a process for changes. Use QuotaGuard when the destination requires a small stable identity or when you do not want to operate the native egress infrastructure yourself.

Does an HTTP proxy setting route Data Factory SFTP?

No. SFTP is an SSH-based protocol. Use a stable native egress path for Self-hosted Integration Runtime, or move the transfer into a customer-controlled worker that can use SOCKS5 or QGTunnel.

Can Power Automate use QuotaGuard directly?

Not as a global platform setting. For an HTTP destination that requires dedicated addresses, Power Automate calls a relay you control and the relay uses QuotaGuard.

Does the Function operating system determine whether this works?

No single operating-system claim is sufficient. What matters is whether the HTTP client making the request supports the configured authenticated proxy. Test the exact runtime and library.

Official Azure References

Control Azure Functions outbound IP with a NAT Gateway

Azure Functions networking options

Azure App Service outbound IP address changes

Create and configure a Self-hosted Integration Runtime

Choose the right Data Factory Integration Runtime

Azure Data Factory SFTP connector

Power Automate IP address configuration

Getting Started

For an Azure Function making an HTTP request, configure one client call and verify it through https://ip.quotaguard.com. For Data Factory SFTP, choose between a native stable egress path and a customer-controlled transfer worker before purchasing or changing infrastructure. For Power Automate, confirm whether the destination accepts Microsoft service tags before adding a relay.

View QuotaGuard plans or contact support if you want help mapping a specific Azure service, connector, and protocol to the correct route.