I wasn’t lucky enough to go to AWS re:Invent but due to the magic that is the Internet, I was able to satisfy my nerd needs by waking up even earlier today and watching Monday Night Live, hosted by Peter DeSantis, VP of Global Infrastructure at AWS.
Just so that you don’t miss out on the main announcements made so far, here a quick post with the summary of them.
New EC2 Instance Type: A1 based on ARM-Based Graviton Processors
Today, AWS has launched a new EC2 instance based on ARM-Based AWS Graviton processors. Targeted workloads are containerised microservices, web servers, development environments and caching fleets – basically, instances that are small but typically scaled-out.
They will come in 5 instances sizes for now and are EBS-Optimised and with high network bandwidth by default and do not cost a huge amount per hour.
As it’s a different processor architecture, you will have to recompile your application if it’s written in native code. If a scripting language was used then chances are that they will work as they are.
For more information, read: EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors
Virtualisation for Serverless Computing called Firecracker
This is a KVM-Based virtualisation platform created specifically for containers and serverless functions. They’re lightweight or “micro” virtual machines that can be launched on non-virtualised environments in a fraction of a second, with the security and isolation of a typical virtual machine.
They launch in as little as 125ms and can be killed as quickly which is ideal for short-lived workloads. In terms of memory, Firecracker consumes about 5 MiB of memory, which means thousands of them can be launched on a large instance.
It designed to be very simple so doesn’t have all the bells-and-whistles of a regular virtual machine and has a very limited set of services but just about enough to run containers or functions very well and disappear soon after.
It’s new and AWS is still developing so not a huge amount of information yet and it’s yet to be seen how widely it will be adopted but it does look promising. AWS has also made it open source so it will be interesting to see a community building around it.
For more information, read: Firecracker – Lightweight Virtualization for Serverless Computing
C5n Instance and 100 Gbps Networking
For this one, I was torn between classing this as a Compute announcement or Networking as Peter talked about it at the same time but lets put this into the Compute category for now.
Last year, C5 instances were launched which were built on the AWS Nitro System and earlier this year, AWS added the ability to add local NVMe storage to them (C5d instances).
Today, C5n instances were announced and the great thing here is this other announcement of having “up to” 100 Gbps Networking available for these instances. Smaller C5n instances e.g. C5n.large will have just 25 Gbps but C5n.18xlarge (which is a monster instance with 72 vCPUs, 192 GiB RAM and 14 Gbps EBS Bandwidth) comes with the 100 Gbps network connectivity.
Such instances are ideal for High-Performance computing, video encoding and scalable multiplayer online gaming (Fortnite anyone??) etc. and will be quite a popular addition to the EC2 instance family.
For more information, read: C5n Instances with 100 Gbps Networking
AWS Transit Gateway
This is huge! This was probably the most-requested feature for AWS and a lot of designs incorporated third-party products to provide just that.
Most moderately or large-sized AWS designs have many accounts for various functions e.g. billing, audit etc. but also for kinds of environments e.g. dev, test, shared service etc. Once that happens, some need to peer and some don’t. The result is a complex mesh of peering connectivity which is not only difficult to set up or automate but is also operationally very expensive.
It will simplify AWS designs for most environments and is, therefore, a very welcome and hugely anticipated development. The usually monitoring via CloudWatch and VPC Flow Logs will be there and if sending traffic towards your AWS environment using the same CIDR blocks on multiple VPN links, then ECMP will ensure that both links are utilised equally.
At the time of writing, it’s only available with VPN but Direct Connect will also come in the future. In terms of pricing, you will pay a per-hour fee for each hour the Transit Gateway is attached and also for the data per GB.
For more information, read: Use an AWS Transit Gateway to Simplify Your Network Architecture
AWS Global Accelerator
AWS also announced the availability of AWS Global Accelerator, a network service aimed to improve the availability and performance of your applications globally by taking your users’ traffic via the entry point closest to them and then using AWS internal low latency network to route the traffic to its destination with minimal resistance.
It also makes management of endpoints easier by assigning static Anycast IP addresses to the application, meaning that they remain allocated to you and any change of topology underneath doesn’t affect user access and is invisible to them.
If also monitors the health of the overall environment and in case of issues with geographic location, general health of the application or just based on weight determined by you, can dynamically make decisions to route your traffic accordingly.
This is similar to Google’s Cloud Load Balancing and is a very welcome addition to an infrastructure architect’s arsenal of tools.
For more information, read: AWS Global Accelerator for Availability and Performance
This post is about to go over 1000 words so I am thinking about releasing this one so that you can read this with your morning coffee while I write Part II. There are enough links in this one to keep you occupied. Topics still to come are Storage, IoT and HPC/ML.
Hopefully, you’ll join me for the next one too!
[Update 27/11/2018 10:30 BST]: Click here for AWS re:Invent 2018 – Latest Announcements – Part II