AWS day 13

Main ideas, concepts, and lessons

EC2 networking basics: public vs private IP

• When you launch an EC2 instance, it can have both a public IP and a private IP.
• Public IP: reachable from the internet (used for exposing services to the public).
• Private IP: used for internal communication within the VPC; not directly exposed to the public internet.
• Common private IP ranges mentioned:
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
• Rationale given: keep sensitive data private (e.g., examples involving card/order info) while exposing only what must be public (e.g., website access).

VPC (Virtual Private Cloud) and why it’s needed

• VPC is presented as mandatory in modern AWS setups, with a historical note that older options existed to launch EC2 without VPC.
• Security purpose: VPC uses mechanisms like security groups to isolate and protect resources.
• Conceptual explanation (analogy):
  • Think of VPC as a “city.”
  • Subnets are smaller divisions within the city.
• Public vs private subnet behavior:
  • Subnet connected to the Internet Gateway → resources can be treated as public-facing
  • Subnet not connected → resources remain not directly internet-reachable

Internet connectivity for VPC: Internet Gateway

• The speaker likens home Wi‑Fi/internet access to explain that VPC requires an Internet Gateway for internet connectivity.

Access to EC2: Key pair vs alternatives

• Key pair is important for SSH login to an EC2 instance from a local machine.

• Key pair structure:

  • A public key is stored on the instance (Linux path referenced): /home/ec2-user/.ssh/authorized_keys

  • The private key is downloaded and kept locally.

  • How it works:
  • During SSH connection, the SSH process compares the provided credentials (private/public key match).
  • If the keys match, access is granted.
  • Port 22 is referenced as the SSH access port.
  • Alternatives to key pair:
  • Session Manager (AWS Systems Manager) is described as a more modern/secure approach:
    • No SSH keys required
    • Does not rely on opening port 22
    • Requires IAM roles (permission-based access)

Direct Connect vs SSH key (conceptual distinction)

• Direct Connect:
  • Framed as a “road”/network path
  • Uses dedicated/fiber infrastructure to connect to AWS data centers
  • Operates at the network layer
• SSH key:
  • Authentication mechanism after the network path is established
  • Framed as belonging to the application/OS login layer

AMI (Amazon Machine Image)

• AMI definition: preconfigured golden templates for launching EC2 instances.
• Purpose:
  • Capture a configured instance (OS + applications + storage configuration + details/permissions)
  • Use the AMI to:
    • Create multiple identical instances (scale-out)
    • Provide backups/restore points
• AMI vs “screenshot” analogy:
  • AMI is treated like a captured snapshot/template you can clone from.
• AMI workflow (as described in the lab):
  1. Create an instance
  2. Configure it (e.g., create directories/files)
  3. Create an AMI from the running instance (Actions → Create Image)
  4. Wait until the AMI is available
  5. Launch new EC2 instances from the AMI
  6. Verify the new instance has the same files/configuration

Instance launching and capacity notes

• When launching from an AMI, AWS may limit how many instances can be requested at once (example mentioned: a cap like “maximum I can create only eight at a time”).
• Instance types discussed briefly:
  • T2/T3: described as “general purpose” for studying/simple uses (not representative of real enterprise high-end workloads)
  • Graviton-based examples mentioned (e.g., C8G) as what companies might request for real workloads

Cost estimation

• To estimate EC2 costs before running instances, use the AWS Pricing Calculator.
• Inputs to consider (as stated):
  • region (example: Hyderabad region)
  • OS (Linux vs other)
  • tenancy (mentioned but skipped for now)
  • workload pattern (constant vs limited usage)
  • instance type/specs (vCPU, memory, network expectations)
  • purchase model (example: On-Demand)
• Encouragement: share estimates with customers and adjust instance count/specs to control budget.

---

Methodology / step-by-step instructions emphasized (from the lab guidance)

EC2 lab practice workflow (recommended)

• Practice goal: launch EC2 → connect → configure → make AMI → launch from AMI → verify replication.
• Steps:
  1. Launch one EC2 instance
     • Keep it simple on day 1 (no extra complexities).
  2. Connect to the instance
     • Use Direct Connect (explicitly requested in the guidance)
     • Don’t worry about CLA/other options on day 1.
  3. Configure the instance
     • Create directories/files (Linux commands referenced earlier).
  4. Create an AMI
     • From the instance: Actions → Create Image
     • Name it (example: “backup”)
     • Wait until the AMI becomes available
  5. Launch a new instance from the AMI
     • Go to AMIs
     • Choose Launch instance from AMI
     • Wait for the new instance to come up
  6. Verify replication
     • Connect to the new instance
     • Run ls (as referenced) to confirm the directories/files exist

Linux skills to practice alongside AWS (recurring advice)

Spend time on Linux commands used during labs:

• Create/edit files and directories (vi mentioned)
• Create directories (mkdir implied)
• Permission management (chmod referenced)
• Disk/utilization inspection and device listing (df, lsblk referenced)

Study approach (what to prioritize)

• Emphasis:
  • Practice over theory for memorization and command fluency.
  • Don’t expect instant mastery of DevOps/Linux/networking concepts—a minimum 3–4 hours/day practice mindset is suggested.
  • AWS services are interconnected, so understanding networking and Linux basics is necessary.

---

Speakers / sources featured

• Primary speaker: the instructor/mentor leading the AWS day-13 class (no name provided in subtitles).
• No other explicit external speakers or sources were cited (no specific publications/companies beyond AWS references).