Building a High-Availability Multi-Tier Web App on AWS with Amazon VPC, EC2, and Aurora RDS

Introduction

In this project, I developed a highly available, multi-tier, and fault-tolerant web application on AWS, focusing on uptime, scalability, and security - making it suitable for production use. This experience allowed me to work hands-on with essential AWS services, like Amazon VPC, Amazon EC2, Amazon Aurora, and Amazon S3, to build an architecture that provides high performance, resilience, and cost efficiency.

Tech Stack

• Amazon VPC: Provides isolated networking environments for secure data flow.

• Amazon EC2: Hosts scalable web and application server instances.

• Amazon Aurora: A managed, high-performance relational database with automated failover.

• Amazon S3: Stores and serves static content with durability and low latency.

Prerequisites

• AWS Account: Required to access and configure all necessary AWS services.

• AWS CLI: For managing resources, configurations, and deployment tasks.

• Basic Networking Knowledge: Familiarity with networking concepts like subnets, load balancing, and security groups.

• AWS Console Proficiency: Experience using the AWS Console for deploying and configuring services.

Problem Statement or Use Case

Problem: Traditional on-premises infrastructure often fails to meet the needs of applications requiring high availability and fault tolerance, especially under varying loads.

Solution: This project implements a multi-tier architecture with high availability and fault tolerance using AWS. By setting up a web application across multiple tiers (frontend, application logic, and database), the solution ensures seamless user experience, even in case of server failure or maintenance.

Real-World Relevance: The solution suits production environments where uptime is crucial, such as e-commerce platforms, content-driven websites, and customer-facing applications. The architecture can dynamically adjust resources to accommodate fluctuating traffic, making it scalable and cost-effective.

Architecture Diagram

Below is a high-level overview of the architecture used:

Component Breakdown

1. Amazon VPC: Provides network isolation, enabling private and public subnets to securely route traffic between the internet and internal services.

2. Amazon EC2: Hosts web and application server instances, with auto-scaling groups to dynamically adjust resources as traffic demands change.

3. Load Balancer: Manages incoming requests and distributes them to healthy EC2 instances across different availability zones, ensuring high availability.

4. Amazon Aurora: A managed relational database that automatically replicates data and performs failovers, providing a resilient storage solution.

5. Amazon S3: Stores and delivers static content like images, CSS, and JavaScript files, reducing load on EC2 instances and improving performance.

Step-by-Step Implementation

Network — Amazon VPC

Create VPC

Amazon Virtual Private Cloud (Amazon VPC) allows you to start AWS resources with a user-defined virtual network. This virtual network, along with the benefits of using AWS’s scalable infrastructure, is very similar to the existing network operating in the customer’s own data center.

Move on to VPC service

1. After logging in to the AWS console, select VPC from the service menu.

If the screenshot below is different from the screen that you’re viewing, enable the New VPC Experience toggle to active.

Create VPC through VPC Wizard

1. Select VPC Dashboard and click Create VPC to create your own VPC.

1. To create a space to provision AWS resources used in this lab, we will create a VPC and Subnets. Select VPC and more in Resource to create tab and change name tag to VPC-Lab. Leave the default setting for IPv4 CIDR block.

It is a best practice to deploy resources across multiple Availability Zones for high availability and fault tolerance.

1. To design high availability architecture, we create 2 subnet space and select 2a and 2c for Customize AZs. And set the CIDR value of the public subnet that can communicate directly with the Internet as shown in the screen below. Set the CIDR value of the private subnet as shown in the screen.

1. You can use a NAT gateway so that instances in your private subnets can connect to services outside your VPC, but external services cannot initiate direct connections to these instances. In this lab, we will create a NAT gateway in only one Availability Zone to save cost. Also, for DNS options, enable both DNS hostnames and DNS resolution. After confirming the setting value, click the Create VPC button.

1. As the VPC is created, you can see the process of creating network-related resources as shown in the screen below. For NAT Gateway, provisioning may take longer compared to other resources.

1. You can check the information of the created VPC. Check related information such as CIDR value, route table, network ACL, etc. Check that the values you just set are correct.

Architecture Configured So Far

If VPC is completed through the VPC Wizard, the environment configured so far is as follows.

Challenges Faced and Solutions

• Cross-AZ Latency: Replicating data across availability zones resulted in some latency in data access.

• Solution: Used Aurora’s automated cross-region replication to reduce latency while maintaining data consistency.

• Auto Scaling Configuration: Initially faced challenges with EC2 instances not scaling back down after load reduction.

• Solution: Adjusted Auto Scaling policies to ensure smoother scaling transitions, keeping resource usage cost-effective.

Create VPC Endpoint

In this section, you create an endpoint for S3 to learn a VPC endpoint. Skip to do this step will not affect your progress to the next lab.

VPC Endpoint

1. In VPC Dashboard, select Endpoints. Click Create endpoint button.

1. Type s3 endpoint for name and select AWS services in Service category tab. In the search bar below, type s3 and select the list at the top.

1. For S3 VPC endpoints, there are gateway types and interface types. For this lab, select the gateway type. And for the deployment location, select the VPC-Lab-vpc created in this lab.

1. Choose a route table to reflect the endpoint. Select the two private subnets as shown below. Additional routing information for using the endpoint is automatically added to the selected route table.

1. You can also configure policies to control access to endpoints as shown below.

You can use VPC endpoint policies to allow full access to AWS services or create custom policies. Check Use VPC endpoint policies

1. Confirm that the route to access Amazon S3 through the gateway endpoint has been automatically added to the private route table specified earlier.

VPC endpoints are communications within the AWS network and have the security and compliance advantage of being able to control traffic through the endpoints. You can also optimize the data processing cost if you transfer your data through a VPC endpoint rather than a NAT gateway.

In this section, you created a S3 gateway endpoint to allow private S3 access from within the VPC without needing an internet gateway. This keeps S3 traffic private within the AWS network.

Compute — Amazon EC2

Launch a web server instance

This chapter starts with the default Amazon Linux instance and lets you automatically configure the Apache/PHP Web server during initial step.

Launch instance and connect to web service

1. In the AWS console search bar, type EC2 and select it. Then click EC2 Dashboard **at the top of the left menu. Press the **Launch instance **button and select **Launch instance from the menu.

1. In Name, put the value Web server for custom AMI. And check the default setting in Amazon Machine Image below.

1. Select t2.micro in Instance Type.

1. For Key pair, choose Proceed without a key pair.

1. Click the Edit button in Network settings to set the space where EC2 will be located.

And choose the VPC-Lab-vpc created in the previous lab, and for the subnet, choose public subnet. Auto-assign public IP is set to Enable.

1. Right below it, create Security groups to act as a network firewall. Security groups will specify the protocols and addresses you want to allow in your firewall policy. For the security group you are currently creating, this is the rule that applies to the EC2 that will be created. After entering Immersion Day - Web Server in Security group name and Description, select Add Security group rule and set Type to HTTP. Also allow TCP/80 for Web Service by specifying it. Select My IP in the source.

It is a best practice to configure security groups following the principle of least privilege, allowing only the minimum required traffic.

1. All other values accept the default values, expand by clicking on the Advanced Details tab at the bottom of the screen.

Click the Meta Data version dropdown and select V2 only (token required)

Enter the following values in the User data field and select Launch instance.

#!/bin/sh
​
#Install a LAMP stack
dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel
dnf install -y mariadb105-server
dnf install -y httpd php-mbstring
​
#Start the web server
chkconfig httpd on
systemctl start httpd
​
#Install the web pages for our lab
if [ ! -f /var/www/html/immersion-day-app-php7.zip ]; then
   cd /var/www/html
   wget -O 'immersion-day-app-php7.zip' 'https://static.us-east-1.prod.workshops.aws/public/2e449d3a-fc13-44c9-8c99-35a37735e7f5/assets/immersion-day-app-php7.zip'
   unzip immersion-day-app-php7.zip
fi
​
#Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
   cd /var/www/html
   mkdir vendor
   cd vendor
   wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
   unzip aws.zip
fi
​
# Update existing packages
dnf update -y

User Data is a user-defined initialization script that is executed when the first instance is created.

1. Information indicating that the instance creation is in progress is displayed on the screen. You can view the list of EC2 instances by selecting View Instances in the lower right corner.

2. After the instance configuration is complete, you can check the Availability Zone in which the instance is running, and externally accessible IP and DNS information.

1. Wait for the instance’s Instance state result to be Running. Open a new web browser tab and enter the Public DNS or IPv4 Public IP of your EC2 instance in the URL address field. If the page is displayed as shown below, the web server instance is configured normally.

2. If you are using the Chrome web browser, when you attach the Public IPv4 DNS value to the web browser, if it does not run, https may be automatically added in front of the DNS value, so it may not run. Therefore, it is recommended to enter http://.

Access the web service

1. Go to the EC2 instance console. Select the instance you want to connect to and click the Connect button in the center.

1. In the Connect your instance window, select the EC2 Instance Connect tab, then click the Connect button in the lower right corner.

1. After a while, you can use the browser-based SSH console as shown below. Just close the window after the CLI test.

Connect to the Linux instance using Session Manager

You must click the Access your Linux instance using Session Manager link below to proceed with the exercise.

In the database lab to be followed, we connect to RDS database using the IAM role granted to the web server. Therefore, refer to Accessing Linux instance using Session Manager to assign IAM role to EC2 instance and connect to your Linux instance using Session Manager

Create a custom AMI

In the AWS EC2 console, you can create an Custom AMI to meet your needs. This can then be used for future EC2 instance creation. In this page, let’s create an AMI using the web server instance that we built earlier.

1. In the EC2 console, select the instance that we made earlier in this lab, and click Actions > Image and templates > Create Image.

1. In the Create Image console, type as shown below and press Create image to create the custom image.

1. Verify in the console that the image creation request in completed.

2. In the left navigation panel, Click the AMIs button located under IMAGES. You can see that the Status of the AMI that you just created. It will show either Pending or Available.

Terminate the instance

Custom AMI (Golden Image) creation has been completed for the auto scaling by using the EC2 instance you just created. Therefore, the EC2 instance currently running is no longer needed, so let’s try to terminate it. ( In Deploy auto scaling web service, we will use custom AMI to create a new web server.)

Do not terminate the “Web server for custom AMI” Instance until the AMI creation process is fully completed. Ensure the AMI status shows as Available before proceeding.

1. In the left navigation panel of the EC2 dashboard, select Instances. Then select the instance that should be deleted. From there, click Instance state -> Terminate instance.

1. When the alert message appears, click Terminate to delete.

1. The instance status changes to Shutting down. After that, the instance status turned to terminated. The instance deletion is complete. You may see the instance for a short period of time for deletion logging.

Architecture Configured So Far

If you mark the resources that have been configured so far in conceptual terms, it is same with the picture below.

Congratulations! You have successfully created a Custom AMI (Golden Image) using the EC2 web server, which can be utilized for deploying an auto-scaling web service in the next section.

Deploy auto scaling web service

Using the network infrastructure created in the Network- AMazon VPC lab, we will deploy a web service that can automatically scale out/in under load and ensure high availability. We use the web server AMI created in the previous chapter and the network infrastructure named VPC-Lab.

Configure Application Load Balancer

AWS Elastic Load Balancer supports three types of load balancers: Application Load Balancer, Network Load Balancer, and Gateway Load Balancer. In this lab, you will configure and set up the Application Load Balancer to handle load balancing HTTP requests.

1. From the EC2 Management Console in the left navigation panel, click Load Balancers under Load Balancing. Then click Create Load Balancer. In the Select load balancer type, click the Create button under Application Load Balancer.

1. Name the load balancer. In this case, name Name as Web-ALB. Leave the other settings at their default values.

It is a best practice to deploy resources across multiple Availability Zones for fault tolerance and high availability.

1. Scrolling down a little bit, there is a section for selecting availability zones. First, Select the VPC-Lab-vpc created previously. For Availability Zones select the 2 public subnets that were created previously. This should be Public Subnet for ap-northeast-2a and Public Subnet C for ap-northeast-2c.

1. In the Security groups section, click the Create new security group hyperlink. Enter web-ALB-SG as the security group name and check the VPC information. Scroll down to modify the Inbound rules. Click the Add rule button and select HTTP as the Type and Anywhere-IPv4 as the Source. And create a security group.

1. Return to the load balancer page again, click the refresh button, and select the web-ALB-SG you just created. Remove the default security group.

1. In Listeners and routing column, click Create target group. Put Web-TG for Target group name and check all settings same with the screen below. After that click Next button.

1. This is where we would register our instances. However, as we mentioned earlier, there are not instances to register at this moment. Click Create target group.

1. Again, move into the Load balancers page, click refresh button and select Web-TG. And then Click Create load balancer.

Configure launch template

Now that ALB has been created, it’s time to place the instances behind the load balancer. To configure an Amazon EC2 instance to start with Auto Scaling Group, you can use Launch Template, Launch Configuration, or EC2 Instance. In this workshop, we will use the Launch Template to create an Auto Scaling group.

The launch template configures all parameters within a resource at once, reducing the number of steps required to create an instance. Launch templates make it easier to implement best practices with support for Auto Scaling and spot fleets, as well as spot and on-demand instances. This helps you manage costs more conveniently, improve security, and minimize the risk of deployment errors.

The launch template contains information that Amazon EC2 needs to start an instance, such as AMI and instance type. The Auto Scaling group refers to this and adds new instances when a scaling out event occurs. If you need to change the configuration of the EC2 instance to start in the Auto Scaling group, you can create a new version of the launch template and assign it to the Auto Scaling group. You can also select a specific version of the launch template that you use to start an EC2 instance in the Auto Scaling group, if necessary. You can change this setting at any time.

Create security group

Before creating a launch template, let’s create a security group for the instances created through the launch template to use.

1. From the left navigation panel of the EC2 console, select Security Groups under the Network & Security heading and click Create Security Group in the upper right corner.

Scroll down to modify the Inbound rules. First, select the Add rule button to add the Inbound rules, and select HTTP in the Type. For Source, type ALB in the search bar to search for the security group created earlier Web-ALB-SG. This will configure the security group to only receive HTTP traffic coming from ALB.

1. Leave outbound rules’ default settings and click Create Security Group to create a new security group. This creates a security group that allows traffic only for HTTP connections (TCP 80) that enter the instance via ALB from the Internet.

Create launch template

1. In the EC2 console, select Launch Templates from the left navigation panel. Then click Create Launch Template.

1. Let’s proceed with setting up the launch template step by step. First, set Launch template name and Template version description as shown below, and select Checkbox for Provide guidance in Auto Scaling guidance. Select this checkbox to enable the template you create to be utilized by Amazon EC2 Auto Scaling.

1. Scroll down to set the launch template contents. In Amazon Machine Image(AMI), set the AMI to Web Server v1, which was created in the previous EC2 lab. You can find it by typing Web Server v1 in the search section, or you can scroll down to find it in the My AMI section. Next, select t2.micro for the instance type. We are not going to configure SSH access because this is only for Web service server. Therefore, we do not use key pairs.

1. Leave the other parts as default. Let’s take a look at the Network Settings section. In security group dropdown, find and apply ASG-Web-Inst-SG created before.

1. Follow the Storage’s default values without any additional change. Go down and define the Instance tags. Click Add tag and Name for Key and Web Instance for Value. Select Resource types as Instances and Volumes.

1. Finally, in the Advanced details tab, set the IAM instance profile to SSMInstanceProfile. If IAM role was not created earlier, refer Create an IAM instance profile for Systems Manager to create the SSMInstanceProfile IAM role.

Leave all other settings as default, and click the Create launch template button at the bottom right to create a launch template.

1. After checking the values set in Summary on the right, click Create launch template to create a template.

Set Auto Scaling Group

Now, let’s create the Auto Scaling Group.

1. Enter the EC2 console and select Auto Scaling Groups at the bottom of the left navigation panel. Then click the Create Auto Scaling group button to create an Auto Scaling Group.

1. In [Step 1: Choose launch template or configuration], specify the name of the Auto Scaling group. In this workshop, we will designate it as Web-ASG. Then select the launch template that you just created named Web. The default settings for the launch template will be displayed. Confirm and click the lower right Next button.

1. Next, proceed to set up load balancing. First, select Attach to an existing load balancer. Then in Choose a target group for your load balancer, select Web-TG created during in ALB creation. At the Monitoring, select Check box for Enable group metrics collection within CloudWatch. This allows CloudWatch to see the group metrics that can determine the status of Auto Scaling groups. Click the Next button at the bottom right.

1. In the step of Configure group size and scaling policies, set scaling policy for Auto Scaling Group. In the Group size column, specify Desired capacity and Minimum capacity as 2 and Maximum capacity as 4. Keep the number of the instances to 2 as usual, and allow scaling of at least 2 and up to 4 depending on the policy.

1. In the Scaling policies section, select Target tracking scaling policy and type 30 in Target value. This is a scaling policy for adjusting the number of instances based on the CPU average utilization remaining at 30% overall. Leave all other settings as default and click the Next button in the lower right corner.

1. We will not Add notifications. Clcik the Next button to move to the next step. In the Add tags step, we will simply assign name tag. Click Add tag, type Name in Key, ASG-Web-Instance in Value, and then click Next.

1. Now we are in the final stage of review. After checking the all settings, click the Create Auto Scaling Group button at the bottom right.

2. Auto Scaling group has been created. You can see the Auto Scaling group created in the Auto Scaling group console as shown below.

1. Instances created through the Auto Scaling group can also be viewed from the EC2 Instance menu.

Architecture Configured So Far

Now, we’ve built a web service that is high available and automatically scales under load! The configuration of the services we have created so far is as follows.

Congratulations! You successfully deployed a scalable and highly available web service using an Application Load Balancer, security groups, launch template, and Auto Scaling group.

Check web service and test

Now, let’s test the service you have configured for successful operation. First, let’s check whether you can access the website normally and whether the load balancer works, and then load the web server to see if Auto Scaling works.

Check web service and load balancer

1. To access through the Application Load Balancer configured for the web service, click the Load Balancers menu in the EC2 console and select the Web-ALB you created earlier. Copy DNS name from the basic configuration.

1. Open a new tab in your web browser and paste the copied DNS name. You can see that web service is working as shown below. For the figure below, you can see that the web instance placed in ap-northeast-2a is running this web page.

1. If you click the refresh button here, you can see that the host serving the web page has been replaced with an instance of another availability zone area (ap-northeast-2c) as shown below. This is because routing algorithms in ALB target groups behave Round Robin by default.

1. Currently, in the the Auto Scaling group, scaling policy’s baseline has been set to 30% CPU utilization for each instance.

• If the average CPU utilization of an instance is less than 30%, Reduce the number of instances.

• If the average CPU utilization of an instance is over 30%, Additional instances will be deployed, load will be distributed, and adjusted to ensure that the average CPU utilization of the instances is 30%.

1. Now, let’s test load to see whether Auto Scaling works well. On the web page above, click the LOAD TEST menu. The web page changes and the applied load is visible. Click on the logo at the top left of the page to see that each instance is under load.

• Before load:

The principle that causes CPU load is that when the CPU Idle value is over 50, the PHP code operates every five seconds to create, compress, and decompress arbitrary files. Traffic is distributed and operated by the ALB, so the load is applied to other instances continuously.

1. Enter Auto Scaling Groups from the left side menu of the EC2 console and click the Monitoring tab. Under Enabled metrics, click EC2 and set the right time frame to 1 hour. If you wait for a few seconds, you’ll see the CPU Utilization (Percent) graph changes.

1. Wait for about 5 minutes (300 seconds) and click the Activity tab to see the additional EC2 instances deployed according to the scaling policy.

2. When you click on the Instance management tab, you can see that two additional instances have sprung up and a total of four are up and running.

3. If you use the ALB DNS that you copied earlier to access and refresh the web page, you can see that it is hosting the web page in two instances that were not there before. The current CPU load is 0% because it is a new instance. It can also be seen that each of them was created in a different availability zone. If it’s not 0%, it can look more than 100% because it’s a constant load situation.

So far, we’ve checked that Auto Scaling group is working through a load test on the web service. If the page that causes the CPU load is working, close the page to prevent additional load.

Database — Amazon Aurora

Create VPC security group

The RDS service uses the same security model as EC2. The most common usage format is to provide data as a database server to an EC2 instance operating as an applicatiojn server within the same VPC, or to configure it to be accessible to the DB Application client outside of the VPC. The VPC Security Group must be applied for proper access control.

In the previous Compute — Amazon EC2 lab, we created web server EC2 instances using Launch Template and Auto Scaling Group. These instances use Launch Template to apply the security group ASG-Web-Inst-SG . Using this information, we will create a security group so that only web server instances within the Auto Scaling Group can access RDS instances.

1. On the left side of the VPC dashboard, select Security Groups and then select Create Security Group.

2. Enter Security group name and Description as shown below. Choose the VPC that was created in the first lab. It should be named VPC-Lab.

Following the principle of least privilege, it is a best practice to allow inbound traffic to your database only from trusted sources, such as your application servers.

1. Scroll down to the Inbound rules column. Click Add rule to create a security group policy that allows access to RDS from the EC2 Web servers that you previously created through the Auto Scaling Group. Under Type, select MySQL/Aurora The port range should default to 3306. The protocol and port ranges are automatically specified. The Source type entry can specify the IP band (CIDR) that you want to allow acces to, or other security groups that the EC2 instances to access are already using. Select the security group(named ASG-Web-Inst-SG ) that is applied to the web instances of the Auto Scaling group in the Compute — Amazon EC2

1. When settings are completed, click Create Security Group at the bottom of the list to create this security group.

Create RDS instance

Since the security group that RDS will use has been created, let’s create an instance of RDS Aurora (MySQL compatible).

1. In the AWS Management console, go to the RDS (Relational Database Service) .

1. Select Create Database in dashboard to start creating a RDS instance.

1. You want to select the RDS instances’ database engine. In Amazon RDS, you can select the database engine based on open source or commercial database engine. In this lab, we will use Amazon Aurora with MySQL-compliant database engine. Select Standard Create in the choose a database creation method section. Set Engine type to Aurora (MySQL Compatible), Set Version to Aurora (MySQL 5.7) 2.11.4.

1. Select Production in Template. Under Settings, we want to specify administrator information for identifying the RDS instances. Enter the information as it appears below.

For production workloads, it is a best practice to enable high availability and fault tolerance by creating read replicas in different Availability Zones.

1. Under DB instance size select Memory Optimized class. Under Availability & durability select Create an Aurora Replica or reader node in a different AZ. Select db.r5.large for instance type.

It is a best practice to deploy databases within a private subnet of a VPC for better security and network isolation

1. Set up network and security on the Connectivity page. Select the VPC-Lab that you created earlier in the Virtual private cloud (VPC) and specify the subnet that the RDS instance will be placed in, public access, and security groups. Enter the information as it appears below.

1. Scroll down and click Additional configuration. Set database options as shown below. Be aware of the uppercase and lowercase letters of Initial database name.

1. Subsequent items such as Backup, Entry, Backtrack, Monitoring, and Log exports all accept the default values, and press Create database to create a database.

2. A new RDS instance is now creating. This may take more than 5 minutes. You can use an RDS instance when the DB instance’s status changed to Available.

Architecture Configured So Far

The configuration of the services we have created so far is as follows.

Connect RDS with Web App server

The Web Server instance that you created in the previous computer lab contains code that generates a simple address book to RDS. The Endpoint URL of the RDS must be verified first in order to use the RDS on the EC2 Web Server.

Storing RDS Credentials in AWS Secrets Manager

The web server we built includes sample code for our address book. In this lab, you specify which database to use in the sample code and how to connect it. We will store that information in AWS Secrets Manager.

In this chapter, we will create a secret containing data connection information. Later, we will give the web server the appropriate permission to retrieve the secret.

1. In the console window, open AWS Secrets Manager (https://console.aws.amazon.com/secretsmanager/ ) and click the Store a new secret button.

It is a best practice to store database credentials and other sensitive information securely using AWS Secrets Manager, instead of hard-coding them in application code.

1. Under Secret Type, choose Credentials for Amazon RDS database. Write down the user name and password you entered when creating the database. And under Database select the database you just created. Then click the Next button.

1. Name your secret, mysecret. The sample code is written to ask for the secret by this specific name. Click Next.

1. Leave Secret rotation at default values. Click Next.

1. Review your choices. Click Store.

1. You can check the list of secret values with the name mysecret as shown below.

1. Click mysecret hyperlink and find Secret value tab. And click Retrieve secret value button.

1. Click Edit button, and check whether there is dbname and immersionday in key/value section. If they were not, click Add button, fill out the value and click save button.

Access RDS from EC2

Now that you have created a secret, you must give your web server permission to use it. To do this, we will create a Policy that allows the web server to read a secret. We will add this policy to the Role you previously assigned to the web server.

Allow the web server to access the secret

To follow the principle of least privilege, it is a best practice to grant the minimum required permissions to resources. In this case, you will grant permissions for the web server instances to access the specific secret containing the database credentials.

1. Sign in to the AWS Management Console and open the IAM console . In the navigation pane, choose Policies, and then choose Create Policy.

1. Click Choose a service.

1. Type Secrets Manager into the search box. Click Secrets Manager.

1. Under Access level, click on the carat next to Read and then check the box by GetSecretValue.

1. Click on the carat next to Resources. For this lab, select All resources. Click Next: Tags.

For the lab, we’re allowing EC2 to access all secrets. With a real workload, you should consider allowing access to specific secrets.

1. Click Next: Review.

1. On the Review Policy screen, give your new policy the name ReadSecrets. Click Create policy.

1. In the navigation pane, choose Roles and type SSMInstanceProfile into the search box. This is the role you created previously in Connect to your Linux instance using Session Manager. Click SSMInstanceProfile.

1. Under Permissions policies, click Attach policies.

1. Search for the policy you created called ReadSecrets. Check the box and click Attach policy.

1. Under Permissions policies, verify that AmazonSSMManagedInstanceCore and ReadSecrets are both listed.

Try the Address Book

1. Access the EC2 Console window and click load balancer. After copying the DNS name of the load balancer created in the compute lab, open a new tab in your browser and paste it.

1. After connecting to the web server, go to the RDS tab.

1. Now you can check the data in the database you created.

This is a very basic exercise in interacting with a MySQL database managed by AWS. RDS can support much more complex relational database scenarios, but hopefully this simple example will make the point clear. You are free to add/edit/delete content from the RDS database using the Add Contact, Edit and Remove links in the address book.

Architecture Configured So Far

Now, with the work done so far, you have built a web service with guaranteed high availability. The infrastructure architecture we have constructed so far is as follows.

RDS Management Features

In multiple AZ deployments, Amazon RDS automatically provisions and maintains synchronous spare replicas in different availability zone. The default DB instance is synchronized from the availability zone to the spare replica to provide data redundancy.

RDS Failover Tests

When multiple AZs are enabled, Amazon RDS automatically switches to a spare replica in another availability zone if the DB instance has a planned or unplanned outage. The amount of time that failover takes to complete depends on the database activity and other conditions when the default DB instance becomes unavailable. The time required for failover is typically 60–120 seconds. However, if the transaction is large or the recovery process is complex, the time required for failover can be increased. When failover is complete, the RDS console UI takes additional time to reflect in the new availability zone.

1. From the RDS management console, select Databases, select the instance that you want to proceed with the failover, and click Failover in the task menu.

1. A message asking whether you’re going to failover the rdscluster. Press the Failover button.

1. The refresh button changes the status of rdscluster in the DB identifier to Failing-over. In a few minutes, press the Refresh button to see Reader and Writer roles changed. The failover is complete.

Create RDS Snapshot

Let’s take a snapshot of the RDS in production. Snapshot can be created at any frequency for backup to database instances, and the database can be restored at any time based on the snapshots created.

1. From the RDS management console, select Databases, and Select the instance on which you want to perform the snapshot operation. Select Actions > Take snapshot in the upper right corner.

1. Type the name you want to use for the snapshot as immersionday-snapshot. Press the Take Snapshot button to complete the creation.

1. From the left RDS menu, select Snapshots and check the creation status of the snapshot. The state of the snapshot is the first creating state, and you can use that snapshot to restore the database when state become available. To restore, select the snapshot and select Actions to see what you can do with that snapshot. Restore Snapshot allows you to create RDS instances with the same data based on snapshots taken. This lab will not perform a restore.

Change RDS Instance Type

Scale-Up/Scale-Down of RDS instances can be done very simply through the RDS Management Console.

1. Let’s change the specification of the RDS instance by selecting the instance you want to change and clicking Modify.

2. You can select the specification of the instance that you want to change by selecting the list box of instance classes. Let’s choose db.r6g.large here.

3. Scroll to the bottom and select Continue to go to the page where you check the instance’s current value and new value and select when to apply.

4. Select Apply immediately. In this case, RDS changes its instance immediately after perform a back up task. Then click Modify DB Instance. Depending on the type of instance and the amount of data to back up, it can take several minutes. Therefore, you should expect a certain amount of downtime for RDS services(Redundant configuration minimizes downtime).

In case of selecting Apply during the next scheduled maintenance window, make the change in the user’s Maintenance Window, which is specified on a weekly basis.

1. You can see that the status of the instance has changed to Modifying.

2. When you click refresh button again, you can see that the Writer instance has changed. This is because the instance you selected earlier for the size change was the Writer instance. RDS minimizes downtime through failover before resizing. If you wait a moment, you will see that the change to Available status has been completed as shown below.

RDS can change the size of the instance at any time. However, the size of the database does not support shrink after scaling up.

Connect RDS Aurora

Let’s try to make an RDS connection through MySQL CLI, which is used for general database management/operation.

To do this,

1. Create an EC2 instance with the AMI created in Public Subnet within the VPC-Lab. The networking option should allow Public IP.

2. Changes the security group settings for RDS Aurora. Configure the newly created EC2 instance to accept security groups as sources.

3. Log in to the EC2 instance you just created with SSH, and connect to RDS Aurora through the MySQL Client. The EC2 web server already has MySQL client installed during EC2 deployment.

Organizing the above items will be a challenge. Once the setup is successful, you can connect to the CLI environment and perform mysql commands as shown below.

$ ssh -i AWS-ImmersionDay-Lab.pem ec2-user@”EC2 Host FQDN or IP”
Last login: Sun Feb 18 14:41:59 2018 from 112.148.83.236

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/


$ mysql -u awsuser -pawspassword -h awsdb.ccjlcjlrtga1.ap-northeast-2.rds.amazonaws.com

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 34
Server version: 5.6.10 MySQL Community Server (GPL)


Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| immersionday       |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.01 sec)

mysql> use immersionday;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+------------------------+
| Tables_in_immersionday |
+------------------------+
| address                |
+------------------------+
1 row in set (0.01 sec)

mysql> select * from address;
+----+-------+--------------+---------------------+
| id | name  | phone        | email               |
+----+-------+--------------+---------------------+
|  1 | Bob   | 630-555-1254 | [e-mail] |
|  2 | Alice | 571-555-4875 | [e-mail]   |
+----+-------+--------------+---------------------+
2 rows in set (0.00 sec)

mysql>

Storage — Amazon S3

Create Bucket on S3

All objects in Amazon S3 are stored within a bucket. You must create a Bucket before storing data on Amazon S3.

Create Bucket

1. From the AWS Management Console, connect to S3 . Press Create bucket to create a bucket.

It is a best practice to use S3 Bucket Policy and Access Control Lists (ACLs) to control access to your S3 buckets and objects, following the principle of least privilege.

1. Enter a unique bucket name in the Bucket name field. For this lab, type immersion-day-user_name, substituiting user-name with your name. All bucket names in Amazon S3 have to be unique and cannot be duplicated. In the Region drop-down box, specify the region to create the bucket. In this lab, select the region closest to you. The images will show the Asia Pacific (Seoul) region. Object Ownership change to ACLs enabled. Bucket settings for Block Public Access use default values, and select Create bucket in the lower right corner.

Bucket names must comply with these rules:

• Can contain lowercase letters, numbers, dots (.), and dashes (-).

• Must start with a number or letter.

• Can be specified from a minimum of 3 to a maximum of 255 characters in length.

• Cannot be specified in the format like the IP address (e.g., 265.255.5.4).

There may be additional restrictions depending on the region in which the bucket is created. The name of the bucket cannot be changed once it is created and is included in the URL to specify objects stored within the bucket. Please make sure that the bucket you want to create is named appropriately.

1. A bucket has been created on Amazon S3.

There are no costs incurred for creating bucket. You pay for storing objects in your S3 buckets. The rate you’re charged depends on the region you are using, your objects’ size, how long you stored the objects during the month, and the storage class. There are also per-request fees. Click for more information

Adding objects to buckets

If the bucket has been created successfully, you are ready to add the object. Objects can be any kind of file, including text files, image files, and video files. When you add a file to Amazon S3, you can include information about the permissions and access settings for that file in the metadata.

Adding objects for static Web hosting

This lab hosts static websites through S3. The static website serves as a redirect to an instance created by the VPC Lab when you click on a particular image. Therefore, prepare one image file, one HTML file, and an ALB DNS name.

1. Download the image file aws.png and save it as aws.png.

   1. Write index.html using the source code below.

<html>
        <head>
            <meta charset="utf-8">
            <title> AWS General Immersion Day S3 HoL </title>
        </head>
        <body>
            <center>
            <br>
            <h2> Click image to be redirected to the EC2 instance that you created </h2>
            <img src="{{Replace with your S3 URL Address}}" onclick="window.location='DNS Name'"/>
            </center>
        </body>
    </html>

1. Upload the aws.png file to S3. Click S3 Bucket that you just created.

1. Click the Upload button. Then click the Add files button. Select the pre-downloaded aws.png file through File Explorer. Alternatively, place the file in Drag and Drop to the screen.

1. Check the file information named aws.png to upload, then click the Upload button at the bottom.

1. Check the URL information to fill in the image URL in index.html file. Select the uploaded aws.png file and copy the Object URL information from the details on the right.

1. Paste Object URL into the image URL part of the index.html. Then specify the ALB DNS Name of the load balancer created by Deploy auto scaling web service to redirect to ALB when you click on the image.

1. Upload the index.html file to S3 following the same instructions as you did to upload the image.

1. If you check the objects in your S3 bucket, you should see 2 files.

Congratulations! You have successfully created an S3 bucket and uploaded objects into it.

View objects

Now that you’ve added an object to your bucket, let’s check it out in your web browser.

View Objects

1. In the Amazon S3 Console, please click the object you want to see. You can see detailed information about the object as shown below.

By default, all objects in the S3 bucket are owner-only(Private). To determine the object through a URL of the same format as https://{Bucket}.s3.{region}.amazonaws.com/{Object}, you must grant Read permission for external users to read it. Alternatively, you can create a signature-based Signed URL that contains credentials for that object, allowing unauthorized users to access it temporarily.

1. Return to the previous page and select the Permissions tab in the bucket. To modify the application of Block public access (bucket settings), press the right Edit button.

1. Uncheck box and press the Save changes button.

1. Enter confirm in the bucket's Edit Block public access pop up window and press the Confirm button.

1. Click the Objects tab, select the uploaded files, click the Action drop-down button, and press the Make public button to set them to public.

1. When the confirmation window pops up, press the Make public button again to confirm.

It is a best practice to periodically review and audit the permissions and access settings for your S3 buckets and objects to ensure they align with your security requirements and the principle of least privilege.

1. Return to the bucket page, select index.html, and click the Object URL link in the Show Details entry.

1. When you access the HTML object file object URL, the following screen is printed.

1. When you click on an image, it is redirected to the instance’s web page you created.

Enable Static Web Site Hosting

You can use Amazon S3 to host static websites.

Static Web Site Settings

A static website refers to a website that contains static content (HTML, image, video) or client-side scripts (Javascript) on a web page. In contrast, dynamic websites require server-side processing, including server-side scripts such as PHP, JSP, or ASP.NET. Server-side scripting is not supported on Amazon S3. If you want to host a dynamic website, you can use other services such as EC2 on AWS.

1. In the S3 console, select the bucket you just created, and click the Properties tab. Scroll down and click the Edit button on Static website hosting.

1. Activate the static website hosting function and select the hosting type and enter the index.html value in the Index document value, then click the save changes button.

1. Click Bucket website endpoint created in the Static website hosting entry to access the static website.

1. This allows you to host static websites using Amazon S3.

Move objects

You have seen the ability to add objects to buckets and verify them so far. Now, let’s see how we can move objects to different buckets or folders.

Move Objects

1. Create a temporary bucket for moving objects between buckets (Bucket name: immersion-day-myname-target). Substitute myname with your name. Rememeber the naming rules for the bucket. Block all public access Uncheckbox for quick configuration.

1. Check the notification window below and select Create bucket.

1. In the Amazon S3 Console, select the bucket that contains the object (the first bucket you created) and click the checkbox for the object you want to move. Select the Actions menu at the top to see the various functions you can perform on that object. Select Move from the listed features.

1. Select the destination as bucket, then click the Browse S3 button to find the new bucket you just created.

1. Click the bucket name in the pop-up window, then select the destination (arrival) bucket. Click the Choose destination button.

1. Check that the object has moved to the target bucket.

Even though you move an object, its existing permissions remain intact.

Enable Bucket versioning

You can use Bucket Versioning if you want to update existing files to the latest version within the same bucket, but still want to keep the existing version.

It is a best practice to enable versioning on your S3 buckets to protect against accidental deletion or overwrites of objects, and to maintain a history of changes to your data.

Enable versioning

1. In the Amazon S3 Console, select the first S3 bucket we created. Select the Properties menu. Click the Edit button in Bucket Versioning.

1. Click the enable radio button on Bucket Versioning, then click Save changes.

1. In this lab, the index.html file will be modified and re-uploaded with the same name. Make some changes to the index.html file. Then upload the modified file to the same S3 bucket.

2. When the changed file is completely uploaded, click the object in the S3 Console. You can view current version information by clicking the Versions tab on the page that contains object details.

Congratulations on your progress! You’ve successfully learned how to add and verify objects in Amazon S3 buckets, move objects between buckets or folders, and utilize bucket versioning to update files while preserving existing versions.

Deleting objects and buckets

You can delete unnecessary objects and buckets to avoid unnecessary costs.

1. In the Amazon S3 Console, select the Bucket that you want to delete. Then click Delete. A dialog box appears for deletion.

1. There is a warning that buckets cannot be deleted because they are not empty. Select empty bucket configuration to empty buckets.

1. Empty bucket performs a one-time deletion of all objects in the bucket. Confirm by typing permanently delete in the box. Then click the Empty button.

1. Now the bucket is empty. Perform task 1 again. Enter a bucket name and press the Delete bucket button.

Congratulations!! You have completed all the workshop. Thank you for your efforts.

Clean up resource

If you participated in an AWS event using an AWS-provisioned account, no cleanup is necessary. However, if you completed this workshop with your own account, we strongly recommend following this guide to delete the resources and avoid incurring costs

Delete the resources you created for the lab in reverse order.

Database

Delete an Amazon RDS Cluster

1. After accessing to the Amazon RDS console, select DB Instances.

1. By default, an Amazon RDS cluster has delete protection enabled to prevent accidental deletions. To disable it, select the Cluster and click the Modify button.

1. Uncheck the Enable deletion protection button and click the Continue button.

2. For immediate deletion, select Apply immediately and click the Modify cluster button.

3. In order to delete a DB Cluster, you must first delete the DB instances included in the cluster. They can be deleted in any order, but we will delete the Writer instance first. Select the Writer instance, and click the Delete button on the Actions menu.

1. Type delete me in the blank and click the Delete button.

2. This time, we will delete the Reader instance. Select the Reader instance and click the Delete button on the Actions menu.

3. Type delete me in the blank and click the Delete button.

4. Lastly, we will delete the DB Cluster. Click the Delete button on the Actions menu.

5. Uncheck the Take a final snapshot button, check the I acknowledge that automatic backups, including system snapshots and point-in-time recovery, are no longer available when I delete an instance button, and type delete me in the blank. Click Delete DB Cluster and the DB cluster will be deleted.

Delete a Amazon RDS Snapshot

1. To delete the snapshot of the DB Cluster created during the lab, select immersionday-snapshot and click the Delete snapshot button on the Actions menu.

2. Click the Delete button.

Delete a secret in AWS Secrets Manager

1. We’re going to delete the secret that stored a RDS credential during the lab. Type Secrets Manager in the AWS console search bar and then select it.

2. Select mysecret.

3. Click Delete secret on the Actions menu.

4. To prevent accidental deletion of secrets, AWS Secrets Manager has a deletion wait time of minimum 7 days and maximum 30 days. Enter the minimum time of 7 days and press the Schedule deletion button.

Compute

Delete an Auto Scaling Group

1. We’re going to delete the Auto Scaling Group that we used during the lab. Type EC2 in the AWS Console search bar and select it. Select Auto Scaling Groups from the left menu. Select the Web-ASG that we created in the lab and click the Delete button on the Actions menu.

2. Type delete in the blank and click the Delete button.

Delete an Application Load Balancer

1. Next, we’re going to delete the Application Load Balancers. Select Load Balancers from the left menu. Then select the Web-ALB that we created in the lab and click the Delete load balancer button in the Actions menu.

2. Type confirm in the blank and click the Delete button.

Delete a Target Group

1. We’re going to delete the Target Group we created when we created the Application Load Balancer. Select Target Groups from the left menu. Select the Target Group we created in the lab, web-TG, and click the Delete button on the Actions menu.

2. Click the Yes, delete button.

Delete EC2 AMIs

1. Select AMIs from the left menu. Select the AMI named Web Server v1 that you created in the lab. Click the Deregister AMI button on the Actions menu.

2. Click the Deregister AMI button.

Delete EC2 Snapshots

1. You’ve just deleted an AMI, but this action doesn’t automatically remove the associated snapshot. So you need to remove it manually. From the left menu, choose Snapshots. Be sure to note the snapshot’s creation date. Then, select the snapshot you created in the lab, and click the Delete snapshot button on the Actions menu.

2. Click the Delete button.

3. Select Launch Templates from the left menu. Select the template named Web that you created in the lab. Click the Delete template button on the Actions menu.

4. Type Delete in the blank and click the Delete button.

(Optional) Delete an EC2 instance

1. If you went through the (Optional) Connect RDS Aurora section during the database lab, you need to delete the EC2 instance you created in the lab. Select Instances **from the left menu. Select the EC2 instance you created during the lab, and click the **Terminate instance **button on the **Instance state menu.

2. Click the Terminate button.

Network

Delete VPC endpoints

1. You’re almost there. Type VPC in the AWS Console search bar and select it. Select Endpoints from the left menu. Select S3 endpoint, the endpoint you created in the lab, and click the Delete VPC endpoints button on the Actions menu.

2. Type delete in the blank, and click the Delete button.

Delete a NAT gateway

1. Select NAT gateways from the left menu and select VPC-Lab-nat-public you created during the lab. Click the Delete NAT gateway button on the Actions menu.

2. Type delete in the blank and click the Delete button.

Delete an Elastic IP

1. You’ve just deleted the NAT gateway, but this action doesn’t automatically delete the Elastic IP that the NAT gateway used, so you need to remove it manually. Select Elastic IPs from the left menu, and select VPC-Lab-eip-ap-northeast-2a. (The name after VPC-Lab-eip may vary depending on your region.) Click the Release Elastic IP addresses button on the Actions menu. If it says it is still associated with the NAT gateway and cannot be deleted, refresh the webpage and try again.

2. Click the Release button.

Delete a Security Group

1. We’re going to delete the Security Group you created during the lab. Select Security Groups from the left menu. Select Immersion Day — Web Server and DB-SG first, and then click the Delete security groups button on the Actions menu. The reason for not deleting all security groups at once is that some security groups reference other security groups in their inbound rules. A security group that is being referenced cannot be deleted until the security group that is referencing it is deleted. Therefore, delete the security groups in the following order: Immersion Day — Web Server, DB-SG -> ASG-Web-Inst-SG -> web-ALB-SG.

2. Type delete in the blank and click the Delete button.

3. Select ASG-Web-Inst-SG and click the Delete security groups button on the Actions menu.

4. Click the Delete button.

5. Select web-ALB-SG and click the Delete security groups button on the Actions menu.

6. Click the Delete button.

Delete a VPC

1. Finally, select Your VPCs from the left menu, and select the VPC-Lab-vpc that you created during the lab. Click the Delete VPC button in the Actions menu.

2. Type delete in the blank and click the Delete button.

We strongly recommend that you double-check to make sure you haven’t missed anything, as some resources that weren’t cleared may incur costs.

Conclusion

This project demonstrates the power of AWS for building scalable, resilient applications with best practices in networking, compute, database, and storage services. From implementing VPC security to auto-scaling EC2 instances and configuring a fault-tolerant Aurora database, this architecture is well-suited for real-world applications that demand reliability and flexibility.

Explore my GitHub repository.

Shubham Murti — Aspiring Cloud Security Engineer | Weekly Cloud Learning !!

Let’s connect: Linkdin, Twitter, Github