| AWS Account | • billing + security boundary • all AWS resources built live inside one account • root user → every account contains root user with unrestricted access, locked down with MFA, not used day-to-day | | --- | --- | | AWS Organizations | • manage multiple accounts centrally • easy, centralized logging, security, and resource sharing • management account → manages all accounts • organizational unit (OU) → group all other accounts into OUs • offers consolidated billing • service control policy (SCP) → organization-wide guardrails ◦ wrap whole organization ◦ set absolute ceiling for every account in org including root | | Account Hierarchy | • AWS Organization → SCPs ◦ AWS Account → security + billing boundary ‣ IAM User/Role → identity policy + boundary ‣ AWS Resource → resource-based policy | | IAM Identity | • distinct AWS object that can be authenticated + assigned permissions • 3 types → Users, Groups, and Roles | | IAM User | • credentials → long-term via password + access keys • represents → specific person or app • avoid using for workloads, use roles instead • implement with MFA + least privilege, do not make root user | | IAM Group | • group of users → apply policies to multiple users at once • cannot be principal in trust-based or resource-based policy • cannot be nested inside other groups | | IAM Role | • credentials → temporary access token issued via Secure Token Service (STS) • represents → a trusted entity, IAM user, AWS service, federated identity, another AWS account • 2 parts: ◦ trust policy → who can assume it ◦ permission policies → what it can do • standard method for cross-account or service access and privilege isolation without sharing long-term credentials | | IAM Identity Federation | • configured inside IAM • lets external users (ex. Azure Active Directory, Google Workspace) access AWS using temporary credentials • avoids permanent IAM user keys | | Policy Structure | • policies take effect once they are attached to an identity or resource • JSON doc with fields: ◦ effect → allow or deny ◦ action → API operation ◦ resource → ARN(s) the actions apply to ◦ condition → optional logic, ex. require MFA, restrict IP range ◦ principal → who the policy applies to (only in resource-based and trust policies) | | Policy Types | • Identity-Based Policy → attached to IAM users/groups/roles ◦ AWS Managed Policy → created by AWS, standard roles (ex. AdministratorAccess) ◦ Customer Managed Policy → created by customer, custom team permissions ◦ In-line Policy → attached to one specific identity, hard stopping permission inheritance + edge cases • Resource-Based Policy → attached directly to resource (ex. S3 bucket, SQS queue, SNS topic, KMS key, Lambda function) ◦ specifies Principal → allows cross-account access without caller assuming a role ◦ Trust-Based Policy → attached to IAM role, grants permission to assume role ◦ Bucket Policy → attached directly to S3 bucket • Permission Boundary → attached to IAM identity ◦ sets max permissions ceiling that identity’s identity-based policies can grant • Service Control Policy (SCP) → attached to org root, OU, or account ◦ sets max permissions ceiling for everything in scope • Resource Control Policy (RCP) → attached to org root, OU, or account ◦ sets max permissions ceiling on what resource-based policies in scope can grant • Session Policy → passed as parameter when assuming role via STS ◦ restricts permissions of temporary session • Access Control List (ACL) → attached to specific resources (ex. S3 buckets + objects, VPC subnets → network ACLs (NACLs)) ◦ legacy permission mechanism ◦ does not use JSON policy format | | explicit Allow vs. Deny | • an action is allowed only if there’s an explicit Allow from every application layer ◦ ex. SCP/RCP, permission boundary, identity-based policy, resource-based policy, session policy if relevant • and there’s no explicit Deny anywhere ◦ explicit Deny in any single layer overrides every Allow | | Permission Boundary | • special policy attached to IAM identity that sets ceiling on permissions for all identity-based policies the identity has • only denies, does not grant anything itself • classic delegation pattern: let a team create their own IAM roles, but cap those roles with a boundary so they can never escalate beyond a defined set of services. | | AWS Shared Responsibility Model | • AWS responsibilities → security of cloud ◦ global infrastructure → regions, availability zones, edge locations ◦ physical infrastructure → hardware, networking, facilities ◦ host operating system → virtualization layer underneath managed services ‣ OS + DB engine patching • customer responsibilities → security in cloud ◦ customer always owns IAM/access management, data, client + app side config ◦ infrastructure services (ex. EC2, EBS) ‣ guest OS → patching + config ‣ firewall rules → security groups, NACLs ‣ IAM ‣ data → rest + transit ◦ managed + container services (ex. RDS, ElastiCache, EMR) ‣ IAM access control ‣ network config ‣ enabling data encryption ◦ abstract + serverless services (ex. S3, DynamoDB, Lambda) ‣ IAM, data classification ‣ client-side config → bucket policies, encryption settings | | AWS Well-Architected Framework (6 Pillars) | • Operational Success → continuously run + improve systems ◦ make small, frequent, reversible changes • Security → protect data + infrastructure ◦ strong identity foundation + least privilege ◦ defense in depth across all layers ◦ enable traceability with logging + monitoring ◦ automate security responses ◦ protect data at rest + in transit • Reliability → recover from failure + meet demand on systems ◦ automatically recover from failure ◦ test recovery procedures ◦ scale horizontally before vertically ◦ use auto scaling instead of guessing capacity ◦ manage change through automation • Performance Efficiency → use resources efficiently as demand + tech changes ◦ use serverless + managed services to offload undifferentiated work ◦ go global quickly with replicated infrastructure ◦ experiment often ◦ match tool to workload • Cost Optimization → avoid unnecessary spending ◦ adopt consumption-based models ◦ measure + attribute costs ◦ stop spending on undifferentiated heavy loads ◦ consider right-size + appropriate pricing models (ex. on-demand, reserved, spot, savings plans) • Sustainability → minimize environmental impact ◦ maximize utilization of provisioned resources before allocating more ◦ use managed services (AWS optimizes hardware efficiency) ◦ adopt newer more efficient instance types + services ◦ reduce idle + over-provisioned capacity | | trade-off-awareness | “given these constraints, which pillar are you optimizing for and what are you giving up?” | | Amazon Resource Name (ARN) | • resource → any provisioned tool in AWS • ARN → unique identifier for any resource in AWS • used to track, permission, automate any resource • syntax: ◦ arn:partition:service:region:account-id:resource-id | | AWS Prefix | • used to organize data or names hierarchically • acts like virtual folders • S3/Data Storage Prefix ◦ file name: s3://my-bucket/logs/2026/june/file.txt ◦ prefix: logs/2026/june/ • IAM/Resource Prefix ◦ used when naming resources to organize them in security policies ◦ ex. giving dev team access to any S3 bucket named “dev-” | | System Architecture Tiers/Layers | • Presentation Layer → frontend/client ◦ user interface, content delivery, client-side interactions ◦ handles delivering static assets + routing user traffic globally ◦ caches web assets close to users to reduce latency ◦ ex. CloudFront (CDN), S3 (Static Web Hosting) • Edge + Networking Layer → ingress ◦ secures incoming traffic, manages domain name routing, entry gateway to internal infrastructure ◦ filters malicious requests + balances web traffic across backend compute resources ◦ ex. Route 53 (DNS), Shield (DDoS + firewall), ELB, VPC • API + Orchestration Layer → integration ◦ acts as router, translator, orchestrator for microservices + decoupled application parts ◦ authorizes requests, manages API rate limiting, sequences complex workflows ◦ ex. API gateway, Step Functions, EventBridge • Application + Compute Layer → business logic ◦ differentiated workload ◦ handles business logic, user input, software mechanics ◦ processes client data, runs backend, interacts with storage systems ◦ ex. Lambda, ECS, EC2 • Data + Storage Layer → persistence ◦ securely store structured app data, unstructured files, cached queries, operational records ◦ evaluates data transactions. optimizes read/write speeds, ensures data durability ◦ ex. RDS, DynamoDB, S3, ElastiCache • Security + Management + Operations Layer → cross-cutting ◦ wraps around all other layershorizontally, not sequential ◦ provides unified identity access, compliance, logging, monitoring ◦ enforces principle of least privilege + provides full observability across system ◦ ex. IAM, Secrets Manager, CloudWatch, CloudTrail | | Differentiated vs. Undiffierentiated Workloads | • undifferentiated heavy lifting ◦ mandatory, repetitive, time-consuming infrastructure work required to keep systems running ◦ adds 0 unique value to customers • differentiated workloads ◦ unique business logic, custom software engineering, customer-facing feature development ◦ separates business from competitors | | Decoupled Application Parts + microservices | • decoupling → break tightly-linked components apart so they scale + fail independently • tightly coupled (synchronous) → caller waits for a direct response; one failure cascades downstream • loosely coupled (asynchronous) → components talk through an intermediary (queue/topic); no direct dependency • microservices → app split into small independent services, each owning one capability, deployed + scaled separately • decoupling tools: ◦ SQS → queue, point-to-point, pull-based, buffers work between producer + consumer ◦ SNS → pub/sub, push-based, fan-out one message to many subscribers ◦ EventBridge → event bus, routes events to targets by rules ◦ API Gateway → managed front door for APIs ◦ Step Functions → orchestrates multi-step workflows • exam cues → "absorb spikes / process at own pace / buffer" = SQS; "notify multiple / fan-out" = SNS | | Step Functions, EventBridge | • Step Functions → serverless workflow orchestration ◦ coordinates multiple AWS services into a state machine (defined sequence of steps) ◦ built-in retries, error handling, parallel branches, wait states, human-approval steps ◦ Standard workflows → long-running (≤ 1 yr), exactly-once, auditable ◦ Express workflows → high-volume, short (≤ 5 min), at-least-once ◦ use for → order processing, ETL pipelines, ML workflows • EventBridge → serverless event bus ◦ routes events from AWS services, SaaS apps, + custom apps to targets via rules (pattern matching) ◦ schema registry + event filtering ◦ scheduled rules (cron) → replaces legacy CloudWatch Events ◦ use for → event-driven architectures, decoupling producers from consumers • exam contrast → Step Functions = orchestration (you define the order); EventBridge = choreography (components react to events) | | Identity vs. Resource Policies | • S3 Buckets ◦ support resource-based policies that allow cross-account access without requiring the external principal to assume a role, grants access directly to principals in other accounts • EC2 Instances + Auto Scaling Groups (ASGs) → do not support resource-based policies • IAM Groups/Users/Roles → cannot be used as principals for resource-based policies |

| Instance Profile | • AWS oncifg container that holds exactly 1 IAM role • allows you to pass role to an EC2 instance - allowing servers to use roles | | --- | --- | | Workload Profiles | • the resource-demand pattern of an application → used to pick the right EC2 instance family (right-sizing) • compute-bound → high CPU (batch, HPC, gaming, ML inference) → C family • memory-bound → large in-memory datasets (caches, in-memory DBs, SAP HANA) → R / X family • balanced → web servers, small DBs, dev/test → M / T family • accelerated / GPU → ML training, rendering, video encoding → P / G / Inf family • storage-bound → high local IOPS (NoSQL, data warehousing, log processing) → I / D / H family • matching family to profile is both a performance and cost optimization | | EC2 Instance Family + Type | • family → category of instances optimized for workload profile • type → specific size within family, grouped into families ◦ determines hardware of host computer used for instance ◦ varying combinations of CPU, memory, storage, and networking capacity • ex. m5.large — family m, generation 5, size large • feature modifiers → a = AMD, g = Graviton/ARM, n = enhanced networking, d = NVMe instance store, i = Intel | | NVMe | • non-volatile memory (NVM) → storage flash memory retails all its saved data when server is powered off • express (e) → data traveling over PCI express - direct ultra fast straight to CPU | | EC2 Instance Families | • General Purpose (m, t) ◦ balanced CPU/memory/network ◦ t-family → accrues CPU credits when idle + burns during bursts, best for unpredictable workloads ◦ ex. web servers, small DBs, dev envs ◦ ex. m6i, t3 • Compute Optimized (c) ◦ CPU-intensive ◦ ex. batch, HPC, gaming servers, ML inference ◦ ex. c6i, c5 • Memory Optimized (r, x, z1d) ◦ large in-memory datasets, RAM ◦ ex. in-memory DBs, real-time analytics, SAP HANA (systems, applications, and products: high-performance analytic appliance) ◦ ex. r6i, x2idn • Accelerated Computing (p, g, inf) ◦ GPU workloads ◦ ex. ML training, graphics rendering, video encoding ◦ ex. p4, g5, inf2 • Storage Optimized (i, d, h) ◦ high sequential read/write to local NVMe (non-volatile memory express), noSQL DBs, distributed file systems, log processing ◦ local disk IOPS (input/output operations per second) ◦ ex. data warehousing, hadoop, OLTP (online transaction processing) • High-Performance Computing Optimized (hpc) ◦ requires low-latency networking ◦ ex. hpc6a | | EC2 Purchasing Options | • On-Demand ◦ no commitment ◦ 0% discount vs. on-demand ◦ short-term, unpredictable workloads, cannot be interrupted • Reserved Instance (RI) ◦ 1 or 3 yr + family + region commitment ◦ ≤ 72% discount vs. on-demand ◦ steady-state workloads, predictable usage ◦ Standard RIs → cheaper, inflexible ◦ Convertible RIs → allow family/OS changes ◦ Scheduled RIs → depreciated, recurring time windows • Saving Plans (compute, EC2 instance, SageMaker) ◦ 1 or 3 yrs $/hr commitment ◦ ≤ 72% discount vs. on-demand ◦ more flexible than RIs ◦ cover EC2, Fargate, Lambda across any region + family • Spot ◦ no commitment, AWS can reclaim within 2 min warning ◦ ≤ 90% discount vs. on-demand ◦ fault-tolerant, stateless, batch workloads ◦ never for stateful, interruption-sensitive workloads • Dedicated Instance ◦ pay per instance on dedicated hardware ◦ premium ◦ compliance requires physical isolation, but not socket/visibility control • Dedicated Host ◦ pay for whole physical server ◦ premium ◦ bring-your-own-license (windows server, sql server, oracle) ◦ needs socket/core visibility + strict compliance • Capacity Reservations ◦ reserve capacity in specific availability zone ◦ no discount, still pay for on-demand instances ◦ use for known events - failover, launches ◦ can combine with Savings Plans + RIs for discount • Spot Fleet/EC2 Fleet → mix purchasing options + instance types to meet target capacity at lowest cost • Spot Black → legacy, fixed-duration spot | | EC2 Placement Groups | • control how instances are physically distributed within an availability zone or region to optimize network performance or fault tolerance • Cluster Groups → one rack, low latency ◦ lowest inter-node latency + highest throughput ◦ maximize blast radius ◦ ex. HPC, tightly coupled compute • Spread Groups → each distinct hardware ◦ guarantees each instance is on diff hardware ◦ limit 7 per availability zone ◦ ex. small number of critical instances • Partition Groups → isolated rack groups ◦ isolated rack groups ◦ ≤ 7 partitions per availability zone ◦ large clusters of instances ◦ failure isolation between partitions ◦ tolerates co-location within partition | | Amazon Machine Image (AMI) | • template containing OS, app server. apps, launch permissions, block device mapping — which EBS snapshots/instance store volumes to attach • region-scoped → copying AMI to another region creates new AMI with new ID • can share AMIs across accounts • make AMIs public/sell in Marketplace • encrypt underlying snapshots • EBS-Backed AMIs → boot from EBS snapshot + can be stopped/started • Instance Store-Backed AMIs → boot from S3-resident bundles + can only be terminated, no start/stop, take longer to launch • Golden AMIs → pre-baked with software, launch faster, heavier maintenance, automated with EC2 Image Builder | | Auto Scaling Groups (ASG) | • maintains fleet of EC2 instances using launch template • enforces min, max, + desired capacity • distributes instances across assigned availability zones + subnets • works with ELB to register/de-register instances • uses health checks (EC2 status checks, ELB target health) to replace unhealthy instances automatically • lifecycle hooks → pause instances in pending/terminating state to run setup/cleanup • warm pools → pre-initialized instances ready to launch faster • instance refresh → rolls instances to new launch template version • termination policies → decide which instance dies on scale-in ◦ default - balance across availability zones ◦ then targets oldest launch template/config ◦ then targets most redundant launch template/config • cooldown period → ASG waits after scaling before responding to additional alarms, default = 300s, prevents rapid repeated scaling actions (thrashing) | | Scaling Policies | • Manual ◦ desired capacity changes ◦ ex. ad-hoc adjustments • Scheduled ◦ cron-styled rules ◦ ex. known time-based traffic patterns • Simple Scaling ◦ CloudWatch alarm → add/remove # instances + wait for cooldown ◦ ex. simple workloads with stable patterns • Step Scaling ◦ CloudWatch alarm with multiple steps → add more instances as breach grows ◦ warmup settings override cooldown for scale-out ◦ ex. proportional response to changing load • Target Tracking ◦ pick target + metric → ASG calculates ◦ default recommendation → simplest to configure ◦ warmup settings override cooldown for scale-out • Predictive Scaling ◦ ML model forecasts load + scales ahead ◦ ex. predictable cyclical patterns, combined with target tracking | | Health Checks | • EC2 Health Check → default, marks instance unhealthy if EC2 Status Check fails • ELB Health Check → uses load balancer’s health check, more application-aware • unhealthy instance → ASG terminates + launches replacement | | Launch Templates vs. Configuration | • Launch Template → supports versioning, mixed instance types, spot + on-demand in one group, T2/T3 unlimited mode • Launch Config → legacy, does not support ^ features | | AWS Elastic Block Store (EBS) | • EBS volumes are AZ-specific — they can only attach to instances in the same AZ • Multi-Attach: io1/io2 volumes can attach to multiple instances simultaneously (up to 16), but only within the same AZ • By default, the root volume is deleted on instance termination; additional data volumes are retained • Snapshots are incremental and stored in S3; they can be copied across regions • EBS encryption uses KMS (key management system); encrypted volumes produce encrypted snapshots and vice versa | | EBS Volume Types | • gp3 ◦ SSD ◦ 16,000 IOPS ◦ 1,000 MB/s throughput ◦ general purpose - boot volumes, dev/test, most workloads • gp2 ◦ SSD ◦ 16,000 IOPS ◦ 250 MB/s throughput ◦ legacy general purpose ◦ IOPS tied to size → 3 IOPS/GB • io2 + io2 Block Express ◦ SSD ◦ 256,000 IOPS ◦ 4,000 MB/s ◦ mission-critical DBs requiring consistent sub-ms latency • io1 ◦ SSD ◦ 64,000 IOPS ◦ 1,000 MB/s ◦ high-performance DBs • st1 ◦ HDD ◦ 500 IOPS ◦ 500 MB/s ◦ through-put intensive sequential workloads, big data, log processing • sc1 ◦ HDD ◦ 250 IOPS ◦ 250 MD/s throughput ◦ cold data accessed infrequently, lowest cost HDD • gp3 vs. gp2 ◦ gp3 provides 3,000 IOPS and 125 MB/s baseline for any volume size — independent of size ◦ gp2 provides 3 IOPS per GB (minimum 100 IOPS), bursting to 3,000 IOPS via a credit bucket for volumes under 1 TB ◦ gp3 IOPS and throughput can be provisioned independently up to 16,000 IOPS / 1,000 MB/s — without increasing storage size ◦ gp3 is ~20% cheaper per GB than gp2 ◦ gp3 is the default and recommended choice for new volumes | | AWS Instance Store | • ephemeral block storage physically attached (NVMe SSD) to the host server • extremely high IOPS + throughput — faster than EBS for local workloads • data is lost on stop, hibernate, terminate, or hardware failure (survives reboot only) • cannot be detached/reattached; size + presence are fixed by the instance type • no snapshots, not durable • included in the instance price (no separate charge) • use for → caches, buffers, scratch/temp space, or data replicated elsewhere (Hadoop, Cassandra) | | EBS vs. Instance Store | • EBS ◦ network-attached ◦ persists independently of instance lifecycle ◦ can detach/reattach ◦ snapshots to S3 ◦ performs lower than instance store but predictable ◦ pay for provisioned size + IOPS ◦ use for most workloads, DBs needing durability ◦ data must survive reboots/termination • Instance Store ◦ physically attached to host ◦ data is lost on stop, hibernate, terminate, hardware failure ◦ cannot detach/reattach ◦ no snapshots ◦ performs with high IOPS + throughput ◦ NVMe SSDs on i3/i4i ◦ included in instance price ◦ use for temporary buffers, caches, distributed DBs with own replication ◦ workload needs highest possible IOPS + data is replicated/regenerable | | AWS Elastic Load Balancer (ELB) | • managed service that distributes incoming traffic across multiple targets (EC2, containers, IPs, Lambda) in one or more AZs • improves availability + fault tolerance → routes only to healthy targets via health checks • scales automatically with traffic, no pre-warming for most cases • regional → spans multiple AZs; enable cross-zone load balancing to spread evenly across all AZs • integrates with Auto Scaling → auto-registers/deregisters instances • listener → checks for connection requests on a configured protocol + port • target group → routes to registered targets, has its own health check • can be internet-facing or internal | | ELB Types | • Classic Load Balancer (CLB) → legacy, layer 4 + 7, EC2-Classic era — avoid for new builds • Application Load Balancer (ALB) → layer 7 (HTTP/HTTPS) ◦ content / path / host-based routing, microservices + containers, WebSocket, redirects, fixed responses ◦ targets → EC2, ECS, Lambda, IP ◦ use for → web apps + HTTP routing • Network Load Balancer (NLB) → layer 4 (TCP/UDP/TLS) ◦ ultra-low latency, millions of req/s, static / Elastic IP per AZ, preserves source IP ◦ use for → extreme performance, TCP/UDP, static IP requirements • Gateway Load Balancer (GWLB) → layer 3 ◦ deploy + scale third-party virtual appliances (firewalls, IDS/IPS, deep packet inspection) ◦ uses GENEVE protocol on port 6081 • exam → HTTP routing = ALB; static IP / extreme perf / TCP = NLB; third-party security appliances = GWLB | | EC2 Placement Groups | • Cluster → packs instances close together in one AZ → lowest latency + highest throughput; HPC / tightly coupled; larger blast radius • Spread → each instance on distinct hardware (≤ 7 per AZ) → small set of critical instances, isolates correlated failure • Partition → instances split into isolated rack groups (≤ 7 partitions per AZ) → large distributed workloads (Hadoop, Cassandra, Kafka); failure isolation between partitions | | Amazon Machine Image (AMI) | • template defining an EC2 instance → OS, app server, applications, launch permissions, block device mapping • region-scoped → copying to another region creates a new AMI ID • can be shared across accounts, made public, or sold in the Marketplace • sources → AWS-provided, Marketplace, community, or your own custom AMI • EBS-backed → root from EBS snapshot, supports stop/start • instance store-backed → root from S3 bundle, terminate only (no stop/start) • Golden AMI → pre-baked with config + software for fast, consistent launches (build with EC2 Image Builder) |

| Simple Storage Solution (S3) | • object storage → store + retrieve any amount of data, virtually unlimited • objects (data + metadata + key) live in buckets (globally unique name) • flat structure → "folders" are just key prefixes • 11 nines (99.999999999%) durability → replicated across ≥ 3 AZs (except One Zone-IA) • max object size 5 TB; single PUT ≤ 5 GB (use multipart above 100 MB) • strong read-after-write consistency for all operations • regional (bucket lives in one region) but the namespace is global • use for → backups, data lakes, static website hosting, content distribution, logs | | --- | --- | | S3 Classes | • Standard → frequent access, ≥ 3 AZ, lowest latency, default, no retrieval fee • Standard-IA → infrequent access, ≥ 3 AZ, lower storage cost + per-GB retrieval fee; 30-day + 128 KB min billing • One Zone-IA → infrequent, single AZ (less durable), ~20% cheaper than Standard-IA; re-creatable data • Intelligent-Tiering → auto-moves objects between tiers by access pattern, small monitoring fee, no retrieval fees; unknown/changing access • Glacier Instant Retrieval → archive with millisecond retrieval, cheaper than Standard-IA; accessed ~once a quarter • Glacier Flexible Retrieval → archive, minutes-to-hours ◦ tiers → expedited (1-5 min), standard (3-5 hr), bulk (5-12 hr) • Glacier Deep Archive → lowest cost, 12-48 hr retrieval; long-term / regulatory, accessed ~once a year • exam → choose by access frequency + retrieval-time tolerance + cost | | Bucket Policies | • resource-based policy (JSON) attached directly to a bucket • applies to the bucket + all objects in it • specifies Principal → can grant cross-account access without role assumption • common uses → grant public read, enforce HTTPS (aws:SecureTransport), restrict by IP / VPC endpoint, require encryption • evaluated together with IAM policies → explicit Deny always wins • best for bucket-wide rules (vs ACLs, which are object-level + legacy) | | Access Control Lists (ACLs) | • legacy access mechanism, predates IAM + bucket policies • grant coarse read/write on buckets or individual objects, per-grantee; not JSON • AWS now recommends disabling ACLs → set Object Ownership to "Bucket owner enforced" so IAM + bucket policies control everything • still relevant for → cross-account object-ownership edge cases, S3 server access log delivery • exam → prefer bucket policies + IAM over ACLs | | Block Public Access | • safety feature that prevents accidental public exposure • 4 settings → block public ACLs (new + existing) and block public bucket policies (new + existing) • can apply at the account level or bucket level • overrides any ACL or bucket policy that would otherwise grant public access • ON by default for new buckets • exam → if BPA is on, public-granting policies are ignored and access stays blocked | | Pre-signed URLs | • time-limited URL granting temporary access to a specific object (GET or PUT) • generated with the creator's credentials → inherits their permissions • recipient needs no AWS account or credentials • use for → private downloads, direct browser uploads, temporary sharing • expiration set at creation (up to 7 days with SigV4) • exam → "share a private object temporarily without making it public" = pre-signed URL | | S3 Access Points | • named network endpoints with their own access policy, attached to a bucket • simplify access for shared datasets → each app/team gets its own access point + policy instead of one giant bucket policy • each has a unique DNS name; can be restricted to a VPC (private) or internet • Multi-Region Access Points → single global endpoint routing to buckets in multiple regions (failover + latency routing) | | Versioning | • keeps multiple versions of an object in the same bucket (each PUT/delete gets a new version ID) • protects against accidental overwrite + delete • delete → adds a delete marker (recover by removing it); permanent delete needs the version ID • once enabled, can only be suspended, never fully disabled • required for CRR/SRR replication + MFA Delete • old versions still cost storage → use lifecycle rules to expire them • exam → "recover overwritten/deleted objects" = versioning | | Lifecycle Policies | • rules to automatically transition or expire objects for cost optimization • transition actions → move to cheaper classes after N days (Standard → Standard-IA → Glacier) • expiration actions → delete objects, old versions, or incomplete multipart uploads after N days • can scope by prefix or tag • minimums → Standard-IA / One Zone-IA require 30 days before transition • exam → "automatically archive/delete after X days to save cost" = lifecycle policy | | Replication | • async copy of objects to another bucket; versioning required on both source + destination • Cross-Region Replication (CRR) → different region → DR, lower latency for distant users, compliance • Same-Region Replication (SRR) → same region → log aggregation, prod/test sync, data residency • S3 Batch Replication → replicate existing objects (normal replication only covers new objects after enabling) • can replicate to a different account / storage class / KMS key • not transitive (A→B→C does not chain); one hop by default • Replication Time Control (RTC) → SLA-backed 15-minute replication | | S3 Encryption Options | • SSE-S3 → server-side, AWS-managed keys (AES-256), simplest, baseline default • SSE-KMS → server-side, AWS KMS keys → audit trail (CloudTrail), key rotation, access control; watch KMS API limits (use S3 Bucket Keys to cut cost/throttling) • SSE-C → server-side, customer-provided keys; you manage keys, AWS does the encryption, send key with each request over HTTPS • Client-Side Encryption → encrypt before upload; you fully control keys, AWS never sees plaintext • in transit → HTTPS/TLS; enforce with aws:SecureTransport condition • note → S3 now encrypts all new objects by default (SSE-S3 baseline) | | S3 Performance Features | • multipart upload → split large objects into parts, uploaded in parallel + retried individually; recommended > 100 MB, required > 5 GB • Transfer Acceleration → upload via CloudFront edge + AWS backbone for fast long-distance transfers • S3 Select → retrieve a subset of object data with SQL (CSV/JSON/Parquet) → less data transferred • byte-range fetches → parallelize downloads or grab part of an object • prefix scaling → 3,500 PUT / 5,500 GET per second per prefix (spread keys across prefixes to scale) • event notifications → trigger Lambda / SQS / SNS on object events • object lock → WORM, prevents delete/overwrite (Governance vs Compliance mode) • strong consistency → read-after-write for all operations |

| Virtual Private Cloud (VPC) | • logically isolated virtual network inside an AWS region that you fully control • spans all AZs in its region; you define a CIDR block (IPv4 + optional IPv6) • private by default → resources can't reach the internet until you add an IGW/NAT + routes • building blocks → subnets, route tables, internet gateway, NAT, security groups, NACLs, endpoints • can connect to other VPCs (peering / TGW) + on-prem (VPN / Direct Connect) • CIDR /16 to /28; primary CIDR can't change after creation (can add secondary CIDRs) | | --- | --- | | CIDR Math | • CIDR notation → IP/prefix (e.g. 10.0.0.0/16); prefix = number of fixed network bits • total addresses = 2^(32 − prefix) ◦ /16 = 65,536 • /24 = 256 • /28 = 16 (smallest allowed) • AWS reserves 5 IPs per subnet → usable = total − 5 ◦ .0 network, .1 router, .2 DNS, .3 reserved, .255 broadcast • each +1 to the prefix halves the block (/24 → two /25s) • split a /16 into 4 = /18 each (add 2 bits); into 2 = /17 • subnet CIDRs must sit inside the VPC CIDR + must not overlap • exam → "need X usable IPs" → pick prefix where 2^(32−p) − 5 ≥ X | | Subnets | • a range of IPs within a VPC; each subnet lives in exactly one AZ (cannot span AZs) • public subnet → route table has a route to an Internet Gateway (0.0.0.0/0 → igw); can hold public IPs • private subnet → no direct route to an IGW; reaches internet outbound only via NAT • route table → rules directing subnet traffic; the main route table is default, custom ones can be associated per subnet • multi-AZ HA → create a subnet per AZ • AWS reserves 5 IPs per subnet | | Internet Gateway (IGW) | • horizontally scaled, redundant, highly available VPC component • enables two-way communication between VPC resources and the internet • one IGW per VPC → attach to the VPC + add route 0.0.0.0/0 → igw in the subnet's route table • performs NAT for instances that have public IPv4 addresses • a subnet is "public" only because its route table points to an IGW • no bandwidth limits + no charge for the gateway itself | | Network Access Translation (NAT) Gateway | • managed service letting private subnet instances initiate outbound internet (updates, API calls) while blocking inbound from the internet • lives in a public subnet, needs an Elastic IP; private route table points 0.0.0.0/0 → nat • AZ-specific → deploy one per AZ for HA (a NAT GW in a failed AZ takes its subnets offline) • managed, scales to 100 Gbps, no admin • NAT instance → legacy self-managed EC2 alternative; you patch/scale it + must disable source/dest check • billed per hour + per GB processed • exam → "private instances need outbound internet, no inbound" = NAT Gateway | | Network Access Control List (NACL) | • stateless firewall at the subnet level • stateless → return traffic must be explicitly allowed (inbound + outbound evaluated separately) → remember ephemeral ports • rules evaluated in number order, lowest first; first match wins then stops • supports both allow AND deny rules (unlike security groups) • default NACL allows all; a custom NACL denies all until you add rules • one NACL per subnet, but one NACL can cover many subnets • exam → subnet-wide rules / block a specific IP = NACL | | Security Group | • stateful firewall at the instance / ENI level • stateful → return traffic is auto-allowed regardless of outbound rules • allow rules only (no explicit deny); all rules evaluated, implicit deny otherwise • default → denies all inbound, allows all outbound • can reference other security groups (not just IP/CIDR) → clean tier-to-tier rules • multiple SGs per instance; changes apply immediately • exam → instance-level + stateful + allow-only = security group (contrast with stateless NACL) | | VPC Endpoints | • private connectivity to AWS services without internet / NAT / IGW → traffic stays on the AWS network • Gateway Endpoint → for S3 + DynamoDB only; a route-table target; free, no ENI • Interface Endpoint (AWS PrivateLink) → ENI with a private IP in your subnet; for most other services; hourly + data charges • improves security + can cut NAT data-processing cost • exam → private S3/DynamoDB access with no NAT = gateway endpoint; private access to other services = interface endpoint | | VPC Domain Name System (DNS) | • VPC provides DNS via the Amazon-provided resolver (Route 53 Resolver) at the VPC base +2 address • enableDnsSupport → instances can use the Amazon DNS server for resolution • enableDnsHostnames → instances with public IPs get public DNS hostnames • both must be on for public DNS hostnames to work • exam → instances can't resolve names / no public DNS name = check these two VPC attributes | | Route 53 Resolver | • the DNS resolver inside every VPC (the .2 resolver); handles hybrid DNS • inbound endpoint → lets on-prem resolve names in your VPC / Route 53 private zones (on-prem → AWS) • outbound endpoint → lets VPC resources resolve names in on-prem DNS (AWS → on-prem) • resolver rules → forward queries for specific domains to target DNS servers • use for → hybrid-cloud DNS between on-prem and AWS | | VPC peering | • private 1-to-1 network connection between two VPCs (same or different account/region) • traffic stays on the AWS private network, uses private IPs • not transitive → A↔B and B↔C does NOT give A↔C; need direct peering or a Transit Gateway • CIDR blocks must not overlap • must update route tables on both sides and security group rules • no single point of failure / no bandwidth bottleneck • exam → connect a few VPCs privately = peering; many VPCs / hub-spoke = Transit Gateway | | Transit Gateway (TGW) | • regional hub connecting many VPCs + on-prem (VPN / Direct Connect) through one gateway (hub-and-spoke) • solves the peering mesh problem → transitive routing between attachments • supports route tables for segmentation / isolation between attachments • cross-region peering between TGWs; scales to thousands of VPCs • exam → many VPCs / centralized connectivity / hybrid at scale = Transit Gateway | | Virtual Private Network (VPN) | • encrypted tunnel over the public internet between networks/users and AWS • two main types → Site-to-Site VPN (network-to-AWS) + Client VPN (user-to-AWS) • cheaper + faster to set up than Direct Connect, but rides the public internet (variable latency) • often used as a backup/failover for Direct Connect • exam → quick, encrypted hybrid connectivity over the internet = VPN | | site-to-site VPN | • IPsec tunnel connecting an on-prem network to a VPC over the internet • Virtual Private Gateway (VGW) → the AWS side of the VPN, attached to the VPC • Customer Gateway (CGW) → represents the on-prem device/router (its public IP) • VPN connection → the IPsec tunnels (two for redundancy) between CGW and VGW (or TGW) • supports static or dynamic (BGP) routing • exam → encrypted on-prem-to-AWS over internet, fast to deploy = Site-to-Site VPN | | aws client vpn | • managed remote-access VPN → individual users/devices connect securely to AWS (and on-prem) from anywhere • based on the OpenVPN protocol; uses an OpenVPN client • authentication → Active Directory, SAML federation, or mutual certificate auth • use for → remote workforce reaching VPC resources • contrast → Site-to-Site connects whole networks; Client VPN connects individual users | | aws direct connect | • dedicated private physical connection from on-prem to AWS (bypasses the public internet) • consistent low latency + high bandwidth, more secure than VPN • VPN vs DX → VPN = cheap/quick/internet; DX = dedicated/consistent/pricier + weeks to provision • dedicated connection (single customer, 1/10/100 Gbps) vs hosted (via partner, flexible bandwidth) • virtual interfaces (VIFs): ◦ private VIF → reach VPC resources (private IPs) ◦ public VIF → reach AWS public services (S3, DynamoDB) ◦ transit VIF → reach VPCs via Transit Gateway • Direct Connect Gateway → connect a DX to VPCs in multiple regions • not encrypted by default → run a VPN over DX for encryption • exam → consistent throughput / large data / hybrid not over internet = Direct Connect (add VPN if encryption needed) | | vpc flow logs | • capture metadata about IP traffic to/from network interfaces in a VPC • enable at VPC, subnet, or ENI level • log accepted / rejected / all traffic → publish to CloudWatch Logs, S3, or Kinesis Data Firehose • records src/dst IP + port, protocol, bytes, action (ACCEPT/REJECT) — not packet contents (no payload) • use for → troubleshooting connectivity (is an SG/NACL blocking?), security analysis, monitoring • exam → "why is traffic blocked / monitor traffic without packet capture" = VPC Flow Logs |