Foundations
Provider-neutral core
Learn the recurring concerns underneath every cloud platform before you map them to product names.
Use this section to separate durable concepts from vendor naming, defaults, and marketing layers so later service choices are easier to justify.
Orientation
Start with the pages that define the field, the learning path, and the main provider differences.
What Is Cloud EngineeringLearning RoadmapProvider Differences
Platform Basics
Understand networking, identity, compute, storage, and database choices before comparing managed services.
Delivery Systems
Study the building blocks that shape how workloads are packaged, deployed, and changed over time.
Operations And Scale
Connect observability, cost, and AI-oriented workloads to the rest of the operating model.
Purpose
This section explains the concepts that sit underneath every cloud platform. The goal is to understand how cloud systems are designed and operated before focusing on provider-specific service names.
How To Use This Section
Read the Foundations pages as a connected set, not as isolated definitions. Networking affects identity. Identity affects CI/CD. Compute choices affect observability and cost. Storage and database choices affect architecture for years. The more clearly you can see those relationships, the easier it becomes to design systems that work in production.
If you are early in your learning path, start with the general pages and then move into the more technical building blocks. If you already know one provider well, use this section to separate durable concepts from vendor naming and defaults.
Recommended Reading Order
- What Is Cloud Engineering
- Learning Roadmap
- Cloud Provider Differences
- Networking
- Identity and Access
- Compute
- Storage
- Databases
- Serverless
- Containers
- Infrastructure as Code
- CI/CD
- Observability
- Cost Management
- AI and Agents
What Strong Foundations Look Like
Strong cloud foundations mean you can explain more than which service to click. You should be able to describe:
- how traffic reaches the system,
- who or what is allowed to use it,
- where code runs,
- where data lives,
- how changes are deployed,
- how failures are detected,
- and what cost or risk grows as the system scales.
That level of understanding transfers across providers and makes later project work much more useful.
How This Fits Into Cloud Engineering
Cloud engineers use these ideas to choose services, set guardrails, debug failures, and explain tradeoffs to both technical and non-technical stakeholders. Provider pages make far more sense once the underlying concepts are clear.