This is the second part of our article: AWS Certification Practice Exam: 3 Top Tips For You, Klaus Conrad is an experienced manager that started using AWS years ago. In this last article will take a closer look at the importance of monitoring costs and building fault-tolerant solutions with AWS.
Amazon Web Services will fail
I actually changed the title for this point from ‘can’ to ‘will’ because of how many times I have had to fight the notion that AWS never fails. AWS is resilient, but the folks at Amazon Web Services are the first ones to tell you to architect for failure. You can build amazingly resilient solutions using AWS, but YOU have to be the one to design a fault tolerant solution.
Amazon Web Services gives you all the tools to do so, but if you spin up a single instance, place a critical app on it and then expect it to never fail you are in for a rough time. Don’t deploy something that is business critical unless you are willing to put in place a proper solution that is as redundant as you can make it. The good news is that very often the elasticity and flexibility of AWS allow you to deploy a proper solution at a much lower cost than anything comparable outside of AWS. This will contribute greatly to making fault tolerance a much more palatable concept to the people paying the bills.
When designing from scratch, redundancy and SOA principles should be central to everything you do. If working with legacy applications, apply the same considerations you would in a traditional IT model – chances are good that if you mirror your existing setup as AWS services the cost will be lower.
Monitor Costs
Since we just mentioned costs – usage-based billing (pay for what you use) is a very cool concept. But it can be a double-edged sword. It makes entry into the world of AWS easy by minimizing upfront capital expenditure and allows you to start using lots of services at almost no cost. But once you start using AWS for ‘real work’ you must keep an eye on costs. Be smart about what you use. If you have EC2 instances running 24×7 and intend to keep them that way, do not use OnDemand pricing. Fork out for reserved instances.
Look at the different billing tiers for various services and pick the ones that best suit what you are planning to do. Try and anticipate the cost ahead of time so you are not surprised at the end of the month. This is especially important when you get into the exciting world of script based deployments and auto-scaling. You need to really embrace the concept of right-sizing your deployments.
Also, consider usability. It might make monetary sense to put files in S3 instead of buying a NAS, but if all your users sit on the LAN and they will be downloading those same files through your broadband link it might not be the most efficient solution and will be more expensive in the long run (e.g. consider what happens if work stops because your broadband went down and no one can access their files).
When people ask me why I like AWS, my answer is: because it is awesome. I love the way things work. I love the speed of deployment and the flexibility of working with AWS brings to a project. AWS as a company is one of the most responsive and pro-active organizations I have worked with – when you submit a feature request and they say they are working on it you KNOW they are actually working on it. There is a great community around the services and a real conviction that this is the future.
I firmly believe cloud computing is not a fad – it is here to stay and will be the future for many types of applications and services. But the future does not arrive for everyone at the same time. Some organizations will be ready to move to a cloud platform while others will need to do some serious reworking of their processes and systems before adoption makes sense. But what every organization should do is to slowly test the waters.
And what you as an individual IT Pro should be doing is to learn about and learn to love what AWS can do for you. It will be time well spent.
