Table of contents
Good Morning, Afternoon, Evening, and Night! One thing I would always love to do is build infrastructure in the cloud. Not only does it gives me hands-on skills I can talk about but it also helps me understand why it's needed and even help me with my troubleshooting when I do bump into an error. So in this article we're gonna build a highly available and scalable web application in AWS, I've followed a guide from Immersion Day. Now let's get started!
Networking
The first thing we want to do is create our VPC or VLAN in other words. Best practice to do so before anything else. I used the 10.0.0.0/16 CIDR block just to keep it simple. To make sure our web application is highly available I made two AZs (us-east-1a and us-east-1b) and created two subnets in each, a private subnet and a public one, so just in case one of our EC2 or Database fails another one is up in running.
Our subnets will have a /24 and I also created a NAT gateway in our public subnet so our services can talk to each other.
Now that we have our VPC and Subnets, let's create a VPC Endpoint! Why a VPC Endpoint? well, anything in our private subnet can talk to our S3 bucket securely without using the Internet Gateway which is a public communication. We don't want any sensitive information going through the internet first so why not keep it internal?
There's an awesome medium article Ashish Patel wrote that goes into more detail. You check it out here.
Compute
Now that we have our VPC set up, let's spin up an EC2. The EC2 we want will be Amazon Linux 2. We will be putting the EC2 in the public subnet of our VPC. Also creating a new security group to allow HTTP and SSH traffic from anywhere.
We also want to install a LAMP stack to our EC2 using the user data under the advanced section.
# Install a LAMP stack
amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
yum -y install 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.tar.gz ]; then
cd /var/www/html
wget https://aws-joozero.s3.ap-northeast-2.amazonaws.com/immersion-day-app-php7.tar.gz
tar xvfz immersion-day-app-php7.tar.gz
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
yum -y update
Afterward, we'll connect to the EC2 instance, this is the first problem I ran into. The workshop doesn't tell you the steps needed to connect via session manager so I had to do some research. The first thing you have to do is create an IAM role that gives the EC2 access to the session manager and attach it to the instance. Then you have to manually install an SSM agent on the instance. Here's an article explaining how to install it. Let's use the IP address to see if our web server is working properly.
Now for the most important part, making an AMI image so we can make a template our autoscale can use.
Let's delete our instance now that we have our image and create an application load balancer. We want to launch it in our two public subnets.
Our load balancer doesn't have a security group yet so we'll create one that allows all inbound traffic from port 80.
A target group to listen to on port 80 is needed also.
The last thing on our list for computing is the auto-scaling group but first, let's make our template from the AMI image we made earlier from the instance we destroyed.
I made a new security group for the template to let traffic from the ALB.
Don't forget to attach the SSM manager role we created earlier to the template!
Let's create the auto-scaling group now!
We want our instances in our private subnets in the VPC.
Attach the ALB and enable the group metrics collection.
The whole point of using the ASG is to make sure our web server is highly available, so we need to tell the ASG to create another web server when one CPU average utilization is remaining at 30% overall.
Database
We can't have a web server with no database to house all our data in so let's go ahead and make an RDS with Amazon Aurora with a DB.r5.large and have it in a private subnet. IMPORTANT!! make sure you remember the username and password for the RDS we will need it for the secrets manager.
Before we make the RDS let's make a subnet group to attach the RDS. I did the lab without doing that and had a problem accessing the RDS through the browser.
Now let's create our database!
For the security group with have to make a new one with allows the EC2 instances to talk to the RDS.
Now that our RDS is existing let's configure our secrets manager so that when the web server would like to access the RDS it will gain access, using the sample code given when we configured the user data the web server will know where to look. Make sure in the secret value you add a secret key called "dbname" and the secret value is the name of the database.
And create another policy to attach to our instances so that when the time comes it can access the RDS.
Finally, attach the policy to the SSM instance profile.
Conclusion
I know there's an S3 bucket to create and configure to make static but you can walk through this part and troubleshoot any problems you bump into. I hope this workshop helped some but there's many more you can do!
This website lets you be able to pick which service you would like to have more hands-on with. You do the workshops, take screenshots of your work, and write a blog just like I am and stand out to employers if you are job hunting! could even talk about them in interviews. Or maybe when you studying for AWS certifications and is a hands-on learner like me to understand a topic you can pick a service you struggling with and build it. The possibilities are endless!
I plan on doing more Azure-based labs in the future, and already have the AZ-900 scheduled!
Like always thank you for taking the time to read my blog and I hope this helps someone 😃