AWS EC2
Amazon EC2 (Elastic Compute Cloud) is AWS's virtual machine service — you rent VMs with full control over the kernel, OS packages, and network stack. That control is its strength and its cost: compared to managed services like Lambda or ECS Fargate, EC2 hands you the most flexibility and the most operational responsibility (patching, scaling, deployments).
The production mindset is cattle, not pets: treat instances as disposable and reproducible, fronted by an Auto Scaling Group and load balancer, rather than hand-tuned servers you nurse along.
TL;DR
- EC2 is "rent a VM" — you manage the OS, services, and deployments.
- For production, pair instances with an Auto Scaling Group + load balancer.
- Use IAM roles (instance profiles), not static AWS keys.
- Watch costs: instance type, EBS, and data transfer all add up.
Quick Example
Launch an instance from the CLI with an instance profile (no static keys):
Core Concepts
- Instance — a running VM.
- AMI — the machine image an instance launches from.
- Instance type — its CPU/memory/network profile (e.g.
t3.micro,m6i.large). - EBS — block storage volumes attached to instances.
- Security group — a stateful firewall around the instance.
- Key pair — SSH access (many orgs prefer SSM Session Manager instead).
Common Architectures
Single instance (simple)
Fine for dev/staging or low-traffic apps. Risks: no redundancy, manual scaling, risky deployments.
Auto Scaling Group + Load Balancer (production baseline)
- Multiple instances spread across Availability Zones.
- A load balancer routes traffic and health-checks instances.
- Rolling updates and automatic replacement make deploys and failures safer.
Best Practices
- Security — put instances in private subnets, use least-privilege security groups, avoid SSH from the internet (prefer SSM Session Manager), and automate OS patching.
- Deployments — treat instances as ephemeral; bake an AMI or bootstrap with scripts, and keep config/secrets out of the image (see Secrets Management).
- Reliability — run across multiple AZs, use health checks with automatic replacement, and back up attached storage.
- Access — use IAM roles / instance profiles so code gets temporary credentials, never long-lived keys on disk.
Cost Tips
- Right-size instance types to actual CPU/memory use.
- Use Reserved Instances / Savings Plans for steady workloads.
- Use Spot Instances for fault-tolerant, interruptible jobs.
- Monitor EBS volume size and IOPS — over-provisioned disks quietly add up.
Common Mistakes
Open security group
Treating instances as pets
FAQ
When should I use EC2 instead of Lambda or Fargate?
Choose EC2 when you need full OS control, specialized or GPU hardware, long-running stateful processes, or custom networking/kernel tuning. For event-driven or bursty work, Lambda is simpler; for containerized services without managing VMs, ECS Fargate is. EC2 is the most flexible but carries the most operational burden.
How should I handle SSH access to instances?
Prefer AWS Systems Manager (SSM) Session Manager, which gives audited, IAM-controlled shell access with no open SSH port and no key distribution. If you must use SSH, keep it off the public internet — go through a bastion host or VPN, scope the security group to known CIDRs, and rotate key pairs.
Why does my stopped instance still cost money?
Stopping an instance halts compute charges, but attached EBS volumes keep billing for the storage they occupy, and Elastic IPs not attached to a running instance also incur charges. To stop paying entirely, snapshot and delete the volumes (or terminate the instance) rather than just stopping it.
How do I make EC2 deployments safe?
Run behind an Auto Scaling Group and load balancer across multiple AZs, use health checks so unhealthy instances are replaced automatically, and do rolling or blue/green deploys with immutable AMIs. Keeping instances stateless (state in managed databases/caches) is what makes replacement painless.
Related Topics
- Cloud Computing — The hub
- AWS Lambda — Serverless alternative
- AWS ECS/EKS — Container orchestration
- Docker — Containerizing workloads
- Deployment Strategies — Rolling/blue-green deploys