A Framework For Hosting Apps on AWS
Consider using some combination of these services
There are a ton of benefits that come from hosting web applications in the cloud, such as the ability to save money in various ways and scale to any size. I do not want to talk about said benefits here, but instead let’s assume that you have decided to host a web application in the cloud.
I’d like to give you a framework of services that you can pick and choose from to host your web app on AWS, my cloud provider of choice. Depending on your use case, you should consider using some of these services to the appropriate extent, and set your architecture up to where they can work together independent of your supervision.
Something to consider first, is that I will only lay out what is actually needed to run your app. We will assume you are going to implement admin tools like CloudWatch, CloudTrail, IAM policies etc. These should be a given because security should be priority number one for really any organization or application.
We will take a look at 5 different services, and as I previously mentioned you can use each to different degrees, or not at all if it doesn’t fit your use case.
- EC2
- S3
- RDS
- CloudFront
- SQS
- EC2
AWS’s flagship service for computing workloads. Utilizing EC2 allows you to provision servers to host your application, handle logic, and serve requests going between your end users and private subnets.
Within EC2 you can utilize auto scaling to automatically add or reduce computing resources based on your predicted or actual workloads. The best way to figure out what kind of resources you need to provision, is to use monitoring tools to overtime see usage patterns. You could then set the appropriate auto scaling policies so that your application meets the demands of both you and your consumers/customers.
At your disposal you will have a fully interactive console, as well as API tools for a CLI if you wish to go that route to manage your compute workloads. You can find more information about EC2 here.
2. S3
Amazon’s object storage service (also the first publicly available AWAS service) that can be used to store a variety of objects and file types. S3 stores redundant copies of your data for availability purposes, and supports multiple types of encryption for security.
S3 works with just about every other AWS service so it can be a great place to store multiple types of objects either from your customers, or that your application needs to function. Many services such as Amazon Athena can easily parse over S3 to analyze some of your workloads and data.
You also have the option to use S3 for static website hosting, if you would like to get a little more hands off with certain components of your applications. A link to the S3 documentation can be found here.
3. RDS
RDS is AWS’s SQL like database offering, with multiple types of relational databases being supported, such as SQL server, PostgreSQL, Oracle, and others. It is another fully managed service, meaning all you really need to worry about is how you are going to use your database.
If you have existing data to import, it is relatively simple. They also have their own serverless version of SQL called Amazon Aurora that was built to scale almost limitlessly and also to be highly available.
Just like with EC2, you can scale your databases up or down to meet your performance requirements while also optimizing your costs to the greatest possible extent. More information about RDS can be found here.
4. CloudFront
CloudFront can be thought of as a global content delivery service. I like to picture a cloud (filled with my resources) rolling out across the world, delivering my content.
The main purpose of this is to increase the efficiency in delivering content to users that are geographically very far away from your servers. In theory this would provide those users with high latency, but the main objective of CloudFront is to cache dynamic and static content at edge locations closer to them, so that they can eliminate this latency issue.
A great way to say goodbye to a customer is to give them a poor experience when interacting with your website or applications. More information on CloudFront can be found here.
5. SQS
I like to think of SQS as the glue that holds your applications together, and allows you to automate processes as you work towards a higher degree of operational excellence.
An analogy I like to use to demonstrate how SQS works, is to think of the kitchen in a restaurant. You have your servers taking care of your customers and taking orders (representing your compute workloads). When they get an order they write it down on paper, and then post it right outside the kitchen so a chef can grab it and get started on it. This line of cards with orders would be what SQS is. Then, a chef (representing a database or other AWS service) can grab a card and get started on that order, get rid of the card so there are not duplicate dishes being made, then drop it off to have the server get it back to the customer.
SQS uses a pub sub model to allow your architecture to consume events that happen, and automatically take the appropriate response. The benefit to this is of course that you have to do less manual labor and focus more on your business and innovating. The SQS documentation can be found here.
Hopefully this helps you better visualize how to host a web application on AWS, although as I’m sure you have already found it is simple but not easy. AWS has some of the best documentation around, as well as a Github page with a ton of free labs to get some practice setting things up.
Thanks for reading, and as always best of luck in your journey through Cloud Computing.
