I set out to find a credit mechanism or hard-coded limit in packets per second in AWS EC2. After all my findings set out in this series so far, I had one more test to perform around t2.unlimited. I wanted to see how “unlimited” it is and the difference it makes in packet throughput on capable instance types. This post is about my findings.

I don’t know what to say about this post… I found something weird while investigating PPS on EC2. It seems to correlate with CPU credits on t1/t2/t3 instances, but is consistently inconsistent in presentation. It only shows up when you track the stats yourself, because Cloudwatch doesn’t show the 1-second granularity needed to see these numbers.

While benchmarking packets per second (PPS) in AWS EC2 and searching for hard-coded or other software-based limitations, my early findings suggested that there definitely was a credit mechanism, complete with network throttling, in place. I now know that to be false, since finding the guaranteed throughput / best effort mechanic.

Amazon Elastic Beanstalk allows you to quickly provision the infrastructure needed for an entire application without the hassle of managing the configuration of EC2 instances, Elastic Load Balancers, Auto Scaling, and many other AWS services. Elastic Beanstalk also automatically monitors these resources and provides a simplified view into your application’s health.

First, let me say that I know AWS doesn’t promise anything about network performance as it relates to packets. At best, they leave it as a multivariate calculus problem for the reader — inclusive of CPU performance, code optimization, MTU, and current network congestion under the VLANs. But still, I was curious to see if there was any correlation to Amazon’s published “Network Performance” and the actual packets per second metric I tested.

Remember the customer who reported a hard-coded packet per second (PPS) limit in AWS? His use case was a reverse-proxy server to a very active database cluster, complete with heartbeats, keep-alive connections, and a heavy load of queries and traffic. When the network throughput was sustained for an hour or so, the throughput would drop despite increasing demand.

A customer of ours reported a limit on number of packets in Amazon’s EC2 instances. According to the report, it didn’t happen on all instance types, and didn’t happen all the time. Also, it was unrelated entirely to bandwidth or MTU. According to the report, packet transmission rates were limited the same as CPU on t2/t3 instances — each instance earns credits which, when exhausted, cause throttling.

If you remember getting an Erector Set as a kid, I’m sorry. In a stocking full of toy building systems, an Erector Set is the proverbial lump of coal. The instructions are complicated, and the pieces are made of metal, connected together with tiny screws. Few children have ever completed one of these sets successfully.