AWS Setup Guide Full Service Map

Service Index

Quick map of every service covered on this page:

• IAM — Users, roles, and least-privilege access.
• VPC — Private network, subnets, and security groups.
• EC2 — Virtual servers for apps and workers.
• S3 — Object storage for media and backups.
• RDS — Managed Postgres / MySQL.
• DynamoDB — Serverless NoSQL key-value store.
• ElastiCache — Redis / Memcached caching.
• ALB — Application load balancer.
• Route 53 — DNS and health checks.
• CloudFront — CDN in front of S3 or apps.
• ACM — Free TLS certificates.
• ECR — Private Docker image registry.
• ECS / Fargate — Run containers without managing servers.
• EKS — Managed Kubernetes.
• Lambda — Serverless functions.
• API Gateway — HTTP APIs for Lambda and backends.
• SQS — Message queues for async work.
• SNS — Pub/sub notifications.
• EventBridge — Event bus and schedules.
• SES — Transactional email.
• Cognito — User sign-up, login, and JWT.
• CloudWatch — Logs, metrics, and alarms.
• Secrets Manager / SSM — Passwords and config secrets.

1. AWS Account & Foundation Setup

Step 1: Create an account

• Go to aws.amazon.com → Create account.
• Add a payment method (the free tier still needs a card).
• Choose a Support plan — Basic (free) is enough to start.

Step 2: Secure the root user

• Enable MFA on the root account.
• Do not use the root user for daily work.

Step 3: Create an IAM admin user

• IAM → Users → Create user.
• Attach AdministratorAccess (or a custom admin policy).
• Enable MFA for that user and sign in with it going forward.

Step 4: Choose a region

Pick one primary region and stick to it, e.g.:

• ap-south-1 (Mumbai) — good for India.
• us-east-1 — the largest set of services.

Step 5: Install the AWS CLI

# macOS
brew install awscli

aws configure
# AWS Access Key ID
# AWS Secret Access Key
# Default region: ap-south-1
# Output: json

Create access keys under IAM → Security credentials, and never commit them to git. Prefer IAM roles on EC2/ECS/Lambda over long-lived keys.

2. VPC — Your Private Network

What it is: an isolated virtual network where your EC2, RDS, and load balancers live. You control IP ranges, subnets, and who can talk to whom.

Core pieces

• Subnets — public (internet-facing) and private (no direct public IP).
• Internet Gateway — lets public subnets reach the internet.
• NAT Gateway — lets private subnets make outbound calls (costly — use only when needed).
• Security Groups — stateful firewalls attached to instances.
• NACLs — optional subnet-level firewalls (advanced).

Recommended starter layout

VPC 10.0.0.0/16
├── Public subnet  10.0.1.0/24  → ALB, bastion (optional)
├── Private subnet 10.0.10.0/24 → EC2 / ECS tasks
└── Private subnet 10.0.20.0/24 → RDS (no public access)

For learning, the default VPC is fine. For production, create a custom VPC with public + private subnets across 2 Availability Zones.

3. EC2 — Virtual Servers

What it is: a rented Linux/Windows VM in AWS. You control the OS, packages, and processes.

Common uses

• Host Node/Next.js apps, APIs, Docker, and Nginx.
• Bastion / jump hosts.
• Workers and cron jobs.

Launch an instance

• EC2 → Launch instance.
• AMI: Amazon Linux 2023 or Ubuntu 22.04.
• Instance type: t3.micro / t3.small (free-tier eligible is often t2/t3.micro).
• Key pair: create or select one (.pem — keep private).
• Network: default VPC is fine to start; enable a public IP.
• Storage: 20–30 GB gp3.

Security group (firewall)

• SSH (22) — your IP only, for admin access.
• HTTP (80) and HTTPS (443) — open to the web.
• App (3000) — restrict to the VPC/SG and keep it behind Nginx.

Connect

chmod 400 your-key.pem
ssh -i your-key.pem ec2-user@PUBLIC_IP   # Amazon Linux
# or ubuntu@PUBLIC_IP for Ubuntu

Typical app setup

# Update OS
sudo dnf update -y

# Install Node
curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -
sudo dnf install -y nodejs

# Or use Docker
sudo dnf install -y docker
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

Process manager + reverse proxy

npm i -g pm2
pm2 start npm --name "app" -- start
pm2 save
pm2 startup

server {
  listen 80;
  server_name yourdomain.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

Then add HTTPS with Certbot (Let's Encrypt), and allocate an Elastic IP so the public IP does not change on restart.

Internet → Security Group → EC2 (Nginx :80/:443) → App (:3000)

4. S3 — Object Storage

What it is: unlimited object storage for files (images, videos, builds, backups). It is not a filesystem for databases.

Common uses

• User uploads / media (CDN origin).
• Static website hosting.
• Backups of DB dumps and logs.
• Build artifacts.

Create a bucket & upload

aws s3 mb s3://knowvora-media-prod --region ap-south-1
aws s3 cp ./image.png s3://knowvora-media-prod/uploads/image.png
aws s3 ls s3://knowvora-media-prod/

Keep Block Public Access ON unless you intentionally serve public files.

Private bucket + signed URLs (recommended)

const url = await getSignedUrl(s3Client, new GetObjectCommand({
  Bucket: "knowvora-media-prod",
  Key: "uploads/image.png",
}), { expiresIn: 3600 });

For public delivery, prefer CloudFront in front of S3 (CDN + HTTPS + cache) rather than opening the bucket.

Least-privilege IAM policy

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::knowvora-media-prod/*"
}

Attach it to an IAM role for EC2 (preferred) instead of hardcoding access keys.

5. RDS — Managed Relational Database

What it is: managed Postgres, MySQL, MariaDB, or SQL Server. AWS handles backups, patching, and multi-AZ failover.

Step-by-step create

• RDS → Create database → Standard create.
• Engine: PostgreSQL (or MySQL).
• Template: Free tier / Dev for learning; Production for real apps.
• Instance: db.t3.micro or db.t4g.micro to start.
• Storage: gp3, enable storage autoscaling if needed.
• Connectivity: same VPC as EC2; Public access = No.
• Security group: allow port 5432 (Postgres) or 3306 (MySQL) only from your app's security group.

Connect from your app

DATABASE_URL=postgresql://user:pass@mydb.xxxxx.ap-south-1.rds.amazonaws.com:5432/appdb

• Store the password in Secrets Manager, not in git.
• Enable automated backups (7 days is a solid default).
• Use Multi-AZ for production high availability.

6. DynamoDB — Serverless NoSQL

What it is: a fully managed key-value / document store. No servers to patch; scales automatically. Great for sessions, feature flags, and high-throughput lookups.

When to use DynamoDB vs RDS

• RDS — complex queries, joins, transactions, reporting.
• DynamoDB — simple access patterns, massive scale, low ops.

Create a table

aws dynamodb create-table \
  --table-name Users \
  --attribute-definitions AttributeName=userId,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Start with on-demand billing. Add GSIs only after you know your query patterns.

7. ElastiCache — Redis / Memcached

What it is: managed in-memory cache. Use Redis for sessions, rate limits, and hot API responses.

Setup tips

• Create a Redis cluster in a private subnet.
• Allow port 6379 only from your app security group.
• Never expose Redis to the public internet.
• Use it to cut RDS load for repeated reads.

REDIS_URL=redis://my-cache.xxxxx.cache.amazonaws.com:6379

8. ALB — Application Load Balancer

What it is: distributes HTTP/HTTPS traffic across multiple EC2 instances or ECS tasks. Handles health checks and TLS termination.

Step-by-step

• EC2 → Load Balancers → Create → Application Load Balancer.
• Scheme: Internet-facing; select at least 2 public subnets (AZs).
• Security group: allow 80/443 from the internet.
• Target group: register your EC2 instances or ECS service on port 3000.
• Listener: HTTPS :443 with an ACM certificate; optionally redirect HTTP → HTTPS.

Users → ALB (HTTPS) → Target Group → EC2 / ECS tasks

Prefer ALB over putting a single Elastic IP in front of one EC2 once you need redundancy or zero-downtime deploys.

9. Route 53 — DNS

What it is: AWS DNS service. Points your domain to an ALB, CloudFront, or Elastic IP.

Common record types

• A / Alias — apex domain (example.com) → ALB or CloudFront.
• CNAME — www or api subdomain.
• MX — email routing.

Steps

• Create a hosted zone for your domain.
• Update your registrar's nameservers to the Route 53 NS values.
• Create an Alias A record to your ALB or CloudFront distribution.
• Optional: health checks + failover routing.

10. CloudFront + ACM — CDN & HTTPS

CloudFront caches content at edge locations worldwide. ACM issues free TLS certificates.

ACM certificate

• Request a certificate in us-east-1 if you will attach it to CloudFront (required).
• Validate via DNS (Route 53 can auto-create the CNAME).

CloudFront in front of S3

• Create a distribution with your S3 bucket as origin (use Origin Access Control).
• Attach the ACM certificate and your custom domain.
• Keep the S3 bucket private — only CloudFront can read it.

Users → CloudFront (HTTPS + cache) → private S3 bucket

11. ECR — Container Registry

What it is: private Docker image registry, like Docker Hub inside your AWS account.

# Create repo
aws ecr create-repository --repository-name knowvora-api

# Login, build, push
aws ecr get-login-password --region ap-south-1 \
  | docker login --username AWS --password-stdin ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com

docker build -t knowvora-api .
docker tag knowvora-api:latest ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/knowvora-api:latest
docker push ACCOUNT_ID.dkr.ecr.ap-south-1.amazonaws.com/knowvora-api:latest

12. ECS / Fargate — Run Containers

What it is: run Docker containers without managing EC2 yourself (Fargate) or on your own instances (EC2 launch type).

Step-by-step (Fargate)

• Push image to ECR.
• Create an ECS cluster.
• Create a Task Definition — CPU/RAM, container image, port, env vars, IAM task role.
• Create a Service — desired count, attach to ALB target group.
• Enable auto scaling on CPU/memory or request count.

ECR image → ECS Task Definition → ECS Service → ALB → Users

Start with Fargate. Move to EKS only when you need Kubernetes-specific features or multi-cloud portability.

13. EKS — Managed Kubernetes

What it is: Amazon's managed Kubernetes control plane. You still manage worker nodes (or use Fargate profiles), networking (CNI), and deployments.

• Use when your team already knows Kubernetes or needs complex scheduling.
• Heavier ops than ECS — ingress, RBAC, Helm, cluster upgrades.
• Typical flow: EKS cluster → node group → deploy via kubectl / Helm → ALB Ingress Controller.

14. Lambda — Serverless Functions

What it is: run code without managing servers. You pay per request and compute time. Ideal for APIs, webhooks, image processing, and scheduled jobs.

Create a function

• Lambda → Create function → Author from scratch.
• Runtime: Node.js 20 / Python 3.12.
• Attach an IAM role with only the permissions it needs (S3, DynamoDB, etc.).
• Set timeout, memory, and environment variables.

export const handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Hello from Lambda" }),
  };
};

Trigger via API Gateway, S3 events, SQS, EventBridge schedules, or Cognito triggers.

15. API Gateway — HTTP APIs

What it is: managed front door for REST/HTTP/WebSocket APIs. Routes requests to Lambda, ALB, or other HTTP backends.

Quick setup with Lambda

• API Gateway → Create HTTP API (cheaper/simpler than REST API for most apps).
• Add routes: GET /users, POST /orders, etc.
• Integrate each route with a Lambda function.
• Enable CORS if a browser frontend calls it.
• Optional: JWT authorizer with Cognito.

Client → API Gateway → Lambda → DynamoDB / RDS

16. SQS — Message Queues

What it is: a durable queue between producers and consumers. Decouples slow work (emails, PDFs, AI) from your main API.

Steps

• Create a Standard queue (or FIFO if order matters).
• API enqueues a message after accepting a request.
• Worker (EC2, ECS, or Lambda) polls and processes messages.
• Configure a Dead Letter Queue (DLQ) for failed messages.

# Send
aws sqs send-message \
  --queue-url https://sqs.ap-south-1.amazonaws.com/ACCOUNT/jobs \
  --message-body '{"type":"send-email","userId":"123"}'

17. SNS — Pub/Sub Notifications

What it is: publish once, deliver to many subscribers (email, SMS, SQS, Lambda, HTTP).

• Create a Topic (e.g. order-events).
• Subscribe SQS queues or Lambda functions.
• Classic fan-out: SNS → multiple SQS queues for different microservices.

Publisher → SNS Topic → SQS (orders) + SQS (analytics) + Lambda (notify)

18. EventBridge — Events & Schedules

What it is: an event bus for app events and cron-like schedules. Cleaner than wiring every service to every other service.

• Scheduled rules — run a Lambda every night at 2 AM (like cron).
• Event bus — services emit events; rules route to targets.
• Integrate with S3, ECS task state changes, and custom app events.

# Example: cron expression — every day at 02:00 UTC
cron(0 2 * * ? *)

19. SES — Email

What it is: send transactional email (welcome, password reset, receipts) at low cost.

Steps

• Verify your domain (or a single email) in SES.
• Start in the sandbox (can only send to verified addresses).
• Request production access when ready.
• Send via SMTP or the AWS SDK from your API / Lambda.

Pair SES with SQS so email sending never blocks your HTTP request path.

20. Cognito — User Auth

What it is: managed sign-up, login, MFA, and JWT tokens — so you do not build auth from scratch.

Core pieces

• User Pool — users, passwords, social login (Google/Apple).
• App Client — your web/mobile app credentials.
• Identity Pool (optional) — temporary AWS credentials for S3 uploads.

Typical flow

User signs in → Cognito → JWT (ID + Access tokens)
→ API Gateway / your backend validates JWT → allow request

21. CloudWatch — Logs, Metrics & Alarms

What it is: the default observability layer for AWS. Collect logs, watch CPU/errors, and alert you.

• Logs — Lambda, ECS, and EC2 agents send stdout here.
• Metrics — CPU, memory, request count, custom app metrics.
• Alarms — e.g. page you if 5xx rate > 1% for 5 minutes.
• Dashboards — single pane for production health.

# Tail Lambda logs
aws logs tail /aws/lambda/my-function --follow

22. Secrets Manager & SSM Parameter Store

What they are: safe places for DB passwords, API keys, and config — never commit secrets to git.

• Secrets Manager — secrets with automatic rotation (great for RDS).
• SSM Parameter Store — cheaper config/secrets; SecureString for encryption.

# Store
aws secretsmanager create-secret \
  --name prod/db \
  --secret-string '{"username":"app","password":"..."}'

# Or SSM
aws ssm put-parameter \
  --name /prod/DATABASE_URL \
  --value "postgresql://..." \
  --type SecureString

Grant your EC2/ECS/Lambda role secretsmanager:GetSecretValue (or SSM GetParameter) — nothing more.

23. Monorepo vs Microservices

These are architecture choices. AWS can host either pattern.

Monorepo

One Git repo containing multiple apps/packages:

knowvora/
  apps/
    web/          # Next.js frontend
    api/          # Express/Fastify API
    worker/       # background jobs
  packages/
    ui/
    db/
    shared/

• Pros: shared types, one PR across services, easier refactors.
• Cons: heavier CI; needs tooling (Turborepo, Nx, pnpm workspaces).

Microservices

Independent deployable services, each with its own API/DB boundary:

Auth Service         → Cognito / users DB
Orders Service       → RDS
Media Service        → S3
Notification Service → SQS + SES

• Pros: scale teams/services independently; isolate failures.
• Cons: network complexity, distributed debugging, more DevOps.

Practical path

• Start as a monolith (or a monorepo with one deployable).
• Extract media → S3 early.
• Extract heavy workers later (email, PDF, AI) → SQS + Lambda/ECS.
• Only then split into true microservices.

24. End-to-End Production Layout

Users
  │
  ▼
Route 53 (DNS)
  │
  ▼
CloudFront / ALB + ACM (HTTPS)
  │
  ├── ECS / EC2     → Next.js + API
  ├── Lambda        → webhooks / workers
  ├── S3            → images / files
  ├── RDS           → Postgres
  ├── DynamoDB      → sessions / flags
  ├── ElastiCache   → Redis cache
  ├── SQS / SNS     → async jobs
  ├── SES           → email
  ├── Cognito       → auth
  └── CloudWatch    → logs & alarms

Deploy checklist

• Create a VPC with public + private subnets (2 AZs).
• Launch EC2/ECS with IAM roles (S3, Secrets, CloudWatch).
• Create private S3 + RDS; store credentials in Secrets Manager.
• Put ALB + ACM in front; point Route 53 Alias records.
• Add CloudFront for media; Cognito for auth if needed.
• Queue heavy work on SQS; send mail via SES.
• Enable CloudWatch logs and billing alarms.

25. Cost & Safety Basics

• Prefer IAM roles on EC2/ECS/Lambda over long-lived access keys.
• Lock SSH to your IP; keep S3 and RDS private.
• Turn on billing alerts; stop unused EC2 instances.
• Watch RDS, NAT Gateways, and ALB hours — they add up fast.
• Use free-tier / on-demand DynamoDB and Fargate carefully while learning.