Chapter 4 — Compute (EC2)

Day 1 — Instances, AMIs, and Key Pairs

1. Concept Primer

An EC2 instance is launched from an AMI (a snapshot image of an OS + software) into a specific subnet, with a security group controlling its network access and a key pair providing SSH login credentials. Instance state moves through pending → running → stopping → stopped/terminated.

2. Hands-on Exercise

Launch an instance into the subnet from Chapter 2, attach the security group, and inspect its lifecycle.

3. Exact Commands

floci start && eval $(floci env)

aws ec2 create-key-pair --key-name day1-key \
  --query 'KeyMaterial' --output text > day1-key.pem
chmod 400 day1-key.pem

INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-00000000 \
  --instance-type t2.micro \
  --key-name day1-key \
  --subnet-id $SUBNET_ID \
  --security-group-ids $SG_ID \
  --query 'Instances[0].InstanceId' --output text)

echo "Instance: $INSTANCE_ID"
aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].State'

aws ec2 stop-instances --instance-ids $INSTANCE_ID
aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].State'

4. Gotchas

• EC2 instance emulation focuses on API-shape and metadata fidelity rather than booting a full guest OS — don't expect to SSH into a genuinely running Linux box the way you would with a real instance. Use this chapter to master the API (launch, describe, tag, stop, terminate), not to test actual instance behavior.
• Any AMI ID is generally accepted since there's no real image registry backing it locally — pick a placeholder like ami-00000000 rather than hunting for a "valid" one.

5. Self-Check

Which three resources from Chapter 2 (VPC) does a run-instances call actually depend on to succeed?

Day 2 — Instance Profiles and User Data

1. Concept Primer

An instance profile is the container that lets an EC2 instance assume an IAM role — this is how compute gets scoped, credential-free permissions instead of embedding static keys. User data is a bootstrap script that runs once on first boot.

2. Hands-on Exercise

Create an instance profile wrapping the IAM role from Chapter 1, and launch an instance with both the profile and a user-data script attached.

3. Exact Commands

eval $(floci env)

aws iam create-instance-profile --instance-profile-name day2-profile
aws iam add-role-to-instance-profile \
  --instance-profile-name day2-profile --role-name s3-read-role

cat > user-data.sh << 'EOF'
#!/bin/bash
echo "Bootstrapped by Floci" > /tmp/bootstrap.log
EOF

INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-00000000 \
  --instance-type t2.micro \
  --subnet-id $SUBNET_ID \
  --security-group-ids $SG_ID \
  --iam-instance-profile Name=day2-profile \
  --user-data file://user-data.sh \
  --query 'Instances[0].InstanceId' --output text)

aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].IamInstanceProfile'

4. Gotchas

• As with Day 1, treat this as API/wiring practice — verifying that user-data actually executed inside a real guest isn't something to rely on here.
• The instance profile must reference a role that already exists (Chapter 1) — creating the profile alone isn't enough.

5. Self-Check

Why is an instance profile + role a better pattern than baking an access key into user-data?