AWS Basics — Core Services for Developers

Overview

Amazon Web Services (AWS) is the most widely adopted cloud platform, offering over 200 services. For developers, understanding the core services — compute, storage, databases, networking, and security — is essential for building growth-ready, cost-effective applications. This guide focuses on the services you will use daily and how they fit together in a typical architecture.

When to Use

• For alternatives, see Azure Basics — Core Services for Developers.

• You are migrating from on-premises to cloud

• You need growth-ready compute without managing hardware

• You want managed databases and storage

• You are building serverless or microservices architectures

Compute — EC2 and Lambda

EC2 (Elastic Compute Cloud)

Virtual servers in the cloud with full OS control.

# Launch an instance via CLI
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --count 1 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-123456 \
  --subnet-id subnet-123456

Instance Family	Use Case
T3/T4g	General purpose, burstable (dev/test)
M6i/M6g	General purpose, sustained workloads
C6i/C6g	Compute-intensive (APIs, batch)
R6i/R6g	Memory-intensive (caches, analytics)

Lambda

Serverless functions that run in response to events. Pay per invocation and duration.

import json

def handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Hello from Lambda'})
    }

Lambda integrates with S3, API Gateway, SQS, SNS, DynamoDB streams, and CloudWatch Events.

Storage — S3 and EBS

S3 (Simple Storage Service)

Object storage for files, backups, static assets, and data lakes.

# Create a bucket
aws s3 mb s3://my-app-bucket

# Upload a file
aws s3 cp app.zip s3://my-app-bucket/builds/

# Make public (with caution)
aws s3api put-object-acl --bucket my-app-bucket --key app.zip --acl public-read

Storage Class	Use Case	Retrieval
Standard	Frequently accessed	Immediate
Intelligent-Tiering	Unknown access patterns	Immediate
Glacier	Long-term archives	Minutes to hours
Deep Archive	Compliance backups	12-48 hours

EBS (Elastic Block Store)

Persistent block storage for EC2 instances. Like a virtual hard drive.

# Create and attach a volume
aws ec2 create-volume --size 100 --region us-east-1 --availability-zone us-east-1a --volume-type gp3
aws ec2 attach-volume --volume-id vol-12345 --instance-id i-12345 --device /dev/sdf

Databases — RDS and DynamoDB

RDS (Relational Database Service)

Managed PostgreSQL, MySQL, MariaDB, SQL Server, and Oracle.

# Create a PostgreSQL instance
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --master-username admin \
  --master-user-password secret123 \
  --allocated-storage 20

DynamoDB

Managed NoSQL key-value and document database with single-digit millisecond latency.

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Users')

table.put_item(Item={'id': 'user-1', 'name': 'Alice', 'email': 'alice@example.com'})
response = table.get_item(Key={'id': 'user-1'})

Networking — VPC

Virtual Private Cloud isolates your resources and controls traffic.

┌─────────────────────────────────────────────┐
│                    VPC                        │
│  ┌─────────────┐    ┌─────────────────────┐ │
│  │ Public Subnet│    │   Private Subnet    │ │
│  │  ┌───────┐  │    │  ┌───────┐ ┌─────┐ │ │
│  │  │  ALB  │  │    │  │  EC2  │ │ RDS │ │ │
│  │  └───┬───┘  │    │  └───┬───┘ └──┬──┘ │ │
│  │      │      │    │      │        │    │ │
│  │  Internet    │    │   NAT Gateway      │ │
│  │  Gateway     │    │   (egress only)    │ │
│  └──────────────┘    └────────────────────┘ │
└─────────────────────────────────────────────┘

Key components:

• Subnets: Public (with IGW route) vs Private (no direct internet)
• Security Groups: Stateful firewall at the instance level
• NACLs: Stateless firewall at the subnet level
• NAT Gateway: Allows private instances to reach the internet

Security — IAM

Identity and Access Management controls who can do what.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*",
      "Condition": {
        "StringEquals": {"aws:RequestedRegion": "us-east-1"}
      }
    }
  ]
}

What works:

• Use roles, not long-term access keys
• Apply least privilege
• Enable MFA for root and admin users
• Use IAM policy conditions for extra security

Common Mistakes

• Leaving S3 buckets public — use bucket policies and Block Public Access
• Using root credentials — create IAM users and roles immediately
• No VPC flow logs — you cannot debug what you cannot see
• Oversized EC2 instances — start small and scale up; use CloudWatch metrics
• Ignoring cost alerts — set up billing alarms before you get surprised

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts. Compare deployed versions with the declared source of truth before debugging behavior differences.

FAQ

Is AWS free? AWS offers a Free Tier: 12 months of limited usage on EC2, S3, RDS, and Lambda. Always monitor billing.

Should I use ECS, EKS, or Lambda?

• Lambda: event-driven, short-lived tasks
• ECS: containerized workloads, AWS-native
• EKS: Kubernetes-based workloads, multi-cloud portability

How do I secure secrets? Use AWS Secrets Manager or Parameter Store (SSM). Never hardcode credentials in code or EC2 user data.

How do I get started with this in an existing project?

Start with a small, isolated part of your codebase. Apply the concepts from this guide to one module or service. Measure the impact, then expand to other areas.

What tools do I need?

The tools mentioned throughout this guide are listed in each section. Most are open-source and widely adopted. Check the related resources for setup instructions.

How do I measure success after implementing this?

Define clear metrics before starting: performance benchmarks, error rates, or maintainability indicators. Compare before and after. Iterate based on the data, not on assumptions.

Advanced Topics

Scenario: Web Architecture on AWS

System: Scalable web app, multi-AZ
Requirements: 99.95% availability, auto-scaling, DR

Architecture:
  Route53 (DNS) -> CloudFront (CDN/WAF) -> ALB -> ECS Fargate
    AZ-a: 2 tasks
    AZ-b: 2 tasks

  ECS -> RDS PostgreSQL (Multi-AZ)
  ECS -> ElastiCache Redis (Multi-AZ)
  ECS -> S3 (static assets)
  ECS -> SQS (async queue)

Key services:
  | Layer | Service | Configuration |
  |-------|---------|---------------|
  | DNS | Route53 | Latency-based routing |
  | CDN/WAF | CloudFront + WAF | Global edge, rate limiting |
  | Load Balancer | ALB | Cross-zone, health checks |
  | Compute | ECS Fargate | 2 vCPU / 4GB per task |
  | DB | RDS PostgreSQL | db.r6g.large, Multi-AZ |
  | Cache | ElastiCache Redis | cache.r6g.large, Multi-AZ |
  | Storage | S3 | Standard + IA lifecycle |
  | Queue | SQS | FIFO, DLQ configured |
  | Monitoring | CloudWatch + X-Ray | |
  | Secrets | Secrets Manager | Automatic rotation |

Auto-scaling:
  - CPU > 70% for 5 min -> scale out (+2 tasks)
  - CPU < 30% for 10 min -> scale in (-1 task)
  - Min: 4 tasks, Max: 20 tasks
  - ALB 5xx > 1% -> scale out + alert
  - SQS queue depth > 1000 -> scale out

Disaster Recovery:
  | Component | RPO | RTO | Strategy |
  |-----------|-----|-----|----------|
  | RDS | < 5s | < 2min | Multi-AZ synchronous |
  | ElastiCache | < 1min | < 5min | Multi-AZ + failover |
  | S3 | 0 | 0 | Cross-region replication |
  | ECS | 0 | < 5min | Auto-scaling group multi-AZ |
  | Route53 | 0 | < 30s | Health check failover |

Estimated costs (monthly):
  | Service | Cost |
  |---------|------|
  | ECS Fargate (8 tasks) | $1,200 |
  | RDS (r6g.large Multi-AZ) | $700 |
  | ElastiCache (r6g.large) | $350 |
  | S3 (1TB) | $25 |
  | ALB + data transfer | $200 |
  | CloudFront (1TB) | $85 |
  | Route53 | $5 |
  | Secrets Manager | $40 |
  | Total | ~$2,600/month |

Lessons:
  - Fargate eliminates server management for containers
  - Multi-AZ is mandatory for production
  - CloudFront + WAF protects at the edge
  - SQS decouples producers from consumers
  - Secrets Manager rotates credentials automatically

How do I choose between ECS and EKS?

Use ECS if you just need containers without complex orchestration. It is simpler, cheaper, and sufficient for most apps. Use EKS if you need native Kubernetes, Helm charts, service mesh, or if your team already knows K8s. EKS has more operational overhead but offers more flexibility and a broader ecosystem.

Common Production Pitfalls

• Treating the guide as a checklist to complete once rather than a practice to evolve.
• Adopting every recommendation at once instead of starting with one measured change.
• Skipping the maturity assessment and forcing advanced practices on an unprepared team.
• Not updating runbooks and on-call expectations as new practices are introduced.
• Ignoring real incident data when prioritizing which parts of the guide to apply first.
• Failing to assign an owner who reviews decisions quarterly.
• Copying examples without adapting them to the team’s actual tooling and constraints.
• Forgetting to measure outcomes before adding the next improvement.