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:
User
│
▼
CloudFront
│
▼
Amazon S3
│
▼
index.html
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...
Top comments (0)