Before jumping into the Practical session, we should know the basics.

So, Lets start with the basics of Cloud Endure

What is Cloud Endure?

  • Cloud endure provides a unified, simple process to migrate/protect any application or database from any source  into AWS
  • This can be from On-premise environment to AWS Cloud or from any other Cloud service provider to AWS Cloud or also Cross region migration across AWS
  • AWS Application Migration Service is the next generation of Cloud Endure Migration. This is the recommended service for Lift and Shift Migrations to AWS
  • Cloud Endure is SaaS Solution

For more posts on AWS RDS please check the INDEX page or visit our YouTube channel

Uses of Cloud Endure :

  • Migration : It allows Rapid, Reliable and Independent migration with minimal business downtime
  • Disaster Recovery : Meets recovery objectives during any sort of disaster

 

Features of Cloud Endure :

  • Continuous replication

CloudEndure Disaster Recovery provides continuous, asynchronous, block-level replication of your source machines into a staging area. This allows you to achieve sub-second Recovery Point Objectives (RPOs), since up-to-date applications are always ready to be spun up on AWS if a disaster strikes.

  • Low-cost staging area

Data is continually kept in sync in a lightweight staging area in your target AWS Region. The staging area contains low-cost resources that are automatically provisioned and managed by CloudEndure Disaster Recovery. This eliminates the need for duplicate resources and significantly reduces your disaster recovery total cost of ownership (TCO).

  • Automated machine conversion and orchestration

In the event of a disaster or drill, CloudEndure Disaster Recovery triggers a highly automated machine conversion process and a scalable orchestration engine that quickly spins up thousands of machines in your target AWS Region in parallel. This enables Recovery Time Objectives (RTOs) of minutes. Unlike application-level solutions, CloudEndure Disaster Recovery replicates entire machines, including OS, system state configuration, system disks, databases, applications, and files. Therefore, when you launch your machines during a failover or drill, your machines will run just as they do on your source infrastructure. You do not need to install everything again or maintain duplicate copies of the OS, system state configuration, or software.

  • Point-in-time recoveryGranular point-in-time recovery allows you to recover applications and IT environments that have been corrupted as a result of accidental system changes, ransomware, or other malicious attacks. In such cases, you can launch applications from a previous consistent point in time rather than launching applications in their most up-to-date state. During the recovery, you can select either the latest state or an earlier state from a list of points in time.
  • Easy, non-disruptive drillsWith CloudEndure Disaster Recovery, you can conduct disaster recovery drills without disrupting your source environment or risking data loss. During drills, CloudEndure Disaster Recovery spins up machines in your target AWS Region in complete isolation to avoid network conflicts and performance impact. Because you are leveraging AWS, there is no need to provision or pay in advance for the resources needed during the disaster recovery drill. CloudEndure Disaster Recovery’s automation also minimizes the manual work involved in conducting drills.
  • Wide application and infrastructure supportBecause CloudEndure Disaster Recovery replicates data at the block level, you can use it for all applications and databases that run on supported versions of Windows and Linux OS. This includes Windows Server versions 2003/2008/2012/2016/2019 and Linux distributions, such as CentOS, RHEL, OEL, SUSE, Ubuntu, and Debian. CloudEndure Disaster Recovery supports common databases, including Oracle and SQL Server, as well as enterprise applications such as SAP. Below is a partial list of the applications, hardware configurations, operating systems, and source infrastructure that CloudEndure Disaster Recovery supports.
  • It can migrate from any source
  • You can also migrate back due to any issues originating and are forced to go back
  • Replication is done as continuous block level replication. This means none of the data is left behind and everything is moved
  • The cutover window is extremely short, since replication happens continuously
  • Cloud Endure provides a secure environment with regards to migration as it uses Encryption in transit while replicating the data using AES-256 encryption.
  • In addition to his, customers can use their own private connectivity such as VPN or direct tunnel data to replicate data privately on top of the encryption
  • EBS encryption on the target side is also leveraged with Encryption at rest
  • There is a unified process to migrate any kind of applications or database as long as the OS version is supported.
  • The only thing engineer needs to do is to deploy the agent in the source machine.
  • You can perform non disruptive tests anytime before cutover

Steps for Cloud Endure Migration

  1. Assessment – Identify machines, networking, instance rightsizing
  2. Install Agents – replication begins into lightweight staging area
  3. Configure blueprint – can be updated anytime without disrupting replication
  4. Test target machines – launch target machines in non disruptive tests
  5. Cutover – The test target machines are automatically terminated before deploying the target machines for final cutover where machines are automatically converted to run natively in AWS

Cloud Endure Architecture

Staging Area

It is a low cost computing storage which is needed to keep the data in sync with the source

It consists of :

  • Replication servers : Lightweight EC2 instances
  • Staging Volumes : Low cost EBS volumes
  • Snapshots : Incremental EBS snapshots

The staging area resources scale up or down based on concurrently replicating machines and disks which is managed by cloud endure. So no maintenance is needed by customers for staging area

Replication servers by default use T2 small instance types.

1 replication server can handle upto 15 concurrently replicating disks

Replication is encrypted with AES-256 encryption key and encryption at rest in the target is maintained with EBS encryption

2 stages of replication :

  • Initial sync : cloud endure copies the entire existing content of the source disk into ebs volumes in the staging area
  • Continuous data replication : copies any changes and synchronously copies that to the target staging area

Blueprint

  • The target machine blueprint is a Set of instructions and how to launch target machines for your source machines such as target subnets, instance types, security groups, volume types, tags, etc.
  • This lets cloud endure know how to orchestrate your target machines

Network architecture

  • The Cloud Endure agent on source machine should be able to connect to Cloud Endure console through Port 443. This connectivity must be in place as long as the data is replicating

This is a HTTPS connectivity and can be redirected through Web Proxy.

  • The cloud endure agent sends data to the replicating agent through port 1500
  • Connectivity between staging area and cloud endure console is similar to connectivity between Source machine and Cloud Endure console which is Port 443 for authentication, integration and monitoring purposes. This connectivity must be in place as long as the replication is in progress
  • In addition, when the replicating server spin up, it must be able to access S3 for downloading softwares and configuration files.
  • It also issues an API call to take snapshots of EBS volumes. So connectivity to EC2 API endpoint on port 443 must also be in place

 

Practical steps for Lift and Shift Migration using Cloud Endure

1. Login to

https://console.cloudendure.com/#/signIn

2. You need to have the AWS Access Key ID and Secret Access key of the AWS user to proceed with your migration.

3. Also, the AWS user needs to be attached with a policy having the below JSON code :

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "RunInstances"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVolume"
}
}
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:DeleteVolume",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:RevokeSecurityGroupEgress",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "CloudEndure*"
}
}
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:DeleteVolume",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:RevokeSecurityGroupEgress",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/CloudEndure creation time": "*"
}
}
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"ec2:DisassociateAddress",
"ec2:CreateDhcpOptions",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeregisterImage",
"ec2:DeleteSubnet",
"ec2:DeleteSnapshot",
"ec2:ModifySnapshotAttribute",
"ec2:ModifyVolumeAttribute",
"ec2:CreateVpc",
"ec2:AttachInternetGateway",
"ec2:GetConsoleScreenshot",
"ec2:GetConsoleOutput",
"elasticloadbalancing:DescribeLoadBalancer*",
"ec2:CreateRoute",
"ec2:CreateInternetGateway",
"ec2:CreateSecurityGroup",
"ec2:CreateSnapshot",
"ec2:ModifyVpcAttribute",
"ec2:ModifyInstanceAttribute",
"ec2:ReleaseAddress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AssociateDhcpOptions",
"ec2:ImportKeyPair",
"ec2:CreateTags",
"ec2:RegisterImage",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:AssociateRouteTable",
"ec2:CreateRouteTable",
"ec2:DetachInternetGateway",
"iam:ListInstanceProfiles",
"ec2:AllocateAddress",
"ec2:ReplaceNetworkAclAssociation",
"ec2:CreateVolume",
"kms:ListKeys",
"ec2:Describe*",
"ec2:DeleteVpc",
"iam:GetUser",
"ec2:CreateSubnet",
"ec2:AssociateAddress",
"ec2:DeleteKeyPair",
"ec2:CreateNetworkAclEntry",
"outposts:GetOutpostInstanceTypes"
],
"Resource": "*"
},
{
"Sid": "MigrationHubConfig",
"Effect": "Allow",
"Action": [
"mgh:GetHomeRegion"
],
"Resource": "*"
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"mgh:CreateProgressUpdateStream",
"kms:Decrypt",
"kms:Encrypt",
"ec2:RevokeSecurityGroupEgress",
"ec2:DeleteDhcpOptions",
"ec2:RunInstances",
"kms:DescribeKey",
"kms:CreateGrant",
"ec2:DeleteNetworkAclEntry",
"kms:ReEncrypt*",
"kms:GenerateDataKey*"
],
"Resource": [
"arn:aws:mgh:*:*:progressUpdateStream/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:network-acl/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:kms:*:*:key/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"mgh:ImportMigrationTask",
"mgh:AssociateCreatedArtifact",
"mgh:NotifyMigrationTaskState",
"mgh:DisassociateCreatedArtifact",
"mgh:PutResourceAttributes"
],
"Resource": [
"arn:aws:mgh:*:*:progressUpdateStream/*/migrationTask/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*::network-interface/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*::snapshot/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*::image/*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": "ec2:Delete*",
"Resource": [
"arn:aws:ec2:*:*:route-table/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:internet-gateway/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "CloudEndure*"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": "ec2:Delete*",
"Resource": [
"arn:aws:ec2:*:*:route-table/*",
"arn:aws:ec2:*:*:dhcp-options/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:internet-gateway/*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/CloudEndure creation time": "*"
}
}
},
{
"Sid": "VisualEditor9",
"Effect": "Allow",
"Action": "ec2:ModifyVolume",
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "CloudEndure*"
}
}
},
{
"Sid": "VisualEditor10",
"Effect": "Allow",
"Action": "cloudwatch:GetMetricData",
"Resource": "*"
}
]
}
 

4. Click on New Project with the + symbol

5. Provide the Project Name and create project

 

6. You now need to setup your project. Provide the AWS Access Key and Secret Access Key details as shown below :

7. In Replication Settings, from Drop down menu select “Other Infrastructure” if you are migrating from On-Premise/Any other cloud provider to AWS Cloud. If you  are moving between AWS regions, then choose the desired AWS region in the Source. Similarly set your desired Target

 

8.  Provide the below entries as per your requirement or keep it as blank :

Replication Server instance type

Converter instance type

Choose if each source machine should have a dedicated Replication Server

Choose the default disk type and cost optimization mode to be used by the Replication Servers (SSD disks are faster; HDD disks cost less

Security Groups to apply to the Replication Servers

Enable/Disable Volume encryption

Snapshot retention Policy

9. Go to the Machines Tab and check the tokens  and process on how to add Cloud Endure agent on your source machines

In the below screenshot, the Installation token has been striked out for security purposes. Also, you will get the methods for installation of Cloud Endure Agent 

Follow the steps to install the cloud endure agent. Please install them as an Admin user to get all facilities.

10. Once the Cloud Endure Agent is installed, the Machine will show up as given below :

11. You can check the status after clinkng on the machine too

Here our source machine is test.infraxpertzz.com

12. Once the Initial Sync is done, the status of DATA REPLICATION PROGRESS will change to “Continuous Data Protection”

13. You can check the status of your replication from the flags provided in there. 

14. From machines, select the machine which you want to launch and launch in Test mode for checking compatibility and validating everything is fine before the final cutover

15. Choose the latest recovery point or the point till where you need to restore for testing

16. Once launched, you can see the job progress from the Job Progress tab on the right hand side

17. Once the target is launched, you can test the connections and validate before proceeding during the final cutover.

18. Follow the same steps from Step 14 and choose Recovery Mode instead of Test Mode during your Final Cutover date.