AWS VPC Endpoints: A solid security service, but watchout for the potential financial impact

/0 Intro

I usually don’t discuss the financial side of things in pure technical discussions. But the reality is, cost must always be part of the security architectural decisions we make, as security can become very expensive operationally if left “unmonitored”.

VPC Endpoints (AWS PrivateLink) provide a secure and traffic-encrypted communication channel from your own AWS Account(s) to other AWS and Partner services. They can also be used to build secure and private AWS architectures, such as described below:

https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-securely-publish-internet-applications-at-scale-using-application-load-balancer-and-aws-privatelink/

That said, in terms of usability, VPCEs offer a great option which reduces some important security risks when building architectures and workloads in AWS. In most cases, VPCEs also have their own Security Group and resource policy that can be used with each VPCE created. However, depending on the architecture implemented and/or the security requirements, they can potentially be quite expensive.

/1 Typical usage for VPCEs

VPC Endpoints can be used across many AWS services (S3, DynamoDB, SSM, ELBs, Glue, Lambda/EC2, just to name a few) which makes them an overall great security tool to be used along with other different security layers.

Typically, a lot of organizations use many AWS Accounts and VPCs as part of their overall corporate architectural design and objectives:

1. Different AWS accounts for various environments: Testing, DEV, Pre-Production and Production;
2. Different AWS accounts for various business departments, or strategic goals, for example: Finance, specific projects, PoCs, Internet-facing, internal-only, etc;
3. More AWS accounts for logical grouping of architectural components: AWS Organizations, Security and/or Login accounts, Networking accounts, Deployment accounts, etc;

and so we can easily end up with anywhere from 20 to 600+ different AWS accounts for a single organization.

Now let’s take a quick example: if 10 VPC Endpoints are needed per AWS account in order to:

• Connect Cross-VPC services to each others (ex. an ALB in VPC1 to 2 ELBs in VPC2 and VPC3 respectively)
• as well as to connect other important services such as S3, DynamoDB, SSM, EC2/ECS, and API Gateways for example;

then we scale scale that to about ~100 AWS accounts that actually need VPC Endpoints across two different AZs, we end up with ~2000 VPC endpoints.

VPC Endpoints are unfortunately charged on a flat-per-hour rate (0.011 CAD/h here in Canada), unlike other services where the pricing schema depends on actual usage, such as Lambda. That adds up to 2000 Endpoints x 8760 hours a year x $0.011CAD = about CAD$193,000… It is a staggering financial figure, just for VPC endpoints alone.

This price tag, and in some cases even higher ones, will force some organizations to reevaluate the usage and/or number of VPC Endpoints deployed, which in turns will reduce the security benefits of having them in the first place.

/2 Conclusion and reflections

This article might not apply to many smaller or differently designed architectures. But for those who need a lot of VPC endpoints deployed, there are 2 options: accepting the financial operational costs associated, or, prioritizing the VPC endpoints needed for the entire environment to respect a specific budget. The cost of anything in the cloud is important, and security is no exception here.

Some potential alternatives to VPC Endpoints include a combination of Transit Gateway, NAT Gateways, VPC peering, and AWS Network Firewall along with the implementation of application-level and/or traffic encryption.

I am not personally in favor of charging on a per-hour basis for any Cloud service, as it goes against the notion of pay as you need or as you scale philosophy. Ironically, the very pricing principle of pay-as-you-go has been one of the biggest selling points of cloud marketing strategies. But as usual, Marketing has always been about advertising how refreshing and tasty a can of Pepsi is, but never about how many grams of sugar it has, nor the dental impacts of it :)

Anyhow, the total “actual usage” of those VPC endpoints is most likely a lot less than we are paying for them on a per-year basis, so I really would like AWS to reconsider the pricing schema for VPC Endpoints (and similarly priced services), as they have a lot going for them from a security point of view.

I hope you enjoyed this article!