The most exciting news for the mid-month update must come first – this announcement highlights the commitment that Amazon Web Services have towards well-architected workloads and customer workload efficiency. The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while designing and building systems on AWS by means of 52 guided business, process and architecture related questions, with detailed best practices associated with each.
The Well-Architected Framework is built on five pillars, namely Operational Excellence, Security, Reliability, Performance Efficiency and Cost Optimization. In addition to a general workload view, the Framework offer lenses, that in addition offers focused best practices covering: serverless compute, analytics, machine learning, IoT, financial services industry, and high-performance compute.
The July 2020 updates include new questions and best practices. Below are some of the highlights across the five pillars:
- Operational Excellence: how your organization supports Cloud enablement and operations
- Cost Optimization: practicing Cloud Financial Management has gained a front-row seat
- Reliability: workload architecture, specifically on distributed system patterns and a focus on chaos engineering
- Security: identity and access management (IAM) and how workloads should be operated securely take center stage
- Performance Efficiency: new services adoption (like AWS Outposts and CloudWatch Synthetics) are now included in best practices. Improved networking to support enterprise hybrid-cloud architectures have gained attention in the update
Looking for a detailed analysis on the Well-Architected Framework updates, refer to this blog written by the AWS Well-Architected team.
AWS Outposts now supports Amazon Relational Database Service (RDS) for MySQL and PostgreSQL
This announcement has been a key requirement to position AWS Outposts as a well-rounded on-premises service. For those new to AWS Outposts, in short – it is a big and heavy, fully configured rack built and maintained by AWS that is installed in your datacentre. The Outpost is homed to an Availability Zone in the Region and is an extension of that Availability Zone, logically separated as a subnet that you can use for resiliency.
Amazon RDS on Outposts allows you to run RDS on premises for low latency workloads that need to be run in close proximity to your on-premises data and applications. Amazon RDS on Outposts automates tasks like database provisioning, operating system and database patching. It further enables high-availability hybrid deployments, with disaster recovery back to the AWS Region, read replica bursting to Amazon RDS in the cloud, and long-term archival in Amazon Simple Storage Service (Amazon S3) in the cloud.
A few key aspects that RDS’s cloud service offers that is not available on Outposts (yet) are:
- Supported engines are MySQL 5.7.26 and PostgreSQL 10.9
- Support for only R5 and M5 instances with General Purpose SSD
- Outposts require Internet connectivity to perform most activities like backup, restore and DB-instance replacement on failure
The following services are supported by Outposts today: EC2, EBS, RDS (MySQL & PostgreSQL) Containers (ECS & EKS), Amazon EMR. Coming soon are Amazon S3 & VMC on AWS.
Amazon Outposts is available in Sydney and New Zealand.
Amazon EBS direct APIs now enable snapshot creation from any block storage
Ever thought about using the same capability of EBS-snapshots for on-premises backup solutions – well, look no further. This announcement offers customers the ability to create snapshots of their block storage data, including on-premises data using Amazon Elastic Block Store (EBS) direct APIs. The take-away for on-premises operations teams here is that you can now achieve business continuity in AWS at lower cost.
Services like Amazon Storage Gateway (File, Volume, or Virtual Tape) may offer similar style backups, however the incremental storage mechanism offered by EBS-snapshots cannot be beaten to enable efficient (low storage) long term and incremental backups. CloudEndure may also be considered to simplify the process of disaster recovery; however, this may result in unnecessary costs for a pure backup requirement.
This announcement paves the way for backup solution providers and ISVs to implement next-generation incremental backup solutions that serve both on-premises and cloud use-cases.
In addition of the storage cost for snapshots, there is a charge per API call when you call PutSnapshotBlock.
One thing this announcement does not offer is a simple utility (like an EBS-Snapshot-Agent) that you can run locally that magically creates, manages and increments snapshots based on a cron-schedule.