Cloud Integrations
DAY_01 / SECTION_04 // LIVE DEMO
DEMO READY

AWS console walkthrough

The pieces from this morning, hands-on. Networking & identity in the AWS console — a 30-minute walkthrough that anchors VPC + EC2 + IAM in muscle memory.

~/aws/console-walkthrough.sh ~30 MIN
  1. 01

    AWS Console tour

    Region selector · services menu · billing alert. Set the stage — this is the surface students will see.

  2. 02

    Create a VPC

    10.0.0.0/16, two AZs, public + private subnets, NAT gateway. Whiteboard it as you click.

  3. 03

    Create a security group

    Allow HTTP/HTTPS in, all out. Talk through inbound vs outbound.

  4. 04

    Launch an EC2 instance

    Amazon Linux, t3.micro, in the public subnet. No SSH key — we use Session Manager.

  5. 05

    Connect via SSM

    No port 22 exposed, no key to lose. Show the audit trail this leaves in CloudTrail.

  6. 06

    Create an IAM role

    Attach ReadOnlyAccess to S3. Walk through how the role is assumed by the instance.

  7. 07

    Verify

    `aws s3 ls` works. `aws ec2 describe-instances` fails. Permissions match the policy.

  8. 08

    Show CloudTrail

    Find one of the API calls we just made. Talk through immutability and retention.

// discussion as you go

What would be different for production? Surface answers like:

  • — Multi-AZ, no public subnet for DB
  • — Infrastructure-as-code (Terraform / CDK / Pulumi) instead of console clicks
  • — MFA enforced on every IAM user
  • — Centralized log destination, not per-account CloudTrail
  • — Tag-based cost attribution
// what to take away

After this demo you should be able to:

  • — Recognize a VPC diagram and read its security groups
  • — Explain what an IAM role is and why it beats long-lived keys
  • — Find the audit log in any AWS account
  • — Justify (or push back on) "let's just put it in the public subnet"
// instructor solution

Stuck, or running the demo yourself? Open the click-by-click walkthrough. Every step has the exact console path, every field has the exact value to type.

chevron_right See solution ~30 MIN

// before you start

  • — Log into the AWS console as an IAM user (not root). Top-right region: us-east-1 (N. Virginia).
  • — You'll create a VPC, EC2, IAM role, security group. Cost if you finish in 30 min and clean up: under $1. NAT Gateway is the big charge (~$0.045/hr) — delete it at the end.
01

AWS Console tour

  1. Top-right: confirm region is N. Virginia (us-east-1). Click to show the dropdown of regions — point out it's geographic.
  2. Top search bar: type VPC, then EC2, then IAM — show how everything is reachable from one bar.
  3. Top-right account menu → Billing and Cost Management → mention Free Tier. Don't click around — just show it exists.
02

Create a VPC

  1. Search bar → VPC → click VPC dashboard → orange button Create VPC.
  2. Resources to create: pick VPC and more (the wizard — it creates subnets, route tables, IGW, NAT for you).
  3. Name tag auto-generation: demo.
  4. IPv4 CIDR block: 10.0.0.0/16. IPv6: No. Tenancy: Default.
  5. Number of AZs: 2. Public subnets: 2. Private subnets: 2.
  6. NAT gateways: In 1 AZ (cheaper than per-AZ — call out that production usually wants per-AZ for HA).
  7. VPC endpoints: None for the demo. (VPC endpoints would let private subnets reach SSM without internet. We're putting the instance in a public subnet, so we'll use the IGW path instead — this prevents the "should I add SSM VPC endpoints?" rabbit-hole later.) DNS options: leave both checked.
  8. Click Create VPC — watch the live diagram on the right while resources spin up (~2 minutes). Whiteboard the diagram as it appears.
  9. Verify the wizard actually wired up internet access. If the wizard skipped or you used a custom path, Session Manager will silently fail in step 7. Confirm all three before moving on:
    • VPC dashboard → Internet gateways → one exists with State Attached and VPC = demo-vpc. If not: Create internet gateway → name it → Actions → Attach to VPC → pick demo-vpc.
    • VPC dashboard → Subnets → click the public subnet → Route table tab. There must be a route 0.0.0.0/0 → igw-…. If only 10.0.0.0/16 → local shows, click the route table ID → Edit routes → Add route → destination 0.0.0.0/0, target Internet Gateway → pick the IGW → Save.
    • Subnet → Details tab → Auto-assign public IPv4 address = Yes. If No: Actions → Edit subnet settings → check "Enable auto-assign public IPv4 address" → Save.
03

Create a security group

  1. Search → EC2 → left nav Security Groups → Create security group.
  2. Name: demo-web-sg. Description: HTTP/HTTPS in, all out.
  3. VPC: pick demo-vpc from the dropdown (NOT the default VPC — students always miss this).
  4. Inbound rules → Add rule: Type HTTP, source Anywhere-IPv4 (0.0.0.0/0).
  5. Add another: Type HTTPS, source Anywhere-IPv4.
  6. Outbound rules: leave default (All traffic to 0.0.0.0/0). Discuss why outbound is permissive in most setups.
  7. Click Create security group.
04

Launch an EC2 instance

  1. EC2 → left nav Instances → orange Launch instances.
  2. Name: demo-web-01.
  3. AMI: Amazon Linux 2023 (first option, Free tier eligible).
  4. Instance type: t3.micro (Free tier eligible).
  5. Key pair: pick Proceed without a key pair (Not recommended). Pause here — explain: "no key means no SSH; we'll use Session Manager instead, which is auditable."
  6. Network settings → Edit:
    • VPC: demo-vpc.
    • Subnet: any demo-subnet-public1-*.
    • Auto-assign public IP: Enable.
    • Firewall: Select existing → demo-web-sg.
  7. Storage: leave default (8 GiB gp3).
  8. Advanced details → IAM instance profile: leave blank for now — we'll attach the role in step 6 to make the lesson land.
  9. Click Launch instance → View all instances. Wait until Running + 2/2 checks passed.
05

Try to connect via SSM (and fail)

  1. Sanity check first — open the instance summary and confirm it shows a Public IPv4 address. If that field is empty, the failure you're about to see won't be the IAM one we want to teach — it'll be a network failure that looks identical. Go back to step 2's verification list (IGW attached, default route in the route table, auto-assign public IP enabled on the subnet) before continuing.
  2. Select the instance → Connect (top button) → tab Session Manager.
  3. The Connect button will be greyed out, with a note about the SSM agent not registering. This is the teaching moment.
  4. Ask the class: "Why? The agent is running on the AMI. The network path is fine (we just confirmed). What's it missing?" The answer: an IAM role with permission to talk to SSM. That's step 6.
06

Create an IAM role & attach

  1. Search → IAM → left nav Roles → Create role.
  2. Trusted entity type: AWS service. Use case: EC2. Next.
  3. Add permissions — search and check both:
    • AmazonSSMManagedInstanceCore — lets SSM connect.
    • AmazonS3ReadOnlyAccess — the lesson: read S3, nothing more.
  4. Next → Role name: demo-ec2-role → Create role.
  5. Back to EC2 → Instances → select demo-web-01 → Actions → Security → Modify IAM role.
  6. Pick demo-ec2-role → Update IAM role.
  7. Wait 60–90 seconds for the SSM agent to register. Use the time to whiteboard "role assumption": instance metadata → STS → temporary credentials → AWS API.

// if Connect is still grey after 2 minutes

"SSM agent unable to register" has two causes. Read the agent's last error before guessing: select the instance → Actions → Monitor and troubleshoot → Get system log, then scroll for the SSM agent line.

  • no valid credentials could be retrieved for ec2 identity → the role didn't attach cleanly, or IMDS is disabled. Re-do the "Modify IAM role" step, then reboot the instance.
  • RequestError: send request failed → the role is there but the instance can't reach ssm.us-east-1.amazonaws.com. Go back to step 2's verification (IGW attached, 0.0.0.0/0 route, public IP on the instance). After fixing, reboot the instance to force the agent to retry.
07

Verify permissions live

  1. Select the instance again → Connect → Session Manager tab. The button should now be active. Click Connect.
  2. A black terminal opens in the browser. Run: 
    aws sts get-caller-identity
    Show the ARN — point out it ends with assumed-role/demo-ec2-role/i-….
  3. Run: 
    aws s3 ls
    Buckets list (or empty — both prove access). ✅ allowed.
  4. Run: 
    aws ec2 describe-instances
    Returns UnauthorizedOperation. ❌ denied — proves the policy is doing real work, not just decoration.
08

Find it in CloudTrail

  1. Search → CloudTrail → left nav Event history.
  2. Lookup attribute: Event name. Value: RunInstances. The launch from step 4 should be the top result.
  3. Click the event → tab Event record. Walk through the JSON:
    • userIdentity — who did it (your IAM user).
    • sourceIPAddress — from where.
    • requestParameters — exactly what was asked.
    • eventTime — when.
  4. Discuss: 90 days free in Event history. Beyond that, ship to S3 + KMS for compliance / forensics. Immutable. This is the source of truth in any incident review.

// cleanup — do this before you leave the lab

  1. EC2 → Instances → select demo-web-01 → Actions → Terminate instance.
  2. VPC dashboard → NAT gateways → select the demo NAT → Actions → Delete NAT gateway. This is the one that bills hourly.
  3. VPC dashboard → Elastic IPs → release the one the NAT freed up (otherwise ~$3.60/mo).
  4. VPC dashboard → Your VPCs → select demo-vpc → Actions → Delete VPC. AWS will cascade subnets, route tables, IGW.
  5. IAM → Roles → delete demo-ec2-role. EC2 → Security groups → delete demo-web-sg (only deletable after the instance is gone).
arrow_back day-1 / security day-2 / overview arrow_forward