Tuesday, June 9, 2026

Cohort 3 | Project CloudIgnite Topics: Amazon S3 Static Website Hosting, AWS CLI, EC2 Deep Dive (AMI, Key Pairs, Security Groups, Instance Profile, User Data, Metadata, IP Types, Connection Methods) Duration: ~3 hours

Key Takeaways

• S3 static website hosting: no servers to manage, cost-effective, automatic scaling, globally unique bucket names required, endpoint format: http://<bucket>.s3-website-<region>.amazonaws.com
• aws s3 sync vs cp: sync uploads only changed files (preferred for scripts), cp --recursive re-uploads everything every run
• EC2 instance types: General Purpose (T), Compute Optimized (C), Memory Optimized (R/X), Storage Optimized (I/D), Accelerated Computing (P/G), HPC (Hpc) — T3 used in labs so far
• IP addressing: Private IP retained on stop/start, Public IP changes on every stop/start, Elastic IP is static and persistent
• Instance Profile attaches IAM Role to EC2 — allows EC2 to access AWS services without storing credentials; User Data runs once at launch for bootstrapping
• Instance Metadata Service: http://169.254.169.254/latest/meta-data/ — accessible only from within EC2, returns instance info
• EC2 connection methods ranked by security: SSM Session Manager (no ports, no keys) > EC2 Instance Connect (port 22, browser) > SSH (port 22, .pem key)
• Instance store is ephemeral (data lost on stop/terminate), EBS is persistent — always use EBS for important data

Table of Contents

1. Amazon S3 — Static Website Hosting (Theory)
2. EC2 Compute — Deep Dive
3. Lab Walkthrough — Static Website on S3 using AWS CLI
4. CLF-C02 Exam Relevance

1. Amazon S3 — Static Website Hosting (Theory)

What is a static website?

• A website made up of HTML, CSS, and client-side JavaScript only — no server-side scripting, no database.
• Content changes infrequently (e.g. a café info page, a portfolio, a product image gallery).
• Client-side JavaScript is allowed; server-side processing (PHP, Python, etc.) is not.

Why host a static website on S3?

Dynamic websites (with databases, server-side logic) should use EC2 instead.

How S3 static website hosting works

1. Create an S3 bucket (bucket name must be globally unique).
2. Upload static files (HTML, CSS, JS, images).
3. Enable Static Website Hosting on the bucket.
4. S3 automatically assigns an endpoint URL in the format:

   http://<bucket-name>.s3-website-<region>.amazonaws.com
   

5. Set Block Public Access to off and enable ACLs (Access Control Lists) so objects can be read publicly.

Using a custom domain

• Use Amazon Route 53 to map your own domain name to the S3 static website endpoint.

Automating website updates with AWS CLI

• Instead of manually uploading files every time (error-prone, slow), write a bash script using the AWS CLI.
• Two key CLI commands for S3 file operations:

Tip from lecture: Prefer sync over cp for update scripts — it avoids re-uploading unchanged files.

Bash script structure (common pitfall)

#!/bin/bash
aws s3 sync ./website s3://your-bucket-name

• #!/bin/bash must be on its own line — do not put the aws command on the same line.
• Make the script executable: chmod +x update_website.sh
• Run it: ./update_website.sh

2. EC2 Compute — Deep Dive

EC2 Architecture Recap

• EC2 instances are virtual machines running on top of a hypervisor.
• Each instance has: CPU, RAM, ephemeral (instance store) storage.
• Instance store is not persistent — data is lost when an instance is stopped or rebooted. Use EBS for persistent storage.

EC2 instances sit inside a VPC subnet and can communicate with:

• The internet via an Internet Gateway
• Other EC2 instances within the VPC
• S3 via an S3 VPC Endpoint
• Attached EBS volumes

AMI — Amazon Machine Image

An AMI is a pre-configured template used to launch EC2 instances. It contains:

• Boot volume (OS + pre-installed software)
• Block device mapping (storage configuration)
• Launch permissions (who can use the AMI)

Benefits of AMIs:

• Repeatable — launch hundreds of identical instances from one template.
• Consistent configuration — reduces human error.
• Available from multiple sources: AWS-provided, community, or your own custom AMIs.

EC2 Instance Types

In labs so far: T3 (General Purpose) has been used throughout.

Key Pairs

• Used to connect to an EC2 instance without a username/password.
• Public key → stored by AWS on the instance.
• Private key → downloaded by you (.pem file). Keep it safe — it cannot be recovered.
• Connection uses SSH on port 22.

IP Address Types

Use Elastic IP when you need a permanent, unchanging public IP address.

Security Groups

• Act as a virtual firewall for EC2 instances.
• Control inbound and outbound traffic by port, protocol, and source/destination.
• One security group can be applied to many instances.
• Source can be:
  • 0.0.0.0/0 — anyone (open to the world)
  • A specific IP CIDR range — restricted access
  • Another security group — only instances in that security group can connect
• Common rule: SSH = port 22, HTTP = port 80, HTTPS = port 443

Instance Profile

• A way to attach an IAM Role to an EC2 instance.
• The EC2 instance can then perform actions on AWS services (e.g. read from S3) without storing credentials.
• Example: Attach a role with AmazonS3FullAccess → the EC2 instance can now read/write S3 buckets.

User Data

• A bash script provided at instance launch time.
• Runs once automatically when the EC2 instance first boots.
• Used for: installing software, configuration tasks, downloading files, etc.
• Format:

  #!/bin/bash
  yum update -y
  yum install -y httpd
  

• Also supports cloud-init directives (alternative format — less common in this course).

Instance Metadata Service

• A built-in HTTP endpoint accessible only from within an EC2 instance.
• URL: http://169.254.169.254/latest/meta-data/
• Returns information about the instance: instance ID, instance type, public hostname, AMI ID, etc.
• Also accessible: http://169.254.169.254/latest/user-data/ to retrieve the user data script.

# Run this from inside an EC2 instance
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/instance-id

This URL is not reachable from your local machine — only from within EC2.

EC2 Connection Methods

Best practice: Prefer SSM Session Manager — no port 22 needed, no key pair required, and all sessions are logged.

Launching an EC2 Instance via AWS CLI

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.micro \
  --key-name <key-pair-name> \
  --security-group-ids <sg-id> \
  --subnet-id <subnet-id> \
  --iam-instance-profile Name=<profile-name> \
  --user-data file://userdata.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=MyInstance}]'

EC2 Best Practices (from lecture)

• Use key pairs or SSM — do not enable password login.
• For Windows instances: use AWS Directory Service / Active Directory.
• Apply security patches regularly.
• Enable Termination Protection to prevent accidental deletion.
• Turn off source/destination check only for NAT instances.
• Take screenshots for troubleshooting unreachable instances.
• Use IAM roles (instance profile) instead of hardcoding credentials.

Troubleshooting: SSH Timeout with Public IP

Symptom: Instance launched successfully, has a public IP, but SSH connection times out.

Most likely cause: Port 22 is not open in the security group inbound rules.

Solution: Edit the security group and add an inbound rule: SSH / TCP / Port 22 / Source: your IP or 0.0.0.0/0.

3. Lab Walkthrough — Static Website on S3 using AWS CLI

Business scenario: Build a static website for a café (Sophia's Café) to display product photos and business info. Frank updates menu photos regularly, so the update process must be automated.

Lab Steps Summary

Step 1 — Connect to EC2 (CLI Host) via SSM Session Manager

# Switch to ec2-user after connecting
sudo su -l ec2-user

Step 2 — Configure AWS CLI

aws configure
# Enter: Access Key ID, Secret Access Key, Region (us-west-2), Output format (json)

Step 3 — Create an S3 Bucket

aws s3api create-bucket \
  --bucket <your-unique-bucket-name> \
  --region us-west-2 \
  --create-bucket-configuration LocationConstraint=us-west-2

Bucket names must be globally unique across all AWS accounts.

Step 4 — Create an IAM User

# Create the user
aws iam create-user --user-name aws-s3-user

# Create a login profile (set password)
aws iam create-login-profile \
  --user-name aws-s3-user \
  --password Training123!

Step 5 — Attach S3 Policy to the User

# List available policies to find AmazonS3FullAccess ARN
aws iam list-policies --scope AWS | grep S3

# Attach the policy
aws iam attach-user-policy \
  --user-name aws-s3-user \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

Step 6 — Enable Public Access & ACLs on the Bucket

• In the S3 Console → Permissions → uncheck Block all public access → Save.
• Edit Object Ownership → enable ACLs.

Step 7 — Configure the Bucket for Static Website Hosting

aws s3 website s3://<your-bucket-name> \
  --index-document index.html

Step 8 — Unzip and Upload Website Files

# Unzip the provided website archive
tar -xvf <website-archive>.tar.gz   # or unzip depending on format

# Upload all files with public read ACL
aws s3 cp ./website s3://<your-bucket-name> \
  --recursive \
  --acl public-read

Step 9 — Access the Website

• Go to S3 → your bucket → Properties → Static website hosting → copy the endpoint URL.
• Open the URL in a browser.

Step 10 — Create an Automation Bash Script

#!/bin/bash
aws s3 sync /path/to/website s3://<your-bucket-name> --acl public-read

chmod +x update_website.sh
./update_website.sh

sync only uploads changed files. cp --recursive re-uploads everything every time.

4. CLF-C02 Exam Relevance

The following topics from today's lecture directly map to the AWS Certified Cloud Practitioner (CLF-C02) exam domains.

Domain 3 — Cloud Technology and Services (33% of exam)

Domain 2 — Security and Compliance (30% of exam)

Domain 1 — Cloud Concepts (24% of exam)

Key Facts to Remember for the Exam

• S3 bucket names are globally unique across all AWS accounts.
• S3 static website = no server, no infrastructure to manage, scales automatically.
• Elastic IP = static public IP. Public IP = changes on every stop/start.
• Instance store = ephemeral (lost on stop). EBS = persistent.
• Security Groups are stateful — if you allow inbound traffic, the response is automatically allowed outbound.
• SSM Session Manager requires no open ports and no key pair — preferred over SSH for security.
• IAM Roles attached to EC2 (via instance profile) = no need to store credentials on the instance.
• User Data runs once at launch and is used to automate instance configuration.
• aws s3 sync uploads only changed files; aws s3 cp copies everything.

Notes compiled from Cohort 3 Project CloudIgnite lecture transcript — June 9, 2026.