In the past month, AWS has been pleasantly surprising with the release of a number of new VPC features, some that the community has been asking for YEARS! (for example, providing users with the ability to expand an existing VPC’s CIDR). Of interest, these releases have been done without much fanfare (besides a blog post or two) and don’t necessarily align with an AWS event such as a Summit.
In this blog post we will provide a brief overview of the feature and a use case for how we can take advantage of it today.
Network Load Balancing (NLB)
Network Load Balancing (NLB) is the non HTTP/HTTPs counterpart to Application Load Balancing (ALB). Much like ALB the NLB endpoint is represented as a fully qualified domain name (FQDN), allows you to route to target endpoints, and has integration with Auto Scaling Groups (ASGs) and Elastic Container Service (ECS). Where it differs is that it is optimized for TCP based traffic, which tends to require fixed IP addresses (you can assign Elastic IP Addresses, one per Availability Zone, to NLBs), have longer lived sessions (generally a challenge with ALBs), and unlike ALB does not act as a reverse proxy.
NLBs are especially interesting to us as it allows us to provide Load Balanced services to consumers who have extremely restrictive Network Access Control Policies as it allows the NLB instances to utilize Elastic IP Addresses instead of a broad range of Public IP Addresses.
Use Application Load Balancer (ALB) to Load Balance traffic to non-EC2 resources
You can now create Application Load Balancer (ALB) targets using IP Addresses rather than EC2 instances. Think of the possibilities! Load Balance traffic to a managed AWS service (as long as it has an Elastic Network Interface or ENI) or to on-premises services (as long as it has a route from the VPC the ALB lives in). Useful for seamless migration of on-premises services to AWS or providing basic DoS protection.
Read more about it here: https://aws.amazon.com/about-aws/whats-new/2017/08/elastic-load-balancing-application-load-balancer-now-supports-load-balancing-to-ip-addresses-as-targets-for-aws-and-on-premises-resources/
Expand Existing Virtual Private Cloud (VPC) CIDRs
Previous to the release of this feature, Virtual Private Cloud (VPC) CIDRs were fixed and could not be changed without creating a new VPC and the resources contained within it. As a result, you would typically create oversized VPC CIDRs and increase the likelihood of future conflicts or you you would create undersized VPC CIDRs and have to resize later. Now, you can create a reasonably sized VPC CIDR and increase it later.
Add Descriptions to Security Group Rules (Grants)
A close representation of one of the most often asked for and longest asked for VPC features. While you still do not have the ability to tag Security Groups, each grant (permit statement) in a security group can have a description added to it. Previously you had to maintain this information in a separate system of record (typically a spreadsheet), or manage it solely through a configuration management tool (such as Ansible). Now, in addition to either of those processes, you can add a description to identify the purpose of the rule for easy review or include an associated tracking number to link it to a system of record.
This is something we have immediately taken advantage of to identify external resources requiring grants.
25 Gb/s throughput on instances that support Elastic Network Adapters (ENAs)
F1, G3, I3, P2, R4, X1, and m4.16xlarge instances, which previously supported Elastic Network Adapters (ENAs) providing throughput of 20 Gb/s now support throughput of 25 Gb/s. Combined with the capabilities of Enhanced Networking (lower latency, lower jitter, higher packet per second rate), Jumbo Frames and Placement Groups, larger and more performant High Performance Computing (HPC) clusters can be launched on AWS.
Virtual Private Cloud (VPC) Endpoints for DynamoDB
A number of managed AWS services (such as S3, DynamoDB, etc.) have endpoints that exist outside of the abstraction of the Virtual Private Cloud (VPC) and as such do not have an Elastic Network Interface (ENI). Access to these services from within the VPC must traverse the Internet (eg. go through an Internet or NAT Gateway) which is rated at a higher bandwidth cost and cannot be as easily secured. With the introduction of VPC Endpoints and the first service to support it, S3, this was no longer a challenge. Since the introduction of VPC Endpoints for S3, VPC Endpoints for DynamoDB was recently added, helping solve these two challenges.
Recover Released Elastic IP Addresses
Elastic IP Addresses that are inadvertently released due to operator or code error can now be recovered. Functionality is not yet exposed in the AWS Console but is available in the CLI and SDK.
CloudWatch Metrics Support for Direct Connect and NAT Gateways
Both Direct Connect and NAT Gateways emit metrics available via CloudWatch which will allow you to measure both service performance and capacity. Of most interest is the ability to determine when the physical direct connect connection is made, so that you may commence the remainder of the Direct Connect configuration without waiting for confirmation from the carrier.
Read more about it here: https://aws.amazon.com/about-aws/whats-new/2017/09/amazon-vpc-nat-gateways-now-support-amazon-cloudwatch-monitoring-and-resource-tagging/ and https://aws.amazon.com/about-aws/whats-new/2017/06/aws-direct-connect-now-provides-amazon-cloudwatch-monitoring/
As you can see, a lot of exciting features have been released in the past month, the above collection is not complete and represents only a small section of the services offered on AWS but are ones that relate well with us and the challenges our customers ask us to help them solve.