CloudCraft

☁️ CloudCraft — My First Hands-On AWS Cloud Deployment

From an HTML file on my laptop to a website running on AWS.

As part of the CloudCraft Cloud Workshop, I got hands-on with AWS by












deploying a static website using Amazon S3 and exploring how services like CloudFront and Route 53 fit into the architecture.

This wasn't just about learning what each AWS service does.

I actually went through the console, created resources, configured permissions, hosted the website, tested the endpoint, and then tried to put CloudFront in front of it.

Here is my step-by-step journey.

☁️ Step 1 — Starting with AWS

The first step was getting familiar with the AWS Management Console.

The main services I worked with were:

AWS
│
├── Amazon S3
├── CloudFront
└── Route 53

The goal was to take a simple static website and make it accessible through AWS infrastructure.

🪣 Step 2 — Creating an S3 Bucket

The first actual resource I created was an Amazon S3 bucket.

I went to:

AWS Console → S3 → Create bucket

For the bucket configuration, I selected:

Bucket type: General purpose
AWS Region: Europe (Stockholm) — eu-north-1
Bucket namespace: Global namespace
Bucket name: amuthanila-04-15

The bucket name needs to be unique within the relevant S3 namespace.

After creating the bucket, it became the storage location for my website.

📂 Step 3 — Uploading Website Files

Once the bucket was created, I uploaded my website files.

My bucket contained:

amuthanila-04-15
│
├── index.html
└── cloud.jpg

The important file here is:

index.html

because it acts as the entry page for the static website.

🌐 Step 4 — Enabling Static Website Hosting

Next, I configured the S3 bucket for static website hosting.

I went to:

S3 → Bucket → Properties → Static website hosting

and enabled:

S3 static website hosting

with:

Hosting type:
Bucket hosting

AWS then provided a region-specific website endpoint.

My website could now be accessed through an S3 website endpoint.

However, this endpoint uses HTTP, not HTTPS.

That became an important reason to explore CloudFront next.

🔓 Step 5 — Configuring Access

Uploading the files isn't enough.

The browser also needs permission to retrieve them.

So I worked with S3 access configuration.

One of the concepts I explored was ACL — Access Control List.

ACLs provide a mechanism for controlling access to S3 resources.

This helped me understand that storing a file and allowing someone to access that file are two different things.

🛡️ Step 6 — Adding an S3 Bucket Policy

Next, I configured a Bucket Policy.

The policy I used allowed s3:GetObject access to objects in the bucket.

The basic structure was:

Principal
↓
Action
↓
Resource
↓
Allow / Deny

For example:

Action:
s3:GetObject

and the resource pointed to the objects inside my bucket.

This was one of the first places where AWS IAM-style permissions started making practical sense.

🏷️ Step 7 — Understanding Tags

I also explored S3/AWS resource tags.

A tag is basically a key-value pair used to identify and organize resources.

For example:

Project = CloudCraft
Environment = Learning

It looks simple, but tags become very useful when working with many cloud resources.

🔄 Step 8 — Enabling Bucket Versioning

Next came S3 Versioning.

I enabled versioning for the bucket.

Instead of simply replacing an object:

index.html
↓
new index.html

S3 can maintain different versions of the object.

Conceptually:

index.html
│
├── Version 1
├── Version 2
└── Version 3

This provides protection against accidental overwrites and helps with recovery.

🔑 Step 9 — Exploring Presigned URLs

Another concept I explored was the S3 Presigned URL.

A presigned URL provides temporary access to an S3 object.

Instead of making an object permanently public:

Private Object
↓
Temporary Presigned URL
↓
User gets access

The URL can have an expiration time.

This is useful for securely sharing private files for a limited period.

🌍 Step 10 — Understanding S3 Global Namespace

While creating the bucket, I also learned an important S3 concept:

Bucket names are globally significant in the traditional S3 general-purpose bucket namespace.

That means you can't assume a name like:

mybucket

will be available.

So choosing a unique bucket name is part of creating an S3 bucket.

🏗️ Step 11 — High Availability

Along the way, I explored the idea of High Availability (HA).

The basic principle is:

Don't design your application around a single point of failure.

Cloud architecture aims to provide resilience through redundancy and distributed infrastructure.

This made me look at AWS not simply as:

"A place where I upload my website"

but as:

Infrastructure designed to deliver applications reliably.

⚡ Step 12 — Moving to CloudFront

After getting the website working through S3, the next step was Amazon CloudFront.

The architecture changes from:

User
↓
S3

to:

User
↓
CloudFront
↓
S3

CloudFront acts as a CDN and can cache content at edge locations closer to users.

This can improve content delivery performance and also gives us a path toward serving the site over HTTPS.

⚙️ Step 13 — Creating the CloudFront Distribution

I went to:

AWS Console → CloudFront → Distributions → Create distribution

For the distribution, I used:

Distribution name:
my-portfolio

I selected:

Single website configuration

For the origin, I selected my S3 bucket:

amuthanila-04-15.s3.eu-north-1.amazonaws.com

I also enabled:

Grant CloudFront access to origin → Yes

This allows CloudFront to access the S3 origin while AWS can manage the required S3 bucket policy configuration.

🚧 Step 14 — The Unexpected Problem

Everything looked ready.

The CloudFront configuration showed:

Billing:
Free ($0/month)

Origin:
S3

CloudFront access:
Yes

Security:
Enabled

But when I tried to create the distribution, AWS stopped me with:

"Your account must be verified before you can add new CloudFront resources."

So the problem wasn't my S3 configuration.

It was an AWS account verification requirement.

Instead of randomly changing the configuration, I opened an AWS Support case to resolve the account verification issue.

And honestly, this was also part of the learning.

Because in real cloud work:

Things don't always fail because your code is wrong.

Sometimes the problem is permissions, account restrictions, quotas, billing, or service-level requirements.

🌐 Step 15 — Route 53

The next part of the CloudCraft journey is Route 53.

The purpose is DNS.

Instead of users having to remember a long AWS endpoint, DNS allows a domain name to point toward the application infrastructure.

The intended architecture becomes:

             🌍 USER
                │
                ▼
          ┌───────────┐
          │ Route 53  │
          │    DNS    │
          └─────┬─────┘
                │
                ▼
          ┌───────────┐
          │CloudFront │
          │    CDN    │
          └─────┬─────┘
                │
                ▼
          ┌───────────┐
          │    S3     │
          │  Website  │
          └───────────┘

🧩 What I Covered in CloudCraft

My first CloudCraft hands-on session covered:

AWS
│
└── S3
├── Bucket creation
├── Global namespace
├── Object upload
├── Static website hosting
├── ACL
├── Bucket Policy
├── Tags
├── Versioning
└── Presigned URLs
│
▼
CloudFront
│
▼
Route 53
💡 My Biggest Takeaway

Before this workshop, these could have looked like separate AWS terms:

S3. ACL. Bucket Policy. Versioning. CloudFront. Route 53.

After actually configuring them, I started seeing them as different layers of the same architecture.

Storage
↓
Access Control
↓
Website Hosting
↓
Content Delivery
↓
DNS

That's the part I found most valuable about the hands-on approach.