Skip to main content

​
Introduction

On Private Cloud, data transfer costs are billed based on where traffic originates, where it is destined, and which networking components handle it along the way. Understanding each category can help you design systems that minimize unnecessary transfer spend and reduce latency for your end users.
Data Transfer Out refers to traffic leaving your compute to the public internet. This is most commonly HTTP responses served to end users, outbound API calls to external services, or downloads for assets served by your compute. This cost often scales directly with your application’s traffic.
  • Consider your caching strategy, leveraging Cloud’s cache control and cache rules to reduce traffic that hits your origin compute.
  • Connecting to external services like databases, caches, or other resources that do not use internal connections may disproportionately contribute to bandwidth allocation. When possible, configure private networking to route connections internally, without the need to traverse the public internet.
  • Applications that make heavy use of assets such as images and videos should leverage object storage to reduce burden on data transfer originating from your application compute.
Data Transfer In refers to traffic entering your applications from the public internet. There is no charge for inbound internet traffic, including user traffic, webhooks, or other forms of ingress.
  • Although Data Transfer In is free, inbound requests often produce responses from your application, which are billed as Data Transfer Out. Consider configuring your web application firewall to proactively reduce unnecessary or malicious inbound request volume.
A NAT (Network Address Translation) Gateway is a network component that lets compute in a private subnet make outbound connections to the internet. It is required for IPv4-based traffic from private subnets to reach the public internet. NAT Gateway traffic is typically equal to or less than your Data Transfer Out traffic and is billed as incremental to Data Transfer Out. A NAT Gateway is not necessary for IPv6 connections.
  • NAT Gateway traffic is billed in both directions, not just for outbound requests. For example, if your application makes a GET request to download a 1 GiB file, you are billed for the small outbound request and the 1 GiB response returning through the gateway.
  • Connecting to external services like databases, caches, or other resources that do not use internal connections may disproportionately contribute to bandwidth allocation. When possible, configure private networking to route connections internally, without the need to traverse the public internet.
  • Use IPv6 endpoints where available, since IPv6 traffic can route without the need for a NAT Gateway, avoiding these costs.
Traffic between resources in different Availability Zones within the same region is billed in both directions. On Private Cloud, compute clusters are distributed across multiple AZs automatically to enable automatic failover. As workload placement is handled automatically with intelligent load-balancing of traffic across the cluster, inter-AZ transfer is an inherent characteristic of the managed high-availability design. Some cross-AZ transfer is therefore healthy and expected as part of a resilient architecture.
Traffic flowing privately across a VPC peering connection between your Private Cloud and your own AWS Account in the same region is billed at a lower rate, well below that of typical Data Transfer Out. If your Private Cloud connects to services in your own AWS account over VPC Peering, the cost for that traffic is minimal compared to other transfer types.
  • When possible, use VPC peering private connections in the same AWS region to avoid cross-region peering rates, which can be significantly higher.
  • If you use VPC peering to connect to high-traffic external resources in your AWS account, such as databases or caches, consider migrating these to Laravel Cloud managed resources. Private Cloud customers can provision RDS and ElastiCache directly inside their Private Cloud VPC, which removes the need for peering altogether. Reach out to your account team to discuss support with resource migrations.
Cloudflare Edge Traffic refers to traffic handled by Cloudflare’s global edge network sitting in front of your origin. It has two dimensions: data transfer, the volume of HTTP(S) responses served from the edge to clients; and requests, the number of HTTP(S) requests handled by the edge. A single page load can trigger multiple requests, depending on how your application requests assets.
  • Maximize your cache hit ratio, leveraging Cloud’s cache control and cache rules.
  • Pages that make separate requests for linked assets like fonts, images, JavaScript bundles, and more can contribute to excess request volume as counted by Cloudflare.