What is
Architecture as Code?

The model behind the diagram

In Cloud Markup, Architecture as Code means representing cloud architecture as a typed, versioned model. Services, relationships, and configuration have meaning beyond their position on a canvas. That model becomes a shared reference for the diagram, validation findings, and supported infrastructure outputs.

The practical question is simple: when a team changes an architecture, can the people reviewing it understand what changed and which design the handoff represents?

A picture is useful for a conversation. A structured model can also capture that one resource depends on another, which settings belong to a service, and which revision produced an exported artifact. Moving a box should change the layout—not silently change the infrastructure it describes.

How it relates to Diagram as Code and Infrastructure as Code

These approaches work at different levels. They can complement one another rather than replace one another.

Architecture diagrams

Communicate the components and relationships in a system. They help people discuss a design, but a drawing alone may not carry the configuration or revision history needed for implementation.

Diagram as Code

Describes a diagram using text or structured data so that the visual can be generated and its source reviewed. Whether that source also models deployable resources depends on the tool.

Architecture as Code

Connects system intent to a structured architecture model. In Cloud Markup, the model ties visual design to service configuration, deterministic checks, and revision-based handoffs.

Infrastructure as Code (IaC)

Defines infrastructure through configuration that provisioning tools can use. For example, Terraform separates writing configuration, planning changes, and applying them. See HashiCorp’s Terraform introduction.

Architecture work can inform an IaC workflow, but producing an export is not the same as deploying it. The receiving team still reviews the code, checks it against the target environment, and controls execution. AWS’s introduction to Infrastructure as Code explains the role of versioned, declarative configuration in provisioning.

An AWS example: the questions behind the boxes

Consider an API design with Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. A diagram can communicate the request path quickly. The handoff also needs to make the design’s assumptions understandable.

• Entry point: How should requests reach the application, and what authentication is intended?
• Compute: What belongs in the function’s configuration, and which resources does it need to access?
• Data: What information is stored, and what access should the application have?
• Review: Which questions are resolved, which findings remain, and which revision is ready to hand off?

A structured architecture workflow brings those questions closer to the visual design. This is an illustrative example, not a complete deployable reference architecture; service support and validation coverage depend on the workspace.

Keep the workflow reviewable

1. Model the design. Add supported services, define their relationships, and keep configuration close to the architecture.
2. Review proposed changes. Where AI assistance is available, inspect proposals before accepting them. A generated suggestion should remain a proposal until you choose to apply it.
3. Validate and refine. Use supported deterministic checks to surface findings. A passing check is evidence for that check, not a guarantee that every design concern has been covered.
4. Hand off a specific revision. Keep the exported artifacts tied to the architecture they came from. Review and deploy them through the process your team owns.

This is especially useful when architects, platform engineers, and developers need to carry decisions between design and implementation. You can follow the steps in more detail on our design-to-handoff workflow page.