CCHQ ARTICLE GUIDE / CLOUD PLATFORMS
Practical learning, clear decisions, real-world context
An easy-to-navigate technical field guide with key takeaways, actionable checks, FAQs, and official references. Approximately 9 minutes of reading.
Cloud computing architecture is the set of decisions that determine how an application uses compute, networking, storage, identity, data services, monitoring, and recovery in a cloud environment.
A good architecture is not simply a diagram full of service icons. It explains how requests and data move, which identities can perform each action, what happens when a component fails, and what the system costs when traffic changes.
AWS, Microsoft Azure, and Google Cloud offer different names and implementation details for many of the same core capabilities.
The durable engineering skill is learning to reason about requirements, trust boundaries, dependencies, and trade-offs before choosing a particular service.
This guide gives aspiring cloud engineers a repeatable method for drawing and assessing a simple web application, then translating that design into an AWS, Azure, or Google Cloud implementation.
At a glance
The main topics you’ll work through:
- Start with requirements, not service selection
- Map the layers of a cloud application
- Understand networking and trust boundaries
- Choose compute based on operational needs
In this guide
01 / KEY CONCEPT
Start with requirements, not service selection
KEY TAKEAWAY
Before creating resources, write down what the application must do.
Identify the users, expected traffic, types of data, recovery needs, geographic constraints, and permitted monthly spend.
A portfolio website and a payment-processing application may both run in the cloud, but they have very different tolerance for outages, administrative access, data loss, and unexpected costs.
Capture the business goal in a short paragraph, then turn it into measurable requirements. For example, define an acceptable recovery time after a service failure and whether the workload can be temporarily unavailable during maintenance.
Treat nonfunctional requirements as design inputs rather than decorations added at the end. Security determines which systems may talk to each other. Reliability determines whether one availability zone is acceptable.
Performance determines cache and data placement. Observability determines whether failures can be diagnosed. Cost determines whether fully managed services or smaller experiments are justified.
A useful first artifact is a one-page decision record listing the assumptions you made, the alternatives you considered, and the circumstances that would cause you to revisit them.
02 / PRACTICAL APPLICATION
Map the layers of a cloud application
KEY TAKEAWAY
A typical application contains a client, DNS and routing, an entry point for requests, a compute layer, a data layer, and supporting management services.
Draw a request entering through DNS and HTTPS, reaching a load balancer or managed endpoint, then reaching an application service that calls a database. Indicate where files are stored and how the service gets credentials.
Draw administrative traffic separately from user traffic because an engineer’s access path should not be identical to the public application entry point.
The application also needs services that users do not see: logs, metrics, tracing, audit records, configuration, secrets, backups, deployment pipelines, and alerting. A diagram that omits these elements can hide operational weaknesses.
Mark which components are managed by the provider and which remain your responsibility. Managed databases reduce work on hardware and some maintenance tasks, but you still choose access controls, backup policies, data models, and recovery objectives.
Cloud architecture is ultimately a description of both components and responsibilities.
03 / KEY CONCEPT
Understand networking and trust boundaries
KEY TAKEAWAY
Most cloud providers give you a way to define an isolated virtual network with address ranges, subnets, routes, and filtering controls.
AWS uses VPCs, Azure uses virtual networks, and Google Cloud uses VPC networks. These concepts resemble one another but are not interchangeable in every detail.
Place public-facing entry points in the appropriate network path and keep databases and internal service endpoints off the public internet unless the design has a well-justified need.
A resource being inside a virtual network is not, by itself, proof of isolation.
Draw trust boundaries wherever identity, network ownership, or data sensitivity changes. Examples include the boundary between the browser and the web endpoint, between the app and database, and between a deployment workflow and the production account.
Use encryption in transit, narrow security group or firewall rules, and separate administrative permissions. A private subnet is useful only when its routes, endpoints, and access rules support the intended communication.
Review ingress and egress so a component cannot reach arbitrary destinations merely because it can start a connection.
04 / PRACTICAL APPLICATION
Choose compute based on operational needs
KEY TAKEAWAY
Virtual machines provide control of an operating system, packages, and background services.
They also leave patching, capacity planning, scaling configuration, and much operational work to the team. Containers package an application and its dependencies into an image; a managed container service can schedule and restart those images.
Serverless functions can handle event-driven tasks without managing long-running servers directly, but they introduce execution limits, service integration considerations, and new observability patterns. None of these choices is automatically the best.
Ask whether the workload must run continuously, needs specialized runtime access, has predictable traffic, or can tolerate variable request latency.
For a learning lab, a small managed function may simplify infrastructure; for a long-lived service, a container might better match the deployment process.
Estimate not only compute charges but also load balancing, data transfer, storage, logging, image storage, and support resources.
Architecture reviews should examine the complete billable path rather than comparing only the headline price of a VM and a function.
05 / KEY CONCEPT
Design storage and data access deliberately
KEY TAKEAWAY
Object storage is appropriate for assets, backups, exports, and large blobs.
Block storage suits workloads that need disk-like access. Relational databases handle structured records and transactional relationships; NoSQL and other specialized data stores support different access patterns.
Choose a data store by how the application reads, writes, queries, and recovers information—not because a certification course mentions it frequently. A diagram should show data ownership, sensitivity, retention, and the source of truth.
For a simple web application, users might upload files to object storage while metadata lives in a relational database. The application should not need broad administrative rights to either service.
Use temporary identities, encryption policies, and explicit data access paths. Consider backup frequency, recovery testing, schema migrations, and deletion requirements.
A backup that exists but cannot be restored inside the required recovery window is not a complete recovery strategy. Similarly, replication increases availability but does not automatically protect against accidental deletion or malicious changes.
06 / PRACTICAL APPLICATION
Compare AWS, Azure, and Google Cloud concepts
KEY TAKEAWAY
On AWS, an introductory architecture might combine Route 53, a load balancer or API Gateway, compute such as ECS or Lambda, S3, and a managed database.
On Azure, analogous building blocks include Azure DNS, application entry services, App Service or Container Apps, Blob Storage, and Azure SQL or other managed databases.
On Google Cloud, comparable patterns can use Cloud DNS, Cloud Run or other compute, Cloud Storage, and Cloud SQL. These are illustrative mappings, not assertions that each service has identical behavior, pricing, networking, or availability.
Use each provider’s architecture framework when evaluating a design. AWS Well-Architected covers operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.
Microsoft’s Cloud Adoption Framework emphasizes organizational foundations and landing zones alongside workload operation. Google Cloud has its own Well-Architected guidance for security, reliability, cost, performance, and operations.
Studying the differences teaches a more valuable skill than memorizing a table of service names: understanding where governance, identity, recovery, and deployment responsibility reside.
07 / KEY CONCEPT
Build a small reference design on paper
KEY TAKEAWAY
Consider a hypothetical read-only documentation site.
A visitor requests a page over HTTPS. A public content delivery or application endpoint serves the result. An application component retrieves metadata from a private store and static assets from object storage.
Content authors authenticate through a separate administrative identity. A monitoring component records error rates and latency, and the deployment process promotes versioned application changes.
Label the exact data flow, and identify which arrows cross a trust boundary or incur data transfer charges.
Now challenge the design with five questions. What stops an anonymous visitor from accessing the database directly? What happens if the app crashes after an update? Can a stolen deployment token modify production resources?
How would you restore an accidentally deleted object? Which resource continues accruing charges when no visitors arrive? Write the answers beside the diagram.
If you cannot answer without assuming the provider handles everything, the drawing is not ready to become production infrastructure. This exercise turns a generic diagram into a decision-making tool.
08 / PRACTICAL APPLICATION
Validate the design before and after deployment
KEY TAKEAWAY
A paper review should check requirements coverage, service ownership, access paths, and failure scenarios.
Use a simple threat model: identify assets, possible actors, entry points, and controls. Verify the application’s critical dependencies and mark potential single points of failure.
Estimate which components need metrics and which events must be captured in audit logs. For a real deployment, inspect the provider’s configuration rather than assuming your intended settings took effect.
Check identity policies, exposed endpoints, encryption, routing, backup states, and alert delivery.
Run a limited failure experiment only in an authorized lab, such as stopping a noncritical task and observing whether the intended replacement starts. Record the observed behavior and compare it with the expected recovery time.
If the design includes automated deployment, verify that an unapproved identity cannot run the pipeline. If it includes cost controls, inspect the account’s current charges and budget alerts, remembering that budget notifications are not a hard spending cap.
Keep screenshots or test logs only for work you actually performed, and disclose when a diagram is conceptual.
09 / KEY CONCEPT
Cost, documentation, and future evolution
KEY TAKEAWAY
Cloud architecture changes as the workload changes.
A small learning site may start in one region with few components, whereas a production system may need redundancy, formal change controls, more detailed monitoring, and data residency safeguards.
Capture the initial design in version control with a concise architecture decision record. Note the cloud region, service tiers, IAM assumptions, estimated recurring resources, and deployment dependencies.
Avoid hardcoding exact prices into evergreen tutorials when service prices vary by region and time.
Return to the design after measuring traffic, failure patterns, and operational overhead. Introduce caches only when measurements show a need. Add redundancy where failure impact warrants the expense.
Separate environments when the deployment and security process requires it. Engineers demonstrate maturity by removing needless complexity as confidently as they add components.
A successful cloud design is not the one with the largest diagram; it is the one that reliably fulfills stated requirements, makes risk visible, and can be operated by the people responsible for it.
Before you finish: practical checklist
Turn the main lessons into a short review of your own environment:
- Identify the users, expected traffic, types of data, recovery needs, geographic constraints, and permitted monthly spend.
- Use encryption in transit, narrow security group or firewall rules, and separate administrative permissions.
- Review ingress and egress so a component cannot reach arbitrary destinations merely because it can start a connection.
- Choose a data store by how the application reads, writes, queries, and recovers information—not because a certification course mentions it frequently.
- Use temporary identities, encryption policies, and explicit data access paths.
Frequently asked questions
Is cloud architecture the same as cloud engineering?
Architecture concentrates on system-wide decisions and trade-offs; engineering implements, operates, and improves those decisions. In practice, the work overlaps. A cloud engineer who can explain why an IAM boundary or network route exists is stronger than one who only knows which console button to press.
Do beginners need to learn all three cloud providers?
No. Learning one platform deeply and understanding transferable concepts is usually more productive than memorizing three sets of service names. Use provider comparisons to recognize which ideas transfer and which details require fresh documentation.
Should every cloud application use Kubernetes?
No. Kubernetes is useful for certain workload and platform requirements, but it adds cluster and operational complexity. Managed functions, app platforms, and other container services may fit a small application better. Choose based on workload requirements and the team operating it.
Official documentation and next steps
AWS Well-Architected Framework · Microsoft Cloud Adoption Framework · Google Cloud Well-Architected Framework
To continue learning, explore the Cloud Platforms hub, then develop a concrete application from the requirements you documented.
A good next exercise is to choose one identity model, one deployment strategy, and one measurable recovery objective, and explain each choice in a design review.
