Securing the bag… Moving the bank’s web front to AWS.

I’m currently in a program called Level Up In Tech to develop and secure DevOps skills. I am enjoying being in the program. Being only 2 weeks in, they’ve assigned me a project. As my project for my course in Level Up In Tech, I took the approach of being contacted to move a bank’s front-end website from on-premise to the AWS cloud.

I was approached by Level Up Bank out of New York who had a little situation with costs of hosting their website. Their current method was hosting it from their data center and were looking to save money and compute resources in their infrastructure. Their plan was going to the cloud in order to take advantage of the scalability and high availability of the resources that cloud providers like AWS offer.

In our discussion, we decided to at first go with hosting the front end in a AWS S3 bucket.

1. Using S3 is cheaper than moving the migrating the entire front end instance to an AWS EC2 instance since with EC2 will charge for management (man hours, instance updating, etc.), compute, storage and data transfer.
2. Using S3 provides scalability since with more load, S3 can handle the increased load with no downtime.
3. Using S3 will make the site more highly available through redundancy and multiple availability zones.

You might be wondering how I did this?

I’m glad you asked!

First step was to migrate the data from their current front page to an S3 bucket. Since this was more of a proof of concept, I did a mockup of their site in HTML. I then uploaded it to an S3 bucket (in this case — bucket name scj-project11). S3 has the ability to use the contents of a bucket as a static website, so I took advantage of this and enabled the static web function in S3, setting the default html file to be the file I uploaded — index.html

This is the site URL generated by AWS: http://scj-project1.s3-website-us-east-1.amazonaws.com

From there, I wanted to verify that the html would render properly from the S3 bucket, so I disabled the default “Block All Public Access” policy to be able to have the site render.

Unselecting the Block All Public Access and pressing Save Changes will cause the site to become public.

We will also need to allow the site to be accessed for all users rather than just the Bucket Owner as well. For this, I’ve chosen to use a json blurb to grant the access by adding this blurb to the Bucket Policy under Permissions Bucket Policy:

Code snip — Notice that the Resource name reflects my bucket name so this blurb will Allow (Effect) Public Access to Objects (via the Sid) in this bucket (Resource) via the GetObject action.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPublicAccesstoObjects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::scj-project1/*"
        }
    ]
}

Add it here by pressing edit and pasting over the current contents.

Select Save Changes and then I tested the access.

Access and display from S3 link shows successful, except one thing. Note that the URL is http and not https and the Vivaldi browser notes that the site is “Not Secure”. I wouldn’t want to bank with a entity that wasn’t using encryption.

So I checked and didn’t see an option to enable https and verified that https access was not allowed in this manner by trying to access using the URL above but replacing http with https (note the Not Secure is missing from the url here but nothing displays):

So part of my dilemma is solved. The front end is now hosted by the S3 bucket. But I still need to work on making the site more reliable and with Level Up Bank’s reach going more and more global, I needed something to improve the global connectivity for their site to localize the accessibility of their site.

After speaking with a couple folks about this, the idea of using CloudFront’s content delivery caching mechanism came to the fore front. CloudFront their S3 Hosted Static website. AWS CloudFront is a content delivery network (CDN) service that delivers web content (including images, and videos), to users around the world by caching the content at edge locations, providing users of the web content with low latency and high data transfer speeds. It also has the added benefit of enhanced web security via using Web Application Firewalls (WAFs) and the ability to redirect http traffic to https, using a CloudFront certificate or by using a custom certificate (i.e. one referencing the site/company) should I so configure it.

Back in AWS, I go find CloudFront and create a Distribution, using the S3 bucket’s URL (minus the http:// prefix) as the origin domain name. For simplicity’s sake I didn’t enable WAF, etc.

Notice that the only option I was given to host this was http!! I looked a little further and noted a section named Behaviors and low and behold, there was what I was searching for! A setting to redirect the http traffic to https!!!

After clicking through the setup, I was able to access the web front end page through the CloudFront Distribution Domain Name.

CloudFront: https://d2td234rwz63h7.cloudfront.net

I then verified that redirection from http to https worked via multi-browser test using http://d2td234rwz63h7.cloudfront.net, which redirected to using https. I inspected the certificate on the webpage just to double verify what was being noted:

I went back to verify whether the caching would auto-update (because I actually noted that I didn’t set up anything or notice anything that would autoupdate the cache when S3 updates occurred). I uploaded a new default page to the S3 bucket to see if the changes would show in the CloudFront endpoint and — they didn’t!!

From the S3 link:

From the CloudFront Distribution Domain name:

I did a little further research and noted that if I used the Invalidate functionality in CloudFront, the content of the S3 bucket set to be cached in CloudFront would be recached and thus be live!! So, I tried it out.

I selected Create Invalidation and for the path, I entered /* to have it recache the contents of the S3 web endpoint and selected the Create Invalidation button at the bottom of the page.

Once it listed as completed, I checked the CloudFront Domain Name and saw the following:

Success! Now we have a process that we could use to update the front end (and any other content of the bucket as well).

But we still hvae that pesky original bucket URL that is NOT using encryption. After considering that the content has been replicated and it’s all basically the file that is needed and not the S3 website, I removed access to S3 Static website (i.e. reenabled Block All Public Access) so disable http access to the any version of the site.

I then checked the access to the S3 web URL and encountered the following:

And CloudFront is still publishing the updated site.

The bank is happy with the solution!