Learning Resources
No cloud-platform primer exists in the local semester library for this module. The external stack below is therefore the authoritative source list. Treat provider documentation as the default, and use third-party material only when it adds cross-provider framing or a concrete cost perspective.
Source Stack
| Source | Role | How to use it in this module |
|---|---|---|
| AWS official docs (docs.aws.amazon.com, aws.amazon.com/*) | Primary teaching source | Default escalation for every concept; exact behavior, limits, pricing, and API shapes |
| GCP official docs (cloud.google.com) | Cross-provider reference | Use when the concept is sharper or differently named on GCP (e.g., Cloud Run) |
| Azure Learn (learn.microsoft.com) | Cross-provider reference | Use for Well-Architected-style framing and for regions/availability-zone cross-check |
| AWS Well-Architected framework | Selective support | Use for shared-responsibility and reliability framing in Clusters 1 and 5 |
| The Twelve-Factor App (12factor.net) | Application patterns | Use for Cluster 2 context: what makes a workload actually portable up the ladder |
Resource Map by Cluster
Cluster 1: What a Cloud Platform Is
| Need | Best external URL | Why |
|---|---|---|
| shared-responsibility model overview | AWS Shared Responsibility Model | Canonical AWS diagram and narrative; every concept 1 question maps here |
| shared-responsibility framed for security review | Well-Architected Security Pillar: Shared responsibility | Per-service-tier responsibility breakdown with practical language |
| regions and AZs on AWS | AWS EC2: Regions and Zones | Authoritative region/AZ/ID semantics |
| regions and AZs cross-provider (Azure) | Azure: What are availability zones? | Same concept, different vocabulary; good sanity check |
| Architecture strategy for AZs vs regions | Azure Well-Architected: Using Availability Zones and Regions | Decision-framework framing |
| app patterns on the abstraction ladder | The Twelve-Factor App | Portable-app patterns that make PaaS/serverless actually work |
Cluster 2: Compute
| Need | Best external URL | Why |
|---|---|---|
| EC2 autoscaling groups | EC2 Auto Scaling: Auto Scaling groups | Canonical ASG model |
| mixed-instance and Spot ASGs | EC2 Auto Scaling: Mixed instance types | How to diversify capacity safely |
| AWS Fargate for ECS | Architect for AWS Fargate for Amazon ECS | Task sizing, networking, pricing model |
| serverless containers on GCP | Google Cloud Run | Cross-provider compare for Cluster 2 concept 5 |
| Lambda concurrency and cold starts | Lambda function scaling | Concurrency limits, cold starts, provisioned concurrency pointers |
| Lambda cold-start mitigation (Java) | Lambda SnapStart | Concrete cold-start mitigation example |
| provisioned concurrency detail | Lambda provisioned concurrency | For latency-sensitive functions |
Cluster 3: Networking
| Need | Best external URL | Why |
|---|---|---|
| how VPCs work end-to-end | Amazon VPC: How it works | Canonical mental model |
| subnets, route tables, AZ scoping | Amazon VPC: Subnets for your VPC | Subnet and route-table semantics |
| VPC sizing and subnet basics | Amazon VPC: VPC basics | Entry-level sanity source |
| elastic load balancing overview | AWS: Elastic Load Balancing | All four load-balancer types compared in one place |
| Application Load Balancer | AWS: What is an Application Load Balancer? | Listener/rule model, target groups, health checks |
| private hosted zones | Route 53: Private hosted zones | Scope and resolution |
| PrivateLink endpoints | AWS PrivateLink: Accessing AWS services | Interface and gateway endpoints, DNS integration |
Cluster 4: Storage and Databases
| Need | Best external URL | Why |
|---|---|---|
| storage decision framework | AWS decision guide: Choosing an AWS storage service | Decision tree over S3/EBS/EFS and more |
| storage service overview | AWS Overview whitepaper: Storage services | Pricing classes and durability in one page |
| EFS vs S3 vs EBS | AWS: When to choose Amazon EFS | Direct comparison of the three shapes |
| managed relational databases | Amazon RDS overview | Engines, Multi-AZ, backup model |
| Aurora storage and failover | Amazon Aurora overview | Aurora's architecture vs RDS |
| data-transfer cost architecture | Overview of Data Transfer Costs for Common Architectures | Per-path pricing for typical topologies |
| reading data-transfer line items | CUR: Understanding data transfer charges | How to interpret egress lines in a bill |
Cluster 5: Identity and Accounts
| Need | Best external URL | Why |
|---|---|---|
| IAM JSON policy structure | IAM JSON policy element reference | Every policy field with examples |
| IAM identities | IAM identities: users, groups, roles | Canonical roles vs users framing |
policy Principal semantics | IAM JSON: Principal | Trust and resource-based policy detail |
| multi-account landing zones | Control Tower: Multi-account landing zone | The reference architecture |
| OU and account structure | Prescriptive Guidance: Account structure and OUs | OU layouts and rationale |
| landing zones for regulated orgs | OU structure in regulated AWS landing zones | PCI/HIPAA-aware OU variants |
| cost-allocation tagging | Tagging Best Practices: Cost allocation tags | How tags flow into billing reports |
| cost-allocation strategy | Tagging Best Practices: Building a cost allocation strategy | Full strategy blueprint |
Use Rules
- If you are unsure of exact behavior (limits, quotas, pricing, IAM action names), go to AWS docs first. They are the source of truth; blog posts are commentary.
- For concepts that recur across providers (regions, AZs, load balancers, object storage), skim one AWS page and one GCP or Azure page to make sure you are not conflating vocabulary.
- Open one URL per concept gap; do not crawl through a whole service guide.
- If you find a third-party blog giving a clearer explanation, still verify the facts in the provider's docs before trusting them in design work.