Content management error: Header Banners should not be placed in the Navigation placeholder!
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
Welcome to the third article in our AWS Migration Considerations Series. You can find the start of the series here.
Once you start an EC2 Instance, you have got a good prospect of that same virtual machine running for years. It may not follow the Well-Architected principles to have a single, stand-alone Instance, but you can easily set and forget, and that is fine.
You will not have to maintain the hypervisor, that’s managed for you.
You will not have to replace the hardware, that’s managed for you.
You will not have to replace the disks on the Instance (EBS), that’s managed for you.
But you may want to. And there are two main reasons why.
Historically, the compute for an EC2 Instance, the memory and CPU provided, often has a new version that comes out over time. Typically, each wave of new CPU releases sees a new Instance Family defined. While the obvious improvements in performance of the newer CPU is a given, it is not the primary driver for more compute migrations. It is the tactic that AWS uses to encourage the use of the newer, more efficient hardware: a big lever called “price”.
Every, one to two years, we see a 10% price reduction in computer between the current generation of instance types, and the subsequent. This encourages more customers to migrate, to obtain the advantage. And as the older equipment becomes idle, the existing space in the AWS data centre can be reclaimed, and redeployed with newer hardware.
The second reason is legacy: older instance families are labelled “previous generation”, and while they remain available, there is no guarantee they will be available forever.
The process of moving to a newer instance family is often simple: for a stand-alone EC2 instance, stop the instance (do not terminate). Once it is off, then you can reconfigure its instance type, and start it again. If your instance(s) are in an AutoScale group, then potentially update the Launch Template (previously launch configuration) and initiate a replacement.
The one consideration we have seen has been support of the installed operating system for the new CPU type. While upgrades from older Intel to newer Intel are generally straight forward, we did see an issue with an older version of RedHat Linux, that did not have the required drivers in the kernel to operate on the new EC2 Instance family. In this case, the solution was an in-place upgrade of RedHat (of which older versions of RHEL do not support in-place upgrades).
For a long time, the only options within the AWS EC2 environment were Intel x86 (32 bit and 64 bit) compatible CPUs, clearly those from Intel, and from AMD. Largely compatible with each other, but a price point differential. But the new contender is the ARM based architecture CPUs, historically used in embedded devices, mobile phones, but now, full EC2 instances.
ARM based instances require a fresh operating system, specifically compile for the ARM CPU Architecture. But the power consumption (and thus cooling) is much lower, the pricing is lower, and the performance has grown from being underwhelming 10 years ago, to impressive.
To take a data point, the M6G.large instance is 1.65 time faster than the previous m5.large, but the on-demand pricing in Sydney drops from $US0.12 to US$0.096, a price decrease of 20%, and a price/performance improvement of 33%.
When it comes to the storage, there is a nuance in here: your operational hard disk drives, as provided by the Elastic Block Store service, runs from a single availability zone (recall a Region consist of multiple availability zones, which availability zones is a cluster of data centres). That EBS volume that you use, for example a 30GB drive for C: on a Windows Instance, is provided as a RAID-1 (mirrored) and managed disk. You only see the one disk, upon which you have your formatted file system.
However, should the actual storage used by EBS to provide you with your 30 GB need to be replaced, then that operation happens transparently without user impact or cost. You can happily keep using the same 30 GB EBS Volume for years. You will not be isolated from massive failures, but maintenance should be transparent.
EBS offers several different underlying storage implementations, such as mechanical hard disk, general purpose storage, and performance optimised storage. In 2017, AWS announced the ability to live-modify EBS: both storage type, and the capacity provisioned.
But, you may want to migrate your Block storage. At AWS re:Invent 2020, a new general-purpose Solid-State Disk (SSD) option was announced, GP3. This service represented the same baseline performance as its predecessor, but with a few new capabilities, and with a 20% price drop.
As part of the shared responsibility model of the AWS cloud, the deployed OS is the customer (or partner) responsibility to patch and update. There are two major approaches:
Older version of RedHat Enterprise Linux, and others, did not support in place updates from one major version to another. Other distributions, such as Debian, have supported in-place major version upgrade since the last millennium. Microsoft Windows Server on AWS is updated via an instance replacement approach: fresh server, reinstalled applications.
The advantage of an in-place upgrade is that most of your installed application will be hopefully unaffected. The instance will maintain the same address, it will just reboot after an update.
The advantage of a replacement strategy is that you are re-starting from a known, base image, and removing any bit-rot that may have set into a long-lived Instance. As noted above, you may have a limitation of not being able to change instance families because of lacking operating system support, so eventually you are going to have to factor this activity in. A key win on this is to move to a more DevOps approach, and full script and automate the deployment of your Instance fleets via mechanisms such as AutoScale groups.
This is where the magic really lives. The Simple Storage Service, as an object store, takes care of the full lifecycle of the storage layer, transparent to customer interaction. Once you have data in S3, you can leave it there and enjoy the durability SLA on going. Any improvements to the service, including pricing improvements, generally trickle down automatically. While new storage tiers and other features may come along over time, you can choose to adopt, or you can just keep using S3 in an ongoing manner.
S3 does automatically periodically re-checksum and validate the content it stores for you. And while you pay per GB for the service (metered regularly), multiple separate copies are stored in separate data centres. If any of these copies are detected to fail a checksum, that copy is discarded, and it is copied from another known-good data centre.
It’s worth reviewing for any ASW services that the long-term future upgrade roadmap looks like. Without a crystal ball, we can look at the history of how this has happened in the past for those services that have been around long enough.
As an example, the Managed Elasticsearch Service: when launched, and for a period after, when a new major version of the service was available, customers must rip and replace their deployment (and manage coping data from the old to the new). Then came in-place upgrades of versions, making upgrades a much simpler customer experience.
Databases via the Relational Database Service (RDS) is worth reviewing the upgrade path: the service does natively support a “auto minor version upgrade”. And while “auto major version upgrade”, is defined in some documentation for CloudFormation templates, as of 2020 it does not actually do that.
Diving in deeper on the auto-minor version upgrade capability, it’s worth asking when this gets applied. While customers can define a maintenance window (day of week and time window) that is least impactful to their business, that does not mean a new minor update release gets applied in the very next maintenance window. Our experience has shown that the trigger for the minor version upgrade to kick-in is the deprecation of the in-use version, not the availability of a newer minor version. And when this does finally trigger, the upgrade path may be to the latest minor version, or something in between.
When dealing with relational databases with read replicas, we have additional complications of version matching.
This level of understanding comes from experience that Modis has developed with a deep understanding of the way that AWS has historically operated these services. That is not to say they will not change in future.
Modis has been an AWS Consulting Partner since 2013. You can learn more about our AWS Practice and services here.
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!