Raj's Notes

Cloud infrastructure

AWS compute, networking, identity, storage, Kubernetes control systems, queues, deployments, reliability, and recovery.

Scope#

How an application becomes a production service: first the internet and AWS boundaries around it, then containers and Kubernetes, scheduling, managed container platforms, asynchronous work, and day-two operation. The notes are sequential. Each product is introduced before its failure modes or operating details. Worked cases use a fictional bookshop whose names, values, and repository layouts exist only in these notes.

The final four notes revisit the cloud boundary in more depth. Internet edge and private connectivity follows public, private, and hybrid network paths; identity and cloud security follows credentials, authorization, secrets, encryption, and audit evidence; storage, backups, and disaster recovery separates live copies from recoverable history across object, block, file, and managed database storage; observability pipelines follows metrics, logs, and traces from instrumentation through collection, buffering, storage, query, rules, alerts, failure, and recovery.

How the collection fits together#

flowchart TB
  accTitle: Cloud infrastructure learning path
  accDescr: AWS foundations lead into containers, Kubernetes objects, control planes, networking, scheduling, and the EKS versus ECS comparison. The path then adds asynchronous systems, delivery, production operation, and shared services. Four deeper notes revisit networking, identity, storage, and observability.

  AWS["CI1<br/>AWS foundations"] --> ORCH["CI2–6<br/>Containers through managed orchestration"]
  ORCH --> ASYNC["CI7–8<br/>Kafka and Celery"]
  ASYNC --> DELIVERY["CI9<br/>IaC and GitOps"]
  DELIVERY --> OPS["CI10–11<br/>Operation and shared services"]

  AWS --> DEEP["CI12–14<br/>Networking, identity, storage, and recovery"]
  OPS --> OBS["CI15<br/>Observability pipelines"]

Reading path#

  1. Cloud foundations first maps accounts, Regions, Availability Zones, VPCs, subnets, service APIs, and the main AWS service families. It then follows synchronous and asynchronous application paths through compute, identity, networking, and storage.
  2. Containers and the Kubernetes object model starts with the process, image, port, and state concepts Kubernetes assumes, then separates Pods, Deployments, Services, and the other objects around a workload.
  3. Control planes, etcd, and reconciliation follows that declared workload through the API server, controllers, scheduler binding, kubelet, and durable control-plane state.
  4. Kubernetes networking, storage, and security adds the Service, gateway, volume, identity, and policy paths a running Pod needs.
  5. Scheduling, autoscaling, and noisy neighbors explains placement and runtime resource behavior before deriving scheduler scale limits.
  6. EKS and ECS compares the two managed container contracts after the Kubernetes and AWS layers are visible.
  7. Kafka first distinguishes queues, topics, event buses, retained logs, and workflows, then follows one retained record through Kafka.
  8. Celery applies the work-queue model to named background tasks, acknowledgements, retries, and worker failure.
  9. Infrastructure as code and GitOps supplies the reviewed change path for the infrastructure and workloads already introduced.
  10. Production operation defines service success, telemetry, scaling feedback, availability, recovery, and capacity.
  11. Shared production services uses platform interfaces, PostgreSQL pooling, and durable workflows as separate examples of owned resource contracts.
  12. Internet edge and private connectivity revisits CI1's request path at packet, transport, proxy, and hybrid-network depth.
  13. Identity, secrets, and cloud security revisits CI1's identity boundary and joins it to workload credentials, encryption, network policy, and audit evidence.
  14. Storage, backups, and disaster recovery revisits CI1's storage choices and separates live service, replicas, snapshots, backups, restore, RPO, and RTO.
  15. Observability pipelines follows the machinery that carries the production signals defined in CI10.

The cloud path does not require reading the low-level collection first. When a cloud abstraction needs host detail, use LL2 for CPU scheduling and NUMA, LL4 for persistence, LL5 for packet paths, LL6 for container isolation and resource enforcement, and LL7 for host evidence.

Sandbox systems applies CI2–6 and CI9–15 to isolated computers for agents and untrusted code. It continues from Kubernetes objects into sandbox claims, warm pools, gVisor and microVMs, checkpoint storage, credential brokering, and platform selection.

Useful background#

Notes

  1. AWS foundations: accounts, networks, compute, and service boundaries Build an AWS resource map, then follow synchronous and asynchronous application paths through networking, compute, identity, storage, and operations.
  2. Containers and the Kubernetes object model Connect processes and images to clusters, Pods, Deployments, Services, configuration, storage, and replaceable workload instances.
  3. Control planes, etcd, and reconciliation Follow a Kubernetes API mutation through etcd, watches, controllers, scheduling, and node reconciliation, then operate the storage boundary under churn and failure.
  4. Kubernetes networking, storage, and security Trace packets through Services and gateways, bind durable volumes with CSI, and layer workload security controls.
  5. Scheduling, autoscaling, and noisy neighbors Follow the scheduler queue and serialized placement cycle, calculate node-evaluation work, and connect binding, requests, cgroups, autoscaling, and contention.
  6. EKS and ECS without false equivalence Compare the two AWS container control planes by API, ownership, compute, extension points, and operating cost.
  7. Kafka as a replicated event log Start with Kafka vocabulary, then follow one record through partitioning, replication, consumption, replay, and failure.
  8. Celery task processing under failure Design background tasks around brokers, acknowledgements, retries, visibility, prefetch, idempotency, and poison work.
  9. Infrastructure as code and GitOps Trace Terraform ownership and state recovery, then promote one immutable artifact through GitOps and controller evidence.
  10. Production operation: reliability, observability, and capacity Define service evidence, tune autoscaling, plan capacity and recovery, and review a production system in a fixed order.
  11. Shared production services: queues, pools, and durable workflows Define supported platform contracts, choose asynchronous delivery semantics, bound PostgreSQL connections, and recover durable work.
  12. Internet edge and private connectivity Trace public and private connections through DNS, IP routing, VPC controls, transport security, load balancing, caching, edge protection, and hybrid links.
  13. AWS identity, secrets, encryption, and security evidence Follow an AWS request from temporary credentials through every policy layer, then connect workload identity, KMS, secret rotation, network controls, audit records, and incident response.
  14. AWS storage, backups, and disaster recovery Choose object, block, file, and managed database storage by interface and failure boundary, then design recoverable copies with measured RPO and RTO.
  15. Observability pipelines for metrics, logs, and traces Follow telemetry from instrumentation through collection, buffering, storage, query, rules, alerts, failure, and recovery.