Welcome to the eighth and final article in our AWS Migration Considerations Series. You can find the start of the series here.
EC2 is a wonderfully flexible environment, and nearly any workload you can run on existing tin or existing virtualised tin, you can run on AWS. There is a small caveat list, including things like artificial license limits.
But just because you can run (almost) anything on Ec2 yourself, there sometimes comes the question IF you should run it yourself. AWS has done a great job of gathering the common components in various solution architectures and turning them into managed Platform services. Often these are open-source projects wrapped in automation, and deployable (and manageable over time) through CloudFormation templating.
Key elements to look for in these managed components are:
- How configurable is the service: can you enforce your configuration into the managed platform? Certain configurations will not be possible; you do not get Administrator or Root access to the configuration files to tweak it. However you can customise.
- Is the solution fault tolerant, or multi-AZ capable? And if so, is that active-active, or active standby. What happens if an Availability Zone becomes unavailable, and what happens when an availability zone returns to service?
- Is data encrypted at rest within the service, using a key of your choice (eg, KMS), and potentially envelope encryption beyond that to optimise the KMS costs. Do you have to manage any of these keys?
- Is the data encrypted in flight, and if so, is there a CA that can be trusted that issues the certificate? What is the TLS protocol and ciphers in use, and does that meet your requirements? Can you ENFORCE encryption at rest (ie, disable unencrypted access).
- What is the upgrade process like: can it be done online, or is there an interruption to service? Do you have to redeploy and copy your data across or is it an in-place upgrade?
- Where are the backups or snapshots, are they stored durably, how are they restored, are they encrypted at rest? Are they taken automatically on a schedule, and are they cleaned up after some moving-window – or is any of this your responsibility as the customer?
- Is the data endpoint for the service within your VPC, and do you, the customer have control to a Security Group for network INGRESS access?
- Is there CloudFormation support for all your settings, so you deploy into non-production environments as uniformly as production.
- What cost options are there, like Reservations and Savings plans.
- Do you have to manage the Instance type for compute and CPU allocations?
- Do you have to manage the allocated storage (and storage type)? Can you scale storage up without interruption to the workload? Can you scale storage back down?
- How do you turn the service off when not in use? Do you have to Terminate, or is there a Stop function? Can you save money doing this? Can it be automated?
- Is the version of the managed Platform service up to speed with your requirements, and how does that compare to the upstream vendor version? When do security updates get incorporated, and what action do you, as the customer need to take to apply these, if any?
- What is the scalability like? Do you need to take action to scale up and down? What is the unit of scale, and can this scalability be automated?
- What is the cost of the service for a given size, and how does that equate to the management overhead of all the above items?
To give you an example, let us look at one of the most popular managed Platform services, the Relational Database Service.
Relational Database Service at a glance
- RDS is available for MySQL, MariaDB, SQL Server, Oracle, and Postgres. If you are looking for another database, currently, you are out of luck (though speak to your AWS contacts and enquire as to support for your desired relational database).
- RDS automates snapshots taken during a customer nominated time window daily, that are stored durably across multiple data centres at the S3 “11 9’s” of durability. The operating disk storage is selected by the customer for type and capacity and can be set to automatically grow when it reaches a low threshold. The storage at rest can be encrypted with a KMS key of the customer’s choosing, and the snapshots taken are also encrypted at rest with the same key.
- RDS instances can have new instance types, and customer initiate the action to move to the new type.
- RDS can automatically apply minor version updates in-place for you – generally requiring an instance reboot/fail over, and this generally happens when your currently selected version becomes Unsupported, not when the new minor version becomes available. The maintenance to do this occurs during a customer-nominated maintenance window.
- RDS can run with failover to a standby, automated and taking 2 – 5 minutes to complete. It should be noted that applications that cannot connect to an RDS database instance should wait a short time and then try to reconnect.
- RDS major versions are generally also supported in-place.
- RDS can be configured within certain boundaries using the concept of Parameter Groups.
- Additional installation of optional modules can often be achieved via Option Groups, depending on the database Engine.
- Costs for an RDS instance are based on the Engine type, the instance type, and the configured storage.
- If you STOP an RDS instance, only the storage costs continue. However, the instance only remains in a STOPPED state for 7 days, before coming back to service. You can STOP it again.
- If you TERMINATE (delete) an RDS Instance, you get the option of taking (and keeping) a final snapshot.
- You do not get System Administrator (SA), administrator/admin or Root access, but you do get a Master User who has elevated access and can call stored procedures that wrap administrative functions.
The other Platform services
- Elastic Load Balancing
- Aroura Database Service
- ElasticCache: MemcacheD
- ElasticCache: Redis
- Managed Apache MQ
- ElasticSearch
- DynamoDB
- Route53
- CloudWatch Logs
- Managed Grafana
- Neptune database
- Timeseries database
- … and many more…
You will quickly see that the undifferentiated heavy lifting of installing, deploying, and maintaining these services are wrapped up in a full- or semi- managed service. For example, Route53 requires no ongoing maintenance actions by the customer, whereas RDS may need you to look at Instance Type, Version, storage, and a few other items. These services become a force-multiplier for your most expensive resource: your human team.
The AWS Migration Journey with Modis
Modis has been an AWS partner since 2013. In addition to migrating Enterprise and Government workloads into the cloud, we are also the Managed Services Provider responsibility for continuing to operate and maintain the full stack capability.
In 2020 Modis became an AWS Business Case partner, with our Business Analyst practice skilled up and experienced at researching your existing operating environment, financials, and desired migration approaches per workload.
As an AWS Migration partner, Modis can seek AWS Partner funding under the Migration Acceleration Program, to help alleviate some of the migration costs incurred when starting your cloud journey. You can find more about our recognised Competencies, Service Delivery recognitions, and more on our Modis AWS Practice web sites around the world, at https://aws.modis.com/
Combining these two together, we can write a specific Business Case for you over a short number of months and seek to have it funded by AWS in part or in whole.
The Modis AWS Cloud Practice team are the most certified and experienced engineers, testers, project managers, business analysts and more. Modis combines dozens of individual technical practices to weave together the team of consultants required for your outcome. Modis is customer focused, its customer driven, and we partner with our customer in a shared vision, shaped by the experience we both share. Modis collaborates with our customers to envisage the art-of-the-possible, and then deliver it, and maintain it.