Skip to content
Understanding Networking Costs in AWS: Data Transfer Costs by Operation
In this series of blog posts, we’ll do a deep dive into the costs of AWS services. In this specific post, I’ll cover data transfer costs related to the Amazon Elastic Compute Cloud (Amazon EC2) service, and how these charges appear on your AWS bill.
There are many line items in the AWS Cost and Usage Report (AWS CUR). When you filter spend by Usage type and Operation, you can deepen your understanding of your bandwidth cost and see which resources generate this cost. In AWS Cost Explorer, you can filter by Usage type, but the AWS CUR also has an Operation line item. Generic costs like InterZone-In or VPCPeering-In can be filtered by Operation, enabling you to find resources that might generate unnecessary Operation costs. And, more specific costs like USW1-AWS-In-Bytes can be filtered by Usage type.
Suffice it to say, bandwidth cost has many dimensions. I will cover the most common ones under Operation in this blog post. All the dimensions are charged at different rates. Some of the data transfer costs can be avoided. For example, if you see a large InterZone-In or -Out cost on your AWS bill, there are steps you can take to reduce bandwidth cost. I’ll show you how to quickly find the resources related to the bandwidth cost so you can make the right architecture decisions. And, I’ll provide tips on how the nOps cloud management platform can help you detect data transfer costs that can be reduced by taking necessary actions.
In addition to the sheer volume of different dimensions, there are always new resources getting launched, so it becomes challenging to get a grip on the networking cost. Check out my other blog post about tracking growth of these services to catch anomalies in your AWS spend.
While researching this blog post, I came across a useful diagram from the open-guides repository on GitHub that illustrates the various costs associated with AWS data transfer:
Let’s start with Operations related to networking costs. For each dimension, I will share tips for reducing your cost. Let’s get started.
Operations
InterZone-In and InterZone-Out: Data transferred “into” and “out of” the following services across Availability Zones or Amazon Virtual Private Cloud (Amazon VPC) peering connections in the same AWS Region are charged at $0.01/GB in each direction.
- Amazon EC2
- Amazon Relational Database Service (Amazon RDS)
- Amazon Redshift
- Amazon DynamoDB Accelerator (DAX),
- Amazon ElastiCache instances
- Amazon elastic network interfaces
Check out Corey Quinn’s article on this. Essentially, any time there is bandwidth cost, you pay for transferring out of the Availability Zone (AZ) and into the AZ.
nOps Tip: Determine whether the instances sending the most traffic are in the same Availability Zone as the NAT gateway. If they’re not, create new NAT gateways in the same Availability Zone as the resource to reduce cross-AZ data transfer charges. In nOps, you can quickly find the NatGateway charge that includes InterZone cost.
NatGateway: If you choose to create a NAT gateway in your Amazon VPC, you are charged for each “NatGateway-hour” that your NAT gateway is provisioned and available. Data processing charges apply for each Gigabyte processed through the NAT gateway regardless of the traffic’s source or destination. Each partial NatGateway-hour consumed is billed as a full hour. You also incur standard AWS data transfer charges for all data transferred via the NAT gateway.
Example: You’ve created a NAT gateway, and you have an Amazon EC2 instance routing to the internet through the NAT gateway. Your Amazon EC2 instance behind the NAT gateway sends a 1 GB file to one of your Amazon Simple Storage Service (Amazon S3) buckets. With 1 GB data going through the NAT gateway, a NatGateway Data Processing charge is applied and will result in a charge of $0.045.
nOps tip: As I mentioned above, sometimes customers have NAT gateways without any traffic going through them. You pay for a NAT gateway by the hour and by usage (1 GB of data processed costs $0.045, as well as $0.045 per hour of NAT being present). In nOps, you can quickly find NAT gateways without any bandwidth traffic. If you don’t know who created the NAT gateway, you can quickly find that out as well.
PublicIP-In: IPv4 — Data transferred “in” from a public or Elastic IPv4 address is charged at $0.01/GB in each direction.
nOps tip: If you are transferring data within an AZ, you shouldn’t use a public IP address. Instead, you should be using a private IP address to avoid public IP charges. Just like InterZone traffic, in nOps you can quickly see the resources related to PublicIP-In and -Out in your environment.
PublicIP-Out: IPv4 — Data transferred “out” from a public or Elastic IPv4 address is charged at $0.01/GB in each direction.
VPCPeering-In: VPC peering connections in the same AWS Region are charged at $0.01/GB in each direction.
VPCPeering-Out: VPC peering connections in the same AWS Region are charged at $0.01/GB in each direction.
Elastic Load Balancing: You are charged for each hour or partial hour that a Classic Load Balancer is running and for each GB of data transferred through your load balancer:
- $0.025 per ClassicLoadBalancer-hour (or partial hour)
- $0.008 per GB of data processed by a Classic Load Balancer
nOps tip: Sometimes, there are load balancers you’re paying for without resources attached to them. Using nOps, you can quickly find load balancers without instances.
LoadBalancing-PublicIP-In: GB of data processed by a Classic Load Balancer
LoadBalancing-PublicIP-Out: GB of data processed by a Classic Load Balancer
LoadBalancing: Application — You are charged for each hour or partial hour that an Application Load Balancer is running and the number of Load Balancer Capacity Units (LCU) used per hour.
- $0.0225 per ApplicationLoadBalancer-hour (or partial hour)
- $0.008 per LCU-hour (or partial hour)
LoadBalancing: Network — You are charged for each hour or partial hour that a Network Load Balancer is running and the number of LCU used by the Network Load Balancer per hour.
In conclusion
To reduce your AWS networking costs, you need to be able to detect the resources generating unnecessary data transfer charges so that you can make the right architecture decisions to avoid those charges in the future. The nOps cloud management tool can help you eliminate surprises in your AWS invoices by identifying billing anomalies.
Hopefully, you’ve found this information to be helpful. If I missed any Operation charges related to networking, please do leave a comment. I will be covering networking costs associated with Usage type in the next blog post.
Want to start gaining sharper visibility to AWS cost anomalies and see how much you can save? Click here to get started with a free trial of nOps (or click here to sign in to nOps if you’re already a user) and take advantage of its cost control capabilities.
