rning | Flexible, interruption-tolerant work like batch jobs and data processing | | **Dedicated Hosts / Instances** | Run on hardware reserved only for your account | Licensing requirements or compliance rules that forbid shared hardware | Besides the instance itself, other things add to the bill: EBS volumes and snapshots, public IPv4 addresses, and data transferred out to the internet. --- ## Common Use Cases ### Hosting websites and web applications EC2 can run web servers like Apache, Nginx, or IIS to host websites, APIs, and full web applications. For high availability, instances can run in several Availability Zones behind a **load balancer**. ### Application and backend servers Business applications, internal tools, and backend services can run on EC2, often in **private subnets** where they're reachable only from other parts of the system and not directly from the internet. ### Databases Databases like MySQL, PostgreSQL, or MongoDB can be installed directly on EC2 when full control over the configuration is needed. AWS also offers managed database services such as Amazon RDS, which take care of backups, patching, and failover. ### Development and testing environments Developers can quickly launch servers that match production, test changes, and terminate them afterward, paying only for the hours used. ### Batch processing and data analysis Large jobs like processing logs, transforming data, or running reports can be spread across many instances, often using **Spot Instances** to cut costs. ### Machine learning and high-performance computing GPU instances train and run machine learning models, and compute-optimized instances handle scientific simulations, financial modeling, and rendering. ### Game servers Multiplayer game servers can run on EC2 in regions close to players to reduce lag, scaling up during busy times and down when traffic drops. ### Lift-and-shift migrations Companies moving to the cloud often start by moving their existing on-premises servers onto EC2 with few or no changes, since EC2 instances behave much like traditional servers. ### Remote desktops and Windows workloads Windows Server instances can host Windows-only applications and be accessed over **RDP**, as in a remote desktop setup. --- ## Scaling and High Availability - **Auto Scaling groups** automatically add instances when demand rises and remove them when it falls, and replace instances that fail health checks. - **Elastic Load Balancing** spreads incoming traffic across multiple instances, so no single instance is overloaded and one failure doesn't take the application down. - Running instances in **multiple Availability Zones** protects against a problem in a single data center. --- ## When EC2 Might Not Be the Best Fit Because EC2 gives full control over the server, it also comes with the responsibility of managing it. Other AWS services can be simpler for some workloads: | Need | Alternative | | --- | --- | | Run short pieces of code in response to events, without managing servers | **AWS Lambda** | | Run containerized applications | **Amazon ECS** or **Amazon EKS** (which can run on EC2 or on AWS Fargate) | | Deploy a web application without configuring servers | **AWS Elastic Beanstalk** | | Run a relational database without managing it | **Amazon RDS** or **Amazon Aurora** | | Host a static website | **Amazon S3** with **Amazon CloudFront** | --- ## Key Takeaways - EC2 provides **virtual servers** that can be launched in minutes and paid for only while they run. - An instance is defined by its **AMI** (what's installed), **instance type** (how powerful it is), **storage**, **network placement**, and **security group** (what traffic it allows). - **Stopping** an instance pauses compute charges but keeps its storage, while **terminating** deletes it permanently. - Choosing the right **pricing model** can significantly lower costs for long-running or flexible workloads. - EC2 is the most flexible way to run workloads on AWS, which makes it a good fit when full control over the server is needed.1b:T178a,## Summary In this lab I created a Windows Server 2019 EC2 instance in AWS, connected to it using Remote Desktop (RDP), retrieved the initial Administrator password by decrypting it with my `.pem` key file, and then changed the Windows password after logging in. ## Lab Environment | Setting | Value | | --- |---------------------------------------------------------| | Region | Canada (Central) `ca-central-1` | | Instance name | `MyNewEC2Window` | | AMI | Microsoft Windows Server 2019 Base (Free tier eligible) | | Instance type | `t3.micro` (2 vCPU, 1 GiB memory) | | Key pair | `demo` (RSA, `.pem`) | | Network | Default VPC, subnet in `ap-south-1a` | | Security group | `launch-wizard-80` (RDP, TCP 3389) | | Storage | 30 GiB gp2 root volume | --- ## Part 1: Launch the Instance ### 1. Open EC2 I searched for **EC2** in the AWS Console, opened the EC2 dashboard, went to **Instances**, and clicked **Launch instances**. ### 2. Name the instance Under **Name and tags**, I entered the name `MyNewEC2Windows`. ### 3. Choose the AMI (Amazon Machine Images) Under **Application and OS Images (Amazon Machine Image)**, I clicked **Browse more AMIs** and selected **Microsoft Windows Server 2019 Base** (Datacenter edition, English, 64-bit x86). Before selecting it, I checked that it was marked **Free tier eligible**. ### 4. Choose the instance type I selected `t3.micro`, which provides 2 virtual CPUs and 1 GiB of RAM and is free tier eligible. ### 5. Create a key pair Under **Key pair (login)**, I clicked **Create new key pair** and used these settings: - **Key pair name:** `demo` - **Key pair type:** RSA - **Private key file format:** `.pem` After clicking **Create key pair**, the `demo.pem` file downloaded automatically. I saved it somewhere safe, because AWS does not let you download it again and it is needed later to get the Windows password. ### 6. Configure network settings I clicked **Edit** in the **Network settings** section. - **VPC:** I kept the default VPC. - **Subnet:** I selected the subnet in `ca-central-1a`. The Central region has three Availability Zones (`ca-central-1a`, `ca-central-1b`, `ca-central-1d`). If no subnet is chosen, AWS picks the Availability Zone automatically. - **Auto-assign public IP:** Enabled, so the instance can be reached from the internet. ### 7. Configure the security group I chose **Create security group**. AWS gave it a default name (`launch-wizard-80`), which can be changed. For Windows instances, AWS adds an inbound rule for **RDP** by default: | Type | Protocol | Port | Source | | --- | --- | --- | --- | | RDP | TCP | 3389 | `0.0.0.0/0` (Anywhere) | Extra inbound rules can be added here if needed. ### 8. Configure storage I kept the default **30 GiB gp2** root volume. The root volume is like the hard drive on a laptop: it is where the operating system is installed. Free tier accounts get up to 30 GB of EBS storage. ### 9. Launch In the **Summary** panel, I left **Number of instances** at 1 and clicked **Launch instance**. ### 10. Wait for status checks The instance showed **Running**, but the status check said **Initializing**. I waited until it changed to **3/3 checks passed** before connecting. --- ## Part 2: Connect Using RDP ### 1. Download the RDP file I selected the instance, clicked **Connect**, opened the **RDP client** tab, and clicked **Download remote desktop file**. The page also shows the connection details: - **Public DNS:** `ec2-13-235-18-93.ap-south-1.compute.amazonaws.com` - **Username:** `Administrator` ### 2. Open the RDP file I opened the downloaded `.rdp` file and clicked **Continue** on the trust prompt. The login window asked for the Administrator password. ### 3. Get the Administrator password Back on the RDP client tab in the browser: 1. Clicked **Get password**. 2. Clicked **Upload private key file** and uploaded `demo.pem`. 3. Clicked **Decrypt password**. 4. Copied the decrypted password that appeared. ### 4. Log in I pasted the password into the Remote Desktop login window and clicked **Connect**. The Windows Server desktop loaded, with the instance details (hostname, instance ID, IP addresses, instance size, Availability Zone) shown in the top-right corner. --- ## Part 3: Change the Windows Password The decrypted password is long and random, so I changed it to one I can remember for future logins. 1. Clicked the **Start** (Windows) button and opened **Server Manager**. 2. Clicked **Tools** → **Computer Management**. 3. Went to **System Tools** → **Local Users and Groups** → **Users**. 4. Right-clicked **Administrator** and selected **Set Password...** 5. Entered and confirmed the new password. Next time I connect, I can log in with this new password instead of decrypting the original one. --- ## Key Takeaways - An **AMI** decides which operating system and software the instance starts with. - The **instance type** decides the CPU and memory (`t3.micro` = 2 vCPU, 1 GiB). - The **key pair** is required for Windows: the private `.pem` file decrypts the initial Administrator password. - The **security group** acts as a firewall; RDP needs inbound TCP port **3389** open. - The **root volume** is where the operating system is installed. - Choosing a **subnet** controls which Availability Zone the instance runs in. ## Security Notes - Allowing RDP from `0.0.0.0/0` lets anyone on the internet attempt to log in. For real use, the source should be limited to **My IP**. - The `.pem` file and the decrypted password should never be shared or committed to a repository. ## Cleanup To avoid charges after the lab, stop or terminate the instance from **Instance state** → **Terminate instance**, and delete the security group and key pair if they are no longer needed.1c:T1943,## Summary In this lab I created an Amazon Linux EC2 instance in AWS, configured its networking and security group, created a key pair, and connected to the instance over SSH from the Windows Command Prompt using the `.pem` key file and the instance's public IP address. ## Lab Environment | Setting | Value | | --- |-----------------------------------------------------| | Region | Canada (Central) `ca-central-1` | | Instance name | `MyFirstLinux` | | AMI | Amazon Linux 2023 (Quick Start, Free tier eligible) | | Instance type | `t3.micro` (2 vCPU, 1 GiB memory) | | Key pair | `demo` (RSA, `.pem`) | | Network | Default VPC, subnet in `ca-central-1a` | | Security group | New security group (SSH, TCP 22) | | Storage | 8 GiB gp3 root volume | | Login user | `ec2-user` | --- ## Part 1: Launch the Instance ### 1. Open EC2 I searched for **EC2** in the AWS Console, opened the EC2 dashboard, went to **Instances**, and clicked **Launch instances**. ### 2. Name the instance Under **Name and tags**, I entered the name `MyFirstLinux`. ### 3. Choose the AMI Under **Application and OS Images (Amazon Machine Image)**, I selected **Amazon Linux** from the **Quick Start** tab. Unlike the [Windows lab](/journal/aws/ec2/launching-connecting-windows-ec2-instance), I didn't need to browse more AMIs, since Amazon Linux is the default option. > **Note:** When selecting an AMI, note down the default SSH username displayed on the AMI details page. Different AMIs use different usernames: Amazon Linux uses `ec2-user`, Ubuntu uses `ubuntu`, Debian uses `admin`, and so on. We'll need this username to connect via SSH later. ### 4. Choose the instance type I selected `t3.micro`, which provides 2 virtual CPUs and 1 GiB of RAM and is free tier eligible. On-demand Linux pricing for this type is lower than Windows because there is no Windows license cost. ### 5. Create a key pair Under **Key pair (login)**, I clicked **Create new key pair** and used these settings: - **Key pair name:** `demo` - **Key pair type:** RSA - **Private key file format:** `.pem` (for use with OpenSSH) After clicking **Create key pair**, the `demo.pem` file downloaded automatically to my **Downloads** folder. I saved it, because it is the only way to log in to the instance over SSH and AWS will not let me download it again. ### 6. Configure network settings I clicked **Edit** in the **Network settings** section. - **VPC:** I kept the default VPC. - **Subnet:** I selected the subnet in `ca-central-1a`. The Mumbai region has three Availability Zones (`ca-central-1a`, `ca-central-1b`, `ca-central-1d`). If no subnet is chosen, AWS picks the Availability Zone automatically. - **Auto-assign public IP:** Enabled, so I can reach the instance from my computer. ### 7. Configure the security group I chose **Create security group** and kept the name AWS generated (it can be changed if needed). For Linux instances, AWS adds an inbound rule for **SSH** by default: | Type | Protocol | Port | Source | | --- | --- | --- | --- | | SSH | TCP | 22 | `0.0.0.0/0` (Anywhere) | Extra inbound rules can be added here if needed (for example HTTP on port 80 for a web server). ### 8. Configure storage I kept the default **8 GiB gp3** root volume (3000 IOPS). The root volume is like a laptop's hard drive: it's where the operating system is installed. Linux needs much less space than Windows, which defaulted to 30 GiB in the [Windows Lab](/journal/aws/ec2/launching-connecting-windows-ec2-instance). Free tier accounts get up to 30 GB of EBS storage. ### 9. Launch I clicked **Launch instance**, then went back to the **Instances** page and waited until the instance showed **Running** with **3/3 checks passed**. --- ## Part 2: Connect Using SSH Since the security group only allows SSH, I connected through the command line instead of a graphical desktop. ### 1. Copy the public IP I selected the instance and copied its **Public IPv4 address** from the **Details** tab. ### 2. Open Command Prompt and go to the key's folder The `demo.pem` file was in my Downloads folder, so I opened Command Prompt and moved into it: ```bash cd Downloads ``` ### 3. Connect with SSH I ran the `ssh` command with the key file (`-i`), the default Amazon Linux user (`ec2-user`), and the public IP: ```bash ssh -i demo.pem ec2-user@PUBLIC_IP_ADDRESS ``` ### 4. Accept the host fingerprint On the first connection, SSH warned that the host's authenticity couldn't be established and showed its ED25519 fingerprint. I typed `yes`, and the host was added to my list of known hosts. ### 5. Logged in The Amazon Linux 2023 banner appeared, followed by the shell prompt: ```bash [ec2-user@ip-xxx-xxx-xxx-xxx ~]$ ``` I was now connected to the Linux instance and could run commands on it. --- ## Key Takeaways - **Amazon Linux** is available directly from the Quick Start AMIs. - Linux instances are accessed through **SSH on port 22**, while Windows instances use **RDP on port 3389**. - Linux doesn't need a decrypted password: the **`.pem` private key** is used directly to log in. - The default username for Amazon Linux is **`ec2-user`** (other AMIs differ, for example `ubuntu` for Ubuntu). - The default Linux root volume (**8 GiB gp3**) is much smaller than the Windows one (30 GiB). ## Troubleshooting - **"Permission denied (publickey)":** check that you're using the right key file and the `ec2-user` username. - **"UNPROTECTED PRIVATE KEY FILE" or "bad permissions":** the `.pem` file is readable by other users. On Linux or macOS, run `chmod 400 demo.pem`. On Windows, remove other users' access to the file in its **Properties → Security** settings. - **Connection timed out:** confirm the instance is running, has a public IP, and the security group allows port 22. ## Security Notes - Allowing SSH from `0.0.0.0/0` lets anyone on the internet attempt to connect. For real use, the source should be limited to **My IP**. - The `.pem` file should never be shared or committed to a repository. ## Cleanup To avoid charges after the lab, terminate the instance from **Instance state** → **Terminate instance**, and delete the security group and key pair if they are no longer needed.1d:T20cf,## Summary In this lab I created a custom Amazon Machine Image (AMI) from a configured Windows EC2 instance. I launched a Windows Server 2019 instance, connected to it over RDP, installed the Web Server (IIS) and DHCP Server roles, and confirmed the IIS website was reachable from my browser. I then created an AMI from that instance, terminated the original, and launched a new instance from my custom AMI. The new instance served the same website without me logging in or installing anything on it. ## Lab Environment | Setting | Value | | --- | --- | | Region | Canada (Central) `ca-central-1` | | Original instance | `MyServer_AMI` | | Base AMI | Microsoft Windows Server 2019 Base (Free tier eligible) | | Instance type | `t3.micro` (2 vCPU, 1 GiB memory) | | Key pair | `demo` (RSA, `.pem`) | | Network | Default VPC, subnet in `ca-central-1a` | | Security group | New security group (RDP 3389, HTTP 80) | | Storage | 30 GiB gp2 root volume | | Custom AMI | `Custom_AMI` | | New instance | `MyServer_AMI2` | --- ## Part 1: Launching the Base Instance ### 1. Opened EC2 I searched for **EC2** in the AWS Console, opened the EC2 dashboard, went to **Instances**, and clicked **Launch instances**. ### 2. Named the instance Under **Name and tags**, I named the instance `MyServer_AMI`. ### 3. Chose the AMI Under **Application and OS Images**, I clicked **Browse more AMIs** and selected **Microsoft Windows Server 2019 Base** (Datacenter edition, English, 64-bit x86). I confirmed it was marked **Free tier eligible** before selecting it. ### 4. Chose the instance type I selected `t3.micro`, which gave me 2 virtual CPUs and 1 GiB of RAM and is free tier eligible. ### 5. Created a key pair I clicked **Create new key pair** and created a key named `demo` with the **RSA** type and **`.pem`** format. The private key downloaded automatically, and I saved it for retrieving the Windows password later. ### 6. Configured network settings I clicked **Edit** under **Network settings**. I kept the default VPC and selected the subnet in `ca-central-1a`. The Canada (Central) region has three Availability Zones (`ca-central-1a`, `ca-central-1b`, and `ca-central-1d`), and choosing a subnet let me decide which one the instance ran in. I left **Auto-assign public IP** enabled. ### 7. Configured the security group I chose **Create security group** and kept the name AWS generated. AWS added the RDP rule for Windows by default, and I added a second rule for HTTP so I could reach the web server from my browser: | Type | Protocol | Port | Source | | --- | --- | --- | --- | | RDP | TCP | 3389 | `0.0.0.0/0` | | Custom TCP | TCP | 80 | `0.0.0.0/0` | ### 8. Configured storage I kept the default **30 GiB gp2** root volume, which is where Windows is installed. ### 9. Launched the instance I left **Number of instances** at 1, clicked **Launch instance**, and waited for the status check to change from **Initializing** to **3/3 checks passed**. --- ## Part 2: Connecting and Installing Server Roles ### 1. Connected over RDP I selected the instance, clicked **Connect**, opened the **RDP client** tab, and clicked **Download remote desktop file**. I opened the downloaded file and clicked **Continue** on the trust prompt. ### 2. Retrieved the Administrator password Back in the console, I clicked **Get password**, uploaded my `demo.pem` file with **Upload private key file**, and clicked **Decrypt password**. I copied the decrypted password, pasted it into the Remote Desktop login window, and clicked **Connect**. The Windows Server desktop loaded. ### 3. Installed the Web Server and DHCP roles 1. I opened the **Start** menu and launched **Server Manager**. 2. I clicked **Add roles and features**. 3. On the **Server Roles** page, I checked **DHCP Server** and **Web Server (IIS)**. 4. I clicked **Next** through the remaining pages, kept the defaults, and clicked **Install** on the final page. ### 4. Changed the Administrator password After the installation finished, I went to **Tools** → **Computer Management** → **Local Users and Groups** → **Users**, right-clicked **Administrator**, selected **Set Password...**, and set a new password that I could remember. ### 5. Tested the website I went back to the EC2 console, copied the instance's **Public IPv4 address**, and opened it in a new browser tab using `http://` (not `https://`). The default **IIS (Internet Information Services) welcome page** loaded, which confirmed that the Web Server role was installed correctly and that port 80 was open in the security group. > **Note:** Use `http://` when accessing the server, not `https://`. SSL/TLS certificates are not installed by default, so HTTPS connections will fail. --- ## Part 3: Creating the Custom AMI ### 1. Created the image In the EC2 console, I selected `MyServer_AMI`, right-clicked on it, and selected **Image and templates** → **Create image**. I named the image `Custom_AMI` and left **Reboot instance** checked so that EC2 would reboot the instance and take consistent snapshots of its volumes. Then I clicked **Create image**. ### 2. Waited for the AMI to become available I opened **Images** → **AMIs** in the left menu. `Custom_AMI` appeared with a status of **Pending**, and I waited until it changed to **Available**. ### 3. Terminated the original instance Once the AMI was available, I terminated `MyServer_AMI`. This showed that everything I needed was now stored in the image rather than in the original instance. --- ## Part 4: Launching an Instance from the Custom AMI ### 1. Launched a new instance I clicked **Launch instances** and named the new instance `MyServer_AMI2`. Under **Application and OS Images**, I opened the **My AMIs** tab, selected **Owned by me**, and chose `Custom_AMI`. ### 2. Used the same settings as before I configured everything else the same way as the first instance: `t3.micro`, the `demo` key pair, the default VPC with a subnet in `ca-central-1a`, a security group allowing RDP (3389) and HTTP (80), and a 30 GiB root volume. Then I launched it. ### 3. Tested the website on the new instance I waited for **3/3 checks passed**, copied the new instance's public IPv4 address, and opened it in my browser. The same IIS welcome page loaded. I never connected to `MyServer_AMI2` or installed any roles on it. The website worked because the new instance was built from my custom image, which already contained Windows Server with IIS and DHCP installed. --- ## What I Learned - An **AMI** is a template that captures an instance's operating system, installed software, and configuration. - A **custom AMI** let me configure a server once and reuse that setup for new instances, instead of repeating the installation steps each time. - When I created the image, EC2 took **EBS snapshots** of the instance's volumes. The AMI depends on those snapshots. - Leaving **Reboot instance** checked made EC2 restart the instance before taking snapshots, so the data was in a consistent state. - Custom AMIs appear under **My AMIs → Owned by me** when launching an instance, and they are **private** by default. - To reach a web server running on the instance, I had to add an inbound rule for **port 80** to the security group. - Since I didn't run Sysprep before creating the image, the new instance would keep the same Administrator password I had set on the original. ## Cleanup To avoid ongoing storage charges after the lab: 1. **Terminate the instance:** Go to **Instances**, select `MyServer_AMI2`, click **Instance state** → **Terminate instance**. 2. **Deregister the AMI:** Go to **Images** → **AMIs**, select `Custom_AMI`, click **Actions** → **Deregister AMI**. 3. **Delete the EBS snapshot:** Go to **Elastic Block Store** → **Snapshots**, find the snapshot associated with your AMI (check the description), select it, and click **Actions** → **Delete snapshot**. > **Note:** Deregistering an AMI does not automatically delete its underlying EBS snapshot. You must delete the snapshot separately to stop incurring storage costs. ## Notes - Both inbound rules allowed traffic from `0.0.0.0/0`. That was fine for a short lab, but in a real setup I would restrict RDP to my own IP address. - A custom AMI keeps costing storage until it is deregistered and its EBS snapshot is deleted. Deregistering the AMI alone does not remove the snapshot.1e:T1b2e,## Summary In this lab I worked with EC2 from the command line instead of the AWS Console. I installed the AWS CLI, created an IAM access key, and configured my credentials and default region. Then I used CLI commands to create a security group, add an inbound RDP rule, and create a key pair. I launched a Windows Server 2016 instance with `run-instances`, confirmed it in the console, and terminated it with `terminate-instances` using its instance ID. ## Lab Environment | Setting | Value | | --- | --- | | Region | Canada (Central) `ca-central-1` | | Tool | AWS CLI v2 on Windows Command Prompt | | Output format | `json` | | Security group | `awsclitraining` (RDP, TCP 3389) | | Key pair | `cliKeyPair` (saved as `clikeyPair.pem`) | | AMI | Microsoft Windows Server 2016 Base | | Instance type | `t2.micro` | | Subnet | Default subnet in `ca-central-1a` | --- ## Part 1: Installing and Configuring the AWS CLI ### 1. Installed the AWS CLI I downloaded the AWS CLI v2 installer for Windows from the AWS website and ran it. After the installation finished, I opened Command Prompt. ### 2. Started the configuration I ran: ```bash aws configure ``` The CLI prompted me for an **AWS Access Key ID**, so I needed to create an access key first. ### 3. Created an access key In the AWS Console, I clicked my account name in the top-right corner and selected **Security credentials**. In the **Access keys** section, I clicked **Create access key**. On the **Access key best practices & alternatives** page, I selected **Command Line Interface (CLI)** as the use case and clicked **Next**. I skipped the optional description tag and clicked **Create access key**. The **Retrieve access keys** page showed my **Access key** and **Secret access key**. The secret is only shown once, so I copied both before leaving the page. ### 4. Entered my credentials Back in Command Prompt, I pasted the access key and secret access key when prompted, then set the default region and output format: ```bash AWS Access Key ID: **************** AWS Secret Access Key: **************** Default region name: ca-central-1 Default output format: json ``` From then on, every command I ran used these credentials and targeted `ca-central-1` unless I specified otherwise. --- ## Part 2: Creating a Security Group and Key Pair ### 1. Created a security group I ran: ```bash aws ec2 create-security-group --group-name awsclitraining --description "test sg from cli" ``` The command returned JSON with the new security group's `GroupId` and `SecurityGroupArn`. Because I didn't specify a VPC, the group was created in my default VPC. I copied the `GroupId` (it starts with `sg-`) into Notepad because I needed it to launch the instance. ### 2. Allowed RDP traffic I added an inbound rule for RDP on port 3389: ```bash aws ec2 authorize-security-group-ingress --group-name awsclitraining --protocol tcp --port 3389 --cidr 0.0.0.0/0 ``` ### 3. Created a key pair I created a key pair and saved its private key straight to a file: ```bash aws ec2 create-key-pair --key-name cliKeyPair --query "KeyMaterial" --output text > clikeyPair.pem ``` The `--query "KeyMaterial"` option pulled only the private key out of the JSON response, `--output text` printed it as plain text, and `>` saved it into `clikeyPair.pem` in my current folder. --- ## Part 3: Gathering the AMI ID and Subnet ID ### 1. Found the AMI ID In the EC2 console, I clicked **Launch instance**, scrolled to **Application and OS Images**, and clicked **Browse more AMIs**. I found **Microsoft Windows Server 2016 Base** and copied its AMI ID into Notepad. I didn't launch anything from the console; I only needed the ID. AMI IDs differ by region, so I made sure the console was set to Canada (Central) when I copied it. ### 2. Found the subnet ID I opened the **VPC** console and went to **Subnets**. I selected the default subnet in `ca-central-1a`, copied its **Subnet ID** from the details panel, and added it to Notepad. I picked a subnet from the default VPC because that's where my security group was created. The security group and subnet must belong to the same VPC. --- ## Part 4: Launching and Terminating the Instance ### 1. Launched the instance With the three IDs in Notepad, I filled them into the `run-instances` command: ```bash aws ec2 run-instances --image-id AMI_ID --count 1 --instance-type t2.micro --key-name cliKeyPair --security-group-ids SECURITY_GROUP_ID --subnet-id SUBNET_ID ``` | Option | What I passed | | --- | --- | | `--image-id` | The Windows Server 2016 Base AMI ID | | `--count` | `1` instance | | `--instance-type` | `t2.micro` | | `--key-name` | `cliKeyPair` | | `--security-group-ids` | The `GroupId` of `awsclitraining` | | `--subnet-id` | The default subnet in `ca-central-1a` | ### 2. Confirmed it in the console I opened **EC2 → Instances** and saw the new `t2.micro` instance in `ca-central-1a`. It had no name, since I didn't add a `Name` tag in the command. After a few minutes it reached **Running** with **2/2 checks passed**. I copied its instance ID for the next step. ### 3. Terminated the instance Back in Command Prompt, I ran: ```bash aws ec2 terminate-instances --instance-ids INSTANCE_ID ``` The response showed the instance's `PreviousState` as `running` (code 16) and its `CurrentState` as `shutting-down` (code 32). ### 4. Confirmed termination I refreshed the **Instances** page in the console, and the instance state showed **Terminated**. --- ## What I Learned - The AWS CLI lets me do the same things as the console with commands, which is faster to repeat and easier to script. - `aws configure` stores my access key, secret key, default region, and output format, so I don't have to pass them with every command. - **Access keys** are long-term credentials tied to my IAM user. The secret access key is only shown once when the key is created. - `create-security-group` and `authorize-security-group-ingress` are the CLI equivalents of creating a security group and adding inbound rules in the console. - `--query` and `--output text` let me pull a single value out of a JSON response, which is how I saved the private key directly to a `.pem` file. - `run-instances` needs the IDs of the resources it uses (AMI, security group, subnet), so I had to collect them before launching. - The instance state codes in the CLI output match the console: 16 is `running`, 32 is `shutting-down`, and 48 is `terminated`. ## Notes - The RDP rule allowed traffic from `0.0.0.0/0`. That was fine for this short lab, but in a real setup I would limit it to my own IP address. - Terminating the instance didn't remove the `awsclitraining` security group or the `cliKeyPair` key pair; those stay in the account until deleted with `delete-security-group` and `delete-key-pair`. - Since access keys give full CLI access as my IAM user, I deactivated and deleted the key in **Security credentials** after finishing the lab.1f:T3169,## Summary In this lab I worked with DNS records in **Amazon Route 53**. I launched an Amazon Linux [EC2](/journal/aws/ec2/introduction-to-amazon-ec2) instance, installed the Apache web server, and published a simple web page. I created a public hosted zone and added an **A record** named `learn` that pointed to the instance's public IP. I then created a **CNAME record** named `test` that pointed to `learn.YOUR_DOMAIN`. I didn't own a registered domain, so instead of opening the names in a browser, I verified both records by asking Route 53 directly, with the console's **Test record** tool and with `nslookup` against the hosted zone's own name servers. Finally, I reviewed the purpose of the other common record types: AAAA, MX, TXT, PTR, SRV, and SPF. ## Lab Environment | Setting | Value | | --- | --- | | Region | Canada (Central) `ca-central-1` | | Instance | Amazon Linux, in a public subnet in `ca-central-1a`, with a public IP | | Security group inbound | SSH (TCP 22) and HTTP (TCP 80) | | Web server | Apache (`httpd`) | | Hosted zone | A **public** hosted zone I created for `YOUR_DOMAIN`, a domain name I didn't register | DNS records created: | Record name | Type | Value | Purpose | | --- | --- | --- | --- | | `learn.YOUR_DOMAIN` | A | The instance's public IPv4 address | Points the name straight at the web server | | `test.YOUR_DOMAIN` | CNAME | `learn.YOUR_DOMAIN` | A second name that follows the first | Route 53 is a **global** service, so the hosted zone and its records weren't tied to Canada (Central). Only the EC2 instance lived in that region. --- ## Part 1: Creating the Hosted Zone I opened the **Route 53** console, went to **Hosted zones**, and clicked **Create hosted zone**. I entered `YOUR_DOMAIN` as the **Domain name**, chose **Public hosted zone**, and clicked **Create hosted zone**. A public hosted zone holds the DNS records that answer lookups for a domain. Route 53 created two records in the zone automatically: - **NS:** the four Route 53 name servers that hold this zone's records, such as `ns-123.awsdns-45.com`. - **SOA:** basic information about the zone itself. I left both alone, and noted one of the **NS** values for testing later. I didn't register the domain, so this zone existed only inside Route 53. Normally, a domain's **registrar** tells the internet which name servers to ask about it. Since no registrar pointed anywhere at these four name servers, the rest of the internet would never send lookups for `YOUR_DOMAIN` to my zone. The records would still work, but only when I asked Route 53's name servers directly. --- ## Part 2: Launching and Configuring the Web Server ### 1. Launched the instance In the EC2 console, I launched an **Amazon Linux** instance in a public subnet in `ca-central-1a`, with **Auto-assign public IP** enabled and an existing key pair. Its security group allowed: | Type | Protocol | Port | Source | Reason | | --- | --- | --- | --- | --- | | SSH | TCP | 22 | `0.0.0.0/0` | Lets me connect from my computer to install the web server | | HTTP | TCP | 80 | `0.0.0.0/0` | Lets anyone load the website in a browser | I waited until the instance showed **Running**. ### 2. Connected over SSH From Command Prompt, in the folder with my key: ```bash ssh -i KEY_NAME.pem ec2-user@EC2_PUBLIC_IP ``` ### 3. Installed Apache ```bash sudo yum update -y sudo yum install -y httpd sudo systemctl start httpd sudo systemctl enable httpd ``` `start` launched the web server right away, and `enable` made it start automatically whenever the instance rebooted. ### 4. Created the web page I wrote a simple HTML page to Apache's web folder: ```bash sudo tee /var/www/html/index.html > /dev/null <<'EOF' Route 53 Record Types Demo

Route 53 Record Types Lab

This page is served from an EC2 web server.

EOF ``` Then I gave the file to Apache's user and made it readable: ```bash sudo chown apache:apache /var/www/html/index.html sudo chmod 644 /var/www/html/index.html ``` ### 5. Verified the web server On the instance: ```bash curl -s localhost ``` It printed the HTML of my page. Then I opened `http://EC2_PUBLIC_IP` in my browser and the page loaded, confirming the server was reachable from the internet before I added any DNS. --- ## Part 3: Creating the A Record Back in the hosted zone, I clicked **Create record** and entered: | Setting | Value | | --- | --- | | Record name | `learn` | | Record type | A – Routes traffic to an IPv4 address | | Value | The instance's public IPv4 address | | TTL | 300 seconds (default) | | Routing policy | Simple routing | I clicked **Create records**. The full name became `learn.YOUR_DOMAIN`, because the record name is added in front of the hosted zone's domain. The **TTL (time to live)** is how long, in seconds, other DNS servers and browsers can remember the answer before asking Route 53 again. With 300 seconds, a change to the record can take up to 5 minutes to reach everyone. --- ## Part 4: Verifying the A Record Without a registered domain, opening `http://learn.YOUR_DOMAIN` in a browser wouldn't work, because my computer's DNS would never find my hosted zone. So I checked the record against Route 53 directly, in two ways. ### 1. Test record in the console In the hosted zone, I clicked **Test record**, entered `learn` as the **Record name**, chose **A** as the **Type**, and clicked **Get response**. Route 53 answered with: | Field | Value | | --- | --- | | Response returned | The instance's public IPv4 address | | Response code | `NOERROR` | `NOERROR` meant the name existed and Route 53 returned an answer. ### 2. nslookup against the zone's name server From my computer's Command Prompt, I asked one of the zone's own name servers instead of my usual DNS server: ```bash nslookup learn.YOUR_DOMAIN ns-123.awsdns-45.com ``` using one of the actual NS values from the hosted zone. It returned the instance's public IP, the same answer as the console. Adding the name server at the end of `nslookup` is what made this work. Without it, my computer would ask its normal DNS server, which would have no idea where to find `YOUR_DOMAIN` and would answer that the name doesn't exist. --- ## Part 5: Creating the CNAME Record I clicked **Create record** again and entered: | Setting | Value | | --- | --- | | Record name | `test` | | Record type | CNAME – Routes traffic to another domain name | | Value | `learn.YOUR_DOMAIN` | | TTL | 300 seconds (default) | I clicked **Create records**. A **CNAME** doesn't point to an IP address. It says "this name is another name for that name." When someone looks up `test.YOUR_DOMAIN`, DNS answers with `learn.YOUR_DOMAIN`, then looks that up to get the IP. --- ## Part 6: Verifying the CNAME Record ### 1. Test record in the console In **Test record**, I entered `test` as the **Record name**, chose **CNAME** as the **Type**, and clicked **Get response**. Route 53 answered with `learn.YOUR_DOMAIN` and a response code of `NOERROR`. The answer was a **name**, not an IP address, because a CNAME only says which other name to look up next. ### 2. nslookup against the zone's name server ```bash nslookup test.YOUR_DOMAIN ns-123.awsdns-45.com ``` The result showed `test.YOUR_DOMAIN` as an **alias** (canonical name) of `learn.YOUR_DOMAIN`, followed by the instance's public IP. Because both names were in the same hosted zone, Route 53 followed the CNAME to the A record and returned both answers together. Both names led to the same IP, so with a registered domain, both would open the same website. If the instance's IP ever changed, I'd only need to update the `learn` A record, and `test` would follow it automatically. A CNAME isn't a redirect. In a browser, the address bar would keep showing `test.YOUR_DOMAIN`. DNS just follows the CNAME behind the scenes to find the IP, and the web server answers for whichever name was used. --- ## Part 7: Reviewing Other Record Types | Record type | What it does | Example use | | --- | --- | --- | | **A** | Maps a name to an **IPv4** address | `learn.YOUR_DOMAIN` → `15.157.0.10` | | **AAAA** | Maps a name to an **IPv6** address | The same as A, for IPv6 networks | | **CNAME** | Makes a name an **alias** of another name | `test.YOUR_DOMAIN` → `learn.YOUR_DOMAIN` | | **MX** | Lists the **mail servers** that receive email for the domain, with priorities | Email for `@YOUR_DOMAIN` goes to Google Workspace or Microsoft 365 | | **TXT** | Stores **text**, often used to prove ownership or set email security policies | Verifying the domain with Google, or publishing SPF and DMARC policies | | **PTR** | **Reverse lookup**: maps an IP address back to a name | Mail servers checking that a sending IP has a matching name | | **SRV** | Says which **host and port** offer a specific service | Finding Active Directory or SIP servers | | **SPF** | Lists the servers allowed to **send** email for the domain | Helping receiving servers reject spoofed email | --- ## What I Learned - A domain only resolves on the internet when its **registrar** points to the hosted zone's **name servers**. Without that link, a public hosted zone's records still work, but only when Route 53's name servers are asked directly, with **Test record** or `nslookup NAME NAME_SERVER`. - A **hosted zone** holds all the DNS records for a domain. A **public** hosted zone answers lookups from the internet, and a **private** one answers only inside linked VPCs. - An **A record** points a name directly at an IPv4 address, which is the simplest way to put a website on a domain. - A **CNAME** points a name at **another name**, not an IP. Updating the target record updates every CNAME pointing to it. - A **CNAME can't be used on the root domain** (`YOUR_DOMAIN` itself), and a name with a CNAME can't have any other records. Route 53's **Alias** records solve this for AWS resources like load balancers and CloudFront. - A CNAME is **not a redirect**. The address bar keeps the name the user typed, and the website just needs to respond to it. Apache's default setup answers for any name, which is why `test.YOUR_DOMAIN` worked without changing the server. - **TTL** controls how long other DNS servers cache an answer. A shorter TTL means changes spread faster, at the cost of more DNS queries. - **Route 53 is global**, so its records aren't tied to a region, even though the resources they point to are. - Pointing an A record at an instance's **auto-assigned public IP** is fragile: the IP changes if the instance is stopped and started, and the record would point to the wrong address. An **Elastic IP**, or an Alias record pointing to a load balancer, keeps the name working. ## Notes - The **SPF record type** still exists in Route 53, but it's deprecated in the DNS standards. SPF policies are now published as **TXT** records instead. - **PTR** records for EC2 public IPs aren't created in your own hosted zone. AWS owns those IP ranges, so reverse DNS for an **Elastic IP** is set through EC2. - The provided `index.html` was originally titled "CloudFront Origin Group Demo", reused from another lab. I used a simpler page with a title matching this lab, which works the same way. --- ## Cleanup The running instance and its public IPv4 address were billed by the hour. The hosted zone is billed monthly, and leaving records that point at a released IP is a bad habit, since that IP might later belong to someone else. I deleted everything from this lab: ### 1. Deleted the DNS records In the hosted zone, I selected the `test` CNAME record and the `learn` A record, clicked **Delete records**, and confirmed. The **NS** and **SOA** records can't be deleted on their own; they're removed along with the zone. ### 2. Terminated the instance In the EC2 console, I selected the instance and clicked **Instance state** → **Terminate (delete) instance**. This also deleted its root volume and released its public IP. ### 3. Deleted the security group Once the instance showed **Terminated**, I deleted the security group created for it. ### 4. Deleted the hosted zone The hosted zone was created just for this lab, so I deleted it too. With only the NS and SOA records left, I selected the zone in **Hosted zones**, clicked **Delete**, and confirmed. A hosted zone can't be deleted while it still contains other records, which is why the A and CNAME records had to go first. A hosted zone is billed monthly, but AWS doesn't charge for one that's deleted within 12 hours of being created, so deleting it right after the lab meant it cost nothing.20:T28ed,## Summary In this lab I used a **weighted routing policy** in Amazon Route 53 to share traffic between two EC2 web servers running in different Availability Zones. I created two **A records with the same name**, `learn.sakibs-domain.com`, each pointing to one server's public IP and each given a **weight** of 50. Route 53 then answered lookups for that name with one IP or the other, in proportion to the weights. I didn't own a registered domain, so I verified the distribution by querying the hosted zone's own name server many times and counting how often each IP came back. Finally, I reviewed how **health checks** let Route 53 stop sending traffic to a server that goes down. ## Lab Environment | Setting | Value | | --- | --- | | Region | Canada (Central) `ca-central-1` | | VPC | Default VPC | | `Web-Server-1` | Amazon Linux with Apache, default subnet in `ca-central-1a`, public IP | | `Web-Server-2` | Amazon Linux with Apache, default subnet in `ca-central-1b`, public IP | | Security group inbound | SSH (TCP 22) and HTTP (TCP 80) from `0.0.0.0/0` | | Hosted zone | Public hosted zone for `sakibs-domain.com` (not registered) | | Name server used for testing | `ns-315.awsdns-39.com` | Weighted records: | Record name | Type | Value | Routing policy | Weight | Record ID | | --- | --- | --- | --- | --- | --- | | `learn.sakibs-domain.com` | A | `Web-Server-1`'s public IP | Weighted | 50 | `record-1` | | `learn.sakibs-domain.com` | A | `Web-Server-2`'s public IP | Weighted | 50 | `record-2` | --- ## Part 1: Preparing the Web Servers ### 1. Launched two web servers I followed Parts 1 and 2 of the **Route 53 record types** lab twice, launching two Amazon Linux instances in the **default VPC**, each running Apache with the same web page: | Instance | Availability Zone | | --- | --- | | `Web-Server-1` | `ca-central-1a` | | `Web-Server-2` | `ca-central-1b` | Putting them in **different Availability Zones** meant that a problem in one AZ wouldn't take down both servers, which is the point of spreading traffic across them. Both used a security group allowing **SSH (22)** for setup and **HTTP (80)** for the website. ### 2. Verified both servers I opened `http://WEB_SERVER_1_PUBLIC_IP` and `http://WEB_SERVER_2_PUBLIC_IP` in my browser, and both showed the same page. I noted each server's **public IPv4 address** for the DNS records. ### 3. Removed the old `learn` record The `learn` A record from the record types lab used the **simple** routing policy. Route 53 doesn't allow a simple record and weighted records with the same name and type at the same time, so I deleted the old `learn` A record from the hosted zone first. I also deleted the `test` CNAME, since it pointed to `learn` and wasn't part of this lab. --- ## Part 2: Creating the First Weighted Record In the Route 53 console, I opened the `sakibs-domain.com` hosted zone, clicked **Create record**, and entered: | Setting | Value | | --- | --- | | Record name | `learn` | | Record type | A | | Value | `Web-Server-1`'s public IPv4 address | | TTL | 60 seconds | | Routing policy | Weighted | | Weight | 50 | | Record ID | `record-1` | I clicked **Create records**. - The **weight** is a number from 0 to 255 that controls how often this record's answer is returned compared with other records of the same name. - The **record ID** is a label that tells apart records sharing the same name and type. It has to be unique among them. - I lowered the **TTL** to 60 seconds, so changes to the weights would take effect faster during testing. --- ## Part 3: Creating the Second Weighted Record I clicked **Create record** again and entered: | Setting | Value | | --- | --- | | Record name | `learn` | | Record type | A | | Value | `Web-Server-2`'s public IPv4 address | | TTL | 60 seconds | | Routing policy | Weighted | | Weight | 50 | | Record ID | `record-2` | I clicked **Create records**. The hosted zone now listed **two** A records named `learn.sakibs-domain.com`, one with record ID `record-1` and one with `record-2`. Normally, a name can only have one record of each type. Routing policies like weighted are the exception: they allow several records with the same name and type, and Route 53 chooses between them for each lookup. --- ## Part 4: Testing the Weighted Routing Policy ### 1. Test record in the console In the hosted zone, I clicked **Test record**, entered `learn` as the record name and **A** as the type, and clicked **Get response** several times. The returned IP switched between `Web-Server-1` and `Web-Server-2`, rather than always being the same. ### 2. nslookup against the name server From PowerShell on my computer, I asked the hosted zone's name server directly: ```bash nslookup learn.sakibs-domain.com ns-315.awsdns-39.com ``` Running it several times returned one IP or the other each time. Each lookup returns **only one** of the two IPs. Route 53 picks which one for each query, based on the weights. --- ## Part 5: Measuring the Weight Distribution ### 1. Ran many lookups at once To see the pattern, I ran 20 lookups in a row in PowerShell and counted how often each IP came back: ```powershell 1..20 | ForEach-Object { (Resolve-DnsName learn.sakibs-domain.com -Server ns-315.awsdns-39.com -Type A).IPAddress } | Group-Object | Select-Object Count, Name ``` With both weights at 50, each IP came back roughly half the time. The split wasn't exactly 10 and 10, because Route 53 chooses randomly for each query according to the weights. Over many queries, the counts get closer to the expected percentages. ### 2. Calculated the expected traffic share Route 53 calculates each record's share of traffic like this: > **Traffic percentage = (record's weight ÷ total of all weights) × 100** | Weights | `Web-Server-1` share | `Web-Server-2` share | | --- | --- | --- | | 50 and 50 | 50 ÷ 100 = **50%** | 50 ÷ 100 = **50%** | | 70 and 30 | 70 ÷ 100 = **70%** | 30 ÷ 100 = **30%** | | 1 and 3 | 1 ÷ 4 = **25%** | 3 ÷ 4 = **75%** | | 100 and 0 | **100%** | **0%** | The weights don't need to add up to 100. Only their proportions matter, so 1 and 1 behaves exactly like 50 and 50. A weight of **0** means Route 53 never returns that record, unless **every** record with that name has a weight of 0, in which case they're all returned equally. Setting a weight to 0 is a quick way to take a server out of rotation without deleting its record. ### 3. Why querying the name server mattered The original lab used Google's public resolver (`8.8.8.8`) for this test, which requires a registered domain. Querying the hosted zone's **own name server** had an extra advantage: it skipped **caching**. A resolver like `8.8.8.8` remembers an answer for the record's TTL, so repeated lookups through it can keep returning the same IP even though Route 53 would choose differently. Asking `ns-315.awsdns-39.com` directly gave a fresh choice on every query. --- ## Part 6: Understanding Route 53 Health Checks So far, Route 53 had no idea whether either server was actually working. If `Web-Server-2` crashed, Route 53 would keep returning its IP for about half of all lookups, and those users would get an error. A **health check** solves this: 1. Route 53 sends a request to the server from locations around the world every 10 or 30 seconds, for example an HTTP request to port 80. 2. If enough checks fail in a row, Route 53 marks the server **unhealthy**. 3. When a weighted record is linked to a health check, Route 53 **stops returning that record's IP** while it's unhealthy, and sends all traffic to the remaining healthy records. 4. When the server passes its checks again, Route 53 brings it back and resumes splitting traffic by the configured weights. To set this up, I would create a health check under **Route 53 → Health checks** for each server's IP on HTTP port 80, then select it in each weighted record's **Health check ID** setting. --- ## What I Learned - A **weighted routing policy** lets several records share the same name and type, and Route 53 picks one for each lookup in proportion to their **weights**. - Each weighted record needs a unique **record ID** to tell it apart from the others with the same name. - Each record's share of traffic is its **weight divided by the total weight**. Weights only matter relative to each other. - A weight of **0** takes a record out of rotation without deleting it. - The split is **random per query**, so it only matches the percentages closely over many lookups. - **Caching** by resolvers can hide the distribution, because a cached answer is reused for the TTL. A low TTL and querying the authoritative name server make testing clearer. - A simple record and weighted records **can't share** the same name and type. - Common uses for weighted routing: - **Load sharing** between servers or regions - **Canary releases**, sending a small share of traffic, like 5%, to a new version before switching everyone over - **Blue/green deployments**, shifting traffic gradually from the old environment to the new one - Without **health checks**, weighted routing keeps sending traffic to a server even if it's down. Health checks let Route 53 route only to healthy servers. - DNS-based routing works at the **lookup** level, not per request. A user's browser keeps using the IP it received until the cached answer expires, so this isn't as precise as a **load balancer**, which spreads every individual request. --- ## Cleanup Both instances and their public IPv4 addresses were billed by the hour, so I deleted everything from this lab: ### 1. Deleted the weighted records In the `sakibs-domain.com` hosted zone, I selected both `learn` A records (`record-1` and `record-2`), clicked **Delete records**, and confirmed. ### 2. Terminated the instances In the EC2 console, I selected `Web-Server-1` and `Web-Server-2` and clicked **Instance state** → **Terminate (delete) instance**. This also deleted their root volumes and released their public IPs. ### 3. Deleted the security group Once both instances showed **Terminated**, I deleted the security group they had used. ### 4. Deleted the hosted zone (when finished with Route 53 labs) With only the NS and SOA records left, the hosted zone could be deleted from **Hosted zones** → **Delete**. A hosted zone is billed monthly unless it's deleted within 12 hours of being created, so I deleted it once I was done with the Route 53 labs rather than leaving it in my account.21:T2d4d,## What Is a VPC? **Amazon VPC (Virtual Private Cloud)** is your own private, isolated network inside AWS. It's where resources like [EC2](/journal/aws/ec2/introduction-to-amazon-ec2) instances, databases, and load balancers live and communicate. You decide its IP address range, how it's divided into subnets, how traffic is routed, and what's allowed in and out. A VPC works much like a traditional network in an office or data center, but it's fully software-defined. There's no physical hardware to buy or cable, and changes take effect in seconds. Key characteristics: - A VPC exists in **one region**, but it spans **all Availability Zones** in that region. - Resources in different VPCs are **isolated** from each other by default. - Nothing can enter or leave a VPC unless you set up a path for it. --- ## Default VPC vs Custom VPC | | Default VPC | Custom VPC | | --- | --- | --- | | **Created by** | AWS, automatically in every region | You | | **CIDR block** | `172.31.0.0/16` | Your choice, from `/16` to `/28` | | **Subnets** | One public subnet in each AZ | None until you create them | | **Internet access** | Already set up, with an Internet Gateway and a route to it | None until you add it | | **Public IPs** | Assigned to instances automatically | Off by default | | **Best for** | Quick testing and learning | Real applications, where you control the design | The default VPC is convenient but makes every subnet public. Production workloads normally use a custom VPC with a deliberate mix of public and private subnets. --- ## Core Components ### CIDR block The **CIDR block** defines the VPC's range of private IP addresses, for example `192.168.0.0/24` or `10.0.0.0/16`. Every resource in the VPC gets an address from this range. VPCs normally use private ranges: `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`. See **VPC Networking Basics** for how CIDR notation and subnet sizing work. ### Subnets A **subnet** is a smaller section of the VPC's address range. Each subnet lives in exactly **one Availability Zone**, so placing resources in different AZs means using different subnets. - A **public subnet** has a route to an **Internet Gateway**, so resources in it can be reached from the internet (if they also have a public IP and the security group allows it). - A **private subnet** has no route to an Internet Gateway, so resources in it can't be reached directly from the internet. A subnet's name doesn't make it public or private. Its **route table** does. ### Route tables A **route table** is a set of rules that decide where network traffic goes. Each rule, or **route**, has: - A **destination**: where the traffic is headed, as a CIDR range. - A **target**: where to send it next. Every route table includes a **local** route for the VPC's own CIDR block, which lets all resources in the VPC reach each other. When traffic matches more than one route, the **most specific** route (the longest prefix) wins. Every VPC has a **main route table**. Any subnet that isn't explicitly associated with another route table uses it. A common practice is to keep the main route table private and create a separate route table for public subnets. ### Internet Gateway (IGW) An **Internet Gateway** connects a VPC to the internet. It has to be **attached** to the VPC, and a VPC can have only one. To use it, a route table needs a route like `0.0.0.0/0` → IGW. The Internet Gateway also translates between an instance's **private IP** (which the instance sees) and its **public IP** (which the internet sees). ### NAT Gateway A **NAT Gateway** gives resources in **private subnets** **outbound-only** internet access. They can download updates or call external APIs, but nothing on the internet can start a connection to them. The NAT Gateway sits in a **public subnet**, and the private subnets' route table gets a route like `0.0.0.0/0` → NAT Gateway. For high availability, one NAT Gateway is usually placed in each AZ. ### Elastic IP An **Elastic IP** is a static public IPv4 address that stays the same until you release it. A regular public IP changes whenever an instance is stopped and started. Elastic IPs are also required for NAT Gateways. --- ## Security Layers A VPC has two layers of firewall: | | Security group | Network ACL (NACL) | | --- | --- | --- | | **Applies to** | Individual resources, like an [EC2](http://localhost:5173/journal/aws/ec2/introduction-to-amazon-ec2) instance | An entire subnet | | **Rules** | Allow rules only | Allow and deny rules | | **Remembers connections?** | Yes, it's **stateful**: replies are automatically allowed | No, it's **stateless**: replies need their own rule | | **Rule order** | All rules are checked together | Rules are checked in number order, and the first match wins | | **Default behavior** | Blocks all inbound, allows all outbound | The default NACL allows everything in both directions | Most day-to-day traffic control is done with **security groups**. NACLs are useful as an extra safety net, for example to block a specific IP range across a whole subnet. ### Inbound and outbound - **Inbound** rules control traffic coming **into** a resource, started by someone else. - **Outbound** rules control traffic going **out of** a resource, started by the resource itself. Every connection is outbound for one side and inbound for the other, so rules are always checked on the side being connected to. --- ## How Traffic Flows ### From an instance to the internet 1. An instance in a public subnet sends a request to an address outside the VPC. 2. The subnet's route table matches it to `0.0.0.0/0` → Internet Gateway. 3. The Internet Gateway swaps the instance's private IP for its public IP and sends the traffic out. ### From the internet to an instance 1. Traffic arrives at the Internet Gateway, addressed to the instance's public IP. 2. The Internet Gateway swaps the destination to the instance's private IP. 3. The `local` route delivers it to the instance's subnet. 4. The **network ACL** and then the **security group** check whether it's allowed in. 5. The instance's reply goes back out through the `0.0.0.0/0` route. For an instance to be reachable from the internet, it needs **all** of these: a public IP, an attached Internet Gateway, a `0.0.0.0/0` route to it in the subnet's route table, and a security group rule allowing the traffic. If any one is missing, the connection fails. --- ## Connecting VPCs to Other Networks | Option | What it connects | Notes | | --- | --- | --- | | **VPC Peering** | Two VPCs, in the same or different accounts and regions | Private connection between exactly two VPCs. Their CIDR ranges can't overlap | | **Transit Gateway** | Many VPCs and on-premises networks | A central hub, simpler than peering every VPC to every other | | **Site-to-Site VPN** | A VPC and an on-premises network | Encrypted tunnel over the public internet | | **AWS Direct Connect** | A VPC and an on-premises network | A dedicated private network line, with more consistent performance | | **VPC Endpoints** | A VPC and AWS services like S3 or DynamoDB | Lets private resources reach AWS services without going over the internet | --- ## A Common Design: Public and Private Subnets Across Two AZs ``` Internet │ Internet Gateway │ ┌───────────── VPC 10.0.0.0/16 ─────────────┐ │ │ │ AZ a AZ b │ │ ┌─────────────────┐ ┌──────────────┐ │ │ │ Public subnet │ │ Public subnet│ │ │ │ Load balancer, │ │ Load balancer│ │ │ │ NAT Gateway │ │ NAT Gateway │ │ │ └─────────────────┘ └──────────────┘ │ │ ┌─────────────────┐ ┌──────────────┐ │ │ │ Private subnet │ │Private subnet│ │ │ │ App servers, │ │ App servers, │ │ │ │ databases │ │ databases │ │ │ └─────────────────┘ └──────────────┘ │ └───────────────────────────────────────────┘ ``` - **Public subnets** hold only what must face the internet, such as load balancers and NAT Gateways. - **Private subnets** hold application servers and databases, which can't be reached directly from the internet. - Each tier runs in **both AZs**, so the application keeps working if one AZ has a problem. --- ## Common Use Cases ### Hosting secure web applications Web-facing components go in public subnets, while application logic and data stay in private subnets. Users reach the application only through the parts meant to be public. ### Isolating environments Separate VPCs, or separate subnets, keep **development**, **testing**, and **production** environments apart, so a mistake in one can't affect the others. ### Protecting sensitive data Databases and internal services run in private subnets with tight security group rules, which helps meet security and compliance requirements. ### Extending an on-premises network With a VPN or Direct Connect, a VPC can act as an extension of a company's existing data center, letting on-premises systems and cloud resources communicate privately. ### Multi-tier architectures Each tier of an application (web, application, database) can have its own subnets and security groups, with rules that only allow each tier to talk to the ones next to it. ### Connecting multiple teams or accounts Large organizations often give each team its own VPC and connect them with **VPC Peering** or a **Transit Gateway**, keeping teams independent while still letting them share services. --- ## Pricing Creating a VPC, subnets, route tables, Internet Gateways, security groups, and network ACLs is **free**. Costs come from certain components and from traffic: | Component | Charged for | | --- | --- | | **NAT Gateway** | Every hour it ex