- Kloudnative
- Posts
- How Not to Build a Solution on AWS Cloud
In partnership with
I had a client who hired a contract development team to build a custom application to be hosted on AWS. I’m a huge proponent and evangelist for SMBs to build applications in the cloud that they can either use in their business or offer as a SaaS solution to other businesses. The barrier to entry for custom development on the cloud is very low.
This article, however, is a cautionary tale on how not to develop an application in the cloud.
The Players
Our SMB Owner: Our protagonist had an idea for a custom application that would help him in his business. It was a fairly simple application and the desire was to have it specific to his needs without a lot of features he wouldn’t use. The thought was he could have it developed and hosted on AWS at a much lower cost that a per user subscription might cost for a similar commercial application.
The Dev Team: Just your typical outsourced application development entity. They know how to write business logic code. They know how to build databases. They know how to build functionl frontends that include user authentication and authorization.
The MSP: This is the outsourced IT management for the SMB Owner. The MSP manages the network and supports the SMB users. The MSP might have recommended the Dev Team to the SMB Owner. The application is being hosted in an AWS account managed by the MSP.
Kloudnative is committed to staying free for all our users. We kindly encourage you to explore our sponsors to help support us.
10x Your Outbound With Our AI BDR
Imagine your calendar filling with qualified sales meetings, on autopilot. That's Ava's job. She's an AI BDR who automates your entire outbound demand generation.
Ava operates within the Artisan platform, which consolidates every tool you need for outbound:
300M+ High-Quality B2B Prospects
Automated Lead Enrichment With 10+ Data Sources Included
Full Email Deliverability Management
Personalization Waterfall using LinkedIn, Twitter, Web Scraping & More
☝️ Support Kloudnative by clicking the link above to explore our sponsors!
The Application
The Dev Team worked with theSMB Owner and MSP to define what the application should be. The application would consist of a web front end, a business logic tier that would perform the actions requested by the user, and a database for storing data relevant to the actions in the application.
The application is a basic inventory and order accounting application logically built on the 3 tiers previously mentioned: web, logic, database. A very simple architecture.
In discussions with the SMB Owner and MSP it was decided the application would be developed and hosted on a Microsoft Server EC2 instance in AWS since that was a platform with which the developers were most comfortable.
The Implementation
There are several ways we could implement this application architecture on AWS. Our priorities as far as trading off cost versus high availability, for instance, will affect our decisions. What do we need as far as disaster recovery? How are we backing up our database? How do we backup our application configuration and user settings?
There are many things to consider and many correct ways to implement our architecture on AWS based on those considerations. The way our Dev Team decided to do it is not one of those correct ways.
What The Dev Team Delivered
What the Dev Team delivered was all 3 tiers in a single Microsoft Server EC2 instance. And it was a large instance with a large storage volume. The monthly cost for the instance running 24/7 was over $250.
This is essentially what it was. A single instance. In a single AZ. With a public IP address that was mapped to a url hosted on GoDaddy.
It worked. But that was about the best thing you could say about it.
What’s The Problem?
Let’s capture a list of the issues we see with this implementation and discuss how it could be better:
All 3 tiers are encapsulated in a single instance
The application is not horizontally scalable for performance
The EC2 instance is in a single AZ thus not highly available
The entire application along with database are directly accessible from the public internet
The url on GoDaddy points to a dynamic public IP address
There are no automated snapshots of the EC2 instance
And there are other issues we could point out, but these are the primary ones that many of those others result from.
Why are these issues bad?
Ultimately, these issues add up to a single point of failure that might be very difficult from which to recover. And likely not able to fully recover from a data security perspective.
Lack of horizontal scalability can be a performance issue if our application is prone to overload due to multiple users accessing simultaneously. We can overcome that to some extent with vertical scalability, i.e. a larger EC2 instance. The Dev Team in this case had really no choice other than a very large EC2 instance in order to address what they estimated to be maximum demand on the instance.
Single AZ implementation could result in our application being unavailable if the AZ our instance is running in were to go offline. That’s bad.
The fact that all session and user state and data are contained within our single EC2 instance really precludes us from implementing an autoscaled, multi-AZ solution. We would need to break our tiers and data out in ways that we have automated database failover and externalized state.
All 3 tiers being exposed to the public internet is a fundamental security issue due to a larger attack surface. If we decouple our tiers we can isolate our logic and database tiers in private subnets and use security group chaining to improve our security posture.
The url pointing to the EC2 public IP address is not good at all. What happens when we top and start an EC2 instance in AWS? We get new public IP address. Now our url is pointing to a non-existent IP address and we no longer have access to our application.
And, finally, no automated snapshots. With this single instance solution if something were to happen to that instance and we had to redeploy our application to a new instance then without a backup we are starting over. Whatever was in our database is lost.
What Is A Better Solution?
Decoupling our 3 tiers is where we would start on building a better solution. That would allow us to host our web frontend either in its own EC2 instance or in a S3 bucket. We would follow that with our application logic hosted in its own EC2 followed by our database either hosted in its own EC2 or in the AWS RDS service.
This would allow us to put our application logic and database in private subnets and allow access to those from specific security groups thus improving our security tremendously.
If we externalize state from our web front end and application tiers then we can put those in EC2 autoscaling groups and scale those in and out automatically according to demand on each tier. We could also deploy those autoscale groups across multiple AZs to address our high availability concerns.
There is an implied load balancing between the users and the Web instances. It is just not shown in the diagram for simplicity sake.
The Backstory
This example comes from a real life consulting that I did for a MSP and their SMB client. For that particular engagement we were not really interested in rearchitecting the solution since the client was moving off the custom solution anyway and was just accessing the application a few times each day to migrate old data as needed to the new solution.
I was consulted to come up with a way to start and stop the instance on a schedule so they could save money while they were migrating to the new solution.
In addition to this I created an EC2 snapshot of the instance. I also created an elastic IP that I associated with the instance and then updated the url mapping on GoDaddy to point to that elastic IP.
But I couldn’t help thinking how I would have done things differently in developing and deploying the application and that led to this article.
Summary
In this article we have looked at a common application architecture and how not to implement it in AWS cloud. We’ve looked at what could be done differently to make the application more dynamically performant with autoscaling and resilient with multi-AZ.
As mentioned at the beginning of this article there are many ways you can architect solutions in the cloud. We’ve looked at a very specific example. Let me know in the comments other things you think would be good to consider.