AWS Migration Considerations Series: The Move to Managed Platform Service

 

Amazon Elastic Compute Cloud (Amazon EC2) is a wonderfully flexible environment. Nearly any workload you can run on existing tin or existing virtualized tin can be run on AWS. There is a small caveat list, including artificial license limits.

But just because you can run (almost) anything on EC2 yourself, there sometimes comes the question of whether you should run it yourself. AWS has done a pretty good 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 Considerations for Evaluating a Managed Service Platform

• 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 them. That is not to say you cannot do some customization.

• Is the solution fault-tolerant or multi-AZ capable? If so, is it active-active or active-standby? What happens if an Availability Zone becomes unavailable, and what happens when it returns to service?

• Is data encrypted at rest within the service, using a key of your choice (e.g., KMS), and potentially envelope encryption beyond that to optimize the KMS costs? Do you have to manage any of these keys? the data encrypted in flight, and if so, is there a CA that can be trusted to issue the certificate? What are the TLS protocol and ciphers in use, and do they meet your requirements? Can you ENFORCE encryption at rest (i.e., disable unencrypted access)?

• Is the data encrypted in flight, and if so, is there a CA that can be trusted to issue the certificate? What are the TLS protocol and ciphers in use, and do they meet your requirements? Can you ENFORCE encryption at rest (i.e., 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? Are they cleaned up after some moving windows? Or is any of this your responsibility as the customer?

• Is the service's data endpoint within your VPC, and do you, the customer, have control over 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? Are there three, 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 interrupting the workload? Can you scale storage back down?

• How do I turn the service off when not in use? Do I have to Terminate, or is three a Stop function? Can I save money doing this? Can it be automated?

• Is the managed Platform service version up to speed with my requirements, and how does that compare to the upstream vendor version? When do security updates get incorporated, and what action do I, as the customer, need to take to apply these, if any?

• What is the scalability like? Do I 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.

AWS Relational Database Service at a Glance

1. RDS is available for MySQL, MariaDB, SQL Server, Oracle, and Postgres. If you are looking for another database, you are out of luck (though speak to your AWS contacts and enquire about support for your desired relational database).
2. RDS automates snapshots taken during a customer-nominated time window daily that are stored durably across multiple data centers at the S3 “11 9’s” of durability. The customer selects the operating disk storage for type and capacity, and it can be set to grow automatically 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.
3. RDS instances can have new instance types, and the customer initiates the action to move to the new type. 
4. RDS can automatically apply minor version updates for you, generally requiring an instance reboot/failover. 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.
5. RDS can run with failover to a standby, which is automated and takes around 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.
6. RDS major versions are generally also supported in place.
7. RDS can be configured within certain boundaries using the concept of Parameter Groups.
8. Additional installation of optional modules can often be achieved via Option Groups, depending on the database Engine.
9. Costs for an RDS instance are based on the Engine type, the instance type, and the configured storage.
10. If you STOP an RDS instance, only the storage costs continue. However, the instance remains STOPPED for seven days before returning to service. You can STOP it again.
11. If you TERMINATE (delete) an RDS Instance, you get the option of taking (and keeping) a final snapshot.
12. You do not get System Administrator (SA), administrator/admin, or Root access. Still, you do get a Master User who has elevated access and can often call stored procedures that wrap certain administrative functions.

The Other Platform Services

Having cast your eye at RDS, you can now think about other full-service platform offerings:

• Elastic Load Balancing

• Aurora Database Service

• ElasticCache: MemcacheD

• ElasticCache: Redis

• Managed Apache MQ

• ElasticSearch

• DynamoDB

• Route53

• CloudWatch Logs

• Managed Grafana

• Neptune database

• Time series database

• … and many more…

You will quickly see that the undifferentiated heavy lifting of installing, deploying, and maintaining these services is 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 Akkodis

Akkodis has been an AWS partner since 2013, not just migrating enterprise and government workloads into the cloud but taking on the managed services provider's responsibility to continue to operate and maintain the full stack capability. 

In 2020, Akkodis became an AWS Business CasePartner with our business analyst practice, which is skilled and experienced at researching your existing operating environment, financials, and desired migration approaches per workload.

As an AWS Migration Partner, Akkodis 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 Akkodis AWS Practice websites around the world at https://aws.akkodis.com/. 

Combining these two, 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 Akkodis AWS Cloud Practice team consists of some of the most certified and experienced engineers, testers, project managers, business analysts, and more. 

Akkodis combines over a dozen individual technical practices to weave together the team of consultants required for your outcome. Akkodis is more than just customer-focused. It is customer-driven and prefers to think of itself as being partnered with our customers in a shared vision shaped by the experience we both bring together. 

Akkodis tends to collaborate with our customers to envisage the art of the possible, deliver it, and, optionally, maintain it.

Akkodis has certified AWS cloud delivery consultants in twelve countries and has extensive experience in architecting, migrating, and operating critical lines of business and national security workloads.

The End

This brings us to the end of our AWS Migration Considerations Series.

Please take the next step and contact us so we can help you with your AWS Cloud Migration.

By James Bromberger, VP Cloud computing, Akkodis Australia