Starting out with AWS can be a daunting task. Amazon has done a great job of documenting and presenting systems and services in a clear and concise manner, but when you try to apply those concepts to your specific infrastructure or use case things might not always simply click into place.
Understanding the benefits of working with AWS and weighing them against the challenges is key to a successful implementation. It is always important to put everything into the context of the particular organization or project you are considering AWS for. Some benefits seem universal: usage-based billing, low upfront infrastructure costs, just-in-time infrastructure, for example, translate well to most implementations. But beyond these, it gets more complicated to categorically embrace AWS in every situation. Is having my critical files on S3 better than keeping them on my branch-office file server? What if my internet is down? Will my legacy windows server app play nice with an RDS backend? What about security? Is AWS safe?
These are the types of questions you will face again and again, and the answers might be different for every particular use case. Deciding if AWS is right for you becomes a little easier if you consider AWS as a collection of tools (or services). Picking the right tool for the job at hand is what your decision-making process should be focused on. Let me offer some practical considerations.
1. AWS can be as much or as little as you want it to be
Doing everything in AWS can be a great concept if you are starting out from scratch. If your business case requires a solution that can handle rapid growth while keeping costs low there are very few alternatives to AWS (or cloud platforms in general) that come close. But for many company architects, the reality might be that they don’t have the luxury of starting over tabula rasa. They might be expected to move something ‘to the cloud’ that was never designed with SOA principles for example (say a legacy client-server app with tight coupling). In such cases, it can be more difficult to see benefits from moving. However don’t focus only on the app itself: consider aspects such as business continuity & disaster recovery, running costs, availability, and scalability and compare what you get on AWS vs what you have now.
Look at what your customer or organization is doing and try to find things that make sense to do with AWS. Consider using EC2 to have cheap and disposable test machines. Keep some backups on S3 or Glacier instead of investing in more tapes or NASs.
Really embracing AWS should be an evolutionary journey for many organizations.
2. You don’t have to go it alone
If you sign up with AWS directly, understand exactly what you are getting. Amazon provides you with a platform of services that you can use. There will not be a lot of hand-holding. There will not be a lot of direct support. You are expected to know what you are doing at least to some level. Although AWS offers premium support options, these can get expensive quickly and might not be cost effective for smaller deployments.
Depending on your particular situation it might make more sense to sign up for AWS services through an AWS partner. They can assist you in planning and deploying your AWS solution as well as assisting in the management and monitoring of the solution. If you are asked to deploy something with 24*7 uptime for example but don’t have the IT resources to actually cover everything 24*7, going with a partner organization that can offer that constant level of support can be a smart move in the long run.
AWS is able to give you the tools to monitor your instances 24*7, but no one from AWS will actually fix anything for you if your EC2 instance crashes. You might be able to architect your solution so that it is redundant on many levels, but if having managed services is important to you and your customers then make sure you factor this into your planning.
3. Security is important
Is AWS safe? I think this must be one of the most frequently asked questions in any implementation. The short answer is that AWS is as safe as you make it. Understand where your responsibility starts and where Amazon’s responsibility ends. AWS dedicates a huge amount of resources to make sure their infrastructure and services are safe. But once you start using those services it is up to you to make the right decisions. AWS is like a car manufacturer – they try to make their product as safe as possible, but if you drive recklessly you only have yourself to blame.
A simple example: spin up an EC2 windows instance and open port TCP 3389 to the world. Smart? Definitely not. I can almost guarantee that within 24 hrs at the latest you start getting password spammed. Of course, this will happen whether your server is on AWS or any other provider or in-house – an inherent risk of connecting anything to the web. But it underscores the point that AWS makes it easy to avoid such a mistake, but if you go ahead and ignore best practices then the security problem is not AWS – it is you.
There will be more sophisticated situations where security can make or break an AWS deployment. Some services at AWS might not be at a stage yet where you want them to be (e.g. not all RDS instances have transparent encryption for example) which might require you to rewrite your application to encrypt data within the application or switch back ends to something that works at AWS. What you should not do is put unencrypted data at AWS and then complain if someone steals it. Design your solutions under the assumption that people will try to breach your security and do everything you can to prevent that from happening. A healthy dose of paranoia can go a long way to improving system design.
Also, be aware of AWS specific limitations. One example: because of the way AWS stores data in S3, you cannot audit a particular HDD and say ‘my data is stored here’. A strange request maybe but one that is made in certain industries and for certain applications. Be aware of how things work before making the leap.
When considering security the reality in many cases is that AWS is probably more secure than many in-house IT departments – the certifications and resources they can boast of is a testament to that. But your solution and data are only as secure as the procedures and systems you put in place and the choices you make when deploying and building your solution.
