re:Invent 2021 Tech Recap

AWS re:Invent 2021 is now done and dusted, and as usual AWS released a huge number of tech announcements leading up to and during the event. This year we had a small number of Kainos people physically attend (just like the good old days!), but most of us attended remotely, following the many channels to keep up with the huge amount of content streaming out of the event.

If you missed re:Invent, you still have time to catch up – the Keynotes are online here and the excellent Breakout Sessions have also just been released. Here is a rundown of the tech announcements we found most interesting!

AWS Control Tower - Region Deny and Account Factory for Terraform

Region deny functionality has been a capability of AWS Organisations for a while now – essentially setting a Service Control Policy (SCP) to deny any resources being created in specific regions. This has not been supported in Control Tower until now, so it’s a very welcome addition.

Account Factory for Terraform (AFT) allows you to provision and customise accounts with Terraform from within Control Tower.

Deny services and operations for AWS Regions of your choice with AWS Control Tower

AWS Control Tower introduces Terraform account provisioning and customization

Amazon CloudWatch Evidently

The ability to perform A/B testing and disable select features has long been controlled as a function of the application code, or a third-party service running in the same software stack (Flagsmith, Unleash, etc.. ).

CloudWatch Evidently allows users to control and perform A/B experiments and implement feature toggles as a function of the AWS platform. Feature toggles have been around for a while, and you could use Parameter Store for the values however this controls everything in one space, as well as having the added benefit of abstracting feature toggle state out of the deployed application code. Also, for A/B testing, allowing a certain amount of traffic to see the new feature or version to test is awesome. The ability now to have feature toggles controlled as part of Infrastructure as Code, rather than application code should also potentially make it easier for non-technical product owners to regain direct control of the feature toggle state, without having to go through the entire build/deploy/release cycle, which was required if feature toggles were a component of the running application itself.

Evidently can store feature toggle evaluation events (metadata on the conditions of the flag’s visibility) in either S3 or CloudWatch Logs to allow bulk analysis of the events to be performed later.

From my very brief experimentation, Evidently seems to have a requirement on AWS Cognito (because the Evidently client SDK requires an AWS access token to access the API). I suspect it’s still preferable to having feature toggles ‘baked-in’ to the code of an application.

Amazon CloudWatch Evidently – Experiments and Feature Management

Karpenter

Karpenter is a Kubernetes (K8s) auto-scaler from AWS that takes over from the K8s Cluster Autoscaler and Auto scaling groups - essentially doing the work of both tools together.

One of the hardest things when using an Autoscaling Group to manage K8s nodes is picking the correct metrics on which to scale the cluster in/out - selecting the incorrect metric can lead to unexpected performance bottlenecks, and potentially higher costs for compute nodes.

Karpenter effectively eliminates this, by handing control of the scaling over to the cluster itself. It works by instrumenting the unscheduled pods and calculating their resource requirements. If there’s not enough compute resources in the cluster already, it will launch new resources to meet the resource requirements for the waiting pods.

Because Karpenter observes the unscheduled pods to calculate required resources, it should be able to respond quicker than a traditional CloudWatch alarm-based ASG, as it can scale accurately to meet demand, rather than just waiting for an alarm to activate to trigger a scale-out event.

Introducing Karpenter – An Open-Source High-Performance Kubernetes Cluster Autoscaler

Enhanced S3 integration with Amazon FSx for Lustre

Amazon FSx for Lustre together with Amazon S3 gives you a very robust and performant storage layer. However, that performance improvement came at a cost because 1) it was a 1-to-1 relationship between FSx disk and S3 bucket and 2) the data written back to the FSx disk didn't go to S3 directly, you had to "release" it, which was not a great process. Now there is bi-directional synchronisation between the two - making it more of a cache on S3, which it should be. AND you can put one FSx in front of many S3 buckets.

Enhanced Amazon S3 Integration for Amazon FSx for Lustre

Sticking briefly to the topic of FSx, one of the other announcements came in the form of FSx for OpenZFS. Built on top of the open-source ZFS filesystem, this new architecture boasts a maximum throughput of 12.5GB/s and 1 Million IOPS for frequently cached data. For data accessed from persistent storage, the throughput is 4GB/s and 160K IOPS. Supporting both NFSv3 and NFSv4, this should prove more management-efficient.

EMR Serverless

Keeping up the tradition of “if it exists, we should make it serverless” AWS announced EMR Serverless.

Although only currently available in preview, and in us-east-1, EMR Serverless could provide some real cost savings to infrequent users of EMR services. The fact that there’s now a service to provide EMR services without having to worry too much about right-sizing a cluster in advance means that the cost controls are down to ‘traditional’ serverless configuration options, vCPU, Memory and concurrency limits.

Introducing Amazon EMR Serverless in preview

CloudWatch RUM (Real-User Monitoring)

By putting a piece of a JS script inside the <head> element of a website client-side perf metrics, errors, browser/device info and user journey details are collected and can be analysed to identify issues, behaviours, and errors (unhandled exceptions) raised by the monitored application.

CloudWatch RUM also can enable end-to-end request path tracing if the backend application is instrumented with AWS X-Ray. This allows full application visibility within X-Ray and CloudWatch ServiceLens maps.

With pricing at $1 for every 100K collected events, it shows real potential to compete with existing RUM solutions, whilst having the major benefit that all data can be retained within CloudWatch Logs for further processing (such as Athena) or archiving in S3 / Glacier.

At time of writing, RUM wasn’t supported by the AWS Terraform Provider (however there is an open feature request for it).

Introducing Amazon CloudWatch RUM for monitoring applications’ client-side performance

AWS Backup support for VMware and VMware Cloud on AWS

AWS Backup now supports automated data protection of VMs running on both VMware On-premise, and VMware Cloud on AWS. AWS Backup for VMware works by installing an agent (gateway) VM within the vCenter, and providing a secure tunnel to the AWS Backup service in the cloud. This means that backup and restore jobs can be monitored easily with the usual tools, such as CloudWatch Logs and Alarms, with notification of failed jobs being sent with Eventbridge and SNS.

New for AWS Backup – Support for VMware and VMware Cloud on AWS

AWS Customer Carbon Footprint Reporting

Not strictly a tech update, however this news is hugely exciting to us. Releasing carbon footprint information is the first step towards empowering businesses to make conscious decisions with regard to the carbon impact of their cloud design and deploy choices. Imagine Carbon Impact being promoted to a first-class non-functional requirement alongside Cost when designing, building, and managing your cloud infrastructure – a simple but impactful development. AWS seem to be moving in this direction with the inclusion of Sustainability in the AWS Well-Architected Framework. Looking forward to seeing how far they take this concept in future!

AWS re:Invent 2020: Measuring for change: Carbon footprinting at Amazon scale

Conclusion

re:Invent ‘21 was yet another superb event which unveiled lots of exciting new announcements. There are too many to list here, but we look forward to exploring them in the coming months! The innovation from AWS is impressive as always so we look forward to seeing what’s in store for the next year. If you missed re:Invent, you can watch all the keynotes back here.