Real Cloud Architecture Examples: Patterns Used in Production

Pattern 1: The typical SaaS web application

This is the most common setup for a product company. A web frontend, a backend API, a database, and some supporting infrastructure.

What it looks like

• A CDN (CloudFront, Fastly, or Cloud CDN) sits in front of static assets and sometimes the API
• A load balancer receives traffic and distributes it to a pool of application server instances
• The application runs on ECS, GKE, or EC2 in an auto-scaling group, depending on the team’s preferences and history
• A managed relational database (RDS PostgreSQL, Cloud SQL) in a private subnet — accessible from the application but not from the internet
• A Redis cluster for caching and session storage
• An S3 bucket or GCS bucket for user-uploaded files, served back through the CDN
• A background job queue (SQS, Pub/Sub, or a managed Redis queue) for async work like sending emails or processing uploads

What the diagram does not show

It does not show the read replica that was added when the primary database got overloaded eighteen months ago. It does not show the three different VPN integrations for connecting to enterprise customers. It does not show the legacy batch job that runs on a lone EC2 instance because nobody has had time to migrate it. Real systems accumulate these things.

Cloud engineering’s role here

Cloud engineers maintain the VPC, the auto-scaling configuration, the database backup policy, the CDN cache invalidation rules, and the cost optimisation (the EC2 instance types chosen when the company had ten users may not be right for ten thousand). They also own the deployment pipelines and the monitoring that tells the team whether everything is working.

Pattern 2: A data processing pipeline

Common at companies that collect large amounts of event data — analytics platforms, IoT companies, adtech, fintech, and any product with a data warehouse behind it.

What it looks like

• Ingestion: Events from the application are written to a stream (Kinesis, Pub/Sub, or Kafka). The stream buffers the events so downstream processing does not need to keep up in real time.
• Processing: A set of workers consume the stream — transforming, filtering, and enriching the events. Sometimes this is a managed service (Dataflow, AWS Glue), sometimes it is a custom service running on Kubernetes.
• Storage: Processed events land in a data warehouse (BigQuery, Redshift, Snowflake) and also in object storage (S3 or GCS) for cheaper long-term archiving.
• Query layer: Analysts and dashboards run SQL queries against the warehouse. Cost spikes here are common — a badly written query scanning terabytes daily can add hundreds of dollars per month.

What the diagram does not show

The stream has two consumers, and they were added at different times by different teams, with different error handling. One drops events silently when processing fails; the other writes to a dead-letter queue. Both behaviours are correct in isolation, but the team does not know which to trust when counts diverge.

There is also a nightly batch job that backfills missed data. It was supposed to be temporary when it was written fourteen months ago.

Cloud engineering’s role here

Cloud engineers provision and maintain the streaming infrastructure, manage the data warehouse cost controls, and often own the pipeline monitoring (lag alerts on the stream, job failure notifications). In smaller teams, they also write and maintain the processing jobs.

Pattern 3: Microservices on Kubernetes

Common at companies that started with a monolith and decomposed it over time, or at organisations that adopted service-oriented architecture from the start.

What it looks like

• A Kubernetes cluster (EKS, GKE, or AKS) running 20 to 200 services, each deployed as a separate Deployment or StatefulSet
• An ingress controller (NGINX, Istio, or a cloud-native one) routing external traffic to the right internal service
• A service mesh (Istio or Linkerd) handling mTLS between services, traffic shaping, and distributed tracing — sometimes
• Each service has its own database, or databases are shared between small groups of services
• A centralised logging and tracing stack (Loki + Tempo + Grafana, or Datadog, or Elastic)

What the diagram does not show

Fifteen of those services were built by teams that no longer exist. Six of them have not been touched in over a year. Nobody is sure what two of them actually do, and removing them requires investigation nobody has time for.

There is a service that calls another service synchronously, which calls a third service, which calls the first service under specific conditions. Nobody documented this cycle. It only surfaces during incidents.

Cloud engineering’s role here

Cluster maintenance (upgrades, node pool management, capacity planning), deployment tooling (Helm, ArgoCD, or Flux for GitOps deployments), and network policy management. In most teams, cloud engineers also handle the observability stack and the on-call runbooks for cluster-level issues.

Pattern 4: Multi-account AWS or GCP organisation

Common at larger organisations or those with strict compliance requirements. Instead of one cloud account, there are many — typically one per environment, one per team, or both.

What it looks like

• A management account (AWS Organizations or GCP Organization) that contains billing, IAM identity, and policies that apply to child accounts
• Separate accounts for production, staging, development, and security tooling
• Networking managed centrally — often a Transit Gateway (AWS) or Shared VPC (GCP) so accounts can communicate without exposing everything to the internet
• Centralised logging: all accounts ship logs and audit trails to a dedicated security account that developers cannot access
• Service Control Policies (AWS) or Organization Policies (GCP) that enforce guardrails — for example, “no one in this organisation can disable CloudTrail” or “all storage buckets must use customer-managed encryption keys”

What the diagram does not show

There is one account that was created before the multi-account strategy was adopted. It has everything in it — production, staging, and dev workloads — because migrating out has always been too disruptive to prioritise. The strategy only covers everything except that account.

Cloud engineering’s role here

Landing zone design and maintenance, account vending (the process for creating new accounts with the right baseline configuration automatically), cross-account IAM and networking, and enforcing organisational policies. This is senior-level work that requires understanding security, governance, and automation together.

What “real” architecture actually means

All four patterns above are real. So is everything that did not make it into the diagrams.

Production systems are not built once and left alone. They evolve over years, with different teams, different priorities, and different levels of care. The clean architecture decision made at year one is surrounded by pragmatic additions, temporary workarounds, and inherited choices by year five.

Experienced cloud engineers understand that maintaining and improving existing systems is as valuable as designing new ones — often more valuable. If you want to understand how things break in production, that is the next logical step after understanding how they are built.

For the certification and study path to understand these patterns properly, the AWS Solutions Architect – Associate and Google Professional Cloud Architect exams both test your ability to design architectures like the ones above.