Cost Optimization: Lambda
A few considerations that should not be ignored.
While the creation of a VPC is free, there are many services and features associated with Amazon VPC that do cost money. When Trek10 is working to optimize our clients’ AWS costs, we often find savings opportunities in VPC. This post will cover both fundamental cost-saving techniques surrounding things such as data transfer types as well as very situational cost-saving tips such as using NAT Instances instead of NAT Gateways.
The most critical part of “VPC billing” (technically it is billed as an EC2 expense) to understand is data transfer costs. Specifically, traffic flowing from [but not into] a VPC will cost different amounts of money depending on the destination of the traffic. Traffic within a VPC will be free provided that the traffic remains within a single AZ. The most expensive type of traffic, which can be called “Internet” traffic, corresponds to data transfers from a VPC to an IP address not owned by AWS. Data transfers from an EC2 instance in Ohio into an S3 bucket in Ohio would be free, whereas traffic between AWS regions (for example data transfers from EC2 resources in Ohio into S3 resources in Virginia) would be billed at a reduced rate relative to Internet traffic. Despite being the most critical VPC-related concept for cost optimization, this information is not listed on the VPC pricing page but rather on the EC2 pricing page underneath the “Data Transfer” section.
On the official VPC pricing page, you can see that there are three categories: NAT Gateway, IPAM, and Network Analysis. NAT Gateway is arguably the most relevant and expensive of the three, due to the frequent need to have NAT within VPCs and NAT Gateway being the most common way to provide NAT to resources in the network. With regard to the IPAM costs, AWS provides an example of managing 5000 active IP addresses costing roughly $1000 per month. Accounting for both upfront development costs and ongoing maintenance, a custom IPAM solution might result in massive savings over AWS IPAM after about a year1. Lastly, the category of “Network Analysis” refers to Traffic Mirroring and Reachability Analyzer. There is not much to say about cost optimization for either of these services other than the basic recommendation to disable Traffic Mirroring sessions that are no longer needed.
In cases in which there is a Lambda within a VPC and/or EC2 instances without public IPs, it is likely that there will also be a NAT Gateway(s) to enable Internet access. As of writing, the price per GB data processed for NAT Gateway is 4.5 cents. If the Lambda/EC2 resources are interacting with S3/Dynamo, then this cost of 4.5 cents may be reduced to zero via the usage of VPC Gateway Endpoints for S3 and Dynamo. Additionally, note that the cost of having each NAT Gateway “running” is 4.5 cents per hour. It is common for a NAT Gateway to exist in each AZ due to connection limit concerns as well as cross-AZ data charges. Because of this, an application deployed across three AZs with three NAT Gateways will cost $97 a month even when there are no compute costs or data transfer costs. If the application only needs access to S3 and/or Dynamo, then this $97 monthly cost can also be reduced to zero via the usage of VPC Gateway endpoints and removal of the NAT Gateways.
While VPC Gateway endpoints are free, they are only available for S3 and Dynamo; VPC Interface Endpoints are available for most AWS services and also can offer cost benefits when compared against NAT Gateways. VPC Interface endpoints essentially cost $7 a month each plus $0.012 per GB of data processed. Given that the data processing fees of NAT Gateways are 4.5x the cost of VPC Interface Endpoints, the recommendation would be that VPC Endpoints should be used if the expected data transfer OUT to some AWS service per month per AZ in a VPC exceeds 150 GB3.
As seen in this post, in theory NAT costs can be reduced by 93% via using NAT Instances instead of NAT Gateways. Caution should be taken before making this decision, as the common understanding is that NAT Gateways are almost always preferable over NAT Instances due to their ease of use as well as better availability/bandwidth.
Direct Connect’s data transfer out cost is significantly cheaper than transfer out to the Internet. If there is an existing connection and the data is destined for an on-premise destination, it naturally would make sense to use the Direct Connect connection.
Using Snowball to export data from S3 becomes cheaper than S3’s “Data Transfer OUT to Internet” rate for data 30 TB or larger. This is worth mentioning because Snowball is not commonly used, but it can provide tremendous cost savings. For 200 TB of data, the cost savings would be roughly $4,000. This observation is relevant to VPC cost optimization because it provides a cheaper mechanism for exporting data from AWS that does not rely upon a Direct Connect connection. Direct Connect would be even cheaper for the data transfer cost when compared to Snowball but it would entail significant cost to maintain the connection. In scenarios in which a Direct Connect connection cannot be justified and data must be exported from AWS, Snowball is a good candidate for the job.
Want to learn more? Contact us if you would like help with your VPC cost optimization!
A few considerations that should not be ignored.
A fresh perspective on the capabilities of serverless technologies and what that means in terms of cost, services, and required knowledge for your business.