EC2 Security Groups — SSH 0.0.0.0/0 to Miner in 24h

Every app you've ever built eventually hits the same wall: where does it actually run? Your laptop can't serve production traffic, a shared hosting plan falls over under load, and buying physical servers means you're locked into hardware that's obsolete in three years. The cloud exists to solve this, and AWS EC2 is where most teams start — and for good reason. It's the backbone of thousands of production systems running right now, from early-stage startups to Fortune 500 backends.

EC2 (Elastic Compute Cloud) solves the problem of unpredictable infrastructure needs. 'Elastic' is the key word — you can spin up 50 servers at 9am for a product launch and terminate 48 of them by noon when the traffic spike passes. You're billed by the second. No contracts, no idle hardware, no datacenter lease. The underlying model shifts infrastructure from a capital expense (buy servers) to an operational one (rent compute), which changes how engineering teams think about scaling entirely.

By the end of this article you'll understand what an EC2 instance actually is under the hood, how to choose the right instance type for your workload, how to launch and connect to a real server using the AWS CLI, and how to lock it down with security groups. You'll also see the exact mistakes that burn people — including accidental bills from instances left running and SSH connections that silently refuse to work.

Why EC2 Security Groups Are Your First Line of Defense — and How to Get It Wrong

An EC2 security group is a virtual firewall that controls inbound and outbound traffic at the instance level. It operates as a stateful packet filter: if you allow inbound traffic on port 22 (SSH) from a specific IP, the return traffic is automatically allowed regardless of outbound rules. This statefulness is the core mechanic that makes security groups simple but also easy to misconfigure.

Each security group consists of a set of allow rules — there are no deny rules. Traffic that isn't explicitly allowed is implicitly denied. You can assign up to 5 security groups per instance (soft limit), and rules are evaluated collectively: any matching allow rule in any assigned group permits the traffic. Changes take effect immediately, with no instance restart required. This means a single overly permissive rule, like SSH from 0.0.0.0/0, opens your instance to the entire internet within seconds.

Use security groups to enforce least-privilege access for your EC2 instances. In production, you should never use 0.0.0.0/0 for SSH, RDP, or database ports. Instead, restrict access to specific IP ranges (e.g., your office VPN CIDR) or use a bastion host. Security groups are free, fast to modify, and essential for compliance — but they are not a substitute for host-level firewalls like iptables or network ACLs for subnet-level control.

EC2 Instance Types and Pricing — Stop Paying for What You Don't Need

AWS divides instance types into families based on the ratio of CPU, memory, storage, and network. Pick wrong and you overpay or underperform.

General purpose (t3, m6i) — balanced CPU/memory. Good for web servers, dev/test environments. The t3 family includes burstable credits: you earn credits when idle and burn them under load. Exhaust them and the instance throttles.

Compute optimized (c6i, c7g) — higher CPU-to-memory ratio. For batch processing, video encoding, high-performance web servers. c6i is Intel, c7g is Graviton (ARM) — ~20% better price/performance.

Memory optimized (r6i, x2iedn) — massive RAM per vCPU. For in-memory databases (Redis, SAP HANA), large caches. The x2iedn gives up to 4 TB RAM.

Storage optimized (i3, d2) — high local NVMe SSD. For data warehouses, log processing. d2 has spinning disks for cold storage.

GPU instances (p4, g5) — for machine learning, graphic rendering. p4 uses A100 GPUs; g5 uses NVIDIA A10G.

In production, you usually start with a small general-purpose for your app, then use CloudWatch to profile actual resource usage and right-size after a week. Most teams over-provision by 2–3x initially.

Pricing models: - On-Demand: Pay per second, no commitment. Highest per-hour cost. Best for short-lived workloads. - Savings Plans: Commit to $/hour spend for 1-3 years (up to 72% off). Flexible across instance families and regions. - Reserved Instances: Commit to specific instance family in specific AZ for 1-3 years. Inflexible, but up to 75% off. Lock-in risk. - Spot Instances: Spare capacity, up to 90% off, but can be terminated with 2-min warning. Use for batch, CI/CD, stateless workloads.

Cost optimisation trap: buying a 3-year RI for a project that gets cancelled after 6 months. You're stuck paying for the entire term. Start with Savings Plans — they're flexible.

One nuance: the Graviton-based types (c7g, m7g, r7g) offer better price-performance for most workloads, but you'll need ARM-compatible software. Most container images and modern language runtimes work fine, but legacy binaries might not. Test before you commit.

#!/bin/bash
# TheCodeForge — Check EC2 cost and right-sizing recommendations

echo "=== EC2 Cost Analysis ==="

# List all running instances with type and launch time
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,LaunchTime,PublicIpAddress]' \
  --output table

# Check CloudWatch CPU utilization for one instance
INSTANCE_ID="i-0123456789abcdef0"
echo "=== CPU Utilization for $INSTANCE_ID (last 24h) ==="
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --statistics Average \
  --period 3600 \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Datapoints[*].[Timestamp,Average]' \
  --output table

# Check if instance is t-family and burst credits
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --statistics Minimum \
  --period 3600 \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Datapoints[0].Minimum' \
  --output text

Instance Family Comparison Table — C, M, R, T, I, G Series at a Glance

When selecting an instance, start with the family. Each family optimises a different resource ratio. The table below shows the common families, representative types, the vCPU-to-memory ratio, typical use cases, and approximate on-demand hourly pricing (us-east-1, as of May 2026). Prices are for the smallest size in each family and increase with size.

Graviton (ARM) variants (c7g, m7g, r7g) offer 20% better price/performance than equivalent Intel/AMD types for most workloads. For example, c7g.large costs ~$0.068/hr vs c6i.large at $0.085/hr. Check software compatibility before migrating.

How to choose: - If your CPU is pegged at 100% but memory is under 50%, you need a compute-optimised type (C or better). - If memory is near capacity but CPU is idle, move up to R series. - If you need high local I/O (e.g., for temporary data processing), pick I series with instance store. - For GPU-accelerated workloads, G or P series. P (p4, p5) are even more powerful but more expensive.

Use the AWS CLI to list available instance types in your region: aws ec2 describe-instance-types --filters Name=instance-type,Values=t3. --query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]' --output table

#!/bin/bash
# TheCodeForge — List EC2 instance families and their characteristics

echo "=== Listing all instance families with example types ==="

# Describe instance types for each family
for family in t3 m6i c6i r6i i3 g5 x2iedn; do
  echo ""
  echo "--- $family ---"
  aws ec2 describe-instance-types \
    --filters Name=instance-type,Values="${family}.*" \
    --query 'InstanceTypes[*].[InstanceType, VCpuInfo.DefaultVCpus, MemoryInfo.SizeInMiB, InstanceStorageInfo.TotalSizeInGB]' \
    --output table --max-items 5
done

Pricing Model Decision Matrix — Choose Between On-Demand, Reserved, Spot, and Savings Plans

EC2 offers multiple pricing models, and choosing the wrong one can double your costs or leave you locked into a commitment you can't change. This decision matrix maps each model's commitment level, discount depth, interruptibility, and ideal use case.

Decision flow: 1. Will the workload run continuously for 1-3 years? -> Yes -> Consider Savings Plans or RIs. Start with Compute Savings Plans for flexibility. 2. Can the workload tolerate interruption? -> Yes -> Use Spot Instances for maximum savings. If no, use On-Demand or Savings Plans. 3. Is the instance type and region known to be fixed? -> Yes -> Standard RI gives highest discount (up to 75%) but locks you in. For most teams, Savings Plans are safer. 4. Is the workload short or unpredictable? -> On-Demand is the simplest. Never commit to RI/Savings Plans for short projects.

Common pitfall: A developer committed to a 3-year Standard RI for an application that migrated to containers 6 months later. The RI was tied to a specific instance type and region, so it became useless. The cost: $50,000 paid for compute they never used.

Best practice: Use a mix: On-Demand for baseline flexibility, Savings Plans for steady-state capacity (covering about 60-80% of your expected usage), and Spot for elastic workloads that can be restarted. This blend gives you cost efficiency without lock-in risk.

#!/bin/bash
# TheCodeForge — Compare pricing models for a given instance type

INSTANCE_TYPE="m6i.large"
REGION="us-east-1"

echo "=== Pricing for $INSTANCE_TYPE in $REGION ==="

# Get On-Demand price
aws pricing get-products \
  --service-code AmazonEC2 \
  --filters "Type=TERM_MATCH,Field=instanceType,Value=$INSTANCE_TYPE" "Type=TERM_MATCH,Field=regionCode,Value=$REGION" \
  --query "PriceList[0]" --output json | jq -r '."terms".OnDemand | to_entries[0].value.priceDimensions | to_entries[0].value.pricePerUnit.USD'

# Get 1-year Compute Savings Plan price
# Savings Plans don't have a direct API, but you can approximate: ~40% off On-Demand

# Get Spot price history
aws ec2 describe-spot-price-history \
  --instance-types $INSTANCE_TYPE \
  --product-descriptions "Linux/UNIX" \
  --start-time "$(date -u -d '-1 day')" \
  --query 'SpotPriceHistory[*].[SpotPrice,Timestamp]' \
  --output table | head -5

Security Groups — The Firewall That Saves You from Crypto Miners

Security groups (SGs) are stateful virtual firewalls attached to EC2 (and other AWS resources). They control inbound and outbound traffic based on rules you define.

Key properties: - Stateful: if you allow inbound on port 80, response traffic is automatically allowed outbound regardless of outbound rules. - Explicit allow: no deny rules — only allow. Traffic that isn't allowed is implicitly denied. - Reference other security groups: you can allow inbound from another SG (e.g., allow HTTP from ALB SG), which is more secure than IP ranges. - You can attach up to 5 SGs per instance.

Common patterns: - Web tier: allow HTTP (80) and HTTPS (443) from 0.0.0.0/0; allow SSH from your office IP only. - App tier: allow traffic only from the web tier SG on application port. - Database tier: allow traffic only from app tier SG on DB port (e.g., 3306 for MySQL). Never allow DB ports from 0.0.0.0/0.

Mistake to avoid: Opening all ports to 0.0.0.0/0 for 'convenience'. That's how your instance becomes a crypto mining node overnight.

SSH-specific best practices: - Never open 0.0.0.0/0 on port 22. Ever. Bots scan every IP every 15 minutes. - Use AWS Systems Manager Session Manager instead of SSH — no public IP needed, no SSH keys, audit logs built-in. - If you must use SSH, restrict to your office IP using --cidr $(curl -s http://checkip.amazonaws.com)/32. - Use EC2 Instance Connect (temporary SSH key pushed via IAM).

Worst-case scenario: A client opened port 3306 (MySQL) to 0.0.0.0/0 for 'easy testing' and forgot to revert. Within 3 hours, their database was publicly accessible and a script dumped all tables. The data breach cost $500k in fines.

#!/bin/bash
# TheCodeForge — Fix dangerous security group rules

# Find security groups with SSH open to 0.0.0.0/0
echo "=== Security groups with SSH open to all ==="
aws ec2 describe-security-groups \
  --filters Name=ip-permission.protocol,Values=tcp Name=ip-permission.to-port,Values=22 \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]' \
  --output table

# Revoke dangerous rule (replace SG_ID with actual)
# aws ec2 revoke-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 0.0.0.0/0

# Add rule for your current IP only
MY_IP=$(curl -s http://checkip.amazonaws.com)
echo "=== Adding SSH rule for your IP: $MY_IP ==="
# aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr "$MY_IP/32"

# Check for database ports open to internet
DB_PORTS=(3306 5432 1433 27017)
for port in "${DB_PORTS[@]}"; do
  echo "=== Checking port $port ==="
  aws ec2 describe-security-groups \
    --filters Name=ip-permission.to-port,Values=$port \
    --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]' \
    --output table
done

echo "=== Recommendation: Use Systems Manager Session Manager instead of SSH ==="
echo "aws ssm start-session --target i-0123456789abcdef0"

EBS Volumes — gp3 vs gp2 and the Burst Credit Trap

Amazon Elastic Block Store (EBS) provides block-level storage volumes that persist independently from your EC2 instance. Think of it as an external hard drive you can attach/detach at will.

Volume types: - gp3 (General Purpose SSD): baseline 3000 IOPS, burst to 16000. Good for most workloads. Cost-optimised. Recommended for new deployments. - gp2 (older): IOPS tied to volume size (3 IOPS per GB). Baseline 3 IOPS/GB with burst credits (up to 3000 IOPS). Avoid for new deployments unless you need compatibility. - io1/io2 (Provisioned IOPS): guaranteed IOPS, expensive. For databases requiring consistent, high IOPS. - st1 (Throughput Optimized HDD): cheap, high throughput. For log processing, big data. - sc1 (Cold HDD): lowest cost, infrequent access.

The gp2 burst trap: gp2 earns I/O credits when idle (like CPU credits). Under sustained high I/O, credits exhaust, and performance drops from 3000 IOPS to baseline (3 IOPS per GB). A 100GB gp2 volume would drop to 300 IOPS.

gp3 eliminates burst credits: baseline 3000 IOPS regardless of size, and it's often cheaper than gp2. Migrate any gp2 volumes to gp3 for consistent performance and lower cost.

Performance tip: gp3 decouples IOPS from size and is cheaper than gp2. For high-performance databases, use io2 Block Express (up to 256,000 IOPS).

Encryption warning: By default, EBS encryption is not enabled in a new account. Enable it at the account level via the EC2 console settings. Otherwise, any snapshot you share accidentally could leak data.

#!/bin/bash
# TheCodeForge — Migrate gp2 volumes to gp3 for cost and performance

# List all gp2 volumes
echo "=== gp2 volumes in account ==="
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].[VolumeId,Size,Attachments[0].InstanceId,CreateTime]' \
  --output table

# Check burst credit balance for a gp2 volume
VOLUME_ID="vol-0123456789abcdef0"
echo "=== gp2 burst credit balance for $VOLUME_ID ==="
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=$VOLUME_ID \
  --statistics Minimum \
  --period 3600 \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output text

# Migrate volume from gp2 to gp3 (no downtime, online operation)
echo "=== Migrating $VOLUME_ID from gp2 to gp3 ==="
aws ec2 modify-volume \
  --volume-id $VOLUME_ID \
  --volume-type gp3 \
  --iops 3000

echo "=== Migration started. Monitor with: ==="
aws ec2 describe-volumes-modifications --volume-ids $VOLUME_ID

# Enable EBS encryption by default for future volumes
echo "=== Enabling EBS encryption by default ==="
aws ec2 enable-ebs-encryption-by-default

Storage Comparison — EBS vs Instance Store

EC2 instances have two storage options: Elastic Block Store (EBS) volumes and Instance Store volumes (ephemeral). They differ fundamentally in persistence, performance, and pricing. Choosing incorrectly can lead to data loss or unexpected costs.

EBS (Elastic Block Store): - Network-attached block storage that persists independently of the instance. - Can be detached and reattached to another instance. - Data survives instance stop, start, and terminate (unless you choose 'delete on termination' for the root volume). - Multiple volume types (gp3, io2, st1, sc1) with different performance/cost profiles. - Billed per GB-month plus IOPS/throughput provisions. - Typical latency: 1-5 ms.

Instance Store (Ephemeral Storage): - Physically attached to the host server that runs the instance. - Data is lost when the instance is stopped, terminated, or the underlying host fails. - Included in the instance price — no separate billing. - Extremely low latency (sub-millisecond) and very high IOPS (millions on NVMe). - Only available on certain instance types (i3, i4i, m5d, c5d, r5d, etc. — look for 'd' suffix for local NVMe). - Cannot be detached or moved to another instance.

Best practices: - Always use EBS for persistent data like databases, application state, and logs you need to keep. - Use Instance Store for temporary data that can be regenerated: build caches, intermediate processing results, swap space, or data replicated from another source. - Many production architectures combine both: boot from EBS (gp3), and mount instance store NVMe for high-performance scratch space (e.g., database temp tables, MapReduce shuffle). - If you use Instance Store for anything important, replicate it across instances or to a shared EBS/EFS/S3 to avoid single-point-of-failure.

Common mistake: A developer used an instance store volume as the primary data store for a stateful application. When the instance was stopped for a security patch, all data was lost. Recovery took days from backups. Always review the 'Delete on termination' flag and instance type storage options before launching.

#!/bin/bash
# TheCodeForge — Check instance storage details

echo "=== Check if instance has Instance Store volumes ==="
INSTANCE_ID="i-0123456789abcdef0"

# Describe instance to see block device mappings
aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].BlockDeviceMappings[*]'

echo ""
echo "=== List all EBS volumes attached to instance ==="
aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=$INSTANCE_ID \
  --query 'Volumes[*].[VolumeId,Size,VolumeType,State,Attachments[0].Device]' \
  --output table

echo ""
echo "=== Check if instance type supports Instance Store ==="
INSTANCE_TYPE=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].InstanceType' --output text)

echo "Instance type: $INSTANCE_TYPE"
aws ec2 describe-instance-types --instance-types $INSTANCE_TYPE \
  --query 'InstanceTypes[0].[InstanceType, InstanceStorageSupported, InstanceStorageInfo.TotalSizeInGB]' \
  --output table

User Data and Bootstrapping — Stop Hand-Jobbing Your Instances

Manually SSHing into every new instance to install packages is a production incident waiting to happen. User Data is a script you pass at launch that runs once on boot. Use it to install agents, pull the latest app code, or register with your configuration management. The trap: User Data runs as root and is idempotent only if you write it that way. On Windows, it runs as SYSTE M. On Linux, it executes after the kernel boots but before the service manager finishes. If your script calls yum install and the instance reboots, it won't re-run. Wrap your logic in a conditional check against a lock file or cloud-init state. Never hardcode secrets in User Data — fetch them from Parameter Store or Secrets Manager. The golden rule: treat your User Data like a one-shot provisioning trigger, not a daemon.

#!/bin/bash
# io.thecodeforge
# One-shot bootstrap for production EC2
set -euo pipefail

LOCKFILE="/var/lib/cloud/instance/booted.lock"
if [[ -f "$LOCKFILE" ]]; then
  echo "Bootstrap already ran. Exiting."
  exit 0
fi

echo "Installing CloudWatch agent..."
yum install -y amazon-cloudwatch-agent || apt-get install -y amazon-cloudwatch-agent

echo "Fetching app config from Parameter Store..."
REGION=$(curl -s http://169.254.169.254/latest/meta-data/placement/region)
aws ssm get-parameters --names "/app/prod/db_url" --with-decryption --region "$REGION" --query "Parameters[0].Value" --output text > /etc/app/db_url.conf

echo "Registering with ASG lifecycle hook..."
touch "$LOCKFILE"
echo "Bootstrap complete."

Instance Metadata — The Backdoor You Didn't Lock

Every EC2 instance has a metadata endpoint at 169.254.169.254. It hands out instance ID, IAM role, security group info, and even the User Data you sent. If an attacker gets shell access, they hit that endpoint and steal your IAM credentials. That's how crypto miners get a foothold. The fix: restrict IMDS to version 2, which requires a session token. Version 1 is plaintext and vulnerable to SSRF attacks. Also, disable IMDS entirely on instances that don't need it — like NAT gateways or load balancers. For IAM roles, use the IMDSv2 token flow instead of hardcoding credentials. And always audit your metadata access with CloudTrail. The single worst EC2 security mistake is leaving IMDSv1 enabled on a public-facing instance with an admin role attached. Lock it down before your next deployment.

#!/bin/bash
# io.thecodeforge
# Force IMDSv2 on a running instance
# Requires AWS CLI and valid credentials

INSTANCE_ID="i-0abcdef1234567890"

# Check current metadata option
aws ec2 modify-instance-metadata-options \
  --instance-id "$INSTANCE_ID" \
  --http-tokens required \
  --http-endpoint enabled \
  --http-put-response-hop-limit 2 \
  --region us-east-1

echo "IMDSv2 enforced. Token required for all calls."

# Verify change
aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --region us-east-1 \
  --query "Reservations[0].Instances[0].MetadataOptions.HttpTokens"

# Expected output: "required"

Placement Groups — How to Sabotage Your Own Latency

When you launch instances without placement strategy, AWS spreads them across hardware to maximize fault tolerance. That's fine for web servers. For high-performance computing, distributed databases, or Kafka clusters, you need low latency between instances. Placement groups force instances onto the same rack or cluster. Three flavors: cluster for single-AZ, ten-thousandths latency; spread for maximum separation across hardware; partition for large distributed workloads like Hadoop. The gotcha: cluster placement groups don't span Availability Zones. If the AZ fails, everything goes down. And you can't move a running instance into a placement group — you must launch it there. Also, if capacity is tight, your cluster group may get an insufficient capacity error. Always request an EC2 capacity reservation for critical cluster groups. And never mix instance families in a cluster group — the network performance will be unpredictable.

#!/bin/bash
# io.thecodeforge
# Create a cluster placement group and launch instances into it

PLACEMENT_GROUP="production-kafka-cluster"

# Create the group
aws ec2 create-placement-group \
  --group-name "$PLACEMENT_GROUP" \
  --strategy cluster \
  --region us-east-1

echo "Placement group created: $PLACEMENT_GROUP"

# Launch instances into it (example: c5n.4xlarge for network-optimized Kafka)
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type c5n.4xlarge \
  --placement GroupName="$PLACEMENT_GROUP" \
  --count 3 \
  --region us-east-1 \
  --query "Instances[*].InstanceId"

echo "3 instances launched into cluster group. Check inter-instance latency."