Ravindra BagaleCourses & study guides मराठी Track your progress

Chapter 14: EC2 Operations — Elastic IP, AMI, Snapshots and Vertical Scaling

Common Mistakes I See Students Make

By Last updated:

Friends, I see these EC2 operations mistakes in every batch – an EIP never released, snapshots left behind after an AMI, trying x86 on Graviton. Read them once – it will save your bill.

  • Allocating Elastic IPs and never releasing them — idle EIPs are still charged.
  • Forgetting to update SSH/DNS after associating an EIP — the old public IP is gone.
  • Deregistering an AMI but leaving its snapshots, which keep costing money.
  • Creating an AMI with "No reboot" from a busy database server and getting a corrupted copy.
  • Creating a volume from a snapshot in a different AZ from the instance — it cannot be attached.
  • Running mkfs on a volume restored from a snapshot, wiping the very data they wanted to recover.
  • Mounting an XFS copy on the same instance without nouuid and getting a "duplicate UUID" error.
  • Changing an x86 instance to a Graviton type and expecting it to boot.
  • Forgetting that the public IP changes after a type change and thinking the server is dead.
  • Scaling up beyond free-tier types and leaving it running.

Extended notes for this AWS lesson

Why students get stuck here

AWS pages look simple until three things collide: the service setting, the VPC/security group, and the app configuration. The expansions below separate those layers with real stacks and sample commands.

Always check three layersAWS servicesettingNetworkSG / NACL / DNSApp configendpoint / driver
Most "it does not connect" tickets miss one of these three.

The same pattern in app stacks

Whether the data store is RDS MySQL, PostgreSQL, or another engine, apps read an endpoint + user + password from the environment.

Java / Spring Boot

spring.datasource.url=jdbc:mysql://ENDPOINT:3306/db with password from Secrets Manager / env.

Python / Django / Flask

HOST from env; never commit settings with real hosts.

Node.js

mysql2/pg clients with process.env.DB_HOST.

.NET

ConnectionStrings via env or Parameter Store.

PHP / Laravel

DB_HOST in .env, not in Git.

Go

database/sql with env-based DSN.

Indian company (sample)

Suppose we are a junior cloud engineer at Swiggy or Razorpay-style infrastructure. A new microservice cannot reach RDS. You check: 1) SG on RDS allows the app SG on 3306/5432. 2) App is in a private subnet with a route to the DB subnet. 3) The secret in Secrets Manager matches the rotated password. 4) You connect with the mysql/psql client from the app host before blaming the ORM.

Global practice

AWS Well-Architected Security and Reliability pillars: least-privilege SG, Multi-AZ for production relational DBs, automated backups, no public DB reachability.

Everyday analogy

A warehouse (RDS) should not open onto the street. Delivery bikes (app servers) enter through a staff gate (security group) with a badge (password/IAM auth).

Engines and ports

MySQL / MariaDB on RDS

Port 3306. Users and grants like self-managed MySQL.

PostgreSQL on RDS

Port 5432. Prefer scram auth.

SQL Server on RDS

Port 1433. Common with .NET shops.

Amazon Aurora

MySQL or PostgreSQL compatible; learn the endpoint types (cluster vs reader).

Load balancers in one breath

ALB is for HTTP/HTTPS apps (Spring, Node, Django, .NET). NLB is for extreme performance/TCP. GLB is for virtual appliances. Classic LB is legacy—prefer ALB/NLB for new work. Always put TLS on the balancer with ACM when you can.

Common EC2 and Linux mistakes (expanded)

  1. Losing the SSH key → use SSM Session Manager next time.
  2. Editing on the server without backups → keep AMI + user-data scripts.
  3. Opening 0.0.0.0/0 on SSH → restrict to your IP or VPN.
  4. Forgetting Elastic IP / DNS when testing restarts.
  5. Growing EBS without extending the Linux filesystem (growpart + resize2fs/xfs_growfs).

Common mistakes

  • Publicly accessible RDS "for a quick test" left open.
  • Mixing Classic LB advice with ALB listener rules.
  • Hard-coding IPs instead of DNS names for RDS endpoints.
  • Taking snapshots but never testing restore.

Worksheet

  1. Draw your VPC boxes: public subnet, private subnet, RDS subnet.
  2. Write the SG rules in a table.
  3. From the app host, run a one-line DB client connect.
  4. Take a snapshot and write the restore steps without looking.

Recap

  • Service + network + app config.
  • Private databases.
  • Prefer ALB + ACM for web apps.
  • Practise restore, not only backup.