Skip to content
BeaconiXBlueprint

Cloud Architecture

Cloud Architecture Principles

Two complementary views: the platform principles that shape every workload, and the integration pattern library used to connect them.

Platform architecture

Eleven platform principles

These principles apply regardless of workload type — they are enforced through the landing zone, not left to individual project discretion.

Identity first

Every access decision starts with identity — human, workload, or agent.

Infrastructure as Code

No production resource exists that isn't defined in a repository.

Policy as Code

Governance rules are versioned, tested and deployed like application code.

Private-by-default

Public endpoints are the exception, justified and reviewed — not the default.

Observable-by-default

Logging and metrics are provisioned alongside the resource, not bolted on later.

Least privilege

Access is scoped to the smallest role and shortest duration that satisfies the need.

Environment separation

Dev, test and production are isolated at the subscription boundary, not by naming convention.

Resilience

Failure modes are designed for — retries, redundancy and graceful degradation are explicit.

Cost governance

Budgets, alerts and right-sizing are part of design, not a post-deployment audit.

Standardised deployment

Landing zone templates and pipeline patterns are reused, not reinvented per team.

Automation-first operations

Routine operational tasks are automated; manual runbooks are the fallback, not the plan.

Integration architecture

Azure Integration Services pattern library

Eight integration shapes, each mapped to the Azure service Contoso uses by default. Expand a pattern for guidance on when — and when not — to reach for it.

API

Expose a governed, versioned interface to internal or partner consumers.

Azure API Management

When to use

  • +Synchronous request/response is required
  • +Consumers need a stable, documented contract
  • +Rate limiting, auth or transformation is needed at the edge

When not to use

  • -Long-running or fire-and-forget processing
  • -High-volume telemetry ingestion

Example architecture

Contoso partner portal calls a versioned order-status API fronted by APIM, with OAuth2 and subscription-key policies.

Key design considerations

  • Versioning strategy
  • Throttling policy
  • Backend health probes
  • OpenAPI contract

Command / Queue

Decouple producer and consumer with guaranteed, ordered, single-consumer delivery.

Azure Service Bus (Queues)

When to use

  • +Work must be processed exactly once by one consumer
  • +Producer and consumer scale independently
  • +Back-pressure protection is needed for downstream systems

When not to use

  • -Multiple independent consumers need the same message
  • -Sub-second end-to-end latency is required at high volume

Example architecture

Contoso's finance system enqueues invoice-approval commands consumed by a single processing service.

Key design considerations

  • Dead-letter handling
  • Message sessions for ordering
  • Poison message policy

Publish / Subscribe

Deliver the same message to multiple independent subscribers with filtering.

Azure Service Bus (Topics)

When to use

  • +Several systems need to react to the same business event
  • +Subscribers need independent consumption rates
  • +Filtering per-subscriber is required (topic subscription rules)

When not to use

  • -Only one consumer will ever exist
  • -Simple point-to-point delivery is sufficient

Example architecture

An 'EmployeeOnboarded' event fans out to provisioning, IT asset, and facilities subscribers via topic subscriptions.

Key design considerations

  • Subscription filter rules
  • Topic sizing
  • Consumer idempotency

Event distribution

Route discrete, lightweight system events to many handlers at near-real-time.

Azure Event Grid

When to use

  • +Reacting to resource or platform state changes
  • +High-scale fan-out with low-latency delivery
  • +Serverless event-driven triggers (e.g. blob created)

When not to use

  • -Large payloads need to be delivered (Event Grid favours small event payloads)
  • -Guaranteed strict ordering is required

Example architecture

A new file landing in Contoso's ingestion container triggers an Event Grid event that starts a Function.

Key design considerations

  • Event schema (CloudEvents)
  • Retry policy
  • Dead-lettering to storage

Workflow orchestration

Coordinate multi-step business processes across systems with low-code visibility.

Azure Logic Apps

When to use

  • +A business process spans multiple systems or approvals
  • +Visibility and auditability of each step matters to the business
  • +Connectors to SaaS or line-of-business systems are needed quickly

When not to use

  • -High-throughput, low-latency processing is the priority
  • -Complex custom logic is better expressed in code

Example architecture

Contoso's supplier onboarding workflow moves a request through legal, finance and IT approval steps.

Key design considerations

  • Run history retention
  • Error handling scopes
  • Connector governance

Serverless processing

Run event-triggered, stateless compute without managing infrastructure.

Azure Functions

When to use

  • +Short-lived, event-triggered processing logic
  • +Variable or unpredictable load that benefits from scale-to-zero
  • +Custom transformation logic between integration components

When not to use

  • -Long-running or stateful processing (consider Durable Functions or containers)
  • -Consistently high, steady-state load where reserved compute is cheaper

Example architecture

A Function normalises inbound partner file formats before publishing a Service Bus message.

Key design considerations

  • Cold start impact
  • Execution timeout limits
  • Managed identity for downstream calls

File integration

Exchange data with systems that only support file-based interfaces.

Azure Storage (Blob) + Logic Apps

When to use

  • +Trading partners require SFTP, CSV or fixed-width file exchange
  • +Legacy systems have no API surface
  • +Batch processing windows are acceptable

When not to use

  • -Near-real-time delivery is required
  • -Both systems already support API or event integration

Example architecture

A nightly export lands supplier invoices in Blob Storage, triggering validation and downstream posting.

Key design considerations

  • File naming conventions
  • Malware scanning
  • Archival and retention policy

Streaming

Ingest and process high-volume, high-throughput event streams in near-real-time.

Azure Event Hubs

When to use

  • +Telemetry, IoT or clickstream-scale ingestion
  • +Multiple consumers need independent read positions (consumer groups)
  • +Ordered processing per partition key is required

When not to use

  • -Low-volume, discrete business events (Event Grid is a better fit)
  • -Simple task queuing without a streaming consumption pattern

Example architecture

Contoso's facility sensors stream telemetry through Event Hubs into Stream Analytics for anomaly detection.

Key design considerations

  • Partition key design
  • Consumer group isolation
  • Capture to storage for replay