AWS Stack

A region is a geographic location (us-east-1, eu-west-2); an availability zone is one or more discrete data centres within it, isolated in power and networking but connected by low-latency links.

This is the first architectural decision and it is hard to reverse. Region choice drives latency, price, data residency, and which services are even available. Spreading across AZs is how you survive a data-centre failure; spreading across regions is how you survive a regional one, and costs considerably more to do properly.

IAM governs who can do what to which resource. Policies are JSON documents attached to users, groups, or roles, and a role — an identity a service or user temporarily assumes — is the mechanism that lets workloads authenticate without stored credentials.

Two habits prevent most incidents. Grant least privilege and widen only when something breaks, rather than starting with * and intending to tighten later. And use roles instead of long-lived access keys wherever possible — the credential that cannot leak is the one that was never issued.

A VPC is your private network inside AWS: subnets split by availability zone, route tables directing traffic, security groups acting as stateful per-resource firewalls, and NACLs as stateless subnet-level rules.

The pattern worth internalising is public and private subnets. Load balancers sit in public subnets with internet routes; databases and application servers sit in private ones and reach out through a NAT gateway. Nothing that holds data should be directly reachable from the internet, and the VPC is where that is enforced structurally rather than by configuration on each host.

AWS's own design framework, organised around six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. It comes with a structured review process for auditing a workload against each.

Treat it as a checklist rather than doctrine. Its practical value is surfacing the questions teams skip — what happens when this AZ fails, who is paged, what does this cost per request — early enough that the answers are still cheap to act on.

A container packages an application together with its dependencies, libraries, and runtime into an image that behaves the same wherever it runs. Unlike a virtual machine it shares the host kernel rather than booting its own, which is why it starts in seconds and measures in megabytes rather than gigabytes.

On AWS this is the common currency of deployment: ECS, Fargate, EKS, Batch, SageMaker, and even Lambda all accept container images, so the same artefact moves between them. For ML work specifically it is the only reliable answer to CUDA, driver, and dependency drift — "works on my laptop" stops being a category of bug once the laptop and the GPU cluster run the same image.

The caveat worth holding: kernel sharing means isolation is weaker than a VM's. For multi-tenant or untrusted code, a container boundary alone is not a security boundary.

Docker is the tooling that builds and runs containers. A Dockerfile declares the build step by step, each instruction producing a cached layer, and the resulting image is what you ship. ECR is AWS's private registry — where those images live, with IAM controlling who can pull them, vulnerability scanning on push, and lifecycle policies to expire old ones.

Three habits separate a workable image from a painful one. Use multi-stage builds so compilers and build dependencies stay out of the final image — the difference is routinely gigabytes. Order instructions so the slowest-changing layers come first, since a change invalidates every layer after it and turns a ten-second rebuild into ten minutes. And pin base images by digest or explicit version, because :latest means your build is not reproducible and today's working image may not be tomorrow's.

On the AWS side, set an ECR lifecycle policy early. Untagged images accumulate silently from every CI run, and nobody notices until the storage line on the bill does something surprising.

Virtual machines you rent by the second, in instance families tuned for different profiles — compute-optimised, memory-optimised, GPU-accelerated, storage-optimised. It is the most general and most manual compute option.

Pricing model matters more than instance choice for cost. On-demand is flexible and expensive; reserved instances and savings plans cut it substantially for predictable load; spot instances run at a large discount but can be reclaimed with two minutes' notice — which is fine for fault-tolerant training jobs and unacceptable for a database.

Run a function in response to an event with no server to provision. It scales from zero to thousands of concurrent executions automatically and bills only for execution time.

The constraints define where it fits: a maximum execution duration, limited memory and ephemeral storage, and cold starts when a new environment initialises. Excellent for event handlers, glue between services, and bursty low-latency work — a poor fit for long-running training or anything needing a GPU.

ECS is AWS's container orchestrator. With the EC2 launch type you manage the underlying instances; with Fargate you do not — you declare CPU and memory per task and AWS provisions the capacity.

Fargate is usually the right default for containerised services: no cluster to patch or scale, at a premium per unit of compute. Choose EC2-backed ECS when you need GPUs, specific instance types, or high enough steady utilisation that managing capacity pays for itself.

Managed Kubernetes. AWS runs the control plane; you run workloads with standard Kubernetes manifests, tooling, and ecosystem.

The honest trade is portability and ecosystem against operational weight. Choose EKS when you already have Kubernetes expertise, need its ecosystem (Kubeflow, Argo, service meshes), or want workloads that could move to another cloud. If you have neither the expertise nor the requirement, ECS with Fargate does the same job with far less to learn.

Object storage addressed by key within buckets — effectively unlimited capacity, very high durability, and the substrate under most data lakes. It stores objects, not a filesystem: there are no real directories, and you cannot append to an object in place.

Storage classes and lifecycle rules are where the cost control lives, moving cold data to cheaper tiers automatically. The other thing to get right is access: public buckets remain among the most common causes of data exposure, and Block Public Access should stay on unless you have a deliberate reason.

EBS is a block volume attached to a single EC2 instance — effectively its disk, with configurable IOPS and throughput. EFS is a managed NFS filesystem that many instances can mount simultaneously.

The choice is about sharing. One instance needing a fast local disk wants EBS; a fleet needing the same files — a shared dataset across training nodes, for example — wants EFS, at higher cost per gigabyte and higher latency.

Managed relational databases — PostgreSQL, MySQL, and others — with backups, patching, replicas, and failover handled for you. Aurora is AWS's own engine, wire-compatible with PostgreSQL and MySQL, with storage that scales automatically.

Managed does not mean unmanaged: you still own schema design, indexing, connection pooling, and query performance. The failure mode people hit first is connection exhaustion — a serverless function scaling to hundreds of concurrent executions will open hundreds of database connections unless something like RDS Proxy sits in between.

A managed key-value and document store offering single-digit millisecond reads at effectively unbounded scale, with no servers to size and no query planner to fight.

The catch is that access patterns must be designed in from the start, through the partition and sort key. Unlike SQL, you cannot bolt on a new query shape later without a secondary index or a migration — DynamoDB rewards knowing your queries in advance and punishes exploratory workloads.

A columnar data warehouse for analytical queries over large volumes — aggregations across billions of rows rather than single-row lookups. Column storage means a query touching three columns reads only those three.

Distribution and sort keys determine whether it performs. A poorly distributed table forces data across nodes on every join, and the same query can run orders of magnitude slower than a well-modelled equivalent.

Managed ETL built on Spark, plus a Data Catalog that acts as a central metadata store — table definitions and schemas that Athena, Redshift Spectrum, and EMR all read from.

The catalog is frequently the more valuable half. It is what lets several engines query the same S3 data as tables without each maintaining its own view of what those tables are.

Managed clusters for Spark, Hadoop, Presto, and friends. AWS handles provisioning and configuration; you submit jobs against data in S3.

It suits heavy distributed processing that outgrows a single machine — large joins, feature pipelines over terabytes, model training on Spark. Transient clusters that spin up for a job and terminate afterwards, especially on spot capacity, are usually the economical pattern.

Serverless SQL directly over data in S3, using the Glue catalog for schema. No cluster, no loading step — point it at a prefix and query.

Billing is per byte scanned, which makes storage layout a cost decision rather than only a performance one. Partitioning and columnar formats like Parquet routinely cut both time and cost by an order of magnitude versus raw CSV, because the engine can skip everything irrelevant.

A managed queue that decouples producers from consumers. Standard queues offer high throughput with at-least-once delivery and no ordering guarantee; FIFO queues preserve order within a message group and deduplicate.

Because standard delivery is at-least-once, consumers must be idempotent — the same message will eventually arrive twice. Pair every queue with a dead-letter queue so poison messages stop blocking the pipeline and become visible instead.

Publish/subscribe messaging: publish once to a topic and every subscriber receives a copy — queues, Lambda functions, HTTP endpoints, email.

The distinction from SQS is fan-out versus work distribution. SNS delivers the same message to all subscribers; SQS delivers each message to one consumer. The common pattern combines them — SNS topic fanning out into several SQS queues, so each downstream system gets its own durable buffer.

An event bus that routes events to targets based on content-matching rules, with built-in sources from AWS services and SaaS providers, plus a schema registry.

Where SNS routes by topic, EventBridge routes by what is inside the event — allowing a single bus with rules like "orders over $1000 from EU customers go here". It is the natural backbone for event-driven architectures, and its scheduler also replaces cron for triggering periodic work.

A managed state machine for coordinating multi-step workflows. You declare states, transitions, retries, error handling, and parallelism; AWS executes and tracks each run.

Its value is that orchestration logic stops living in a Lambda function that calls other Lambda functions. Retries and failure paths become declarative and visible, and a failed run shows exactly which step broke and with what input — which is the difference between debugging a distributed workflow in minutes and in hours.

The end-to-end ML platform: managed notebooks, training jobs on ephemeral instances, hyperparameter tuning, a model registry, pipelines, and autoscaling inference endpoints.

The strongest argument for it is training economics — a training job provisions instances, runs, and tears them down, so you pay only for the run rather than for an idle GPU box. The cost is platform coupling: SageMaker-specific pipelines and endpoints do not port elsewhere without rework.

Managed access to foundation models from several providers behind one API, with no infrastructure to run, plus supporting pieces for retrieval, agents, and guardrails.

The practical benefit is that the interface is shared: switching or A/B-testing models becomes a configuration change rather than an integration project. It also keeps inference traffic inside your AWS account and IAM boundary, which is often what makes it viable where a third-party API is not.

KMS manages encryption keys and performs cryptographic operations, integrating with most services so encryption at rest is a configuration flag. Secrets Manager stores credentials and can rotate them automatically.

Together they remove the two habits that cause credential incidents: keys handled by application code, and passwords living in environment variables or committed files. Retrieving a secret at runtime through an IAM role means there is no secret in the repository to leak.

Metrics, logs, traces, dashboards, and alarms across AWS services and your own applications. Alarms trigger notifications or automated actions such as scaling.

Default metrics tell you about infrastructure; custom metrics tell you about your product, and those are the ones worth alerting on. CPU utilisation rarely explains a bad user experience — p99 latency, error rate, and queue depth do. Log retention is also worth setting deliberately, since the default of "forever" becomes a meaningful line on the bill.

Infrastructure as code. CloudFormation declares resources in YAML or JSON templates; the CDK lets you define the same infrastructure in a real programming language and synthesises the template for you.

The reason to bother is reproducibility and review. Infrastructure created by clicking through the console exists only in that account and in someone's memory; infrastructure in code can be diffed, reviewed, versioned, and recreated in a second region. Terraform solves the same problem across clouds and is often the better choice in a multi-cloud estate.

An Application Load Balancer distributes traffic across healthy targets and removes failing ones; Auto Scaling adjusts capacity in response to demand or a schedule.

Together they deliver both elasticity and fault tolerance, but only if health checks are meaningful. A check that confirms the process is listening will happily keep routing traffic to an instance whose database connection died. Health checks should exercise the path that actually matters, or they provide false confidence rather than protection.