Static Outbound IPs for Serverless Integrations

Serverless functions can upload, download, and process files as part of an automated workflow with Files.com. For production integrations where dependable connectivity matters, we recommend routing outbound connections through static public IP addresses reserved in your cloud account.

This gives your team a stable source address to manage and investigate when a transfer fails.

By default, a function's outbound Internet address can be shared with other cloud customers or change between executions, depending on its service and hosting configuration.

A changing address makes IP-based access policies difficult to maintain. Activity from unrelated workloads can also affect the reputation of a shared address, leading destination firewalls, web application firewalls, or other security services to block or rate-limit otherwise legitimate requests.

As a result, unchanged function code can work one day and receive rejected requests the next. A different source address or changed address reputation is one possible cause to investigate, alongside credentials, access policies, routing, and service limits.

A customer-controlled static address reduces dependence on a provider's shared outbound address pool; it does not guarantee that every destination will accept every request.

Outbound Network Architecture

The function connects through a Virtual Private Cloud (VPC) or Azure Virtual Network (VNet) in your cloud account. Network address translation (NAT) gives its outbound IPv4 connections a reserved public source address. The logical connection path is:

Function → Customer VPC/VNet → NAT Gateway (reserved static public source IP) → Files.com

The static address is the public source address used by NAT, not another service to deploy. Your cloud team owns the network, routing, NAT configuration, and reserved addresses. The Files.com administrator owns any access restrictions applied to the integration's account.

This source address is separate from the Files.com destination your function connects to. Files.com Dedicated IP Addresses belong to your Files.com site and do not give a Lambda, Cloud Run function, or Azure Function a fixed outbound address. Continue connecting to Files.com by hostname, and allow the application and storage destinations needed for the complete transfer.

Cloud Provider Configuration

The following patterns establish a fixed outbound IPv4 address. Apply them to the deployed function and every subnet or revision that can run the integration. Connecting a function to a private network alone does not establish its public source address; Internet-bound traffic must use the configured NAT service.

AWS Lambda

Attach the function to private subnets in your VPC. Route Internet-bound IPv4 traffic from those subnets through a public NAT Gateway with an Elastic IP address.

The NAT gateway's public subnet needs a route to an Internet Gateway. Attaching Lambda to a public subnet alone does not give it Internet access.

AWS's Internet access instructions for VPC-connected Lambda functions cover the subnets, routes, execution-role permissions, and security groups. For a deployment spanning Availability Zones, follow that guide's resilient NAT layout and include each gateway's Elastic IP in your set of outbound addresses.

Google Cloud Run Functions

Use Direct VPC egress to connect the function to your VPC, and route all outbound traffic through that network. Configure Cloud NAT for the relevant subnet with manually assigned, reserved static external IP addresses.

Routing only private address ranges through the VPC leaves public Internet requests outside this path. Google's static outbound IP guide covers the Cloud Router, Cloud NAT, and address reservations.

Choose the configuration that matches how you deploy the function. Functions deployed through Cloud Run use the Direct VPC egress function configuration, with --vpc-egress=all-traffic. For second-generation functions deployed with gcloud functions, Google's second-generation Direct VPC guide uses --direct-vpc-egress=all with the network and subnet settings.

A Serverless VPC Access connector is an alternative and is needed for first-generation functions, which do not support Direct VPC egress.

When using a connector, configure it to carry all outbound traffic and ensure Cloud NAT covers its subnet.

Azure Functions

Use VNet Integration with a supported hosting plan: Flex Consumption, Premium, or Dedicated (App Service). Associate an Azure NAT Gateway and a static Public IP address with the integration subnet. Microsoft's NAT gateway tutorial demonstrates this with a Premium plan and identifies the other supported plans.

For Premium and Dedicated plans, enable routing of public Internet traffic through the VNet using Route All. For Flex Consumption, outbound traffic already routes through the integrated VNet, so Route All is not needed. Microsoft's networking options explain these differences. Preserve the function app's access to its storage account and other dependencies when changing its network routes.

Source Address Verification and IP Restrictions

Verify the source address from the deployed function, using its production network configuration. A request from your laptop or a cloud console shell does not establish the address the function uses. Have the function make an outbound request to an endpoint your team controls that records the connecting public IP, or to a trusted service that returns that address. Compare the result with your reserved NAT addresses.

Then make a representative Files.com request and inspect its Request IP in the API Logs. Test the actual upload or download as well as authentication, because file transfers can reach storage destinations separately.

For deployments across several subnets, zones, regions, or active revisions, verify each configured outbound path; one successful invocation does not establish the full address set.

If the integration is already subject to IP Whitelisting, add all of its reserved public source addresses to the appropriate site, user, group, or partner allowlist. Use the public NAT addresses, not the function's private subnet addresses or the Files.com destination addresses. Account for failover paths so that moving work to another zone or region does not prevent access.

Static outbound networking is useful independently of allowlisting. Creating a new allowlist restricts who can connect; it is not a general remedy for connection failures. An allowed source address must still satisfy authentication, permissions, country restrictions, and other applicable controls.

For a failed connection, retain the time, destination hostname, observed source IP, response or client error, and any request ID. Compare these with the Files.com API Logs and your cloud networking logs. A rejection before a request reaches your site may have no corresponding API log entry. The Support Team can help investigate using those details.

Capacity, Availability, and Cost

Size the outbound network for the number of simultaneous function instances and connections. NAT connection capacity, subnet address space, and connector throughput can limit a workload even when the function itself can scale. A resilient or high-volume deployment may need several fixed public addresses. Keep the complete set reserved and reflected in any applicable allowlists.

Provider guidance covers the design details: AWS NAT gateway availability and capacity, Google Cloud NAT addresses and ports, and Azure NAT gateway resources and availability. A fixed source IP does not remove Files.com's connection limits; account for the combined traffic of functions sharing that address.

Cloud networking adds charges beyond function execution, including NAT service time, data processing or transfer, public IPv4 addresses, and connector resources where used. Some charges continue while functions are idle. Use the provider's pricing guidance for AWS, Google Cloud, or Azure to estimate the cost of the chosen design.