| 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 |