Which strategy will have the LEAST impact on the Operations staff after the migration?
Create an Elasticsearch server on Amazon EC2 right-sized with 2 TB of Amazon EBS and a public AWS Elastic Beanstalk environment for the web application. Pause the data sources, export the Elasticsearch index from on premises, and import into the EC2 Elasticsearch server. Move data source feeds to the new Elasticsearch server and move users to the web application.
Create an Amazon ES cluster for Elasticsearch and a public AWS Elastic Beanstalk environment for the web application. Use AWS DMS to replicate Elasticsearch data. When replication has finished, move data source feeds to the new Amazon ES cluster endpoint and move users to the new web application.
Use the AWS SMS to replicate the virtual machines into AWS. When the migration is complete, pause the data source feeds and start the migrated Elasticsearch and web application instances. Place the web application instances behind a public Elastic Load Balancer. Move the data source feeds to the new Elasticsearch server and move users to the new web Application Load Balancer.
Create an Amazon ES cluster for Elasticsearch and a public AWS Elastic Beanstalk environment for the web application. Pause the data source feeds, export the Elasticsearch index from on premises, and import into the Amazon ES cluster. Move the data source feeds to the new Amazon ES cluster endpoint and move users to the new web application.
Explanations:
While using Elastic Beanstalk reduces operational overhead for the web application, managing Elasticsearch on EC2 requires ongoing maintenance, patching, and scaling. This increases operational burden compared to a managed Elasticsearch service. Exporting and importing the index is a valid migration strategy but requires downtime.
Using AWS DMS for Elasticsearch migration is not the recommended approach. DMS is designed for relational databases. While it technicallycanbe used for some NoSQL migrations, it’s not optimized for Elasticsearch and can be complex. Using the native Elasticsearch snapshot/restore process is a better strategy.
Using SMS for replicating the VMs is a lift-and-shift approach that doesn’t take advantage of managed services. This increases operational overhead as you’re responsible for managing the EC2 instances, including patching and scaling. Also, starting the migrated instances after pausing the feeds will still result in some downtime.
Using Amazon ES (a managed service) for Elasticsearch and Elastic Beanstalk for the web application minimizes operational overhead. These are both managed services that handle scaling, patching, and other infrastructure management tasks. Exporting and importing the index is a valid migration strategy for Elasticsearch and allows for a controlled cutover during the maintenance window. This approach minimizes ongoing operational effort.
As I understand it, the answer is:
Create an Amazon ES cluster for Elasticsearch and a public AWS Elastic Beanstalk environment for the web application. Pause the data source feeds, export the Elasticsearch index from on premises, and import into the Amazon ES cluster. Move the data source feeds to the new Amazon ES cluster endpoint and move users to the new web application.