Shared Cloud Environments

Some customers run code or automated workflows in shared cloud environments such as AWS Lambda, Azure Functions, Google Cloud Run, or Zapier. That's a useful way to automate work with Files.com. There's one important thing to be aware of: the public IP address your connection comes from may be shared with other customers, and it may change.

A shared address can be blocked or rate-limited because of activity from other customers using it. Your integration can then stop connecting even though your own code and credentials have not changed. A changing address can also fall outside an IP allowlist your Files.com administrator configured.

These networking issues can affect SDK and API requests as well as SFTP, FTP/FTPS, WebDAV, and other file-transfer protocols. What matters is the network your connection comes from, regardless of the client library or protocol you use.

Connection Failures

A shared or changing address is one possible explanation when an integration stops connecting, or when code works locally but fails in a hosted environment. Check the actual error alongside credentials, access restrictions, routing, and service limits before choosing a remedy.

For an attempt recorded in the API Logs, the Request IP shows the public source address Files.com received, including for activity through file-transfer protocols. Compare it with any applicable IP Whitelisting settings. Retain the time, destination hostname, client error, and any request ID so the provider and the Support Team can investigate the same attempt.

If you control the code, you can also check its public source address by having it contact an endpoint your team controls that records the connecting IP, or a trusted service that returns that address. Run this check from the deployed environment using the integration's network configuration. A test from a laptop or cloud console shell does not establish the address used by the integration.

For a managed workflow service, consult the provider's outbound IP guidance for the particular app or connection involved. Different parts of the service can use different address sets.

Test the complete upload or download as well as authentication. A successful login does not establish that the integration can reach every destination required for the transfer.

Stable Outbound Addresses

For production code running in a cloud account your team controls, we recommend reserving static public outbound IP addresses. This gives your team a known set of source addresses to manage and investigate, and reduces dependence on shared or changing provider addresses. It does not guarantee that a destination accepts every connection.

For managed services such as Zapier, the provider controls the outbound network. Zapier offers static IP addresses for supported apps and plans; confirm that the option covers the app your workflow uses. A provider's fixed address range can still be shared by other customers. It gives you predictable addresses for an allowlist, while addresses reserved in your own cloud account also reduce dependence on other customers' activity.

Cloud Functions in Your Own Account

To use reserved outbound addresses, connect the function to a Virtual Private Cloud (VPC) or Azure Virtual Network (VNet) in your account. Route Internet-bound IPv4 connections through a network address translation (NAT) service that uses those addresses:

Function → Customer VPC/VNet → NAT service with reserved public IP → Files.com

Your cloud team configures the network, routes, NAT service, and reserved addresses. Attaching the function to a private network alone is insufficient: its Internet-bound traffic must use that NAT path.

These are source addresses belonging to your cloud account. Files.com Dedicated IP Addresses identify the Files.com destination and cannot provide a fixed source address for your function. Continue connecting by hostname, with access to the destinations needed for the complete transfer.

AWS Lambda

Attach the function to private subnets in your VPC. Route their Internet-bound IPv4 traffic through a public NAT Gateway with an Elastic IP address. The gateway's public subnet needs a route to an Internet Gateway. Attaching Lambda to a public subnet alone does not give it Internet access.

Follow AWS's Internet access instructions for VPC-connected Lambda functions for the required routes, permissions, security groups, and a resilient layout across Availability Zones.

Google Cloud Run Functions

Use Direct VPC egress and route all outbound traffic through the VPC. 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 connections outside this path.

Google's static outbound IP guide explains the network setup. Use the function configuration for your deployment method: Cloud Run or second-generation Cloud Functions. A Serverless VPC Access connector is an alternative and is required for first-generation functions; it must also carry all outbound traffic through a subnet covered by Cloud NAT.

Azure Functions

Use VNet Integration on a supported Flex Consumption, Premium, or Dedicated hosting plan. Associate an Azure NAT Gateway and a static Public IP address with the integration subnet, following Microsoft's NAT gateway tutorial.

For Premium and Dedicated plans, enable Route All so public Internet traffic uses the VNet. Flex Consumption already routes outbound traffic through the integrated VNet. Microsoft's networking options explain the plan differences. Preserve access to the function's storage account and other dependencies when changing routes.

Verification and IP Restrictions

After changing the outbound network configuration, repeat the source-address check and a representative file transfer from the integration. For cloud functions using multiple subnets, zones, regions, or active revisions, verify each outbound path. A resilient deployment may use several reserved public addresses.

If the integration is already subject to site, user, group, or partner IP restrictions, include its complete set of public source addresses in the appropriate allowlist, including addresses used during failover. For your own NAT configuration, these are the public NAT addresses. Private subnet addresses and Files.com destination addresses do not identify the integration's public source.

Static outbound networking is useful independently of allowlisting. Creating a new allowlist restricts access and is not a general fix for connection failures. An allowed source address must still satisfy authentication, permissions, and other applicable controls.

Capacity and Cost

If your team operates the outbound network, plan for the number of simultaneous function instances and connections. NAT capacity, subnet address space, and connector throughput can constrain a workload even when the function can scale. Provider guidance covers AWS NAT gateway capacity and availability, Google Cloud NAT addresses and ports, and Azure NAT gateway resources. Files.com's connection limits still apply to the combined traffic using a source address.

The outbound network adds charges beyond function execution, potentially including NAT service time, data processing or transfer, reserved public addresses, and connector resources. Some charges continue while functions are idle. Estimate the cost using the pricing for AWS, Google Cloud, or Azure.