Tips on Using CloudEndure

Somethings, this is likely the little genius that could, but everyone pays attention to the bigger boy in the family. Documentation wise, there are some things that need to be stated in a simple QNA format better:

What are some setup tips with using CloudEndure? – the Staging systems should be placed in a network with an Internet Gateway ( IGW ). It will require that public IP to communicate directly to port 1500. The conversion system should use a very large / expensive system as it will decrease the amount of time it takes to convert the system…and it will only cost $4-20 for the whole effort.

Does CloudEndure Support Migrating from one AWS account to another? – it does not obviously state this, but if you specify the other source account as “other Infrastructure,” you should be able to migrate EC2 systems ( Computer and SQL ) server between accounts pretty easily.

How does CloudEndure compare to using Commvault or Zerto? – Working in infrastructure sometimes mean you wished you didn’t have to provision tons of infrastructure to make things work. The key difference is that both less Source infrastructure is required and that the fact that the service is a SAAS Service. Although Zerto and Commvault both use OS Level agents, you still need to provision source infrastructure for each region your in. Imagine you have 5 regions that will DR to 1 centralized region. Would you rather have 1 server or 5 servers to do the same thing?

How do i ensure the target system connects to the AD Server? Make sure to add the destination DNS Server, Disable Network Level Authentication, and restart the system. Restarting the system ensures it connects to the destination DC vs. the Source DC.

Could this whole process be done manually? Of course, but its a bit slower and not automated…ha! I have not tested it, but its perhaps worthy of trying to automate this:

  1. Stop instance (and poll to wait for it to stop)
  2. Create a Snapshot and Create an AMI from it (and poll to wait for image to complete)
  3. If encrypted with a Customer Managed Key (CMK) key, share the key. If encrypted with built-in key, copy image to a CMK key that is shared (you can’t share the aws/ebs key). Wait for copy to complete.
  4. Record the ImageID
  5. Share AMI image and snapshot
  6. Record relevant information that may be important (availability zone, instance size, IP address, tags, etc.)
  7. Switch role to other account
  8. Convert any relevant information captured in step 5 (e.g. desired subnet)
  9. Launch instance from ImageID
  10. Apply tags

If you are dealing with Windows instances, you will likely also need to fix the static routes to the 169.254.169.* endpoints as they are created during deploying based on the original VPC configuration.

source: cloudnewbie1 on Reddit of all places….

This article sounds better: https://aws.amazon.com/blogs/security/how-to-create-a-custom-ami-with-encrypted-amazon-ebs-snapshots-and-share-it-with-other-accounts-and-regions/

Leave a Reply

Bitnami