Skip to main content

Blog

Client VPN, Faster GP2 Storage, CodePipeline VPC Endpoints, and Shared VPCs

January 2, 2019       Cris Daniluk       ,         Comments  0

With the endless flood of new products, features and changes from AWS and its surrounding ecosystem, it can be easy to miss an update. Our monthly round up highlights major AWS news, announcements, product updates and behind the scenes changes we think are most relevant.

With so many big announcements at re:Invent, December was predictably light on news. However, there were still some important, long awaited services.

AWS Client VPN

AWS has seriously beefed up core networking services like VPC and Route 53 over the past 2 years, catering to customers who expect to remain in a hybrid mode indefinitely. Client VPN is the latest improvement on that front, allowing customers to have a fully managed OpenVPN installation that also plays nice with other AWS functions like IAM and CloudWatch.

Some key “limitations” you need to know for right now:

  • Your authentication options are client certificates (it’s not 2005, don’t use these) and AWS Directory Services. You can link Directory Services to your existing Active Directory implementation, but you cannot link it to OAUTH or SAML providers like Okta. This will improve quickly.
  • Split tunneling is not permitted. Most of us don’t have the resources to properly secure general web browsing in our AWS environments. While split tunneling is often thought of as less secure, it is actually considerably more secure if the alternative is routing endpoint traffic through an environment that has no content filtering or UTM services. This is a disappointing limitation that may or may not change over time. For now, your best bet is to prevent general Internet access to your clients by not adding a default route to the tunnel.
  • The limit on routes is fairly low. It can be increased via an AWS support request, but if you’re going to use Client VPN as a gateway to multiple accounts or clients, this limitation may impact you.

Still, we’re excited about this service. Like all initial releases, it will quickly improve based on user feedback. And in many cases, this will offer better, more easily managed connectivity. Read the Client VPN announcementdocumentation and FAQ for more details.

GP2 Storage Now 60% Faster (sort of)

AWS increased the maximum IOPS of a GP2 volume from 10,000 to 16,000, resulting in many headlines that GP2 performance increased 60% overnight. That’s a great headline, but this change actually won’t affect you much. Actual IOPS are determined by multiplying your volume size by 3, so unless your volume is larger than 3.33TB (10,000 IOPS / 3), this change won’t affect you.

Still, this is a positive announcement. More importantly, it is an opportunity to talk storage performance in GP2. I often see provisioned IOPS (io1) used unnecessarily because people don’t understand how GP2 volumes perform. The cheapest way to improve GP2 performance is to make your volume larger. I put together a blog post that gives a full overview of the factors that drive GP2 performance and cost.

CodePipeline VPC Endpoints

This announcement didn’t get a lot of hype, surprisingly, but it addresses a painful limitation that has lived in CodePipeline for too long–the inability to directly address resources inside your VPC. Previously, doing so required effectively routing over the Internet, exposing code and artifact repositories and other assets unnecessarily.

With VPC Endpoints, your pipeline jobs can now address both VPC resources and on-premise resources, giving significantly more flexibility. The AWS Code tools in general still need to improve in accessing in-VPC and on-premise resources. For example, you still cannot initiate a CodeBuild job from an on-premise Bitbucket server. Hopefully, AWS continues to flesh out these tools over the coming year.

Shared VPCs

AWS announced Shared VPCs a long-requested feature. Shared VPCs fall into the “just because you can doesn’t mean you should” product release category. There are important use cases for this, so it is a positive announcement. But, there are far more use cases where you shouldn’t use a Shared VPC.

The argument behind Shared VPC is to take the burden out of account owners to manage networking, allowing that to be a shared IT service (as it has been for the last 40 years). It can also streamline costs by reducing the number of network gateways, VPN connections, etc that you may be duplicating across each account for on-premise connectivity. But, there are some gotchas:

  • Security Groups are not shared between accounts, but Network ACLs are global. In a Shared VPC model in particular, network ACLs are particularly important as a way to effectively restrict access to and from external networks. This can result in increased interaction between teams trying to troubleshoot why connectivity issues are occurring.
  • Network Load Balancers (and a few other services) are simply not supported.
  • Individual subnets must be delegated to each account.
  • All routing decisions are made through the shared VPC.

Teams rolling out Shared VPCs are likely to run into headaches on IP address space management, coordination of security policies between teams and difficulty in troubleshooting reachability issues in a shared management model. In effect, Shared VPCs do not change who is responsible for network management but rather turns it into a shared responsibility model where one team can no longer fully manage this concern. If you do not have strong governance and team coordination in place, this will likely create more problems than it solves.

If your primary objective is to streamline connectivity between accounts and on premise environments, and you have no need to centralize high level networking decisions, consider Transit Gateways. They provide transitive routing solutions for VPC-to-VPC hub/spoke communication, cross-organization routing, and on-premise routing.

Miscellaneous News

  • ECR now supports tagging. Tags can be linked to IAM policy, giving an effective way to manage permissions to image repositories.
  • API Gateway now supports websockets. This will be a big deal for some people, but in general if you are already implementing websockets outside of API Gateway, switching makes little sense.
  • A new region in Sweden (eu-north-1) is now available, bringing the total in Europe to 5. Sweden is a potentially interesting choice for data locality.
  • EC2 adds support for partition placement groups. Partitions let you spread instances across both availability zones and physical hardware simultaneously, which can improve availability on distributed clusters like Hadoop and ElasticSearch. Partition placement groups need to be specified when the cluster is created, but it requires little planning or effort to maintain. If you’re running a distributed cluster of any kind in AWS, you should probably be using this.
  • PostgreSQL finally logs in CloudWatch. No explanation as to why it took four years. Note that you need to be on a recent-ish version of Postgres 9.6+ or 10.4+ to use this.

Leave a Reply