AWS Migration Checklist For Startups
Suppose you are going to adopt AWS as your cloud provider. Whether you are migrating from some other cloud providers or it is your first time setting up your application’s infrastructure on the cloud, This article will be immensely beneficial for you. AWS is an industry leader in cloud innovation technologies and carries the largest market share among cloud providers.
In this article, we will go through a checklist aimed at startups and growing companies who wish to migrate to AWS for their cloud needs.
Morgan PerryMarch 30, 2022 · 7 min read
CRO and co-founder of Qovery. Morgan is a Tech entrepreneur with 7+ years of experience in the SaaS industry.See all articles
Let’s start by documenting the following points.
- Basic need for migration – Are you migrating to AWS because you are struggling to maintain your application at Heroku? Is your application missing the desired scalability needs? Or are you facing some security and compliance challenges (E.g., PCI, HIPAA, SOC2?) Or it is just a cost factor.
- Business and Technical objectives – Clearly state your business and technical goals, which you wish to achieve after this migration is completed.
- Migration strategy (i.e., Phased Approach) – Specify if you wish to perform migration in one go or in multiple phases.
Why Do Businesses Migrate to AWS?
- Scalability – You will be able to scale out your business after moving to AWS. E.g. Auto scaling etc.
- Agility – You will be able to reduce your business’s time to market and shorten your application’s development cycles.
- High availability and Disaster Recovery – Your applications on AWS will have zero downtime, and they will be able to tolerate any disaster (physical damage to the data center, etc.)
- Cost – Moving to AWS will save your cost e.g., Cost of Infrastructure, services, etc.
Let’s start with the checklist of documenting all high-level technical needs.
Technical Requirements Checklist
- Verify that you have correctly documented any compliance/regulatory needs on AWS
- Verify that you have documented requirements related to data, e.g. :
- Cold data backups or any S3 buckets life cycle rules for data archiving
- Data retention requirements in SQS
- Any PII or sensitive data to be stored in the database should be encrypted
- Verify that you have documented the requirements related to serverless services e.g., Lambda, Fargate, etc., if applicable
- Verify that you have documented which users will have access to the AWS console and which users will only have programmatic access to AWS services
- Verify that you have documented a comparison table having a list of all the AWS services to be used, along with the information if the service from the previous cloud vendor was replaced or it was an entirely new addition on AWS.
- Verify that you have correctly documented the needs related to Route53 and routing needs
- Verify that you have correctly documented the setup of Cloud watch and audit logging needs.
- Verify that you have correctly documented the needs of the AWS audit trail, if applicable
- Verify that you have documented the needs for dedicated instances if needed.
- Verify that you have correctly documented the needs related to Infrastructure, Security, Network, Performance, Backup, and Cost. The checklist for all these areas can be found below.
Target Infrastructure Checklist
- Verify the target cloud types included in your migration. Examples include PaaS (Elastic Beanstalk), IaC (CloudFormation), database as service (RDS), function as service (Lambda), etc.
- Verify that you have your target infrastructure documented in the form of a table having the following information:
- Name of target AWS infrastructure component/service (e.g. Staging EC2 instance etc.)
- Region (not needed if all your services will be in one region)
- Type (PaaS, IaaS, database as service, etc.)
- What purpose it will serve
- Any other important info (e.g. this AWS service will be retired next year)
- Verify that the infrastructure has redundancy in different availability zones to support high availability/fault tolerance.
- Verify that you have correctly set up SNS, SES, and/or email and SMS notifications.
- Verify that you have correctly set up containerization services e.g. ECS, EKS, etc.
- Verify that you have correctly set up CI/CD services, if applicable
Target Security Checklist
- Verify that the root account has 2FA applied
- Verify that you have created IAM users to perform operations in AWS. You are using the root account only for billing purposes.
- Verify that you have correct permissions assigned to each IAM user
- Verify that you have correct access policies applied to your S3 buckets and their objects.
- Verify that you have Accidental termination protection enabled for your EC2 instances and other services where applicable
- Verify that you have applied standard password rotation policies to AWS console passwords
- Verify that you have given access to Access key/Secret access key to authorized users only
- Verify that the sensitive information like API keys, secrets are not part of code, they are ideally managed through AWS secrets manager or at least environment variables
- Verify that your API or web application redirects HTTP to HTTPS, if applicable
- Verify that you have generated SSL certificates through AWS ACM, if applicable
- Verify that you have correctly set up user authentication services e.g. AWS Cognito etc. if applicable
- Verify that you have correctly set up the hardware-based security module in AWS CloudHSM, if applicable
- Verify that the encryption is enabled for the contents of your S3 buckets, if applicable.
Target Network Checklist
- Verify all your security groups for the following:
- Correct security groups are applied to their respective services.
- Correct inbound rules have been applied in each security group (Give special attention to public access in inbound rules)
- Verify that correct security groups/IPs have been whitelisted in inbound rules
- Verify that you have placed internet gateway or NAT gateways in the correct VPC’s
- Verify that your database is on a private subnet (no public access)
- Verify all the route tables for correct routes, including the internal communication route
- If using AWS WAF, verify that you are using the correct WAF rules.
- Verify that all the communication between all services/applications is secured through TLS
- Verify that network and penetration tests are all passed.
- Verify that the traffic to your database is on SSL.
- Verify that you have correctly set up Elastic IP in your VPC’s
Target Performance/Scalability Checklist
- Verify that the new infrastructure on AWS supports the target workload, e.g., by using load testing tools.
- Verify that the correct type of ELB is used. E.g., NLB or ALB, etc. if applicable
- Verify that the right target groups are set up for ALB, if applicable
- Test the metrics for auto-scaling by artificially mimicking the health checks failure.
- Verify that the dynamic scaling and scheduled scaling is working correctly
- Verify the multi-AZ feature for RDS, if applicable
- Verify the read replicas feature for RDS, if applicable
- Verify that Dynamo DB, MongoDB have been correctly set up for read/write performance
- Verify that your EC2 instances support the desired network speed, bandwidth, compute needs, etc.
Checklist related to Backup / Archiving
- Verify that you have enabled AWS EBS volume snapshots, if applicable
- Make sure the snapshots are encrypted, if applicable
- Make sure that you have created image AMI’s of your EBS backed EC2 instances.
- Verify that you have enables automatic snapshots of your database as well
- Verify that you have set up hybrid cloud backup (e.g. Storage gateway), if applicable.
- Verify that you have set up S3 life cycle rules for archiving data E.g. Glacier etc.
Checklist related to Cost
- Verify that you have correctly evaluated the cost of all AWS services by using this AWS calculator
- Verify that you have considered region-wise cost because the cost of AWS services varies from region to region.
- Verify that you have visited the AWS billing dashboard and gone through the cost explorer to see costs for each AWS service in each region
- Verify that you have utilized any AWS credits, if applicable
- Verify that you can take advantage of AWS free tier services to save cost, if applicable.
Applying the above checklist will ensure that you do not miss any important aspect of your migration to AWS. It will not only simplify the process for you but will take you closer to your goal of successful migration.
How Qovery helps businesses to migrate on AWS
Think of Qovery as a DevOps engineer as a service. It keeps your team in full control of your infrastructure while doing the maintenance and the heavy lifting for you. Ideal for growing startups which cannot afford a DevOps engineer, Qovery simplifies the process of your migration to AWS. Qovery’s features like automatic CD pipeline, automatic upgrades of your cluster, Preview environments, etc., and the highly developer-friendly tools (UI, CLI, API) let you take most out of the AWS without going into the technical details. The good thing is that you use Qovery on your own AWS account, and you can also utilize your AWS credits. Qovery hides all the complexities related to the setup and management of infrastructure and services on AWS. You will see reduced dependency on DevOps, higher agility, faster release cycles, reduced development time, etc. All of these will enable you to market your product faster and eventually result in higher ROI.
Instead of spending months setting up your infrastructure or directly dealing with the complexity of AWS, you could consider Qovery. You can connect your git repository and start deploying your application in about 15 minutes while retaining the power of your cloud provider. Discover Qovery today!
Test and Release Features 4x Faster with On-demand Environments
Qovery is a Platform to Deploy Production-like Environments in your AWS account in Seconds; Helping Developers To Test and Release Features Faster ⚡️Try it out now!