AWS Service Index

A searchable, filterable reference of the AWS services that matter to infrastructure, data, and platform teams. Search any field; filter by domain or operational model. Click a row to expand what it is, when to use it, the main gotcha, and a cost note. This is the fast lookup layer; the deep-dive tabs carry the detail.

Tip: click any row to expand. The deep-dive tabs on the left cover each domain in depth.

1. AWS Fundamentals

The global infrastructure, account model, and organizational primitives that every other decision sits on top of. Get the account topology and Region/AZ model right first; almost everything else is easier to change later than these are.

What AWS is

AWS is a collection of independent services, each exposed as an API, running in data centers grouped into Regions around the world. You do not "log into a server"; you make authenticated, authorized API calls (via the console, CLI, SDK, or IaC) that create, configure, and destroy resources. Two consequences follow and shape everything:

• Every action is an IAM-authorized API call. Security, automation, and troubleshooting all reduce to "which principal called which API on which resource, and was it allowed."
• Services are largely regional and independent. A failure or a limit in one service/Region usually does not cascade to others. You compose resilient systems from these independent pieces.

AWS global infrastructure

Accounts and AWS Organizations

An AWS account is the fundamental container and the strongest isolation boundary AWS offers: separate resources, separate IAM, separate default limits, and a separate bill. Serious environments do not run everything in one account. They use many accounts, grouped and governed by AWS Organizations.

Control Tower and the Landing Zone

A landing zone is a pre-configured, secure, multi-account baseline: the org structure, centralized logging, guardrails, identity, and network scaffolding, ready before workloads arrive. AWS Control Tower is the managed way to build and maintain one.

• Account Factory vends new accounts from a standard blueprint (baseline IAM, logging, guardrails, VPC).
• Guardrails are preventive (SCP-based) and detective (Config-based) controls applied per OU.
• It wires up a Log Archive account and an Audit/Security account automatically.

Reference multi-account structure

Naming, ARNs, tags, and Resource Groups

• ARN (Amazon Resource Name) uniquely identifies every resource: arn:aws:service:region:account-id:resource. IAM policies, cross-account grants, and automation all reference ARNs. Some are global (no Region), like IAM and S3 buckets.
• Tags are key/value metadata. They drive cost allocation, access control (ABAC), automation targeting, and inventory. Define a mandatory tagging standard early (Owner, Environment, CostCenter, Application, DataClassification) and enforce it with SCPs/Config/tag policies.
• Resource Groups collect resources by tag or CloudFormation stack for bulk operations and views.

Ways to interact with AWS

Decide before production

• Account topology and OU structure (multi-account from the start; retrofitting is painful).
• Region strategy: primary Region, whether multi-Region DR is required, allowed Regions (enforced by SCP).
• Network CIDR plan across all VPCs and on-prem (non-overlapping, room to grow).
• Identity: IAM Identity Center wired to your corporate IdP; no per-account IAM users for humans.
• Centralized logging (CloudTrail org trail, Config, VPC Flow Logs) to a locked log-archive account.
• Guardrails: baseline SCPs and Config rules; GuardDuty and Security Hub org-wide.
• Tagging standard and cost allocation tags activated.
• IaC tooling and pipeline; state management strategy.
• Backup and DR baseline (AWS Backup plans, RTO/RPO targets).

Common mistakes in account design

2. Identity and Access Management Deep Dive

IAM is the authorization engine in front of every AWS API call. Understand the evaluation logic and the difference between the policy types, and most "why can/can't this work" questions answer themselves.

The building blocks

STS, temporary credentials, and role assumption

STS issues short-lived credentials (access key + secret + session token) when a principal assumes a role or federates. This is how you avoid long-lived keys everywhere:

• Instance profile attaches a role to EC2; the app reads temporary creds from IMDSv2. No keys on disk.
• Task role (ECS) / IRSA or Pod Identity (EKS) / execution role (Lambda) give containers and functions scoped credentials.
• Cross-account roles: a principal in account A assumes a role in account B whose trust policy permits it.
• Federation: SAML or OIDC exchanges an external identity for AWS credentials (the basis of IAM Identity Center and web/OIDC workloads like GitHub Actions).

IAM Identity Center and federation

IAM Identity Center (formerly AWS SSO) is how humans should access AWS across many accounts. You connect it to an identity source (Microsoft Entra ID, Okta, or its built-in directory) via SAML/SCIM, define permission sets (which become IAM roles in each target account), and assign users/groups to accounts. Users get a portal, pick an account and role, and receive short-lived credentials. No per-account IAM users, no long-lived keys, centralized deprovisioning.

MFA, access keys, and credential hygiene

• Enforce MFA everywhere, especially root and any remaining IAM users. Prefer hardware/FIDO2 for privileged access.
• Root account: hardware MFA, no access keys, used only for the handful of tasks that require it. Lock it away.
• Avoid long-lived access keys. Where unavoidable, rotate on a schedule and scope tightly. Prefer roles/federation.
• Use the credential report (account-wide CSV of users, key age, MFA, last use) and last-accessed data to prune.

Example policy statements

Each example below states what it allows, where to attach it, its risk level, a safer alternative, and how it gets misused.

Example 1: read-only access to one S3 bucket

# Identity-based policy attached to a role/permission set
{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-reports-bucket" },
    { "Sid": "GetObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-reports-bucket/*" }
  ]
}

Example 2: the dangerous one - full admin

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "*", "Resource": "*" }
  ]
}

Example 3: a cross-account trust policy

# Trust policy ON the role in account B (the account being accessed)
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/CICDDeployer" },
      "Action": "sts:AssumeRole",
      "Condition": { "StringEquals": { "sts:ExternalId": "shared-secret-value" } } }
  ]
}

Example 4: a permission boundary for delegated role creation

# Boundary limiting what any role a team creates can ever do
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Action": ["s3:*","dynamodb:*","logs:*","cloudwatch:*"],
      "Resource": "*" }
  ]
}

Least-privilege design in practice

• Start from zero and add specific actions/resources, not from * and trim.
• Use IAM Access Analyzer policy generation to build a policy from actual CloudTrail activity.
• Add conditions: aws:PrincipalOrgID, aws:SourceIp, aws:SourceVpce, aws:RequestedRegion, tag conditions (ABAC).
• Prefer ABAC (attribute/tag-based) for scale: "allow if resource tag Team = principal tag Team" instead of enumerating resources.
• Review with last-accessed data and prune unused permissions periodically.

Tooling

The AWS IAM mental model

When you evaluate any "is this allowed?" question, walk this in order. AWS evaluates every request against all applicable policies:

Break-glass access

Even with SSO, keep a tightly controlled emergency path for when the IdP or Identity Center is unavailable: a dedicated break-glass IAM role or user per critical account, hardware MFA, credentials sealed and split, every use alarmed via CloudTrail/EventBridge to security. Test it periodically so it works when you need it.

Common AWS IAM mistakes

3. Networking Deep Dive

The VPC and everything around it. Networking is where the most time is lost in AWS, because reachability depends on the intersection of routing, security groups, NACLs, gateways, and DNS, all of which must line up. This section covers the model, the diagrams, and the runbooks.

Core building blocks

CIDR planning

• Pick RFC 1918 space with room to grow (a /16 per VPC is common). Reserve distinct ranges per environment/Region/account.
• Never overlap CIDRs across VPCs or with on-premises if they might ever connect. Overlap makes Transit Gateway/peering/VPN routing impossible without NAT.
• Leave room for multiple subnet tiers across 3 AZs (public, private-app, private-data, per AZ).
• Watch IP consumption: the EKS VPC CNI, interface endpoints, and large fleets consume many ENIs/IPs.

Diagram: three-tier VPC across AZs

Diagram: private subnet reaching S3 via a Gateway VPC endpoint

Diagram: hub-and-spoke with Transit Gateway

Connecting networks: which option

Route 53 and DNS

• Public hosted zones serve internet DNS; private hosted zones serve names inside associated VPCs.
• Resolver endpoints (inbound/outbound) bridge DNS between on-prem and VPC for hybrid name resolution.
• Routing policies: simple, weighted, latency, failover, geolocation, geoproximity, multivalue. Failover + health checks are the basis of DNS-level DR.
• Alias records point to AWS resources (ALB, CloudFront, S3 website) and are free to query.

Firewalls and traffic security

Visibility

• VPC Flow Logs: record accepted/rejected traffic metadata per ENI/subnet/VPC to CloudWatch Logs or S3. Essential for "is traffic even arriving, and is it being rejected."
• Reachability Analyzer: static analysis of whether a path exists between two resources and, if not, which component blocks it. The fastest way to debug SG/NACL/route problems.
• Traffic Mirroring: copy packets to security/monitoring appliances for deep inspection.

Networking troubleshooting runbooks

AWS networking gotchas

4. Compute Deep Dive

From EC2 virtual machines to Lambda functions. The recurring decision is how much of the stack you want to own: full OS (EC2), containers (ECS/EKS/Fargate, covered in the Containers tab), or just code (Lambda). This tab focuses on EC2 and the surrounding compute primitives.

EC2 essentials

Choosing an instance family

Purchasing and capacity models

Auto Scaling and high availability

• Run instances in an Auto Scaling Group spanning at least 3 AZs, behind a load balancer, launched from a launch template (launch configurations are legacy).
• Use ELB health checks (not just EC2 status checks) so unhealthy-but-running app instances are replaced.
• Set scaling policies (target tracking on CPU/requests) and lifecycle hooks for graceful add/remove.
• Use mixed instances + Spot in the ASG for cost with capacity resilience.
• Treat instances as cattle: no unique state on the box; store state in RDS/S3/ElastiCache.

Managing EC2 with Systems Manager

Other compute options

EC2 operational runbooks

5. Storage Deep Dive

Block, object, and file storage, plus archive, backup, and data-movement services. The first decision is almost always block (EBS) vs object (S3) vs file (EFS/FSx); get that right and the rest is configuration.

Choosing the storage type

EBS in depth

• Snapshots are incremental, stored in S3 (managed), and are how you back up, copy across AZ/Region, and create AMIs.
• Encryption via KMS; enable encryption-by-default at the account level so no unencrypted volume is ever created.
• Multi-Attach (io2) lets a volume attach to multiple instances in one AZ, but the app/cluster filesystem must handle concurrency (for example clustered databases). Not a general share.
• Performance: gp3 gives 3,000 IOPS / 125 MB/s baseline, tunable up; ensure the instance is EBS-optimized and large enough to not cap volume throughput.

S3 in depth

Storage classes

Key features

• Versioning keeps prior object versions (protects against overwrite/delete); pair with lifecycle to expire noncurrent versions.
• Lifecycle rules transition objects to cheaper classes and expire them on a schedule.
• Object Lock (WORM) enforces retention for compliance/ransomware protection; combine with a backup account.
• Replication (CRR/SRR) copies objects across Regions/buckets for DR or locality.
• Multipart upload for large objects; pre-signed URLs for temporary, credential-free access.
• Access Points give per-application access policies to a shared bucket.

S3 security

EFS and FSx

• EFS: regional, elastic NFS; create a mount target per AZ so every AZ can mount it. Performance modes (General Purpose vs Max I/O) and throughput modes (Bursting/Elastic/Provisioned). Lifecycle to IA/Archive for cost. Higher latency/cost than EBS for single-instance work, so use it when you genuinely need a shared filesystem.
• FSx for Windows File Server: managed SMB with AD integration, for Windows apps and shares.
• FSx for Lustre: high-performance parallel filesystem for HPC/ML, can link to S3.
• FSx for NetApp ONTAP: full ONTAP (snapshots, dedup, compression, SnapMirror, multi-protocol) for enterprises standardizing on NetApp.
• FSx for OpenZFS: ZFS features (snapshots, clones) with NFS access.

Data movement and hybrid

Storage decision examples

Storage gotchas

6. Database Services Deep Dive

AWS offers a purpose-built database for almost every workload. The hard part is not any single service; it is choosing correctly and understanding exactly what you give up in control when you move from self-managed to managed. This section is written with DBAs in mind.

The database portfolio

When to use what (decision table)

HA, DR, scaling, backup, patching across services

Operational features you should use

• Performance Insights: database load by wait event and top SQL; the first place to look for RDS/Aurora performance issues.
• Enhanced Monitoring: OS-level metrics at high resolution.
• RDS Proxy: connection pooling in front of RDS/Aurora; smooths connection storms (important for Lambda and many-client apps), preserves connections across failover.
• Blue/Green deployments: create a synchronized green copy, test, then switch with minimal downtime (great for major-version upgrades).
• Parameter groups / option groups: engine configuration and features; the managed equivalent of tuning init.ora and installing options, within AWS-permitted bounds.
• Secrets Manager + KMS: managed credential rotation and encryption at rest.

Enterprise examples

AWS database gotchas for Oracle DBAs

This is the section most likely to catch an experienced Oracle DBA off guard. RDS is genuinely managed, which means AWS takes away control you are used to having.

Migration

• DMS (Database Migration Service): homogeneous and heterogeneous migration with CDC for near-zero-downtime cutover.
• Schema Conversion Tool (SCT): converts schema/code for heterogeneous engine changes (for example Oracle to PostgreSQL/Aurora).
• For Oracle-to-Oracle lift-and-shift, consider native tooling (Data Pump, RMAN, Data Guard) plus DMS for the CDC phase. Always run data validation. See the Migration & DR tab.

7. Load Balancing and Traffic Management

Distributing traffic to healthy targets, terminating TLS, routing by content, and steering users globally. Pick the right load balancer for the protocol and the requirement; most "it works locally but not through the LB" issues are health checks, security groups, or listener rules.

Load balancer types

Core concepts

Global traffic management

Choosing quickly

• HTTP(S) app with routing rules, containers, or Lambda targets -> ALB.
• Millions of connections, gaming/IoT/TCP, static IP, source IP preservation, or exposing a service via PrivateLink -> NLB.
• Inline third-party firewall/IDS for all traffic -> GWLB.
• Global static web assets -> CloudFront. Global low-latency TCP/UDP -> Global Accelerator. Cross-Region DR -> Route 53 failover.

Troubleshooting: target unhealthy and related

8. Security Deep Dive

Security in AWS is layered: the shared responsibility split, identity, network, data protection, detection, and governance. Most incidents trace to a small set of mistakes (public S3, over-broad IAM, open security groups, no detection). Close those first, then build depth.

The shared responsibility model

The security service map

Data protection

• KMS: customer-managed keys with key policies + IAM; integrated with S3, EBS, RDS, secrets, and more. Enable encryption-by-default account-wide. Deleting/disabling a key can make data unrecoverable, so manage key lifecycle deliberately; use multi-Region keys only when needed.
• CloudHSM: dedicated single-tenant HSM for strict compliance or custom cryptographic needs.
• Secrets Manager vs SSM Parameter Store: Secrets Manager for secrets needing rotation (DB creds); Parameter Store SecureString for simpler/cheaper config and secrets without rotation.
• ACM: managed TLS certificates, auto-renewed, for LBs/CloudFront/API GW.
• Encrypt in transit (TLS) and at rest (KMS) everywhere; make it the default, not a per-resource decision.

Detection and response

How to secure specific things

Production security checklist

Common security mistakes

9. Observability, Monitoring, and Operations

You cannot operate what you cannot see. CloudWatch is the hub for metrics, logs, and alarms; CloudTrail and Config cover audit and configuration; Systems Manager covers fleet operations. The goal is useful signal, not noise.

The observability stack

What to monitor, by resource

Designing good alarms

• Alarm on symptoms users feel (error rate, latency, unhealthy hosts, saturation) before alarming on causes.
• Use appropriate periods, evaluation periods, and M-of-N datapoints to avoid flapping.
• Use anomaly detection bands for metrics without a fixed threshold.
• Set alarms to actionable destinations; page only what a human must act on now. Everything else is a dashboard or ticket.
• Alarm on missing data where absence is bad (a stopped heartbeat).
• Composite alarms to reduce noise (alert once when several related alarms fire).

Example alarms

Centralizing observability across accounts

• Cross-account CloudWatch observability: link source accounts to a central monitoring account for a unified metrics/logs/traces view.
• Ship logs to a central account (subscription filters -> Kinesis Firehose -> central S3, or Security Lake for security data).
• Aggregate GuardDuty/Security Hub/Config to delegated admin accounts.
• Standardize dashboards and alarms via IaC so every account gets the same baseline.

10. Containers, Kubernetes, and Cloud Native

Running containers, functions, and event-driven systems on AWS. The main choice is ECS vs EKS vs Lambda, and then EC2 vs Fargate for the compute underneath. Pick by operational appetite and portability needs, not by hype.

The choices

How networking works with containers

• ECS awsvpc mode and EKS VPC CNI give each task/pod its own ENI and VPC IP. This gives real VPC networking and SGs per task/pod but consumes subnet IPs fast; plan CIDRs accordingly (or use prefix delegation / custom networking on EKS).
• Load balancers: ALB in front of ECS services / the AWS Load Balancer Controller for EKS Ingress; NLB for TCP/UDP or extreme performance.
• Service-to-service discovery: ECS Service Connect / Cloud Map; Kubernetes Services + CoreDNS on EKS.

How IAM works with containers

• ECS task role: permissions for the app in the container; the separate execution role lets ECS pull images and write logs. Do not rely on the EC2 instance role for app permissions.
• EKS IRSA / EKS Pod Identity: map a Kubernetes service account to an IAM role so pods get scoped, short-lived credentials, not the node role.
• Least-privilege per task/pod is the goal; the node/instance role should be minimal.

CI/CD and registry

• ECR for private images; enable scan-on-push and lifecycle policies to purge old tags.
• CodeBuild/CodeDeploy/CodePipeline or GitHub Actions/GitLab for build-test-deploy; deploy with rolling or blue/green (CodeDeploy supports ECS blue/green).
• CodeArtifact for private package repositories.

Serverless and event-driven building blocks

Architecture examples

Operating containers

• Monitor task/pod health, restarts, CPU/memory limits vs usage, and pending/unschedulable tasks (capacity).
• Right-size task/pod requests and limits; over-requesting wastes capacity, under-requesting causes throttling/OOM.
• Use Container Insights (CloudWatch) or Prometheus/Grafana for cluster and workload metrics.
• On EKS, keep the control plane and node AMIs/add-ons on supported versions; plan quarterly upgrades.

11. Analytics, Data, and Integration

Storing, moving, transforming, querying, and streaming data at scale, plus the integration services that connect systems. The lake-on-S3 plus purpose-built engines model is the backbone of most modern AWS data platforms.

The data and analytics services

Integration services

Common data patterns

12. AI, ML, and Generative AI on AWS

From custom ML on SageMaker to generative AI on Bedrock and applied-AI APIs. The enterprise question is rarely "which model" and usually "how do we connect models to our data safely, cheaply, and with an audit trail." This section covers both the services and the governance.

Generative AI: Amazon Bedrock

• Foundation models from multiple providers (Anthropic Claude, Amazon Nova/Titan, Meta, Mistral, and others) behind one API. Availability varies by Region; verify.
• Knowledge Bases: managed RAG (chunk, embed, store, retrieve) over your data in S3, backed by a vector store.
• Agents: orchestrate multi-step tasks and tool/API calls with a model.
• Guardrails: content filters, denied topics, PII redaction, and grounding checks applied to prompts/responses.
• Pricing: per input/output token (on-demand) or provisioned throughput; Knowledge Bases add embedding + vector-store cost.

Custom ML: Amazon SageMaker

• Studio (IDE), training jobs, hyperparameter tuning, endpoints (real-time/serverless/async/batch), Pipelines (MLOps), Model Registry, Feature Store, and Clarify (bias/explainability).
• Use for training/fine-tuning your own models and productionizing the full ML lifecycle.

Applied-AI APIs

Vector stores for RAG

Enterprise GenAI patterns

Governance and safety warnings

13. Migration and Disaster Recovery

Getting workloads into AWS, and keeping them recoverable once there. Migration and DR share tooling (replication, backup, failover) and the same core discipline: define your objectives (RTO/RPO) first, then pick the pattern that meets them at acceptable cost.

RTO and RPO drive everything

Migration services

The 7 Rs of migration

DR patterns (ordered by RTO/RPO and cost)

DR building blocks

• AWS Backup: policy-based backups with cross-Region/cross-account copies and Vault Lock (immutability against ransomware).
• Elastic Disaster Recovery (DRS): continuous block replication for low-RPO server recovery; drill without disrupting production.
• Database replication: RDS cross-Region read replicas, Aurora Global Database (sub-second lag), DynamoDB Global Tables (active-active).
• Route 53 failover: health-check-based DNS failover to the DR Region.
• Multi-AZ for in-Region resilience (the default); multi-Region for Region-level DR.
• IaC: the DR Region must be reproducible from code; manual DR is DR that fails.

Architecture examples

14. Cost Management and Governance

AWS cost is an engineering discipline, not a finance afterthought. The bill is driven by architecture decisions (data transfer, NAT, idle resources, over-provisioning) far more than by unit prices. Governance keeps those decisions consistent across many accounts.

Pricing model basics

The costs that surprise teams

Cost management tools

Governance

• Organizations + consolidated billing: one bill, shared volume discounts and Savings Plan/RI benefit across accounts.
• SCPs: restrict Regions, instance families, or services to prevent expensive mistakes.
• Tagging strategy + tag policies: enforce mandatory tags (Owner, Environment, CostCenter, App) so cost is attributable.
• Service Quotas: know and manage limits proactively (they also cap runaway spend).
• Control Tower / landing zone: consistent guardrails and account baselines including budgets.
• Per-account or per-OU budgets with alerts; chargeback/showback from CUR.

Cost optimization examples

Monthly AWS cost review checklist

15. Enterprise Architecture Patterns

Reference designs for real AWS deployments. Each card gives the use case, the services, the traffic flow, and how security, HA, DR, monitoring, and cost play out, plus the risks and common mistakes. Use them as starting points, not blueprints to copy blindly.

16. Troubleshooting Guides

Runbooks for the failures you will actually hit. Each has symptoms, likely causes, checks (console path + CLI where useful), fixes, and prevention. The meta-rule: almost every AWS problem is IAM (permission), networking (reachability), or a quota/limit. Isolate which, then dig.

Compute and access

aws ec2 describe-instance-status --instance-ids i-0abc
aws ec2 describe-security-groups --group-ids sg-0abc

Storage

Networking and load balancing

Database

IAM and serverless

Observability

17. AWS CLI, CloudFormation, CDK, and Terraform Examples

Practical, copy-friendly automation. Prefer IaC for anything that must be reproducible, reviewed, or promoted across environments. Reserve the CLI for investigation and glue. All snippets are illustrative; verify against current provider/service versions.

AWS CLI

Setup and profiles (with SSO / role assumption)

# Configure IAM Identity Center (SSO) - the recommended way for humans
aws configure sso
# ~/.aws/config: a profile that assumes a role via SSO
[profile prod-admin]
sso_session = corp
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = us-east-1

# A profile that assumes a cross-account role from a base profile
[profile deploy]
role_arn = arn:aws:iam::444455556666:role/CICDDeployer
source_profile = prod-admin
external_id = shared-secret-value

# Use a profile
aws sts get-caller-identity --profile deploy
aws s3 ls --profile prod-admin

Common commands

# Who am I / what account
aws sts get-caller-identity

# EC2
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].[InstanceId,InstanceType,PrivateIpAddress]" --output table

# Assume a role manually
aws sts assume-role --role-arn arn:aws:iam::444455556666:role/ReadOnly \
  --role-session-name debug

# S3 sync
aws s3 sync ./build s3://my-site-bucket --delete

# Tail logs
aws logs tail /aws/lambda/my-func --follow

# Start a keyless shell (no SSH)
aws ssm start-session --target i-0abc123

CloudFormation (YAML)

# An S3 bucket, encrypted, private, versioned
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  ReportsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "reports-${AWS::AccountId}-${AWS::Region}"
      VersioningConfiguration: { Status: Enabled }
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault: { SSEAlgorithm: aws:kms }
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      Tags:
        - { Key: Environment, Value: prod }
        - { Key: Owner, Value: platform }
Outputs:
  BucketName:
    Value: !Ref ReportsBucket

Deploy across accounts/Regions with StackSets; detect manual changes with drift detection.

AWS CDK (TypeScript)

import { Stack, StackProps, RemovalPolicy } from "aws-cdk-lib";
import { Bucket, BucketEncryption, BlockPublicAccess } from "aws-cdk-lib/aws-s3";
import { Construct } from "constructs";

export class StorageStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    new Bucket(this, "ReportsBucket", {
      versioned: true,
      encryption: BucketEncryption.KMS_MANAGED,
      blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
      removalPolicy: RemovalPolicy.RETAIN,
    });
  }
}

CDK synthesizes to CloudFormation, so you inherit its deploy semantics with real language constructs, reuse, and tests.

Terraform

Provider and remote state

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  # Remote state in S3 with DynamoDB lock (create these once, separately)
  backend "s3" {
    bucket         = "tfstate-111122223333"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

provider "aws" {
  region = "us-east-1"
  default_tags { tags = { Environment = "prod", ManagedBy = "terraform" } }
}

VPC (minimal, three-AZ public/private)

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "prod-vpc" }
}

resource "aws_subnet" "private" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 4, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  tags = { Name = "private-${count.index}", Tier = "private" }
}

EC2 with instance profile and IMDSv2 enforced

resource "aws_instance" "app" {
  ami                    = data.aws_ami.al2023.id
  instance_type          = "m7i.large"
  subnet_id              = aws_subnet.private[0].id
  iam_instance_profile   = aws_iam_instance_profile.app.name
  vpc_security_group_ids = [aws_security_group.app.id]
  metadata_options {
    http_tokens   = "required"   # enforce IMDSv2
    http_endpoint = "enabled"
    http_put_response_hop_limit = 1
  }
  tags = { Name = "app-1", Environment = "prod" }
}

S3 bucket, locked down

resource "aws_s3_bucket" "reports" {
  bucket = "reports-111122223333-us-east-1"
}
resource "aws_s3_bucket_versioning" "reports" {
  bucket = aws_s3_bucket.reports.id
  versioning_configuration { status = "Enabled" }
}
resource "aws_s3_bucket_public_access_block" "reports" {
  bucket                  = aws_s3_bucket.reports.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}
resource "aws_s3_bucket_server_side_encryption_configuration" "reports" {
  bucket = aws_s3_bucket.reports.id
  rule { apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" } }
}

IAM role and least-privilege policy

data "aws_iam_policy_document" "assume" {
  statement {
    actions = ["sts:AssumeRole"]
    principals { type = "Service", identifiers = ["ec2.amazonaws.com"] }
  }
}
resource "aws_iam_role" "app" {
  name               = "app-role"
  assume_role_policy = data.aws_iam_policy_document.assume.json
}
data "aws_iam_policy_document" "app" {
  statement {
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.reports.arn}/*"]
  }
}
resource "aws_iam_role_policy" "app" {
  role   = aws_iam_role.app.id
  policy = data.aws_iam_policy_document.app.json
}
resource "aws_iam_instance_profile" "app" {
  name = "app-profile"
  role = aws_iam_role.app.name
}

CloudWatch alarm

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "app-cpu-high"
  namespace           = "AWS/EC2"
  metric_name         = "CPUUtilization"
  statistic           = "Average"
  period              = 300
  evaluation_periods  = 2
  threshold           = 80
  comparison_operator = "GreaterThanThreshold"
  dimensions          = { InstanceId = aws_instance.app.id }
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

Terraform best practices

• Remote state in S3 with DynamoDB locking (or a managed backend); never commit state to git; state contains secrets.
• Separate state per environment (and often per component) to limit blast radius.
• Modules for reusable components (network, EKS, RDS); version them.
• Environment separation via directories/workspaces + tfvars; distinct accounts per environment.
• Pin provider and module versions; run plan in CI and require review before apply.
• Use default_tags for consistent tagging; enforce with policy-as-code (OPA/Sentinel/Checkov).
• Least-privilege the CI role that runs Terraform; do not use admin.

Modular structure

infra/
  modules/
    vpc/          # reusable VPC module
    eks/
    rds/
  envs/
    prod/
      main.tf     # calls modules with prod inputs + prod backend
      prod.tfvars
    nonprod/
      main.tf
      nonprod.tfvars

18. AWS Well-Architected Framework

Six pillars for evaluating and improving architectures. Treat them as a review lens with concrete questions, not a checklist to tick. A real Well-Architected Review surfaces trade-offs you made implicitly and forces you to make them on purpose.

Operational Excellence

Meaning: run and monitor systems to deliver business value and continually improve. Why: most outages and slow recoveries come from operational gaps, not architecture.
Services: CloudFormation/CDK/Terraform, Systems Manager, CloudWatch, EventBridge, CloudTrail, Config, DevOps Guru.
Practical: everything as code, small frequent reversible changes, runbooks/playbooks, game days, observability built into the platform, post-incident reviews that produce fixes.

Security

Meaning: protect data, systems, and assets. Why: a single misconfiguration (public S3, over-broad IAM) can be catastrophic.
Services: IAM/Identity Center, Organizations/SCPs, KMS, Secrets Manager, CloudTrail, Config, GuardDuty, Security Hub, WAF/Shield, Macie, Inspector.
Practical: least privilege, identity-based access with MFA, encryption everywhere, private-by-default networking, centralized immutable logging, detection wired to response, automated guardrails.

Reliability

Meaning: a workload performs its function correctly and recovers from failure. Why: availability and recovery are what the business feels.
Services: Multi-AZ everything, Auto Scaling, ELB, Route 53, AWS Backup, Elastic Disaster Recovery, Aurora Global DB, Service Quotas.
Practical: design for failure (assume AZ loss), automate recovery (self-healing ASGs, auto-failover DBs), manage quotas proactively, test DR with game days, define and measure RTO/RPO.

Performance Efficiency

Meaning: use resources efficiently and adapt as demand and technology change. Why: right technology + right sizing delivers performance without waste.
Services: the right compute (Graviton, serverless), purpose-built databases, caching (CloudFront/ElastiCache/DAX), Compute Optimizer, auto scaling.
Practical: pick purpose-built services over one-size-fits-all, benchmark, cache aggressively, scale elastically, adopt newer instance generations, use managed/serverless to offload undifferentiated work.

Cost Optimization

Meaning: deliver business value at the lowest price point. Why: unmanaged cloud cost grows silently through idle and over-provisioned resources.
Services: Cost Explorer, Budgets, CUR, Compute Optimizer, Savings Plans, Spot, S3 lifecycle, Trusted Advisor.
Practical: right-size, schedule non-prod off, commit steady baseline (Savings Plans), Spot for interruptible, lifecycle storage, cut data-transfer/NAT, attribute cost via tags, review monthly.

Sustainability

Meaning: minimize the environmental impact of running cloud workloads. Why: efficiency and sustainability align, and it is increasingly a reporting/compliance requirement.
Services/levers: Graviton (better perf/watt), serverless (no idle), right-sizing, storage-class efficiency, Region choice, the Customer Carbon Footprint Tool.
Practical: maximize utilization, eliminate idle, prefer efficient instance types, delete unused data, choose managed/serverless to raise shared-infrastructure efficiency.

19. Learning Path

A structured route from fundamentals to enterprise-grade AWS. Each level lists what to learn, why it matters, hands-on labs, common mistakes, and the outcome you should be able to demonstrate. Build in a sandbox account with a budget alarm; tear down what you create.

Beginner

Intermediate

Advanced

Suggested certification path (optional)

Sources and Accuracy

How to treat the content in this portal, and where to confirm current facts.

Primary sources (preferred)

• AWS Documentation - the authoritative per-service reference.
• AWS Well-Architected Framework - pillars, lenses, and the Well-Architected Tool.
• AWS Architecture Center and Prescriptive Guidance - reference architectures and patterns.
• AWS Security Documentation and the Security Reference Architecture (AWS SRA).
• Service Quotas and the AWS Pricing Calculator - for current limits and cost estimates.
• AWS What's New and service release notes - for the latest features and changes.
• The AWS Console - the ground truth for what exists in your account/Region right now.

What changes fast (always verify)