Workshop on Cloud Native Systems and AI Integration

Kalaiselvan K — Tue, 15 Sep 2026 07:01:25 +0000

Cloud-Native Systems & Applied AI Integration — My Hands-on Workshop Journey

A practical exploration of AWS, cloud infrastructure, containers, networking, security, and AI integration.

Introduction

As part of the M.Sc. Artificial Intelligence and Machine Learning programme at the Coimbatore Institute of Technology, I am attending a two-day hands-on workshop on Cloud-Native Systems & Applied AI Integration.

The workshop focuses on understanding modern cloud-native technologies through practical implementation rather than learning them only from a theoretical perspective.

The sessions are being conducted by Mr. Santhosh NC, Lead Infrastructure Consultant at Thoughtworks, Coimbatore.

The workshop brings together concepts and technologies including:

Amazon Web Services (AWS)
Amazon S3
Amazon EC2
Cloud Networking
Security
Docker
Kubernetes
Generative AI
AI Guardrails
Agentic AI
AI/ML Deployment

The overall philosophy of the workshop can be summarized as:

Build → Deploy → Integrate → Innovate

Understanding Cloud Computing Through a Pizza

One of the first analogies used in the workshop to introduce cloud computing service models was surprisingly simple: ordering a pizza.

Instead of starting directly with technical definitions of IaaS, PaaS, and SaaS, the pizza analogy helped visualize how much responsibility is handled by the customer versus the service provider.

The basic idea is that depending on the service model, we take responsibility for different parts of the underlying infrastructure.

This can be visualized as:

Traditional / On-Premises
        ↓
We manage almost everything

IaaS
        ↓
Cloud provider manages physical infrastructure
We manage OS, applications, etc.

PaaS
        ↓
Cloud provider manages more of the infrastructure
We mainly focus on our application

SaaS
        ↓
We simply use the software
Most infrastructure and maintenance is handled by the provider

The pizza analogy made the underlying idea much easier to understand:

The more managed the service, the less infrastructure we have to manage ourselves.

This became a useful starting point for understanding why cloud platforms such as AWS provide different levels of abstraction.

AWS Cloud Quest

We were also introduced to AWS Cloud Quest, a gamified learning platform from AWS designed to help learners develop practical cloud skills.

The platform provides interactive learning experiences around AWS cloud concepts and services.

We were encouraged to explore the available learning paths and free AWS learning/certification opportunities as part of continuing our cloud journey beyond the workshop.

This was particularly useful because cloud concepts become much easier to understand when they are combined with hands-on practice.

Session 1 — AWS Infrastructure Fundamentals

The first major hands-on session covered the fundamentals of AWS infrastructure.

The planned topics for Session 1 were:

Amazon S3
Amazon EC2
Networking
Security Setup

We started by understanding the AWS account structure and some of the fundamental concepts behind AWS infrastructure.

Logging into AWS: Root User vs IAM User

The session began with understanding how we access an AWS account.

An important distinction was made between the AWS Root User and an IAM User.

Root User

The root user represents the original AWS account identity and has extremely broad permissions.

Because of its level of access, the root account should not be used for routine cloud operations.

IAM User

AWS Identity and Access Management (IAM) allows organizations to create identities with specific permissions.

Instead of giving every person complete access to an AWS account, permissions can be controlled according to what that person or application actually needs.

This introduces an important cloud security principle:

Give identities only the permissions they actually require.

Understanding this distinction was important before starting the practical AWS exercises.

AWS Regions and Availability Zones

Before creating resources, we explored one of the fundamental concepts behind AWS infrastructure: Regions and Availability Zones.

AWS Region

An AWS Region is a separate geographic area containing AWS infrastructure.

For example:

Asia Pacific (Mumbai)
ap-south-1

Since we are working from India, we used ap-south-1 (Mumbai) during our setup.

Choosing a region is important because it can affect:

Latency
Data residency
Service availability
Pricing
Application architecture

Availability Zones

Within an AWS Region, AWS provides multiple isolated locations known as Availability Zones (AZs).

Conceptually:

AWS Region
│
├── Availability Zone A
│
├── Availability Zone B
│
└── Availability Zone C

Availability Zones allow applications to be designed for higher availability and resilience.

This becomes especially important when we move from simple storage exercises into services such as EC2, networking, and production architectures.

Amazon S3

After covering the AWS fundamentals, we started working with Amazon S3 (Simple Storage Service).

S3 is an object storage service that can be used to store and retrieve files and other objects.

Instead of thinking about a traditional filesystem, S3 can be viewed conceptually as:

S3
│
└── Bucket
     │
     ├── image.jpg
     ├── index.html
     ├── portfolio/
     └── other objects...

The basic storage unit we worked with was an S3 bucket.

Creating an S3 Bucket

Our first practical AWS exercise was creating an S3 bucket.

The bucket provided a location where we could upload and manage objects.

After creating the bucket, we uploaded a basic image to understand how objects are stored and accessed through S3.

Practical Flow

AWS Console
    ↓
Amazon S3
    ↓
Create Bucket
    ↓
Upload Object
    ↓
Upload Image
    ↓
Access the Object

Screenshot — S3 Bucket Creation

📸 Screenshot — Uploaded Image

Hosting a Portfolio Using Amazon S3

After experimenting with a simple image, we moved to something more meaningful: hosting a basic portfolio webpage using S3.

We created a simple index.html file containing basic portfolio information.

For example, the structure was:

index.html

The file was then uploaded to the S3 bucket and configured for web hosting.

This demonstrated one of the interesting capabilities of S3: static website hosting.

Instead of running a web server ourselves, we could serve a static webpage using cloud storage infrastructure.

The architecture at this stage looked conceptually like:

                 AWS
                  │
                  ▼
             Amazon S3
                  │
                  ▼
             index.html
                  │
                  ▼
             Portfolio Page

📸 Screenshot — Portfolio index.html

📸 Screenshot — S3 Static Website

Introducing Amazon CloudFront

After successfully hosting the portfolio using S3, we took the next step and introduced Amazon CloudFront.

CloudFront is AWS's content delivery network (CDN).

Instead of users always accessing content directly from the origin, CloudFront can distribute content through its global network of edge locations.

The simplified architecture became:

This introduces an additional layer between the user and the storage origin.

Connecting CloudFront with S3

We created a CloudFront distribution and connected our S3-hosted content as the origin.

The objective was to understand how a static website stored in S3 can be delivered through a CDN.

The overall flow became:

User
 │
 │ HTTPS Request
 ▼
CloudFront
 │
 │ Request for content
 ▼
S3 Bucket
 │
 ▼
index.html
 │
 ▼
CloudFront
 │
 ▼
User

This was our first practical introduction to the idea of separating:

Storage → Delivery → User

S3 provides the storage/origin, while CloudFront provides the content delivery layer.

📸 Screenshot — CloudFront Distribution

📸 Screenshot — S3 Connected as Origin

📸 Screenshot — Portfolio Through CloudFront

What We Have Completed So Far

At this point in the workshop, we have gone from understanding basic cloud concepts to actually deploying a working static website on AWS.

Our journey so far:

Cloud Computing Concepts
        ↓
IaaS / PaaS / SaaS
        ↓
AWS Account
        ↓
Root User vs IAM
        ↓
AWS Regions
        ↓
Availability Zones
        ↓
Amazon S3
        ↓
Create S3 Bucket
        ↓
Upload Objects
        ↓
Host Static Website
        ↓
Create Portfolio
        ↓
Amazon CloudFront
        ↓
Deliver Portfolio through CDN

This progression was particularly useful because every concept was immediately followed by a practical implementation.

Key Takeaways So Far

1. Cloud is more than just "someone else's computer"

Cloud platforms provide different levels of abstraction and managed services, allowing developers to focus on applications without managing every layer of physical infrastructure.

2. IAM is fundamental to cloud security

Understanding identities and permissions is essential before working extensively with cloud resources.

3. Region selection matters

Choosing the appropriate AWS Region affects latency, availability, pricing, and architecture.

4. S3 can be used for static content

A simple HTML website can be hosted without maintaining a traditional web server.

5. CloudFront adds a delivery layer

Connecting CloudFront with S3 demonstrates how cloud applications can separate their origin/storage layer from their content delivery layer.

What's Next?

The workshop is continuing with the remaining components of the cloud-native stack.

The upcoming sessions will take us further into:

Amazon EC2
Networking
Security configuration
Docker
Kubernetes
AI integration
Deployment workflows

I'll continue updating this article as the workshop progresses, documenting the actual commands, configurations, screenshots, problems encountered, and solutions along the way.

Day 1 — Halfway Through

The first half of the workshop gave us a practical foundation in AWS and cloud infrastructure.

What started with a simple pizza analogy for cloud service models progressed into actually deploying a portfolio website using Amazon S3 and CloudFront.

And that's exactly what makes this workshop interesting — we're not just learning what AWS services are; we're actually building and deploying with them.

More to come as Day 1 continues...

DEV Community: Kalaiselvan K