DEV Community: Peter Koech

Amazon S3 + Cloudflare Cloud Connector magic

Peter Koech — Sat, 25 Jan 2025 09:06:30 +0000

Securely host your static website in Amazon S3 using Cloudflare's CloudConnector

Peter Koech for AWS Community Builders ・ Jan 25

#aws #s3 #cloudflarechallenge #cloudcomputing

Securely host your static app in Amazon S3 using Cloudflare's CloudConnector

Peter Koech — Sat, 25 Jan 2025 09:00:06 +0000

I am going to demonstrate how to use Amazon S3 to host your objects or a static website and use Cloudflare as a Content Distribution Network (CDN).

Amazon S3 is an industry-leading object storage service offering unrivaled scalability, performance, and availability.

Cloudflare is one of the leading stand-alone Content Distribution Network (CDN), Amazon CloudFront is AWS's service that offers CDN and a host of other powerful features.

Normally users would use Amazon S3 and CloudFront to achieve the demo below, but some organizations have deployed Cloudflare as a dedicated CDN service in their infrastructure

Amazon S3

We will create a simple static website: http://stellar-landing.s3-website-us-east-1.amazonaws.com

It's usually a breeze using AWS CLI or SDK since you only run a couple of commands to get up and running. As you may be aware, every service in AWS can be interacted with through an API call.

So let me demonstrate, how we can set up stellar-landing bucket using AWS CLI.

Create the bucket using AWS CLI

aws s3 mb s3://stellar-landing
Access the console and enable public access for the bucket, allowing you to run the subsequent commands.
On your terminal, create a json file, we can name it "public-read.json" and inside it, you can place this policy which tells the bucket to allow everyone on the internet denoted by principal "*" to GET objects


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

We need to run a put-bucket-policy that updates the bucket's policy to allow for accessibility to the public.

aws s3api put-bucket-policy --bucket stellar-landing --policy file://public-read.json
To configure the bucket for static web hosting, you can use the put-bucket-website command:

aws s3 website s3://stellar-landing/ --index-document index.html --error-document error.html

As you can see, AWS CLI only has three commands to get a static site hosted. I can demonstrate how to do the same via the Console (point and click)

Create the bucket using AWS Console

Log into the console, then search for Amazon S3, click on it and the click on Create Bucket. Give it a name and leave the other options as is.

Go to the permissions tab, then uncheck the checkbox for block all public access

Attach the bucket policy to enable GetObjet requests for all users (principals)

Go to the properties tab; you will need to make two key change, under Static website hosting select on Enable then under Hosting type select Host a static website

Afterwards, you'll notice an endpoint provisioned for your public bucket, it follows this pattern; the name of the bucket stellar-landing followed by s3-website-us-east-1.amazonaws.com thus the final link Link

CloudFlare CDN

Now that we have our bucket up and running, before Cloudflare's connector service, it was nearly impossible to use CloudFlare as a CDN for Amazon S3 buckets to be hosted in CloudFlare, most methods were too complex as detailed in this link by Jaroslav Link

Then came Cloud Connector Link from CloudFlare, a service that enables us to route matching incoming traffic from our static website hosted in Amazon S3 bucket Link.

Steps to enable and configure Cloud Connector

Step 1

Step 2

Enter your bucket URL where your traffic can be directed to the URL via CNAME, select your bucket URL from your Amazon S3 console, it should be stellar-landing.s3-website-us-east-1.amazonaws.com

Step 3

Configure your Cloud Connector, give it a name such as stellar-landing-cdn under If incoming requests match Select custom filter expression
Under When incoming requests match; Select Field as URI Full, then under Operator select Contains, then for Value enter your preferred friendly URL that you wish your bucket to be referred to e.g https://stellar-landing.nation.africa

** Step 4**

Still in Cloudflare under DNS menu on the left, select Records
Then click on Add record
For **Type* select CNAME, then under Name provide an ideal name for your Amazon S3 hosted website e.g stellar-landing and finally under Target, enter your S3 bucket endpoint stellar-landing.s3-website-us-east-1.amazonaws.com
To enable SSL for your new endpoint on Cloudflare, click the Proxy status toggle; it should change to orange. This indicates that requests will now be proxied securely through CloudFlare.

You can now securely access your statically hosted website via this link Link i.e https://stellar-landing.nation.africa as opposed to non secure Amazon S3 endpoint: http://stellar-landing.s3-website-us-east-1.amazonaws.com/

PS: The template for the static website is owned by @ajlkn Link

Scaling down the storage of a MySQL RDS database with zero downtime using AWS Blue/Green Deployment

Peter Koech — Tue, 21 Jan 2025 21:29:24 +0000

As a DevOps engineer, you will find yourself optimizing and tinkering the RDS databases powering your workloads, you probably know the struggle with updating databases especially if you have heavy workloads depending on them. The risk of experiencing downtime during production is high. Traditional database management often leads to a catch-22 situation where you want to update your database for better performance but fear database downtime.

Well, worry no more! In this article, we will explore the AWS Blue/Green Deployment method that allows you to change your Relational Database Service (RDS) with zero downtime. Yes, you read that right: ZERO downtime, and it works like magic!

From explaining the Blue/Green Deployment strategy to providing a step-by-step guide on how you can utilize this in AWS, this article covers everything you need to know when updating your RDS database instance without compromising availability.

So, let's dive straight in!

Preparation

You need to identify a time when your dev team will not be performing any releases and also an ideal time when you have the least traffic on your workloads.

It's a good DevOps practice to notify the larger team of what time you schedule to perform such changes.

I will demonstrate downscaling DB's instance storage volume in this case while using Blue/Green deployment with zero downtime.

The same exercise can be achieved using either

AWS RDS Console
AWS CLI
AWS SDK

For our exercise, we will use the AWS RDS Console
NB Before performing Blue/Green deployments for either a MySQL or Mariad-based RDS instance, please enable automated backups link

Step 1

For our demo, we will scale the storage space from 400 GB to 200 GB. Our database cluster is made up of a master and 3 replicas as shown below.

Select the master database from the cluster
Click on actions then click on Create Blue/Green Deployment from the drop-down menu to open the "Blue" screen

Step 2

We need to create a copy of the production environment, here referred to as the Blue environment to a staging environment referred to as Green

Give your Blue/Green deployment an identifier name, remember the identifier is case-insensitive, but is stored as all lowercase.

Step 3

The next step is configuring the Blue/Green deployment by specifying the ideal database engine and the parameter group for your Green environment.

For our case, since we are interested in downsizing the storage size, we will use the same engine version and parameter group as the Blue environment (Production DB)

Step 4

This step entails configuring your Green instance database type; for our case, we will use use the same instance as Blue.

Step 5

Our main task is focussing on downsizing the allocated storage for the Green deployment.

The configuration update on AWS console will be done on one screen and will be replicated across the entire database cluster.

Remember we are scaling down storage for the master database and it's 3 replicas as shown in the figures below.

Side-by-side view of the Blue and Green master Deployments highlighting the updates.

Side-by-side view of the Blue/Green database replicas highlighting the changes made

Once you confirm all is looking good, a few things to note at this stage is that the cost of the Green deployment will be shown before you hit the create button.

Blue/Green will take anything between a few minutes to hours, this is dictated by factors such as the size of the database, how busy the workloads running off the database are, and the number of replicas.

For our case, it took about 5 hours for the Green deployment to be ready and it worked like magic.

Zero downtime, only a bit of lag on the Primary cluster (Blue) environment.

A lot of the magic happens under the hood, AWS handles renaming the Green deployment's DB cluster naming convention to match Blue environment, including updating the Endpoints for the Master and Replicas.

You won't need to update your application's configuration, the most I did is notifying the dev team via Slack about this exercise.