Code from github to self hosted with git tea in AWS
10
.gitignore
vendored
Normal file
@@ -0,0 +1,10 @@
|
|||||||
|
# Local environment files
|
||||||
|
.env
|
||||||
|
*.env
|
||||||
|
aws-cloud-drive/CODE/.env
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# Python artifacts
|
||||||
|
__pycache__/
|
||||||
|
*.pyc
|
||||||
|
.venv/
|
||||||
279
PRACTICE/APPLICATION-LOAD-BALANCER/ALB-README.md
Normal file
@@ -0,0 +1,279 @@
|
|||||||
|
# Application Load Balancer (ALB)
|
||||||
|
|
||||||
|
## What is an Application Load Balancer?
|
||||||
|
|
||||||
|
An **Application Load Balancer (ALB)** operates at **OSI Layer 7** (the application layer), meaning it understands HTTP and HTTPS traffic and can make routing decisions based on the content of each request. When a client sends a request to the ALB's DNS endpoint, the ALB inspects the request and forwards it to one of the healthy registered targets in its **target group**, distributing load across multiple backend instances. This means you expose a single DNS name to the internet, and the ALB handles spreading requests across your backend — no single instance bears all the traffic. ALB also supports advanced routing rules (path-based, host-based), sticky sessions, and continuous health checks that automatically remove failed instances from rotation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lab Overview
|
||||||
|
|
||||||
|
| Resource | Name |
|
||||||
|
|---|---|
|
||||||
|
| Load Balancer | `demo-ALB` |
|
||||||
|
| Target Group | `demo-TG-ALB` |
|
||||||
|
| Security Group (ALB) | `demo-SG-ALB` |
|
||||||
|
| EC2 Instance 1 | `Demo-EC2-ALB-1` |
|
||||||
|
| EC2 Instance 2 | `Demo-EC2-ALB-2` |
|
||||||
|
| Region | `ap-south-1` (Mumbai) |
|
||||||
|
| Protocol | HTTP port `80` |
|
||||||
|
| Target type | EC2 instances |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Video Demo
|
||||||
|
|
||||||
|
[](https://youtu.be/JrgvgSGxSdw)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step-by-Step Walkthrough
|
||||||
|
|
||||||
|
### Step 1 — Open the AWS Console
|
||||||
|
|
||||||
|
Log in to AWS and navigate to the Console Home. From the recently visited services or the search bar, click **EC2** to start launching instances.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 2 — Launch EC2 Instances
|
||||||
|
|
||||||
|
#### 2a — Set instance name and choose OS
|
||||||
|
|
||||||
|
In the EC2 dashboard click **Launch instances**. Enter a name for the instance and select **Amazon Linux 2023** as the AMI.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2b — Configure security group and allow HTTP
|
||||||
|
|
||||||
|
Under **Network settings**, select an existing security group or create a new one. Make sure **Allow HTTP traffic from the internet** is checked so the web server is reachable on port 80.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2c — Add the user data script
|
||||||
|
|
||||||
|
Expand **Advanced details** and scroll down to the **User data** field. Paste the following script:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# Use this for your user data (script from top to bottom)
|
||||||
|
# install httpd (Linux 2 version)
|
||||||
|
yum update -y
|
||||||
|
yum install -y httpd
|
||||||
|
systemctl start httpd
|
||||||
|
systemctl enable httpd
|
||||||
|
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
|
||||||
|
```
|
||||||
|
|
||||||
|
**What this script does:**
|
||||||
|
|
||||||
|
| Command | Purpose |
|
||||||
|
|---|---|
|
||||||
|
| `yum update -y` | Updates all installed packages to the latest versions |
|
||||||
|
| `yum install -y httpd` | Installs Apache HTTP Server |
|
||||||
|
| `systemctl start httpd` | Starts the web server immediately after boot |
|
||||||
|
| `systemctl enable httpd` | Ensures the web server starts automatically on every reboot |
|
||||||
|
| `echo ... > /var/www/html/index.html` | Creates a simple HTML page displaying the instance's private hostname — this is how you can tell which backend instance responded when testing the ALB |
|
||||||
|
|
||||||
|
Set **Number of instances** to `2`, then click **Launch instance**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2d — Rename both instances
|
||||||
|
|
||||||
|
Once both instances are running, rename them to `Demo-EC2-ALB-1` and `Demo-EC2-ALB-2` by clicking the pencil icon next to each name.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 3 — Navigate to Load Balancers
|
||||||
|
|
||||||
|
In the EC2 left sidebar, scroll down to the **Load Balancing** section and click **Load Balancers**. Then click **Create load balancer**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 3a — Choose Application Load Balancer
|
||||||
|
|
||||||
|
On the **Compare and select load balancer type** page, click **Create** under **Application Load Balancer**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 4 — Configure the ALB
|
||||||
|
|
||||||
|
#### 4a — Basic configuration
|
||||||
|
|
||||||
|
Enter the following settings:
|
||||||
|
- **Load balancer name:** `demo-ALB`
|
||||||
|
- **Scheme:** Internet-facing
|
||||||
|
- **IP address type:** IPv4
|
||||||
|
- **VPC:** Select your default VPC (or your custom VPC)
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 4b — Select all availability zones
|
||||||
|
|
||||||
|
Under **Mappings**, select all available availability zones. This ensures the ALB can route to instances in any AZ and improves fault tolerance.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 5 — Create and Assign a Security Group
|
||||||
|
|
||||||
|
#### 5a — Create a new security group
|
||||||
|
|
||||||
|
Click **Create new security group** next to the security group selector. This opens the Security Groups console in a new tab.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 5b — Fill in security group details
|
||||||
|
|
||||||
|
Enter:
|
||||||
|
- **Security group name:** `demo-SG-ALB`
|
||||||
|
- **Description:** Security group for Application Load Balancer
|
||||||
|
- **VPC:** Select the same VPC chosen for the ALB
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 5c — Add inbound rule
|
||||||
|
|
||||||
|
Under **Inbound rules**, click **Add rule**. Set:
|
||||||
|
- **Type:** HTTP
|
||||||
|
- **Source:** `0.0.0.0/0` (allows all internet traffic on port 80)
|
||||||
|
|
||||||
|
Then click **Create security group**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 5d — Select the new security group in the ALB config
|
||||||
|
|
||||||
|
Go back to the ALB creation tab, refresh the security group list, and select `demo-SG-ALB`. Scroll down to continue.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 6 — Configure Listener and Target Group
|
||||||
|
|
||||||
|
#### 6a — Set default listener action
|
||||||
|
|
||||||
|
Under **Listeners and routing**, the default listener is HTTP port 80. Set the **Default action** to **Forward to** a target group. Click **Create target group** to open the target group wizard.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 6b — Configure target group basics
|
||||||
|
|
||||||
|
In the target group wizard, set:
|
||||||
|
- **Target type:** Instances
|
||||||
|
- **Target group name:** `demo-TG-ALB`
|
||||||
|
- **Protocol:** HTTP
|
||||||
|
- **Port:** 80
|
||||||
|
- **IP address type:** IPv4
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down and click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 6c — Register targets
|
||||||
|
|
||||||
|
Select both EC2 instances (`Demo-EC2-ALB-1` and `Demo-EC2-ALB-2`) from the available instances list, then click **Include as pending below**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Click **Next** to proceed to the review step.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Click **Create target group** to finalize.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 6d — Select the target group in the ALB config
|
||||||
|
|
||||||
|
Return to the ALB creation tab and select `demo-TG-ALB` as the target group for the listener's default action.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down and click **Create load balancer**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 7 — ALB Created Successfully
|
||||||
|
|
||||||
|
The ALB is now created. You will see a success banner and the ALB will appear in the load balancers list with state **Active** once it finishes provisioning.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 8 — Test the ALB
|
||||||
|
|
||||||
|
#### 8a — Copy the DNS name
|
||||||
|
|
||||||
|
In the **Load Balancers** list, select `demo-ALB` and copy the **DNS name** from the details panel at the bottom.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 8b — Open in a browser
|
||||||
|
|
||||||
|
Paste the DNS name into your browser's address bar and press Enter. You should see a page displaying one of the instance hostnames.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 8c — Refresh to confirm load distribution
|
||||||
|
|
||||||
|
Refresh the page. The ALB routes the second request to the other backend instance, and a different hostname appears — confirming the load balancer is distributing traffic across both EC2 instances.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **ALB in action:** The same DNS endpoint served two different responses from two different backend instances. This is exactly what ALB is designed to do — distribute incoming HTTP requests across all healthy registered targets, preventing any single instance from becoming a bottleneck.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 9 — Cleanup
|
||||||
|
|
||||||
|
#### 9a — Delete the ALB
|
||||||
|
|
||||||
|
In the **Load Balancers** console, select `demo-ALB`, click **Actions > Delete load balancer**, type `confirm` in the confirmation field, and click **Delete**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 9b — Delete the security group
|
||||||
|
|
||||||
|
Navigate to **EC2 > Security Groups**, select `demo-SG-ALB`, and click **Actions > Delete security groups**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 9c — Terminate EC2 instances
|
||||||
|
|
||||||
|
Navigate to **EC2 > Instances**, select both `Demo-EC2-ALB-1` and `Demo-EC2-ALB-2`, click **Instance state > Terminate instance**, and confirm.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
All resources used in this lab have been deleted.
|
||||||
|
After Width: | Height: | Size: 234 KiB |
|
After Width: | Height: | Size: 250 KiB |
|
After Width: | Height: | Size: 231 KiB |
|
After Width: | Height: | Size: 182 KiB |
|
After Width: | Height: | Size: 210 KiB |
|
After Width: | Height: | Size: 196 KiB |
|
After Width: | Height: | Size: 184 KiB |
|
After Width: | Height: | Size: 217 KiB |
|
After Width: | Height: | Size: 211 KiB |
|
After Width: | Height: | Size: 204 KiB |
|
After Width: | Height: | Size: 205 KiB |
|
After Width: | Height: | Size: 146 KiB |
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 168 KiB |
|
After Width: | Height: | Size: 170 KiB |
|
After Width: | Height: | Size: 212 KiB |
|
After Width: | Height: | Size: 175 KiB |
|
After Width: | Height: | Size: 240 KiB |
|
After Width: | Height: | Size: 183 KiB |
|
After Width: | Height: | Size: 158 KiB |
|
After Width: | Height: | Size: 183 KiB |
|
After Width: | Height: | Size: 170 KiB |
|
After Width: | Height: | Size: 154 KiB |
|
After Width: | Height: | Size: 258 KiB |
|
After Width: | Height: | Size: 249 KiB |
|
After Width: | Height: | Size: 174 KiB |
|
After Width: | Height: | Size: 177 KiB |
|
After Width: | Height: | Size: 256 KiB |
|
After Width: | Height: | Size: 261 KiB |
|
After Width: | Height: | Size: 234 KiB |
|
After Width: | Height: | Size: 242 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 89 KiB |
|
After Width: | Height: | Size: 262 KiB |
|
After Width: | Height: | Size: 155 KiB |
|
After Width: | Height: | Size: 248 KiB |
|
After Width: | Height: | Size: 245 KiB |
321
PRACTICE/AUTO-SCALING-GROUP-ELB/ASG-README.md
Normal file
@@ -0,0 +1,321 @@
|
|||||||
|
# Auto Scaling Group (ASG) with Elastic Load Balancer
|
||||||
|
|
||||||
|
## What is an Auto Scaling Group?
|
||||||
|
|
||||||
|
An **Auto Scaling Group (ASG)** is an AWS service that automatically manages a fleet of EC2 instances, maintaining the number you specify at all times. When paired with an **Elastic Load Balancer (ELB)**, the ASG registers its instances as targets in the load balancer's target group automatically — so every new instance spun up by the ASG is immediately eligible to receive traffic. The ELB continuously performs health checks on all registered instances and reports results back to the ASG; if an instance fails a health check, the ASG detects it, terminates the unhealthy instance, and launches a replacement — entirely without human intervention. This combination delivers **high availability**, **self-healing infrastructure**, and the ability to **scale in or out** based on demand.
|
||||||
|
|
||||||
|
> **Prerequisites:** This lab assumes an Application Load Balancer (`ALB-ASG`) and Target Group (`ALB-ASG-TG`) already exist. If you haven't created them yet, refer to the [ALB README](../APPLICATION-LOAD-BALANCER/ALB-README.md) first.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lab Overview
|
||||||
|
|
||||||
|
| Resource | Name / Value |
|
||||||
|
|---|---|
|
||||||
|
| Auto Scaling Group | `ASG` |
|
||||||
|
| Launch Template | `ASG-launch-template` |
|
||||||
|
| AMI | Amazon Linux 2023 (ami-0317b0f0a0144b137) |
|
||||||
|
| Instance Type | `t3.micro` |
|
||||||
|
| Security Group (instances) | `launch-wizard-1` |
|
||||||
|
| Security Group (ALB) | `SG-ASG` |
|
||||||
|
| Load Balancer | `ALB-ASG` |
|
||||||
|
| Target Group | `ALB-ASG-TG` |
|
||||||
|
| Desired / Min / Max capacity | `2` / `1` / `4` |
|
||||||
|
| Availability Zones | ap-south-1a, ap-south-1b, ap-south-1c |
|
||||||
|
| Region | `ap-south-1` (Mumbai) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Video Demo
|
||||||
|
|
||||||
|
[](https://youtu.be/gUS-584nZ7M)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step-by-Step Walkthrough
|
||||||
|
|
||||||
|
### Step 1 — Open EC2 and Navigate to Auto Scaling Groups
|
||||||
|
|
||||||
|
Log in to the AWS Management Console. From the **Recently visited** services on Console Home, click **EC2**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Inside the EC2 dashboard, locate the **Resources** panel and click **Auto Scaling Groups**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
The Auto Scaling Groups landing page explains how ASG works. Click **Create Auto Scaling group** to begin.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 2 — Create a Launch Template
|
||||||
|
|
||||||
|
A **launch template** is a reusable blueprint that tells the ASG exactly how to configure every EC2 instance it launches — OS, instance type, security group, and startup script — so you never have to configure machines manually again.
|
||||||
|
|
||||||
|
#### 2a — Name the ASG and open the launch template wizard
|
||||||
|
|
||||||
|
In the **Name** field of the ASG wizard, enter `ASG`. Since no launch template exists yet, click **Create a launch template** to open the template wizard in a new tab.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2b — Name and describe the template
|
||||||
|
|
||||||
|
Enter the following details:
|
||||||
|
- **Launch template name:** `ASG-launch-template`
|
||||||
|
- **Template version description:** `A launch template for Auto Scaling Group`
|
||||||
|
- **Auto Scaling guidance:** check the box — *Provide guidance to help me set up a template that I can use with EC2 Auto Scaling*
|
||||||
|
|
||||||
|
Then scroll down.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2c — Choose AMI and instance type
|
||||||
|
|
||||||
|
Under **Application and OS Images**, click **Quick Start**, select **Amazon Linux**, and choose **Amazon Linux 2023 AMI 2023.10** (Free tier eligible).
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Under **Instance type**, open the dropdown and select **t3.micro** (Free tier eligible, 2 vCPU, 1 GiB Memory).
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2d — Select security group, add user data, and create the template
|
||||||
|
|
||||||
|
Under **Network settings**, choose **Select existing security group** and select **launch-wizard-1**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down and click **Advanced details** to expand it.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll to the **User data** field and paste the following script. This script runs automatically the first time each instance boots, installing and starting a web server that displays the instance's private hostname — which is how you can confirm the load balancer is routing to different instances.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# Use this for your user data (script from top to bottom)
|
||||||
|
# install httpd (Linux 2 version)
|
||||||
|
yum update -y
|
||||||
|
yum install -y httpd
|
||||||
|
systemctl start httpd
|
||||||
|
systemctl enable httpd
|
||||||
|
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
|
||||||
|
```
|
||||||
|
|
||||||
|
| Command | Purpose |
|
||||||
|
|---|---|
|
||||||
|
| `yum update -y` | Updates all installed packages |
|
||||||
|
| `yum install -y httpd` | Installs Apache HTTP Server |
|
||||||
|
| `systemctl start httpd` | Starts the web server immediately |
|
||||||
|
| `systemctl enable httpd` | Ensures the web server starts on every reboot |
|
||||||
|
| `echo ... > /var/www/html/index.html` | Creates a page showing the instance's private hostname |
|
||||||
|
|
||||||
|
Click **Create launch template**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 3 — Select the Launch Template and Configure the Network
|
||||||
|
|
||||||
|
Return to the ASG wizard tab. Open the **Launch template** dropdown and select **ASG-launch-template**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
The template summary appears, confirming the AMI, instance type (`t3.micro`), and security group. Click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
On the **Choose instance launch options** step, under **Availability Zones and subnets**, select all three availability zones:
|
||||||
|
- **aps1-az1** (ap-south-1a)
|
||||||
|
- **aps1-az2** (ap-south-1c)
|
||||||
|
- **aps1-az3** (ap-south-1b)
|
||||||
|
|
||||||
|
Leave **Availability Zone distribution** set to **Balanced best effort**. Click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **Why select all AZs?** Spreading instances across multiple Availability Zones means that if one AZ has an outage, your application keeps running on instances in the remaining zones.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 4 — Attach to the Existing Load Balancer
|
||||||
|
|
||||||
|
On the **Integrate with other services** step, under **Load balancing**, select **Attach to an existing load balancer**.
|
||||||
|
|
||||||
|
Under **Select the load balancers to attach**, choose **Choose from your load balancer target groups**. Click the target group dropdown — it shows `ALB-ASG-TG | HTTP` backed by the `ALB-ASG` load balancer. Select it.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down to the **Health checks** section. Tick **Turn on Elastic Load Balancing health checks** (marked Recommended). Leave the health check grace period at **300 seconds**. Click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **Why enable ELB health checks?** By default the ASG only uses EC2 health checks (is the instance running?). Enabling ELB health checks adds a second layer — the ASG will also replace instances that are running but failing to serve HTTP traffic.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 5 — Configure Group Size and Scaling
|
||||||
|
|
||||||
|
On the **Configure group size and scaling** step, set the capacity values:
|
||||||
|
|
||||||
|
| Setting | Value |
|
||||||
|
|---|---|
|
||||||
|
| Desired capacity | `2` |
|
||||||
|
| Min desired capacity | `1` |
|
||||||
|
| Max desired capacity | `4` |
|
||||||
|
|
||||||
|
Under **Automatic scaling**, leave **No scaling policies** selected — the group will maintain exactly the desired capacity at all times.
|
||||||
|
|
||||||
|
Under **Instance maintenance policy**, leave **No policy** selected.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down, review the additional settings (all defaults), and click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
On the **Add notifications** step, skip adding any SNS notifications and click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
On the **Add tags** step, skip adding tags and click **Next**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 6 — Review and Create
|
||||||
|
|
||||||
|
The **Review** page summarises every setting. Verify:
|
||||||
|
- **Auto Scaling group name:** `ASG`
|
||||||
|
- **Launch template:** `ASG-launch-template` (Default version)
|
||||||
|
- **Availability Zones:** aps1-az1, aps1-az2, aps1-az3
|
||||||
|
|
||||||
|
Scroll through and confirm the load balancer integration and group size settings are correct.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll to the bottom and click **Create Auto Scaling group**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 7 — ASG Created — EC2 Instances Auto-Provisioned
|
||||||
|
|
||||||
|
The ASG is created. Navigate to the **Activity** tab. The Activity history shows two **Successful** launch events — the ASG immediately provisioned the desired 2 instances using the launch template.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Navigate to **EC2 > Instances**. Two `t3.micro` instances are in **Running** state — one in `ap-south-1a`, one in `ap-south-1b`.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **Key point:** You never clicked "Launch instance." The ASG read the launch template and provisioned both machines automatically as soon as it was created.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 8 — Test via the Load Balancer DNS
|
||||||
|
|
||||||
|
Navigate to **EC2 > Load Balancers** and select **ALB-ASG**. In the details panel, locate and copy the **DNS name**:
|
||||||
|
|
||||||
|
```
|
||||||
|
ALB-ASG-1425310447.ap-south-1.elb.amazonaws.com
|
||||||
|
```
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Paste the DNS name into your browser's address bar and press Enter. You will see a page served by one of the ASG-managed instances:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Refresh the page. The ALB routes the request to another instance, and you may see a different hostname — confirming the load balancer is distributing traffic across the ASG's instances.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 9 — Test Auto-Healing
|
||||||
|
|
||||||
|
To verify the self-healing capability, manually terminate one of the running instances. Go to **EC2 > Instances**, select one of the ASG-managed instances, click **Instance state > Terminate (delete) instance**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Switch to **Auto Scaling groups > ASG > Instance management**. The terminated instance appears with a health status of **Unhealthy** (Lifecycle: Terminating), while the others remain **Healthy**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Within a few minutes, check the **Activity** tab. A new entry appears:
|
||||||
|
|
||||||
|
> *"An instance was launched in response to an unhealthy instance needing to be replaced."*
|
||||||
|
|
||||||
|
The ASG detected the unhealthy instance via the ELB health check, terminated it, and launched a fresh replacement — all automatically.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **Auto-healing in action:** No manual intervention was needed. The ASG + ELB health check loop detected the failure and self-healed the fleet within minutes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 10 — Cleanup
|
||||||
|
|
||||||
|
Delete resources in the following order to avoid dependency errors.
|
||||||
|
|
||||||
|
#### 10a — Delete the Auto Scaling Group
|
||||||
|
|
||||||
|
In **Auto Scaling groups**, select `ASG`, click **Actions > Delete**. Type `delete` in the confirmation field and click **Delete**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
The ASG status changes to **Deleting** and the desired/min/max capacity drops to 0.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
The Activity history shows both instances being terminated.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> **Important:** Deleting the ASG automatically terminates all EC2 instances it manages. You do not need to terminate them separately.
|
||||||
|
|
||||||
|
Navigate to **EC2 > Instances** to confirm all instances are terminated.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 10b — Delete the Load Balancer
|
||||||
|
|
||||||
|
In **EC2 > Load Balancers**, select `ALB-ASG`, click **Actions > Delete load balancer** and confirm. A green banner confirms: *Successfully deleted load balancer: ALB-ASG*.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 10c — Delete the Target Group
|
||||||
|
|
||||||
|
In **EC2 > Target Groups**, select `ALB-ASG-TG`, click **Actions > Delete** and confirm.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 10d — Delete the Security Group
|
||||||
|
|
||||||
|
In **EC2 > Security Groups**, select `SG-ASG`, click **Actions > Delete security groups** and confirm.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
All resources from this lab have been deleted.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Key Concepts Learned
|
||||||
|
|
||||||
|
- **Auto Scaling Group (ASG):** Automatically maintains a desired number of EC2 instances. If an instance fails or is terminated, the ASG replaces it to keep the fleet at the desired count.
|
||||||
|
- **Launch Template:** A reusable configuration blueprint (AMI, instance type, security group, user data) used by the ASG to provision identical instances on demand — eliminating manual configuration.
|
||||||
|
- **Desired / Min / Max Capacity:** Defines the target fleet size (Desired), the floor (Min), and the ceiling (Max) the ASG will operate between.
|
||||||
|
- **ELB Health Checks:** When enabled, the ASG uses the load balancer's perspective of instance health (is the instance passing HTTP checks?) rather than just EC2 status (is the instance running?). This catches application-level failures.
|
||||||
|
- **Auto-Healing:** ASG automatically replaces any instance the ELB marks as unhealthy — no manual action required.
|
||||||
|
- **Multi-AZ Deployment:** Distributing instances across multiple Availability Zones ensures the application survives a single AZ failure.
|
||||||
|
- **Instance Maintenance Policy:** Controls whether the ASG launches a replacement before or after terminating an unhealthy instance during rebalancing events.
|
||||||
|
After Width: | Height: | Size: 642 KiB |
|
After Width: | Height: | Size: 676 KiB |
|
After Width: | Height: | Size: 549 KiB |
|
After Width: | Height: | Size: 443 KiB |
|
After Width: | Height: | Size: 701 KiB |
|
After Width: | Height: | Size: 682 KiB |
|
After Width: | Height: | Size: 792 KiB |
|
After Width: | Height: | Size: 688 KiB |
|
After Width: | Height: | Size: 607 KiB |
|
After Width: | Height: | Size: 560 KiB |
|
After Width: | Height: | Size: 497 KiB |
|
After Width: | Height: | Size: 544 KiB |
|
After Width: | Height: | Size: 540 KiB |
|
After Width: | Height: | Size: 786 KiB |
|
After Width: | Height: | Size: 655 KiB |
|
After Width: | Height: | Size: 758 KiB |
|
After Width: | Height: | Size: 559 KiB |
|
After Width: | Height: | Size: 295 KiB |
|
After Width: | Height: | Size: 408 KiB |
|
After Width: | Height: | Size: 483 KiB |
|
After Width: | Height: | Size: 358 KiB |
|
After Width: | Height: | Size: 754 KiB |
|
After Width: | Height: | Size: 498 KiB |
|
After Width: | Height: | Size: 679 KiB |
|
After Width: | Height: | Size: 660 KiB |
|
After Width: | Height: | Size: 664 KiB |
|
After Width: | Height: | Size: 59 KiB |
|
After Width: | Height: | Size: 60 KiB |
|
After Width: | Height: | Size: 821 KiB |
|
After Width: | Height: | Size: 377 KiB |
|
After Width: | Height: | Size: 821 KiB |
|
After Width: | Height: | Size: 707 KiB |
|
After Width: | Height: | Size: 602 KiB |
|
After Width: | Height: | Size: 518 KiB |
|
After Width: | Height: | Size: 590 KiB |
|
After Width: | Height: | Size: 861 KiB |
|
After Width: | Height: | Size: 447 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 658 KiB |
225
PRACTICE/EC2/EC2-README.md
Normal file
@@ -0,0 +1,225 @@
|
|||||||
|
# EC2 - Elastic Compute Cloud
|
||||||
|
|
||||||
|
> Practice completed on: February 13, 2026
|
||||||
|
|
||||||
|
## Video Tutorial
|
||||||
|
|
||||||
|
[](https://youtu.be/0Vk-Q6gzWwU)
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This practice demonstrates how to launch an EC2 instance in AWS, configure security groups, connect via SSH, and manage the instance lifecycle. EC2 (Elastic Compute Cloud) is AWS's virtual server service that provides scalable computing capacity in the cloud.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
- [x] AWS Account (Free Tier eligible)
|
||||||
|
- [x] SSH client installed (PuTTY for Windows, or built-in ssh command)
|
||||||
|
- [x] Basic understanding of Linux command line
|
||||||
|
- [x] Basic networking knowledge (IP addresses, ports, security)
|
||||||
|
|
||||||
|
## Step-by-Step Walkthrough
|
||||||
|
|
||||||
|
### Step 1: AWS Management Console
|
||||||
|
|
||||||
|
Starting point - accessing the AWS Management Console to begin the EC2 instance creation process.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Navigate to EC2 service from the AWS Console
|
||||||
|
- Ensure you're in the correct AWS region (check top-right corner)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 2: Launch Instance
|
||||||
|
|
||||||
|
Initiating the EC2 instance launch wizard to configure and create a new virtual machine.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Click "Launch Instance" button to start the configuration process
|
||||||
|
- You'll configure multiple settings before the instance is created
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 3: Instance Configuration
|
||||||
|
|
||||||
|
Configuring basic instance details including name, AMI selection, and instance type.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Choose a meaningful name for your instance
|
||||||
|
- Select Amazon Machine Image (AMI) - Amazon Linux 2 or Ubuntu are common free tier options
|
||||||
|
- Select instance type - t2.micro is free tier eligible
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 4: Key Pair Configuration
|
||||||
|
|
||||||
|
Creating or selecting a key pair for secure SSH access to the EC2 instance.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Key pairs are essential for SSH authentication
|
||||||
|
- Download the .pem file immediately - you cannot retrieve it later
|
||||||
|
- Store the key file securely - it's like a password for your instance
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 5: Network Settings
|
||||||
|
|
||||||
|
Configuring network and security group settings to control inbound and outbound traffic.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Security groups act as virtual firewalls
|
||||||
|
- SSH (port 22) must be allowed for remote access
|
||||||
|
- Consider restricting SSH access to your IP address for better security
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 6: Security Group Rules
|
||||||
|
|
||||||
|
Detailed configuration of security group rules defining which ports and protocols are accessible.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Default SSH rule allows connection from anywhere (0.0.0.0/0)
|
||||||
|
- For production, always restrict source IP addresses
|
||||||
|
- Additional rules can be added for HTTP (80), HTTPS (443), or custom applications
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 7: Storage Configuration
|
||||||
|
|
||||||
|
Configuring the root volume and additional storage for the EC2 instance.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Default is 8 GB general purpose SSD (gp2/gp3)
|
||||||
|
- Free tier includes up to 30 GB of EBS storage
|
||||||
|
- Volume is deleted on instance termination by default (can be changed)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 8: Review and Launch
|
||||||
|
|
||||||
|
Final review of all configurations before launching the instance.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Double-check all settings before launching
|
||||||
|
- Instance type, security groups, and key pair cannot be changed after creation (without stopping)
|
||||||
|
- Confirm you have the key pair file downloaded
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 9: Instance Launching
|
||||||
|
|
||||||
|
Instance creation in progress - AWS is provisioning the virtual machine.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Instance goes through several states: pending → running
|
||||||
|
- Usually takes 1-2 minutes to fully initialize
|
||||||
|
- You can view instance details and status from the EC2 dashboard
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 10: Instance Running
|
||||||
|
|
||||||
|
Instance is now running and ready for connection - view instance details and public IP.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Instance state shows "Running" with a green indicator
|
||||||
|
- Public IPv4 address is assigned (needed for SSH connection)
|
||||||
|
- Instance ID uniquely identifies your EC2 instance
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 11: SSH Connection Details
|
||||||
|
|
||||||
|
Preparing to connect to the instance via SSH using the key pair and public IP address.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Key Points:**
|
||||||
|
- Use the Connect button to see detailed SSH instructions
|
||||||
|
- Connection command format: `ssh -i "keyfile.pem" ec2-user@public-ip`
|
||||||
|
- For Windows users: Use PuTTY or Windows SSH client
|
||||||
|
- First connection will prompt to verify the host fingerprint
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Key Concepts Learned
|
||||||
|
|
||||||
|
- **EC2 Instance:** Virtual server in AWS cloud that you can configure and control
|
||||||
|
- **AMI (Amazon Machine Image):** Pre-configured template containing the OS and software
|
||||||
|
- **Instance Type:** Defines the CPU, memory, storage, and networking capacity (e.g., t2.micro)
|
||||||
|
- **Key Pair:** Public-private key pair used for secure SSH authentication
|
||||||
|
- **Security Group:** Virtual firewall controlling inbound and outbound traffic rules
|
||||||
|
- **EBS (Elastic Block Store):** Persistent block storage volumes for EC2 instances
|
||||||
|
- **Public IP:** Internet-accessible IP address assigned to your instance
|
||||||
|
- **SSH (Secure Shell):** Encrypted protocol for secure remote access to Linux instances
|
||||||
|
|
||||||
|
## Video Walkthrough
|
||||||
|
|
||||||
|
Complete demonstration of launching an EC2 instance and connecting via SSH:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
This video walks through the entire process from creating the instance to successfully establishing an SSH connection.
|
||||||
|
|
||||||
|
## Troubleshooting
|
||||||
|
|
||||||
|
### Issue: Cannot connect via SSH - Connection timeout
|
||||||
|
**Solution:**
|
||||||
|
- Check security group allows SSH (port 22) from your IP address
|
||||||
|
- Verify you're using the correct public IP address
|
||||||
|
- Ensure your internet connection isn't blocking outbound SSH traffic
|
||||||
|
|
||||||
|
### Issue: Permission denied (publickey) error
|
||||||
|
**Solution:**
|
||||||
|
- Verify you're using the correct key pair file (.pem)
|
||||||
|
- Check key file permissions: `chmod 400 keyfile.pem` on Linux/Mac
|
||||||
|
- Ensure you're using the correct username (ec2-user for Amazon Linux, ubuntu for Ubuntu)
|
||||||
|
|
||||||
|
### Issue: Key file permissions too open
|
||||||
|
**Solution:**
|
||||||
|
- On Linux/Mac: Run `chmod 400 keyfile.pem`
|
||||||
|
- On Windows: Right-click key file → Properties → Security → Advanced → Disable inheritance
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
**Related AWS Services to Practice:**
|
||||||
|
- **EBS Volumes:** Attach additional storage to EC2 instances
|
||||||
|
- **Elastic IP:** Associate a static IP address to your instance
|
||||||
|
- **Load Balancers:** Distribute traffic across multiple EC2 instances
|
||||||
|
- **Auto Scaling:** Automatically adjust instance capacity based on demand
|
||||||
|
- **CloudWatch:** Monitor instance performance and set up alarms
|
||||||
|
|
||||||
|
**Recommended Next Practice:**
|
||||||
|
- [Application Load Balancer](../ALB/README.md) - Learn to distribute traffic
|
||||||
|
- [S3 Integration](../S3/README.md) - Store and retrieve files from EC2
|
||||||
|
- [VPC Configuration](../VPC/README.md) - Understand AWS networking
|
||||||
|
|
||||||
|
## Resources
|
||||||
|
|
||||||
|
- [AWS EC2 Documentation](https://docs.aws.amazon.com/ec2/)
|
||||||
|
- [EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/)
|
||||||
|
- [Security Groups Best Practices](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
|
||||||
|
- [SSH Connection Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
[↑ Back to Practice Index](../../README.md)
|
||||||
BIN
PRACTICE/EC2/ec2-01.png
Normal file
|
After Width: | Height: | Size: 241 KiB |
BIN
PRACTICE/EC2/ec2-02.png
Normal file
|
After Width: | Height: | Size: 264 KiB |
BIN
PRACTICE/EC2/ec2-03.png
Normal file
|
After Width: | Height: | Size: 158 KiB |
BIN
PRACTICE/EC2/ec2-04.png
Normal file
|
After Width: | Height: | Size: 234 KiB |
BIN
PRACTICE/EC2/ec2-05.png
Normal file
|
After Width: | Height: | Size: 197 KiB |
BIN
PRACTICE/EC2/ec2-06.png
Normal file
|
After Width: | Height: | Size: 173 KiB |
BIN
PRACTICE/EC2/ec2-07.png
Normal file
|
After Width: | Height: | Size: 254 KiB |
BIN
PRACTICE/EC2/ec2-08.png
Normal file
|
After Width: | Height: | Size: 337 KiB |
BIN
PRACTICE/EC2/ec2-09.png
Normal file
|
After Width: | Height: | Size: 383 KiB |
BIN
PRACTICE/EC2/ec2-10.png
Normal file
|
After Width: | Height: | Size: 536 KiB |
BIN
PRACTICE/EC2/ec2-11.png
Normal file
|
After Width: | Height: | Size: 538 KiB |
@@ -0,0 +1,292 @@
|
|||||||
|
# S3 Static Website Hosting
|
||||||
|
|
||||||
|
## What is S3 Static Website Hosting?
|
||||||
|
|
||||||
|
**Amazon S3 (Simple Storage Service)** can host static websites directly from a bucket without requiring a traditional web server. When you enable static website hosting on an S3 bucket, AWS provides a unique endpoint URL that serves your HTML, CSS, JavaScript, and image files to anyone on the internet — as long as you configure the bucket for public read access and attach the appropriate bucket policy. This is a cost-effective, highly available, and scalable solution for hosting personal websites, single-page applications, documentation sites, landing pages, and portfolios. Unlike dynamic websites that require backend servers and databases, S3 static hosting is ideal for content that doesn't change based on user interactions or server-side processing.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lab Overview
|
||||||
|
|
||||||
|
| Resource | Name / Value |
|
||||||
|
|---|---|
|
||||||
|
| S3 Bucket | `your-unique-bucket-name` |
|
||||||
|
| Bucket Policy | Allow public `GetObject` |
|
||||||
|
| Static Website Hosting | Enabled |
|
||||||
|
| Index Document | `index.html` |
|
||||||
|
| Region | `ap-south-1` (or your preferred region) |
|
||||||
|
| Bucket Website Endpoint | `http://<bucket-name>.s3-website-<region>.amazonaws.com` |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Video Demo
|
||||||
|
|
||||||
|
[](https://youtu.be/klEGEw2O6q0)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step-by-Step Walkthrough
|
||||||
|
|
||||||
|
### Step 1 — Open AWS Console and Navigate to S3
|
||||||
|
|
||||||
|
Log in to the AWS Management Console and search for **S3** in the services search bar, then click on S3 to open the S3 dashboard.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 2 — Create an S3 Bucket
|
||||||
|
|
||||||
|
#### 2a — Click Create bucket
|
||||||
|
|
||||||
|
In the S3 dashboard, click **Create bucket** to begin the bucket creation wizard.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2b — Enter a unique bucket name
|
||||||
|
|
||||||
|
Enter a **globally unique bucket name**. Bucket names must be unique across all AWS accounts worldwide and must follow DNS naming conventions (lowercase letters, numbers, and hyphens only).
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2c — Uncheck "Block all public access"
|
||||||
|
|
||||||
|
Scroll down to the **Block Public Access settings** section and **uncheck "Block all public access"**. For static website hosting to work, your bucket must allow public read access to its objects.
|
||||||
|
|
||||||
|
> ⚠️ **Important:** Unchecking this setting means anyone with the URL can access files in this bucket. Only use this for content you intend to make publicly available.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 2d — Acknowledge the warning and create the bucket
|
||||||
|
|
||||||
|
Check the acknowledgment box confirming you understand the bucket will be public, then click **Create bucket** at the bottom of the page.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 3 — Upload Website Files
|
||||||
|
|
||||||
|
#### 3a — Open the bucket
|
||||||
|
|
||||||
|
The bucket is created successfully. Click on the **bucket name** to open it and view its contents.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 3b — Click Upload
|
||||||
|
|
||||||
|
Inside the bucket, click the **Upload** button to open the file upload wizard.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 3c — Add files
|
||||||
|
|
||||||
|
Click **Add files** or **Add folder** and select the static website files from your local machine (HTML, CSS, JavaScript, images, etc.).
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 3d — Upload the files
|
||||||
|
|
||||||
|
After selecting your files, scroll down and click **Upload** to transfer them to the S3 bucket.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 4 — Enable Static Website Hosting
|
||||||
|
|
||||||
|
#### 4a — Navigate to Properties tab
|
||||||
|
|
||||||
|
Click on the **Properties** tab at the top of the bucket page.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 4b — Find Static website hosting section
|
||||||
|
|
||||||
|
Scroll down to the **Static website hosting** section at the bottom of the Properties page.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 4c — Enable static website hosting
|
||||||
|
|
||||||
|
Click **Edit**, then select **Enable**. Choose **Host a static website** as the hosting type, and enter `index.html` as the **Index document** (the default page visitors see when they access your site).
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 4d — Save changes
|
||||||
|
|
||||||
|
Scroll down and click **Save changes** to apply the static website hosting configuration.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 5 — Configure Bucket Policy
|
||||||
|
|
||||||
|
#### 5a — Navigate to Permissions and edit bucket policy
|
||||||
|
|
||||||
|
Click the **Permissions** tab, scroll down to **Bucket policy**, and click **Edit**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 5b — Add a statement or use Policy generator
|
||||||
|
|
||||||
|
Click **Add statement** or **Policy generator** to create a new bucket policy. The policy generator helps you build the JSON policy without writing it manually.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 6 — Generate and Apply the Bucket Policy
|
||||||
|
|
||||||
|
#### 6a — Open AWS Policy Generator
|
||||||
|
|
||||||
|
If using the AWS Policy Generator, you'll see a form. Configure it as follows to allow public read access to all objects in the bucket.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Policy Settings:**
|
||||||
|
|
||||||
|
| Field | Value |
|
||||||
|
|---|---|
|
||||||
|
| **Effect** | Allow |
|
||||||
|
| **Principal** | `*` (anyone) |
|
||||||
|
| **Actions** | `GetObject` |
|
||||||
|
| **ARN** | `arn:aws:s3:::your-bucket-name/*` (replace with your bucket name and add `/*` at the end) |
|
||||||
|
|
||||||
|
#### 6b — Add statement and generate policy
|
||||||
|
|
||||||
|
After entering the settings above, click **Add Statement**, then click **Generate Policy**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 6c — Copy the generated policy
|
||||||
|
|
||||||
|
The policy generator will output a JSON policy. Click **Copy** to copy the entire policy to your clipboard.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Sample Bucket Policy:**
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"Version": "2012-10-17",
|
||||||
|
"Statement": [
|
||||||
|
{
|
||||||
|
"Sid": "PublicReadGetObject",
|
||||||
|
"Effect": "Allow",
|
||||||
|
"Principal": "*",
|
||||||
|
"Action": "s3:GetObject",
|
||||||
|
"Resource": "arn:aws:s3:::your-bucket-name/*"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
> **Note:** Replace `your-bucket-name` with your actual bucket name.
|
||||||
|
|
||||||
|
#### 6d — Paste the policy and save changes
|
||||||
|
|
||||||
|
Return to the bucket policy editor, paste the policy JSON, and click **Save changes**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 6e — Bucket policy created successfully
|
||||||
|
|
||||||
|
You'll see a confirmation that the bucket policy has been successfully applied.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 7 — Access Your Website
|
||||||
|
|
||||||
|
#### 7a — Return to Properties tab
|
||||||
|
|
||||||
|
Click the **Properties** tab again.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 7b — Copy the bucket website endpoint
|
||||||
|
|
||||||
|
Scroll down to the **Static website hosting** section and copy the **Bucket website endpoint** URL.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 7c — Open the website in your browser
|
||||||
|
|
||||||
|
Paste the endpoint URL into your browser's address bar and press Enter. Your static website is now live and publicly accessible! 🎉
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 8 — Clean Up Resources (Empty the Bucket)
|
||||||
|
|
||||||
|
#### 8a — Empty the bucket
|
||||||
|
|
||||||
|
To delete a bucket, you must first empty it. Select the bucket (or open it) and click **Empty**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 8b — Confirm deletion of objects
|
||||||
|
|
||||||
|
Type `permanently delete` in the confirmation field and click **Delete objects**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Step 9 — Delete the S3 Bucket
|
||||||
|
|
||||||
|
#### 9a — Select the bucket and click Delete
|
||||||
|
|
||||||
|
After emptying the bucket, select it from the S3 dashboard and click **Delete**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 9b — Confirm bucket deletion
|
||||||
|
|
||||||
|
Type the **bucket name** exactly as shown to confirm permanent deletion, then click **Delete bucket**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
#### 9c — Bucket deleted successfully
|
||||||
|
|
||||||
|
The bucket and all its configurations are now permanently deleted.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Key Points to Remember
|
||||||
|
|
||||||
|
| Point | Details |
|
||||||
|
|---|---|
|
||||||
|
| **Bucket names must be globally unique** | No two buckets can have the same name across all AWS accounts worldwide |
|
||||||
|
| **Public access is required** | Static website hosting requires public read access via bucket policy |
|
||||||
|
| **Bucket policy syntax** | Must allow `s3:GetObject` action for `Principal: "*"` on `Resource: "arn:aws:s3:::bucket-name/*"` |
|
||||||
|
| **Index document** | Always specify `index.html` or your custom default page |
|
||||||
|
| **Endpoint URL format** | `http://<bucket-name>.s3-website-<region>.amazonaws.com` |
|
||||||
|
| **HTTPS not supported by default** | Use Amazon CloudFront for HTTPS and custom domains |
|
||||||
|
| **Cost efficiency** | Free tier includes 5GB storage, 20,000 GET requests, and 2,000 PUT requests per month (first 12 months) |
|
||||||
|
| **Always clean up** | Delete buckets and objects when no longer needed to avoid charges |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Use Cases
|
||||||
|
|
||||||
|
- 📄 Personal websites and blogs
|
||||||
|
- 🚀 Single-page applications (SPAs)
|
||||||
|
- 📚 Documentation sites
|
||||||
|
- 🎨 Portfolio websites
|
||||||
|
- 📱 Landing pages
|
||||||
|
- 🧪 Prototype hosting and demos
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Additional Resources
|
||||||
|
|
||||||
|
- [AWS S3 Static Website Hosting Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html)
|
||||||
|
- [S3 Pricing](https://aws.amazon.com/s3/pricing/)
|
||||||
|
- [Using CloudFront with S3 for HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web.html)
|
||||||
|
After Width: | Height: | Size: 788 KiB |
|
After Width: | Height: | Size: 600 KiB |
|
After Width: | Height: | Size: 686 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 482 KiB |
|
After Width: | Height: | Size: 532 KiB |
|
After Width: | Height: | Size: 454 KiB |
|
After Width: | Height: | Size: 560 KiB |