Forem: Riyaz Ahmed

Hosting a Static Website on AWS

Riyaz Ahmed — Tue, 27 Jun 2023 14:00:18 +0000

In this blog, I will be writing a step by step guide on how I created a basic / simple static website hosted on AWS:

The first thing we needed to do is to register a domain. This can be done on Route 53. Route 53 is a scalable and highly available domain name system (DNS) web service offered by Amazon Web Services (AWS). It provides domain registration, DNS routing, and health checking capabilities, allowing users to manage and route internet traffic to their applications or resources.

From this service, I was able to register a domain with the name "RiyazsProject.net"

side note
( While most organisations will use .com as it is the most popular, I opted to go for .net, for pricing reasons ఠ_ఠ … )

One small thing to mention, AWS kindly offers to allow auto renewal on a yearly basis as well as informing you that this option is on closer to the renewal period. This is great for large organisations who plan to have their webpage up and running throughout the years. However in this case, I will not be choosing this option.

After some confirmation and verification (and some patience..), we finally have our official domain name registered to "riyazproject.net".

Now that we have our domain, the next step is to create a bucket on S3. Amazon S3 (Simple Storage Service) is a cloud-based storage service provided by Amazon Web Services (AWS). It offers highly scalable, durable, and secure object storage, allowing individuals and businesses to store and retrieve vast amounts of data over the internet. While S3 is widely used for its various purposes such as content storage, data archival and data lakes, in this case we will be using it for hosting a static webpage.

There are a few key things we need to note when creating our bucket. The first being the region the bucket is created in. Due to my location, I will be creating this bucket in EU (London) eu-west-2 in order to reduce latency as much as possible.
The second important thing to mention is allowing public access to my bucket.

Allowing public access as well as checking the box below allows for the contents of my bucket to be accessible to the public. If my bucket was private, it would not allow anyone to access my webpage (which defeats the whole purpose to why we're here...)

Once our bucket has been created, I am now able to add the contents needed in order for my webpage to be accessible. I will first start by adding a basic html file (which I was kindly gifted), into my S3 bucket.
Now that I have the contents within my bucket, I now need to enable the bucket for static website hosting as well as having the right permissions for users to access it. This can be done by going into the properties of the bucket and editing "static website hosting"

The bucket is now successfully able to host a static website, however we aren't done just yet. We still need to configure the permissions settings before we send it off. This can be configured on the permissions tab of the bucket.
We need to attach a bucket policy that will allow users to only READ the contents within the bucket.

The permission in the image above consists of a JSON file that represents an IAM policy that grants public read access to all objects within the S3 bucket named "riyazproject.net". This means that any user or entity, including anonymous users, can retrieve (read) objects from this specified S3 bucket.

Our website is officially hosted on Amazon S3! But we have one small detail left..
Unfortunately, our website has a URL that is provided by AWS, not our custom URL. In order to tackle this, we need to redirect riyazproject.net to this S3 bucket.

To do this, I will return to Route 53 and add an additional record. This ensures the bucket will be connected to the Route 53 domain name.

We start off by choosing an A record type. Next, I opt to use an Alias, this allows me to route traffic to the S3 endpoint. I select Simple routing as it is directed only one way and now the record has been created.

Once the record has been set, our webpage officially has its URL set to the domain!

Thank you very much for reading my blog post. This small project was to showcase my skills and knowledge of AWS. I appreciate you taking the time to read my work. If you used this to create and host your own static webpage, I hope it helped!

Capstone Project - Cloud Architecture

Riyaz Ahmed — Mon, 26 Jun 2023 17:03:56 +0000

The Capstone project is quite a formidable task, making even quite experienced users work hard on how to overcome this scenario.
We find ourselves working at a Social Research organisation that has a website that allows users to look up various data. Over the past few years, the website has grown in popularity and begun experiencing traffic issues as well as complaints about how slow it is. Additionally, there have been attempted ransomware attacks and security breaches. This is where we come in. We are here to design an infrastructure for the company's website that follows best practises and improves upon the existing architecture.

This blog is a record of how I overcame the Capstone project.

What we started with
At the start, we were given a diagram of the current environment and how the company's website was laid out:

This current architecture shows us how the bastion host has been set up as well as its additional security groups placed in multiple subnets.
This current architecture does not follow best practises as it is not highly available or does not scale automatically.

The solution

The solution I came up with not only solves the initial problem of being unable to scale automatically but also makes it more secure and highly available. By storing data within a MySQL RDS Multi-AZ database in a private subnet across multiple availability zones (AZ), it allows for more users around the world to access the website without experiencing traffic delays. Additionally, this meant that this solution had failover, allowing the secondary database to take over if the primary one were to fail or become unavailable.

The Application Load Balancer (ALB) is placed in front of the autoscaling group, which is linked to both applications in each AZ, allowing for a smoother runtime. Admin users would be able to access the applications by using SSH through the bastion host and access or store data.

We start off by downloading a SQL dump file provided by AWS that gives us the necessary tools in order for our applications as well as our databases to run.
We create an internet-facing Application Load Balancer and attach it to two public subnets, as well as attaching the respective security groups. As we were setting up the autoscaling group, which would be behind the ALB, it gave us the option to attach it to both availability zones as well as both subnets (public and private). This would allow the infrastructure to be highly available.

Once the two had been created, it allowed the application to also be created within the process. After configuring the security groups, I was finally able to access the website. However, not only did it not look like a proper website, it was not functioning like one either.

The website would list what users may want to find information about, but it would not be able to list any of the necessary information. The website would return a connection error.

The next step was to create a multi-RDS database. This would allow for a secure and highly available way to store and access data that users could access without experiencing traffic.

note
(I had used a burstable class for this instance as it would allow for performance to exceed regular use if there was a need for it as we were already experiencing traffic issues.)

While the database was being created, I used this time to go into Systems Manager and create the parameters needed in the parameter store:

Once the database was created, it was time to connect to it through the application we created earlier. This was done through the Bastion host and accessing it through the Access Key and Secret Access Key provided by AWS. Upon entering, I was able to import the SQL dump file, which allowed the database to have the data it needed. This was done by listing within the file to ensure that Countrydatadump.sql was inside of it. After the commands mysql -u username -p database_name < file.sql and entering the required password that I had set earlier when creating the RDS database, it was successfully able to ingest all the data it needed.

Upon successfully launching the application, the last thing to do was to check the website one last time and see if users could access the data they were looking for. After all my hard work, it was finally a success.

The Capstone project really pushed me to think outside the box and utilise all the skills I acquired during my journey as a trainee cloud engineer. This was something I had never experienced before, and I look forward to working on more projects like this in the future. I plan to update my blog throughout my career to not only allow readers to see my work but also to use it as a portfolio to show myself and others how I have evolved over the coming years with each project.

I appreciate you taking the time to read this!