aws-core-services▌

virtual private cloud — an isolated network inside AWS, and the foundation everything else in this session sits on.

CIDR & subnets

A VPC is defined by a CIDR block — a private IP range, typically something like 10.0.0.0/16 (65,536 addresses). Subnets carve that range into smaller, AZ-specific pieces — /24 is a common subnet size (256 addresses). AWS reserves 5 addresses in every subnet — the network address, the VPC router, DNS, one held for future use, and the broadcast-equivalent address — so a /24 only has 251 usable, not 256.

What makes a subnet "public"

Nothing about a subnet is inherently public or private — it's entirely defined by its route table. A public subnet's route table has 0.0.0.0/0 → an Internet Gateway. A private subnet's route table has no such route — if it needs outbound internet access at all, to pull OS updates or pip packages, that goes through a NAT Gateway instead.

Internet gateway vs NAT gateway

An Internet Gateway is horizontally scaled and redundant, and enables two-way traffic — instances with a public IP can be reached from the internet, and can reach out. A NAT Gateway is one-way only: it lets instances in a private subnet initiate outbound connections, but nothing from the internet can reach in through it. It sits in a public subnet itself, and the private subnet's route table points 0.0.0.0/0 at it.

Transit gateway

VPC Peering connects exactly two VPCs, and doesn't route transitively — if A is peered with B, and B with C, A still can't reach C through B. A Transit Gateway is a hub: every VPC — and, via a Direct Connect Gateway attachment, your on-prem network — attaches to it once, and the TGW routes between all of them. Past a handful of VPCs, or in a hybrid setup, TGW beats a peering mesh on both simplicity and scalability.

Security Groups and NACLs — instance-level vs subnet-level, stateful vs stateless — are covered in Session 3, alongside the EC2 networking scenario.

Hybrid connectivity — on-prem to AWS

Two ways to connect an on-prem GPU cluster to a VPC: a Site-to-Site VPN — an IPSec tunnel over the public internet, cheap and quick to set up, but sharing internet bandwidth with less predictable latency; or AWS Direct Connect — a dedicated physical connection, consistent low latency and guaranteed throughput, at higher cost and longer lead time to provision. Pairing Direct Connect with a Transit Gateway, via a Direct Connect Gateway, lets that one physical connection reach multiple VPCs instead of just one.

elastic compute — and specifically, everything that makes a GPU fleet fast to scale.

Instance families, briefly

The letter in an instance type names its optimization — M (general purpose), C (compute), R (memory), I/D (storage), P and G (GPU). For this role specifically: P-family (P3/P4/P5) is built for training — multiple high-memory GPUs with fast interconnect between them. G-family (G4/G5) leans toward inference and graphics workloads, generally cheaper per GPU.

AMI

An Amazon Machine Image is the template a new instance launches from — the OS, a snapshot of the root volume, launch permissions, and a block device mapping, bundled together. A custom AMI lets you bake in dependencies ahead of time — CUDA drivers, the ML framework, monitoring agents — so a new instance is ready to work the moment it boots, instead of needing a multi-minute bootstrap script to catch up.

Instance metadata service (IMDS)

Every instance can query 169.254.169.254 for its own metadata — instance ID, IAM role credentials, user-data, and more — without any external network path, since that address never leaves the instance. IMDSv1 answers a plain GET request; IMDSv2 requires first exchanging a PUT request for a session token, then including that token on every metadata request after.

EBS vs instance store

EBS is network-attached block storage — persistent, survives a stop unless explicitly configured otherwise, and is what you want for anything that needs to outlive the instance. Instance store is physically attached to the host — faster, but ephemeral: gone on stop or termination. For GPU work specifically, instance store is a reasonable choice for scratch space or intermediate shuffle/cache data during a training run that doesn't need to survive the instance, when speed matters more than durability.

Placement groups

A cluster placement group packs instances close together on the underlying hardware for low-latency, high-throughput networking between them — directly relevant to multi-node distributed training, where interconnect speed between GPU nodes (NCCL all-reduce traffic, for example) can matter as much as the GPUs themselves.

managed relational vs managed NoSQL — and specifically, when a fraud pipeline actually wants each one.

RDS — engine types

RDS is managed relational database hosting — you pick an engine: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, or Aurora, AWS's own MySQL- and PostgreSQL-compatible engine, built for higher throughput and availability than stock MySQL/Postgres on comparable hardware. AWS handles patching, backups, and failover; you still design the schema and write the queries.

Multi-AZ vs read replicas

Multi-AZ keeps a synchronous standby in a different Availability Zone purely for availability — if the primary fails, RDS fails over to the standby automatically. It doesn't help read performance; the standby isn't queryable. Read Replicas are the read-scaling tool — asynchronous copies, same region or cross-region, that you can direct read traffic to, accepting some replication lag in exchange for horizontal read capacity.

DynamoDB

DynamoDB is managed key-value/document NoSQL — every item lives in a table identified by a partition key, and optionally a sort key for range queries within a partition. Capacity is either on-demand (pay per request, scales automatically) or provisioned (set read/write capacity ahead of time, cheaper at steady, predictable load). What you get in exchange for a much simpler query model than SQL: single-digit-millisecond latency, essentially unlimited horizontal scale, and no server or engine to patch.

Which one, when

object storage — buckets and keys, not files and folders, even though the console likes to pretend otherwise.

Storage classes

Versioning & lifecycle policies

Versioning keeps every version of an object instead of overwriting it — protects against an accidental overwrite or delete being permanent. Lifecycle policies automate the boring but important part: transition objects to a cheaper storage class after N days, or expire them entirely, without anyone remembering to do it manually.

Encryption

SSE-S3 (AWS manages the keys entirely), SSE-KMS (AWS KMS-managed keys, with an audit trail and finer access control via key policies), SSE-C (you supply your own key per request; AWS never stores it). SSE-KMS is the common choice when you need to prove who could have decrypted what, for audit purposes.

Where S3 shows up in an ML pipeline

Raw datasets and processed feature sets, model artifacts and checkpoints — MLflow's artifact store is commonly backed by S3 — and often the source location a training job reads from directly, rather than copying data onto the instance first.

seven tasks, mostly doable on AWS free tier. Progress saves automatically.