Amazon Web Services
Master AWS: cloud services, architecture patterns, cost optimization, and enterprise solutions.
What is Amazon Web Services?
Amazon Web Services (AWS) is a public cloud platform that exposes compute, storage, databases, networking, identity, security, analytics, and application infrastructure through APIs. Teams provision logical resources on shared physical infrastructure and pay for reserved capacity, measured use, data movement, or managed operations.
AWS matters because a team can assemble regional systems without building data centers. The trade-off is a large control surface: the customer still owns workload architecture, identity, data classification, configuration, dependency choices, recovery testing, and cost governance under the shared-responsibility model.
The core invariant is every workload resource, permission, data copy, and recovery path belongs to an explicit account, Region, failure boundary, and owner. A managed service changes who operates hardware; it does not remove the need to prove application correctness and recoverability.
Start with the account and identity boundary
1 Blast radius
Separate organizations and accounts
Use an organization with dedicated production, non-production, security, logging, and shared-service accounts so one credential or quota event cannot reach everything.
2 Identity
Federate human access
Use the enterprise identity provider, multi-factor authentication, short sessions, and auditable role assumption instead of shared IAM users.
3 Runtime
Issue workload roles
Give each service short-lived credentials scoped to the actions, resources, network paths, and conditions it actually requires.
4 Audit
Centralize evidence
Protect organization-level activity logs, configuration history, findings, and access evidence in a restricted account with retention controls.
Protect the control plane
- Keep root credentials offline, require phishing-resistant MFA, and alert on root use.
- Apply organization policies and permission boundaries as guardrails, not substitutes for least privilege.
- Deny public access by default and use explicit resource policies for cross-account sharing.
- Rotate or eliminate static keys; scan code, images, logs, and build output for credentials.
- Test emergency access and record every privileged session.
Map the global and regional failure hierarchy
Geographic boundary
Region
A Region contains multiple Availability Zones and its own regional services. Choose it for latency, regulation, service availability, and disaster-recovery scope.
Facility isolation
Availability Zone
An AZ is an independent infrastructure boundary connected to other zones by regional networking. Spread redundant capacity and data across zones.
User proximity
Edge location
Edge networks provide DNS, content delivery, security, and selected compute near users, but the origin and authoritative state still need a regional design.
Administrative boundary
Account and VPC
Accounts contain ownership and quotas; VPCs contain network routing and policy. Neither is automatically a failure-isolation guarantee for application state.
Multi-AZ is the normal regional availability pattern. Multi-region is a separate architecture requiring replicated state, global routing, independent capacity, dependency review, data-governance decisions, and tested failover and failback.
Size the workload after a failure
Peak demand, per-resource capacity, target utilization, zonal placement, and transfer topology determine whether a service remains healthy. Even distribution is not the same as reserve.
The model below uses relative planning units, not current AWS prices. Validate quotas, service behavior, Region availability, commitments, transfer rules, tax, and pricing with official AWS sources before purchasing.
Size capacity, failure headroom, and transfer pressure
This is a relative planning model, not a price quote. Change the workload and deployment assumptions to expose which resource or failure boundary controls the design.
Capacity verdict
Healthy capacity disappears with one Availability Zone
Distributing the current minimum across zones improves placement but does not create failure reserve. Lower utilization or add capacity.
33
11 instances per AZ
4%
420 modeled requests/s per node
1,600/s
Requests crossing an AZ boundary
3,856
Compute plus transfer pressure; not currency
Architecture path
Route
8,000/s
Regional demand and health checks
Balance
3 AZs
Even placement is not reserve capacity
Serve
33 nodes
60% target utilization
Transfer
6 TiB
Classify internet, cross-AZ, and service paths
Validate any real design with current AWS quotas, service behavior, region availability, commitments, data-transfer rules, and the official pricing calculator.
Build the envelope in this order
- Measure peak demand and a representative unit of work.
- Benchmark sustainable per-resource capacity at the target latency and error budget.
- Remove one failed AZ or the declared failure slice, then size the surviving fleet for peak demand.
- Include warm-up, autoscaling delay, connection limits, quotas, retries, and dependency saturation.
- Classify internet, cross-AZ, cross-region, NAT, and managed-service transfer paths.
Inject failures at the boundary you claim to survive
Loading failure lab
Preparing failure domains...
Keep four outcomes separate
- Availability: can a healthy target serve new requests now?
- Durability: which accepted writes remain recoverable after the incident?
- RPO: how much recent state can the business lose under the chosen replication mode?
- RTO: how long until routing, capacity, state, and dependencies restore the required service?
Select managed services from the contract
EC2, ECS, EKS, Lambda
Compute
Choose virtual machines, containers, or functions from runtime control, isolation, startup, scaling, networking, and operational ownership.
S3, EBS, EFS
Storage
Choose object, block, or file semantics from access pattern, durability, consistency, throughput, lifecycle, encryption, and recovery requirements.
RDS, DynamoDB, ElastiCache
Databases
Choose from transaction, query, key, latency, scaling, consistency, backup, and failover contracts rather than the label “managed database.”
VPC, ELB, Route 53, CloudFront
Networking
Model ingress, egress, private endpoints, name resolution, health checks, connection lifetime, address exhaustion, and policy boundaries.
SQS, SNS, EventBridge, MSK
Messaging
Choose queue, fan-out, event routing, or durable log semantics from ordering, replay, delivery, throughput, and consumer ownership.
IAM, KMS, CloudTrail, CloudWatch
Security and operations
Make identity, encryption, evidence, detection, telemetry, automation, and incident response part of the workload design.
Verify current regional support, quotas, limits, consistency, backup, maintenance, and pricing in official documentation before committing to any named service.
Design data ownership and recovery
Classify each dataset
- Authoritative transactional state, derived indexes, caches, logs, analytics, artifacts, and backups need different controls.
- Record data owner, classification, Region, encryption key, retention, legal hold, RPO, RTO, and deletion procedure.
- Keep backups logically separated from the workload credentials and test restore into an isolated environment.
- Validate application consistency after restore; a successful storage operation does not prove usable business state.
Make asynchronous replication visible
Cross-AZ and cross-region replicas can lag. During failover, define which writes are accepted, how conflicts are prevented or reconciled, how clients discover the new authority, and how the old authority safely rejoins.
Secure every data and network path
Identity
Use workload roles, scoped resource policies, session conditions, and service control guardrails; continuously analyze unused and external access.
Network
Minimize public endpoints, control egress, use private service connectivity where justified, and log meaningful flow and edge decisions.
Data
Encrypt in transit and at rest, separate key administration, restrict snapshots and exports, and test rotation and recovery.
Detection
Centralize immutable activity evidence, configuration drift, findings, application audit events, and time-synchronized incident context.
Threat-model metadata services, build credentials, CI federation, resource policies, confused-deputy paths, cross-account access, public snapshots, dependency compromise, and destructive automation.
Operate cost, quotas, and reliability together
Monitor the service
- Demand, latency, errors, saturation, retries, throttling, queue age, connection limits, and dependency health
- Capacity by account, Region, AZ, service quota, warm pool, scaling delay, and failure reserve
- Spend by owner, workload, environment, resource, unit of demand, commitment coverage, idle capacity, and transfer path
- Configuration drift, IAM changes, network exposure, key usage, backup state, restore evidence, and recovery rehearsal age
Automate the lifecycle
- Provision with reviewed infrastructure code and policy checks.
- Use immutable or progressive deployment with health gates and rollback evidence.
- Tag ownership and expiry at creation; quarantine unknown resources.
- Set budget and anomaly alerts that route to an accountable team.
- Rehearse instance, AZ, dependency, credential, data, and regional failures.
A credible AWS design states where it runs, who can change it, what survives each failure, how data recovers, which quotas and transfer paths constrain it, and who owns the resulting cost.