What about AWS? That is a question I hear a lot when working in the SMB space.
AWS has basically dominated the space in terms of marketing and what Cloud is. Or at least what Cloud is perceived as. Azure is right behind them and making a really good run on AWS. Azure appears to have a better trust factor, whatever that means today. Regardless AWS is “The Cloud” and Azure is coming up hot and heavy and the masses seem to really trust Microsoft. Microsoft is seen as the business enabling partner SMB’s would rather work with.
I am not going to head a long and lengthy discussion about AWS vs Azure (another topic) but I believe the bottom line is that Microsoft has positioned itself as your trusted business partner providing your business applications for many years now. AWS is still known as “Amazon” and where you buy your everything in 2 days shipping or less. AWS is also known for awesome innovation, new features and fairly complex options for deployment and scale. Which is all very cool to an engineer but very scary for a company with no IT staff or a one person IT staff with limited overall experience. (Enter http://2ndwatch.com).
But back to the question. What about AWS?
Good question. So I set out on a journey to find out. We have been using AWS EC2 and VPC components for a few years. We have been utilizing AWS as a third party location outside our environments for performance testing of our services and availability tracking. We have also utilized it for other random services as required. Secure third party FTP, etc.
But I was never fully in the know so to say and needed to dig deeper. I wanted to know how AWS actually worked, its requirements, constraints, deployment options, scalability, durability, etc. I needed to know how to recover from failure or even build failure into the design. How zones and regions worked, how they were connected and a whole bunch of other things.
What I learned was actually amazing.
Smoke and mirrors make “The Cloud“ and AWS is pretty damn cool.
I am going to focus of the more popular SMB AWS modules in this discussion. Those being items such EC2, VPC, EBS and S3. SMB is not heavily utilizing Elastic Beanstalk. This will also be a nutshell topic. I am not doing a technical deep dive. The purpose of this article is to give a brief introduce to SMB about what AWS can/can’t do for them.
Smoke and Mirrors
The common perception is that the Cloud is 100% available and always on. The cloud is not 100% fault tolerant. There is no 100% uptime with any service anywhere. AWS is no different. Each one of their offerings has an SLA attached to it.
AWS S3 storage has an SLA of 99.9% (down from a once advertised 99.999999999%).
99.9% equates to up to 43 minutes of downtime per month.
EC2 instances have an SLA of 99.95%.
99.95% equates to up to 21 minutes per month.
And here is the AWS definition of “Unavailable”.
Unavailable” and “Unavailability” mean:
For Amazon EC2, when all of your running instances have no external connectivity
AWS can “Retire” your EC2 instance as it sees fit based on the health of the underlying hardware. All EC2 instances (VM’s) run on host hardware that can and will eventually fail. The VM will be stopped on the set retirement date. You can then restart your EC2 instance if it is utilizing EBS volumes. If the EC2 instance is utilizing the host root hardware you will not be able to restart this VM. The VM will need to be recreated. It is definitely highly recommended to utilize Elastic Block Storage (EBS) for your EC2 instances.
Most networking components are what AWS calls “Highly Durable” meaning that the chances of failure are low. But as you have seen from the EC2 and S3 SLA’s, failure can occur and the definition of what failure is will be determined by AWS and their pre defined definitions. So once again, plan for failure and design your network components around expected failure.
Regions and Zones
AWS EC2 assets are deployed to Regions and Availability Zones. A Region is a geographic area on the globe. Like US WEST. US WEST is located in Oregon or N. California USA. Or US EAST which is located in N. Virginia, USA.
A Zone (Availability Zone) is basically a data center in each region. Each Region will have at least 3 Zones. So US EAST will have zones US-EAST-1a, US-EAST-1b, US-EAST-1c, etc. Up to how many availability zones that they have for that Region. Many AWS services such as EBS and S3 are replicated between Availability Zones. It is however rare that a service is replicated between Regions.
These Regions and Zones will need to be selected based on risk tolerance, distance to end users, latency requirements, services being deployed into the cloud (DR vs Prod), etc.
Once the Region has been selected you can start designing the networking architecture between Zones and connectivity method to your office or via the internet.
It is at this time that the design should incorporate failure, replication and fault tolerance. It is 100% on you to design this. AWS is not going to manage your applications availability. AWS will manage their hardware and software only so much as to allow you to run services on their platform. You will need to design your application to fail and fail gracefully. This design will require spanning Availability Zones and designing your services to handle full Zone failure.
Here is an example from AWS pertaining to a single Active Directory deployment.
This diagram represents the proper design and planning for deploying Active Directory. That’s one small service (albeit critical) for most SMB’s.
Full understanding of each service and design requirements will be crucial to deploying highly available services.
Here is another example from AWS pertaining to an Exchange Deployment (simple and legacy).
In both examples it is evident that designing your solution around multiple Zones within a Region is mandatory to limit failure scenarios.
Many SMB’s today utilize RDP or Citrix services to access documents and applications remotely. Understanding of those services fault tolerant requirements would be required to design a proper solution. As would file replication between Zones.
Well lots. Patch management, AV/Malware protection, perimeter security, file share security, overall account management, backups and restore design, etc. Thats correct, AWS is not backing up your files or VM’s in a manner that allows for rapid recovery. You will need to design your own file recovery solution inside AWS and familiarize yourself with how to restore failed VM’s in a timely manner. Documentation and planning is paramount here.
AWS is pretty damn cool
There is no other platform available that allows you to consume resources as well as AWS. You can consume resources all day. Everything has a cost associated with it. Every single service is designed to allow you to quickly deploy resources and consume space. AWS will even allow you to automate the deployment of applications and services based on load. The toolbox of services and ways in which to deploy these services is awesome. Nobody can come close to it. They are selling you space, compute, etc. It is up to you to create the proper house that you want to live in.
Understand The Platform
Read all the documentation on all the modules you plan to use before you dive into AWS and start deploying resources. Marrying your application to AWS’s abilities is key. Every service available from AWS has great documentation and it is updated regularly.
I have read most of those documents. It is a lot of reading but its all very valuable information. If you want to be successful with your AWS deployment I would strongly suggest reading through at least the services you are interested in and having a vague understanding of what all services do. It is possible that a service that you do not even know about can provide further support for your application. (Route 53 for example).
In the end I hope this helps my SMB pals. Feel free to ping me with any questions or corrections!
Thanks for reading!