V1 Static Website: Get the Get the coffee shop online fast with Amazon S3

Small Intro First

This is the first post of a blog post series called Brewing in the Cloud: A Coffee Shop's Journey Through AWS by Laura Diaz.

Let's get started!

This post is all about Get the coffee shop online fast with Amazon S3🚀

As a first step, we should get the coffee shop online, somewhere customers can find coffee shop's hours, see photos of the delicious Argentinian pastries🥐 and the address in case they want to hop by for a sweet treat and a coffee.

So the first question we need to answer is: Where should this website live?.
We can host a static website on an S3 bucket.

By the end of this blog post, we will have done the following using Amazon S3 bucket:

1. Host a static website.
2. Protect the data: Implement data lifecycle strategy.
3. Implement a disaster recovery strategy.

The architecture would end up looking like this

1. Host a static website.

To host a static website on an S3 bucket you must clear Block all public access and enable ACLs while creating the bucket.

Once the S3 bucket is created, you can upload your files.
You also need to enable Static website hosting under properties and specify the index document, in my case it is index.html. This is the default webpage that S3 returns fine when a visitor requests the root URL or a subfolder of your static website.

At this point, you would think that if you open the S3 endpoint, which would look something like this http://your_coffee_website.s3-website-us-east-1.amazonaws.com, you will be able to see your static website, right? Well, bad news...

In AWS, all permissions are denied by default. This foundational security concept is known as an implicit deny. This means you need to create a bucket policy that grants read-only permission to public anonymous users by using the bucket policy editor.

Under Permissions tab, on Bucket Policy, edit the policy to grant public read access for your website (add the following bucket policy in the Bucket policy editor).

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

This should look something like this

And there you go, the static website is now hosted on the S3 🎉

2. Protect the data: Implement data lifecycle strategy

We just hosted the website but what about the security? How do we protect our data on our website?
A good idea would be to prevent any accidental overwrite and deletion of the website objects, we can achieve this by enabling object versioning

If you change something from the content or styles, you now have the previous version and the current one.

Enabling bucket versioning certainly would increase costs because it retains every single revision and we all know that optimizing costs is very important, not only for a small business like this scenario, but any business. One of the AWS Well Architected Framework pillars is about Cost Optimization, in this case would apply to Amazon S3 object storage.
To save costs we could implement a strategy to retire some of those older versions. We can achieve this by using lifecycle policies.
Create a lifecycle policy to automatically move older versions of the objects to S3 Standard-Infrequent Access (S3 Standard-IA) and also expire the objects.
Check the official docs here.

Create the following lifecycle policies:

• One that moves previous versions of our source bucket objects to S3 Standard-IA after 30 days.
• One that permanently deletes the objects that are in S3 Standard-IA after 365 days.

The lifecycle strategy should be based on the criticality, sensitivity of your data and any legal and organizational requirements

3. Implement a disaster recovery strategy

What if a disaster occurs that affects the region where your website is being hosted? We need a strategy so the website doesn't come down if some event like this happens. For this you can enable cross-region replication on your bucket settings.
In a different Region than the Region where is our source bucket, we need to create a second bucket and enable versioning on it. The second bucket will act as our destination bucket.
Under bucket Management tab, you'll find the Replication Rules.
To enable cross-region replication we must create the replication rule that replicates the entire source bucket.

We need an IAM role, this IAM role should give
S3 permissions to read objects from the source bucket and replicate them to the destination bucket.

In a real production environment, you should restrict the policy to apply to only your source and destination S3 buckets.

Now to test if the replication works, change the html file and upload the modified html. Check the destination bucket and you'll be able to see the file there.

To conclude this blog post, we successfully achieved the following:
✅ S3 bucket configured as a website.
✅ S3 bucket has a public policy.
✅ S3 has versioning enabled.
✅ S3 has a lifecycle policy attached with the required policies.
✅ S3 has cross region replication enabled.

The next blog post will be all about adding online ordering capabilities by implementing a web app and database on Amazon EC2.