What to Expect When Moving to Amazon's AWS

So your organization has decided to make the move to AWS and they’re thinking about ways to manage the migration with the least amount resistance. Good for you! When moving to AWS there are multiple tasks that need to be completed for a successful migration or new implementation within their cloud offering. There are in-depth checklists, Amazon actually has one of their own and in this article, we’re going to review six areas we think should be considered before your move to Amazon occurs.

Applications and Data

When migrating to the cloud an organization needs to consider the applications they’re currently using and if they’ll function properly in AWS. It’s very possible an organization is using legacy apps that might not function properly up in the cloud. Yes, believe it or not, people still use legacy apps. Understand the needs of these applications and if they’re even able to be installed within AWS. Also, get a firm understanding of the data being stored in the cloud. If this data is sensitive, think PHI or PCI, determine if you have the proper controls implemented to cover both security and compliance. If you don’t have this capability after moving to the cloud, you’ll have to start utilizing security solutions to protect this data, either with the AWS native security resources, or other solutions you have configured as an EC2 instance or within a hybrid install. Examples of these solutions would be a web application firewall, data encryption (rest and transit), logging and security assessments. Amazon offers all these services, but it’s possible the organization already has virtual or hybrid solutions which will fulfill your needs. Lastly, it’s important to determine if you’ll be using a public or private cloud model with your data/applications. This could come into effect if there’s a busy tenant causing resource issues which inadvertently cause your stack/application to have performance degradation.

Billing and Cost

As with anything cost and billing are important. This will almost always be an operational expense and the budgeting of moving to the cloud should be spoken of with finance before considering a move. This being told there are a few items to keep your eyes on with AWS. The first thing to determine is if there are other accounts setup with Amazon that might be active within the organization. With it being as easy as setting up instances with a credit card it’s possible a business is already in the cloud and you don’t even realize it. If this occurs or there’s a need to have multiple accounts created there should be an AWS master account created to link back all the services to the organization. Secondly, create billing alerts that will notify you when configured thresholds have gone over. The last thing you want is a misconfiguration or security issue causing additional dollars without knowing about it upfront. There are many other areas to review with billing, but these are two areas you might want to start off with.

Change Management and Automation

This is a big deal in the world of cloud. When deploying systems in the cloud everyone thinks it will be automation nirvana, but because of this flexibility, change, and config management need even more attention. When dealing with a purely AWS environment it needs to be determined who can build and launch instances within your account. AWS has something called Amazon Machine Image (AMI) which allows the needed information for an instance to be built. These need to be monitored as to not have issues with deploying wrong instances and keeping up with updates. Also, how will an organization deal with system hardening, patching, firewall changes (since security groups need to be understood before making inappropriate security holes). When dealing with additional changes and config management on instances it’s very easy to start VM creep and creating a decommissioning process should be written for cost, operational and security concerns.

Incident Response and Security

This is a topic that can have multiple articles written on it alone, but we’re going to try and cram as much as we can in here now. If you’re using AWS for your entire ecosystem then bringing in their security services is a must. Amazon has published native services that allow the ability to use them for IAM, logging, cloud WAF, MFA, encryption with HSM’s and security assessments. Using these tools is a must if you’re going to go all in with Amazon. Using their tools can assist with security since they have native integration with each tool within the Amazon ecosystem. Last, but not least, incident response in the cloud needs to be reviewed. Performing IR in the cloud is a different animal and you’ll need to determine if your normal procedures, tools and runbooks will fit while performing IR in the cloud. There will be areas you can’t touch, like logs on a system within a multitenant environment, and working with Amazon during this time is essential. Learn what you need to do upfront before you have too late.

Remote Management

Obviously, since the systems aren’t on-premise there needs to be a way to remotely access your instances securely. With this there are a few options that need to be thought out before even creating a single instance in AWS. The access to the console needs to be secured and logged right away. It should also have MFA on it and locked down to a particular range if possible, possibly via VPC. This is the access to your world in the cloud and it needs to be secured. Also, there will be applications that have access to the API’s which essentially could have complete access to the instances in AWS. These need to be protected and configured in a way that this access doesn’t get compromised. It’s a big subject and one that needs to be reviewed in greater detail. Lastly, understanding if you’ll be using federation services to tie back to any on-prem LDAP or other identify instance is a thought that must be understood during the design phase of the cloud implementation.

Disaster Recovery and Resiliency

Reviewing how your new cloud environment is built for disaster and resiliency is another major factor to consider when investing in AWS. Get a feel for the availability zones you’ll be hosting your environment in and where you’d like to fail in case of emergency. It’s possible to fail to availability zones in different countries and if that’s that case you should review the data laws of the country your data will no reside in afterward. For your applications and systems, there should be no single point of failure and all critical apps should have a process to make it resilient. Amazon has multiple load balancing, snapshot and synchronization services that allow a customer to keep their data available at all times.

AWS offering is deep and before investing your money into moving into their architecture a customer should have a firm understanding of both their current architecture, where they’d like to be in the future and what AWS has to offer. The options are vast and planning up front is needed for a successful implementation.