Securely Migrating to AWS

In a previous post, we talked about the best security practices to migrate your on-premise workloads to a cloud service provider (AWS, Azure or GCP). The post talked about the five-step secure migration process:

• Assess migration opportunities
• Identify the scope
• Build a dependency plan between applications and components
• Build the infrastructure
• Migrate to and validate the target environment.

The entire migration process remains the same for any cloud service provider; however, services and tools might change.

In this part of our series on secure cloud migration from on-premise to any cloud service provider, we will focus specifically on securely migrating workloads to Amazon Web Services (AWS), applying the five steps listed above.

Opportunity Assessment

Before you start with a migration plan, it is important to complete a business and technical assessment of the given target environment and identify whether or not the applications in question are a right fit for the migration. This assessment involves gathering necessary documents about the infrastructure and the application along with a dependency map that provides vital information pertaining to the migration plan. The key goals of this assessment exercise are to gather the proper objectives, identify possible challenges, and determine business and technical benefits that can lead to the reduction of debt (technical, business, and/or people) for the organization.

AWS provides a great partner ecosystem that boasts years of practical migration expertise and can greatly reduce your assessment and migration effort. AWS partners, such as RISC Networks, Cloudamize, and ATADATA, have built tools to perform automatic discovery of the information needed and add intelligence to the data collected, helping customers identify the right environment and the correct order for the migration.

Determining the Scope of Change

The output of the previous step feeds data into this second step of the process. In step one, you identified the scope of change for the application for it to be migrated to AWS. The scope of change depends on several factors, including time, cost, business requirements, and technical debt. As discussed in the previous post on secure cloud migration, there are four possible choices to define the amount of architectural refactoring.

Rehost

This approach allows you to migrate an application to the cloud without any architectural changes: an as-it-is migration. AWS has recently acquired its partner, CloudEndure, which mastered the art of rehosting migrations. This product makes migrations quicker and easier than before. AWS Server Migration Services is yet another service offered by AWS for a lift-and-shift application migration.

Replatform

Replatforming is the migration of workloads with minimal changes to the target environment, leading to optimal cloud benefits. A classic example here is migrating your database workloads to Amazon Relational Database Service. To simplify the effort, AWS launched Database Migration Service (DMS), which allows you to migrate the database asynchronously and cut over to the new AWS environment with minimal downtime. For other application components, you can sync data files or follow a dump-and-restore approach by using various services such as Amazon S3, AWS Direct Connect, and AWS Snowball.

Repurchase

Repurchasing refers to purchasing or licensing your application directly from AWS Marketplace, which offers thousands of products built specifically for the cloud. It frees you up from your license management overhead, and the need to rewrite or redesign the application. In many cases, all you need to do is move over your data.

Redesign

A redesign is the most time-consuming and expensive effort. However, it delivers numerous benefits, especially since it will encourage the use of service-oriented architectures. It allows you to leverage AWS microservices, such as AWS Lambda, AWS ECS, AWS EKS, Amazon SQS, Amazon SNS, and Amazon SES, and requires you to focus on application functionality rather than infrastructure maintenance.

Map Dependencies and Plan

Once the assessment is complete and the scope of change is identified, it’s time to plan out the migration for the chosen applications. Here you will identify the assets to migrate and their order of migration, and create a solid governance plan to track progress.

The application migration order can be driven by one of three things: technical dependencies, business considerations, or operational issues. Often it is ideal for the organization to start with a crawl-walk-run approach, which involves starting out with a small application and using it to validate the entire migration plan, before hitting the revenue-impacting applications.

Planning for security

While migrating the applications to AWS, security considerations play a vital role. It is important to have proper governance with the right security controls planned out during the migration process. This starts with setting up the right foundation for the infrastructure by properly designing AWS VPCs, subnets, and route tables. The VPC architecture helps to plan out the subnets in which the applications or services will be deployed, with only a minimal number of them capable of being directly accessed from the Internet. It is advisable to open traffic only to necessary ports in security groups, rather than opening all ports and blocking them at the Network Access Control List.

AWS CloudTrail governs the activity in your AWS account, while AWS Config helps you record the configuration history and timeline of the resources. If you have workloads spanning across multiple AWS accounts, it is also advisable to implement service control policies at the organizational level to protect the environment from any unintended changes. AWS IAM is another service which allows you to enforce the permission structure on the various users in the account and implement the least required access model.

For network and perimeter security, AWS has released GuardDuty, AWS Shield, and AWS WAF. These services protect the application from various advanced threats, although AWS WAF and AWS Shield do not provide complete protection. By combining these services with AWS partners like Reblaze, which can serve as the ‘security engine’ for AWS WAF and AWS Shield, the security posture can be solid.

Lastly, it is crucial to capture the logs from all relevant sources and aggregate them at a centralized location for event correlation, security, and threat analysis. AWS CloudWatch Logs comes in handy to help you collect all system-level logs and VPC FlowLogs in an efficient and scalable manner. You can also create alerts by leveraging the metric filter alarm feature.

Create Infrastructure

Once the secure migration plan is solidified, it’s time to go ahead and provision the resources on AWS. This starts with setting up the foundation VPC layer following all security best practices and services, and then provisioning EC2, RDS, DynamoDB, and other AWS services as required for the application.

Often, one of the goals of a cloud migration is to turn your company into a cloud-native or DevOps/DevSecOps organization. For this, you can leverage the infrastructure-as-code capability of AWS by using AWS CloudFormation. This allows you to maintain the environment in JSON or YAML format. Furthermore, by constantly updating your CloudFormation template and pushing the changes, you can ensure that there is no drift from your defined standards. There is also an open-source alternative to CloudFormation called Terraform.

Migrate and Validate

Once your AWS foundation resources are provisioned, you can migrate the data to AWS and validate the integrity and consistency of the data. For migrating your server images, especially for the Rehost approach, it is advisable to leverage AWS SMS or CloudEndure. If you are running your environment on VMWare, you can also leverage VMWare on the AWS platform for the migration.

For database migration, it is advisable to leverage AWS DMS for continuous replication of the database, which makes the cutover smoother and quicker.

If you are dealing with static files or data, it is advisable to migrate it over AWS DirectConnect or Amazon S3 Transfer Acceleration and sync it back to AWS. However, if you’re planning to move petabytes of data, you can leverage Snowball for your data transfer.

Also, if any of the AWS services don’t meet your requirements, one of the great things about AWS is its Marketplace. Here you can leverage any third-party product, usually on a pay-as-you-go model.

Lastly, validation plays a significant role in the entire migration process, since you need to validate the consistency and security of the data. For data consistency and integrity, cryptographic hash functions and checksums can be used; many AWS tools have built-in capabilities for this. For the security of the data, penetration testing can be performed to ensure there is no data leakage. You also need to ensure that the cloud security solutions adapt themselves to each application and secure the workloads.

One last note on penetration testing, which might sound like a strange thing to do as part of a migration. Sometimes organizations don’t do any pen testing; they just focus on basic checks like network security, data encryption, key management, patching, and IAM policies to validate environment security. However, it is recommended to get the penetration testing done for your entire environment, to assure that the migration and its related changes have not introduced any new security gaps into the environment. The security gaps can be at CSP layer or the application layer, and it is important to validate the security posture end-to-end before going live.

Conclusion

Any organization migrating their workloads to AWS requires a solid understanding of their workloads and components, as well as the dependencies between them. This understanding, followed by a complete secure migration plan, can help your organization leverage the benefits of the cloud and protect the workloads from new threats. AWS does fine work in providing services and a partner ecosystem to support such a large and complex workload migration.

Do you have questions on any of the above? Feel free to contact us.