Shared Cloud Environments

If your integration runs in a shared cloud environment such as AWS Lambda, Azure Functions, Google Cloud Run, or Zapier, its outbound connections may share a public IP address with unrelated customers. When someone else uses that address for abusive activity, Files.com's firewalls may block it. Your production transfers can stop even though your own code, credentials, and activity are legitimate.

The use of shared cloud environments for AI-driven abusive activity has grown sharply. Sharing an outbound IP address with that traffic creates a material risk of interruptions to legitimate production work.

We work hard to protect our customers while keeping blocking as narrowly targeted as possible. When legitimate and clearly harmful traffic arrive from the same IP address, a firewall rule blocking that address can affect both. We cannot promise to keep a shared address accessible while it is also a source of harmful traffic.

For production integrations, we strongly recommend dedicated outbound IP addresses reserved for your organization. These are often called egress IPs. Routing your connections through your own addresses separates your production traffic from unrelated customers' activity and reduces the risk of being caught in a block caused by someone else.

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. Alongside protective firewall blocking, shared addresses can be subject to rate limits, and a changing address can fall outside an IP allowlist your Files.com administrator configured. 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.

Dedicated Outbound Addresses

A static address stays the same; a dedicated address is reserved for your use. Production integrations benefit from both. A fixed address makes your network predictable, but it can still expose your integration to blocking caused by other customers if they share it.

For code running in a cloud account your team controls, reserve static public outbound IP addresses in that account and route your production connections through them. Your team then controls which workloads use those addresses. Keep that outbound path limited to your trusted production workloads so unrelated activity does not share their source addresses.

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 and whether its addresses are shared with other customers.

A provider's fixed address range gives you predictable addresses for an allowlist, but sharing that range leaves your traffic exposed to other customers' activity. If a service cannot provide dedicated egress, account for the risk from shared addresses when deciding whether to run a production workflow there.

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.