Recommend a Logging Solution — Lesson

This lesson focuses on a single, high-impact Azure architecture decision: choosing the right Log Analytics workspace design for your organisation. A workspace is the gravitational centre of Azure observability — every diagnostic setting, every Data Collection Rule, every KQL query, and every alert rule ultimately depends on the workspace you point it at. Getting the topology, retention, access model, and pricing tier right on day one saves months of painful refactoring later. This lesson covers workspace topology patterns (centralised, decentralised, hybrid), retention and archival mechanics, RBAC and data-residency controls, and the cost levers that keep your logging bill predictable.

Scope discipline: This LO is about the logging sink — Log Analytics workspace design, retention, cost, RBAC model, and data residency. It is not about routing logs to destinations (that is LO2 — Design a log routing solution) or about monitoring signals and alerts (that is LO3 — Recommend monitoring tools for a solution).

Reference: Ch. 1, §1.1, p. 3–8 of the AZ-305 exam book.

Why This Matters

Picture this: you have just joined an enterprise with 14 Azure subscriptions, 200+ resources, and zero centralised logging. When an outage hits, each team scrambles through its own disconnected workspace — if one exists at all. The security team cannot correlate sign-in anomalies with infrastructure events. Finance has no idea why the Azure bill jumped 40% last month (spoiler: a forgotten workspace was ingesting 500 GB/day with no commitment tier). This is the scenario the AZ-305 exam tests you on, and it is the scenario you will face in real engagements.

The Log Analytics workspace decision sits at the intersection of the Well-Architected Framework's Operational Excellence pillar ("can we observe our workloads?") and Cost Optimization pillar ("are we paying only for the data we actually need?"). Getting it right earns you a unified query surface, predictable costs, and clean RBAC boundaries. Getting it wrong creates data silos, runaway bills, and compliance gaps that are expensive to fix after the fact.

Prerequisites

• Azure Resource Manager (ARM) hierarchy — Can you describe how management groups, subscriptions, resource groups, and resources nest? Self-check: if you assign a role at the subscription level, which resources inherit it?
• Azure RBAC fundamentals — Do you know the difference between a built-in role like Log Analytics Reader and a custom role with Microsoft.OperationalInsights/workspaces/query/*/read? Self-check: what happens if a user has Reader on a resource group but no role on the workspace inside it?
• Basic KQL syntax — Can you write a where + summarize query? Self-check: write a query that counts rows in Heartbeat grouped by Computer.
• Azure pricing model awareness — Do you understand the difference between pay-as-you-go and commitment/reservation pricing? Self-check: why would committing to a fixed daily volume save money?

Learning Objectives

By the end of this lesson you will be able to:

1. Evaluate the three Log Analytics workspace topology patterns — centralised, decentralised, and hybrid — and select the right one for a given set of organisational, regulatory, and cost constraints.
2. Design a workspace retention and archival strategy that balances interactive query needs against long-term compliance requirements and cost.
3. Recommend the appropriate RBAC model — workspace-context versus resource-context — to enforce least-privilege access to log data without creating unnecessary workspace sprawl.
4. Analyse the cost implications of workspace sizing, including PerGB2018 pay-as-you-go pricing, commitment tiers, and the daily cap safety net.
5. Construct a workspace deployment using Bicep or ARM templates that encodes topology, retention, SKU, and access-control decisions as infrastructure-as-code.

Building Blocks

Log Analytics workspace — Analogy: think of a data warehouse purpose-built for operational telemetry — it receives data from many sources, stores it in structured tables, and lets you query it with a specialised language. → Formal definition: an Azure resource of type Microsoft.OperationalInsights/workspaces that ingests, indexes, and retains log and performance data collected by Azure Monitor. You query it using Kusto Query Language (KQL). Each workspace has its own retention policy, pricing tier, and access-control boundary. → Why it matters: the workspace is the single most impactful logging design decision because it determines who can see what data, how long that data is retained, and how much you pay per gigabyte.

Kusto Query Language (KQL) — Analogy: SQL for time-series operational data — you pipe data through operators (where, summarize, join, render) instead of writing nested subqueries. → Formal definition: a read-only query language optimised for large volumes of semi-structured log and telemetry data stored in Azure Data Explorer and Log Analytics. → Why it matters: KQL is the query surface for every Log Analytics workspace. Your topology decision determines whether a single KQL query can reach all the data you need, or whether you must use expensive cross-workspace unions.

Resource-context RBAC — Analogy: imagine a library where your membership card grants you access to specific bookshelves rather than the entire building. → Formal definition: an access model in which a user's permissions on an Azure resource automatically grant them read access to that resource's logs in the workspace, without needing a direct role assignment on the workspace itself. Enabled by setting the workspace access-control mode to UseResourcePermissions. → Why it matters: resource-context RBAC lets you centralise logs into a single workspace while still enforcing least-privilege access per team, per resource, or per resource group.

Commitment tier — Analogy: a bulk discount at a warehouse store — you commit to buying a fixed daily volume and get a lower per-unit price in return. → Formal definition: a Log Analytics pricing option where you pre-commit to a daily ingestion volume (starting at 100 GB/day) in exchange for a per-GB discount of up to 30% compared to pay-as-you-go. Overage above the commitment is billed at the commitment-tier effective rate, not at the higher pay-as-you-go rate. → Why it matters: for workspaces ingesting more than 100 GB/day, a commitment tier is almost always cheaper; choosing the wrong tier (or staying on pay-as-you-go) is one of the most common cost mistakes in Azure logging.

Archive tier — Analogy: moving old files from your desk drawers into off-site document storage — you can still retrieve them, but it takes longer and costs a retrieval fee. → Formal definition: a per-table retention policy in Log Analytics that moves data beyond the interactive retention period (up to 730 days) into a low-cost archive (up to 12 years total). Archived data cannot be queried directly; you must run a search job or restore operation to bring it back into an interactive state. → Why it matters: archive dramatically reduces long-term retention costs for compliance-driven tables while keeping the data accessible if an auditor or investigation demands it.

Deep Dive

Workspace Topology Patterns

The exam book (p. 3–6) establishes that every logging design begins with topology. There are three canonical patterns:

The driving factors behind the choice:

[!TIP] Microsoft's Cloud Adoption Framework (CAF) recommends starting with a centralised workspace for most organisations and splitting into a hybrid model only when a concrete regulatory or autonomy requirement demands it. Premature decentralisation is the most common anti-pattern.

Retention and Archival Strategy

Log Analytics offers a two-tier retention model:

Retention can be configured at two levels:

1. Workspace-level default — applies to all tables unless overridden. Set via the retentionInDays property.
2. Per-table override — individual tables can have longer or shorter interactive retention. Useful for high-volume, low-value tables (e.g., ContainerLog at 30 days) versus compliance-critical tables (e.g., SecurityEvent at 365 days).

To set per-table retention (e.g., 365 days for SecurityEvent):

[!IMPORTANT] The --total-retention-time parameter controls the archive duration (interactive + archive combined). Setting it to 2556 days (7 years) means data remains in archive for $2556 - 365 = 2191$ days after it leaves the interactive tier.

[!WARNING] Archived data is not queryable with a standard KQL query. If an auditor asks for a 3-year-old sign-in record, you must run a search job (which can take minutes to hours depending on the data volume scanned). Factor this retrieval latency into your compliance SLA.

RBAC and Access Control Models

The exam book (p. 3–6) highlights that workspace access is governed by the accessMode property, which has two settings:

Resource-context is enabled by default on workspaces created after March 2019. For older workspaces, you must set it explicitly:

In addition to resource-context, you can apply table-level RBAC to restrict access to specific tables (e.g., deny the app team access to SecurityEvent). This uses custom roles with Microsoft.OperationalInsights/workspaces/query/<TableName>/read actions.

[!NOTE] Table-level RBAC is an additive deny model — you grant workspace-level read, then deny specific tables. It is more complex to manage than workspace-level isolation but avoids workspace sprawl.

Pricing and Cost Optimisation

Log Analytics costs have three components:

The commitment-tier break-even analysis:

As a safety net, you can configure a daily cap that stops ingestion when a threshold is reached. This prevents runaway costs from a misconfigured resource flooding the workspace — but be aware that capping also means you lose visibility during the capped period.

Data Residency and Sovereign Compliance

A Log Analytics workspace stores data in the Azure region where it is deployed. For organisations with data-residency requirements (e.g., GDPR mandating EU data stays in EU, or Australian Privacy Act requiring data in Australia), the workspace region is the compliance control point.

Design guidelines:

• Deploy the workspace in the same region as the resources it serves to avoid cross-region egress costs.
• For multi-region deployments with sovereignty constraints, use the hybrid topology: a central workspace in the primary region for non-sensitive shared data, plus regional satellite workspaces for data that must not leave the region.
• Document the data flow in an architecture decision record (ADR) that maps each log category to its workspace and region.

Worked Examples

Easy — Single-Subscription Start-up

Problem: Tailwind Traders is a start-up with 1 subscription, 10 Azure resources (App Service, Azure SQL, Key Vault, 3 VMs, 2 Storage accounts, a VNet, and an NSG). They want operational visibility and 90-day log retention. Budget is tight; they ingest approximately 5 GB/day.

Step-by-step solution:

1. Create one centralised Log Analytics workspace in the same region as the resources.
2. Set the SKU to PerGB2018 (pay-as-you-go) — at 5 GB/day they are well under the commitment-tier threshold and may even fall within the free 5 GB/month allowance for some tables.
3. Set retentionInDays: 90.
4. Enable resource-context RBAC (default on new workspaces) so developers can see their own resources' logs.
5. No daily cap needed at this volume — the risk of runaway ingestion is low.

[!NOTE] For a small deployment, a single centralised workspace with pay-as-you-go is almost always the right choice. The overhead of managing multiple workspaces is not justified when ingestion is low and teams are small.

Medium — Multi-Subscription Enterprise with HIPAA

Problem: Fabrikam has 4 subscriptions: Prod-Healthcare, Prod-General, Dev, and Shared-Services. The Healthcare subscription processes PHI subject to HIPAA. Total ingestion is 220 GB/day (150 GB from Prod-General and Shared-Services, 50 GB from Prod-Healthcare, 20 GB from Dev). The security team needs cross-estate visibility but must not access raw PHI in application traces.

Step-by-step solution:

1. Deploy a central workspace (la-central) in Shared-Services with a 200 GB/day commitment tier and 90-day interactive retention. This receives all non-healthcare logs.
2. Deploy a satellite workspace (la-healthcare) in the Prod-Healthcare subscription region with a PerGB2018 tier (50 GB/day is below the 100 GB threshold) and 365-day interactive retention (HIPAA audit requirement) plus 7-year total retention (archive).
3. On la-central, enable resource-context RBAC. Grant the security team Log Analytics Reader at the management-group level — they see all resources' logs in the central workspace.
4. On la-healthcare, apply table-level RBAC: grant the security team access only to SecurityEvent and Syslog tables; deny access to AppTraces (which contains PHI).
5. The security team can run cross-workspace queries from la-central using union workspace('la-healthcare').SecurityEvent to correlate security events across the entire estate.
6. Dev workspace is not needed — Dev logs flow to la-central with resource-context RBAC limiting developer access to their own resources.

[!NOTE] The 200 GB/day commitment tier on the central workspace covers the 170 GB (Prod-General + Shared-Services + Dev). The 30 GB overage beyond commitment is billed at the same commitment effective rate — still cheaper than pay-as-you-go.

Hard — Global SaaS with Sovereign Data Requirements

Problem: Woodgrove Bank operates a global SaaS across 4 regions (East US, West Europe, Southeast Asia, Australia East). Australian regulators require that Australian customer data logs never leave the Australia East region. EU GDPR requires EU log data to stay in West Europe. Total ingestion is 800 GB/day globally. The CISO wants a single Sentinel workspace for security correlation, and the platform team wants cost visibility per region.

Step-by-step solution:

1. Deploy four regional workspaces: la-eastus, la-westeu, la-seasia, la-aueast. Each receives infrastructure and application logs from resources in that region only.
2. Deploy a global Sentinel workspace (la-sentinel-eastus) in East US with a 500 GB/day commitment tier. This workspace receives only security-relevant log categories (not raw application data) from all regions.
3. Configure two diagnostic settings per resource: one sending all logs to the regional workspace, one sending only SecurityEvent, AuditLogs, and SignInLogs to the Sentinel workspace.
4. For Australia East and West Europe, the regional workspace satisfies data-residency requirements because log data physically resides in that Azure region.
5. Set per-table archive policies: AzureDiagnostics archived after 90 days with 5-year total retention; SecurityEvent interactive for 365 days with 7-year total retention.
6. Apply resource tags (Region, CostCenter) to each workspace. Export cost data via Azure Cost Management for per-region chargeback.
7. Configure a daily cap on each regional workspace as a safety net (25% above expected daily volume).

[!NOTE] Security data is intentionally duplicated to the Sentinel workspace. The egress cost from Australia East and West Europe to East US is a conscious trade-off — the CISO has determined that unified security correlation is worth the cross-region data transfer cost.

Visual Explanations

Workspace Topology Decision Tree (Mermaid)

Cost Model Decision Flow (Mermaid)

Retention Tiers Architecture (TikZ)

RBAC Model Comparison Table

Commitment Tier Pricing Summary

Common Mistakes

❌ Myth: "We need a separate workspace for every team to keep their data private." ✅ Reality: Resource-context RBAC lets multiple teams share a single workspace while each team sees only its own resources' logs. You avoid workspace sprawl, hit commitment-tier thresholds faster, and retain the ability to run cross-team correlation queries. Why it's tricky: Workspace-per-team was the recommended pattern before resource-context RBAC existed (pre-2019). Many legacy architectures and older blog posts still advocate it.

❌ Myth: "I set retention to 730 days, so my compliance requirement for 7-year log retention is satisfied." ✅ Reality: 730 days is the maximum interactive retention. For 7 years you must configure the archive tier with a totalRetentionInDays of 2556. Without archive, data is deleted after 730 days. Why it's tricky: The Azure portal shows "Retention" as a single slider up to 730 days. The archive configuration is a separate per-table setting that is easy to overlook.

❌ Myth: "A daily cap protects me from cost overruns with no downside." ✅ Reality: A daily cap stops all ingestion once the threshold is hit — you lose visibility for the remainder of the UTC day. If a security incident triggers a log spike and the cap fires, you are blind exactly when you need logs most. Use the daily cap as a last-resort safety net (set 25%–50% above expected volume), not as a primary cost control. Why it's tricky: The cap sounds like a budget-friendly guardrail, and it is — until you realise it also blocks security-critical events during a surge.

❌ Myth: "Cross-workspace queries are free and unlimited — I can decentralise and still correlate." ✅ Reality: Cross-workspace queries are limited to 5 external workspaces per query, they incur higher latency, and the source workspace's data does not benefit from the querying workspace's commitment tier. Heavy cross-workspace usage erodes the benefits of decentralisation. Why it's tricky: The syntax (workspace('name').TableName) looks simple, but the performance and cost implications are hidden.

Practice Exercises

🟢 Easy — Contoso is a small company with 1 subscription and 15 resources. They need 90-day retention and have no regulatory constraints. Which workspace topology should they choose?

▶💡 Hint

Think about the overhead of managing multiple workspaces versus the benefits at this scale.

▶✅ Solution

A single centralised Log Analytics workspace with PerGB2018 pay-as-you-go pricing and 90-day retention. At this scale, decentralisation adds management overhead with no regulatory benefit.

🟢 Easy — What is the maximum interactive retention period for a Log Analytics workspace?

▶💡 Hint

Interactive retention and archive retention are separate settings.

▶✅ Solution

730 days. Beyond that, you must use the archive tier (up to 12 years total retention).

🟡 Medium — Fabrikam ingests 180 GB/day into a Log Analytics workspace currently on PerGB2018 pay-as-you-go. Which commitment tier should they choose, and approximately how much would they save?

▶💡 Hint

Commitment tiers are 100, 200, 300, 400, 500 GB/day. Overage above the commitment is billed at the commitment-tier effective rate.

▶✅ Solution

Choose the 200 GB/day commitment tier. Even though 20 GB/day of the commitment goes unused, the effective per-GB rate (\approx$ $2.15$) applied to all 180 GB still yields \approx 22$\%$ savings compared to pay-as-you-go ($$\approx$$2.76$/GB). The 100 GB/day tier would leave 80 GB at overage rates, which are still discounted but at a lower tier discount.

🟡 Medium — A security engineer needs to query SecurityEvent logs from 3 different workspaces in a single KQL query. Write the query structure and identify the limitation.

▶💡 Hint

The union operator with the workspace() function can span workspaces. What is the maximum number of external workspaces?

▶✅ Solution

union SecurityEvent, workspace('la-workspace-2').SecurityEvent, workspace('la-workspace-3').SecurityEvent | where EventID == 4625 | summarize count() by bin(TimeGenerated, 1h), Computer

Limitation: a single query can reference at most 5 external workspaces. This query uses 2 external references, which is within the limit.

🔴 Hard — Woodgrove Bank must comply with Australian Privacy Act (data stays in Australia East), EU GDPR (data stays in West Europe), and also needs a global Sentinel workspace for security. Design the workspace topology, including the trade-off for security data.

▶💡 Hint

Security events may need to leave sovereign regions for correlation. How do you handle the sovereignty conflict?

▶✅ Solution

Deploy a hybrid topology with 4 regional workspaces (la-eastus, la-westeu, la-seasia, la-aueast) for full platform and application logs. Deploy a Sentinel workspace in East US for security correlation. Configure a second diagnostic setting on each resource to send only security-relevant categories (SecurityEvent, AuditLogs, SignInLogs) to the Sentinel workspace. For Australia and EU, this intentional cross-region transfer of security data must be documented in a Data Protection Impact Assessment (DPIA) and covered by appropriate legal mechanisms (e.g., Standard Contractual Clauses for EU data). The trade-off: accept the sovereignty exception for security data to gain global threat correlation, while all non-security data remains in-region.

🔴 Hard — An auditor requests proof that all resources in the Prod subscription have their diagnostic settings pointing to the central Log Analytics workspace. What Azure governance mechanism do you use, and what is the policy effect?

▶💡 Hint

You need a corrective control that both detects non-compliance and automatically remediates it.

▶✅ Solution

Assign an Azure Policy with the DeployIfNotExists effect scoped to the Prod subscription. Use the built-in policy definitions (e.g., "Deploy Diagnostic Settings for [resource type] to Log Analytics workspace") grouped into a Policy Initiative. The DeployIfNotExists effect automatically creates the diagnostic setting whenever a covered resource is created or updated without one. Export the Policy Compliance dashboard showing 100% compliance as auditable evidence.

Summary & Concept Map

• The Log Analytics workspace is the gravitational centre of Azure logging — topology (centralised, decentralised, hybrid) is the single most impactful design decision.
• Centralised is the CAF-recommended default; split only when regulatory, sovereignty, or autonomy requirements demand it.
• Resource-context RBAC enables centralisation without sacrificing least-privilege access — users see only their own resources' logs.
• Interactive retention goes up to 730 days; for longer compliance horizons, configure the archive tier (up to 12 years total) with per-table policies.
• Commitment tiers (starting at 100 GB/day) save up to 30% over pay-as-you-go — right-size by monitoring actual ingestion in Azure Advisor.
• Use a daily cap as a safety net, not as a primary cost control — it stops all ingestion and creates blind spots during incidents.
• The workspace region determines data residency — match workspace region to regulatory requirements.