• db.t3.micro is free tier eligible (750 hrs/month for MySQL, PostgreSQL, or MariaDB — not Aurora). Good enough for this phase.
• RDS must go in private subnets. It should never have a public IP. Access it only from within the VPC via Security Groups.
• The RDS endpoint looks like: my-db.abc123.us-east-1.rds.amazonaws.com. Use this as your JDBC host.

• The standby replica is not readable. It exists purely for failover. You cannot send read traffic to it to reduce load on the primary — that is what Read Replicas are for.
• Multi-AZ roughly doubles the RDS cost. In dev/learning environments, leave it off.

• Replication is asynchronous — replicas may lag behind the primary by seconds. Never use a replica for anything requiring up-to-date data (e.g., immediately after a write).
• Multi-AZ ≠ Read Replica. Multi-AZ is for availability (automatic failover). Read Replicas are for scalability (read offloading). These are separate features and can both be enabled simultaneously.

• Automated backups are deleted when you delete the RDS instance (unless you take a final snapshot). Manual snapshots survive instance deletion.
• Restoring a snapshot creates a new RDS instance — it does not restore in place. Plan for the new endpoint in your app config.

SecretsManagerClient client = SecretsManagerClient.create();
GetSecretValueResponse r = client.getSecretValue(
    GetSecretValueRequest.builder()
        .secretId("prod/myapp/db")
        .build());
// r.secretString() → JSON: {"username":"dbadmin","password":"..."}
// Parse with ObjectMapper, inject into DataSource

• Secrets Manager costs $0.40 per secret per month + $0.05 per 10,000 API calls. Negligible at learning scale.
• IAM permission required: secretsmanager:GetSecretValue on the specific secret ARN, not on *.
• For local development, use environment variables or a local .env file (excluded from Git). Never configure Secrets Manager with hardcoded access keys locally — that defeats the purpose.

spring.datasource.url=jdbc:postgresql://my-db.abc123.us-east-1.rds.amazonaws.com:5432/mydb
spring.datasource.username=dbadmin
spring.datasource.password=${DB_PASSWORD}
spring.datasource.hikari.maximum-pool-size=10

• Bucket names are globally unique across all AWS accounts worldwide. If someone else already has my-app-uploads, you cannot use it. Use a prefix like your company name or account ID.
• Bucket names must be 3–63 characters, lowercase, no underscores.
• Buckets are created in a specific region. Data stays in that region unless you explicitly replicate it.

• Once enabled, versioning cannot be fully disabled — only suspended. Suspended means new uploads no longer create versions, but existing versions are preserved.
• Old versions accumulate storage costs. Pair versioning with a lifecycle rule to expire non-current versions after N days.

• Standard (~$0.023/GB): frequent access, lowest latency. Default.
• Standard-IA (Infrequent Access, ~$0.0125/GB + retrieval fee): for files accessed less than once a month.
• Glacier Instant Retrieval (~$0.004/GB): archival, millisecond retrieval.
• Glacier Flexible Retrieval (~$0.0036/GB): archival, minutes to hours retrieval.
• Glacier Deep Archive (~$0.00099/GB): cheapest, 12-hour retrieval. For compliance archives.
• Intelligent-Tiering: automatically moves objects between tiers based on access patterns. Monitoring fee per object.

• IA classes have a minimum storage duration (30 days for Standard-IA, 90 days for Glacier). Objects deleted before the minimum are still billed for the full duration.

• Presigned URLs inherit the permissions of the IAM identity that generated them. If your EC2 IAM Role has s3:GetObject on the bucket, it can generate presigned GET URLs. Without the permission, the URL will fail.
• Maximum expiry: 7 days (604800 seconds) for IAM user or role credentials. For temporary session credentials (e.g., from STS), the URL expires no later than when the session expires — even if you set a longer duration.

• Bucket policies still control which IAM identities (your EC2 role, Lambda function) can access objects — Block Public Access only prevents public (unauthenticated) access.
• Never use bucket ACLs — they are a legacy mechanism. Use bucket policies and IAM policies instead.

<dependency>
  <groupId>software.amazon.awssdk</groupId>
  <artifactId>s3</artifactId>
  <version>2.25.x</version>
</dependency>

• CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, DiskWriteOps
• NOT included by default: memory usage, disk space used. These require the CloudWatch Agent.
• Detailed monitoring (1-minute intervals): costs extra. Enable per instance in the console.

sudo dnf install amazon-cloudwatch-agent -y
# Use the wizard to generate config:
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
# Start the agent:
sudo systemctl enable amazon-cloudwatch-agent
sudo systemctl start amazon-cloudwatch-agent

• Log retention defaults to Never Expire. This accumulates storage costs indefinitely. Always set a retention policy (e.g., 30 or 90 days) on every log group.
• CloudWatch Logs Insights: SQL-like query language for searching and analysing logs. Example: filter @message like /ERROR/ | stats count(*) by bin(5m)

• Set the evaluation period and datapoints carefully. CPU > 80% for 1 out of 1 datapoints at 1-minute intervals will fire on transient spikes. 2 out of 3 datapoints reduces false positives.
• An alarm in INSUFFICIENT_DATA state means CloudWatch is not receiving metric data — which itself can indicate a problem (agent stopped, instance down).

• Dashboards cost $3/month per dashboard (first 3 are free). Not a budget concern at learning scale.

• Container filesystem is ephemeral. Anything written inside the container is lost when the container stops. Use volumes or external storage (S3, RDS) for persistence.
• Each layer in a Docker image is cached. Put infrequently-changing layers (base image, dependencies) early in the Dockerfile, and your app code last — this speeds up rebuilds significantly.

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

• Use a JRE image (not JDK) in production containers — JDK includes the compiler which you don't need at runtime and adds unnecessary image size.
• Spring Boot's layered JAR feature (spring-boot:build-info) creates separate Docker layers for dependencies and app code, making rebuilds faster. Worth exploring after basics are solid.

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin \
  123456789.dkr.ecr.us-east-1.amazonaws.com

# Tag and push
docker tag my-app:latest 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

• There is no SSH into Fargate containers. Debugging uses CloudWatch Logs (stdout/stderr from the container) and ECS Exec (an optional feature that provides a shell into a running task).
• ECS tasks are not persistent. A stopped task is replaced by a new one. Any state must be in external storage (RDS, S3, ElastiCache).

• Fargate CPU units: 256 (0.25 vCPU), 512 (0.5 vCPU), 1024 (1 vCPU), up to 16384 (16 vCPU)
• Memory: 512 MB minimum, must be compatible with chosen CPU. E.g., 512 CPU → 1–2 GB memory.
• Spring Boot typically needs at least 512 MB; 1 GB is comfortable for a small service.

• Fargate has a slightly slower cold start than EC2 launch type (~10–30 seconds to start a new task). Not usually a problem for long-running services, but relevant for burst scaling.
• Fargate does not support GPU workloads or privileged containers.

• Pods have dynamic IPs. Never hardcode a pod's IP — use a Service to get a stable endpoint.
• When a pod crashes, Kubernetes restarts it (according to the restartPolicy). It does not move to a new IP or name unless it is rescheduled to a different node.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"

• A LoadBalancer Service in EKS creates an AWS NLB, which costs money. For HTTP routing to multiple services, use an Ingress with the AWS Load Balancer Controller instead — it creates a single ALB shared across services.

• Kubernetes Secrets are not encrypted at rest by default in etcd. For production, integrate with AWS Secrets Manager using the External Secrets Operator, or use the AWS Secrets and Configuration Provider (ASCP) with the Secrets Store CSI Driver.
• Base64 is encoding, not encryption. Anyone with kubectl access can decode a Secret trivially: kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d

• EKS control plane: $0.10/hour (~$72/month) per cluster. Plus the EC2 cost of worker nodes. Delete the cluster when not actively learning — this is the biggest cost trap in this roadmap.
• Alternatively, use EKS with Fargate profiles to avoid managing EC2 worker nodes entirely. Pay per pod CPU/memory instead.

# Step 1: Associate OIDC provider with the cluster (once per cluster)
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster --region us-east-1 --approve

# Step 2: Create an IAM service account in your cluster namespace
eksctl create iamserviceaccount \
  --cluster my-cluster \
  --namespace default \
  --name my-app-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

# Step 3: Reference it in your Deployment manifest
# spec.template.spec.serviceAccountName: my-app-sa

• The OIDC provider must be associated with the cluster before creating IRSA service accounts. Without this, the IAM role trust policy cannot validate the pod's identity token.
• The AWS SDK inside the pod automatically uses IRSA credentials. On EC2, it uses the Instance Profile. Both flow through the same credential provider chain — your Spring Boot code works identically in both environments without any changes.
• When a second team member tries to kubectl into your cluster and gets "Unauthorized", they need to be added to the aws-auth ConfigMap: kubectl edit configmap aws-auth -n kube-system and add their IAM user ARN.

# Create cluster (takes ~15-20 minutes)
eksctl create cluster --name my-cluster --region us-east-1 \
  --nodegroup-name workers --node-type t3.small --nodes 2

kubectl get nodes          # verify workers are Ready
kubectl get pods -A        # all pods in all namespaces
kubectl apply -f app.yaml  # deploy from manifest
kubectl get svc            # list services and their external IPs
kubectl logs pod-name -f   # tail pod logs
kubectl rollout undo deployment/my-app  # rollback

• Default concurrent execution limit: 1000 per account per region (soft limit, can be increased). One Lambda function hitting the limit can throttle all other functions in the account. Use reserved concurrency to isolate critical functions.
• Lambda is not suitable for long-running processes (batch jobs, video encoding) or anything requiring persistent local state.

public class UserHandler
    implements RequestHandler<APIGatewayProxyRequestEvent,
                               APIGatewayProxyResponseEvent> {

  // Initialised ONCE per container — reused on warm starts
  private final DynamoDbClient dynamo = DynamoDbClient.create();

  @Override
  public APIGatewayProxyResponseEvent handleRequest(
      APIGatewayProxyRequestEvent event, Context ctx) {

    String userId = event.getPathParameters().get("id");
    // query dynamo, build response...
    return new APIGatewayProxyResponseEvent()
        .withStatusCode(200)
        .withBody("{\"userId\":\"" + userId + "\"}");
  }
}

• Do not use Spring Boot as a Lambda runtime. Spring's application context initialises in 3–8 seconds — that's a multi-second cold start on every scale-out event. Use plain Java for Lambda. If your team requires Spring, use Spring Cloud Function + SnapStart, which snapshots the initialised context to cut cold starts to ~1 second.
• Static initialisers (static { ... }) run during the init phase — counted as cold start time. Move heavyweight setup into instance variables (initialised once) or lazy-init them on first invocation.

• Lambda SnapStart (available for Java 11+ managed runtimes): AWS takes a snapshot of the initialised execution environment after the init phase, then restores from it on cold starts. Reduces Java cold starts from seconds to ~1 second. Enable in the function configuration → "Edit" → SnapStart.
• Provisioned Concurrency: keeps N containers pre-warmed and ready. Eliminates cold starts completely but you pay for the reserved capacity even when idle. Use for latency-sensitive APIs.
• Avoid heavy Spring Boot in Lambda — Spring's context initialisation is slow. Use plain Java, Quarkus (with native compilation), or Micronaut instead. If you need Spring, use Spring Cloud Function with GraalVM native image.

• The right memory setting is not always the minimum. Use AWS Lambda Power Tuning (an open source Step Functions state machine) to find the optimal memory-to-cost ratio for your function.
• Ephemeral storage (/tmp): 512 MB by default, configurable up to 10 GB. Files in /tmp persist between warm invocations on the same container — useful for caching, but don't assume it's always available.

• HTTP API: JWT authorisers, Lambda proxy integration, CORS, lower cost (~$1/million requests). Missing: caching, API keys/usage plans, per-method throttling, AWS WAF integration.
• REST API: all HTTP API features plus response caching, usage plans, API keys, resource policies, AWS WAF, mock integrations, request/response transformations. Costs ~$3.50/million requests.
• Default recommendation: use HTTP API unless you need a specific REST API feature.

• The API Gateway endpoint is public by default. Anyone can call it. Add an authoriser (JWT/Cognito for HTTP API, Lambda authoriser for custom logic) or at minimum use an API key to prevent open access in production.

• Choose a high-cardinality partition key (e.g., user ID, order ID — values that are unique and evenly distributed). A low-cardinality partition key (e.g., status = "active"/"inactive") creates hot partitions that throttle performance.
• DynamoDB has no joins. Design your table access patterns upfront — think in queries, not entities. One table design (putting multiple entity types in one table) is the advanced but optimal pattern.
• Free tier: 25 GB storage + 25 RCUs + 25 WCUs per month — always free, not just 12 months.

• 1 RCU = 1 strongly consistent read per second for items up to 4 KB, or 2 eventually consistent reads per second. 1 WCU = 1 write per second for items up to 1 KB.
• On-Demand is ~5–7x more expensive than Provisioned at equivalent sustained throughput. Use On-Demand for unpredictable or new workloads; switch to Provisioned once traffic patterns are known.

• GSI reads are eventually consistent — the GSI may lag behind the base table by milliseconds to seconds. Never use a GSI for reads that must reflect the very latest write.

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  default = "us-east-1"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-app-uploads-${var.region}"
}

resource "aws_s3_bucket_versioning" "my_bucket" {
  bucket = aws_s3_bucket.my_bucket.id
  versioning_configuration { status = "Enabled" }
}

• terraform init: download providers and modules, initialise the backend. Run once per project or after backend/provider changes.
• terraform plan: show what will be created, changed, or destroyed. Reads current state and compares to your code. Always review this output before applying.
• terraform apply: execute the plan. Prompts for confirmation. Writes results to state file.
• terraform destroy: destroys all resources managed by the current state. Use carefully.

• Never run terraform apply in CI without first reviewing the plan output. A -replace or -destroy flag in the wrong hands deletes production resources.
• terraform import: bring an existing manually-created resource under Terraform management without recreating it.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

• State files can contain sensitive values (RDS passwords, private keys). Enable S3 bucket encryption and restrict access with bucket policies.
• Never edit the state file manually. Use terraform state mv, terraform state rm, or terraform import for state surgery.

• Avoid deeply nested modules — they make debugging hard. Flat module structures are more readable.
• Pin module versions (version = "5.5.0") to avoid unexpected breaking changes from upstream updates.

AWSTemplateFormatVersion: '2010-09-09'
Description: My application stack
Parameters:
  InstanceType:
    Type: String
    Default: t3.micro
Resources:          # required
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: ami-0abcdef1234567890
Outputs:
  InstanceId:
    Value: !Ref MyInstance

• If a stack update fails, CloudFormation automatically rolls back to the previous state. This is generally helpful but means you must investigate why the update failed before retrying.
• Deleting a stack deletes all resources in it (by default). Use DeletionPolicy: Retain on critical resources like RDS and S3 to protect them.

• Manual changes to CloudFormation-managed resources cause drift. If you update a resource manually and then run CloudFormation, it may overwrite your manual change or fail with a conflict. Always make changes through CloudFormation or Terraform — never manually in the console for IaC-managed resources.