EC2, SSH & IAM

• EC2 is the compute workhorse of AWS — most production workloads, autoscaling groups and EKS nodes are EC2 under the hood.
• SSH is the universal way to reach Linux servers; every troubleshooting session starts with it.
• IAM mistakes (over-broad policies, shared keys, root usage) cause most real AWS security incidents.
• Instance sizing and key management are daily DevOps decisions that affect cost and security.
• Understanding AMIs, key pairs and IAM roles prepares you for services like EKS, Lambda and RDS that all build on them.

The car is an EC2 instance: you pick the model (instance type), it runs a standard engine (AMI), and the ignition key is your SSH key pair. IAM is the fleet policy: a badge (user) grants access to the lot, group badges get the same permissions together, and a service role is like a valet card that lets the car itself request parts. The badge controls what you may drive and where — least privilege means the badge only opens the cars and garages you actually need.

• You launch an instance by choosing an AMI, an instance type, a key pair, a subnet and a security group; AWS provisions a VM from a pooled fleet in seconds.
• The instance boots the AMI's OS; user data scripts can run at first boot to install packages and configure the machine.
• SSH access uses the private half of your key pair — you connect as a named user (ec2-user, ubuntu, admin) and the server checks your key against the public key it holds.
• Traffic is filtered by security groups (stateful allow lists) attached to the instance, and by the subnet's route table and network ACLs.
• IAM authenticates every action: your CLI or console call is checked against policies attached to your user, group or role, and every API action is recorded in CloudTrail.

• Run application servers in an Auto Scaling group across availability zones behind a load balancer.
• Use IAM instance roles instead of access keys on the box — the instance fetches short-lived credentials from the metadata service.
• Build immutable AMIs in a CI pipeline so long-lived, drift-prone servers are replaced instead of patched.
• Use spot instances and capacity reservations to cut compute cost for batch and fault-tolerant workloads.
• Provide access into private subnets through a bastion host or AWS Systems Manager Session Manager with full audit trails.

• Never store private keys in git or on shared drives; use ssh-agent and rotate keys on a schedule.
• Follow least privilege in IAM: grant the minimum actions on the minimum resources.
• Enable MFA on the root account and create IAM users (or an SSO integration) for every human.
• Use instance roles for anything that runs on EC2 — no long-lived access keys on disk.
• Right-size instances: start small, watch utilization, and scale out before scaling up.

• Leaving a security group open to 0.0.0.0/0 on SSH and then wondering about brute-force login attempts.
• Storing AWS access keys inside application code or config files.
• Putting a key pair in the repo 'just for onboarding' — it grants access to every instance that uses it.
• Using the root account for daily work because it is simpler than configuring IAM.
• Choosing an oversized instance type 'to be safe' and paying for idle vCPUs.

• Permission denied (publickey) almost always means wrong key, wrong user, or a key with incorrect permissions.
• Check the security group allows your source IP on port 22 before blaming the key.
• Confirm the instance has a public IP and is in a public subnet with a route to the internet.
• Use aws ec2 get-console-output to read boot logs when SSH is not reachable.
• Verify IAM with aws sts get-caller-identity before debugging a denied API call.