DEV Community: 47.jp. Yokhash.

Yokhash Meets VPC: Exploring Amazon Virtual Private Cloud ☁️

47.jp. Yokhash. — Wed, 16 Sep 2026 02:14:15 +0000

📝 Introduction

What is the AWS service?

Amazon VPC (Virtual Private Cloud) is a networking service that lets you create your own logically isolated section of the AWS cloud. Think of it as your own private data center — but instead of buying servers, switches, and cables, you define it entirely in software. Inside a VPC, you control your own IP address range, subnets, route tables, and gateways, and you decide exactly what can talk to what.

Why was it created?

Before VPC existed, all AWS EC2 instances launched into a shared public network space (called "EC2-Classic"), where every customer's resources sat in the same network pool with limited isolation. This made it hard to build secure, enterprise-grade architectures. AWS launched VPC in 2009 to give customers a way to isolate their resources, define custom network topologies, and connect their AWS environment safely to on-premises data centers — essentially bringing traditional network security and control into the cloud.

⚙️ How It Works

In simple terms: a VPC is a virtual network dedicated to your AWS account. When you create a VPC, you assign it an IP address range (called a CIDR block, e.g. 10.0.0.0/16). You then divide that range into smaller subnets, which can be:

Public subnets — connected to the internet through an Internet Gateway (for things like web servers)
Private subnets — isolated from the internet (for things like databases)

Traffic between subnets is controlled by route tables, and traffic in and out of instances is filtered by security groups (instance-level firewall) and network ACLs (subnet-level firewall).

Simple Flow Diagram

                         ┌─────────────────────────────────────────┐
                         │                  VPC                      │
                         │              (10.0.0.0/16)                │
                         │                                            │
   Internet  ──────►  Internet                                       │
                       Gateway                                       │
                         │        ┌───────────────┐                  │
                         ├───────►│ Public Subnet │  EC2 (Web Server)│
                         │        │ 10.0.1.0/24   │                  │
                         │        └───────────────┘                  │
                         │                                            │
                         │        ┌───────────────┐                  │
                         │        │ Private Subnet│  RDS (Database)  │
                         │        │ 10.0.2.0/24   │                  │
                         │        └───────────────┘                  │
                         └─────────────────────────────────────────┘

Requests from the internet reach the public subnet through the Internet Gateway; the database in the private subnet is never directly reachable from outside.

🔑 Key Features

Subnets & IP Addressing — You control your own IP range and split it into public/private subnets across different Availability Zones for high availability.
Security Groups & Network ACLs — Fine-grained, layered firewall rules at both the instance level (security groups) and subnet level (NACLs), so you decide exactly what traffic is allowed in or out.
VPC Peering & Transit Gateway — You can privately connect multiple VPCs together (even across accounts or regions) without routing traffic over the public internet.
VPN & Direct Connect Integration — VPC can be securely connected to an on-premises network, letting a college's local campus network extend into AWS.

🎓 College/Student Use Case

Imagine a college hosting a student project portal (say, for internships, hackathon submissions, or a placement management system) on AWS:

The web application servers sit in a public subnet, accessible to students and faculty over the internet.
The database storing student records sits in a private subnet, completely shielded from direct internet access — only the web servers can reach it.
The college's IT department could use VPC peering to connect this project's VPC with another VPC used by a different department (e.g., the library management system) so both can share certain resources securely.
Security groups ensure only the college's own servers can query the database, protecting sensitive student data from external threats.

This mirrors exactly how real companies isolate public-facing apps from sensitive backend data.

💻 Simple Example

A minimal VPC setup using the AWS CLI:

# 1. Create a VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# 2. Create a public subnet inside it
aws ec2 create-subnet --vpc-id vpc-xxxxxxxx --cidr-block 10.0.1.0/24

# 3. Create and attach an Internet Gateway
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxxxxxxx --internet-gateway-id igw-xxxxxxxx

# 4. Create a route table entry to send internet-bound traffic through the gateway
aws ec2 create-route --route-table-id rtb-xxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxxxxxxx

This sequence creates an isolated network, adds a subnet that can reach the internet, and wires up the routing — the foundation any EC2 instance or RDS database would sit on top of.

✅ Advantages

Full control over IP ranges, routing, and network topology
Strong isolation between your resources and everyone else on AWS
Flexible connectivity — link to on-premises networks, other VPCs, or keep resources fully private
Free to use — VPC itself has no additional charge (you pay only for resources like NAT Gateways, VPN connections, or data transfer)

⚠️ Limitations / Things to Consider

Cost: The VPC itself is free, but components like NAT Gateways, VPN connections, and Transit Gateway attachments can add up quickly for a class project on a tight budget.
Complexity: Designing subnets, route tables, and security groups correctly requires a real understanding of networking — it's easy to misconfigure and accidentally expose (or block) resources.
Scalability: A poorly planned CIDR block (too small an IP range) can limit how much you can grow later, so planning ahead matters.
Security: Since VPC is the foundation of your cloud security posture, mistakes here (like leaving a database subnet public) can expose an entire application — it demands careful configuration and regular review.

🏁 Conclusion

Amazon VPC is the networking backbone of almost everything else you do on AWS — it's usually the very first thing you set up before launching EC2 instances, databases, or any other service. Understanding VPC means understanding how to design secure, isolated, and well-connected cloud environments — a skill that's directly transferable to real-world cloud architecture, and a perfect starting point for any student exploring how large-scale applications are actually built and secured on AWS.

CLOUD COMPUTING WORKSHOP AND AI INTEGRATION

47.jp. Yokhash. — Tue, 15 Sep 2026 06:57:02 +0000

What I Learned Today — Session 1

Today was the first half-day of the Cloud-Native Systems & Applied AI Integration hands-on workshop at Coimbatore Institute of Technology.

The session focused on understanding cloud fundamentals and getting practical experience with AWS.

Here are the major concepts I learned today.

Pizza as a Service — Understanding Cloud Service Models

One of the simplest and most memorable explanations from today's session was the Pizza as a Service analogy.

Instead of starting with complicated cloud terminology, we can understand service models by thinking about ordering pizza.

On-Premises

You make everything yourself.

You provide:
Ingredients
Kitchen
Oven
Cooking
Serving
Maintenance

In computing:

Hardware
Networking
Storage
Operating System
Runtime
Application
Data

Everything is managed by you.

IaaS — Infrastructure as a Service

Now imagine renting the kitchen and oven.

The infrastructure provider manages the physical infrastructure, while you manage the operating system and applications.

AWS
├── Servers
├── Networking
└── Storage

You
├── OS
├── Runtime
├── Application
└── Data

Examples include virtual machines and cloud infrastructure services.

PaaS — Platform as a Service

Now imagine the kitchen is already prepared.

You just bring your recipe and ingredients and focus on making the pizza.

Cloud Provider
├── Infrastructure
├── OS
├── Runtime
└── Platform

You
├── Application
└── Data

You don't need to worry about managing the underlying infrastructure.

SaaS — Software as a Service

Now imagine ordering a pizza.

You simply use the finished product.

You
↓
Pizza

You don't manage:

The kitchen
Oven
Ingredients
Cooking
Maintenance

Similarly, with SaaS, you simply use the software while the provider manages the underlying system.

Examples include services such as Gmail, Google Docs, and Microsoft 365.

AIaaS — AI as a Service

Today's discussion also introduced the idea of AI as a Service.

Instead of building and maintaining the complete AI infrastructure yourself, you consume AI capabilities through a service/API.

Your Application
|
v
AI API
|
v
AI Model / Infrastructure

This makes it possible for developers to integrate AI capabilities without necessarily building and training everything from scratch.

The Complete Pizza Analogy

The easiest way I remember it now:

         PIZZA AS A SERVICE

On-Premises
↓
Make everything yourself

IaaS
↓
Rent the kitchen + infrastructure

PaaS
↓
Use a ready-to-use kitchen/platform

SaaS
↓
Order the finished pizza

AIaaS
↓
Order AI capabilities when your
application needs them

This analogy made the difference between IaaS, PaaS, SaaS, and AIaaS much easier to understand.

AWS Infrastructure

We then moved into the basics of AWS infrastructure.

The important takeaway for me was that AWS isn't just a single service.

It is a huge ecosystem of cloud services that can be combined to build applications.

For example:

AWS
│
├── Compute
├── Storage
├── Networking
├── Databases
├── Security
├── AI / ML
└── Developer Tools

Today, we mainly worked with S3 and CloudFront while also understanding AWS account access and identity.

AWS Account — Root User vs IAM User

Another important concept I learned was the difference between the AWS Root User and an IAM User.

Root User

The root user is the original identity associated with an AWS account.

It has extremely high-level access to the account.

Conceptually:

AWS Account
│
└── Root User

Because of its powerful permissions, the root user should not be used for everyday development activities.

IAM User

IAM stands for:

Identity and Access Management

IAM allows us to create identities with specific permissions.

For example:

AWS Account
│
├── Root User
│
└── IAM
├── Developer
├── Administrator
└── Other users/roles

This introduced me to an important cloud security principle:

Give users only the permissions they actually need.

This is the idea of least privilege.

Amazon S3

The next major hands-on topic was Amazon S3 — Simple Storage Service.

I learned that S3 is an object storage service where data is stored as objects inside buckets.

The basic structure is:

AWS Account
↓
S3
↓
Bucket
↓
Objects
↓
Files / Data

Creating an S3 Bucket

We created an S3 bucket and explored its configuration.

The basic workflow was:

Create Bucket
↓
Configure Bucket
↓
Upload Files
↓
Configure Hosting
↓
Access Website

This gave me my first practical experience with creating cloud storage rather than just reading about it.

S3 Bucket Configuration

After creating the bucket, we explored different configuration options.

This helped me understand that creating a bucket is only the beginning.

We also need to think about:

Bucket configuration
Access
Permissions
Website hosting
Objects stored inside the bucket

Uploading Files to S3

We then uploaded files into the bucket.

For example:

S3 Bucket
│
├── index.html
├── style.css
├── script.js
└── assets/

This was particularly interesting because these files can form the foundation of a static website.

Hosting a Website with S3

We also learned how S3 can be configured to host static website content.

The basic idea is:

Browser
|
| Request
v
S3 Bucket
|
| index.html
v
Browser

So a simple frontend application can be stored and served from cloud infrastructure.

Amazon CloudFront

The final major topic of today's session was Amazon CloudFront.

CloudFront is AWS's Content Delivery Network (CDN).

The basic architecture we worked with was:

          User
             |
             v
      CloudFront
         Distribution
             |
             v
          S3
          Bucket
             |
             v
        Website Files

Creating a CloudFront Distribution

We learned how to create a CloudFront distribution.

One of the key steps was configuring the S3 bucket as the origin.

In simple terms:

CloudFront
|
| Origin
↓
S3 Bucket

The origin is essentially the location from which CloudFront obtains the content it needs to deliver.

So our overall architecture became:

                INTERNET
                     |
                     v
                USER
                     |
                     v
            ┌────────────────┐
            │   CloudFront   │
            │  Distribution  │
            └───────┬────────┘
                    |
                 Origin
                    |
                    v
            ┌────────────────┐
            │      S3        │
            │     Bucket     │
            └───────┬────────┘
                    |
                    v
             Website Files

This was probably the most valuable part of today's hands-on work because I could see how storage and content delivery work together.

My Key Takeaways from Session 1

Today's session helped me understand the cloud from three different perspectives:

Cloud Service Models IaaS → Infrastructure PaaS → Platform SaaS → Software AIaaS → AI capabilities
Cloud Identity AWS Account │ ├── Root User └── IAM └── Controlled Access
Cloud Web Hosting Website ↓ S3 ↓ CloudFront ↓ Users

The biggest takeaway for me is that cloud computing isn't just about using a remote server.

It's about understanding how different managed services can be combined to build, deploy, secure, and deliver applications.

What's Next?

This was only the first half-day of Session 1.

The workshop is continuing, and I'm looking forward to getting hands-on with the remaining topics around:

Docker
Containers
Kubernetes
Generative AI
AI Guardrails
Agentic AI
AI/ML deployment

I'll continue documenting the learning journey as the workshop progresses.

Session 1 — First Half: Completed