Cloud Architecture

Cloud architecture is the set of decisions that shapes a cloud workload. It defines the workload's components, their relationships, and the rules for operating them.

An architecture is more than a diagram. A diagram shows what connects today. The architecture explains why those connections exist, which qualities matter, and how the system should respond to change or failure.

You use cloud architecture to turn business needs into technical boundaries. Those boundaries cover identity, networking, compute, data, deployment, monitoring, recovery, and cost. They also identify who owns each decision.

Start with the workload

A workload is a set of resources and processes that delivers business value. A customer-facing application can be one workload. An analytics pipeline or internal identity service can be another.

Define the workload before choosing services. Ask:

Who uses it, and what outcome do they need?
Which functions are essential?
Which data does it create, read, or retain?
Which laws, policies, and contracts constrain it?
What traffic, growth, and change do you expect?
How much interruption and data loss can the business accept?
Who builds, operates, secures, and pays for it?

These answers become requirements. They keep a service feature from becoming an architectural goal by accident.

Separate functions from quality attributes

A functional requirement states what the workload must do. "Accept an order" is a functional requirement.

A quality attribute states how well the workload must operate. Reliability, security, performance efficiency, cost efficiency, and operability are common quality attributes.

Quality attributes create tradeoffs. More redundancy can improve availability, but it usually adds cost and operational work. Stronger isolation can reduce a failure's reach, but it can add communication and management overhead.

There is no universally best architecture. There is a design that fits a stated context, plus risks that the team accepts or reduces.

Turn the workload into boundaries

Good boundaries make ownership and failure behavior visible.

Use an administrative boundary to separate permissions, policy, and billing. Use a network boundary to control communication paths. Use a failure domain to describe resources that can fail together. Use a data boundary to establish ownership, consistency, retention, and recovery rules.

Cloud providers group infrastructure into geographic regions and smaller failure domains. Provider names differ, but the design question stays the same: which independent failure must the workload survive?

Avoid one large boundary for every system. It makes failures, permissions, and costs harder to contain. Avoid extreme fragmentation too. Every boundary creates interfaces and operational work.

Design the request path

Trace one important request from entry to result.

A user or system presents an identity.
An edge or network control accepts and routes the request.
Compute runs application logic.
The application reads or changes state.
Telemetry records the outcome.
A response or asynchronous event continues the process.

At each step, ask what can fail, time out, retry, or duplicate work. Decide where authentication and authorization occur. Identify which component owns state and which team owns the component.

This trace often reveals hidden dependencies. A redundant application is still unavailable if it depends on one database, one identity service, or one network path.

Design for failure and recovery

Cloud infrastructure does not remove failure. It gives you tools and locations for responding to failure.

Start with business targets. Recovery time objective, or RTO, is the maximum targeted time to restore a business process after disruption. Recovery point objective, or RPO, is the maximum targeted period of data loss measured backward from disruption.

Use these targets to choose redundancy, backup, replication, and failover mechanisms. A short RTO can require pre-provisioned capacity and automated recovery. A short RPO can require frequent or continuous replication.

Availability within one location and disaster recovery across locations address different failure scopes. More locations do not guarantee recovery. You still need correct data replication, routing, capacity, procedures, and tests.

Retries also need design. Retry only failures that may be temporary. Apply timeouts and limits. Make write operations idempotent when possible, so repeating the same request does not repeat its business effect.

Give state special treatment

Compute can often be replaced. State must remain correct.

Classify data by owner, sensitivity, location, durability, consistency, retention, and access pattern. Then choose storage that fits those needs. Do not begin with a familiar database type.

Replication creates copies, but copies may not become consistent at the same instant. Decide which operations require immediate consistency and which can accept delay. Document how conflicts are prevented or resolved.

Backups protect a different risk than replicas. Replication can copy accidental deletion or corruption. A backup can preserve an earlier recovery point if it is isolated, retained, and restorable. Test restoration; the existence of a backup does not prove recovery.

Treat security as architecture

Cloud security follows a shared responsibility model. The provider secures parts of the underlying cloud. You remain responsible for duties tied to your identities, data, application, and service configuration. The exact division changes with the service model.

Place identity before network location as a trust decision. Grant least privilege. Separate human, workload, and emergency access. Encrypt data according to its sensitivity and requirements. Keep secrets outside source code and rotate them through a managed process.

Use defense in depth by placing independent controls across identity, network, application, data, and monitoring layers. One control should not carry the full security outcome.

Record administrative activity and security-relevant events. Logs need protected storage, useful retention, and an owner who responds to them.

Make operations part of the design

A workload is not finished when deployment succeeds. It must be observable, changeable, and recoverable.

Define service level indicators, or SLIs, for measurable behavior such as successful request rate or latency. Set service level objectives, or SLOs, as target values for those indicators. Alert on conditions that require action, not every technical variation.

Automate repeatable deployment and configuration. Version infrastructure definitions alongside application changes. Prefer small, reversible changes. Keep a rollback or roll-forward path.

Create runbooks for failure modes that need human action. Name the owner, trigger, diagnostic evidence, safe actions, and escalation path. Exercise recovery procedures before an incident supplies the first test.

Choose services by responsibility

Cloud service models shift operational responsibility.

Infrastructure as a service, or IaaS, gives you fundamental compute, storage, and network resources. You manage more of the software stack.
Platform as a service, or PaaS, gives you a managed platform for deploying applications. The provider manages more of the underlying runtime.
Software as a service, or SaaS, gives you a provider-run application. You mainly manage usage, access, data, and integration.

A managed service can reduce undifferentiated operational work. It can also introduce service limits, provider-specific interfaces, pricing behavior, and migration effort.

Portability has levels. You might need portable data, portable application code, portable deployment definitions, or a complete multi-provider runtime. State the required level. Paying for theoretical portability that the business will never use creates complexity without a matching outcome.

Use patterns as options

An architecture style or pattern gives you a known arrangement with known consequences. It is not a certificate of quality.

A layered monolith can be the right starting point when one team owns a bounded product. Microservices can support independent change and scaling, but they add distributed communication, data ownership, and operations. Event-driven components can decouple producers and consumers, but they require explicit handling for duplicates, ordering, and delayed processing.

Select the simplest design that meets current requirements and keeps a credible path for likely change. Add a component when you can name the requirement or risk it addresses.

Review the architecture as it changes

Record important choices in an architecture decision record, or ADR. Include the context, decision, alternatives, consequences, and review trigger.

Review a workload through several lenses:

Does it meet its business function?
Is access constrained and activity traceable?
Which failures can it tolerate?
Does performance meet measured demand?
Can the team deploy, observe, and recover it?
Can owners explain and control its cost?
Does resource use match the required outcome?

Revisit the design after incidents, major demand changes, new compliance needs, and important service changes. Architecture is a maintained set of decisions.

When cloud architecture fits

Cloud services can fit workloads that benefit from on-demand provisioning, elastic capacity, managed capabilities, global reach, or measured usage. Those properties match the NIST cloud characteristics.

Cloud is not automatically the right location for every workload. Strict latency, disconnected operation, hardware dependency, data-location rules, migration cost, or a stable existing platform can favor on-premises or hybrid designs.

The useful question is not "cloud or no cloud?" Ask which placement and service model meet the requirements with acceptable risk, cost, and operational responsibility.