Amazon Web Services Intermediate

Amazon RDS (Relational Database Service) runs managed relational engines so you stop babysitting servers. It supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and the AWS-built Aurora.

RDS handles the undifferentiated heavy lifting: provisioning, OS and engine patching, automated backups, and point-in-time recovery. You still own the schema, queries, and indexes.

• Multi-AZ — a synchronous standby replica in another Availability Zone for automatic failover and high availability.
• Read replicas — asynchronous copies that scale read traffic; they do not provide automatic failover by default.
• Storage autoscaling grows the volume as data grows.

A key distinction: Multi-AZ is about availability (failover), while read replicas are about read scalability (performance).

DynamoDB is a fully managed, serverless key-value and document NoSQL database with single-digit-millisecond latency at any scale. There are no servers to manage and it scales horizontally for you.

Every item lives in a table and is found by its primary key, which is either a single partition key or a partition key + sort key pair. The partition key determines which physical partition stores the item, so a well-chosen key spreads load evenly.

• Capacity modes — on-demand (pay per request, no planning) or provisioned (set read/write capacity units, optionally with auto scaling).
• Global Secondary Index (GSI) — query on non-key attributes.
• DynamoDB Streams — a change log you can feed to Lambda.

DynamoDB favours access-pattern-first design: you model the table around the queries you need, not normalised relations.

AWS Lambda runs your code without provisioning servers. You upload a function, choose a runtime (Node.js, Python, Java, Go, etc.), and Lambda runs it in response to events — an HTTP request, an S3 upload, a queue message, a schedule.

You pay only for execution time (rounded to the millisecond) and the memory you allocate; idle functions cost nothing. CPU scales with memory.

• Stateless — store state externally (DynamoDB, S3). The /tmp directory is ephemeral.
• Concurrency — Lambda runs many copies in parallel; cold starts add latency to a fresh execution environment.
• Timeout — a function may run up to 15 minutes.

Lambda is ideal for event-driven glue, lightweight APIs, and data processing — not long-running or stateful workloads.

Amazon API Gateway is a fully managed service for creating, publishing, and securing APIs at scale. It is the usual front door that turns HTTP requests into Lambda invocations (or routes them to other backends).

• REST APIs — feature-rich: request/response transformation, API keys, usage plans, caching.
• HTTP APIs — cheaper and lower-latency, ideal for simple Lambda or HTTP proxy integrations.
• WebSocket APIs — for real-time two-way communication.

It handles throttling (rate limiting), authorization (IAM, Cognito, or Lambda authorizers), and stages (e.g. dev and prod deployments of the same API).

A common serverless pattern is API Gateway in front of Lambda in front of DynamoDB — no servers anywhere in the stack.

AWS Elastic Beanstalk is a Platform-as-a-Service layer. You upload application code (Java, .NET, Node.js, Python, Ruby, PHP, Go, or a Docker image) and Beanstalk provisions and manages the underlying EC2 instances, load balancer, Auto Scaling group, and health monitoring for you.

It is the easiest way to deploy a web app on AWS while keeping full access to the resources it creates — you can still tweak the EC2 instances or security groups it manages.

• Environments — typically a web server tier (handles HTTP) and a worker tier (processes a queue).
• Deployment policies — all-at-once, rolling, rolling with additional batch, and immutable.
• You pay only for the underlying resources; Beanstalk itself has no extra charge.

Beanstalk sits between raw EC2 (maximum control) and Lambda (minimum management).

Amazon ECS (Elastic Container Service) is AWS-native container orchestration. You package an app as a container image, describe it in a task definition (CPU, memory, image, ports, environment), and ECS runs and maintains the desired number of tasks, usually behind a service for long-running workloads.

ECS offers two launch types:

• EC2 launch type — you manage a cluster of EC2 instances that host the containers.
• Fargate — serverless containers; AWS provisions the compute per task, you never manage EC2 hosts. You pay for the vCPU and memory each task requests.

Fargate removes server management at the cost of less low-level control. Choose EC2 launch type when you need custom instances, GPUs, or tighter bin-packing for cost.

Amazon EKS (Elastic Kubernetes Service) is managed Kubernetes. AWS runs and scales the highly available control plane (API server, etcd) for you, while your workloads run on worker nodes — self-managed EC2, managed node groups, or Fargate.

EKS suits teams already invested in the Kubernetes ecosystem (Helm, operators, portability across clouds). ECS is simpler and AWS-specific; EKS is more powerful and portable but more complex.

Amazon ECR (Elastic Container Registry) is a managed Docker/OCI image registry. You push images there, and ECS, EKS, or Lambda pull from it. ECR integrates with IAM for access control and can scan images for vulnerabilities.

Elastic Load Balancing offers three modern load balancer types, each operating at a different layer.

• Application Load Balancer (ALB) — Layer 7 (HTTP/HTTPS). It can route by path (/api vs /images), host header, or query string, terminate TLS, and target Lambda or containers. Ideal for web apps and microservices.
• Network Load Balancer (NLB) — Layer 4 (TCP/UDP/TLS). Extremely high throughput and low latency, preserves the client source IP, and gives a static IP per AZ. Ideal for non-HTTP or ultra-high-performance traffic.
• Gateway Load Balancer (GWLB) — Layer 3/4. Used to insert third-party network appliances (firewalls, intrusion detection) transparently into traffic flow.

Rule of thumb: ALB for content-based HTTP routing, NLB for raw TCP/UDP performance, GWLB for inline security appliances.

An Auto Scaling Group (ASG) keeps a fleet of EC2 instances at a desired size, replacing unhealthy instances and adding or removing capacity as demand changes. It is the backbone of elastic, fault-tolerant compute on EC2.

An ASG is defined by minimum, desired, and maximum capacity, and it launches instances from a launch template (the AMI, instance type, security groups, user data, and key pair to use).

• Target tracking — keep a metric near a target (e.g. average CPU at 50%); the ASG scales automatically.
• Step / simple scaling — react to CloudWatch alarm thresholds.
• Scheduled scaling — change capacity at known times.

Spreading instances across multiple Availability Zones lets the ASG survive an AZ failure.

A Virtual Private Cloud (VPC) is your isolated network in AWS, divided into subnets. A public subnet has a route to an Internet Gateway; a private subnet does not.

• NAT Gateway — lets instances in a private subnet reach the internet for outbound traffic (updates, API calls) while remaining unreachable from outside. It lives in a public subnet.
• VPC Peering — connects two VPCs privately so they route to each other. Peering is not transitive: A↔B and B↔C does not give A↔C.
• VPC Endpoints — reach AWS services privately without the internet. A Gateway endpoint (S3, DynamoDB) adds a route-table entry; an Interface endpoint (PrivateLink) puts an ENI in your subnet.

Security groups are stateful (per-instance); network ACLs are stateless (per-subnet).

Amazon Route 53 is AWS’s scalable DNS and domain registration service. (Port 53 is the DNS port.) It translates names like www.example.com into IP addresses and can route users intelligently with routing policies:

• Simple — one record, one answer.
• Weighted — split traffic by percentage (great for canary releases).
• Latency-based — send users to the lowest-latency Region.
• Failover — route to a healthy secondary when the primary fails health checks.
• Geolocation / Geoproximity — route by the user’s location.

Route 53 also supports alias records, which point a domain at AWS resources (ALB, CloudFront, S3 websites) without charge and can sit at the zone apex, unlike a plain CNAME.

Amazon CloudFront is AWS’s global CDN. It caches content at hundreds of edge locations near users, cutting latency and offloading traffic from your origin.

An origin is where the real content lives — an S3 bucket, an ALB, or any HTTP server. CloudFront sits in front and serves cached copies. The Time To Live (TTL) controls how long an object stays cached before CloudFront re-checks the origin.

• Origin Access Control (OAC) lets CloudFront read a private S3 bucket so users cannot bypass the CDN.
• CloudFront integrates with AWS WAF for filtering and ACM for free TLS certificates.
• You can invalidate cached paths to force a refresh after a deploy.

CloudFront improves both performance and security (DDoS absorption at the edge via AWS Shield).

Beyond users and groups, the powerful IAM concept is the role: a set of permissions that an entity assumes temporarily rather than long-lived credentials attached to a person.

A role has two parts: a permissions policy (what it can do) and a trust policy (who is allowed to assume it). Assuming a role via sts:AssumeRole returns temporary security credentials.

• EC2 instance profile — attaches a role to an instance so applications get rotating temporary credentials automatically. Never bake access keys into an AMI.
• Service roles — let services (Lambda, ECS tasks) act on your behalf.
• Cross-account access — a role in account B trusts account A, so users in A assume it.

Roles embody least privilege and remove the risk of leaked static keys.

Hard-coding secrets is dangerous. AWS gives three complementary services.

• AWS Secrets Manager — stores secrets (DB passwords, API keys) encrypted, controls access via IAM, and can automatically rotate them (e.g. an RDS password). It costs per secret.
• SSM Parameter Store — stores configuration and secrets too; standard parameters are free, SecureString parameters are encrypted with KMS. No built-in rotation. Great for config plus the occasional secret on a budget.
• AWS KMS — Key Management Service creates and controls the encryption keys that protect data across AWS (S3, EBS, RDS, Secrets Manager). It never exposes the raw key material.

Rule of thumb: use Secrets Manager when you need automatic rotation; Parameter Store for cheaper config; KMS underpins encryption for both.

Amazon CloudWatch is the observability hub for AWS. It collects three kinds of telemetry:

• Metrics — time-series numbers (CPU, request count, queue depth). EC2 sends basic metrics; the CloudWatch agent adds memory and disk. You can publish custom metrics.
• Logs — application and system logs grouped into log groups and log streams. You can search them and run Logs Insights queries.
• Alarms — watch a metric against a threshold and trigger actions: notify via SNS, scale an ASG, or run automation.

Dashboards visualise it all. CloudWatch is what turns Auto Scaling and incident response from guesswork into data-driven action.

Decoupling components is core to resilient cloud design. AWS offers three messaging services with different patterns.

• Amazon SQS — a managed queue. One producer puts messages in; one consumer (or fleet) pulls them out. Messages wait until processed, smoothing spikes. Standard queues are at-least-once and best-effort order; FIFO queues guarantee order and exactly-once processing.
• Amazon SNS — a publish/subscribe topic. One message is fanned out to many subscribers (queues, Lambdas, HTTP endpoints, email).
• Amazon EventBridge — an event bus that routes events by rules (content-based filtering) from AWS services, SaaS, or your apps to targets. Ideal for event-driven architectures and scheduling.

Pattern: SNS fans an event out to several SQS queues, each feeding its own consumer (the fan-out pattern).

Amazon S3 offers multiple storage classes that trade retrieval speed and cost. Picking the right class for each access pattern is a major cost lever.

• S3 Standard — frequent access, low latency, highest storage cost.
• S3 Standard-IA / One Zone-IA — infrequent access; cheaper storage, a retrieval fee.
• S3 Intelligent-Tiering — moves objects between tiers automatically based on usage, no retrieval fees.
• S3 Glacier Instant / Flexible Retrieval / Deep Archive — archival; very cheap storage, retrieval ranges from milliseconds to hours.

A lifecycle policy automates transitions (e.g. move to IA after 30 days, Glacier after 90, delete after 365) so you stop paying Standard prices for cold data.

Infrastructure as Code (IaC) means defining cloud resources in version-controlled files instead of clicking the console. AWS provides two main tools.

• AWS CloudFormation — declarative templates in YAML or JSON describe the desired resources. CloudFormation creates them as a stack, tracks drift, and can roll back on failure. You describe what you want, not how to build it.
• AWS CDK (Cloud Development Kit) — define infrastructure in a real programming language (TypeScript, Python, Java, Go). The CDK synthesises down to CloudFormation templates, so you get loops, conditionals, and reuse.

Both make environments reproducible and reviewable. The CDK suits developers who want abstraction; raw CloudFormation suits teams wanting plain declarative templates.

AWS provides a native CI/CD toolchain. AWS CodePipeline models a release as a series of stages — source, build, test, deploy — and runs them automatically whenever the source changes.

• Source — pulls code from CodeCommit, GitHub, or S3.
• AWS CodeBuild — a managed build service that compiles, tests, and packages your code in ephemeral containers, driven by a buildspec.yml file. You pay per build minute.
• AWS CodeDeploy — automates deployments to EC2, ECS, or Lambda, including blue/green and canary strategies.

Together they give a fully managed pipeline: a commit triggers a build, tests run, and a successful artifact is deployed — all without managing CI servers.

Durable data needs a deliberate backup strategy. AWS offers several mechanisms.

• EBS snapshots — point-in-time, incremental copies of a volume stored in S3. Only changed blocks are saved after the first snapshot, so they are space-efficient. You can create a new volume from any snapshot, even in another AZ or Region.
• RDS automated backups — enable point-in-time recovery within the retention window; you can also take manual DB snapshots that persist until you delete them.
• AWS Backup — a central service that schedules and enforces backup plans across EBS, RDS, DynamoDB, EFS and more, with retention and cross-Region copy.

Two metrics frame backup design: RPO (how much data you can afford to lose) and RTO (how quickly you must recover).