re:Invent 2022 release summary — Compute, Networking and Storage
As the dust settles on another re:Invent I thought I’d do a series of posts summarising service announcements.
Some ‘cloud natives’ may turn their noses up at starting with compute, networking and storage. However my suspicion is if you ranked AWS services in use you’d find EC2 and EBS near the top of most customer’s bills and you would nearly always see networking services like Transit Gateways, VPNs and Direct Connects on the bill so I decided to start there.
Compute
There were a number of new instances types launched. If you’re starting to get confused by the naming conventions (we’re well beyond ‘Dr McGiftPx’ for memorising instance types!) AWS provide a handy guide here: -
There were new compute optimised instance types focussed on enhanced networking (hence the ’n’ in their names), an Intel flavour (c6in) and a Graviton flavour in preview (c7gn), both offering significantly higher network bandwidth (200Gbps) than previous generations. There were similar announcements for general purpose and memory optimised instances (m6in, m6idn, r6in and r6idn). Clearly AWS have been making improvements to their networking capabilities and this is further evidence of the investment in the Nitro cards to offload hypervisor operations, network and storage I/O paying off. I’d expect people using cluster placement workloads for highly complex parallel processing to be interested here.
Just be sure to consider what’s the right instance type for your workload if you use the AWS Pricing Calculator to find the lowest cost instance for your CPU / RAM requirements. Intel and AMD provide x64 based processors, whereas Graviton processors are ARM based. This means you cannot simply use your existing operating system and applications binaries, you need to use ARM compatible ones. If you’re building new workloads this probably isn’t a big issue, however if you’re looking to migrate existing workloads it’s one to be aware of as you might find your compute ends up being ~20% more expensive (Graviton provides the best price/performance) than your forecast if it turns out you can’t make the move from x64 to ARM based on the products you’re using (not all COTS products have ARM binaries).
High Performance Compute got a new instance type (hpc6id), offering the same high network bandwidth mentioned above with up 1024GB of memory and 15.2TB of local NVMe SSD storage. Machine Learning workloads got a new instance in preview (inf2), increasing performance and lower latency for demanding workloads.
There were more AWS local zone announcements (Buenos Aires, Copenhagen, Helsinki and Muscat) to get workloads closer to users for low latency requirements, whilst also supporting workloads that need to be maintained ‘in country’. Personally I wouldn’t consider AWS Local Zones to be a huge sovereign play as they’re managed from and connected to a ‘parent’ AWS region.
AWS also increased security options for customers running container based workloads with Nitro Enclaves now supporting Elastic Kubernetes Service (EKS) and Kubernetes. I assume Nitro Enclaves may continue moving up the stack in future.
Networking
VPC reachability analyzer became significantly more useful with support for cross account analysis, allowing you to troubleshoot network connectivity and find any blocking configuration across your AWS Organization.
Elastic load balancing gained a number of new features around being able to reconfigure and move traffic on existing load balancers, as well as improved health checks.
Network manager introduced performance monitoring of the AWS Global Network, so you no longer need to use a third party website to estimate latency when designing global applications.
Finally VPC Lattice, which was announced in preview, is an interesting development designed to abstract application owners away from the underlying complexity of AWS networking, and supports cross account and cross VPC use cases. Think of it as ‘low code’ for application developers who don’t want to take the AWS Networking Speciality certification! Instead of having to worry about Security Groups, NACLs, network routing etc. it abstracts this level away to service networks and services, complete with IAM support. Having witnessed some graduates who were ‘born in the cloud’ with knowledge of higher level services like AI/ML but had a lack of understanding of foundational networking this appears to be another way of addressing that knowledge gap.
Storage
There were improvements to AWS backup for compliance, reporting and additional backup capabilities. A legal hold capability was added to ensure sensitive backups that are subject to investigations / audit aren’t deleted at the end of their retention period. Centralised, multi-account reporting across an AWS Organization was added to AWS Backup Audit Manager. Improvements were rounded off with support for delegation for org wide management, so your backup administrators no longer need access to the Org Management account.
Backup support for Amazon Redshift was added, as was ‘application aware’ backups. I’ve put the latter in quotes as it’s probably not what you might think it is. Sadly for those still using databases on EC2 it isn’t the ability for AWS Backup to take database consistent backups (beyond the existing support for Windows VSS), or log backups. It’s actually the ability to backup an entire CloudFormation stack, ensuring all components have a consistent backup frequency and retention. Given the number of hands I see raised in round tables when people are asked if they use Terraform versus CloudFormation it’ll be interesting to see what further developments occur in this area.
Performance improvements were the order of the day with other AWS storage services. Elastic File System gained an elastic throughput capability, so you no longer have to guess throughput capacity requirements, which is extremely useful for spikey workloads, or for new workloads where you are unclear what the requirements might be, read and write latencies were also reduced. FSx for ONTAP throughput and IOPs were doubled, and access from on premise and peered networks to multi-az was improved, so there’s no longer the need for an ‘overlay IP’ outside of your VPC CIDR range, a technique also used for high availability in SAP environments.
Catch my next post where I look at data, AI And ML announcements here.