Cloud-Native Systems & Applied AI Integration

Cloud-Native Systems & Applied AI Integration — Day 2: EC2, Linux, Nginx, and Tying It All Together Continuing my hands-on workshop notes — this time diving into compute, servers, and end-to-end data flow on AWS.

Picking Up From Day 1

Day 1 covered the fundamentals — IAM basics, AWS Regions, and hosting a static portfolio through S3 and CloudFront. Day 2 moved from storage into compute, and then brought everything together into one connected workflow spanning EC2, S3, and CloudFront.

The tools and services covered:

Amazon EC2
IAM (users & permissions)
Amazon S3
Amazon CloudFront
Amazon CloudWatch
AWS Launch Wizard
AWS CLI
Linux
Nginx

Setting Up IAM Properly

Before touching any compute resources, I created a dedicated IAM user with scoped permissions instead of working from the root account — following the same principle from Day 1:

Give identities only the permissions they actually require.

This IAM user was the one used for the rest of the day's exercises, including CLI access later on.

Launching an EC2 Instance

The core of Day 2 was Amazon EC2 — AWS's virtual server service.

I launched an Ubuntu EC2 instance, which involved:

Choosing an AMI (Ubuntu)
Selecting an instance type
Configuring a key pair for SSH access
Setting up a security group (opening ports for SSH and HTTP)

AWS Console
    ↓
EC2
    ↓
Launch Instance
    ↓
Choose Ubuntu AMI
    ↓
Configure Instance / Key Pair / Security Group
    ↓
Launch
    ↓
Connect via SSH

Exploring AWS Launch Wizard

Alongside the manual EC2 setup, I also explored AWS Launch Wizard — a service designed to simplify deploying common application infrastructure by handling sizing, configuration, and provisioning based on a chosen application type, rather than configuring every resource by hand.

It was a useful contrast to see: EC2 launched manually (full control, more steps) versus Launch Wizard (guided, opinionated, faster for standard deployments).

**
Connecting to EC2 and Working With Linux**

Once the instance was running, I connected to it over SSH and worked directly in the Ubuntu shell — updating packages, navigating the filesystem, and installing software from the command line.

Local Machine
    │
    │ ssh -i key.pem ubuntu@<public-ip>
    ▼
EC2 (Ubuntu)

Basic Linux commands (apt update, apt install, cd, ls, sudo) were the backbone of everything that followed on the server side.

📸 Screenshot: ssh-connection.png — connected to the EC2 instance via SSH
**
Installing and Configuring Nginx**

With the server accessible, I installed Nginx on the Ubuntu instance to serve as the web server.

sudo apt update
sudo apt install nginx
sudo systemctl start nginx
sudo systemctl enable nginx

After installation, hitting the instance's public IP in a browser confirmed the default Nginx welcome page was being served — a good checkpoint before customizing anything further.
**
Working With Data: EC2, AWS CLI, and S3**

This part tied compute and storage together using the AWS CLI.

I downloaded a Stranger Things dialogue dataset onto the EC2 instance, then used the AWS CLI to upload it directly from EC2 into an S3 bucket:

# On the EC2 instance
aws configure          # set up IAM user credentials
wget <dataset-url>     # download the dataset onto EC2

aws s3 cp stranger-things-dialogues.csv s3://<bucket-name>/

This demonstrated a common real-world pattern: processing or staging data on a compute instance, then pushing it to durable storage — rather than working with everything locally.

Dataset Source
      │
      ▼
   EC2 (Ubuntu)
      │
      │ aws s3 cp
      ▼
   S3 Bucket

Hosting a Static Website on S3 (Again — This Time End-to-End)

Using the same bucket, I set up static website hosting on S3, similar to Day 1, but now as part of a fuller pipeline that started on EC2.

EC2 → AWS CLI → S3 Bucket → Static Website Hosting

Delivering Through CloudFront

As the final step, I connected the S3-hosted site to a CloudFront distribution for content delivery — the same pattern from Day 1, now applied to a bucket populated via the EC2 → CLI → S3 workflow.

User
 │
 ▼
CloudFront
 │
 ▼
S3 Bucket (populated via EC2 + AWS CLI)
 │
 ▼
Static Website

Monitoring With CloudWatch

To round things out, I looked at Amazon CloudWatch for monitoring the EC2 instance — metrics like CPU utilization and basic status checks, giving visibility into how the instance was performing.

EC2 Instance
      │
      ▼
  CloudWatch
      │
      ▼
Metrics / Alarms / Dashboards

Putting It All Together

IAM User Created
      ↓
EC2 (Ubuntu) Launched
      ↓
Connected via SSH
      ↓
Nginx Installed & Configured
      ↓
Dataset Downloaded on EC2
      ↓
AWS CLI Configured
      ↓
Dataset Uploaded to S3
      ↓
Static Website Hosted on S3
      ↓
CloudFront Distribution Connected
      ↓
CloudWatch Monitoring EC2

Key Takeaways

1. EC2 gives you a real server, not an abstraction — Linux fundamentals matter the moment you SSH in.
2. Nginx is a quick way to get a web server running on a fresh instance.
3. The AWS CLI bridges compute and storage — moving data from EC2 to S3 is a pattern used constantly in real pipelines.
4. Launch Wizard vs manual EC2 setup highlights the trade-off between speed/guidance and full control. 5.CloudWatch closes the loop — once something is deployed, monitoring it is just as important as building it.

Wrapping Up

Day 2 connected the dots between compute and storage — going from a bare Ubuntu EC2 instance all the way to a monitored, CDN-delivered static site, with a real dataset moved through the pipeline via the AWS CLI along the way.

More notes to come as I keep exploring Docker, Kubernetes, and the AI integration components of the workshop.