Migrating a web server to AWS EC2 and serverless
A single web server architecture works well when starting a project. Developing and managing the website is simplified since all the resources are centrally located on one server.
These single server designs allow us to use pre-built configuration or installation scripts that automatically set up everything. These tools set up the web server software (e.g., nginx), the runtime application (e.g., PHP), the database (e.g., MySQL), and firewall rules (e.g., iptables). Thus, our learning curve is shortened, and we can start developing quickly.
These types of setup work well when developing a web application locally on the developer’s computer or a single server meant for development purposes. When the application is ready to go live with actual users, this setup might work well at first. Yet, when that website becomes popular with a lot of users, we might run into issues supporting all the traffic.
Scaling the single server design
Suppose we are running our live website in our on-premises data center. Over time, as the traffic increases, the server CPU and RAM will increase. Ideally, the CPU and RAM utilization should be 50% or less for typical loads. The 50% reserve gives the server extra resources to support traffic spikes. When the server is running higher than 50% for typical loads, that might be an indicator that we should introduce another server. If the server is running at 80% or higher, we should introduce another server quickly since there is hardly any extra resource to support a traffic spike. A large enough traffic spike might crash or overwhelm the server. We should have a plan to upscale and downscale the number of servers based on the traffic patterns.
We will need to configure the next server. The second server will have a web server and database using the pre-built installers. We will need to configure the first and second servers to use the same server that has the database. The second database the installer set up may sit idle. Setting up database replication from the first database to the second might be a good idea. We also want to set up a load balancer to split the website traffic between both web servers. Let’s not forget that we might need to increase our Internet upload and download speeds with our ISP to make sure the connection speeds keep up with the website traffic. This single web server design is quickly becoming more complex with the introduction of a second server. What will happen when we introduce three or more?
Decoupling the web server and database server
We should consider having the web server and database server run on separate servers. The pre-built installers assume a single server, but we are finding the complexity increases when we introduce multiple servers. By separating the web server and database server, we can control how many web servers and database servers we need to support the website traffic load and database usage. We might find we have way more web servers than database servers because the website traffic demands more of a resource load from the servers.
Our on-premises data center will now require more real estate. It will need to store at least two servers: one for the web server and one for the database. We will have multiple web and database servers as the website traffic grows. The
Moving to the cloud
The benefits of the cloud start becoming evident as we run out of space in our data center, have to buy more servers, and pay for increased electricity and Internet bandwidth costs. Moving to a cloud provider, such as Amazon Web Services, simplifies our scaling strategy.
AWS has the EC2 service, which allows us to set up and destroy virtual servers when needed. We can set up a web server and database in minutes. We can shorten this time by having preconfigured EC2 images that are copies of configured servers that can be quickly deployed.
When introducing a second server, we can use the Elastic Load Balancer service to split the website traffic load among multiple servers. We can even configure rules for adding and removing EC2 servers based on the time of day or the traffic loads.
We can improve our website cybersecurity by configuring our Virtual Private Cloud. It is best practice to configure one network subnet on the VPC for Internet-facing resources (our web servers) and another subnet for non-Internet-facing resources (our database servers). None of our users need to connect to the database directly. Therefore, we can remove it from the network that has Internet access. We can configure our network firewall rules using VPC security groups and the Linux firewall rules to allow only the web servers to connect to the database servers.
Cloud architecture enhancements
We can evolve our cloud architecture over time. We can introduce a content delivery network using CloudFront to cache static content. Each time a website user requests an image, the web server has to use resources to deliver it. We are using computing resources unnecessarily for content that rarely or never changes. Rather, we can use CloudFront to cache our static content at edge routers worldwide.
We can put our static content in an S3 bucket that integrates with CloudFront. This will save disk space on our servers for code, virtual memory, and other things. Furthermore, S3 storage is cheaper than the virtual hard disks used by EC2.
We can move static webpages to a website powered by S3 and CloudFront. Suppose our marketing website and blog content rarely change. We can create those pages using HTML, CSS, and JavaScript. CloudFront can serve these files as a website. Then, we can use the web server for a web application (for subscribers) instead of a marketing site.
Another change we can make is to use API Gateway for our backend APIs. This allows us to use a mix of server-based, serverless, and direct integrations with other AWS services (such as writing directly to DynamoDB from API Gateway).
The architect diagram in the hamster’s thought bubble shows these design changes.
Conclusion
We briefly discussed how a single web server design becomes complex when trying to scale up for increased web traffic demand. Moving to the AWS cloud allows us to decouple our web server and database server while supporting load balancing and scaling virtual servers based on demand. We reviewed how to add a content delivery network, serverless computing, and static website hosting.
Before you go
If you want more details on how to decouple the single server design and how to build a serverless application, the Mastering AWS Serverless book provides more details.
These are other stories you might like.
