Building a Scalable AWS Web Application: A Step-by-Step Architecture Runbook

When you are first getting started with cloud infrastructure, clicking through the AWS Management Console is a great way to learn. However, transitioning from manual clicks to a documented, repeatable architecture is what separates a beginner from a cloud professional.

This article serves as a reusable runbook for building a foundational, highly available web application stack on AWS. We will walk through setting up isolated networking, configuring least-privilege security, deploying compute instances, distributing traffic, and integrating object storage.

Note: This architecture is designed for learning core AWS building blocks; for instance, we use HTTP instead of HTTPS to simplify the initial setup.

---

Architecture Overview

Our goal is to build out a simple web application infrastructure. We will deploy the following AWS services:

• Amazon VPC for network isolation.

• Security Groups and IAM Roles for access control.

• Amazon EC2 for our web server compute.

• AWS Systems Manager Session Manager for secure administration.

• Application Load Balancer (ALB) for traffic distribution.

• Amazon S3 for scalable object storage.

Our baseline environment will be deployed in the us-east-1 region. Let's dive into the build process.

---

Phase 1: Establishing the Network Foundation (Amazon VPC)

An Amazon VPC is a logically isolated virtual network that allows you to launch AWS resources in a secure environment.

Using the "VPC and more" wizard, we will create a network structure spanning two Availability Zones (us-east-1a and us-east-1b). An Availability Zone is a group of one or more data centers within a region, and using multiple zones provides high availability.

Key Network Configurations:

• Public Subnets: These subnets are routed to an Internet Gateway, allowing communication between the VPC and the public internet.

• Private Subnets: These host our compute resources and do not have direct internet access.

• NAT Gateways: We configure 1 NAT Gateway per Availability Zone. This allows our private web servers to communicate out to the internet to download updates without exposing them to inbound internet traffic.

• VPC Endpoints: We must include an S3 Gateway endpoint. This provides private connectivity to AWS storage services without routing traffic through the public internet.

---

Phase 2: Securing the Perimeter and Identity

Security in the cloud is layered. We will use Security Groups to control network traffic and IAM Roles to manage service permissions.

1. Security Groups

We need two distinct security groups in our project-vpc to enforce an isolated traffic flow:

• Load Balancer Security Group: Acts as our external access point, allowing inbound HTTP traffic on TCP port 80 from anywhere (IPv4).

• Web Server Security Group: Protects our private EC2 instance. It restricts inbound HTTP traffic on port 80 so that it is only accepted from the Load Balancer Security Group.

2. IAM Role and Instance Profile

Instead of using static credentials, we create an IAM role named WebServerInstanceProfile.

• We set the trusted service to EC2 and attach the AmazonSSMManagedInstanceCore managed policy.

• This role allows the EC2 instance to interact securely with AWS Systems Manager for administrative tasks.

---

Phase 3: Deploying Compute (Amazon EC2)

With our network and security policies in place, we can launch our web server (mywebserver) into the private subnet project-subnet-private1-us-east-1a.

We use an Amazon Linux 2023, 64-bit x86 AMI on a t2.micro instance type. To enforce security, we proceed without an SSH key pair. Instead, we attach the WebServerSecurityGroup and the WebServerInstanceProfile IAM role.

Bootstrapping via User Data: To automate the server configuration, we inject a bootstrap script via EC2 User Data. This script automates several vital steps:

• Updates packages and installs the Session Manager agent.

• Installs and starts Apache, PHP, and supporting packages.

• Downloads the AWS SDK for PHP and fetches the lab web content into /var/www/html.

Secure Administration: Because the instance resides in a private subnet and we did not assign an SSH key, we use AWS Systems Manager Session Manager to connect. This is the preferred administration path because it avoids direct SSH exposure to the internet while still allowing us to access the terminal directly from the browser.

---

Phase 4: Distributing Traffic (Application Load Balancer)

To allow users to access the private web server, we place an internet-facing Application Load Balancer (ALB) named WebServerLoadBalancer in front of it.

1. Network Mapping: We map the ALB to our two public subnets (project-subnet-public1 and project-subnet-public2) and attach the Load Balancer Security Group.

2. Target Group: A target group defines the EC2 instances that the load balancer will route traffic to. We create WebServerTargetGroup configured for HTTP on port 80 and register our mywebserver instance as a target.

3. Verification: Once the load balancer state becomes Active and the target group registers a healthy instance, we can copy the ALB's DNS name and paste it into a browser (using http://) to view our functioning website. We can also use the website's API test to confirm that the instance can reach the internet through the NAT Gateway.

---

Phase 5: Integrating Object Storage (Amazon S3)

Amazon S3 is an object storage service offering industry-leading scalability, data availability, security, and performance. Our web application requires access to S3 to store and retrieve files.

• We create a new S3 bucket with a globally unique name in the us-east-1 region, keeping the default settings.

• After uploading the required unarchived lab files to the bucket via the AWS console, we configure the web application by entering the bucket name and region into the site's provided fields.

• Thanks to the S3 VPC Endpoint we created earlier, the private EC2 instance can securely communicate with S3 and successfully utilize the S3 object browser from the load-balanced site.

---

Summary and Next Steps

By following this runbook, we have successfully built a robust reference architecture for an AWS-hosted web application. We achieved network isolation with public and private subnets, restricted access using security groups, implemented IAM roles instead of static credentials, and securely managed a private EC2 instance via Session Manager. Finally, we distributed traffic with an ALB and connected our app to S3 storage.

The Next Challenge: The current design uses a single EC2 instance, which represents a potential single point of failure. For an advanced challenge, consider replacing this single-instance design with an Auto Scaling group to dramatically improve the application's reliability and scaling behavior.

---

Resources & Let's Connect

Explore the Project Repository Transitioning from a manual click-through exercise to a documented runbook is all about repeatability. You can view the complete project documentation and reference files for this architecture on my GitHub:

• TuWienProjects/aws-cloud-workshop2-vpc

Let's Discuss Cloud Architecture Are you working on scaling your own foundational cloud environments, or do you have insights on taking this stack to the next level with Auto Scaling and automation? I am always open to discussing cloud infrastructure, AWS best practices, and new engineering challenges.

• Let's connect and continue the conversation on LinkedIn: Sajid Bashir