AZ-305: Azure Solutions Architect Expert — Study Guide

Exam Overview#

Domain Weightings#

---

Transcript Summary#

This guide is arranged to match the AZ-305 exam domains and study flow. Each section below translates a topic transcript into:

• a concise summary of the topic,
• key architecture decisions,
• important design trade-offs,
• links to official documentation for deeper study.

Focus on the design rationale behind service selection, governance patterns, resiliency decisions, and hybrid connectivity architecture.

---

AZ-305 Index#

• Domain 1: Identity, Governance, and Monitoring
  • Identity architecture
  • Governance at scale
  • Monitoring architecture
• Domain 2: Data Storage Solutions
  • Storage service selection
  • File and blob storage deep dives
    • Storage accounts deep dive
    • Blob storage deep dive
    • Data security deep dive
    • File storage deep dive
    • File and blob data protection deep dive
    • Migrating file and blob data deep dive
  • Cosmos DB design
  • Data protection
• Domain 3: Business Continuity Solutions
  • Azure SLAs and composite SLA
  • Compute resilience
  • Database business continuity
  • Backup and DR architecture
• Domain 4: Infrastructure Solutions
  • Compute service selection
  • Compute platform deep dives
    • Container technologies in Azure deep dive
    • Choosing container technologies deep dive
    • Container availability and scaling deep dive
  • Virtual machine design deep dives
    • Planning VM deployment deep dive
    • VM availability deep dive
    • Secure VM traffic deep dive
    • VM backup recovery deep dive
    • Azure hybrid backup recovery deep dive
  • Network architecture patterns
    • Cloud network connectivity
    • Hybrid network connectivity
    • Network routing
    • Securing external network traffic
  • Migration architecture
  • Well-Architected Framework review
• Study Plan
• Key Resources

---

Domain 1: Identity, Governance, and Monitoring (25–30%)#

Identity architecture#

AZ-305 identity scenarios test whether you can choose the correct identity model for applications, users, and external partners.

• Single-tenant vs multi-tenant — choose single tenant for internal enterprise solutions and multi-tenant for ISV / SaaS publishers.
• Hybrid identity — Entra Connect is the recommended path to sync on-premises AD with Entra ID.
  • Password Hash Sync: easiest, lowest operational overhead.
  • Pass-through Authentication: on-premises validation for compliance or when plaintext passwords cannot leave network.
  • Federation (AD FS / third-party IdP): necessary when on-premises authentication policies are required.
• Entra ID B2B — partner collaboration without separate guest accounts; use conditional access for external identities.
• Entra External ID (B2C) — customer-facing identity with custom branding, social login, and OAuth/OIDC/SAML support.
• Entitlement Management — use access packages for easy onboarding, governance, and lifecycle automation across cross-tenant and partner users.

Key exam focus:

• compare identity models by security, user experience, and compliance.
• map user types to identity boundary decisions.
• know where Delegated Permissions and App Roles belong in Entra architecture.

Reference docs:

• https://learn.microsoft.com/entra/identity/what-is-microsoft-entra-id
• https://learn.microsoft.com/entra/b2b/what-is-b2b
• https://learn.microsoft.com/entra/b2c/overview
• https://learn.microsoft.com/entra/identity/connectors/entitlement-management

Governance at scale#

Governance is tested as a design trade-off between agility and control.

• Azure Landing Zones — use landing zones to secure and stabilize enterprise-scale Azure with subscription scaffolding.
  • Management subscription for shared platform services (log analytics, security, automation).
  • Platform subscription for identity and connectivity services.
  • Landing zone subscriptions for workloads and application boundaries.
• Management Groups — structure subscriptions into policies and role inheritance.
• Azure Policy — choose policy mode based on resource type and lifecycle.
  • Deny for hard-block rules.
  • Modify for automatic remediation of tags, diagnostics, or naming.
  • DeployIfNotExists for auto-deploying diagnostic settings and monitoring agents.
• Tagging and naming — enforce tags for cost center, owner, environment, and workload.
• Role-based access control — define least-privilege roles and separate identity from workload permissions.

Key exam focus:

• pick the appropriate governance tool for large scale (Policy, Blueprint, Management Groups).
• balance central policy enforcement with delegated subscription autonomy.
• design naming and tagging conventions that support both cost reporting and security.

Reference docs:

• https://learn.microsoft.com/azure/cloud-adoption-framework/strategy/landing-zones
• https://learn.microsoft.com/azure/governance/management-groups/overview
• https://learn.microsoft.com/azure/governance/policy/overview
• https://learn.microsoft.com/azure/role-based-access-control/overview

Monitoring architecture#

Monitoring design is about visibility, operational readiness, and incident response.

• Centralised Log Analytics — collect logs from multiple subscriptions into a central workspace for cross-resource querying.
• Azure Monitor — use metrics, alerts, autoscale rules, and dashboards for operational view.
• Application Insights — instrument applications for request, exception, dependency, and performance telemetry.
• Diagnostic settings at scale — deploy with Policy or ARM/Bicep to ensure all resources send logs and metrics to Log Analytics or storage.
• Alert strategy — build actionable alert rules with dynamic thresholds, smart detection, and ticketing integration.

Key exam focus:

• define the monitoring architecture for applications and platform resources.
• decide between per-resource vs central monitoring workspace patterns.
• include automation for diagnostic settings and alert remediation.

Reference docs:

• https://learn.microsoft.com/azure/azure-monitor/overview
• https://learn.microsoft.com/azure/azure-monitor/logs/log-analytics-overview
• https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview
• https://learn.microsoft.com/azure/azure-monitor/essentials/diagnostic-settings

---

Domain 2: Data Storage Solutions (15–20%)#

Storage service selection#

AZ-305 storage design questions expect you to select the right managed service for each workload requirement.

• Azure Blob Storage — best for unstructured data, archive, backup, analytics.
• Azure Files — ideal for lift-and-shift file shares, SMB/NFS access, and serverless lift-and-shift applications.
• Azure SQL Database / Managed Instance — choose single-tenant PaaS for cloud-native SQL, or Managed Instance for compatibility and migration ease.
• Azure Database for PostgreSQL / MySQL — managed relational databases for open-source workloads.
• Azure Cosmos DB — globally distributed NoSQL with multi-region writes and tunable consistency.
• Azure Synapse Analytics — modern cloud DW for analytics, data integration, and serverless SQL.
• Azure Data Explorer — time-series and log analytics workloads requiring fast ingestion and querying.
• Queue storage vs Service Bus — use Queue Storage for simple task processing and Service Bus for enterprise messaging with ordered delivery, sessions, or pub/sub.
• Event Hubs — event ingestion for streaming analytics and telemetry.

Decision criteria:

• SLA and consistency needs.
• throughput and scale.
• managed vs self-managed complexity.
• data residency and compliance.

Reference docs:

• https://learn.microsoft.com/azure/storage/blobs/storage-blobs-introduction
• https://learn.microsoft.com/azure/storage/files/storage-files-introduction
• https://learn.microsoft.com/azure/sql-database/sql-database-overview
• https://learn.microsoft.com/azure/cosmos-db/introduction
• https://learn.microsoft.com/azure/synapse-analytics/overview-what-is
• https://learn.microsoft.com/azure/event-hubs/event-hubs-about

File and blob storage deep dives#

---

Storage accounts deep dive

Azure Storage Accounts — Review Notes and In-Depth Guide

1. What is an Azure Storage Account?

An Azure Storage account is the top-level Azure resource that provides a unique namespace and configuration boundary for Azure Storage services.

A storage account can contain services such as:

• Blob Storage
• Azure Files
• Queue Storage
• Table Storage
• Azure Data Lake Storage Gen2

The account controls common settings including:

• Region
• Performance tier
• Redundancy
• Networking
• Authentication
• Encryption
• Data protection
• Lifecycle management

A typical storage endpoint follows this pattern:

https://<storage-account-name>.blob.core.windows.net

The storage account name must be globally unique because it forms part of its public DNS namespace. (Microsoft Learn)

---

2. Types of Data

Structured data

Structured data follows a predefined schema, usually rows and columns.

Examples:

• Relational databases
• Customer tables
• Financial transaction records
• Inventory databases

Typical Azure services include Azure SQL Database and Azure Database services.

---

Semi-structured data

Semi-structured data does not follow a rigid relational schema but contains tags, keys, or metadata that describe its structure.

Examples:

• JSON
• XML
• Event messages
• Application telemetry
• NoSQL documents

Possible Azure services include:

• Azure Cosmos DB
• Azure Table Storage
• Blob Storage containing JSON or XML

---

Unstructured data

Unstructured data has no fixed tabular schema.

Examples:

• Images
• Videos
• Audio
• PDF documents
• Backups
• Log files
• Emails
• Office documents

Azure Blob Storage is optimized for storing large amounts of unstructured text and binary data. (Microsoft Learn)

---

3. Main Storage Account Types

Standard general-purpose v2

General-purpose v2, commonly written as StorageV2 or GPv2, is the default account type for most scenarios.

It supports:

• Blob Storage
• Azure Data Lake Storage Gen2
• Azure Files
• Queue Storage
• Table Storage

Typical use cases:

• Application files
• Documents and media
• Data lakes
• File shares
• Messaging queues
• NoSQL key-value data
• Backup and archival data

For most new deployments, begin by evaluating a GPv2 account unless a specific premium workload requires another account type. (Microsoft Learn)

---

Premium block blob account

A premium block blob account provides low-latency, high-transaction-rate storage for:

• Block blobs
• Append blobs
• Data Lake Storage workloads supported by the account

Suitable examples include:

• Applications performing many small transactions
• Interactive analytics
• High-rate data ingestion
• IoT telemetry
• Frequently updated operational data
• Low-latency object storage

Premium storage normally costs more per unit of capacity but can provide more consistent latency and transaction performance.

---

Premium file share account

A premium file share account is optimized specifically for Azure Files.

It can support enterprise file-sharing scenarios using protocols such as:

• SMB
• NFS, where supported by the selected configuration

Typical use cases:

• Enterprise application file shares
• Profile containers
• High-performance shared application data
• Database-related file workloads
• Large numbers of concurrent file operations

Premium file shares are provisioned according to performance and capacity requirements, so they should be used when standard file shares cannot meet required IOPS, throughput, or latency.

---

Premium page blob account

Premium page blob accounts support page blobs, which are optimized for frequent random read and write operations.

Typical uses include:

• Virtual hard disks
• Index-based data
• Sparse data structures
• Certain database workloads

Azure page blobs are divided into addressable pages and are designed for random-access workloads. Block blobs, by comparison, are optimized for sequential object upload and download. (Microsoft Learn)

---

4. Azure Storage Services

Blob Storage

Blob Storage is Azure's object-storage service.

Common uses:

• Images and videos
• Documents
• Backups
• Application assets
• Log files
• Data lake content
• Static website files

Blob types

---

Azure Files

Azure Files provides managed cloud file shares accessible through file-sharing protocols.

Common scenarios:

• Migrating traditional file servers
• Shared application configuration
• Lift-and-shift applications
• User profile storage
• Hybrid file services with Azure File Sync

Azure Files is appropriate when applications expect a mounted file system rather than object-storage APIs.

---

Queue Storage

Queue Storage provides asynchronous message queues.

Example:

Web application
      ↓
Azure Queue
      ↓
Background worker

Common uses:

• Decoupling application components
• Background processing
• Work queues
• Basic event-driven architectures

Queue Storage is not the same as Azure Service Bus. Service Bus provides more advanced enterprise messaging features such as topics, subscriptions, sessions, transactions, and dead-letter queues.

---

Table Storage

Table Storage is a schema-flexible NoSQL key-value service.

Common uses:

• Device metadata
• User preference data
• Simple application records
• Large datasets requiring inexpensive key-based lookup

It is not a relational database and does not provide SQL-style joins or foreign-key relationships.

---

Azure Data Lake Storage Gen2

Data Lake Storage Gen2 adds a hierarchical namespace to Blob Storage.

This provides:

• Directory and file semantics
• Efficient directory operations
• Fine-grained access control
• Compatibility with analytics engines
• Integration with services such as Azure Databricks, Azure Synapse Analytics and Microsoft Fabric

A Data Lake Storage Gen2 account is generally a GPv2 or supported premium block blob account with hierarchical namespace enabled.

Enabling hierarchical namespace is an architectural decision. Confirm service compatibility and workload requirements before enabling it.

---

5. Access Tiers

Access tiers optimize Blob Storage cost according to how frequently data is accessed.

Hot tier

Designed for data accessed or modified frequently.

Characteristics:

• Highest storage cost
• Lowest access and transaction costs
• Immediate online access

Examples:

• Active website content
• Frequently accessed documents
• Current application data
• Active media editing files

---

Cool tier

Designed for infrequently accessed data that must remain immediately available.

Characteristics:

• Lower storage cost than Hot
• Higher retrieval and transaction costs
• Recommended minimum retention of 30 days

Examples:

• Short-term backups
• Older project files
• Disaster-recovery copies
• Infrequently accessed business records

---

Cold tier

Designed for rarely accessed data that still requires online, near-immediate retrieval.

Characteristics:

• Lower storage cost than Cool
• Higher retrieval cost
• Recommended minimum retention of 90 days
• Data remains online

Examples:

• Older backups that may need rapid recovery
• Compliance data with occasional access
• Historical operational data

---

Archive tier

Designed for data that is almost never accessed and can tolerate retrieval delays.

Characteristics:

• Lowest storage cost
• Highest retrieval cost
• Offline storage
• Rehydration is required before normal reading
• Retrieval latency can be measured in hours
• Recommended minimum retention of 180 days

Examples:

• Long-term legal records
• Historical media masters
• Old backups
• Regulatory archives

Current Azure Blob tiers are Hot, Cool, Cold and Archive. Hot, Cool and Cold are online tiers; Archive is offline. (Microsoft Learn)

---

Access-tier comparison

Early deletion charges may apply when an object is deleted or moved before its minimum retention period.

Access tiers primarily apply to eligible block blob data. They should not be treated as a universal setting that behaves identically across Azure Files, queues, tables and page blobs.

---

6. Performance Tiers

Standard performance

Standard storage uses cost-optimized underlying media and is suitable for most workloads.

Use it for:

• General files
• Backups
• Media
• Documents
• Data lakes
• Standard file shares
• Queue and Table Storage

---

Premium performance

Premium storage is designed for workloads requiring:

• Low latency
• High transaction rates
• Predictable performance
• High IOPS
• High throughput

Use premium only when performance measurements or workload requirements justify it.

A common design error is selecting Premium merely because the workload is important. Business criticality alone does not prove that Premium performance is required.

Measure:

• IOPS
• Throughput
• Transaction rate
• Object size
• Read/write pattern
• Latency requirements
• Concurrent connections

---

7. Storage Redundancy

Azure Storage redundancy protects data against hardware, datacenter, zone, or regional failures.

LRS — Locally Redundant Storage

LRS stores multiple synchronous copies of data within a single physical location in the primary region.

Protects against:

• Disk failures
• Server failures
• Rack-level failures

Does not protect against:

• Datacenter-wide failure
• Availability-zone failure
• Regional outage

Best for:

• Re-creatable data
• Temporary processing data
• Cost-sensitive noncritical workloads

---

ZRS — Zone-Redundant Storage

ZRS synchronously replicates data across multiple availability zones in the primary region.

Protects against:

• Hardware failure
• Datacenter failure
• Availability-zone failure

Best for:

• Production applications requiring regional availability
• Analytics workloads
• Business-critical data that does not require cross-region replication

ZRS refers to availability zones within an Azure region. The transcript's description of a zone as “East US or Central US” is incorrect—those are regions, not availability zones.

---

GRS — Geo-Redundant Storage

GRS keeps synchronous copies in the primary region and asynchronously replicates data to a paired secondary region.

Protects against:

• Local hardware failure
• Primary-region disaster

Important:

• Secondary-region data is not normally readable until a failover occurs.
• Because geo-replication is asynchronous, a major primary-region failure may result in some recent writes not yet being copied to the secondary region.

---

RA-GRS — Read-Access Geo-Redundant Storage

RA-GRS provides the same replication model as GRS but permits read access to the secondary endpoint before failover.

Use it when an application can use stale-but-readable secondary data during a primary-region disruption.

---

GZRS — Geo-Zone-Redundant Storage

GZRS combines:

• Synchronous replication across availability zones in the primary region
• Asynchronous replication to a secondary region

It protects against both zonal and regional failure.

---

RA-GZRS — Read-Access Geo-Zone-Redundant Storage

RA-GZRS adds continuous read access to the secondary region.

It provides one of the strongest Azure Storage redundancy options, but it has higher cost and requires application logic if the secondary read endpoint will be used.

Azure currently supports LRS, ZRS, GRS, RA-GRS, GZRS and RA-GZRS, depending on the storage service, account type and region. (Microsoft Learn)

---

Redundancy decision table

Redundancy is not the same as backup. Replication can also replicate deletion, corruption or unwanted modification. Use backup, versioning, soft delete, immutability or point-in-time restore where required.

---

8. Authentication and Authorization

Azure Storage supports several authorization mechanisms.

Microsoft Entra ID and Azure RBAC

This is the preferred method for many modern applications.

Examples of data-plane roles include:

• Storage Blob Data Reader
• Storage Blob Data Contributor
• Storage Queue Data Contributor
• Storage File Data SMB Share Contributor

Benefits:

• No permanent credentials in application code
• Supports managed identities
• Granular permissions
• Central identity lifecycle management
• Auditable role assignments

Microsoft recommends Microsoft Entra ID and managed identities over Shared Key authorization where supported. (Microsoft Learn)

---

Managed identities

An Azure resource such as an application, function or virtual machine can receive a managed identity and use it to access Storage.

Application
   ↓ managed identity
Microsoft Entra ID
   ↓ OAuth token
Storage account

No storage key or password needs to be stored in application configuration.

---

Shared access signatures

A Shared Access Signature, or SAS, grants delegated access to specific storage resources.

A SAS can restrict:

• Resource
• Permissions
• Start time
• Expiry time
• Allowed IP range
• Allowed protocol

Example:

Allow read access
to one blob container
for 30 minutes
over HTTPS only

Where supported, prefer a user delegation SAS backed by Microsoft Entra credentials over a SAS signed directly with an account key. (Microsoft Learn)

---

Storage account access keys

Each storage account has Shared Key credentials with broad access.

Risks:

• Long-lived secret
• Large blast radius
• Difficult attribution when shared
• Applications may retain old keys

Use them only when required, protect them in Azure Key Vault, rotate them, and consider disabling Shared Key authorization after verifying application compatibility. (Microsoft Learn)

---

9. Encryption

Encryption at rest

Azure Storage encrypts data before it is persisted.

Key options include:

• Microsoft-managed keys
• Customer-managed keys stored in Azure Key Vault or Managed HSM
• Infrastructure encryption for qualifying requirements

Customer-managed keys are useful when an organization requires:

• Control of key rotation
• Key revocation
• Separation of duties
• Regulatory control over encryption keys

---

Encryption in transit

Storage clients should use HTTPS/TLS to protect data moving between applications and Azure Storage.

Recommended controls:

• Require secure transfer
• Disable insecure protocols where possible
• Use recent TLS versions
• Use SMB encryption for relevant Azure Files scenarios

Azure Key Vault usually protects customer-managed encryption keys. It does not directly perform every data-in-transit encryption operation.

---

10. Network Security

Storage firewall

The storage firewall can restrict public endpoint access to:

• Selected public IP ranges
• Selected virtual networks
• Trusted service exceptions where explicitly configured

Avoid enabling broad public network access unless the workload requires it.

---

Service endpoints

A service endpoint extends a subnet's identity to an Azure service over the Microsoft backbone.

Characteristics:

• The storage account still uses its public endpoint.
• Access can be restricted to selected VNets and subnets.
• It is relatively simple to configure.
• DNS normally continues to resolve the public service address.

---

Private endpoints and Private Link

A private endpoint places a private IP address from your VNet onto a specific storage service endpoint.

Application subnet
      ↓
Private endpoint: 10.20.1.5
      ↓
Azure Private Link
      ↓
Storage account

Benefits:

• Private IP-based access
• Traffic remains on the Microsoft backbone
• Public Internet exposure can be disabled
• Accessible from peered VNets and connected on-premises networks with proper routing and DNS

Each storage subservice may require its own private endpoint—for example blob, file, queue, table or Data Lake DFS. Private DNS design is critical. (Microsoft Learn)

---

Service endpoint vs private endpoint

For highly sensitive workloads, private endpoints are generally the stronger design.

---

11. Data Protection Features

Redundancy protects infrastructure availability, while data protection features protect against accidental or malicious changes.

Consider:

• Blob soft delete
• Container soft delete
• File share soft delete
• Blob versioning
• Point-in-time restore
• Change feed
• Snapshots
• Immutable storage
• Legal holds
• Azure Backup where supported

Immutable storage

Immutable storage can enforce write-once, read-many behavior.

Useful for:

• Financial records
• Audit data
• Legal evidence
• Regulatory retention
• Ransomware resistance

Policies may be time-based or configured with legal holds.

---

12. Lifecycle Management

Blob lifecycle management uses rules to:

• Move data from Hot to Cool
• Move data from Cool to Cold
• Move eligible data to Archive
• Delete expired blobs
• Delete old versions
• Delete obsolete snapshots

Example policy:

After 30 days  → Cool
After 90 days  → Cold
After 365 days → Archive
After 7 years  → Delete

Lifecycle policies should reflect business retention requirements, legal obligations, retrieval expectations and minimum tier durations.

Azure also offers automated tiering capabilities for eligible Blob Storage scenarios, but feature availability and cost behavior should be verified for the selected account and region. (Microsoft Learn)

---

13. Cost Components

Azure Storage cost is not just the price per GB.

Evaluate:

Total cost =
capacity cost
+ transaction cost
+ retrieval cost
+ data transfer cost
+ replication cost
+ security/networking services
+ backup and monitoring cost

Important cost drivers:

• Stored capacity
• Access tier
• Read and write operations
• List operations
• Early deletion charges
• Rehydration from Archive
• Geo-replication
• Internet egress
• Private endpoint charges
• Premium provisioned capacity
• Backup retention
• Log ingestion

A cheap storage tier can become expensive if the data is retrieved frequently.

---

14. Scenario 1 — Migrating 500 TB of File Shares

Requirements

• 500 TB from on-premises
• Multiple global offices
• Infrequently accessed reference data
• File-system access required

Possible architecture

Global offices
      ↓
Azure Files
      ↓
Azure File Sync or direct SMB access

Design decisions:

• Standard Azure file shares when performance requirements permit
• Premium file shares if IOPS, throughput or latency requires them
• Appropriate redundancy based on recovery objectives
• Private endpoints for private access
• VPN or ExpressRoute for hybrid connectivity
• Azure File Sync for local caching
• Azure Data Box for initial bulk transfer if WAN migration is impractical

Correction to the transcript

Selecting “cool access” for Azure Files is not identical to selecting a Blob Storage access tier. Azure Files has its own share tiers, pricing models and protocol considerations. Verify the available Azure Files tiers for the selected account type and region rather than directly applying Blob Hot/Cool/Cold/Archive terminology.

Also, 500 TB of global file data requires more than a storage-tier choice. Assess:

• Per-share and per-account limits
• Namespace design
• File count
• Metadata and ACL migration
• SMB/NFS compatibility
• Network throughput
• Caching requirements
• Data transfer duration
• Regional latency
• Backup
• Disaster recovery

---

15. Scenario 2 — One Petabyte of Video Content

Requirements

• Frequently accessed during editing
• Rarely accessed after completion
• Expected growth to 1 PB
• Long-term retention

Possible design

Active media
   ↓ Hot tier

Completed projects
   ↓ Cool or Cold

Long-term masters
   ↓ Archive

Recommended components:

• GPv2 Blob Storage
• Hot tier for active editing assets
• Lifecycle rules to move completed projects
• Archive for long-term preservation where retrieval delays are acceptable
• Object replication or geo-redundancy if regional recovery is required
• Private endpoints for internal production systems
• Microsoft Entra ID and managed identities
• Versioning or immutability for valuable masters
• Azure CDN or Front Door if content is distributed publicly

Redundancy consideration

LRS may be appropriate only when the source data can be recreated or another authoritative copy exists. For unique media masters, ZRS, GRS or GZRS may be more appropriate depending on availability and disaster-recovery requirements.

Also note that Archive tier has redundancy compatibility restrictions; for example, it is not currently supported with ZRS, GZRS or RA-GZRS accounts. (Microsoft Learn)

---

16. Design Checklist

Before selecting a storage solution, answer these questions.

Workload

• Is the data structured, semi-structured or unstructured?
• Does the application need object, file, queue or key-value access?
• What protocols and APIs are required?
• Does it require hierarchical namespace?

Performance

• Required IOPS?
• Required throughput?
• Maximum acceptable latency?
• Object or file size distribution?
• Read-heavy or write-heavy?
• Number of simultaneous clients?

Availability and recovery

• Required SLA?
• Can the workload survive a zone failure?
• Must it survive a regional failure?
• What are the required RPO and RTO?
• Does the application support secondary-endpoint reads?

Security

• Can Microsoft Entra ID and managed identities be used?
• Can Shared Key be disabled?
• Is a private endpoint required?
• Is public network access necessary?
• Are customer-managed encryption keys required?
• Is immutable retention required?

Cost

• How often is the data read?
• How long must it be retained?
• Are retrieval delays acceptable?
• Will data frequently move between tiers?
• What are the expected transaction and egress volumes?

Governance

• Which Azure regions are allowed?
• Are there residency requirements?
• Are lifecycle and retention policies documented?
• Are diagnostic logs and alerts enabled?
• Are naming, tagging and policy controls applied?

---

17. Quick Decision Matrix

---

18. Important Corrections and Clarifications

1. Availability zones are not Azure regions. East US and Sweden Central are regions; each region may contain multiple availability zones.

2. GRS does not automatically mean that applications can read the secondary copy. Continuous secondary read access requires RA-GRS or RA-GZRS.

3. Redundancy does not replace backup. Replication can reproduce accidental deletion or corruption.

4. Access tiers mainly concern eligible Blob Storage data. They do not apply uniformly to every storage service.

5. Archive is offline. Objects must be rehydrated before normal access.

6. Azure Key Vault primarily protects customer-managed keys and secrets. It is not the mechanism that encrypts every network connection.

7. Premium should be selected from measured performance requirements, not solely because the workload is production or mission-critical.

8. Managed disks normally use Azure Managed Disk resources. Although their underlying technology relates to page blobs, architects generally should not design modern VM disks as manually managed page blobs unless a specific legacy scenario requires it.

---

19. AZ-305 Exam Review

Remember these associations:

• GPv2 → Default account type for most new storage scenarios.
• Blob Storage → Massive-scale unstructured object storage.
• Azure Files → Managed SMB/NFS-style file shares.
• Data Lake Storage Gen2 → Blob Storage with hierarchical namespace for analytics.
• Hot/Cool/Cold → Online Blob Storage tiers.
• Archive → Lowest-cost offline tier with rehydration delay.
• LRS → Copies within one primary location.
• ZRS → Copies across availability zones in one region.
• GRS → Asynchronous copy to a secondary region.
• RA-GRS → Read access to the secondary region.
• GZRS → Zone resilience plus geo-replication.
• Microsoft Entra ID + managed identity → Preferred authorization model.
• SAS → Time-limited delegated access.
• Private Endpoint → Private IP connectivity to an individual storage service.
• Lifecycle management → Automatic tier transitions and deletion.
• Immutability → Write-once, read-many retention and legal hold.

---

Microsoft Reference Documentation

• Storage account overview and account types. (Microsoft Learn)
• Introduction to Azure Blob Storage. (Microsoft Learn)
• Blob Storage access tiers. (Microsoft Learn)
• Azure Storage redundancy. (Microsoft Learn)
• Azure Files redundancy. (Microsoft Learn)
• Azure Storage authorization methods. (Microsoft Learn)
• Microsoft Entra authorization for Blob Storage. (Microsoft Learn)
• Shared access signatures. (Microsoft Learn)
• Preventing Shared Key authorization. (Microsoft Learn)
• Azure Storage private endpoints. (Microsoft Learn)
• Page blob concepts. (Microsoft Learn)
• Archive cost and retrieval considerations. (Microsoft Learn)

---

Blob storage deep dive

Azure Blob Storage — Review Notes and In-Depth Guide

1. What is Azure Blob Storage?

Azure Blob Storage is Azure’s massively scalable object-storage service for storing unstructured text and binary data.

Typical examples include:

• Images and videos
• Documents and PDFs
• Application files
• Backups
• Log files
• Data lake content
• Machine-learning datasets
• Static website assets
• Software installation packages

Blob Storage is normally accessed using:

• HTTPS-based REST APIs
• Azure SDKs
• Azure CLI or PowerShell
• AzCopy
• Storage Explorer
• Azure portal

HTTPS should be used for all production communication. Azure Storage accounts can be configured to require secure transfer, which rejects requests made over unencrypted HTTP.

---

2. Blob Storage Hierarchy

Blob Storage uses the following logical hierarchy:

Storage account
    └── Blob service
          └── Container
                └── Blob

Storage account

The top-level Azure resource that provides:

• A globally unique namespace
• Authentication and authorization settings
• Networking configuration
• Encryption settings
• Redundancy
• Monitoring
• Data-protection settings

Example endpoint:

https://storageaccountname.blob.core.windows.net

Container

A container organizes related blobs.

Examples:

images
backups
application-logs
customer-documents

A container is similar to a bucket in other object-storage platforms. Containers are flat object namespaces, although blob names containing / characters can appear as virtual folders.

Blob

A blob is the individual object stored inside the container.

Examples:

images/product-1001.jpg
logs/2026/07/22/application.log
backups/database-full.bak

---

3. Blob Types

Azure supports three principal blob types:

1. Block blobs
2. Append blobs
3. Page blobs

The blob type is selected when the blob is created. Each type has a different update model and is optimized for different workloads.

---

A. Block blobs

Block blobs are the most commonly used blob type.

They are optimized for storing and efficiently uploading large text or binary objects.

Typical uses:

• Images
• Videos
• Documents
• Application packages
• Backups
• Data lake files
• Machine-learning datasets
• Static website content

A block blob is uploaded as one or more blocks. Blocks can be uploaded independently and then committed as a complete object.

File
 ├── Block 1
 ├── Block 2
 ├── Block 3
 └── Block 4
       ↓
Committed block blob

This model supports:

• Parallel uploads
• Retrying failed blocks
• Efficient upload of large files
• Updating selected blocks before committing

Block blobs can currently store objects up to approximately 190.7 TiB, subject to API version and block-size limits.

Best suited for

• General-purpose object storage
• Backup and archive data
• Media content
• Data lake workloads
• Large file upload and download
• Content distribution

---

B. Append blobs

Append blobs are composed of blocks but are optimized for operations that add data only to the end of the object.

Existing log
    +
New log entry
    +
New log entry

Existing committed blocks are not normally modified in place.

Typical uses:

• Application logging
• Audit trails
• Diagnostic output
• Telemetry streams
• Append-only event records

An append blob is appropriate when data is written sequentially and earlier data should remain unchanged.

---

C. Page blobs

Page blobs are optimized for frequent, random read and write operations.

They are divided into addressable 512-byte pages and can support sparse data structures. Page blobs currently support sizes of up to 8 TiB.

Typical uses:

• Virtual hard disk files
• Random-access data
• Index-based data structures
• Certain database workloads
• Legacy unmanaged Azure VM disks

Page blob
 ├── Page 1
 ├── Page 2
 ├── Page 3
 └── Page n

For modern Azure virtual machines, Azure Managed Disks are normally preferred over manually managing page blobs.

---

Blob type comparison

---

4. Storage Account Types for Blob Storage

General-purpose v2

A general-purpose v2, or GPv2, storage account is the standard choice for most Blob Storage workloads.

It supports:

• Block blobs
• Append blobs
• Page blobs
• Azure Files
• Queue Storage
• Table Storage
• Data Lake Storage Gen2 when hierarchical namespace is enabled

GPv2 should normally be the initial choice unless the application requires a specialized premium account.

---

Premium block blob account

Premium block blob accounts use higher-performance storage and are designed for workloads requiring:

• Consistently low latency
• High transaction rates
• High request volumes
• Large numbers of smaller objects
• Predictable performance

They support block and append blob workloads and can also support applicable Data Lake Storage scenarios.

Typical examples:

• Interactive analytics
• High-rate telemetry ingestion
• Artificial-intelligence training pipelines
• Transaction-intensive content systems
• Low-latency operational datasets

Premium should be selected based on measured latency, IOPS and transaction requirements—not only because the data is business-critical.

---

Premium page blob account

Premium page blob accounts provide high-performance page blob storage.

Typical uses:

• Random read/write workloads
• VHD-based systems
• Legacy storage architectures
• Specialized database or index workloads

---

5. Blob Access Tiers

Blob access tiers allow cost optimization according to how frequently data is read or modified.

The current primary tiers are:

• Hot
• Cool
• Cold
• Archive

Hot, Cool and Cold are online tiers. Archive is an offline tier that requires rehydration before normal access.

---

Hot tier

Designed for data accessed or modified frequently.

Characteristics:

• Highest capacity cost
• Lowest access and transaction costs
• Immediate retrieval
• No minimum recommended retention period

Examples:

• Active website content
• Frequently used documents
• Current application data
• Video files being actively edited
• Recently generated logs

---

Cool tier

Designed for infrequently accessed data that must remain immediately available.

Characteristics:

• Lower storage cost than Hot
• Higher transaction and retrieval cost
• Online access
• Recommended minimum retention of 30 days

Examples:

• Short-term backups
• Older application content
• Infrequently viewed reports
• Disaster-recovery files

---

Cold tier

Designed for rarely accessed data that still needs fast online retrieval.

Characteristics:

• Lower capacity cost than Cool
• Higher access cost
• Online access
• Recommended minimum retention of 90 days

Examples:

• Historical records
• Older backups
• Compliance data that might require rapid retrieval
• Completed projects with occasional access

---

Archive tier

Designed for data that is almost never accessed.

Characteristics:

• Lowest storage cost
• Highest retrieval and transaction cost
• Offline
• Must be rehydrated before reading
• Retrieval can take hours
• Recommended minimum retention of 180 days

Examples:

• Long-term regulatory records
• Historical media masters
• Long-term backups
• Legal evidence
• Scientific datasets retained for future research

Archive storage provides very low capacity cost, but retrieval latency and retrieval charges must be considered.

---

Access-tier comparison

Deleting or moving data before the recommended minimum period may produce early-deletion charges.

---

6. Performance Tiers

Standard performance

Standard performance is suitable for most general-purpose object-storage workloads.

Use it for:

• Backups
• Media
• Documents
• Data lakes
• Logs
• General application files

Premium performance

Premium provides lower latency and higher transaction performance.

Use it when the workload has validated requirements for:

• High IOPS
• High request rates
• Consistently low latency
• High transaction density
• Large numbers of smaller objects

Do not confuse an access tier with a performance tier.

Access tier:
Hot / Cool / Cold / Archive

Performance tier:
Standard / Premium

The access tier controls the cost model based on data usage. The performance tier controls the underlying performance characteristics.

---

7. Authentication and Authorization

Blob Storage supports several authorization mechanisms.

Microsoft Entra ID and Azure RBAC

Microsoft Entra ID is the preferred authorization model for most modern applications.

Common roles include:

• Storage Blob Data Reader
• Storage Blob Data Contributor
• Storage Blob Data Owner

Applications can use managed identities to obtain OAuth tokens without storing permanent secrets.

Application
    ↓ Managed identity
Microsoft Entra ID
    ↓ Access token
Blob Storage

This provides:

• Central identity management
• Granular permissions
• Credential-free application authentication
• Better auditability
• Easier access revocation

---

Shared access signatures

A Shared Access Signature, or SAS, provides limited delegated access to Blob Storage.

A SAS can restrict:

• Container or blob
• Read, write, delete or list permissions
• Start and expiry time
• Allowed source IP
• HTTPS-only access

Example:

Allow read access
to one blob
for 20 minutes
from a specified IP
using HTTPS only

A user-delegation SAS backed by Microsoft Entra ID is generally preferable to a SAS signed using a storage account key.

---

Storage account keys

Storage account keys provide broad access through Shared Key authorization.

Risks include:

• Large access scope
• Long-lived credentials
• Difficult user attribution
• Credential leakage
• Complex rotation

Use account keys only when required. Store them securely, rotate them and consider disabling Shared Key access where applications support Microsoft Entra authorization.

---

Anonymous public access

Containers and blobs can support anonymous access when explicitly enabled, but this should be avoided unless the content is intentionally public.

Public content scenarios may include:

• Public website images
• Public documentation downloads
• Open datasets

For controlled distribution, consider:

• SAS tokens
• Azure Front Door
• Azure CDN
• Application-level authorization

---

8. Encryption and Secure Transfer

Encryption at rest

Blob data is encrypted before being written to physical storage.

Options include:

• Microsoft-managed keys
• Customer-managed keys in Azure Key Vault or Managed HSM
• Infrastructure encryption where supported
• Encryption scopes for separating key usage within an account

Customer-managed keys are useful when organizations require:

• Control over key rotation
• Key revocation
• Separation of duties
• Regulatory control
• Independent key lifecycle management

---

Encryption in transit

Use HTTPS and recent TLS versions for data travelling between applications and Blob Storage.

Recommended settings include:

• Require secure transfer
• Set an appropriate minimum TLS version
• Disable unused authentication methods
• Avoid transmitting account keys in URLs or source code

---

9. Networking and Private Access

Storage firewall

A storage account firewall can restrict public endpoint access to:

• Specific public IP addresses
• Selected virtual networks
• Approved trusted services
• Explicit resource instances where supported

---

Service endpoints

A service endpoint allows a VNet subnet to access Blob Storage through its public service endpoint while identifying the traffic as originating from an approved subnet.

Characteristics:

• Traffic travels over the Microsoft backbone
• The Blob endpoint remains public
• Storage firewall rules can allow the selected subnet
• DNS generally continues to resolve the public address

---

Private endpoints

A private endpoint assigns a private IP address from a VNet to the Blob service.

Application subnet
      ↓
Private endpoint: 10.10.1.10
      ↓
Azure Private Link
      ↓
Blob Storage

Benefits:

• Private IP connectivity
• Public access can be disabled
• Access from peered VNets
• Access from on-premises through VPN or ExpressRoute
• Reduced Internet exposure

Private DNS configuration is essential. For Data Lake Storage Gen2, both blob and dfs private endpoints may be required depending on the workload.

---

10. Reliability and Redundancy

Blob Storage inherits the redundancy configuration of the storage account.

Current options include:

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

---

LRS — Locally Redundant Storage

Stores multiple synchronous copies within one primary physical location.

Protects against:

• Disk failure
• Server failure
• Rack failure

Does not protect against a complete availability-zone or regional failure.

---

ZRS — Zone-Redundant Storage

Replicates synchronously across availability zones in the primary Azure region.

Protects against:

• Datacenter failure
• Availability-zone failure

Best suited to production workloads requiring resilience within a region.

---

GRS — Geo-Redundant Storage

Maintains copies in the primary region and asynchronously replicates data to a secondary region.

Important considerations:

• Secondary data is not normally readable before failover.
• Recent writes may not yet exist in the secondary region during a sudden regional failure.
• Geo-replication provides regional durability but does not replace application-level recovery planning.

---

RA-GRS — Read-Access Geo-Redundant Storage

Adds read access to the secondary region before failover.

Applications can use the secondary endpoint when eventual consistency and potentially stale data are acceptable.

---

GZRS — Geo-Zone-Redundant Storage

Combines:

• Zone redundancy in the primary region
• Asynchronous replication to a secondary region

This protects against both zone-level and regional failures.

---

RA-GZRS — Read-Access Geo-Zone-Redundant Storage

Adds continuous read access to the secondary copy.

The transcript uses “RA-ZGRS.” The correct current abbreviation is RA-GZRS.

---

Important distinction

Redundancy is not the same as backup.

If an application deletes or corrupts a blob, that change may also be replicated. Combine redundancy with:

• Soft delete
• Versioning
• Point-in-time restore
• Immutable storage
• Operational or vaulted backup where required

---

11. Blob Lifecycle Management

Lifecycle management automatically performs actions based on object age, tier, prefix or blob index tags.

Typical actions include:

• Move blobs to Cool
• Move blobs to Cold
• Move blobs to Archive
• Delete old blobs
• Delete previous versions
• Delete old snapshots

---

Example lifecycle policy

After 30 days:
    Move to Cool

After 90 days:
    Move to Cold

After 365 days:
    Move to Archive

After 7 years:
    Delete

Lifecycle management reduces cost by aligning storage tier with access patterns.

---

Rule filters

Rules can be filtered using:

Blob type

Example:

Apply only to block blobs

Prefix match

Example:

logs/
backups/
media/completed/

Blob index tags

Example:

Classification = Archive
ProjectStatus = Completed
Retention = SevenYears

Blob index tags provide searchable key-value metadata that can be used for lifecycle rules and object management.

---

Prefixes versus blob index tags

A prefix is part of the blob name:

backup/2026/database.bak

A blob index tag is structured metadata:

DataType = Backup
RetentionClass = SevenYears

Prefixes are simple but tied to naming conventions. Index tags provide more flexible classification but require consistent tagging and can have separate costs and feature considerations.

---

Lifecycle limitations

Lifecycle rules are evaluated periodically rather than immediately.

They should not be used as an exact-time scheduling system. A blob that becomes eligible on a particular day may be processed later.

Lifecycle transitions may also create:

• Read or write transaction charges
• Retrieval charges
• Early deletion penalties
• Rehydration costs

---

12. Data Protection

Azure provides several complementary Blob Storage data-protection mechanisms.

Microsoft recommends combining blob versioning, blob soft delete and container soft delete for strong protection against accidental changes and deletion.

---

A. Blob soft delete

Blob soft delete retains deleted blobs or overwritten versions for a configured retention period.

Use it to recover from:

• Accidental deletion
• Application errors
• Malicious deletion
• Accidental overwrite

Example:

Blob deleted today
    ↓
Retained for 30 days
    ↓
Can be undeleted during retention

---

B. Container soft delete

Container soft delete protects entire containers from accidental deletion.

This is important because blob soft delete alone does not necessarily provide the same recovery mechanism when the container itself is removed.

---

C. Blob versioning

Blob versioning automatically preserves previous versions when a blob is modified or deleted.

report.pdf
 ├── Version 1
 ├── Version 2
 └── Current version

Uses include:

• Recovering overwritten data
• Reviewing historical versions
• Protecting against application bugs
• Tracking changes

Versioning can increase capacity and transaction costs, so old versions should be managed using lifecycle rules.

---

D. Change feed

The Blob Storage change feed provides an ordered, durable record of changes to blobs.

It can record events such as:

• Blob creation
• Modification
• Deletion
• Metadata changes

Uses include:

• Audit processing
• Event-driven applications
• Replication workflows
• Compliance reporting
• Data processing pipelines

---

E. Point-in-time restore

Point-in-time restore allows eligible block blob data to be restored to an earlier state.

It is useful after:

• Accidental bulk deletion
• Application corruption
• Incorrect batch updates
• Ransomware-like modification
• Failed data-processing jobs

Point-in-time restore depends on supporting features such as:

• Blob soft delete
• Versioning
• Change feed

The restore period must be shorter than the blob soft-delete retention period.

Important limitations

Point-in-time restore:

• Applies to block blobs
• Is generally performed at the storage-account or container scope using defined ranges
• Has feature and account compatibility requirements
• Does not replace a fully independent backup strategy

---

F. Immutable storage

Immutable storage places data into a Write Once, Read Many, or WORM, state.

While protected by an immutability policy, data cannot be modified or deleted for the configured period.

Two important policy types are:

Time-based retention

Data is protected for a specified duration.

Example:

Retain for 7 years

Legal hold

Data remains protected until the legal hold is explicitly removed by an authorized user.

Typical uses:

• Financial records
• Medical records
• Audit logs
• Legal evidence
• Regulatory archives
• Security event records

Locked policies

An immutability policy can generally be tested while unlocked. Once locked, it cannot simply be reduced or removed.

Locking a retention policy is therefore a significant governance decision.

---

13. Blob Backup Options

Native data-protection features are valuable, but organizations may also require Azure Backup for Blob Storage.

Backup designs can include:

• Operational backup using storage-native capabilities
• Vaulted backup storing recovery points outside the source storage account
• Long-term retention requirements
• Centralized backup policies
• Cross-subscription governance

Point-in-time restore and versioning should not automatically be assumed to satisfy all organizational definitions of “backup.” Evaluate:

• Isolation from the source account
• Protection against subscription compromise
• Retention requirements
• Recovery granularity
• Regulatory requirements
• Backup-vault requirements

Azure Backup for blobs uses storage-native protection capabilities for operational recovery and can also provide vaulted backup options depending on the selected configuration.

---

14. Scenario — Backups and Logs Retained for Seven Years

Requirements

• Store application backups and logs
• Restore data to a previous point within 30 days
• Backups are rarely accessed
• Retain data for seven years
• Prevent modification or deletion
• Provide disaster recovery

Proposed architecture

Application
    ↓
Blob Storage
    ↓
Block blobs for backups
Append blobs or block blobs for logs

Data protection

Enable:

• Blob soft delete
• Container soft delete
• Blob versioning
• Change feed
• Point-in-time restore with an appropriate restore window

Point-in-time restore should be validated against the exact account, redundancy and hierarchical-namespace configuration.

Lifecycle management

Example:

0–30 days      → Hot or Cool
31–90 days     → Cool or Cold
After 90 days  → Archive, if retrieval delays are acceptable
After 7 years  → Delete, subject to compliance approval

Immutability

Apply a time-based immutability policy for seven years.

For strict regulatory compliance:

• Validate the retention start date
• Test the policy while unlocked
• Lock it only after approval
• Separate policy-management duties
• Record legal and compliance ownership

Redundancy

Select redundancy based on recovery requirements:

• ZRS for availability-zone protection
• GRS for regional replication
• GZRS for both zone and regional protection
• RA-GRS or RA-GZRS when secondary-region reads are needed

Security

Use:

• Microsoft Entra ID
• Managed identities
• Private endpoints
• Storage firewall
• Secure transfer required
• Minimum TLS enforcement
• Customer-managed keys where required
• Defender for Storage for threat detection
• Diagnostic logs and alerts

---

15. Corrections to the Transcript’s Proposed Solution

The transcript proposes versioning and soft delete for point-in-time restore. These features are related but not interchangeable:

• Versioning preserves previous individual blob versions.
• Soft delete retains deleted or overwritten data.
• Point-in-time restore performs broader restoration to a previous state and requires supporting features such as soft delete, versioning and change feed.

The transcript also suggests moving data to Archive after 30 days. This may be technically possible for eligible blobs but should be assessed carefully because:

• Archive is offline.
• Retrieval can take hours.
• Retrieval charges apply.
• Early deletion charges may apply.
• Some redundancy configurations do not support Archive.
• Point-in-time restore does not operate on archived blobs in the same way as online block blobs.

The transcript proposes GRS to make data “available in multiple geographic regions.” GRS creates a secondary regional copy, but that copy is not normally readable until failover. Use RA-GRS when continuous secondary read access is required.

Finally, immutability prevents deletion until the retention period expires. A lifecycle rule configured to delete at seven years will not override an active immutable retention period. Retention expiry and lifecycle deletion must be aligned.

---

16. Security Best Practices

Use the following baseline for sensitive Blob Storage workloads:

1. Use Microsoft Entra ID and managed identities.
2. Disable Shared Key authorization where practical.
3. Require HTTPS.
4. Configure a recent minimum TLS version.
5. Disable public network access when not required.
6. Use private endpoints.
7. Restrict storage firewall rules.
8. Enable soft delete and versioning.
9. Use immutability for regulated records.
10. Enable Defender for Storage where threat detection is required.
11. Send diagnostics to Log Analytics or a SIEM.
12. Use Azure Policy to enforce settings.
13. Regularly review role assignments and SAS tokens.
14. Apply lifecycle rules to versions and snapshots.
15. Keep production, backup and logging workloads separated when their security or retention requirements differ.

Microsoft’s Blob Storage Well-Architected guidance also recommends inventory reporting, retention review, encryption verification and structured governance of account contents.

---

17. Cost Considerations

Blob Storage cost includes more than stored capacity.

Total cost =
storage capacity
+ read/write operations
+ data retrieval
+ tier transitions
+ early deletion charges
+ data transfer
+ replication
+ private endpoints
+ monitoring
+ backup
+ version and snapshot capacity

Key design questions:

• How often is each object read?
• How quickly must archived data be retrieved?
• How long must it be retained?
• How many previous versions will accumulate?
• Is geo-replication required?
• Will data leave the Azure region?
• Will applications repeatedly list large containers?
• Are lifecycle transitions frequent?
• Are private endpoint and monitoring costs included?

Lifecycle policies lower capacity cost only when access patterns match the selected tiers.

---

18. Performance and Scalability Considerations

Before designing a large Blob Storage workload, measure:

• Number of requests per second
• Read/write throughput
• Object size
• Concurrency
• Network bandwidth
• Access distribution
• Partitioning and naming patterns
• Account-level scale targets
• Regional service limits

Azure publishes current scalability and performance targets for Blob Storage. These limits should be verified during design rather than assumed from older course material.

For very large or high-throughput systems, consider:

• Multiple storage accounts
• Parallel uploads
• Block-level uploads
• AzCopy
• Azure Data Box for offline migration
• CDN or Front Door for global content delivery
• Object replication for selected cross-account scenarios

Object replication currently supports block blobs rather than append or page blobs and requires compatible source and destination accounts.

---

19. Quick Decision Matrix

---

20. AZ-305 Exam Review

Remember these associations:

• Block blobs → General object storage and large-file streaming.
• Append blobs → Append-only logs and audit data.
• Page blobs → Random read/write data and VHD-related workloads.
• Hot → Frequent access.
• Cool → Infrequent online access, approximately 30-day minimum.
• Cold → Rare online access, approximately 90-day minimum.
• Archive → Offline storage with rehydration delay and approximately 180-day minimum.
• Premium block blobs → High transaction rates and consistently low latency.
• Soft delete → Recovery from deletion.
• Versioning → Recovery of previous blob versions.
• Point-in-time restore → Restore eligible block blob data to an earlier state.
• Immutable storage → WORM compliance.
• Lifecycle management → Automated tier transitions and deletion.
• Blob index tags → Searchable classification and lifecycle filtering.
• GRS → Geo-replication without normal secondary reads.
• RA-GRS → Geo-replication with secondary-region reads.
• Private endpoint → Private IP access to Blob Storage.
• Managed identity → Preferred secretless application authentication.

---

Microsoft Reference Documentation

• Introduction to Azure Blob Storage.
• Block, append and page blob differences.
• Azure page blob overview.
• Blob Storage access tiers.
• Best practices for access tiers.
• Azure Blob Storage lifecycle management.
• Blob data-protection overview.
• Point-in-time restore overview.
• Immutable Blob Storage.
• Azure Storage redundancy.
• Blob Storage scalability and performance targets.
• Azure Blob Storage architecture best practices.
• Blob object replication.
• Azure Blob backup.

---

Data security deep dive

Azure Blob Storage Data Security — Review Notes and In-Depth Guide

1. Overview

Blob Storage security should use a defense-in-depth model rather than relying on a single control.

A secure Blob Storage design combines:

Data classification
        +
Identity and authorization
        +
Network isolation
        +
Encryption
        +
Data protection
        +
Monitoring and governance
        +
Availability and disaster recovery

The main objective is to ensure:

• Only approved identities can access data.
• Access is limited to the minimum required permissions.
• Sensitive data is not exposed over public networks.
• Data is encrypted at rest and in transit.
• Accidental deletion and malicious modification can be recovered.
• Regulatory retention and residency requirements are satisfied.
• Security events are detected and investigated.

---

2. Data Classification

Before selecting security controls, classify data according to its sensitivity and business importance.

A typical classification model is:

Organizations may instead use industry-specific classifications such as:

• Public
• Internal
• Confidential
• Highly confidential
• Personal data
• Financial data
• Payment-card data
• Protected health information
• Legal hold
• Regulatory archive

Classification mechanisms

Blob data can be classified using:

• Blob metadata
• Blob index tags
• Container naming conventions
• Storage account separation
• Resource tags on the storage account
• Microsoft Purview classification and scanning
• Application-level catalogues

Example blob index tags:

Classification = Restricted
DataType       = Financial
Retention      = SevenYears
Region         = EU
Owner          = Finance

Blob index tags are searchable and can be used in lifecycle-management rules. Metadata can describe a blob but is not indexed in the same manner.

Design principle: Tags and metadata record classification, but they do not enforce security by themselves. Enforcement requires RBAC, network controls, policies, encryption and data-protection settings.

For highly sensitive data, consider using separate storage accounts rather than placing public and restricted data in the same account. A storage account is an important security, networking, encryption and operational boundary.

---

3. Identity and Authorization

The first security question should be:

Who or what needs access, and what is the minimum access required?

Azure Storage supports several authorization models.

---

Microsoft Entra ID and Azure RBAC

Microsoft Entra ID authorization is preferred for most modern Blob Storage applications.

Common Blob Storage data-plane roles include:

• Storage Blob Data Reader
• Storage Blob Data Contributor
• Storage Blob Data Owner

These roles are different from management-plane roles such as:

• Reader
• Contributor
• Owner
• Storage Account Contributor

For example, Storage Account Contributor can manage the storage account configuration but does not automatically provide permission to read blob contents.

Applications should use managed identities where possible:

Azure application
      ↓ managed identity
Microsoft Entra ID
      ↓ OAuth access token
Blob Storage

Advantages include:

• No account keys in source code
• No manually managed passwords
• Central access revocation
• Fine-grained permissions
• Better audit attribution
• Support for conditional governance controls

Microsoft recommends Microsoft Entra authorization and managed identities instead of Shared Key authorization whenever the workload supports them.

---

Principle of least privilege

Grant access at the narrowest practical scope:

Management group
    ↓
Subscription
    ↓
Resource group
    ↓
Storage account
    ↓
Container

For example, an application that only reads invoices from one container should not receive contributor rights across the entire storage account.

Also separate duties such as:

• Storage administration
• Data reading
• Data writing
• Key administration
• Immutability-policy management
• Network administration
• Backup administration

---

4. Shared Access Signatures

A Shared Access Signature, or SAS, provides delegated access to an Azure Storage resource without exposing the storage account key directly.

A SAS can restrict:

• Resource or container
• Allowed operations
• Start time
• Expiry time
• Allowed IP range
• Allowed protocol
• Encryption scope in supported scenarios

Example:

Resource: reports/financial-report.pdf
Permission: Read
Protocol: HTTPS only
Valid for: 15 minutes
Source IP: Approved corporate range

---

Types of SAS

User delegation SAS

Signed using a user delegation key obtained through Microsoft Entra ID.

This is the preferred SAS type for Blob Storage because it does not depend directly on the storage account key and is associated with an Entra-authorized identity. Microsoft recommends user delegation SAS whenever possible.

Service SAS

Signed using a storage account key and grants access to resources within one Azure Storage service.

For example:

• Blob container
• Individual blob
• Azure file share

Account SAS

Signed using an account key and can grant broader permissions across multiple storage services and service-level operations.

Because of its potentially broad scope, it should be used cautiously.

---

SAS best practices

• Prefer Microsoft Entra ID over SAS when direct identity authorization is possible.
• Prefer user delegation SAS for Blob Storage.
• Use the shortest practical expiry time.
• Grant only the required permissions.
• Limit the SAS to the required container or blob.
• Require HTTPS.
• Restrict source IP addresses when appropriate.
• Never store SAS tokens in source-control repositories.
• Avoid writing SAS query strings into application or proxy logs.
• Use Azure Policy to define recommended SAS expiration periods.
• Monitor storage access for unexpected usage.
• Revoke access promptly when compromise is suspected.

Microsoft supports a storage-account SAS expiration policy to recommend or enforce expected SAS lifetimes, depending on configuration.

---

Stored access policies

A stored access policy can be associated with a service SAS.

The policy centralizes:

• Expiry
• Start time
• Permissions

Changing or deleting the policy can affect SAS tokens linked to it, providing a revocation mechanism.

However:

• Stored access policies do not apply to user delegation SAS.
• Stored access policies do not apply to account SAS.
• A user delegation SAS is generally preferred where possible, despite not supporting stored access policies.

---

Correction: “Regenerate SAS keys”

A SAS token does not have its own key that can simply be regenerated.

A SAS is signed using either:

• A user delegation key, or
• A storage account access key

To invalidate a compromised SAS, the method depends on how it was created:

Rotating an account key can disrupt every application using that key, so short-lived and narrowly scoped SAS tokens are safer.

---

5. Shared Key Authorization

A storage account has access keys that provide broad Shared Key authorization.

Risks include:

• Large blast radius
• Long-lived credentials
• Limited user attribution
• Accidental exposure in code or configuration
• Operational disruption during rotation

Recommended approach:

1. Use Microsoft Entra ID and managed identities.
2. Replace account-key-based SAS tokens with user delegation SAS where possible.
3. Identify applications still using Shared Key.
4. Rotate keys safely.
5. Disable Shared Key authorization after compatibility has been confirmed.

Microsoft recommends avoiding storage account keys where stronger identity-based methods are available.

---

6. Encryption at Rest

All data written to Azure Storage is automatically encrypted by the storage service before being persisted.

Two primary key-management options are available.

---

Microsoft-managed keys

Microsoft creates, manages, rotates and protects the encryption keys.

Use this option when:

• Standard platform-managed encryption satisfies requirements.
• The organization does not require direct control over key lifecycle.
• Reduced operational complexity is preferred.

---

Customer-managed keys

The customer manages the key using:

• Azure Key Vault
• Azure Key Vault Managed HSM

Customer-managed keys provide additional control over:

• Key creation
• Rotation
• Revocation
• Access policies
• Separation of duties
• Regulatory evidence

The customer-managed key protects the key used to encrypt the storage data; it does not mean that every blob is directly encrypted independently with the Key Vault key.

Responsibilities with customer-managed keys

The organization must manage:

• Key Vault availability
• Key permissions
• Key rotation
• Key expiration
• Soft delete and purge protection
• Managed identity permissions
• Recovery procedures
• Monitoring and alerts

Incorrectly disabling, deleting or expiring the key can make storage data inaccessible.

AZ-305 principle: Select customer-managed keys only when customer control of the encryption-key lifecycle is a stated security, legal or compliance requirement.

---

Encryption scopes

Encryption scopes can provide separate encryption boundaries within a storage account.

They may be useful when:

• Different containers require different keys.
• Multiple customers share one account.
• Some data requires customer-managed keys while other data uses Microsoft-managed keys.

For stronger operational or regulatory isolation, separate storage accounts may still be more appropriate.

---

Infrastructure encryption

Infrastructure encryption adds another layer of encryption at the storage infrastructure level using a separate key.

It may be required when regulations call for double encryption or encryption using two independent key layers. Azure Policy includes definitions that can enforce customer-managed keys and infrastructure encryption.

---

7. Encryption in Transit

Data moving between a client and Blob Storage should be protected using HTTPS and TLS.

Enable Secure transfer required to reject requests sent over plain HTTP.

Recommended controls:

• Require secure transfer.
• Use HTTPS for REST and SDK calls.
• Configure an appropriate minimum TLS version.
• Avoid placing secrets in URLs or logs.
• Use private endpoints for sensitive network paths.
• Validate that legacy clients support the required TLS version.

Secure transfer protects data from interception or modification while it travels between the client and Azure Storage.

Encryption at rest and encryption in transit solve different problems:

One control does not replace the others.

---

8. Storage Firewall and Public Network Access

Azure Storage provides network-level access controls through the storage firewall.

Possible public-network configurations include:

• Allow access from all networks
• Allow access only from selected networks
• Disable public network access

Selected-network rules can include:

• Approved public IPv4 addresses
• Approved virtual-network subnets
• Resource-instance rules in supported scenarios
• Trusted Microsoft service exceptions

For sensitive workloads, disable public network access and use private endpoints where application design permits. Microsoft’s Blob Storage architecture guidance recommends disabling public endpoint traffic and creating private endpoints for Azure-based clients.

A storage firewall controls the network source. It does not grant data access by itself. The caller must still authenticate and be authorized.

---

9. Service Endpoints vs Private Endpoints

Service endpoint

A Virtual Network service endpoint extends the identity of an Azure subnet to the storage service.

Characteristics:

• The application accesses the storage account’s public endpoint.
• Traffic uses the Microsoft backbone.
• The storage firewall can allow the selected subnet.
• The storage account does not receive a private IP address.
• Public network access remains part of the design.

Simplified path:

Application subnet
        ↓
VNet service endpoint
        ↓
Storage public endpoint

Service endpoints can be suitable when:

• Simple subnet restrictions are sufficient.
• A private IP endpoint is not required.
• The workload operates within supported Azure networking patterns.
• Lower networking complexity is preferred.

---

Private endpoint

A private endpoint assigns a private IP address from a VNet to a specific storage service endpoint.

Application
    ↓
Private IP in VNet
    ↓
Azure Private Link
    ↓
Blob Storage

Benefits:

• Private IP-based access
• Public network access can be disabled
• Traffic stays on Microsoft’s network
• Access can be extended to peered VNets
• On-premises clients can connect through VPN or ExpressRoute
• Better protection against public Internet exposure

Azure Storage uses a distinct private endpoint for each storage subservice, such as:

• Blob
• DFS
• File
• Queue
• Table

For Data Lake Storage Gen2, both Blob and DFS private endpoints may be required.

Private endpoint traffic requires correct private DNS configuration. Microsoft confirms that private endpoints use IP addresses from the VNet and avoid exposure to the public Internet.

---

Comparison

---

10. Preventing Anonymous Public Access

Blob containers can support anonymous public read access when both the storage account and container configuration allow it.

For sensitive data:

• Disable anonymous access at the storage-account level.
• Do not configure containers for public access.
• Use Entra ID, managed identity or temporary SAS-based access.
• Use Azure Policy to prevent noncompliant configurations.
• Periodically audit accounts and containers.

Public endpoint availability and anonymous access are different concepts:

• A publicly reachable endpoint may still require authentication.
• Anonymous access allows unauthenticated data reading.

Both must be evaluated separately.

---

11. Immutable Blob Storage

Immutable Blob Storage supports Write Once, Read Many, or WORM, protection.

While data is protected by an applicable immutability policy, it cannot be modified or deleted—even by users with high administrative privileges.

---

Time-based retention policy

Protects data for a defined duration.

Example:

Retain financial records for seven years

During the active retention period, protected data cannot be deleted or overwritten.

---

Legal hold

Protects data until an authorized administrator explicitly removes the legal hold.

Typical scenarios:

• Litigation
• Regulatory investigation
• Audit evidence
• Employment disputes
• Fraud investigation

---

Unlocked vs locked policies

An unlocked policy can be tested and adjusted before final enforcement.

A locked policy provides stronger compliance guarantees. After locking, restrictions generally prevent reducing or removing the retention requirement.

Therefore:

1. Validate the scope.
2. Test application compatibility.
3. Confirm retention duration.
4. Obtain legal and compliance approval.
5. Lock the policy only after verification.

---

Protected append writes

Some immutable-storage configurations allow new blocks to be appended to append blobs while existing protected data remains immutable.

This is useful for:

• Audit logs
• Security records
• Append-only journals

The exact policy configuration must explicitly permit protected append operations.

---

Immutability does not replace backup

Immutability protects retained data from modification and deletion, but it does not automatically provide:

• Point-in-time recovery
• Independent recovery copies
• Protection from application-level logical errors already written as new data
• Regional failover
• Full backup-vault isolation

Combine immutability with:

• Blob versioning
• Soft delete
• Container soft delete
• Point-in-time restore where supported
• Azure Backup
• Appropriate storage redundancy

---

12. Accidental Deletion Protection

The transcript’s scenario requires protection from accidental deletion. Immutability may be appropriate for regulated records, but soft delete is normally the direct control for recovering accidentally deleted data.

Recommended features include:

Blob soft delete

Retains deleted or overwritten blobs for a configured recovery period.

Container soft delete

Protects against accidental deletion of an entire blob container.

Blob versioning

Retains previous versions after blob modification.

Point-in-time restore

Restores eligible block blob content to an earlier point, subject to feature and configuration requirements.

Backup

Provides centrally managed recovery policies and, depending on configuration, recovery points isolated from the operational storage account.

Design principle: Use soft delete for recoverability and immutability for tamper-resistant retention. They solve different problems.

---

13. Storage Redundancy and Security

Azure Storage replication provides durability and availability but should not be treated as an authorization or backup feature.

Primary options include:

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

---

LRS

Stores multiple copies within one primary physical location.

Suitable for:

• Re-creatable data
• Noncritical workloads
• Lowest-cost redundancy

It does not protect against a complete zone or regional failure.

---

ZRS

Synchronously replicates data across availability zones within one Azure region.

Suitable for workloads that must remain available during:

• Datacenter failure
• Availability-zone failure

---

GRS

Replicates data to a secondary Azure region asynchronously.

Important:

• Secondary data is not normally readable before failover.
• Recent writes may not yet have reached the secondary region.
• Failover planning is still required.

---

RA-GRS

Provides read access to the secondary regional copy before failover.

Use it when:

• Secondary-region read access is required.
• Applications can tolerate potentially stale data.
• The application has logic to use the secondary endpoint.

---

GZRS and RA-GZRS

GZRS combines zone redundancy in the primary region with asynchronous geo-replication.

RA-GZRS additionally permits secondary-region reads.

The choice should be based on:

• Recovery point objective
• Recovery time objective
• Zone-failure requirements
• Regional-disaster requirements
• Secondary-read requirements
• Service and tier compatibility
• Cost

Replication can reproduce deletion or corruption. It is not a replacement for versioning, soft delete, immutability or backup.

---

14. Data Residency and Replication

For regulated workloads, verify where both the primary and secondary copies are stored.

A geo-redundant option may create a secondary copy in another Azure region. That region must satisfy:

• Data-residency requirements
• Sovereignty restrictions
• Regulatory commitments
• Contractual requirements

A workload requiring data to remain within a specific jurisdiction may need:

• LRS or ZRS in an approved region
• A specific supported geo-replication arrangement
• Azure Policy restrictions
• Separate subscriptions or management groups
• Purview classification and compliance reporting

Do not automatically select GRS only because the workload is important. Regional replication must be compatible with legal and residency requirements.

---

15. Monitoring and Threat Detection

Security controls should generate evidence and alerts.

Consider enabling:

• Azure Storage resource logs
• Azure Activity Log
• Azure Monitor metrics and alerts
• Log Analytics
• Microsoft Defender for Storage
• Microsoft Sentinel integration
• Key Vault audit logs
• Private endpoint and DNS monitoring
• Azure Policy compliance reporting

Monitor for:

• Anonymous access attempts
• Repeated authorization failures
• Unexpected SAS usage
• Access from unusual IP addresses
• Large or unusual downloads
• Mass deletion or modification
• Storage firewall changes
• Public-access enablement
• Key rotation or Key Vault access failures
• Immutability-policy changes
• Unexpected geo-replication or failover activity

Security logs should be sent to a separate protected destination so an attacker who compromises the storage account cannot easily destroy the evidence.

---

16. Governance with Azure Policy

Azure Policy can help enforce controls such as:

• Require secure transfer.
• Restrict public network access.
• Require private endpoints.
• Disable public blob access.
• Require customer-managed keys.
• Require infrastructure encryption.
• Restrict allowed Azure regions.
• Deploy diagnostic settings.
• Enforce minimum TLS settings.
• Audit storage accounts using Shared Key authorization.
• Enforce network restrictions.

Microsoft publishes built-in Azure Policy definitions for Storage, including controls for customer-managed keys, infrastructure encryption and restricted network access.

Use policy effects carefully:

A common adoption pattern is:

Audit
   ↓
Remediate existing resources
   ↓
Deny future noncompliance

---

17. Real-World Scenario: Sensitive Financial Data

Requirements

A financial institution must store sensitive financial records in Blob Storage.

The data must:

• Be encrypted.
• Be accessible only through approved private networks.
• Be protected from accidental deletion.
• Be retained without modification for seven years.
• Remain available during infrastructure failures.
• Stay within approved geographic boundaries.
• Produce auditable security records.

---

Recommended architecture

On-premises / Azure application
          ↓
VPN or ExpressRoute
          ↓
Private DNS
          ↓
Blob private endpoint
          ↓
Storage account

Identity

• Use managed identities for Azure workloads.
• Use Microsoft Entra ID and Blob data roles.
• Avoid storage account keys.
• Use short-lived user delegation SAS only for exceptional delegated-access scenarios.

Networking

• Create a Blob private endpoint.
• Disable public network access.
• Configure private DNS.
• Restrict NSGs and routes appropriately.
• Validate on-premises DNS resolution over VPN or ExpressRoute.

Encryption

• Use Azure Storage service-side encryption.
• Use customer-managed keys if required by policy.
• Store keys in Key Vault or Managed HSM.
• Enable Key Vault soft delete and purge protection.
• Monitor key expiry and access failures.
• Require secure transfer and current TLS.

Accidental deletion protection

• Enable blob soft delete.
• Enable container soft delete.
• Enable versioning.
• Consider point-in-time restore or Azure Backup.

Regulatory retention

• Apply a seven-year time-based immutability policy.
• Test the policy before locking it.
• Define a separate legal-hold process.
• Align lifecycle deletion with retention expiry.

Availability and disaster recovery

Choose redundancy based on legal and technical requirements:

• ZRS for availability-zone resilience.
• GRS or GZRS for regional protection when the secondary location is legally acceptable.
• RA-GRS or RA-GZRS only when readable secondary data is required.

Monitoring and governance

• Enable Defender for Storage.
• Send logs to Log Analytics or Sentinel.
• Apply Azure Policy.
• Alert on public-access, firewall, key and immutability changes.
• Periodically review RBAC assignments and SAS usage.

---

18. Evaluation of the Transcript’s Proposed Solution

The transcript proposes:

• Private endpoint
• Customer-managed keys
• Immutable Blob Storage
• RA-GRS

This is a reasonable starting point, but it requires several refinements.

Private endpoint

Correct for private access, but it should normally be accompanied by:

• Disabling public network access
• Private DNS configuration
• Identity authorization
• Firewall and routing validation

A private endpoint does not eliminate the need for RBAC.

Customer-managed keys

Appropriate only when customer control over encryption keys is required.

They introduce operational responsibilities, including key availability, rotation, permissions and recovery.

Immutable storage

Appropriate for compliance retention and protection from modification.

However, for accidental deletion recovery, also enable soft delete and versioning. Immutability is not the same as a restore mechanism.

RA-GRS

RA-GRS provides read access to an asynchronously replicated secondary region.

It should be selected only if:

• The secondary region satisfies residency requirements.
• The application requires secondary reads.
• The application can tolerate replication lag.
• The workload and account configuration support it.

For zone and regional resilience together, RA-GZRS may be more suitable where supported.

---

19. Quick Decision Matrix

---

20. AZ-305 Exam Review

Remember these associations:

• Data classification determines the security controls required.
• Microsoft Entra ID and managed identities are preferred over account keys.
• User delegation SAS is preferred when SAS access to blobs is necessary.
• Stored access policies apply to service SAS, not user delegation or account SAS.
• Secure transfer required rejects HTTP requests.
• Microsoft-managed keys minimize operational responsibility.
• Customer-managed keys provide customer control but add key-management responsibilities.
• Service endpoints secure access from selected subnets while using the public service endpoint.
• Private endpoints provide a private IP address and support disabling public network access.
• Soft delete provides deletion recovery.
• Versioning preserves previous blob versions.
• Immutability provides WORM retention.
• ZRS protects against availability-zone failure.
• GRS replicates asynchronously to a secondary region.
• RA-GRS adds read access to the secondary region.
• Replication is not backup.
• Azure Policy enforces required security configurations at scale.

---

Microsoft Reference Documentation

• Blob Storage security recommendations.
• Azure Storage authorization methods.
• Shared access signature overview.
• User delegation SAS creation and security.
• Service SAS and stored access policies.
• SAS expiration policies.
• Storage-account key management.
• Customer-managed keys for Azure Storage.
• Azure Storage private endpoints.
• Blob Storage architecture best practices.
• Azure Storage security baseline.
• Immutable storage for Blob data.
• Built-in Azure Policy definitions for Storage.
• Azure Storage account overview and default encryption.
• General Azure encryption guidance.

---

File storage deep dive

Azure File Storage — Review Notes and In-Depth Guide

1. Overview

Azure provides three main services for managed file-storage workloads:

1. Azure Files — fully managed SMB or NFS file shares.
2. Azure File Sync — synchronizes Windows Server file shares with Azure Files and optionally caches frequently accessed files locally.
3. Azure NetApp Files — high-performance enterprise NAS for demanding SMB, NFS and dual-protocol workloads.

The best service depends on:

• Required protocol
• Performance and latency
• On-premises caching requirements
• Operating system compatibility
• Capacity
• Availability and disaster recovery
• Authentication
• Backup
• Cost

General cloud file share          → Azure Files
Hybrid Windows file server/cache  → Azure File Sync + Azure Files
High-performance enterprise NAS   → Azure NetApp Files

---

2. Azure Files

What is Azure Files?

Azure Files provides fully managed cloud file shares hosted in Azure Storage accounts.

Applications and users can mount shares using standard file protocols rather than rewriting applications to use object-storage APIs.

Azure Files supports two principal file protocols:

• SMB
• NFS

It can also be accessed through:

• Azure portal
• Azure CLI
• Azure PowerShell
• REST APIs
• Storage Explorer
• Azure SDKs

Azure Files is serverless from the customer’s perspective, so Microsoft manages the underlying storage infrastructure, patching and hardware.

---

3. Azure Files Protocols

SMB

SMB is normally selected for:

• Windows file shares
• Windows applications
• User home directories
• FSLogix profiles
• Lift-and-shift applications
• Shared application configuration
• General enterprise collaboration

Modern Azure Files deployments support SMB 3.x capabilities. SMB 2.1 exists mainly for legacy compatibility and has important security and placement restrictions.

The transcript states that Azure Files generally supports SMB 2.1 and SMB 3.0. This needs qualification:

• SMB 3.x should be preferred.
• SMB 2.1 does not support encryption.
• SMB 2.1 is restricted to clients in the same Azure region as the share.
• Disabling secure transfer to support old SMB clients weakens security and should only be considered for exceptional legacy requirements.

Best practice: Use SMB 3.x with encryption in transit.

---

NFS

Azure Files supports NFS file shares for Linux and UNIX-oriented workloads.

Typical scenarios:

• Linux applications
• Container workloads
• AKS persistent volumes
• Shared POSIX file systems
• Application data accessed by Linux VMs
• Development and engineering workloads

Azure Files NFS shares provide POSIX-style file-system capabilities and integrate with services such as AKS through CSI drivers.

---

One share does not use both protocols

An individual Azure file share is normally created as either:

• SMB, or
• NFS

Azure Files should therefore not be confused with Azure NetApp Files dual-protocol volumes, which can expose the same dataset through both SMB and NFS with identity mapping.

---

4. Azure Files Architecture

Storage account
      └── File service
            └── File share
                  ├── Folder
                  ├── File
                  └── Snapshot

Example SMB mount:

\\storageaccount.file.core.windows.net\documents

Azure Files can be:

• Mounted directly by Azure VMs
• Mounted from on-premises through appropriate network connectivity
• Cached through Azure File Sync
• Used by containers and Kubernetes
• Accessed programmatically through FileREST

---

5. Azure Files Deployment Models

A. Direct cloud mount

Clients mount the Azure file share directly.

Azure VM / on-premises client
              ↓
         Azure Files

Use direct mounting when:

• Network latency is acceptable.
• A local cache is not required.
• The application supports SMB or NFS.
• Connectivity to Azure is reliable.
• Centralized cloud storage is preferred.

On-premises direct mounting may require:

• VPN or ExpressRoute
• Private Endpoint
• Correct DNS resolution
• Firewall access
• SMB port availability
• Suitable latency

---

B. Hybrid cached deployment

Azure File Sync keeps the authoritative share in Azure Files while one or more Windows Servers provide local access.

Users
  ↓
Local Windows Server cache
  ↓
Azure File Sync
  ↓
Azure Files

Use this model when:

• Users need LAN-like access.
• Branch offices have limited connectivity.
• Existing Windows file-server paths must remain.
• Local applications require low-latency file access.
• Centralized cloud storage and backup are desired.

---

6. Azure Files Performance Tiers

Current Azure Files planning and billing guidance broadly distinguishes storage backed by:

• SSD
• HDD

The exact share tier, account model, provisioned capacity and performance model depend on the selected deployment configuration. Microsoft documentation now commonly describes these as SSD and HDD media tiers rather than relying only on the older “Premium versus Standard” terminology.

---

SSD file shares

SSD-based shares are intended for workloads requiring:

• Low latency
• High IOPS
• High throughput
• Predictable performance
• Transaction-intensive access

Typical workloads:

• Databases with supported file-share requirements
• FSLogix profile containers
• Enterprise applications
• High-concurrency workloads
• Build and development environments

---

HDD file shares

HDD-based shares are more cost-oriented and appropriate for:

• General-purpose file servers
• Departmental shares
• Documents
• Archive-style online file data
• Light-to-moderate application workloads

Select the tier based on measured latency, IOPS and throughput—not simply whether the workload is production.

Azure Files publishes separate scalability and performance targets. Workload testing is important because client concurrency, file sizes, network bandwidth and access patterns can affect observed performance.

---

7. Azure Files Redundancy

Azure Files uses the redundancy settings supported by its storage-account and share configuration.

Possible options can include:

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

However, not every redundancy option is supported with every Azure Files tier, protocol, account type or region.

---

LRS

Stores multiple copies in one primary physical location.

Use when:

• Lowest cost is important.
• Data can be recreated.
• Zone or regional disaster protection is not required.

---

ZRS

Synchronously stores data across multiple availability zones in the same region.

Use when:

• The share must withstand a zone failure.
• Regional replication is not required.
• Production availability is important.

---

GRS

Replicates data asynchronously to a secondary Azure region.

Important:

• The secondary copy is not normally readable until failover.
• Recent writes may not yet exist in the secondary region.
• Failover and identity dependencies must be designed.

---

RA-GRS

Adds read access to the secondary copy before failover.

Use only if:

• The workload benefits from secondary reads.
• Stale data is acceptable.
• The application is designed to use the secondary endpoint.

---

GZRS and RA-GZRS

These combine zonal resilience in the primary region with asynchronous replication to a secondary region.

They should be selected only when supported for the exact Azure Files configuration.

Azure Storage redundancy applies according to the selected account and service configuration.

---

Replication is not backup

Replication protects against infrastructure failure.

It does not necessarily protect against:

• Accidental deletion
• Ransomware
• File corruption
• Malicious overwrite
• Incorrect application changes

These changes can also be replicated.

Combine redundancy with:

• Share snapshots
• Soft delete
• Azure Backup
• Vaulted backups where required
• Appropriate permissions and monitoring

---

8. Azure Files Authentication and Authorization

Security for Azure Files has multiple layers:

Identity authentication
        +
Share-level authorization
        +
File and directory permissions
        +
Network restrictions

---

SMB authentication

Depending on the design, SMB shares can integrate with identity systems such as:

• Microsoft Entra Kerberos
• Active Directory Domain Services
• Microsoft Entra Domain Services
• Storage account key authentication for legacy or limited scenarios

Identity-based access should be preferred over storage-account-key authentication.

---

Share-level RBAC

Azure RBAC roles control access at the Azure file-share level.

Examples include roles for:

• Reading share data
• Modifying share data
• Elevated SMB share access

RBAC determines whether a user can access the share, but NTFS permissions determine access to individual files and folders in SMB scenarios.

Azure RBAC          → Can the user access the share?
NTFS ACL            → Which folders/files can the user access?

Both layers must allow access.

---

NFS authorization

NFS access typically uses:

• Network restrictions
• UNIX user and group IDs
• POSIX permissions
• Root-squash options where supported

The authentication and security model differs from SMB and must be planned separately.

---

9. Azure Files Networking

Public endpoint

Azure Files can be accessed through its public service endpoint, but access can still be restricted using:

• Storage firewall rules
• Approved public IPs
• Virtual-network rules
• Identity controls

A public endpoint does not automatically mean anonymous access.

---

Private Endpoint

A Private Endpoint gives the file service a private IP address in a VNet.

Client
  ↓
Private DNS
  ↓
Private Endpoint
  ↓
Azure Files

Benefits:

• Private IP connectivity
• Public network access can be disabled
• Connectivity from peered VNets
• Connectivity from on-premises through VPN or ExpressRoute
• Reduced exposure to the public Internet

Private DNS is essential so that the normal Azure Files hostname resolves to the private IP.

---

Port considerations

Direct SMB access normally requires TCP port 445.

Some Internet service providers and corporate networks block outbound port 445. Private connectivity through VPN or ExpressRoute is often preferred for on-premises clients.

---

10. Azure Files Snapshots

Azure Files share snapshots create read-only, point-in-time copies of an entire file share.

They can help recover:

• Deleted files
• Overwritten files
• Changed directories
• Previous file versions
• Application-consistent data when properly coordinated

A snapshot is efficient because it initially records changes rather than creating an immediate full duplicate.

However, snapshots remain associated with the source storage account and should not automatically be considered an independent backup.

Use snapshots for:

• Fast operational recovery
• User self-service previous versions
• Short-term recovery points

Use Azure Backup when you require:

• Central policy management
• Longer retention
• Reporting and alerting
• Protection outside the operational share
• Independent recovery capabilities

---

11. Azure Backup for Azure Files

Azure Backup can protect Azure file shares using scheduled policies and retention rules.

Current Azure capabilities include both operational and vaulted protection models depending on the supported share configuration.

Vaulted backup can retain recovery points independently of the source account and currently supports retention for extended periods, including up to ten years in supported configurations.

Possible benefits:

• Protection against accidental deletion
• Central backup policies
• Long-term retention
• Alternate-location restoration
• Ransomware resilience
• Backup monitoring and alerting

Backup support varies by:

• SMB versus NFS
• HDD versus SSD
• Region
• Redundancy
• Account and share type

For example, NFS share backup support must be checked carefully for the selected configuration; Microsoft’s current classic-share guidance notes limitations for NFS shares.

---

12. Azure File Sync

What is Azure File Sync?

Azure File Sync centralizes an organization’s file shares in Azure Files while allowing Windows Server to retain a local cache.

The service is useful for:

• Branch offices
• Hybrid storage
• File-server consolidation
• Local performance
• Centralized backup
• File-server migration
• Multi-site synchronization

Azure File Sync transforms Windows Server into a fast cache of an Azure file share.

---

13. Azure File Sync Components

Storage Sync Service

An Azure resource representing the top-level synchronization service.

It manages:

• Registered servers
• Sync groups
• Cloud endpoints
• Server endpoints

The transcript says to “install the Storage Sync Service and agents on on-premises servers.” This is imprecise:

• The Storage Sync Service is deployed as an Azure resource.
• The Azure File Sync agent is installed on Windows Server.

---

Registered server

A Windows Server running the Azure File Sync agent and registered with a Storage Sync Service.

---

Sync group

Defines the synchronization relationship between:

• One cloud endpoint
• One or more server endpoints

Sync group
  ├── Cloud endpoint: Azure file share
  ├── Server endpoint: Server A folder
  └── Server endpoint: Server B folder

---

Cloud endpoint

An Azure file share that acts as the cloud member of the sync group.

Each sync group has one cloud endpoint.

---

Server endpoint

A specific folder or volume on a registered Windows Server.

Examples:

D:\CompanyFiles
E:\Projects
F:\Archive

A server endpoint is not necessarily an entire server or share; it is a defined path.

---

14. Azure File Sync Data Flow

Windows Server A
       ↕
Azure file share
       ↕
Windows Server B

Changes made at one endpoint are synchronized through Azure Files to the other server endpoints.

Azure Files is the central cloud endpoint, but Azure File Sync is not a traditional active-active clustered file system. Applications that concurrently modify the same files across locations must be assessed carefully for conflict behavior.

---

15. Cloud Tiering

Cloud tiering is an optional Azure File Sync feature.

It keeps:

• Frequently accessed files locally
• Infrequently accessed file content in Azure Files
• The complete namespace visible on the local server

A tiered file appears locally but its content is recalled when accessed.

Local server:
  Folder structure      → Present
  Hot file contents     → Present
  Cold file contents    → Cloud-only

This reduces the amount of local disk space required while retaining local file-server compatibility.

---

Cloud-tiering policies

Cloud tiering can use policies based on factors such as:

• Desired free space on the local volume
• Last access date
• Local cache objectives

Files are recalled when accessed.

Design considerations:

• Recall traffic consumes network bandwidth.
• A large number of recalls can affect performance.
• Frequently accessed files should remain cached.
• Antivirus and backup software must be compatible with tiered files.
• Offline Internet connectivity may prevent recall of cloud-only content.
• Large bulk operations may unexpectedly recall many files.

Microsoft generally recommends careful disk and server-endpoint layout to simplify tiering behavior and policy management.

---

16. Azure File Sync Deployment Process

A high-level deployment process is:

1. Create or select an Azure Storage account.
2. Create an SMB Azure file share.
3. Deploy the Storage Sync Service in Azure.
4. Install the Azure File Sync agent on each Windows Server.
5. Register each server.
6. Create a sync group.
7. Configure the Azure file share as the cloud endpoint.
8. Configure local server paths as server endpoints.
9. Enable cloud tiering if required.
10. Validate synchronization and conflict handling.
11. Configure backup and monitoring.
12. Test recovery and server replacement.

The agent must be installed on every relevant cluster node when Azure File Sync is used with a supported failover-cluster scenario.

---

17. Migrating Existing File Servers

Azure File Sync can be used to migrate existing SMB file servers.

Two main outcomes are possible:

Cloud-only

Existing file server
       ↓ migration
Azure Files direct mount

The old server is retired and clients connect directly to Azure Files.

Hybrid

Existing Windows Server
       ↓ Azure File Sync
Azure Files

The server remains as a local cache.

Microsoft identifies both cloud-only and hybrid migration patterns.

---

Initial data transfer options

For large datasets, possible methods include:

• Azure File Sync upload
• AzCopy
• Azure Data Box
• Robocopy
• Offline or staged migration
• Pre-seeding the Azure file share

Pre-seeding requires careful planning to prevent changes during onboarding and avoid synchronization conflicts.

---

18. Azure File Sync Limitations and Considerations

Important points:

• Azure File Sync primarily targets Windows Server.
• It synchronizes with SMB Azure file shares.
• It is not used to sync an NFS Azure file share.
• Cloud tiering requires supported Windows file-system configurations.
• Not all reparse points and file types are supported.
• Conflict files can be generated if the same file is modified concurrently.
• Azure File Sync is not a replacement for application-aware database replication.
• Sync is not the same as backup.
• Backup, high availability and redundancy must be designed separately.

Microsoft separates Azure File Sync disaster-recovery planning into high availability, backup/data protection and redundancy.

---

19. Azure NetApp Files

What is Azure NetApp Files?

Azure NetApp Files is a managed enterprise file-storage service powered by NetApp technology.

It provides:

• SMB volumes
• NFS volumes
• Dual-protocol volumes
• High throughput
• Low latency
• Large-scale capacity
• Snapshot technology
• Cross-zone and cross-region replication
• Enterprise NAS capabilities

Azure NetApp Files is designed for demanding applications such as:

• Databases
• SAP
• Oracle
• High-performance computing
• Virtual desktop environments
• Engineering workloads
• Large enterprise file shares
• Home directories
• Analytics

Microsoft identifies performance, scale, availability, data management and security as core characteristics of the service.

---

20. Azure NetApp Files Protocols

Azure NetApp Files supports:

• NFSv3
• NFSv4.1
• SMB
• Dual protocol

A dual-protocol volume can expose the same dataset through both SMB and NFS.

Current dual-protocol designs can support combinations such as:

• NFSv3 and SMB
• NFSv4.1 and SMB

Identity mapping is required so that Windows identities and UNIX identities correspond correctly.

---

21. When to Choose Azure NetApp Files

Choose Azure NetApp Files when requirements include:

• Very low latency
• High sustained throughput
• High-performance NFS
• Dual-protocol access
• Large enterprise NAS
• SAP-certified storage requirements
• Oracle database storage
• High-performance computing
• Enterprise-grade snapshot and replication
• Complex UNIX permissions and identity mapping

It should not be selected solely because a workload is “important.” Compare Azure Files and Azure NetApp Files using:

• Performance
• Latency
• Capacity
• Protocol
• Backup
• Replication
• Management
• Region availability
• Cost

Microsoft provides a current service comparison specifically for this decision.

---

22. Azure NetApp Files Performance

Azure NetApp Files performance is tied to:

• Capacity pools
• Service levels
• Allocated volume size
• Throughput configuration
• Network design
• Client concurrency
• Protocol choice

It can provide sub-millisecond latency in suitable workloads and configurations, but performance should be validated through testing rather than treated as an unconditional guarantee for every deployment.

---

23. Azure NetApp Files Networking

Azure NetApp Files volumes are integrated directly into delegated subnets within an Azure VNet.

Typical requirements include:

• Dedicated delegated subnet
• Correct routing
• NSGs and network controls where supported and appropriate
• DNS
• Active Directory connectivity for SMB
• Connectivity from clients through VNet peering, VPN or ExpressRoute

Unlike Azure Files, Azure NetApp Files is not accessed through a normal Storage account endpoint.

---

24. Azure NetApp Files Authentication

SMB

SMB volumes normally integrate with Active Directory Domain Services.

Requirements can include:

• Domain controllers
• DNS
• Active Directory site design
• Service accounts
• Time synchronization
• Kerberos
• Network connectivity

NFS

NFS access uses:

• Export policies
• UNIX identities
• LDAP where configured
• Kerberos for supported NFSv4.1 scenarios
• POSIX permissions

Dual protocol

Dual-protocol volumes require identity mapping between:

• Windows users and groups
• UNIX users and groups

Incorrect identity mapping can cause access failures or unexpected file ownership.

---

25. Azure NetApp Files Snapshots

Azure NetApp Files snapshots provide space-efficient, point-in-time volume recovery.

They can support:

• Rapid file restoration
• Volume cloning
• Application recovery
• Test/dev copies
• Protection from accidental changes

A new volume can be created from a snapshot, enabling point-in-time recovery.

Snapshots remain part of the same storage service and do not alone replace geographically separate replication or independent backup.

---

26. Azure NetApp Files Replication

Cross-region replication

Cross-region replication asynchronously replicates a volume to another Azure region.

Use it for:

• Regional disaster recovery
• Business continuity
• Secondary copies of critical data

Cross-zone replication

Cross-zone replication asynchronously replicates volumes between availability zones in a supported region.

It can support recovery from a zone outage.

Microsoft describes both cross-region and cross-zone replication as asynchronous replication between Azure NetApp Files volumes.

---

SnapMirror clarification

The transcript refers generally to “SnapMirror.”

Azure NetApp Files replication capabilities are based on NetApp technology, but in Azure architecture and exam answers, use the Azure service feature names:

• Azure NetApp Files cross-region replication
• Azure NetApp Files cross-zone replication

Do not assume that every on-premises NetApp SnapMirror feature is automatically available or configured identically in Azure NetApp Files.

---

27. Azure Files vs Azure File Sync vs Azure NetApp Files

---

28. Scenario Analysis

Requirements

A customer wants to:

• Migrate on-premises file servers to Azure.
• Retain local performance for ordinary user files.
• Use sub-millisecond storage for database files.
• Retain recovery points for 90 days.
• Protect against regional failure.

---

Recommended design

General user and departmental shares

Use:

• Azure Files
• Azure File Sync
• Cloud tiering where beneficial
• Private Endpoint
• Identity-based SMB authentication
• Azure Backup

Users
  ↓
Local Windows Server cache
  ↓
Azure File Sync
  ↓
Azure Files
  ↓
Azure Backup

High-performance database files

Use Azure NetApp Files only if:

• The database supports the selected protocol.
• The vendor supports the storage architecture.
• Measured latency and throughput justify it.
• The service is available in the required region.

Database servers
       ↓
Azure NetApp Files

Recovery points

For Azure Files:

• Use share snapshots for rapid operational recovery.
• Use Azure Backup for policy-based 90-day retention.

For Azure NetApp Files:

• Configure snapshot policies.
• Consider backup or replication based on application recovery requirements.

Disaster recovery

For Azure Files:

• Select a supported geo-redundant configuration when cross-region storage replication is required.
• Consider the authentication, DNS and client-reconnection design.
• Confirm that the selected file-share tier and protocol support the chosen redundancy.

For Azure NetApp Files:

• Use cross-region replication for regional DR.
• Use cross-zone replication for zonal DR where supported.

---

29. Corrections to the Transcript Scenario

“Azure Files snapshots with a 90-day retention policy”

Snapshots can provide point-in-time recovery, but Azure Backup is generally the stronger answer when the requirement explicitly calls for managed retention over 90 days.

Use:

Snapshots    → Fast operational recovery
Azure Backup → Policy-based retention and recovery management

---

“RA-GRS or ZGRS”

The correct abbreviation is GZRS, not ZGRS.

More importantly:

• GZRS and RA-GZRS support depends on the Azure Files tier, protocol, account model and region.
• The architecture should not assume they are available without checking the current compatibility table.
• RA-GRS should be selected only if readable secondary data is actually required.

---

Using Azure File Sync for database files

Azure File Sync should not be used as a substitute for database-native replication or database-supported shared storage.

Database files should be placed only on storage explicitly supported by the database vendor.

Azure NetApp Files may be appropriate for SAP, Oracle and other demanding workloads, but the exact application certification and architecture must be validated.

---

Sub-millisecond latency

Azure NetApp Files is designed for low-latency workloads, but the actual latency depends on:

• Client placement
• Region
• Network design
• Service level
• Volume configuration
• Workload pattern

The requirement should be validated through proof-of-concept testing.

---

30. Security Best Practices

Azure Files

• Prefer identity-based SMB authentication.
• Avoid storage-account keys where possible.
• Use SMB 3.x encryption.
• Require secure transfer.
• Use Private Endpoints.
• Disable public network access when not needed.
• Apply least-privilege RBAC.
• Maintain NTFS ACLs.
• Enable soft delete.
• Configure Azure Backup.
• Enable diagnostic logging.
• Monitor unusual file operations.
• Use Defender for Storage where appropriate.

Azure File Sync

• Patch Windows Servers and the sync agent.
• Protect server credentials and registration.
• Secure local file-server access.
• Monitor synchronization health.
• Back up the Azure file share.
• Test server replacement and recovery.
• Monitor mass recalls and tiering behavior.
• Protect local servers from ransomware.
• Avoid treating synchronization as backup.

Azure NetApp Files

• Restrict access through VNets and export policies.
• Secure Active Directory and LDAP dependencies.
• Use Kerberos where required.
• Apply least-privilege file permissions.
• Configure snapshots and replication.
• Monitor capacity and throughput.
• Protect DNS and domain-controller connectivity.
• Test failover procedures.
• Separate sensitive workloads into appropriate volumes and capacity pools.

---

31. Cost Considerations

Azure Files costs

Potential cost components include:

• Provisioned or consumed storage
• SSD versus HDD
• Transactions
• Snapshots
• Backup
• Geo-replication
• Egress
• Private Endpoints
• Azure File Sync
• Local Windows Server infrastructure

Azure File Sync costs

Include:

• Azure Files storage
• Azure File Sync registered-server charges where applicable
• Local server disks
• Network transfer
• Backup
• Server licensing and operations

Cloud tiering can reduce local disk requirements but can increase recall traffic and cloud transactions.

Azure NetApp Files costs

Potential drivers include:

• Capacity-pool allocation
• Service level
• Provisioned volume capacity
• Replication
• Backup
• Network architecture
• Minimum capacity requirements

Azure NetApp Files is often more expensive but may reduce application latency and migration complexity for workloads that genuinely require enterprise NAS performance.

---

32. Quick Decision Matrix

---

33. AZ-305 Exam Review

Remember these associations:

• Azure Files → Fully managed SMB or NFS cloud shares.
• SMB → Windows and enterprise file-sharing workloads.
• NFS → Linux, POSIX and container-oriented workloads.
• Azure File Sync → Azure Files plus local Windows Server caching.
• Cloud tiering → Hot files local; cold content stored in Azure.
• Storage Sync Service → Azure management resource.
• Sync agent → Installed on Windows Server.
• Sync group → One cloud endpoint plus one or more server endpoints.
• Azure Files snapshots → Fast point-in-time operational recovery.
• Azure Backup → Managed backup policies and longer retention.
• Azure NetApp Files → High-performance enterprise SMB/NFS storage.
• Dual protocol → Same Azure NetApp Files volume accessed by SMB and NFS.
• Cross-region replication → Azure NetApp Files regional DR.
• Cross-zone replication → Azure NetApp Files zonal DR.
• GZRS → Correct abbreviation, not ZGRS.
• Replication is not backup.
• Sync is not backup.
• Private Endpoint → Private IP access to Azure Files.
• Sub-millisecond requirement → Strong indicator to evaluate Azure NetApp Files, but test and validate.

---

Microsoft Reference Documentation

• Azure Files deployment planning.
• Azure Files SMB protocol.
• Azure Files NFS protocol.
• Azure Files scale and performance targets.
• Azure Files billing and media tiers.
• Azure Files architecture best practices.
• Azure Files backup overview.
• Introduction to Azure File Sync.
• Azure File Sync deployment guide.
• Azure File Sync planning.
• Azure File Sync cloud tiering.
• Azure File Sync disaster-recovery guidance.
• Migrating Windows file servers to Azure Files.
• Introduction to Azure NetApp Files.
• Azure NetApp Files architecture best practices.
• Azure Files and Azure NetApp Files comparison.
• Azure NetApp Files replication.
• Azure NetApp Files cross-zone replication.
• Azure NetApp Files data protection and migration FAQ.

---

File and blob data protection deep dive

Azure File and Blob Data Protection — Review Notes and In-Depth Guide

1. Overview

Azure Storage data protection addresses several different risks:

• Accidental deletion
• Accidental overwrite
• Application corruption
• Ransomware or malicious changes
• Storage-account compromise
• Infrastructure or regional failure
• Regulatory retention requirements
• Long-term backup and recovery

No single feature protects against every risk. A complete design normally combines multiple controls:

Soft delete
   +
Versioning or snapshots
   +
Point-in-time restore
   +
Immutable retention
   +
Operational or vaulted backup
   +
Storage redundancy

The key principle is:

Recovery, immutability, backup and replication solve different problems.

---

2. Protection Features at a Glance

---

3. Blob Soft Delete

What it does

Blob soft delete retains a deleted or overwritten blob for a configurable retention period.

During that period, the blob can be recovered instead of being permanently removed.

Blob exists
    ↓
Blob deleted
    ↓
Soft-deleted state
    ↓
Recoverable during retention period
    ↓
Permanently deleted after expiry

Blob soft-delete retention can currently be configured between 1 and 365 days.

Protects against

• Accidental blob deletion
• Malicious deletion
• Accidental overwrite
• Application errors

Does not fully protect against

• Deletion after the retention period
• Complete storage-account compromise
• Regional disaster by itself
• Long-term regulatory retention
• An attacker disabling protection before deleting data, unless governance controls prevent it

Best practice

Microsoft recommends enabling blob soft delete along with blob versioning and container soft delete for stronger Blob Storage protection.

---

4. Container Soft Delete

Container soft delete protects an entire blob container and its contents when the container itself is deleted.

Container
 ├── Blob A
 ├── Blob B
 └── Blob C
      ↓
Container deleted
      ↓
Container and contents retained temporarily
      ↓
Container can be restored

This is separate from blob soft delete:

• Blob soft delete protects individual blobs.
• Container soft delete protects against deletion of the container.

Both should normally be enabled for important storage accounts. Azure allows a soft-deleted container and its contents to be restored during the configured retention period.

---

5. Blob Versioning

Blob versioning automatically creates a previous version whenever a block blob is modified or deleted.

Example:

contract.pdf
 ├── Version 1
 ├── Version 2
 ├── Version 3
 └── Current version

Useful for

• Recovering overwritten files
• Restoring an earlier blob state
• Investigating application changes
• Protecting against accidental modification
• Maintaining file history

Important distinction

Versioning is different from soft delete:

• Versioning keeps earlier versions after changes.
• Soft delete retains objects after deletion.
• Both may be needed.

Restoring a deleted version can require undeleting the retained versions and then copying the desired previous version to become the current version.

Cost consideration

Every modification can create another stored version. Use lifecycle-management rules to delete old versions after they are no longer required.

---

6. Blob Snapshots

A blob snapshot is a manually created, read-only representation of a blob at a specific moment.

Blob
 ├── Snapshot: Monday
 ├── Snapshot: Tuesday
 └── Current blob

Snapshots are useful when an application needs to explicitly preserve a known state before a change.

Snapshot vs versioning

Snapshots remain associated with the source storage account, so they are not equivalent to an independent backup.

---

7. Point-in-Time Restore for Block Blobs

What it does

Point-in-time restore allows a set of eligible block blobs to be reverted to their condition at an earlier time.

It is useful when:

• An application corrupts many files.
• A batch process changes the wrong blobs.
• Ransomware encrypts or overwrites a group of blobs.
• A user deletes a large number of objects.
• Testing requires restoring a dataset to a known state.

10:00 — Data healthy
11:00 — Faulty application changes thousands of blobs
12:00 — Problem discovered

Restore target: 10:59

Point-in-time restore can revert block blob data within its configured retention range.

Supporting features

Point-in-time restore depends on Blob Storage capabilities including:

• Blob soft delete
• Blob versioning
• Change feed

Azure Blob operational backup configures and manages these underlying capabilities.

Important limitations

Point-in-time restore:

• Applies to block blobs.
• Does not revert append blobs or page blobs.
• Does not restore container-level operations in the same way.
• Must be initiated within the retention window.
• Does not provide an independent offsite copy.
• May not protect against complete account compromise.

Microsoft specifically notes that operations on containers, append blobs and page blobs are not reverted by Blob point-in-time restore.

---

8. Change Feed

Blob change feed maintains an ordered record of changes made to blobs.

It can record events such as:

• Blob creation
• Update
• Deletion
• Metadata changes

Point-in-time restore uses the change feed to determine which changes must be reversed.

Change feed is also useful for:

• Auditing
• Event processing
• Data synchronization
• Replication workflows
• Security analysis

It should not be confused with backup—the change feed records changes but does not by itself preserve an independent full copy.

---

9. Immutable Blob Storage

What it does

Immutable Blob Storage places data into a Write Once, Read Many, or WORM, state.

While the policy applies, protected data cannot be:

• Modified
• Overwritten
• Deleted

This protection remains effective even against highly privileged users, subject to the configured policy.

Common use cases

• Financial records
• Healthcare records
• Audit logs
• Security logs
• Legal evidence
• Government records
• Regulatory archives
• Fraud investigations

---

Time-based retention policy

A time-based policy protects data for a defined duration.

Example:

Retain financial records for 7 years

Until the retention period expires, the protected blobs cannot be deleted or modified.

---

Legal hold

A legal hold protects data indefinitely until an authorized administrator removes the hold.

Typical use cases:

• Litigation
• Regulatory investigation
• Audit
• Employment dispute
• Fraud investigation

---

Locked and unlocked policies

An immutability policy can initially be left unlocked for testing.

After validation, it can be locked to enforce stronger compliance.

Create policy
    ↓
Test while unlocked
    ↓
Confirm application compatibility
    ↓
Legal/compliance approval
    ↓
Lock policy

Once locked, the retention period generally cannot be shortened or removed.

Relationship with soft delete

Immutability and soft delete solve different problems:

• Soft delete allows recovery after deletion.
• Immutability prevents deletion or modification in the first place.

A blob protected by an active immutability policy cannot normally enter the soft-deleted state until the immutable retention expires or the legal hold is removed.

---

10. Azure Blob Backup

Azure Backup supports two broad Blob Storage protection models:

1. Operational backup
2. Vaulted backup

Both currently focus primarily on supported block-blob workloads. Always verify the current support matrix before implementation.

---

Operational Blob backup

Operational backup uses native storage-account features including:

• Point-in-time restore
• Blob soft delete
• Blob versioning
• Change feed
• Resource protection locks

It provides fast, local operational recovery within the source storage account.

Advantages

• Fast recovery
• Continuous protection model
• Restore to a selected time
• No traditional scheduled full backup process
• Simple operational recovery

Limitation

The protected data remains associated with the source storage account. It is therefore less isolated from a full account or subscription compromise than a vaulted copy.

---

Vaulted Blob backup

Vaulted backup creates scheduled recovery points stored through an Azure Backup vault-based architecture.

Azure Backup can currently combine operational and vaulted backup for supported Blob Storage scenarios.

Advantages

• Separate backup recovery points
• Greater isolation from the source account
• Scheduled backup policy
• Longer-term retention options
• Recovery from selected recovery points
• Better protection against source-account compromise

Restore model

• Operational backup restores data to a selected point within the operational retention range.
• Vaulted backup restores data from a scheduled recovery point.

---

11. Azure Files Data Protection

Azure Files supports multiple protection layers:

• File-share snapshots
• Soft delete for file shares
• Azure Backup operational protection
• Azure Backup vaulted protection
• Storage redundancy

---

12. Azure Files Share Snapshots

A share snapshot is a read-only, point-in-time copy of an entire Azure file share.

Azure file share
 ├── Snapshot: Monday
 ├── Snapshot: Tuesday
 └── Current share

Snapshots are useful for:

• Recovering individual files
• Recovering folders
• Restoring overwritten content
• User “previous versions” scenarios
• Fast operational recovery

Because snapshots remain in the same storage account, they should not automatically be treated as an independent, offsite backup.

---

13. Azure Files Soft Delete

Azure Files soft delete protects a file share from accidental deletion.

When an Azure file share is deleted, it is retained in a recoverable state for the configured period.

It protects the share-level object—not necessarily every individual file operation in the same way Blob soft delete protects individual blobs.

For file-level recovery, use:

• Share snapshots
• Azure Backup
• Application or file-history controls

---

14. Azure Backup for Azure Files

Azure Backup provides centralized management for protecting Azure file shares.

Current Azure Files backup options include:

• Snapshot-based operational backup
• Vaulted backup

Azure Backup supports configuring both snapshot and vaulted backup policies through Azure management experiences.

---

Snapshot-based operational backup

Operational Azure Files backup creates and manages file-share snapshots.

Advantages:

• Fast backup
• Fast restoration
• Individual-file restore
• Full-share restore
• Low recovery latency

Limitation:

• Snapshots remain within the source storage account.
• The vault replication setting does not apply to snapshot-only backup because the actual snapshot data does not move into the vault.

---

Vaulted Azure Files backup

Vaulted backup creates a more isolated backup copy outside the operational file-share snapshot layer.

It provides:

• Greater ransomware protection
• Protection from source-account loss
• Central backup policy
• Long-term retention
• Alternate-account restore capabilities in supported scenarios
• Central monitoring and reporting

Microsoft expanded vaulted backup support for Azure Files, including SSD and HDD shares, with retention and offsite protection options depending on configuration.

---

Restore options

Azure Files backup can support recovery of:

• Individual files
• Individual folders
• An entire file share
• Data to the original location
• Data to an alternate location, depending on the backup type and configuration

The exact capabilities depend on:

• File protocol
• Share type
• Region
• Backup model
• Vault type
• Redundancy
• Current feature support

Use the Azure Files backup support matrix before finalizing a design.

---

15. “Full and Incremental Backup” Clarification

The transcript says Azure Backup supports “full, incremental and even more.”

For Azure Files, this terminology can be misleading.

Azure Files backup is based primarily on:

• Storage snapshots for operational protection
• Vaulted recovery points for isolated retention

Azure Backup manages the policy and recovery points, but architects should avoid assuming it works like a traditional server backup product performing repeated full and incremental file copies.

Use the Azure-specific terms:

Operational snapshot backup
Vaulted backup
Recovery point
Retention policy

---

16. Backup Vault and Recovery Services Vault

Azure Backup uses vault resources to organize and secure backup data.

Depending on the protected workload, Azure uses:

• Recovery Services vault
• Backup vault

Backup vaults support newer Azure Backup workloads including Blob Storage and other modern data sources.

Vault features may include:

• Backup policies
• Access control
• Soft delete
• Monitoring
• Immutability
• Multi-user authorization
• Resource Guard
• Alerts and reporting

Always confirm which vault type is required for the selected workload.

---

17. Immutable Backup Vaults

Backup immutability protects recovery points from deletion or reduction of their retention period before expiry.

Azure Backup currently supports locked WORM-style immutable storage for applicable Recovery Services vault scenarios.

This helps protect backups against:

• Ransomware
• Malicious administrators
• Compromised credentials
• Accidental policy changes
• Premature deletion

Vault immutability is separate from Blob Storage immutability:

A highly regulated workload may require both.

---

18. Storage Redundancy vs Backup

Storage replication provides durability and availability.

Examples:

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

However, replication is not backup.

User deletes file
      ↓
Deletion replicated
      ↓
All replicas may reflect deletion

Replication protects mainly against:

• Disk failure
• Server failure
• Datacenter failure
• Availability-zone failure
• Regional failure, depending on the option

Backup and data-protection features protect against:

• Deletion
• Corruption
• Overwrite
• Malware
• Historical recovery requirements

A robust design uses both redundancy and backup.

---

19. Protection Feature Comparison

---

20. Real-World Scenario: Financial Institution

Requirements

A financial institution must:

• Store sensitive customer information.
• Recover accidentally deleted or corrupted data.
• Prevent regulatory records from being modified.
• Retain data for seven years.
• Protect cloud file shares.
• Recover from regional or account-level incidents.
• Maintain auditability.

---

Blob Storage design

Operational recovery

Enable:

• Blob soft delete
• Container soft delete
• Blob versioning
• Change feed
• Point-in-time restore

Application error
      ↓
Thousands of blobs corrupted
      ↓
Restore storage data to a time before corruption

Compliance retention

Enable immutable Blob Storage:

• Seven-year time-based retention
• Legal hold process
• Locked policies after testing and approval

Backup isolation

Configure:

• Operational Blob backup for rapid point-in-time recovery
• Vaulted Blob backup for scheduled, isolated recovery points

Availability

Select appropriate redundancy:

• ZRS for availability-zone resilience
• GRS/GZRS for regional disaster protection
• RA-GRS/RA-GZRS only when secondary-region reads are required

---

Azure Files design

Enable:

• File-share soft delete
• Azure Files backup
• Operational snapshots for fast file recovery
• Vaulted backup for isolated, long-term retention
• Appropriate share redundancy

Azure Files
   ├── Operational snapshots
   ├── Vaulted recovery points
   └── Redundant storage copies

Security controls

Also apply:

• Microsoft Entra authentication
• Least-privilege RBAC
• NTFS permissions for SMB
• Private endpoints
• Secure transfer
• Diagnostic logging
• Defender for Storage
• Backup-vault immutability
• Multi-user authorization for critical backup operations

---

21. Recommended Protection Architecture

                    Production data
                          │
          ┌───────────────┴────────────────┐
          │                                │
     Blob Storage                     Azure Files
          │                                │
 Soft delete + versioning           Share soft delete
          │                                │
 Point-in-time restore              Share snapshots
          │                                │
 Operational Blob backup            Operational backup
          │                                │
 Vaulted Blob backup                Vaulted Files backup
          │                                │
 Immutable blob policy              Immutable vault controls
          └───────────────┬────────────────┘
                          │
              ZRS / GRS / GZRS redundancy

---

22. Corrections and Clarifications

“Container restoration restores all blobs with one request”

Container soft delete allows a deleted container and its contents to be recovered. It is not the same as restoring all blobs in an existing container to a previous time.

Use:

• Container soft delete for a deleted container.
• Point-in-time restore for reverting eligible block blob changes.
• Versioning for individual previous blob states.

---

Soft delete does not prevent deletion

Soft delete permits recovery after deletion.

Immutable storage prevents modification or deletion.

Soft delete  → Recover after deletion
Immutability → Prevent deletion

---

Point-in-time restore is not a universal Storage restore

It is primarily designed for eligible block blobs and has configuration and compatibility requirements.

It does not provide equivalent restore behavior for:

• Append blobs
• Page blobs
• Azure Files
• Every container-level operation

---

Immutability is not backup

Immutable data can still require backup because:

• A legally retained bad or corrupted version may remain immutable.
• An independent recovery copy may be required.
• Storage-account compromise may affect accessibility.
• Regional recovery may still be necessary.

---

Snapshots are not always independent backup copies

Blob and file-share snapshots generally remain associated with the source storage account.

Use vaulted backup when the requirement states:

• Offsite copy
• Independent protection
• Long-term retention
• Ransomware isolation
• Restore after source-account loss

---

23. Best Practices

1. Enable blob and container soft delete.
2. Enable versioning for important block blob data.
3. Configure point-in-time restore where bulk recovery is needed.
4. Use lifecycle policies to remove obsolete versions.
5. Apply immutable policies only after testing retention requirements.
6. Lock immutability policies only after legal approval.
7. Use operational backup for rapid recovery.
8. Use vaulted backup for isolation and long-term retention.
9. Enable Azure Files soft delete and Backup.
10. Use vault immutability for high-value backup data.
11. Separate backup administration from workload administration.
12. Use Resource Guard or multi-user authorization for critical backup operations.
13. Test restores regularly.
14. Monitor backup failures and protection-status changes.
15. Use redundancy and backup together.
16. Document RPO and RTO for each dataset.
17. Verify current service support before choosing account type, protocol or redundancy.

---

24. RPO and RTO Design

Recovery Point Objective

RPO defines the acceptable amount of data loss.

Examples:

RPO = 15 minutes
At most 15 minutes of changes may be lost.

Features affecting RPO:

• Point-in-time restore retention
• Backup frequency
• Snapshot frequency
• Replication lag
• Versioning

Recovery Time Objective

RTO defines how quickly data must be restored.

Examples:

RTO = 1 hour
Service must be recovered within one hour.

Features affecting RTO:

• Operational snapshots
• Point-in-time restore speed
• Vaulted restore speed
• Archive retrieval
• Size of data
• Network throughput
• Alternate-location restore requirements

Typically:

Operational backup → Lower RTO
Vaulted backup     → Better isolation and retention

---

25. Quick Decision Matrix

---

26. AZ-305 Exam Review

Remember these associations:

• Blob soft delete → Recover a deleted or overwritten blob during retention.
• Container soft delete → Recover a deleted container and its contents.
• Blob versioning → Preserve previous block blob versions automatically.
• Blob snapshot → Manually preserve a read-only blob state.
• Point-in-time restore → Revert a set of block blobs to an earlier state.
• Change feed → Records blob changes and supports point-in-time restore.
• Immutable Blob Storage → WORM protection.
• Time-based retention → Protect data for a specific period.
• Legal hold → Protect data until the hold is removed.
• Operational Blob backup → Native point-in-time protection in the source account.
• Vaulted Blob backup → Scheduled, isolated recovery points.
• Azure Files snapshots → Fast operational file recovery.
• Azure Files vaulted backup → Isolated, longer-term backup.
• Replication is not backup.
• Soft delete is not immutability.
• Snapshots are not necessarily offsite copies.
• RPO determines acceptable data loss.
• RTO determines acceptable recovery time.

---

Microsoft Reference Documentation

• Blob data-protection overview.
• Blob soft delete.
• Blob versioning.
• Point-in-time restore for block blobs.
• Immutable Blob Storage.
• Azure Blob Backup overview.
• Blob Backup support matrix.
• Blob operational and vaulted backup configuration.
• Restoring Azure Blobs from backup.
• Azure Files Backup overview.
• Azure Files backup configuration.
• Azure Files backup support matrix.
• Azure Files backup management.
• Azure Backup vault overview.
• Azure Backup immutable WORM protection.

---

Migrating file and blob data deep dive

Migrating File and Blob Data to Azure — Review Notes and In-Depth Guide

1. Overview

Migrating data to Azure is not just about copying files—it involves selecting the right migration method based on:

• Data size
• Network bandwidth
• Downtime tolerance
• Security requirements
• Migration timeline
• Cost
• Whether data needs continuous synchronization
• Recovery and rollback strategy

Azure provides multiple migration tools, each optimized for different scenarios.

Large offline migration
        ↓
Azure Data Box
Azure Import/Export

Online migration
        ↓
AzCopy
Azure Storage Migration Service
Azure File Sync

Hybrid synchronization
        ↓
Azure File Sync

AZ-305 Tip: The exam often asks you to choose the best migration tool rather than asking how the tool works.

---

2. Choosing the Right Migration Tool

---

3. Azure Data Box

What is Azure Data Box?

Azure Data Box is a Microsoft-managed physical appliance used to transfer very large amounts of data into Azure.

Instead of sending data over the Internet:

Microsoft ships device
        ↓
Customer copies data
        ↓
Customer ships device back
        ↓
Microsoft uploads data into Azure Storage

Azure Data Box is useful when:

• Internet bandwidth is insufficient.
• Upload would take weeks or months.
• Initial migration is extremely large.
• Data must be transferred securely.

Microsoft encrypts the device using AES-256 encryption and manages secure chain-of-custody during shipping. (learn.microsoft.com)

---

Data Box family

Microsoft provides several devices depending on capacity.

Azure Data Box Disk

• Microsoft ships encrypted SSD disks.
• Suitable for smaller migrations.

Typical use cases:

• Department migration
• Small office migration
• Initial Azure adoption

---

Azure Data Box

Physical appliance with much larger capacity.

Suitable for:

• Datacenter migration
• Large backup repositories
• Media archives
• Enterprise file servers

---

Azure Data Box Heavy

Largest appliance.

Designed for:

• Hundreds of terabytes
• Petabyte-scale migration
• Massive storage environments

The transcript mentions "up to 80 TB."

Current Azure Data Box offerings and capacities evolve over time, so always verify current limits in Microsoft documentation before planning a migration. (learn.microsoft.com)

---

Advantages

• No Internet bottleneck
• Secure hardware
• Fast initial migration
• Offline transfer
• AES encryption
• Chain-of-custody tracking

---

Limitations

• Shipping time required
• Not real-time
• No ongoing synchronization
• Physical logistics
• Import process required

---

Best suited for

• Initial cloud migration
• Large media libraries
• Backup migration
• Archive migration
• Data center consolidation

---

4. Azure Import/Export Service

What is it?

Azure Import/Export allows customers to ship their own encrypted disks to Azure.

Unlike Data Box:

• Microsoft does not provide the hardware.
• The customer prepares, encrypts and ships disks.

Customer disks
      ↓
Encrypt
      ↓
Ship to Microsoft
      ↓
Azure uploads data

(learn.microsoft.com)

---

Typical scenarios

• Existing data already stored on disks
• One-time migration
• Poor bandwidth
• Archive import
• Large backup import

---

Advantages

• Uses existing disks
• Offline
• Secure
• Cost-effective for some scenarios

---

Limitations

• Customer manages disks
• Shipping coordination
• Manual preparation
• No synchronization

---

Data Box vs Import/Export

---

5. Azure Storage Migration Service

What is it?

Azure Storage Migration Service simplifies migration of Windows file servers to Azure.

It performs:

• Discovery
• Assessment
• Copy
• Cutover

rather than simply copying files.

(learn.microsoft.com)

---

Typical workflow

Existing File Server
       ↓
Assessment
       ↓
Inventory
       ↓
Data Copy
       ↓
Identity Transfer
       ↓
Cutover

---

Features

• Inventory file servers
• Copy data
• Copy permissions
• Copy shares
• Copy network identity
• Minimize downtime

---

Typical migrations

Windows Server

↓

Azure VM

or

Windows Server

↓

New Windows Server

or

Windows Server

↓

Azure File Server

---

Advantages

• Automated migration
• Minimal downtime
• Preserves permissions
• Preserves share configuration
• Migration orchestration

---

Limitations

• Windows file server focus
• Not continuous synchronization
• Primarily migration rather than replication

---

6. Azure File Sync

Azure File Sync is not primarily a migration tool.

Its main purpose is hybrid synchronization.

Azure Files
      ↕
Azure File Sync
      ↕
Windows Server

Use Azure File Sync when:

• Local cache is required
• Branch offices exist
• Hybrid storage is needed
• Existing Windows file servers remain

Azure File Sync provides ongoing synchronization.

(learn.microsoft.com)

---

Cloud Tiering

Azure File Sync can:

Frequently used files
        ↓
Local cache

Rarely used files
        ↓
Azure Files

This reduces local storage requirements.

---

7. AzCopy

What is AzCopy?

AzCopy is Microsoft's high-performance command-line utility for Azure Storage.

It supports:

• Blob Storage
• Azure Files

(Current versions no longer support Azure Table or Queue Storage operations as suggested by the transcript.)

(learn.microsoft.com)

---

Typical uses

• Upload files
• Download files
• Copy between storage accounts
• Synchronize folders
• Copy from on-premises
• Copy between subscriptions
• Scheduled synchronization

---

Example

Local Folder
      ↓
AzCopy
      ↓
Azure Blob

---

Synchronization

AzCopy includes a sync command.

Local Folder

↓

Azure Storage

↓

Sync differences only

Unlike Azure File Sync:

• No continuously running service
• Synchronization occurs only when executed

---

Advantages

• Extremely fast
• Parallel uploads
• Resume capability
• Scriptable
• Automation friendly
• CI/CD integration

---

Common automation

PowerShell

↓

AzCopy

↓

Blob Storage

or

Azure DevOps

↓

AzCopy

↓

Storage Account

or

GitHub Actions

↓

AzCopy

↓

Blob Storage

---

8. Authentication with AzCopy

AzCopy supports several authentication methods.

Preferred:

• Microsoft Entra ID
• Managed Identity
• User Delegation SAS

Also supported:

• SAS
• Storage Account Keys

Avoid embedding account keys directly into scripts whenever possible.

(learn.microsoft.com)

---

9. Online vs Offline Migration

Offline

Data

↓

Physical Device

↓

Azure

Examples:

• Data Box
• Import/Export

Advantages:

• Large datasets
• Poor Internet
• Fast bulk transfer

Disadvantages:

• Shipping
• Manual logistics

---

Online

Local

↓

Network

↓

Azure

Examples:

• AzCopy
• Azure File Sync
• Storage Migration Service

Advantages:

• Immediate
• No shipping
• Flexible

Disadvantages:

• Internet bandwidth
• Long transfer time

---

10. Ongoing Synchronization

Not every migration tool synchronizes continuously.

This is a common exam question.

---

11. Security During Migration

Migration should preserve security.

Consider:

• Encryption in transit
• Encryption at rest
• Disk encryption
• Chain of custody
• RBAC
• SAS security
• Managed Identity
• Customer-managed keys
• Private Endpoints
• Network restrictions

---

12. Large Migration Strategy

Typical enterprise migration:

Initial migration

↓

Azure Data Box

↓

Incremental changes

↓

AzCopy

↓

Final cutover

or

Initial migration

↓

Azure Data Box

↓

Azure File Sync

↓

Final cutover

This minimizes downtime.

---

13. Migration Planning Checklist

Before migrating ask:

Data

• Total size?
• Number of files?
• Largest file?
• Small-file count?

---

Network

• Available bandwidth?
• VPN?
• ExpressRoute?
• Internet speed?

---

Downtime

• Allowed downtime?
• Weekend migration?
• Phased migration?

---

Security

• Encryption?
• Compliance?
• Data residency?
• Private networking?

---

Performance

• Upload time?
• Validation?
• Verification?

---

Cutover

• Rollback?
• DNS?
• User communication?
• Testing?

---

14. Comparison Table

---

15. Scenario 1

Requirements

• 300 TB media archive
• 100 Mbps Internet
• One-time migration

Best solution:

✅ Azure Data Box

Reason:

Network upload would take months.

---

16. Scenario 2

Requirements

Branch offices

Need:

• Local cache
• Cloud storage

Best solution:

✅ Azure File Sync

---

17. Scenario 3

Requirements

Move Windows File Server

Need:

• Shares
• Permissions
• Identity
• Minimal downtime

Best solution:

✅ Azure Storage Migration Service

---

18. Scenario 4

Requirements

Nightly upload

Need:

• Script
• Automation

Best solution:

✅ AzCopy

Example:

Azure Automation

↓

PowerShell

↓

AzCopy

↓

Blob Storage

---

19. Corrections to the Transcript

Azure Migrate Data Box

The transcript says "Azure Migrate Data Box."

These are separate services:

• Azure Migrate → Assessment and migration planning platform.
• Azure Data Box → Physical data transfer appliance.

They are related in migration projects but are separate Azure services.

---

Azure Storage Migration Service

The transcript uses "Azure Storage Migration Service."

The official Microsoft service name is:

Storage Migration Service (SMS)

It is part of Windows Server, not an Azure Storage service.

---

AzCopy support

The transcript says AzCopy supports:

• Blob
• File
• Table
• Queue

Current AzCopy v10 primarily supports:

• Azure Blob Storage
• Azure Files

It no longer supports Azure Table or Queue Storage.

---

"AzCopy synchronization"

AzCopy Sync:

• Is not real-time.
• Does not monitor folders continuously.
• Executes only when run manually or via automation.

Azure File Sync provides continuous synchronization.

---

Data Box capacity

The transcript mentions "80 TB."

Microsoft updates Data Box models periodically.

For exam purposes:

Remember:

Data Box = Physical Microsoft device for very large offline migration

Do not memorize specific capacities.

---

20. Best Practices

1. Assess data before migration.
2. Estimate upload duration.
3. Use Data Box for huge datasets.
4. Use AzCopy for automation.
5. Use Azure File Sync for hybrid scenarios.
6. Validate permissions after migration.
7. Preserve NTFS ACLs.
8. Use checksums to validate copied data.
9. Test restore procedures.
10. Perform pilot migrations.
11. Plan rollback.
12. Use Private Endpoints when appropriate.
13. Prefer Entra ID authentication.
14. Monitor migration jobs.
15. Schedule cutover carefully.

---

21. AZ-305 Exam Review

Remember these associations:

• Azure Data Box → Microsoft-managed offline appliance.
• Import/Export → Customer ships encrypted disks.
• Storage Migration Service → Windows File Server migration.
• Azure File Sync → Hybrid synchronization.
• AzCopy → Command-line Blob/File copy.
• AzCopy Sync → Manual synchronization.
• Offline migration → Data Box or Import/Export.
• Online migration → AzCopy or Storage Migration Service.
• Continuous sync → Azure File Sync only.
• Automation → AzCopy.
• Large datasets with slow Internet → Azure Data Box.
• Existing disks → Import/Export.
• Preserve Windows shares and permissions → Storage Migration Service.

---

Microsoft Reference Documentation

• Azure Data Box overview. (learn.microsoft.com)
• Azure Import/Export Service. (learn.microsoft.com)
• Storage Migration Service overview. (learn.microsoft.com)
• Azure File Sync overview. (learn.microsoft.com)
• Azure File Sync cloud tiering. (learn.microsoft.com)
• AzCopy v10 overview. (learn.microsoft.com)
• Authorize AzCopy with Microsoft Entra ID. (learn.microsoft.com)
• Azure Migrate overview. (learn.microsoft.com)

Cosmos DB design#

Cosmos DB design is a common AZ-305 topic because it requires architecture trade-offs.

• API selection — use the API that matches application requirements and developer experience.
• Partition key — choose a high-cardinality, even distribution key to avoid hot partitions.
• Consistency level — stronger consistency increases latency and RU cost; eventual consistency lowers cost and improves performance.
• Capacity models — provisioned throughput for predictable workloads, autoscale for variable or unpredictable usage.
• Global distribution — enable multi-region for low-latency reads.
• Multi-master — use active-active when write availability across regions is required.

Reference docs:

• https://learn.microsoft.com/azure/cosmos-db/partitioning-overview
• https://learn.microsoft.com/azure/cosmos-db/consistency-levels
• https://learn.microsoft.com/azure/cosmos-db/manage-provisioned-throughput
• https://learn.microsoft.com/azure/cosmos-db/distribute-data-globally

Data protection#

Design storage protection using redundancy, recovery, and compliance controls.

• Geo-redundant storage (GRS/GZRS) — replicate storage across paired regions for disaster recovery.
• Soft delete — enable for blob containers and file shares to protect against accidental deletion.
• Point-in-time restore — use for blob storage and database backups to recover from corruption.
• Immutable storage / WORM — enforce retention policies for compliance scenarios.
• Encryption — use Microsoft-managed keys by default; bring-your-own-key (BYOK) for higher compliance.

Reference docs:

• https://learn.microsoft.com/azure/storage/common/storage-redundancy
• https://learn.microsoft.com/azure/storage/blobs/soft-delete-overview
• https://learn.microsoft.com/azure/storage/blobs/data-protection-overview
• https://learn.microsoft.com/azure/storage/blobs/immutable-storage-overview

---

Domain 3: Business Continuity Solutions (15–20%)#

Azure SLAs and composite SLA#

Business continuity questions assess how to meet availability and recovery targets with the right architecture.

• Composite SLA = product of service SLAs in the application path.
• Use Availability Zones or multi-region deployments to increase uptime.
• RPO (Recovery Point Objective): how much data loss is acceptable.
• RTO (Recovery Time Objective): how quickly services must recover.

Reference docs:

• https://learn.microsoft.com/azure/availability-slas/overview
• https://learn.microsoft.com/azure/site-recovery/overview
• https://learn.microsoft.com/azure/backup/backup-overview

Compute resilience#

• Availability Set — protects against host and rack failures inside one region.
• Availability Zone — isolates resources across separate datacenters within the same region.
• Multi-region active-active — use when the application must remain available despite region failure.
• Scale sets — combine scale and resilience for VM workloads.

Key exam signals:

• choose zones for 99.99% SLA and region-level isolation.
• use Availability Sets when zone support is unavailable for the chosen VM SKU.

Database business continuity#

• Azure SQL Database — use Auto-failover groups for cross-region failover.
• Azure SQL Managed Instance — good for lift-and-shift SQL with managed failover.
• Cosmos DB — multi-region writes and automatic failover for globally distributed apps.
• Azure Storage replication — choose RA-GRS or GZRS for read access after failover.

Reference docs:

• https://learn.microsoft.com/azure/azure-sql/database/high-availability-sla
• https://learn.microsoft.com/azure/azure-sql/database/auto-failover-groups-overview
• https://learn.microsoft.com/azure/cosmos-db/high-availability

Backup and DR architecture#

• Azure Backup — protect VMs, SQL databases, file shares, and other workloads.
• Recovery Services Vault — central vault for backup and site recovery.
• Azure Site Recovery — replicate VMs and orchestrate failover to a secondary region.
• Build recovery plans that sequence app components in the correct order.
• Test failover regularly and maintain documented runbooks.

Reference docs:

• https://learn.microsoft.com/azure/backup/backup-introduction
• https://learn.microsoft.com/azure/site-recovery/site-recovery-overview

---

Domain 4: Infrastructure Solutions (30–35%)#

Compute service selection#

AZ-305 expects the architect to select platforms based on operational model, scale, and modernization intent.

• Azure VMs — use for lift-and-shift, custom OS requirements, legacy apps.
• App Service — best for web apps with fast deployment and built-in platform management.
• AKS — for containerized microservices that need Kubernetes orchestration.
• ACI — launch containers quickly without cluster overhead.
• Azure Functions — event-driven workloads with serverless scale.

Reference docs:

• https://learn.microsoft.com/azure/virtual-machines/overview
• https://learn.microsoft.com/azure/app-service/overview
• https://learn.microsoft.com/azure/aks/overview
• https://learn.microsoft.com/azure/container-instances/container-instances-overview
• https://learn.microsoft.com/azure/azure-functions/functions-overview

Compute platform deep dives#

Use these deep dives to connect AZ-305 design choices to the operational details that appear in scenario questions.

---

Container technologies in Azure deep dive

Container Technologies in Azure — Review Notes and In-Depth Guide

1. Overview

Containers package an application together with its:

• Runtime
• Libraries
• Dependencies
• Configuration
• Supporting binaries

This produces a portable deployment unit that behaves consistently across development, testing, and production environments.

Application
   +
Runtime
   +
Libraries
   +
Dependencies
   ↓
Container image

Containers are useful because they are:

• Lightweight
• Portable
• Fast to start
• Easy to replicate
• Suitable for automation
• Well suited to microservices and distributed applications

Azure offers several container-hosting choices. The three core services covered in the transcript are:

1. Azure Container Instances
2. Azure Container Apps
3. Azure Kubernetes Service

Microsoft’s container-service selection guidance emphasizes balancing control against operational simplicity: more control generally creates more management responsibility.

---

2. Containers vs Container Images

A container image is the packaged, read-only template.

A container is a running instance of that image.

Container image
      ↓ run
Running container

For example:

Image:
mycompany/orders-api:1.4

Running instances:
orders-api-1
orders-api-2
orders-api-3

Multiple containers can be created from the same image.

Images are commonly stored in a container registry such as:

• Azure Container Registry
• GitHub Container Registry
• Docker Hub
• Other OCI-compatible registries

For enterprise Azure deployments, Azure Container Registry is often used because it integrates with Microsoft Entra ID, managed identities, private networking, and Azure container services.

---

3. Containers vs Virtual Machines

Containers and virtual machines provide different levels of isolation and control.

Virtual machine architecture

Physical host
    ↓
Hypervisor
    ├── VM 1
    │    ├── Guest OS
    │    └── Application
    └── VM 2
         ├── Guest OS
         └── Application

Each VM includes a complete guest operating system.

Container architecture

Physical or virtual host
    ↓
Host operating system
    ↓
Container runtime
    ├── Container 1
    ├── Container 2
    └── Container 3

Containers share the host kernel while maintaining process, network, and file-system isolation.

---

Comparison

Choose containers when

• The application can be packaged into an image.
• Fast deployment is important.
• Horizontal scaling is expected.
• The workload is stateless or externally stores state.
• CI/CD and immutable releases are desired.
• Microservices or worker processes are used.

Choose VMs when

• Full OS control is required.
• Custom kernel modules or drivers are needed.
• The application depends on a traditional server environment.
• Legacy software cannot be containerized.
• The workload requires interactive desktop access.
• Vendor licensing or support requires a VM.

Containers are not automatically better than VMs. The correct choice depends on application architecture and operational requirements.

---

4. Azure Container Service Selection

A practical Azure decision model is:

Do you need Kubernetes APIs or direct cluster control?
        │
        ├── Yes → AKS
        │
        └── No
             │
             ├── Need event-driven scaling, revisions,
             │   ingress, microservices or long-running apps?
             │       └── Yes → Azure Container Apps
             │
             └── Need to run a simple container or container group?
                     └── Azure Container Instances

Microsoft’s compute and container decision guides recommend evaluating application architecture, portability, networking, scaling, security, orchestration, and the operational skills of the team before selecting a service.

---

5. Azure Container Instances

What is ACI?

Azure Container Instances, or ACI, runs Linux or Windows containers without requiring the customer to provision or manage virtual machines or a Kubernetes cluster.

It provides one of the fastest ways to run an isolated container in Azure.

Container image
      ↓
Azure Container Instances
      ↓
Running container

ACI is best understood as container execution without orchestration.

---

Common use cases

ACI is suitable for:

• Short-lived jobs
• Build agents
• Batch tasks
• Development and test
• Data-processing jobs
• Scheduled scripts
• Proofs of concept
• Temporary API endpoints
• Containerized automation
• Event-triggered processing

Example:

Queue message
     ↓
Workflow starts ACI
     ↓
Container processes file
     ↓
Container exits

---

Main benefits

• No VM administration
• Fast startup
• Linux and Windows container support
• Pay for allocated CPU and memory while the container runs
• Public or private network options
• Ability to mount supported storage
• Suitable for automation
• Simple deployment model

Microsoft describes ACI as a managed, serverless environment for running containers without managing underlying VMs or an orchestrator.

---

6. ACI Container Groups

ACI supports container groups.

A container group contains one or more containers that:

• Run on the same host
• Share a lifecycle
• Share local networking
• Can share mounted storage
• Are deployed and stopped together

ACI container group
   ├── Main application container
   ├── Logging sidecar
   └── Proxy sidecar

The concept is similar to a Kubernetes pod, although ACI does not provide the broader Kubernetes orchestration platform.

---

ACI limitations

ACI is usually not the best choice when the application requires:

• Advanced traffic routing
• Automated rolling deployments
• Large-scale orchestration
• Complex service discovery
• Advanced autoscaling
• Kubernetes operators
• Persistent cluster-level controllers
• Large microservice environments
• Complex stateful applications

ACI can run multiple containers in a group, but it does not replace a full orchestration platform.

---

7. Azure Container Apps

What is Azure Container Apps?

Azure Container Apps, or ACA, is a serverless application platform for running containerized applications without directly managing the underlying infrastructure or Kubernetes cluster.

It is designed for modern applications that need more application-platform capabilities than ACI but do not require direct Kubernetes administration.

Container images
      ↓
Azure Container Apps environment
      ↓
Container Apps
      ↓
Automatically managed replicas

---

Common workloads

Container Apps is well suited for:

• Web applications
• APIs
• Microservices
• Background workers
• Event-driven processors
• Queue consumers
• Scheduled jobs
• Internal services
• Containerized functions
• Applications that scale based on demand

Microsoft identifies APIs, microservices, background processing, event-driven applications, and web workloads as common Container Apps scenarios.

---

8. Container Apps Features

Automatic scaling

Container Apps can scale based on signals such as:

• HTTP traffic
• Events
• Queue length
• CPU or memory
• Custom KEDA-supported scale rules

Depending on configuration and workload type, applications can scale down significantly when idle, including scale-to-zero scenarios.

No demand
   ↓
Zero or minimal replicas

Traffic arrives
   ↓
Replicas start

Demand increases
   ↓
Additional replicas

---

Ingress

Container Apps can expose applications through managed ingress.

Ingress can support:

• Public access
• Internal-only access
• HTTP and HTTPS
• Custom domains
• TLS
• Traffic routing
• Communication between apps in the environment

Microsoft documents that Container Apps can expose applications to the public web, to a VNet, or to other applications inside the environment.

---

Revisions

Container Apps supports revisions, which represent deployable versions of an application.

Example:

Revision 1 → version 1.0
Revision 2 → version 1.1

Revisions can support:

• Rolling releases
• Blue-green deployment
• Traffic splitting
• Testing a new application version
• Fast rollback

90% traffic → Revision 1
10% traffic → Revision 2

---

Jobs

Azure Container Apps jobs are suited to processes that run to completion rather than serving continuous traffic.

Examples:

• Scheduled report generation
• Database maintenance
• Batch processing
• Queue-triggered jobs
• Data transformation

---

Dapr integration

Container Apps supports optional Dapr capabilities for distributed applications, including patterns such as:

• Service invocation
• Pub/sub
• State management
• Secrets access
• Bindings

Dapr is useful but should be selected only when its abstractions improve the application. It is not mandatory for Container Apps.

---

9. Container Apps Environments

Container Apps are deployed into a Container Apps environment.

An environment provides a boundary for:

• Networking
• Logging
• Application communication
• Security configuration
• Workload profiles
• Shared platform capabilities

Container Apps environment
   ├── Frontend app
   ├── Orders API
   ├── Payment worker
   └── Scheduled cleanup job

Applications in the same environment can communicate using internal service names and managed platform networking.

---

10. Container Apps Consumption and Workload Profiles

Container Apps supports hosting models intended for different workload requirements.

Architects should consider:

• Scale-to-zero requirements
• Baseline always-on capacity
• CPU and memory needs
• Dedicated compute requirements
• GPU requirements where supported
• Networking and environment type
• Cost predictability

The exact available profiles and features continue to evolve, so verify current regional support before selecting a production design.

---

11. When to Choose Container Apps

Choose Azure Container Apps when:

• You want serverless container hosting.
• You do not want to manage Kubernetes.
• The application needs automatic scaling.
• HTTP or event-driven workloads are used.
• Scale-to-zero can reduce costs.
• You need revisions and traffic splitting.
• The application consists of APIs, workers, jobs, or microservices.
• Managed ingress is sufficient.
• Full Kubernetes APIs are not required.

---

When Container Apps may not be sufficient

Evaluate AKS when the workload requires:

• Kubernetes custom resource definitions
• Operators
• DaemonSets
• Direct node control
• Specialized networking plugins
• Full ingress-controller control
• Service meshes not supported by the managed platform
• Complex stateful Kubernetes workloads
• Portable Kubernetes manifests as a primary requirement
• Advanced cluster governance
• Custom admission controllers

---

12. Azure Kubernetes Service

What is AKS?

Azure Kubernetes Service, or AKS, is Microsoft’s managed Kubernetes service.

Azure manages much of the Kubernetes control-plane infrastructure, while the customer remains responsible for designing and operating the workload, node pools, networking, security, application deployment, and cluster lifecycle.

Azure-managed control plane
            ↓
AKS cluster
   ├── System node pool
   ├── Application node pool
   ├── GPU node pool
   └── Windows node pool

AKS provides the greatest control of the three principal services, but it also requires the greatest Kubernetes expertise.

---

13. Kubernetes Concepts

Cluster

The complete Kubernetes environment.

Control plane

Manages:

• Kubernetes API
• Scheduling
• Cluster state
• Controllers

In AKS, Microsoft manages the control plane service, but the customer still manages cluster configuration and workload behavior.

Node

A VM that runs container workloads.

Node pool

A group of nodes with similar configuration.

Examples:

System node pool
General application node pool
Memory-optimized node pool
GPU node pool
Windows node pool

Pod

The smallest Kubernetes deployment unit.

A pod contains one or more tightly coupled containers.

Deployment

Defines desired application replicas and rollout behavior.

Service

Provides stable networking for pods.

Ingress

Routes external HTTP or HTTPS traffic to services.

Namespace

Provides logical organization and can support policy and access boundaries.

---

14. AKS Capabilities

AKS supports:

• Kubernetes-native deployment
• Horizontal and vertical scaling patterns
• Cluster autoscaling
• Multiple node pools
• Linux and Windows workloads
• GPU nodes
• Persistent storage
• Advanced networking
• Ingress controllers
• Service meshes
• Kubernetes RBAC
• Microsoft Entra integration
• Azure Policy
• GitOps
• CI/CD
• Kubernetes operators
• StatefulSets
• Custom resource definitions

AKS networking includes Kubernetes networking layers for pod, service, ingress, and external connectivity.

---

15. AKS Automatic

Microsoft also offers AKS Automatic, which provides a more opinionated and simplified AKS experience for common Kubernetes scenarios.

It aims to reduce configuration effort by applying managed defaults and automation while retaining Kubernetes compatibility.

AKS Automatic may be appropriate when:

• Kubernetes compatibility is required.
• The team wants less cluster setup work.
• Opinionated platform defaults are acceptable.
• The workload does not require complete customization of every cluster component.

It still remains Kubernetes and should not be treated as operationally identical to Container Apps.

---

16. AKS Operational Responsibilities

AKS is managed, but it is not operationally hands-off.

The workload team must plan:

• Kubernetes version upgrades
• Node image upgrades
• Node pool design
• Capacity
• Pod resource requests and limits
• Networking
• Ingress
• DNS
• Security policies
• Secrets
• Persistent storage
• Monitoring
• Backup
• Workload availability
• Autoscaling
• Cost
• Disaster recovery

Microsoft manages the control-plane service, but the customer remains responsible for workload and cluster configuration.

---

17. When to Choose AKS

Choose AKS when:

• Kubernetes APIs are required.
• The organization already has Kubernetes skills.
• The application uses many coordinated microservices.
• Advanced networking is necessary.
• Custom controllers or operators are required.
• The workload requires specialized node pools.
• Stateful Kubernetes workloads are used.
• Portability across Kubernetes environments is important.
• Complex deployment strategies are required.
• Platform teams need full governance and policy control.

---

When AKS may be excessive

AKS may create unnecessary complexity for:

• One small API
• One background worker
• A temporary processing task
• A basic web application
• A workload with no Kubernetes requirement
• A small team without Kubernetes skills

Do not choose AKS simply because Kubernetes is popular. Choose it when the workload or organizational platform strategy genuinely requires Kubernetes.

---

18. ACI vs Container Apps vs AKS

---

19. ACI vs Container Apps

The distinction is particularly important.

ACI

Think:

Run this container.

ACI provides a simple container runtime.

Container Apps

Think:

Run, expose, version, and automatically scale this application.

Container Apps adds application-platform concepts including:

• Revisions
• Ingress
• Scaling
• Environments
• Managed service communication
• Jobs
• Application-level traffic management

Microsoft’s service comparison describes Container Apps as providing application-specific abstractions, while ACI focuses on direct container execution.

---

20. Container Apps vs AKS

Container Apps

The platform hides most Kubernetes infrastructure and orchestration details.

Best when:

• The team wants application-level abstractions.
• Kubernetes expertise is not desired.
• Managed scaling and ingress are sufficient.
• Operational simplicity is a priority.

AKS

The team directly works with Kubernetes objects and cluster architecture.

Best when:

• Kubernetes compatibility is required.
• Custom platform components are needed.
• Advanced orchestration is necessary.
• A platform-engineering team operates the cluster.

More simplicity                         More control
ACI → Container Apps → AKS

---

21. Container Images and Azure Container Registry

A typical enterprise container workflow uses Azure Container Registry:

Source code
    ↓
CI pipeline
    ↓
Build container image
    ↓
Security scan
    ↓
Azure Container Registry
    ↓
ACI / Container Apps / AKS

Recommended controls include:

• Microsoft Entra authentication
• Managed identities
• Private endpoints
• Image scanning
• Immutable tags or controlled promotion
• Separate development and production registries or repositories
• Content trust and software supply-chain controls
• Retention policies
• Geo-replication where required

Avoid using long-lived registry admin credentials in production deployments.

---

22. Container Image Design

Good container images should be:

• Small
• Repeatable
• Versioned
• Scanned
• Minimal
• Non-interactive
• Free of embedded secrets

Recommended practices:

1. Use trusted base images.
2. Pin image versions.
3. Apply multi-stage builds.
4. Remove build tools from runtime images.
5. Run as a non-root user where possible.
6. Do not embed secrets.
7. Scan dependencies.
8. Patch and rebuild regularly.
9. Use health checks.
10. Log to standard output and standard error.

---

23. State Management

Containers should ideally be disposable.

Do not store important persistent state only inside a container’s writable layer.

Container deleted
       ↓
Local writable data lost

Store state in external services such as:

• Azure SQL Database
• Azure Cosmos DB
• Azure Storage
• Azure Files
• Managed disks through Kubernetes storage
• Azure Cache for Redis
• Managed database services

This enables containers to be replaced, restarted, or scaled without losing business data.

---

24. Networking

Container networking differs by service.

ACI

Can support:

• Public IP access
• Private VNet integration
• Container-group networking
• DNS labels
• Basic port exposure

Container Apps

Can support:

• External ingress
• Internal ingress
• VNet integration
• Environment-level networking
• Service-to-service communication
• Private endpoints and private environments in supported designs

AKS

Provides the greatest networking flexibility, including decisions around:

• Kubernetes networking model
• Pod IP allocation
• Service CIDRs
• Ingress controllers
• Network policies
• Private clusters
• Egress control
• Load balancers
• Application Gateway integration
• Azure CNI options

The AKS network architecture must be planned before deployment because address-space and networking choices can be difficult to change later.

---

25. Security

Container security should follow defense in depth.

Trusted source code
       ↓
Secure build pipeline
       ↓
Scanned image
       ↓
Protected registry
       ↓
Secure container platform
       ↓
Runtime monitoring

Key controls

• Use managed identities.
• Store secrets in Key Vault.
• Use private registries.
• Restrict registry access.
• Scan images for vulnerabilities.
• Use current base images.
• Run as non-root where possible.
• Use read-only file systems where appropriate.
• Restrict network access.
• Apply least privilege.
• Monitor runtime behavior.
• Sign and verify critical images.
• Rebuild images when dependencies are patched.

Microsoft Defender for Cloud provides security recommendations for serverless container services including ACI and Container Apps.

---

26. Managed Identity

Managed identities allow containers to access Azure resources without storing passwords or client secrets.

Example:

Container App
      ↓ managed identity
Microsoft Entra ID
      ↓ token
Key Vault / Storage / Service Bus

Use managed identity for:

• Azure Key Vault
• Azure Storage
• Azure Service Bus
• Azure SQL
• Azure Container Registry
• Other Entra-protected services

---

27. Secrets

Secrets should not be:

• Embedded in images
• Stored in Dockerfiles
• Committed to Git
• Passed as plain command-line arguments
• Printed in logs

Use:

• Azure Key Vault
• Managed identities
• Container Apps secret references
• Kubernetes Secrets combined with Key Vault integration
• Workload identity in AKS

Remember that Kubernetes Secrets are not automatically equivalent to an external hardened secret-management system.

---

28. Scaling

ACI

Scaling generally requires application or automation logic to start additional container groups.

Container Apps

Scaling is platform managed using configured rules.

HTTP requests increase
        ↓
More replicas

Queue becomes empty
        ↓
Replicas decrease

AKS

Scaling can occur at multiple levels:

• Horizontal Pod Autoscaler
• Vertical Pod Autoscaler
• Cluster Autoscaler
• KEDA
• Node-pool scaling
• Manual scaling

AKS provides the most flexibility but requires careful configuration of resource requests, limits, scheduling, and node capacity.

---

29. Availability

Containers do not automatically make applications highly available.

A resilient design requires:

• Multiple replicas
• Health probes
• Load balancing
• Zone-aware deployment
• Externalized state
• Database resilience
• Retry logic
• Idempotent processing
• Disaster-recovery planning

For AKS, Microsoft provides multiregion reference architectures for active-active or high-availability cluster designs.

---

30. Monitoring and Logging

A complete container-monitoring design should include:

• Application logs
• Container stdout and stderr
• CPU and memory
• Replica count
• Restart count
• Request rate
• Error rate
• Latency
• Dependency health
• Scaling events
• Image and deployment version
• Security events

Possible Azure tools include:

• Azure Monitor
• Log Analytics
• Application Insights
• Container Insights
• Managed Prometheus
• Managed Grafana
• Microsoft Defender for Cloud

Avoid storing important logs only inside the running container because container-local storage can disappear when the container is replaced.

---

31. CI/CD and GitOps

Container platforms work best with automated delivery.

Typical workflow:

Developer commits code
        ↓
Pipeline runs tests
        ↓
Container image built
        ↓
Image scanned
        ↓
Image pushed to ACR
        ↓
Deployment updated
        ↓
Health validation
        ↓
Traffic shifted

For AKS, GitOps can use repository state as the desired cluster configuration.

For Container Apps, pipelines can deploy a new revision and gradually shift traffic.

For ACI, pipelines or workflows can create container groups for temporary jobs or tests.

---

32. Cost Model

ACI

Typical costs are based on allocated container resources and execution duration.

Best when:

• Workloads are short-lived.
• Containers do not run continuously.
• Cluster administration would be wasteful.

Container Apps

Cost depends on the selected hosting model, active resources, requests, replicas, and workload-profile configuration.

It can be cost effective when:

• Workloads scale dynamically.
• Applications can scale down when idle.
• Managed platform features reduce operational effort.

AKS

Costs can include:

• Worker nodes
• Control-plane pricing tier
• Load balancers
• Managed disks
• Log ingestion
• Network egress
• Container registry
• Security services
• Idle cluster capacity
• Platform-team operations

AKS offers several cluster-management pricing tiers with different support and availability characteristics.

A service with the lowest infrastructure charge is not always the lowest total cost. Include engineering and operational effort.

---

33. Scenario 1: Short-Lived Image Processing

Requirements

• Process an uploaded image.
• Job lasts approximately two minutes.
• No public web endpoint is required.
• No orchestration is needed.
• Process ends after completion.

Recommended service

Azure Container Instances

Blob uploaded
    ↓
Event triggers workflow
    ↓
ACI starts
    ↓
Image processed
    ↓
Container exits

---

34. Scenario 2: Event-Driven API and Worker

Requirements

• Public REST API
• Queue-processing worker
• Unpredictable traffic
• Scale-to-zero desired
• No need for Kubernetes APIs
• Managed revisions and traffic routing required

Recommended service

Azure Container Apps

Internet
   ↓
Container App API
   ↓
Service Bus
   ↓
Container App worker

---

35. Scenario 3: Enterprise Kubernetes Platform

Requirements

• Fifty microservices
• Kubernetes operators
• Custom ingress controller
• Linux and Windows workloads
• GPU processing
• Multiple node pools
• GitOps
• Advanced network policies

Recommended service

Azure Kubernetes Service

Container Apps would hide or restrict many of the required Kubernetes-level capabilities.

---

36. Scenario 4: Legacy Application

Requirements

• Requires Windows desktop components
• Installs a kernel driver
• Depends on a traditional server installer
• Cannot run as a stateless service

Recommended service

Azure Virtual Machine

The application is not currently a good container candidate.

---

37. Common Misconceptions

“All containers are serverless”

Containers are a packaging and runtime model.

A container can run on:

• A VM
• AKS
• Container Apps
• ACI
• An on-premises server
• A developer workstation

“Serverless” describes the operational and billing abstraction of a hosting service, not the container itself.

---

“AKS is fully managed, so Microsoft manages everything”

Microsoft manages the AKS control-plane service, but the customer remains responsible for:

• Worker nodes
• Cluster upgrades
• Workload configuration
• Networking
• Security
• Scaling
• Monitoring
• Application availability
• Cost

---

“Microservices require Kubernetes”

Microservices can run on:

• Azure Container Apps
• AKS
• App Service
• Functions
• Other platforms

Kubernetes is one orchestration option, not a requirement.

---

“ACI is the same as Container Apps”

ACI runs containers directly.

Container Apps provides a managed application platform with scaling, ingress, revisions, environments, and event-driven features.

---

“Containers are always stateless”

Containers can run stateful workloads, but durable state should normally be externalized or backed by persistent storage.

Stateful design adds complexity and must include backup and recovery planning.

---

38. Corrections and Clarifications to the Transcript

Containers are not always PaaS

The transcript describes container technologies as belonging to PaaS.

That is an oversimplification.

• ACI and Container Apps provide highly managed container-hosting experiences.
• AKS is a managed Kubernetes service but still exposes significant infrastructure and cluster-management responsibilities.
• Containers can also run directly on IaaS virtual machines.

The service model depends on the hosting platform, not the container format itself.

---

ACI and Container Apps are both called serverless

Both remove direct VM administration, but they serve different purposes:

• ACI is direct container execution.
• Container Apps is a serverless application platform.

---

AKS does not remove all Kubernetes management

AKS reduces control-plane management but still requires Kubernetes operations and platform engineering.

---

Containers do not provide complete VM-equivalent isolation

Containers share a host kernel. They provide strong process and namespace isolation, but VMs provide a separate guest operating-system boundary.

---

“Containers are for microservices, VMs are for monoliths”

This is not absolute.

• Monolithic applications can run in containers.
• Microservices can run on VMs.
• The decision depends on deployment, scaling, isolation, and operational requirements.

---

39. Decision Matrix

---

40. AZ-305 Exam Review

Remember these associations:

• Container image → Packaged application and dependencies.
• Container → Running image instance.
• ACI → Fast, simple container execution without orchestration.
• ACI container group → Containers sharing lifecycle, networking, and resources.
• Container Apps → Serverless application platform for APIs, jobs, workers, and microservices.
• Container Apps revisions → Versioning, traffic splitting, and rollback.
• Container Apps scaling → HTTP, event, and KEDA-based scaling.
• AKS → Managed Kubernetes with the greatest control and complexity.
• AKS node pool → Group of similarly configured worker nodes.
• Pod → Smallest Kubernetes deployment unit.
• AKS Automatic → More opinionated, simplified AKS experience.
• Azure Container Registry → Private Azure container-image registry.
• Managed identity → Secretless access to Azure resources.
• Externalized state → Durable data outside the container’s writable layer.
• VM → Choose when full OS control or legacy compatibility is required.
• Microservices do not automatically require AKS.
• Managed Kubernetes does not mean zero operations.
• Containers do not automatically provide high availability.

---

Microsoft Reference Documentation

• Azure container-services documentation.
• Choose an Azure container service.
• Choose an Azure compute service.
• Azure container architecture guidance.
• Azure Container Instances documentation.
• Azure Container Instances overview.
• ACI container groups.
• Azure Container Apps overview.
• Azure Container Apps documentation.
• Container Apps ingress.
• Container Apps comparison with other services.
• Azure Kubernetes Service overview.
• AKS core concepts.
• AKS Automatic.
• AKS networking concepts.
• AKS architecture best practices.
• AKS multiregion reference architecture.
• AKS pricing tiers.
• Defender for Cloud recommendations for serverless containers.

---

Choosing Container Technologies deep dive

Choosing Azure Container Technologies — Review Notes and In-Depth Guide

1. Core Decision

Azure provides several ways to run containers, but the three main services in this lesson are:

• Azure Container Instances (ACI)
• Azure Container Apps (ACA)
• Azure Kubernetes Service (AKS)

The main trade-off is:

Less infrastructure management                    More control
ACI  →  Azure Container Apps  →  AKS

Choose based on:

• Workload duration
• Application complexity
• Scaling requirements
• Need for orchestration
• Kubernetes compatibility
• Networking and security requirements
• Team expertise
• Operational effort
• Cost model

Microsoft’s current architecture guidance emphasizes that no container service is best for every workload; service selection should balance required control against operational complexity.

---

2. Quick Decision Tree

Do you require Kubernetes APIs, operators, CRDs,
custom node pools, or direct cluster control?
        │
        ├── Yes → AKS
        │
        └── No
             │
             ├── Is this a long-running application,
             │   API, microservice, worker, or event-driven job
             │   needing autoscaling, ingress, and revisions?
             │       └── Yes → Azure Container Apps
             │
             └── Is this a simple, isolated, short-lived,
                 or manually controlled container workload?
                     └── Yes → Azure Container Instances

---

3. Azure Container Instances

What ACI is

Azure Container Instances runs Linux or Windows containers without requiring you to create or manage virtual machines or a Kubernetes cluster. It is a low-level, serverless container execution service rather than a complete application orchestration platform.

Think of ACI as:

“Run this container now.”

---

Best use cases

ACI is well suited for:

• Short-lived processing
• Temporary build agents
• Development and testing
• Proofs of concept
• One-off scripts
• Batch tasks
• Data conversion
• Image or document processing
• Temporary diagnostic tools
• Bursty isolated workloads

Example:

File uploaded
      ↓
ACI container starts
      ↓
File processed
      ↓
Result saved
      ↓
Container stops

ACI supports container groups, where multiple closely related containers share lifecycle, networking, and allocated resources. The model resembles a Kubernetes pod but does not provide a Kubernetes control plane or cluster-level orchestration.

---

Strengths

• Very fast to deploy
• No cluster management
• Supports Linux and Windows containers
• Suitable for isolated jobs
• Pay for allocated compute while the workload runs
• Good for automation
• Supports multi-container groups
• Useful for burst or temporary capacity

ACI also supports regular, confidential, and Spot container scenarios in current Azure offerings, subject to region and feature support.

---

Limitations

ACI does not natively provide a full application platform with:

• Automatic replica scaling
• Managed rolling deployment
• Built-in revision management
• Advanced traffic splitting
• Kubernetes service discovery
• Cluster autoscaling
• Kubernetes operators
• Complex ingress management
• Automatic self-healing across a managed fleet
• Advanced orchestration

Microsoft describes ACI as a lower-level building block than Container Apps. Capabilities such as application-level scaling, managed certificates, traffic management, and load-balancing abstractions must be implemented separately or by choosing a higher-level service.

---

Choose ACI when

Use ACI when:

• The workload is simple.
• It runs for a limited duration.
• You control when instances start and stop.
• Only basic networking is required.
• Kubernetes is unnecessary.
• You need a fast and isolated execution environment.

---

Do not choose ACI when

Avoid ACI as the primary platform when:

• You need many coordinated microservices.
• You need automatic HTTP or event scaling.
• You need zero-downtime revision rollout.
• You need application traffic splitting.
• You need Kubernetes APIs.
• You require sophisticated orchestration.

---

4. Azure Container Apps

What Container Apps is

Azure Container Apps is a managed, serverless application platform for running containerized applications without exposing most underlying Kubernetes infrastructure.

It is designed for:

• APIs
• Web applications
• Microservices
• Event-driven workers
• Background processors
• Scheduled jobs
• Queue consumers

Container Apps supports managed ingress, revisions, traffic splitting, KEDA-based scaling, and scale-to-zero for suitable workloads.

Think of Container Apps as:

“Run, expose, scale, and version this containerized application.”

---

Best use cases

Container Apps is often the best choice for:

• REST APIs
• Internal APIs
• Event-driven services
• Queue-processing workers
• Lightweight microservices
• Background tasks
• Scheduled container jobs
• Applications with unpredictable traffic
• Workloads that benefit from scale-to-zero
• Teams that do not want to manage Kubernetes

---

Important features

Automatic scaling

Container Apps uses declarative scaling rules. A revision can scale out by creating replicas based on configured demand signals.

Scaling can be based on:

• HTTP requests
• Queue length
• Event sources
• CPU or memory
• KEDA-supported triggers

No workload
    ↓
Zero or minimum replicas

Traffic arrives
    ↓
Replicas are created

Traffic increases
    ↓
More replicas are created

Not every configuration can scale to zero. Some scale rules or always-on requirements require one or more minimum replicas.

---

Revisions

A revision represents a deployable version of a container app.

Container Apps can run multiple revisions and route traffic between them.

Example:

Revision A — application v1
Revision B — application v2

90% traffic → Revision A
10% traffic → Revision B

This supports:

• Blue-green deployments
• Canary releases
• A/B testing
• Controlled rollback
• Testing a new version with limited traffic

Container Apps jobs are different: jobs run to completion and do not use the same revision model as continuously running container apps.

---

Jobs

Container Apps jobs run containerized work that starts, completes, and stops.

Jobs can support:

• Manual execution
• Scheduled execution
• Event-triggered execution
• Retries
• Timeouts
• Parallelism

Examples:

• Nightly report generation
• Database maintenance
• Queue batch processing
• File conversion
• Data cleanup
• Scheduled synchronization

---

Managed ingress

Container Apps can provide managed application ingress so you do not need to deploy and maintain your own basic ingress controller for common HTTP workloads.

It can support:

• Public endpoints
• Internal-only endpoints
• HTTPS
• Custom domains
• Application-level traffic routing
• Communication between apps in the same environment

---

Strengths

• Minimal infrastructure management
• Automatic application scaling
• Suitable for microservices
• Supports event-driven workloads
• Managed ingress
• Revision management
• Traffic splitting
• Jobs for run-to-completion workloads
• Scale-to-zero where supported
• Lower operational burden than AKS
• Containers remain portable at the image level

---

Limitations

Container Apps intentionally hides many Kubernetes details.

It is not appropriate when you require:

• Kubernetes CRDs
• Custom operators
• DaemonSets
• Direct node administration
• Custom admission controllers
• Full control of the Kubernetes API
• Highly customized networking plugins
• Arbitrary cluster-level controllers
• Complete control of ingress implementation
• Advanced node scheduling rules
• Specialized cluster extensions not supported by the service

---

Choose Container Apps when

Use Container Apps when:

• You want serverless container hosting.
• You need APIs, workers, or microservices.
• Traffic is variable.
• Automatic scaling is useful.
• You want revisions and controlled releases.
• You do not need full Kubernetes control.
• Operational simplicity matters.

---

Do not choose Container Apps when

Consider AKS instead when:

• Kubernetes compatibility is a firm requirement.
• You use Helm charts that depend on cluster-level objects.
• You require operators or CRDs.
• You need custom node pools and scheduling behavior.
• You need deep networking or policy control.
• A platform engineering team already manages Kubernetes.

---

5. Azure Kubernetes Service

What AKS is

Azure Kubernetes Service is Azure’s managed Kubernetes offering.

Microsoft manages the Kubernetes control-plane service, while customers still design and operate significant parts of the cluster and workloads, including:

• Node pools
• Workload configuration
• Networking
• Storage
• Scaling
• Security
• Upgrades
• Monitoring
• Availability
• Cost management

AKS currently supports two cluster modes:

• AKS Automatic
• AKS Standard

Think of AKS as:

“Provide a full Kubernetes platform.”

---

AKS Standard

AKS Standard provides the greatest infrastructure and Kubernetes configuration control.

Use it when you need:

• Custom node pools
• Specialized VM sizes
• GPU nodes
• Windows node pools
• Custom autoscaling
• Complex network design
• Kubernetes operators
• CRDs
• Custom ingress controllers
• Advanced security policies
• GitOps
• StatefulSets
• Advanced scheduling
• Platform-level extensions

---

AKS Automatic

AKS Automatic provides a more opinionated and managed Kubernetes experience.

Microsoft configures more production-ready defaults around:

• Node management
• Scaling
• Security
• Monitoring
• Upgrades
• Cluster operations

It is designed for teams that require Kubernetes compatibility but want less cluster-management work.

Current Microsoft guidance positions AKS Automatic as the recommended production-ready default for many AKS workloads, while AKS Standard remains appropriate where greater infrastructure control is required.

---

Best use cases

AKS is appropriate for:

• Large microservice platforms
• Enterprise Kubernetes platforms
• Multi-team application estates
• Kubernetes-native applications
• Custom operators
• GPU or specialized compute workloads
• Stateful Kubernetes services
• Complex networking
• Linux and Windows container workloads
• Portability across Kubernetes environments
• Advanced GitOps and policy requirements

---

Kubernetes capabilities

AKS supports concepts such as:

• Pods
• Deployments
• StatefulSets
• Services
• Ingress
• Namespaces
• Node pools
• Horizontal Pod Autoscaler
• Cluster Autoscaler
• KEDA
• Network policies
• Persistent volumes
• Operators
• Custom resource definitions
• Taints and tolerations
• Affinity and anti-affinity
• Helm
• GitOps

---

Strengths

• Full Kubernetes API
• Broad ecosystem compatibility
• Fine-grained control
• Advanced orchestration
• Flexible networking
• Multiple node pools
• Linux and Windows support
• GPU and specialized compute
• Mature deployment tooling
• Strong fit for platform engineering

---

Operational responsibilities

AKS is managed, but not hands-off.

You must still manage:

• Kubernetes versions
• Node image upgrades
• Workload resource requests and limits
• Cluster capacity
• Pod disruption
• Autoscaling
• Network architecture
• Secrets
• Ingress
• Persistent storage
• Security policies
• Monitoring
• Backup and disaster recovery
• Cost optimization

---

Choose AKS when

Use AKS when:

• You require Kubernetes.
• You need maximum orchestration control.
• Your organization has Kubernetes expertise.
• You need advanced node or network configuration.
• The application uses Kubernetes-native tooling.
• Portability across Kubernetes platforms matters.
• You are building a shared internal container platform.

---

Do not choose AKS when

Avoid AKS for a small workload simply because Kubernetes is popular.

It may be excessive for:

• One small API
• One web app
• One queue worker
• A temporary processing job
• A team without Kubernetes skills
• A workload with no cluster-level requirements

---

6. Comparison Table

---

7. Important Edge Cases

Short-lived job: ACI or Container Apps Jobs?

Use ACI when:

• You simply need to launch a container.
• An external workflow controls execution.
• You do not need built-in scheduling, retries, event rules, or application lifecycle features.

Use Container Apps Jobs when:

• You need scheduled jobs.
• You need event-triggered execution.
• You need retries and timeouts.
• You want jobs inside a broader Container Apps environment.
• The same solution contains APIs, workers, and jobs.

---

Microservices: Container Apps or AKS?

Use Container Apps when:

• You want microservices without Kubernetes operations.
• Standard ingress and service communication are enough.
• KEDA-based scaling meets the requirements.
• You do not need Kubernetes extensions.

Use AKS when:

• The microservices platform depends on Kubernetes APIs.
• You require operators, service meshes, or custom controllers.
• You need advanced node scheduling.
• You need custom network architecture.
• Kubernetes portability is mandatory.

---

Simple web container: Container Apps or App Service?

The transcript focuses on three services, but Azure App Service may be simpler for a traditional HTTP web application that:

• Uses one web container
• Needs standard web hosting features
• Does not require event-driven scaling
• Does not need a microservices environment
• Fits the App Service deployment model

Microsoft’s Container Apps comparison documentation also recommends evaluating App Service and Functions alongside ACI, Container Apps, and AKS.

---

Event-driven code: Container Apps or Functions?

Use Azure Functions when:

• The unit of deployment is primarily a function.
• You want function triggers and bindings.
• Container packaging is not a primary requirement.

Use Container Apps when:

• You need a custom container runtime.
• You have multiple processes or services.
• You want container-level control.
• You need revisions and container application lifecycle management.

Azure Functions can also be hosted on Azure Container Apps for selected containerized function-app scenarios.

---

8. High Availability Differences

ACI

ACI does not automatically create a highly available application.

For resilience, you may need to:

• Run multiple container groups
• Use an external load balancer
• Implement retries
• Store state externally
• Recreate failed instances through automation

---

Container Apps

Container Apps can:

• Run multiple replicas
• Restart unhealthy replicas
• Scale horizontally
• Route traffic across revisions

However, your application still needs:

• Health probes
• Multiple minimum replicas where zero downtime is required
• External durable state
• Resilient databases
• Retry logic
• Zone-aware or regional design where necessary

---

AKS

AKS supports the most sophisticated availability patterns:

• Multiple node pools
• Multiple availability zones
• Pod anti-affinity
• Pod disruption budgets
• Multiple replicas
• Cluster autoscaling
• Multiple clusters
• Multi-region architecture

But the platform must be configured correctly. Kubernetes alone does not automatically guarantee application availability.

---

9. Networking Considerations

ACI

Suitable for relatively simple networking:

• Public IP
• Private VNet placement
• Exposed container ports
• Container-group communication

Container Apps

Provides managed application networking:

• External ingress
• Internal ingress
• Environment-level communication
• VNet integration
• Controlled egress in supported configurations
• Private application environments

AKS

Provides the greatest networking flexibility:

• Azure CNI options
• Pod address planning
• Service CIDRs
• Private clusters
• Ingress controllers
• Network policies
• Custom egress design
• Internal and public load balancers
• Service mesh
• Application Gateway integration

Choose AKS when network architecture itself is a major workload requirement.

---

10. Security Considerations

All three services should use:

• Managed identities
• Azure Container Registry
• Microsoft Entra ID
• Least-privilege RBAC
• Azure Key Vault
• Private networking where required
• Image vulnerability scanning
• Minimal container images
• Non-root execution where possible
• No embedded secrets
• Runtime monitoring
• Updated base images

ACI security focus

• Restrict exposed ports.
• Use private networking for sensitive jobs.
• Avoid long-lived secrets.
• Remove completed container groups.
• Use confidential containers where required and supported.

Container Apps security focus

• Use managed identities.
• Use internal ingress for internal APIs.
• Store secrets securely.
• Restrict application exposure.
• Use revision controls.
• Secure environment networking.

AKS security focus

• Use workload identity.
• Secure the API server.
• Use private clusters where required.
• Apply network policies.
• Restrict privileged containers.
• Use Pod Security controls.
• Scan images.
• Protect Kubernetes secrets.
• Patch node images and Kubernetes versions.
• Apply policy and governance.

---

11. State Management

Containers should be assumed replaceable.

Do not store critical data only inside the writable container layer.

Container replaced
      ↓
Local container data may disappear

Use external state stores such as:

• Azure SQL Database
• Azure Cosmos DB
• Azure Storage
• Azure Files
• Managed disks through AKS
• Azure Cache for Redis
• Managed message brokers

A workload’s statefulness often affects the service choice:

• Stateless APIs fit Container Apps well.
• Simple temporary processing fits ACI.
• Complex stateful Kubernetes applications may require AKS.
• Some stateful applications are better placed on managed databases or VMs.

---

12. Cost Considerations

ACI

Good cost fit when:

• Execution is short.
• Containers are created only when needed.
• There is no idle cluster capacity.
• Workloads are isolated and temporary.

ACI may be inefficient if you manually keep many instances running continuously without platform-level scaling.

---

Container Apps

Good cost fit when:

• Demand fluctuates.
• Scale-to-zero is possible.
• You want managed ingress and scaling.
• Operational simplicity reduces engineering effort.

Always account for:

• Minimum replicas
• Workload profiles
• Network usage
• Log ingestion
• Registry charges
• Always-on background processes

---

AKS

AKS costs can include:

• Worker nodes
• Cluster management tier
• Managed disks
• Load balancers
• Networking
• Monitoring
• Registry
• Security products
• Idle capacity
• Engineering and platform operations

AKS may be financially efficient at large scale, but it usually has the greatest operational cost.

---

13. Scenario-Based Selection

Scenario 1: Temporary image conversion

Requirements:

• Process one uploaded image
• Job lasts 30 seconds
• No HTTP endpoint
• No orchestration
• External workflow starts the job

Recommended: ACI

---

Scenario 2: Scheduled report generator

Requirements:

• Runs nightly
• Needs retries
• Must stop after completion
• Uses the same environment as other containerized services

Recommended: Container Apps Job

---

Scenario 3: Public API with unpredictable traffic

Requirements:

• HTTP API
• Scale-to-zero
• Managed TLS
• Canary deployments
• No Kubernetes expertise

Recommended: Container Apps

---

Scenario 4: Enterprise Kubernetes platform

Requirements:

• Custom operators
• GPU nodes
• Windows node pools
• GitOps
• Network policies
• Custom ingress
• Multiple engineering teams

Recommended: AKS

---

Scenario 5: Kubernetes required but team wants less infrastructure management

Requirements:

• Kubernetes manifests
• Standard Kubernetes APIs
• Production defaults
• Less node and cluster configuration

Recommended: Evaluate AKS Automatic

---

14. Corrections and Clarifications to the Transcript

“ACI is only for short-lived workloads”

Short-lived workloads are a strong ACI use case, but ACI can also run longer-lived containers.

The more precise distinction is:

• ACI provides simple container execution.
• It does not provide the richer application orchestration available in Container Apps or AKS.

---

“AKS provides self-healing automatically”

Kubernetes can restart failed containers and recreate pods, but application self-healing depends on correct configuration:

• Replica count
• Health probes
• Resource requests
• Pod disruption budgets
• Availability zones
• Persistent state design
• Database resilience

AKS does not automatically make an application highly available.

---

“AKS is always the best production choice”

AKS is appropriate for production when Kubernetes-level requirements exist.

Container Apps can also run production-grade APIs, workers, and microservices with significantly less operational complexity.

---

“Container Apps is only for lightweight applications”

Container Apps is not limited to trivial applications.

It can host substantial production APIs, microservices, background processing, and event-driven systems, provided its managed platform boundaries meet the workload requirements.

---

“Container Apps manages all networking and load balancing”

Container Apps manages many application-platform networking functions, but architects must still plan:

• Public versus internal ingress
• VNet integration
• Private endpoints
• DNS
• Egress
• Firewall requirements
• Cross-environment communication
• Regional resilience

---

“More complex application means AKS”

Complexity alone does not require Kubernetes.

AKS should be chosen when the application specifically requires Kubernetes capabilities or when the organization deliberately operates a Kubernetes platform.

---

15. Quick Decision Matrix

---

16. AZ-305 Exam Review

Remember these associations:

• ACI → Simple, isolated container execution.
• ACI container group → Containers sharing lifecycle and resources.
• Container Apps → Managed serverless application platform.
• Container Apps revision → Deployable application version.
• Traffic splitting → Container Apps revision capability.
• Container Apps Job → Containerized task that runs to completion.
• KEDA scaling → Event-driven scaling used by Container Apps and optionally AKS.
• AKS → Full managed Kubernetes platform.
• AKS Automatic → Kubernetes with more managed defaults.
• AKS Standard → Greater infrastructure and cluster control.
• CRDs and operators → Strong AKS indicator.
• Custom node pools → AKS.
• Scale-to-zero API → Container Apps.
• One-off isolated job → ACI.
• Scheduled container task → Container Apps Job.
• Microservices do not automatically require AKS.
• Managed Kubernetes does not mean no operations.
• Containers do not automatically provide high availability.
• The service with the most control also usually requires the most operational work.

---

Microsoft Reference Documentation

• Choose an Azure container service.
• Architectural considerations for selecting a container service.
• Compare Azure Container Apps with other Azure container options.
• Azure Container Instances documentation.
• Azure Container Instances overview.
• ACI container groups.
• Azure Container Apps overview.
• Container Apps scaling rules.
• Container Apps revisions.
• Container Apps jobs.
• Azure Kubernetes Service overview.
• AKS core concepts and cluster modes.
• AKS Automatic overview.
• AKS documentation.
• AKS pricing and production-mode guidance.

---

Container availability and scaling deep dive

Container Availability and Scaling (AKS) — Review Notes and In-Depth Guide

1. Overview

Running containers is only the first step.

A production-ready container platform must also ensure:

• High availability (HA)
• Scalability
• Fault tolerance
• Disaster recovery
• Performance
• Cost optimization

For Azure Kubernetes Service (AKS), architects must design both application availability and cluster availability.

Application
      +
Kubernetes Platform
      +
Networking
      +
Storage
      +
Monitoring
      +
Disaster Recovery
      =
Highly Available Solution

Important AZ-305 concept: Kubernetes (AKS) provides mechanisms for availability and scaling, but your application architecture determines whether the application is actually highly available.

Microsoft's AKS Well-Architected guidance emphasizes designing for resiliency, scaling, observability, security, and operational excellence—not just deploying a cluster. (learn.microsoft.com)

---

2. High Availability vs Scalability

These concepts are often confused.

High Availability (HA)

High availability ensures an application continues operating despite failures.

Examples of failures:

• VM failure
• Node failure
• Zone failure
• Container crash
• Pod crash
• Planned maintenance
• Hardware failure

Goal:

Service remains available.

---

Scalability

Scalability increases or decreases resources based on demand.

Example:

100 users
↓

2 Pods

1000 users
↓

20 Pods

Goal:

Maintain performance during changing load.

---

They solve different problems

A system can be:

• Highly available but not scalable.
• Scalable but not highly available.
• Both.
• Neither.

---

3. Availability Layers in AKS

High availability exists at multiple layers.

Users
    ↓
Azure Front Door / Application Gateway
    ↓
AKS Cluster
    ↓
Node Pools
    ↓
Nodes
    ↓
Pods
    ↓
Application
    ↓
Database

Every layer must be resilient.

Example:

Even if AKS is highly available,

a single SQL Server VM may still become the single point of failure.

---

4. AKS High Availability Architecture

A production deployment usually looks like:

Internet
      │
Azure Front Door
      │
Application Gateway
      │
AKS Cluster
 ┌──────────────┐
 │ Zone 1       │
 │  Node Pool   │
 └──────────────┘
 ┌──────────────┐
 │ Zone 2       │
 │  Node Pool   │
 └──────────────┘
 ┌──────────────┐
 │ Zone 3       │
 │  Node Pool   │
 └──────────────┘

Benefits:

• Zone resilience
• Automatic scheduling
• Load distribution
• Rolling updates
• Self healing

Microsoft recommends zone-spread node pools and replicas where supported for production resilience. (learn.microsoft.com)

---

5. Node Pools

The transcript briefly mentions node pools.

Architecturally, they are extremely important.

A node pool is a group of VMs with similar configuration.

Example:

AKS Cluster

System Node Pool
    ↓
Runs Kubernetes system services

Application Pool
    ↓
Runs APIs

GPU Pool
    ↓
Runs ML inference

Windows Pool
    ↓
Runs Windows containers

Benefits:

• Isolation
• Independent scaling
• Different VM sizes
• Different OS
• Different taints
• Cost optimization

Do not place all workloads into one node pool in production.

---

6. Availability Zones

Availability Zones protect against datacenter failure.

Example:

Zone 1
  Node A

Zone 2
  Node B

Zone 3
  Node C

If Zone 2 fails:

Pods restart
↓

Zone 1 & Zone 3

Requirements:

• Multiple zones supported
• Multiple replicas
• Zone-aware scheduling

Merely enabling Availability Zones is insufficient if you deploy only one replica.

---

7. Kubernetes Self-Healing

The transcript says Kubernetes automatically replaces failed nodes.

This requires clarification.

Kubernetes provides several self-healing mechanisms:

Pod restart

If container crashes:

Container crashes
      ↓
Kubelet restarts container

---

Pod recreation

If Pod disappears:

Pod deleted
      ↓
Deployment recreates Pod

---

Node failure

If a node becomes unhealthy:

Node unhealthy
      ↓
Pods rescheduled
      ↓
Healthy node

Only if:

• Capacity exists
• Another node is available
• Constraints allow scheduling

---

Liveness probe

Detects unhealthy application.

Application hangs
      ↓
Probe fails
      ↓
Container restarted

---

Readiness probe

Determines whether traffic should reach Pod.

Application starting
↓

Not Ready

↓

No traffic sent

Very important for rolling deployments.

---

Startup probe

Useful for slow-starting applications.

Prevents premature restarts.

Microsoft documents liveness, readiness, and startup probes as core Kubernetes health mechanisms. (learn.microsoft.com)

---

8. Multiple Replicas

Self-healing alone does NOT create high availability.

Example:

One replica

Pod crashes

↓

Restart

↓

Downtime

Two replicas

Pod A
Pod B

↓

Pod A crashes

↓

Traffic continues to Pod B

Therefore production workloads normally use:

replicas: 2+

or more.

---

9. Horizontal Pod Autoscaler (HPA)

The transcript introduces HPA.

HPA increases or decreases Pod count.

Example:

CPU > 70%

↓

Pods increase

2

↓

4

↓

8

Supported metrics include:

• CPU
• Memory
• Custom metrics
• External metrics

The Horizontal Pod Autoscaler scales replicas based on observed metrics and requires metrics collection to be configured. (learn.microsoft.com)

---

HPA example

Morning:

2 Pods

Lunch:

8 Pods

Night:

2 Pods

Application automatically adapts.

---

10. Cluster Autoscaler

HPA scales Pods.

But what if there is no room?

Example:

Need 10 Pods

Node has capacity for 5

Cluster Autoscaler:

New VM created

↓

Pods scheduled

It adjusts:

• Node count
• VM capacity

The Cluster Autoscaler automatically adds or removes AKS nodes based on unschedulable Pods and utilization. (learn.microsoft.com)

---

Difference

HPA
↓

Pods

Cluster Autoscaler

↓

Nodes

Easy exam question.

---

11. Vertical Pod Autoscaler (VPA)

Not discussed in transcript.

Important concept.

Instead of:

2 Pods

↓

4 Pods

VPA changes:

CPU

1 core

↓

2 cores

Useful when workload needs more resources rather than more replicas.

Generally avoid using HPA and VPA simultaneously on the same CPU or memory resources unless carefully designed because they may conflict.

---

12. KEDA

Modern AKS scaling often uses KEDA.

Instead of CPU:

Scale based on:

• Queue length
• Kafka
• Service Bus
• Event Hub
• RabbitMQ
• Prometheus
• Redis
• Cron

Example:

1000 queue messages

↓

20 Pods

KEDA enables event-driven autoscaling for Kubernetes workloads and is integrated with AKS. (learn.microsoft.com)

---

13. Virtual Nodes

Transcript mentions bursting into ACI.

Virtual Nodes allow AKS to rapidly schedule supported Pods into Azure Container Instances.

AKS

↓

Node full

↓

Virtual Node

↓

ACI

Benefits:

• Burst capacity
• No new VM provisioning
• Fast scaling

Limitations:

• Not every workload is supported.
• Networking and storage features differ from regular nodes.
• Feature support continues to evolve.

For many new architectures, Azure recommends evaluating AKS Automatic or efficient autoscaling before selecting virtual nodes. Virtual Nodes remain available but are not the default recommendation for every burst scenario. (learn.microsoft.com)

---

14. Traffic Patterns

Transcript discusses predictable vs unpredictable traffic.

Predictable:

Morning spike

↓

Scale before spike

Examples:

• Office applications
• Payroll
• Business systems

---

Unpredictable:

Black Friday

↓

Dynamic autoscaling

Examples:

• Retail
• Social media
• Viral applications

Scaling strategy depends on workload.

---

15. Resource Requests and Limits

Autoscaling depends on proper resource definitions.

requests:
  cpu: 250m

limits:
  cpu: 1000m

Requests:

Guaranteed resources.

Limits:

Maximum resources.

Incorrect requests:

• Waste capacity
• Prevent scheduling
• Cause unnecessary scaling
• Reduce cluster efficiency

This is a common production optimization area.

---

16. Pod Disruption Budgets (PDB)

Not discussed.

Critical for HA.

Example:

Replicas = 3

PDB

Minimum Available = 2

During maintenance:

Never evict all Pods

Protects availability during:

• Upgrades
• Maintenance
• Draining nodes

---

17. Topology Spread Constraints

Instead of placing all Pods on one node:

Node A

Pod
Pod
Pod

Use topology spread:

Node A
Pod

Node B
Pod

Node C
Pod

Improves resilience.

---

18. Scaling Best Practices

Monitor:

• CPU
• Memory
• Network
• Pod count
• Restart count
• Queue length
• Response time
• Throughput
• Errors

Do NOT scale solely on CPU.

Business metrics often matter more.

---

19. Disaster Recovery

Transcript briefly mentions region replication.

Clarification:

AKS itself is regional.

Production DR typically requires:

Primary Region

AKS

↓

Secondary Region

AKS

Need replication for:

• Container images
• Database
• Secrets
• Storage
• DNS
• CI/CD
• Monitoring

AKS clusters do not automatically replicate to another region.

Microsoft provides multiregion AKS reference architectures for active-active and disaster recovery scenarios. (learn.microsoft.com)

---

20. RTO and RPO

Transcript mentions these.

RTO

Recovery Time Objective

Maximum downtime.

Example:

RTO = 30 minutes

Need service back within 30 minutes.

---

RPO

Recovery Point Objective

Maximum acceptable data loss.

Example:

RPO = 5 minutes

Maximum five minutes of lost transactions.

High availability reduces downtime.

Backup and replication reduce data loss.

---

21. Monitoring

Transcript recommends:

• Azure Monitor
• Log Analytics

Modern AKS monitoring typically includes:

• Azure Monitor
• Container Insights
• Managed Prometheus
• Managed Grafana
• Log Analytics
• Application Insights
• Microsoft Defender for Cloud

Monitor:

• Node health
• Pod health
• Restart count
• CPU
• Memory
• Network
• Scaling events
• API latency
• Failed deployments

Microsoft recommends Azure Monitor managed service for Prometheus and Azure Managed Grafana for Kubernetes metrics visualization. (learn.microsoft.com)

---

22. Cost Optimization

Balance:

Performance

↓

Cost

Too many nodes:

High cost.

Too few:

Poor performance.

Use:

• Autoscaler
• Right-sized requests
• Spot node pools where appropriate
• Reserved instances
• Node pool optimization
• Cluster scheduling optimization

---

23. Common Production Architecture

Users
      │
Azure Front Door
      │
Application Gateway
      │
AKS
 ├───────────────┐
 │ Zone 1        │
 │ Pods          │
 └───────────────┘
 ├───────────────┐
 │ Zone 2        │
 │ Pods          │
 └───────────────┘
 ├───────────────┐
 │ Zone 3        │
 │ Pods          │
 └───────────────┘
      │
Managed Database
      │
Storage

---

24. Scenario

Customer:

• Global e-commerce site
• Traffic spikes
• Black Friday
• 99.95% uptime
• Regional DR

Recommended:

• AKS across Availability Zones
• Minimum 3 replicas
• HPA
• Cluster Autoscaler
• KEDA for queue processing
• Azure Front Door
• Multi-region DR
• Azure Monitor
• PDBs
• Topology spread
• Azure Container Registry with geo-replication if needed

---

25. Corrections to the Transcript

"AKS replaces failed nodes"

More accurately:

• Kubernetes recreates Pods.
• AKS repairs or replaces nodes depending on failure type and node-pool management.
• Pods are rescheduled only if sufficient healthy capacity exists.

---

"Availability Zones ensure uptime"

Only if:

• Multiple replicas exist.
• Pods are distributed.
• Database is also resilient.
• Networking is redundant.

---

"Region replication"

AKS itself does not replicate automatically.

You deploy another cluster.

Then replicate:

• Images
• Data
• Secrets
• DNS
• CI/CD

---

"Scaling based on CPU"

CPU alone is often insufficient.

Production systems frequently scale using:

• Queue depth
• HTTP requests
• Business events
• Custom metrics
• KEDA triggers

---

"Virtual Nodes"

Still supported, but no longer the default recommendation for every burst scenario.

Evaluate:

• AKS Automatic
• Cluster Autoscaler
• KEDA

before selecting Virtual Nodes.

---

26. Decision Matrix

---

27. AZ-305 Exam Review

Remember these associations:

• High availability → Survive failures.
• Scalability → Handle changing demand.
• Node Pool → Group of similar worker nodes.
• Availability Zones → Datacenter resilience.
• Pod replicas → Application redundancy.
• Horizontal Pod Autoscaler (HPA) → Scale Pods.
• Cluster Autoscaler → Scale nodes.
• Vertical Pod Autoscaler (VPA) → Adjust Pod resources.
• KEDA → Event-driven autoscaling.
• Virtual Nodes → Burst supported workloads into Azure Container Instances.
• Liveness probe → Restart unhealthy containers.
• Readiness probe → Control whether traffic reaches a Pod.
• Startup probe → Prevent premature restarts of slow-starting apps.
• Pod Disruption Budget (PDB) → Maintain availability during maintenance.
• Topology Spread Constraints → Distribute Pods across nodes or zones.
• Azure Monitor + Container Insights + Managed Prometheus → Observe AKS health.
• AKS does not automatically provide application HA.
• Multiple replicas are required for zero-downtime deployments.
• Cluster Autoscaler scales VMs; HPA scales Pods.
• High availability, backup, and disaster recovery are different architectural concepts.

---

Microsoft Reference Documentation

• AKS Well-Architected guidance. (learn.microsoft.com)
• AKS availability zones. (learn.microsoft.com)
• AKS scaling concepts (HPA, VPA, Cluster Autoscaler). (learn.microsoft.com)
• Cluster Autoscaler. (learn.microsoft.com)
• KEDA on AKS. (learn.microsoft.com)
• Virtual Nodes. (learn.microsoft.com)
• Liveness, readiness, and startup probes. (learn.microsoft.com)
• Azure Monitor for AKS and Container Insights. (learn.microsoft.com)
• AKS multiregion reference architecture. (learn.microsoft.com)
• Kubernetes Pod Disruption Budgets. (learn.microsoft.com)
• Kubernetes topology spread constraints. (learn.microsoft.com)

---

Virtual machine design deep dives#

Use these deep dives to connect AZ-305 design choices to the operational details that appear in scenario questions.

---

Planning VM deployment deep dive

Planning an Azure Virtual Machine Deployment — Review Notes and In-Depth Guide

1. Overview

Planning an Azure Virtual Machine deployment requires more than choosing a VM size and operating system.

An architect should evaluate:

Workload requirements
        +
VM size and architecture
        +
Region and availability
        +
Storage performance
        +
Operating system and images
        +
Networking
        +
Security
        +
Patching
        +
Monitoring
        +
Backup and disaster recovery
        +
Cost optimization

The core design question is:

What compute, availability, performance and operational model satisfies the workload without creating unnecessary cost or management overhead?

---

2. First Decision: Does the Workload Need a VM?

Before deploying a VM, determine whether Infrastructure as a Service is the right hosting model.

A VM is usually appropriate when the workload requires:

• Full operating-system control
• Custom drivers or agents
• Legacy application compatibility
• Specific Windows or Linux dependencies
• Persistent server state
• Lift-and-shift migration
• Software not supported by managed Azure services
• Custom networking or security appliances

A VM may not be the best option when the workload can use:

• Azure App Service
• Azure Functions
• Azure Container Apps
• Azure Kubernetes Service
• Azure SQL Database
• Azure Database services
• Azure Virtual Desktop
• Other managed platform services

Need OS-level control?
       │
       ├── Yes → Consider Azure VM
       │
       └── No  → Evaluate PaaS or containers first

Managed services usually reduce:

• Patching responsibility
• OS management
• Backup complexity
• Availability engineering
• Operational overhead

---

3. Workload Discovery

Before selecting a VM, document the workload profile.

Compute requirements

Determine:

• Average CPU utilization
• Peak CPU utilization
• Number of cores required
• Single-thread versus multi-thread behavior
• CPU architecture requirements
• Burst behavior
• GPU or FPGA requirements

Memory requirements

Determine:

• Normal memory use
• Peak memory use
• Required memory-to-vCPU ratio
• In-memory caching requirements
• Database buffer requirements
• Risk of paging or swapping

Storage requirements

Determine:

• Capacity
• Required IOPS
• Required throughput
• Read/write ratio
• Sequential versus random I/O
• Latency requirements
• Temporary-storage requirements
• Growth rate

Network requirements

Determine:

• Expected ingress and egress
• Packets per second
• Latency sensitivity
• Number of network interfaces
• Accelerated networking requirements
• Public or private connectivity
• Load-balancing requirements

Availability requirements

Document:

• Service-level objective
• Recovery Time Objective
• Recovery Point Objective
• Zone-failure tolerance
• Regional-failure tolerance
• Maintenance-window tolerance

---

4. VM Size and Family Selection

Azure VM sizes define combinations of:

• vCPU
• Memory
• Local temporary storage
• Maximum data disks
• Network bandwidth
• Disk throughput
• Disk IOPS
• GPU capabilities
• Accelerated networking support

Microsoft groups VM sizes into workload-oriented families. Availability varies by region, zone and subscription quota.

Common VM categories

---

General-purpose VMs

General-purpose families provide balanced CPU and memory.

Typical uses:

• Web servers
• Application servers
• Small and medium databases
• Development environments
• Enterprise applications

The D-family is one of Azure’s primary general-purpose families.

---

Compute-optimized VMs

Select compute-optimized sizes when:

• CPU utilization is consistently high.
• Memory demand is moderate.
• Processing is highly parallel.
• The application benefits from a high CPU-to-memory ratio.

Typical workloads:

• Batch processing
• Application servers
• Gaming servers
• Scientific processing
• Media encoding

---

Memory-optimized VMs

Select memory-optimized sizes for:

• Relational databases
• In-memory databases
• SAP workloads
• Analytics
• Large caches

For example, Azure’s Easv5 series is designed for memory-intensive enterprise applications.

---

GPU VMs

GPU families may be required for:

• Machine learning training
• AI inference
• Computer vision
• Video rendering
• CAD
• Visualization
• Virtual workstations

Check:

• GPU model
• GPU memory
• Driver requirements
• Framework compatibility
• Regional availability
• Quota
• Cost

---

Burstable VMs

Burstable VMs are suited to workloads with:

• Low average CPU use
• Short CPU spikes
• Development or test usage
• Small web applications
• Domain services or utility servers

They are usually unsuitable for workloads requiring sustained high CPU because performance depends on accumulated CPU credits.

---

5. Right-Sizing Strategy

Avoid sizing only from vendor minimum requirements.

Use:

• Existing performance counters
• Azure Migrate assessment
• Load testing
• Application benchmarks
• Azure Monitor metrics
• Cost Management recommendations
• Azure Advisor

A practical process is:

Measure current workload
        ↓
Select initial VM family
        ↓
Benchmark
        ↓
Monitor utilization
        ↓
Resize or scale

Monitor at least:

• CPU percentage
• Available memory
• Disk latency
• Disk queue depth
• Disk IOPS
• Disk throughput
• Network throughput
• Application response time

Under-sizing risks

• Poor response time
• CPU throttling
• Memory pressure
• Disk bottlenecks
• Application failure
• Unstable performance

Over-sizing risks

• Unnecessary cost
• Low utilization
• Wasted reservations
• Larger licensing costs
• Higher disaster-recovery costs

---

6. VM Size Compatibility Considerations

A VM size can also determine whether certain features are available.

Check support for:

• Premium SSD
• Premium SSD v2
• Ultra Disk
• Accelerated networking
• Nested virtualization
• Trusted Launch
• Confidential computing
• Multiple NICs
• Ephemeral OS disks
• Local NVMe
• High network bandwidth
• Availability Zones
• VM Scale Sets

The size must also provide sufficient limits for:

• Attached data disks
• Combined disk throughput
• Combined disk IOPS
• NIC throughput
• Local temporary disk

The VM itself can become the performance bottleneck even when attached disks are capable of higher throughput. Azure documents separate VM and disk performance limits.

---

7. Environment Classification

Size and availability should reflect the environment.

Do not make development environments unnecessarily identical to production unless they are used for:

• Performance testing
• Availability testing
• Upgrade validation
• Disaster-recovery rehearsals

---

8. Region Selection

Choosing a region affects:

• Latency
• Regulatory compliance
• Data residency
• Service availability
• VM family availability
• Availability Zone support
• Pricing
• Disaster recovery
• Network connectivity

Microsoft maintains a current list of Azure regions, regional pair information and Availability Zone support.

Region-selection criteria

1. Data residency

   Confirm whether data and backups must remain within:

   • A country
   • The European Union
   • A specific Azure geography
   • A sovereign cloud

2. User proximity

   Placing applications closer to users usually reduces latency.

3. Service availability

   Confirm that the region supports:

   • Required VM family
   • Required disk type
   • Availability Zones
   • Backup
   • Azure Site Recovery
   • Dependent databases
   • Private Link
   • Monitoring services

4. Quota and capacity

   A VM SKU may be documented for a region but still require quota approval or may be temporarily capacity constrained.

5. Pricing

   VM and disk prices can differ between regions.

6. Disaster recovery

   Confirm a suitable secondary region and ensure required services are available there.

---

9. Availability Architecture

A single VM is still a single workload instance.

To achieve application availability, design multiple instances and remove other single points of failure.

Azure VM availability options include:

• Single VM
• Availability Set
• Availability Zone
• Zone-redundant deployment
• Virtual Machine Scale Set
• Multi-region deployment

Microsoft identifies Availability Zones as the strongest intra-region reliability option for supported workloads.

---

Single VM

Use a single VM only where downtime is acceptable.

Examples:

• Development
• Test
• Utility server
• Noncritical internal application

A managed disk or backup does not make a single application instance highly available.

---

Availability Sets

Availability Sets distribute VMs across:

• Fault domains
• Update domains

Availability Set
   ├── Fault domain 1
   ├── Fault domain 2
   └── Fault domain 3

They reduce the probability that all instances are affected by:

• Rack failure
• Power failure
• Planned platform maintenance

However, Availability Sets do not provide isolation across physically separate availability zones.

Microsoft currently recommends Virtual Machine Scale Sets with flexible orchestration for high availability with the broadest feature support, while Availability Zones provide higher reliability where available.

---

Availability Zones

Availability Zones are separated groups of datacenters within an Azure region.

A zone-resilient application may use:

                Load Balancer
                  /       \
                 /         \
           VM in Zone 1   VM in Zone 2

Availability Zones protect against a datacenter or zone-level failure.

The application must still handle:

• Multi-instance state
• Session persistence
• Database availability
• Cross-zone traffic
• Load balancing
• Health probes
• Zonal dependencies

---

Virtual Machine Scale Sets

Virtual Machine Scale Sets allow a group of VMs to be:

• Deployed consistently
• Load balanced
• Automatically scaled
• Distributed across zones
• Centrally managed
• Updated systematically

Scale sets can deploy instances across multiple zones, within one zone, or regionally.

Use VM Scale Sets when:

• The workload is horizontally scalable.
• Identical or similar instances are needed.
• Automatic scaling is required.
• Automated instance replacement is desired.
• Fleet-based management is preferred.

---

Multi-region deployment

A multi-region design may be necessary when the business requires resilience against a complete regional outage.

             Azure Front Door / Traffic Manager
                       /             \
                      /               \
              Primary region      Secondary region
               VM instances        VM instances

Multi-region design must include:

• Data replication
• DNS or global routing
• Identity dependencies
• Configuration replication
• Secrets and certificates
• Backup
• Recovery orchestration
• Tested failover procedures

---

10. Load Balancing

Multiple VMs need a traffic distribution layer.

Possible services include:

• Azure Load Balancer
• Application Gateway
• Azure Front Door
• Traffic Manager

High availability requires both multiple VM instances and a highly available traffic-entry design.

---

11. Managed Disks

Azure Managed Disks are Azure-managed block storage volumes for VMs. Microsoft manages storage-account placement and infrastructure complexity.

Use managed disks for almost all new Azure VM deployments.

Benefits include:

• Simplified management
• Improved availability integration
• Native snapshots
• Backup integration
• Encryption
• Zone support
• Shared-disk options for supported clusters
• Easier scale-set deployment

---

Correction: unmanaged disks

The transcript suggests unmanaged disks may be used for customized installations.

That guidance is outdated for most modern designs.

Unmanaged disks require the customer to manage VHD files inside storage accounts and account-level performance limits. New deployments should use managed disks unless a rare legacy dependency specifically requires unmanaged storage.

---

12. Azure Managed Disk Types

Current Azure managed disk options include:

• Standard HDD
• Standard SSD
• Premium SSD
• Premium SSD v2
• Ultra Disk

Microsoft’s current disk documentation lists these disk families and their workload characteristics.

---

Standard HDD

Best suited for:

• Infrequently accessed data
• Development and test
• Backup-style workloads
• Low-cost, low-IOPS systems

Characteristics:

• Lowest cost
• Highest latency
• Limited IOPS and throughput

---

Standard SSD

Best suited for:

• Web servers
• Light enterprise applications
• Development and test
• Moderate I/O workloads

Characteristics:

• More consistent than HDD
• Lower cost than Premium
• Suitable for many noncritical workloads

---

Premium SSD

Best suited for:

• Production workloads
• Databases
• Low-latency applications
• High-IOPS systems

Characteristics:

• Provisioned performance
• Predictable latency
• Broad VM support

---

Premium SSD v2

Best suited for workloads requiring flexible performance configuration.

It allows capacity, IOPS and throughput to be adjusted more independently than traditional Premium SSD tiers.

Use it when:

• Performance needs do not align neatly with fixed disk tiers.
• Cost optimization requires more granular provisioning.
• The region and VM architecture support it.

---

Ultra Disk

Best suited for:

• High-end transactional databases
• Very high IOPS
• Very high throughput
• Very low latency
• Performance-sensitive enterprise applications

Ultra Disk has regional, VM-size and feature compatibility considerations.

---

13. Disk Performance Planning

Do not size disks only by capacity.

A disk must satisfy:

• Capacity
• IOPS
• Throughput
• Latency
• Burst requirements

Application demand
      ↓
Disk IOPS and throughput
      ↓
VM aggregate disk limit
      ↓
Storage design

The effective performance is limited by the lowest relevant ceiling:

Effective performance =
minimum of
(disk limit, VM limit, application capability, network/storage path)

---

Disk striping

Multiple data disks may be combined using operating-system volume management to increase aggregate:

• Capacity
• IOPS
• Throughput

Examples:

• Windows Storage Spaces
• Linux LVM
• RAID 0 where application resiliency exists

Striping increases performance but does not itself provide backup or application-level resilience.

---

14. OS Disk, Data Disk and Temporary Disk

OS disk

Contains:

• Operating system
• Boot files
• Installed system components

Application data should generally be separated from the OS disk.

---

Data disks

Use managed data disks for:

• Databases
• Logs
• Application data
• File repositories
• Durable workload data

Benefits of separating data disks include:

• Independent scaling
• Easier backup
• Better performance design
• Cleaner recovery
• Reduced OS disk contention

---

Temporary disk

Some VM sizes include local temporary storage.

Temporary disks are:

• Located on the physical host
• Not durable
• Potentially lost during redeployment, maintenance or host movement
• Suitable only for temporary data

Use temporary disks for:

• Page files
• Swap
• Temporary processing
• Re-creatable caches

Do not store:

• Database files
• Unique business data
• Application configuration that cannot be recreated
• Required logs

Temporary disks are not managed disks and have different encryption behavior; encryption at host or newer supported VM generations may be needed for full temporary-storage encryption.

---

15. Ephemeral OS Disks

Ephemeral OS disks store the OS disk on local VM storage rather than on remote managed storage.

Benefits:

• Fast reimaging
• Lower OS disk latency
• No OS managed-disk storage charge
• Useful for stateless scale-out instances

Limitations:

• OS state is not durable.
• VM size must provide sufficient local storage.
• The OS disk cannot be resized after deployment.
• Not suitable for unique, stateful servers.

Microsoft documents support and capacity restrictions based on the VM’s cache, temporary or NVMe storage.

Use ephemeral OS disks for:

• VM Scale Sets
• Stateless web tiers
• Build agents
• Disposable workers
• Re-creatable compute nodes

---

16. Disk Caching

Azure managed disks may support host caching modes such as:

• None
• Read-only
• Read/write

Caching can improve performance, but incorrect settings can risk consistency or provide little benefit.

Read-only caching

Often useful for:

• Read-intensive workloads
• Database data files where supported
• Frequently read application content

Read/write caching

Can improve some workloads but should be used only when supported by the application and data-consistency model.

No caching

Often selected for:

• Write-intensive logs
• Ultra Disk
• Workloads where caching offers no advantage
• Database log files according to vendor guidance

Microsoft documents how host caching affects Azure disk performance.

Always follow application-vendor recommendations, particularly for databases.

---

17. Operating System Selection

Azure supports:

• Windows Server
• Multiple Linux distributions
• Marketplace images
• Custom images
• Specialized application images

Choose the OS based on:

• Application support
• Licensing
• Administration skills
• Security requirements
• Automation tooling
• Vendor certification
• Integration dependencies
• Cost

Do not select Windows or Linux solely by team preference if the application vendor supports only one platform.

---

18. Marketplace Images

Marketplace images are useful when:

• A supported base operating system is sufficient.
• Fast deployment is needed.
• Microsoft or a vendor maintains the image.
• Standardized deployment is preferred.

Check:

• Publisher
• Offer
• SKU
• Version
• Support lifecycle
• Licensing
• Marketplace plan acceptance
• Security updates

Use version pinning or controlled image promotion instead of always deploying an untested latest image into production.

---

19. Custom Images

Custom images may include:

• Base operating system
• Security configuration
• Required agents
• Middleware
• Application dependencies
• Organizational settings

Use Azure Compute Gallery to manage and distribute custom VM images across regions, subscriptions and tenants according to the selected sharing model.

A mature image pipeline is:

Base image
    ↓
Automated build
    ↓
Security hardening
    ↓
Patch and test
    ↓
Publish to Azure Compute Gallery
    ↓
Promote through environments

Tools may include:

• Azure VM Image Builder
• Packer
• Azure DevOps
• GitHub Actions
• Azure Compute Gallery

---

20. Generalized vs Specialized Images

Generalized image

A generalized image has machine-specific information removed.

Typical preparation:

• Sysprep for Windows
• Deprovisioning tools for Linux

Use generalized images when deploying multiple independent VMs.

Each new VM receives unique machine identity settings.

---

Specialized image

A specialized image preserves the source VM’s configuration.

It may retain:

• User accounts
• Machine-specific state
• Installed applications
• Existing configuration

Use specialized images for cloning a known configured system where retained state is intentional.

Quick comparison

---

21. Azure Hybrid Benefit

Azure Hybrid Benefit can reduce Windows Server VM licensing cost when the organization has eligible licenses and subscription rights.

Planning should verify:

• License eligibility
• Number of cores
• Datacenter versus Standard rights
• Dedicated-host use
• Disaster-recovery rights
• Compliance evidence

Also consider:

• Reservations
• Savings Plans for Compute
• Dev/Test pricing
• Spot VMs

Licensing decisions should be validated with current Microsoft licensing terms rather than assumed from technical eligibility.

---

22. Networking Design

VM planning should include:

• VNet and subnet placement
• IP addressing
• DNS
• Network Security Groups
• Route tables
• Firewalls
• Private Endpoints
• Load balancers
• Bastion access
• Hybrid connectivity
• DDoS protection
• Network throughput requirements

A typical secure VM design is:

Internet
   ↓
Azure Front Door / Application Gateway
   ↓
Application subnet
   ↓
Internal load balancer
   ↓
VM subnet
   ↓
Private database or storage

Avoid assigning public IP addresses directly to production VMs unless there is a justified requirement.

Use:

• Azure Bastion
• Just-in-Time VM access
• VPN
• ExpressRoute
• Privileged access workstations

for administrative access.

---

23. Accelerated Networking

Accelerated networking uses SR-IOV to reduce:

• Network latency
• Jitter
• CPU overhead

It is valuable for:

• High-throughput applications
• Network appliances
• Databases
• High-performance compute
• Latency-sensitive services

Support depends on:

• VM size
• OS image
• Region
• NIC configuration

Check compatibility before selecting the VM size.

---

24. Security Planning

A secure VM design should cover:

• Identity
• Network isolation
• Operating-system hardening
• Disk encryption
• Secrets
• Vulnerability management
• Endpoint protection
• Logging
• Update management
• Backup
• Governance

Microsoft publishes a Windows VM security baseline aligned to the Microsoft cloud security benchmark.

---

Identity

Use:

• Microsoft Entra ID integration where supported
• Managed identities for Azure resource access
• Least-privilege RBAC
• Privileged Identity Management
• Separate administrative accounts
• Just-in-time access

Avoid embedding:

• Storage keys
• Database passwords
• Client secrets
• Certificates

in VM images or scripts.

---

Trusted Launch

Trusted Launch can provide security capabilities such as:

• Secure Boot
• Virtual TPM
• Boot integrity monitoring

Use it where supported, particularly for security-sensitive workloads.

---

Confidential VMs

Confidential VMs are designed to protect data in use through hardware-backed trusted execution environments.

Consider them when:

• Sensitive data must be protected while being processed.
• Regulatory controls require confidential computing.
• The application and VM family support it.

---

Disk encryption

Azure managed disks use server-side encryption.

Options can include:

• Platform-managed keys
• Customer-managed keys
• Encryption at host
• Guest-level encryption for specific requirements

Select customer-managed keys only when required by:

• Regulation
• Internal policy
• Customer contract
• Separation of duties

Microsoft’s disk encryption documentation also clarifies encryption behavior for temporary and ephemeral storage.

---

Defender for Servers

Microsoft Defender for Servers can provide capabilities such as:

• Security posture recommendations
• Threat detection
• Vulnerability assessment
• Endpoint integration
• File integrity monitoring, depending on plan and configuration

The current Defender for Servers vulnerability-management integration supports agentless and agent-based assessment options.

The transcript’s name Azure Security Center is outdated. The current service is Microsoft Defender for Cloud.

---

25. Patching and Update Management

Patching requires a balance between:

• Security risk
• Application compatibility
• Downtime
• Change control
• Recovery readiness

The transcript refers to “Azure Update Management,” which was historically associated with Azure Automation.

The modern centralized service is Azure Update Manager.

Use it to manage patching for:

• Azure VMs
• Azure Arc-enabled servers
• Windows
• Linux

A patching strategy should define:

• Maintenance windows
• Environment rings
• Reboot behavior
• Emergency patching
• Pre-update validation
• Post-update validation
• Rollback
• Exclusions
• Compliance reporting

---

Recommended patch rings

Ring 0: Image build and test systems
        ↓
Ring 1: Development
        ↓
Ring 2: Test / staging
        ↓
Ring 3: Limited production
        ↓
Ring 4: General production

Do not patch every production VM simultaneously.

For a multi-instance application:

Remove instance from load balancer
        ↓
Patch and reboot
        ↓
Health validation
        ↓
Return to service
        ↓
Patch next instance

---

OS and application updates

VM patching normally handles operating-system updates, but the architect must also plan for:

• Middleware
• Web servers
• Runtimes
• Databases
• Agents
• Antivirus
• Application libraries
• Custom applications

Operating-system patch compliance does not guarantee application security.

---

26. Maintenance Configurations

Azure maintenance configurations can help control when supported platform and guest maintenance occurs.

Use maintenance windows to coordinate:

• Patching
• Reboots
• Application drains
• Cluster failovers
• Change approvals
• Business blackout periods

Applications still need redundancy because not every failure or host event can be scheduled.

---

27. Monitoring Architecture

Effective monitoring includes four layers:

Azure platform
     +
Guest operating system
     +
Application
     +
Business transaction

Platform metrics

Examples:

• Percentage CPU
• Disk operations
• Network traffic
• VM availability
• Heartbeat
• Host events

Guest OS monitoring

Examples:

• Memory
• Processes
• Services
• Event logs
• Syslog
• File systems
• Application logs

Application monitoring

Examples:

• Request rate
• Response time
• Failure rate
• Dependency health
• Queue depth
• Custom metrics

---

28. Azure Monitor Agent

The supported agent for collecting guest operating-system telemetry is Azure Monitor Agent.

Microsoft identifies Azure Monitor Agent as the supported guest OS data collection agent and recommends migration from the legacy Log Analytics agent.

Azure Monitor Agent works with:

• Data Collection Rules
• Log Analytics workspaces
• Azure Monitor
• VM Insights
• Microsoft Sentinel
• Defender integrations

---

29. VM Insights

VM Insights provides monitoring for:

• VM performance
• Guest health
• Dependency information
• Process and connection visibility
• Fleet-level views

Use alerts for conditions such as:

• Sustained high CPU
• Low free memory
• Disk latency
• Low disk space
• VM unavailable
• Service stopped
• Backup failure
• Patch failure
• Security event
• Certificate expiry

---

30. Diagnostics Extension Clarification

The transcript recommends the “Azure Diagnostics extension.”

This requires qualification:

• The Windows Azure Diagnostics extension still exists for specific diagnostic scenarios.
• Azure Monitor Agent and Data Collection Rules are the strategic approach for modern guest telemetry.
• Legacy Log Analytics agents should not be selected for new designs.

Do not deploy multiple overlapping monitoring agents without understanding:

• Duplicate ingestion
• Cost
• CPU and memory impact
• Data duplication
• Operational complexity

---

31. Monitoring Cost Control

Monitoring cost depends on:

• Data volume
• Retention
• Table plan
• Workspace architecture
• Alert frequency
• Diagnostic categories
• Application verbosity

Use:

• Data Collection Rules
• Sampling
• Filtering
• Table-specific retention
• Basic or auxiliary log plans where appropriate
• Archive
• Daily caps only with caution

Do not collect every verbose log indefinitely.

A useful strategy is:

Security and audit logs → Longer retention
Operational logs        → Moderate retention
Debug logs              → Short retention
Metrics                  → Alerts and dashboards

---

32. Backup

Use Azure Backup for stateful VMs when recovery is required.

A VM backup strategy should define:

• Backup frequency
• Retention
• Application consistency
• Crash consistency
• Vault redundancy
• Soft delete
• Immutability
• Cross-region restore
• Cross-zone restore
• Restore testing

Azure Backup supports restoration of managed VMs and, in supported configurations, cross-zonal recovery.

Important principle

High availability ≠ Backup
Backup ≠ Disaster recovery
Disaster recovery ≠ High availability

• High availability reduces service interruption.
• Backup restores historical data.
• Disaster recovery restores service after a major failure.

---

33. Disaster Recovery

Azure Site Recovery can replicate supported Azure VMs to a secondary region.

A DR design should include:

• Replication frequency
• Target region
• Recovery plans
• Network mapping
• Public and private DNS
• Load balancer configuration
• Application dependencies
• Database consistency
• Failover testing
• Failback

Do not assume that VM replication alone recovers the application.

The recovery plan must include:

• Identity
• Key Vault
• Storage
• Databases
• Messaging
• Certificates
• DNS
• Monitoring
• External integrations

---

34. Automation and Infrastructure as Code

Production VM deployments should be repeatable.

Use:

• Bicep
• ARM templates
• Terraform
• Azure Verified Modules
• Azure Policy
• CI/CD pipelines

Automate:

• VM creation
• Networking
• Disks
• Extensions
• Monitoring
• Backup
• Update configuration
• RBAC
• Defender configuration
• Policy assignments

Avoid one-off portal deployments for large or regulated environments.

---

35. VM Extensions

VM extensions can configure or integrate VMs after deployment.

Examples:

• Azure Monitor Agent
• Custom Script Extension
• Domain Join
• Dependency agent
• Guest Configuration
• Key Vault extension
• Antimalware extensions

Risks include:

• Extension sequencing
• Version changes
• Failed deployments
• Excessive agent count
• Startup delays

Use image baking for stable base software and extensions for environment-specific or lifecycle-managed configuration.

---

36. Configuration Management

Options may include:

• Azure Machine Configuration
• PowerShell DSC
• Ansible
• Chef
• Puppet
• Custom scripts
• Cloud-init

A preferred model is:

Immutable base image
        +
Minimal startup configuration
        +
Policy-based compliance

Avoid manually configuring production VMs after deployment.

---

37. Cost Optimization

VM cost includes more than compute.

VM compute
+ OS licensing
+ managed disks
+ snapshots
+ backup
+ monitoring
+ network egress
+ public IPs
+ load balancers
+ Defender
+ disaster recovery

Cost controls

• Right-size VMs.
• Stop and deallocate unused nonproduction VMs.
• Use schedules for development environments.
• Use Azure Hybrid Benefit where eligible.
• Use Savings Plans or Reservations for predictable workloads.
• Use Spot VMs for interruptible workloads.
• Select appropriate disk tiers.
• Remove unattached disks.
• Set log-retention policies.
• Use autoscaling.
• Review Azure Advisor recommendations.

---

Reserved Instances and Savings Plans

Use when workloads are predictable.

• Reservations provide strong discounts for committed VM usage under defined scope and terms.
• Savings Plans provide more compute flexibility across eligible services.
• On-demand pricing provides the most flexibility but usually the highest unit cost.

Do not reserve an oversized VM before utilization has been validated.

---

Spot VMs

Spot VMs use spare Azure capacity at a discounted rate but can be evicted.

Suitable for:

• Batch processing
• CI agents
• Rendering
• Stateless workers
• Fault-tolerant compute

Unsuitable for:

• Domain controllers
• Databases
• Unique production instances
• Workloads that cannot tolerate interruption

---

38. Quotas and Capacity

VM deployment can fail even when the architecture is correct because of:

• Regional vCPU quota
• VM-family quota
• Zonal capacity
• Disk quota
• Public IP quota
• Network limits

Microsoft maintains current Azure subscription and service quota documentation.

Before production deployment:

1. Confirm regional quota.
2. Request increases early.
3. Validate target-zone capacity.
4. Confirm DR-region quota.
5. Test deployment with the required SKU.

---

39. Recommended Enterprise Architecture

                         Users
                           │
                Azure Front Door / DNS
                           │
                 Application Gateway
                           │
          ┌────────────────┴────────────────┐
          │                                 │
      VM Zone 1                         VM Zone 2
          │                                 │
          └──────── Internal services ──────┘
                           │
                  Private Endpoints
                           │
             Database / Storage / Key Vault

Management plane:
    Azure Policy
    Defender for Cloud
    Azure Update Manager
    Azure Monitor Agent
    VM Insights
    Azure Backup
    Azure Site Recovery

---

40. Scenario: Production Business Application

Requirements

A customer needs to deploy a production application that:

• Runs only on Windows Server
• Requires four vCPUs and 16 GB of memory
• Has moderate disk I/O
• Must survive a datacenter failure
• Requires monthly controlled patching
• Must be privately accessible
• Has a two-hour RTO
• Requires seven years of audit logs

Recommended design

Compute

• Select a supported general-purpose VM family after benchmarking.
• Deploy at least two instances.
• Use a VM Scale Set with flexible orchestration where appropriate.

Availability

• Place instances across Availability Zones.
• Use Application Gateway or Load Balancer.
• Confirm all dependencies are zone resilient.

Storage

• Use managed disks.
• Use Premium SSD or Premium SSD v2 if latency testing justifies it.
• Separate OS, application data and logs.
• Do not use the temporary disk for durable data.

Networking

• Use private subnets.
• Avoid public IPs on VMs.
• Use Azure Bastion or private administrative connectivity.
• Apply NSGs and Azure Firewall where required.

Security

• Enable Trusted Launch.
• Use managed identities.
• Store secrets in Key Vault.
• Enable Defender for Servers.
• Apply the VM security baseline.

Patching

• Use Azure Update Manager.
• Patch one instance at a time.
• Drain traffic before reboot.
• Validate health before continuing.

Monitoring

• Deploy Azure Monitor Agent.
• Use Data Collection Rules.
• Enable VM Insights.
• Send application and security logs to Log Analytics.
• Apply separate retention for seven-year audit requirements.

Backup and DR

• Configure Azure Backup.
• Test file, disk and VM restoration.
• Use Azure Site Recovery if the RTO requires regional recovery.
• Maintain recovery documentation.

---

41. Corrections and Clarifications to the Transcript

“Every Azure region contains multiple Availability Zones”

Not every Azure region supports Availability Zones.

Always verify current zone support for:

• Region
• VM family
• Disk type
• Dependent services

Microsoft’s current region list identifies regions with Availability Zone support.

---

“Unmanaged disks are for customized installations”

This is outdated.

Managed disks are the standard choice for new VM deployments. Custom operating systems can still use managed disks through custom images or uploaded VHDs.

---

Missing Premium SSD v2

The transcript lists:

• Standard HDD
• Standard SSD
• Premium SSD
• Ultra Disk

A current design should also evaluate Premium SSD v2.

---

“Azure Update Management”

The modern service is Azure Update Manager.

Azure Automation Update Management is legacy terminology and should not be the default recommendation for new designs.

---

“Azure Security Center”

The current service name is Microsoft Defender for Cloud.

---

“Azure Diagnostics extension for more detail”

For modern monitoring, prefer:

• Azure Monitor Agent
• Data Collection Rules
• VM Insights

Use legacy or workload-specific extensions only when there is a clear requirement.

---

Multi-region does not automatically provide resilience

A second region requires:

• Application deployment
• Data replication
• Routing
• Identity
• Secrets
• Testing
• Failover automation or runbooks

Simply creating a VM in another region is not a disaster-recovery strategy.

---

42. Design Decision Matrix

---

43. Deployment Checklist

Workload

• Is a VM preferable to PaaS or containers?
• Are CPU and memory requirements measured?
• Are application dependencies documented?
• Are vendor certifications confirmed?

Region and availability

• Is the region compliant?
• Is the VM size available?
• Are Availability Zones supported?
• Is regional quota sufficient?
• Is a secondary region identified?
• Are RTO and RPO documented?

Storage

• Is the disk type appropriate?
• Are IOPS and throughput sufficient?
• Are VM aggregate disk limits sufficient?
• Are data and OS disks separated?
• Is temporary storage used only for disposable data?
• Is caching configured according to workload guidance?

Operating system and image

• Is the OS supported?
• Is the image publisher trusted?
• Is a generalized or specialized image appropriate?
• Is an image lifecycle defined?
• Is Azure Compute Gallery required?

Networking

• Does the VM need a public IP?
• Are NSGs applied?
• Is administrative access private?
• Is load balancing required?
• Is accelerated networking supported?
• Are DNS and hybrid routes correct?

Security

• Is Trusted Launch enabled?
• Are managed identities used?
• Are secrets stored outside the VM?
• Is disk encryption configured?
• Is Defender for Servers required?
• Are vulnerability assessments enabled?
• Is JIT access configured?

Operations

• Is Azure Update Manager configured?
• Are patch rings defined?
• Is Azure Monitor Agent deployed?
• Are Data Collection Rules defined?
• Are alerts configured?
• Is log retention cost controlled?

Recovery

• Is Azure Backup configured?
• Has restore been tested?
• Is Site Recovery required?
• Has failover been tested?
• Are application dependencies included?

Cost

• Has right-sizing been validated?
• Are dev/test shutdown schedules configured?
• Is Azure Hybrid Benefit applicable?
• Are reservations or Savings Plans appropriate?
• Are disk and logging costs included?

---

44. AZ-305 Exam Review

Remember these associations:

• General-purpose VM → Balanced CPU and memory.
• Compute optimized → High CPU-to-memory ratio.
• Memory optimized → Databases and in-memory workloads.
• GPU VM → AI, rendering and visualization.
• Availability Set → Fault domains and update domains.
• Availability Zone → Datacenter-level isolation within a region.
• VM Scale Set → Managed fleet, autoscaling and zone distribution.
• Multi-region → Regional disaster resilience.
• Managed disks → Standard choice for modern VM deployments.
• Premium SSD v2 → Flexible high-performance disk configuration.
• Ultra Disk → Extreme IOPS and low-latency workloads.
• Temporary disk → Nonpersistent data only.
• Ephemeral OS disk → Stateless, disposable VM instances.
• Azure Compute Gallery → Image versioning and distribution.
• Generalized image → Machine identity removed.
• Specialized image → Machine-specific state retained.
• Azure Hybrid Benefit → Use eligible Windows Server licenses.
• Azure Update Manager → Centralized VM patching.
• Azure Monitor Agent → Supported guest telemetry agent.
• VM Insights → VM performance and dependency monitoring.
• Microsoft Defender for Cloud → Security posture and threat protection.
• Azure Backup → Historical VM recovery.
• Azure Site Recovery → Disaster-recovery replication and failover.
• High availability is not backup.
• Backup is not disaster recovery.
• Disk size alone does not determine disk performance.

---

Microsoft Reference Documentation

• Azure Virtual Machines overview.
• Azure VM size overview.
• General-purpose D-family VMs.
• Memory-optimized Easv5 VMs.
• Azure VM availability options.
• Azure Availability Zones.
• Availability Sets overview.
• Virtual Machine Scale Sets overview.
• VM Scale Set reliability.
• Current Azure region list.
• Azure Managed Disks overview.
• Azure managed disk types.
• VM and disk performance.
• Managed disk performance options.
• Disk scalability and performance targets.
• Ephemeral OS disk FAQ.
• Azure disk encryption.
• Azure Compute Gallery.
• Azure Monitor Agent overview.
• Windows VM security baseline.
• Defender for Cloud compute recommendations.
• Defender vulnerability management.
• Azure VM policy definitions.
• Azure service limits and quotas.
• Azure VM restore and cross-zone restore.

---

VM availability deep dive

Azure Virtual Machine Availability — Review Notes and In-Depth Guide

1. Overview

Virtual machine availability means designing an application so it remains operational during:

• Hardware failures
• Host failures
• Planned Azure maintenance
• Datacenter or availability-zone outages
• Traffic spikes
• Individual VM failures
• Regional disasters

A single VM is still a single point of failure, even if it uses managed disks and backup.

A highly available design normally combines:

Multiple VM instances
        +
Availability Zones or fault-domain separation
        +
Load balancing
        +
Health probes
        +
Resilient storage and databases
        +
Monitoring
        +
Backup and disaster recovery

The correct design depends on the workload’s:

• Availability target
• Recovery Time Objective
• Recovery Point Objective
• Failure scenarios
• Budget
• Regional requirements

Microsoft currently recommends Availability Zones as the strongest intra-region VM resiliency option where the region and workload support them.

---

2. High Availability, Fault Tolerance, and Disaster Recovery

These terms are related but different.

High availability

High availability minimizes downtime during expected or localized failures.

Examples:

• One VM fails
• One host fails
• Azure performs planned maintenance
• One application instance becomes unhealthy

Typical controls:

• Multiple VMs
• Load balancer
• Availability Zones
• Availability Sets
• Health probes

---

Fault tolerance

Fault tolerance means the service continues operating when one component fails.

Example:

VM 1 fails
   ↓
VM 2 continues serving users

Fault tolerance requires redundant application instances and resilient dependencies.

---

Disaster recovery

Disaster recovery restores the application after a large-scale failure such as a regional outage.

Typical controls:

• Secondary Azure region
• Azure Site Recovery
• Data replication
• Global traffic routing
• Recovery plans
• Tested failover

High availability
    → Handles local failures

Disaster recovery
    → Handles major regional failures

---

3. Availability Options for Azure VMs

The main Azure VM availability approaches are:

1. Single VM
2. Availability Set
3. Availability Zones
4. Virtual Machine Scale Set
5. Multi-region deployment

---

4. Availability Sets

What is an Availability Set?

An Availability Set is a logical grouping that tells Azure to distribute VMs across separate platform fault and update boundaries.

Availability Set
   ├── VM 1
   ├── VM 2
   └── VM 3

Azure assigns each VM to:

• A fault domain
• An update domain

Availability Sets currently support up to three fault domains and twenty update domains, depending on region and configuration. These values are defined when the Availability Set is created and cannot be changed afterward.

---

5. Fault Domains

A fault domain represents a group of infrastructure that shares certain physical dependencies, such as:

• Power source
• Network switches
• Physical rack
• Host hardware boundaries

Example:

Fault Domain 1
    VM 1

Fault Domain 2
    VM 2

Fault Domain 3
    VM 3

If one physical fault domain fails, VMs in other domains should remain available.

Important clarification

The transcript describes fault domains as isolating resources from failures “at the datacenter level.”

That is too broad.

Fault domains protect mainly against localized physical infrastructure failures inside a datacenter deployment boundary. They do not provide the same datacenter-level isolation as Availability Zones.

---

6. Update Domains

An update domain groups VMs that may undergo platform maintenance and restart together.

Azure processes update domains sequentially during certain planned maintenance operations.

Update Domain 1
    VM 1

Update Domain 2
    VM 2

Update Domain 3
    VM 3

This reduces the risk that all application instances restart simultaneously.

Important clarification

Separate update domains reduce simultaneous planned-maintenance impact, but they do not provide an absolute guarantee that one VM is always available.

Application availability still depends on:

• At least two healthy VMs
• Working health probes
• Load-balancer configuration
• Application startup time
• Database availability
• Sufficient capacity
• Correct update and maintenance behavior

---

7. Availability Set Example

Suppose an application has two VMs:

Availability Set

VM 1
  Fault Domain 1
  Update Domain 1

VM 2
  Fault Domain 2
  Update Domain 2

Benefits:

• A rack-level failure is less likely to affect both VMs.
• Planned platform maintenance is less likely to restart both simultaneously.

However, both VMs may still exist in the same Azure datacenter footprint and region. For stronger datacenter-level isolation, use Availability Zones.

---

8. Availability Zones

What is an Availability Zone?

Availability Zones are physically separate groups of datacenters within an Azure region.

Each zone has independent supporting infrastructure such as:

• Power
• Cooling
• Networking

Many—but not all—Azure regions provide Availability Zones. Service and VM-size support must be checked for the selected region.

Example:

Azure Region

Zone 1
    VM 1

Zone 2
    VM 2

Zone 3
    VM 3

If Zone 1 fails, instances in Zones 2 and 3 can continue operating.

---

9. Zonal vs Zone-Redundant Design

Zonal resource

A zonal VM is pinned to a specific Availability Zone.

Example:

VM 1 → Zone 1
VM 2 → Zone 2

The architect explicitly distributes application instances.

Zone-redundant service

Some Azure services automatically distribute service components across zones.

Azure VMs themselves must be deployed appropriately, usually with:

• Multiple VMs
• A zone-spanning VM Scale Set
• A zone-redundant load-balancing frontend where supported

---

10. Availability Zones Do Not Automatically Create HA

Deploying one VM in one zone does not make the application highly available.

Incorrect:

Zone 1
   One VM

Better:

Zone 1
   VM 1

Zone 2
   VM 2

Zone 3
   VM 3

The application must also have:

• Multiple instances
• Health probes
• Load distribution
• Externalized or replicated state
• Resilient DNS
• Resilient databases
• Zone-compatible disks and dependencies

Availability is an application property, not merely a VM setting.

---

11. Availability Sets vs Availability Zones

For new production workloads in zonal regions, evaluate Availability Zones before Availability Sets. Microsoft’s reliability guidance generally treats zonal deployment as the stronger intra-region design.

---

12. Virtual Machine Scale Sets

A Virtual Machine Scale Set manages a group of VM instances.

It supports:

• Consistent deployment
• Automatic scaling
• Instance replacement
• Load-balancer integration
• Distribution across zones or fault domains
• Centralized lifecycle management

Microsoft describes Scale Sets as providing high availability and application resiliency by distributing VMs across Availability Zones or fault domains.

VM Scale Set
   ├── Instance 1 — Zone 1
   ├── Instance 2 — Zone 2
   ├── Instance 3 — Zone 3
   └── Autoscaling policy

Use a Scale Set when:

• Instances share a consistent configuration.
• The application can scale horizontally.
• Automatic capacity changes are needed.
• Failed instances should be replaced.
• Fleet management is preferred.

---

13. Availability Does Not Equal Scaling

Availability and scaling are complementary but different.

Availability

Two VMs remain running
when one fails

Scaling

Two VMs become ten
when demand increases

A Scale Set can support both, but autoscaling is not automatically enabled simply by creating the Scale Set.

---

14. Load Balancing

A load balancer distributes traffic across multiple healthy application instances.

Clients
   ↓
Load balancer
   ├── VM 1
   ├── VM 2
   └── VM 3

Benefits:

• Removes unhealthy instances from new traffic
• Prevents one server from receiving all requests
• Supports multiple application instances
• Improves availability
• Supports horizontal scaling

---

15. Public vs Internal Azure Load Balancer

Azure Load Balancer is a Layer 4 TCP/UDP service.

Public Load Balancer

Uses a public frontend IP.

Internet
   ↓
Public Load Balancer
   ↓
Backend VMs

Use for:

• Public TCP applications
• Public UDP workloads
• Internet-facing services
• Non-HTTP/S application protocols

Internal Load Balancer

Uses a private frontend IP.

Application tier
   ↓
Internal Load Balancer
   ↓
Backend VMs

Use for:

• Internal application tiers
• Private APIs
• Database listener patterns
• Hybrid applications
• Traffic inside a VNet or connected network

Azure Load Balancer supports both public and internal traffic distribution models.

---

16. Health Probes

A health probe checks whether a backend instance is able to serve traffic.

Example:

Load Balancer
    ↓ probe /health
VM 1 → Healthy
VM 2 → Unhealthy

New traffic is sent only to healthy backend instances according to the configured rules.

Possible probe types include supported configurations such as:

• TCP
• HTTP
• HTTPS

A useful application probe should test more than whether the VM is powered on.

Weak probe:

TCP port 80 is open

Stronger probe:

/health
checks whether the application can process requests

Avoid making the probe so deep that a temporary downstream issue removes every application instance from service.

---

17. Load-Balancing Rule Components

An Azure Load Balancer design includes:

• Frontend IP configuration
• Backend pool
• Health probe
• Load-balancing rule
• Protocol
• Frontend port
• Backend port
• Session persistence setting
• Idle timeout
• Outbound design where applicable

Example:

Frontend:
10.10.1.10:443

Backend pool:
VM 1, VM 2, VM 3

Probe:
HTTPS /health

Rule:
TCP 443 → TCP 443

---

18. Correction: Geographic Routing

The transcript says load balancers can distribute traffic based on geographic location.

That is not generally a feature of a standard regional Azure Load Balancer.

Use the correct service based on scope:

Azure’s multiregion architecture guidance combines global routing with regional load-balancing services rather than using a standard regional load balancer for geographic routing.

---

19. Session Persistence

Session persistence, sometimes called source IP affinity, can direct flows from a client to the same backend instance.

Use it only when necessary.

Potential disadvantages:

• Uneven traffic distribution
• Reduced scaling flexibility
• Greater dependency on one backend instance
• More difficult failover behavior

A better cloud-native design is usually to externalize session state to:

• Azure Cache for Redis
• Database
• Distributed cache
• Token or cookie-based stateless application design

---

20. Application Gateway and Front Door

For HTTP/S applications, Azure Load Balancer might not be the only—or best—choice.

Application Gateway

Provides regional Layer 7 functionality such as:

• Host-based routing
• Path-based routing
• TLS termination
• Web Application Firewall
• Cookie-based affinity
• HTTP health probes

Azure Front Door

Provides global HTTP/S entry capabilities such as:

• Global routing
• Edge acceleration
• Web Application Firewall
• Origin health monitoring
• Multiregion failover
• Traffic distribution based on latency and availability

Example:

Global users
    ↓
Azure Front Door
    ├── Region A: Application Gateway → VMs
    └── Region B: Application Gateway → VMs

---

21. Availability Zones and the Load Balancer Frontend

It is not enough to distribute only the backend VMs.

The frontend must also be designed for the required resilience.

For Standard Load Balancer, evaluate whether the frontend is:

• Zonal
• Zone-redundant
• Non-zonal, depending on region and configuration

Azure publishes separate reliability guidance for Load Balancer and zonal designs.

A zonal frontend tied to one zone may not provide the same resilience as a zone-redundant frontend.

---

22. Storage Availability

VM availability also depends on disk design.

Consider:

• Managed disk redundancy
• Zonal disk placement
• Shared disk architecture
• Application-level replication
• Database availability features
• Backup

A VM may restart elsewhere, but the application cannot recover if required data is unavailable or tied to a failed design.

Microsoft provides specific VM and disk high-availability guidance, including Scale Sets and managed-disk considerations.

---

23. Stateful Applications

Stateless applications are usually easier to make highly available.

Stateless tier

Load Balancer
   ├── Web VM 1
   ├── Web VM 2
   └── Web VM 3

Any instance can handle a request.

Stateful tier

Stateful applications require additional planning for:

• Database replication
• Quorum
• Shared storage
• File locking
• Session state
• Transaction consistency
• Failover coordination

Simply deploying two database VMs across zones does not create a supported database HA solution.

Use application-supported technologies such as:

• SQL Server Always On availability groups
• Database-native replication
• Managed Azure database HA
• Cluster technology supported by the application

---

24. Planned Maintenance

Azure platform maintenance can affect VM hosts.

Availability Sets reduce planned-maintenance impact through update domains.

Availability-zone and Scale Set designs should also use:

• Multiple replicas
• Rolling updates
• Health probes
• Traffic draining
• Maintenance windows
• Application validation
• Controlled patching

Do not update all application instances simultaneously.

---

25. Regional Disaster Recovery

Availability Zones protect against failures inside one region.

They do not protect against complete regional failure.

For regional resilience:

Azure Front Door / Traffic Manager
           ├── Region 1
           │     Load balancer
           │     VM instances
           │
           └── Region 2
                 Load balancer
                 VM instances

You must also replicate:

• Databases
• Storage
• VM images
• Configuration
• Secrets and certificates
• DNS
• Monitoring
• Identity dependencies

Azure’s multiregion guidance combines zonal resilience within each region and separate regional deployments for regional-outage recovery.

---

26. RTO and RPO

Recovery Time Objective

RTO is the maximum acceptable downtime.

Example:

RTO = 30 minutes

The service must be restored within 30 minutes.

Recovery Point Objective

RPO is the maximum acceptable data loss.

Example:

RPO = 5 minutes

At most five minutes of data changes may be lost.

Availability Zones primarily improve service continuity. RPO usually depends more heavily on database, storage, and backup replication.

---

27. Monitoring Availability

Monitor:

• VM availability
• Health-probe status
• Backend health
• CPU and memory
• Disk latency
• Application errors
• Response time
• Failed connections
• Load-balancer data path
• Scaling events
• Zone and platform events

Recommended tools include:

• Azure Monitor
• VM Insights
• Application Insights
• Load Balancer metrics
• Log Analytics
• Service Health
• Resource Health
• Azure Alerts

A VM being “running” does not mean the application is healthy. Monitor the application endpoint and business functionality.

---

28. Example Architecture

Requirement

A production web application must:

• Survive one VM failure
• Survive a zone failure
• Remain privately connected to a database
• Scale when traffic grows
• Recover from a regional outage

Recommended design

Global users
      ↓
Azure Front Door
      ↓
Primary Azure region
      ↓
Zone-redundant Application Gateway
      ↓
VM Scale Set
   ├── VM — Zone 1
   ├── VM — Zone 2
   └── VM — Zone 3
      ↓
Zone-resilient database

Secondary region
   ├── Application deployment
   ├── Replicated data
   └── Tested failover

Additional controls:

• Minimum two or three application replicas
• Health probes
• Autoscaling
• Managed identities
• Azure Monitor
• Backup
• Infrastructure as Code
• Tested disaster-recovery runbook

---

29. Scenario-Based Decisions

Scenario 1: Two legacy VMs in a non-zonal region

Requirement:

• Reduce hardware and maintenance-related downtime
• No horizontal autoscaling requirement

Recommended:

• Availability Set
• Azure Load Balancer
• Separate fault and update domains
• Application health probes

---

Scenario 2: New production application in a zonal region

Requirement:

• Survive datacenter failure
• Multiple identical application instances

Recommended:

• Availability Zones
• VM Scale Set spanning zones
• Zone-redundant frontend
• Health probes
• Autoscaling

---

Scenario 3: Global business-critical application

Requirement:

• Survive complete regional failure

Recommended:

• Multiple Azure regions
• Availability Zones within each region
• Azure Front Door or Traffic Manager
• Regional load balancing
• Data replication
• Tested failover

---

Scenario 4: One database VM

Requirement:

• “High availability” by putting it in an Availability Set

Not sufficient.

An Availability Set requires multiple VMs and an application-level failover mechanism. One VM inside an Availability Set remains one VM.

---

30. Corrections and Clarifications to the Transcript

“Virtual machine availability sets refers to ensuring VMs are operational”

Availability is the broader objective.

An Availability Set is one specific Azure placement mechanism.

---

“Fault domains isolate failures at the datacenter level”

Fault domains isolate groups of shared physical infrastructure. Availability Zones provide broader datacenter-group separation.

---

“VMs in different update domains are never updated simultaneously”

Update domains are designed to sequence certain planned Azure platform maintenance. This should not be interpreted as a universal guarantee covering all operating-system patches, application deployments, failures, or maintenance events.

---

“Zones automatically take over”

Azure does not automatically make a single application instance fail over simply because VMs are placed in zones.

You need:

• Multiple instances
• Load balancing
• Health checks
• Sufficient capacity
• Replicated state

---

“Load balancers route based on geography”

Regional Azure Load Balancer does not normally perform geographic routing.

Use Azure Front Door, Traffic Manager, or appropriate cross-region services for global routing.

---

“Load balancing prevents failure”

A load balancer does not prevent a VM from failing.

It detects unhealthy instances and directs new traffic to healthy ones.

---

31. Quick Decision Matrix

---

32. AZ-305 Exam Review

Remember these associations:

• Availability Set → Fault domains and update domains.
• Fault domain → Shared physical infrastructure failure boundary.
• Update domain → Planned platform-maintenance grouping.
• Availability Zone → Separate datacenter group within one Azure region.
• Availability Zones → Stronger intra-region resilience than Availability Sets.
• VM Scale Set → Consistent VM fleet, scaling, and zonal/fault-domain distribution.
• Azure Load Balancer → Regional Layer 4 TCP/UDP distribution.
• Public Load Balancer → Internet-facing frontend.
• Internal Load Balancer → Private VNet frontend.
• Health probe → Determines which backend instances receive new traffic.
• Application Gateway → Regional Layer 7 HTTP/S and WAF.
• Azure Front Door → Global HTTP/S routing and acceleration.
• Traffic Manager → DNS-based global routing.
• Availability Zone does not automatically mean the application is highly available.
• One VM in an Availability Set is still one VM.
• Load balancing does not replace multiple backend instances.
• High availability, scaling, backup, and disaster recovery are separate concerns.

---

Microsoft Reference Documentation

• Azure VM availability options.
• Reliability in Azure Virtual Machines.
• Availability Sets overview.
• Availability Zones overview.
• Architecture guidance for regions and Availability Zones.
• Virtual Machine Scale Sets overview.
• Reliability in Virtual Machine Scale Sets.
• Azure Load Balancer overview.
• Azure Load Balancer components.
• Azure Load Balancer health probes.
• Reliability in Azure Load Balancer.
• Multiregion load-balancing architecture.
• Azure VM baseline architecture.
• High-availability guidance for Azure VM disks.

---

Secure VM traffic deep dive

Securing Virtual Machine Management Traffic — Review Notes and In-Depth Guide

1. What Is VM Management Traffic?

Virtual machine management traffic is administrative network traffic used to configure, troubleshoot, or operate VMs.

Common examples include:

• RDP for Windows
• SSH for Linux
• Windows Remote Management
• PowerShell remoting
• Configuration-management traffic
• Monitoring and support connections
• File transfer during administration
• Database or application administration ports

The most common management ports are:

These ports are attractive attack targets because they can provide direct administrative access to the operating system.

Common threats include:

• Brute-force password attempts
• Credential stuffing
• Stolen SSH keys
• Password spraying
• Man-in-the-middle attacks
• Exploitation of unpatched services
• Session hijacking
• Lateral movement after compromise

The primary design objective is:

Administrators must be able to reach management interfaces, but those interfaces should not be permanently exposed to the Internet.

---

2. Recommended Security Model

A secure administrative-access architecture uses several layers:

Administrator identity
        ↓
MFA and Conditional Access
        ↓
Azure RBAC
        ↓
Bastion, VPN, or approved management network
        ↓
NSG and firewall restrictions
        ↓
RDP or SSH over private IP
        ↓
VM operating-system authorization
        ↓
Monitoring and audit logs

No single control is sufficient.

For example:

• An NSG restricts network traffic but does not validate the administrator inside the VM.
• Azure RBAC permits Azure management actions but does not automatically grant operating-system login.
• Azure Bastion provides a secure path but does not replace VM authentication.
• JIT controls when a port opens but does not patch or harden the operating system.

---

3. Avoid Public IPs on Production VMs

The strongest default is to avoid assigning public IP addresses directly to VMs.

Instead, connect through:

• Azure Bastion
• Point-to-Site VPN
• Site-to-Site VPN
• ExpressRoute
• A hardened privileged-access network
• A controlled jump-host design when required

Microsoft’s current networking guidance recommends private administrative access rather than exposing SSH or RDP directly to the Internet.

Insecure model

Internet
   ↓
Public IP on VM
   ↓
TCP 22 or 3389

Risks:

• Continuous Internet scanning
• Brute-force attempts
• Management port exposure
• Greater dependency on source-IP filtering
• Larger attack surface

Preferred model

Administrator
      ↓
Azure Bastion / VPN
      ↓
Private VNet
      ↓
VM private IP

---

4. Azure Bastion

What Is Azure Bastion?

Azure Bastion is a fully managed Azure service for connecting to VMs through RDP or SSH without assigning public IP addresses to the target VMs.

It is deployed into an Azure virtual network and connects to target VMs using their private IP addresses. Connections can be initiated through the Azure portal or, with supported configurations, through native RDP and SSH clients.

Administrator
      ↓ TLS
Azure Bastion
      ↓ private VNet traffic
VM private IP
      ↓
RDP or SSH service

Main benefits

• Target VMs do not require public IP addresses.
• RDP and SSH ports do not need to be exposed to the public Internet.
• Microsoft manages the Bastion platform.
• Browser-based RDP and SSH are available.
• Supported configurations allow native RDP and SSH clients.
• One Bastion deployment can support multiple VMs reachable within the designed network scope.
• Target VMs do not require a Bastion-specific agent.

---

Important clarification: Does Bastion use the Internet?

The transcript says that Bastion traffic “never traverses the public Internet.”

A more accurate explanation is:

• The target VM does not need a public IP.
• The RDP or SSH service on the VM is not directly exposed to the Internet.
• The connection to Bastion is protected with TLS.
• Bastion then reaches the VM through private Azure networking.

Most normal Bastion deployments still have a Bastion public endpoint. Microsoft also supports a private-only Bastion deployment model with qualifying configurations.

Therefore, the key security benefit is not that no Internet path exists anywhere—it is that the VM’s management port is not directly Internet-accessible.

---

5. Azure Bastion Connection Methods

Depending on Bastion SKU and configuration, administrators can connect using:

• Browser-based SSH
• Browser-based RDP
• Native SSH client
• Native RDP client
• Azure CLI tunnelling
• IP-based connections to supported reachable targets

Native-client support allows administrators to retain familiar tools while routing the connection through Bastion.

IP-based Bastion connections can reach supported machines by IP address, including Azure or non-Azure machines reachable through VPN or ExpressRoute in supported configurations.

---

6. Bastion Network Requirements

A traditional Bastion deployment uses a dedicated subnet named:

AzureBastionSubnet

The Bastion service must be able to reach the target VM’s private IP and management port.

For target VM NSGs, permit management traffic from the Bastion subnet rather than from the entire Internet.

Example conceptual rule:

Source:
AzureBastionSubnet CIDR

Destination:
VM subnet or VM NIC

Port:
22 or 3389

Action:
Allow

Then deny or omit direct Internet-based access to those ports.

Do not create a broad rule such as:

Source: Any
Port: 3389
Action: Allow

---

7. Microsoft Entra ID Authentication

Where supported, use Microsoft Entra ID authentication for VM sign-in instead of relying only on local accounts.

For Linux VMs, Entra ID can support OpenSSH certificate-based authentication.

Azure Bastion also supports Entra ID authentication for qualifying Windows and Linux configurations. The VM must have the required login extension and the user must have an appropriate login role.

Common Azure roles include:

• Virtual Machine User Login
• Virtual Machine Administrator Login

Benefits

• Central identity lifecycle
• Easier removal of access
• Microsoft Entra Conditional Access integration in supported flows
• Reduced use of shared local accounts
• Better individual attribution
• Less dependence on long-lived SSH keys or passwords

Important distinction

Azure resource roles and OS login roles are different.

For example:

• VM Contributor can manage the Azure VM resource.
• Virtual Machine User Login grants normal OS login.
• Virtual Machine Administrator Login grants administrative OS login.

A user should not automatically receive both resource-management and operating-system administrative access.

---

8. Just-in-Time VM Access

What Is JIT?

Just-in-time VM access is a Microsoft Defender for Cloud capability that keeps selected inbound management ports closed and opens them temporarily after an authorized access request.

It reduces the amount of time a VM management port is reachable.

Normal state:
Port 22/3389 blocked

Administrator requests access:
Source IP + port + duration approved

Temporary state:
Port available for requested source

After expiry:
Port blocked again

---

JIT can control

• Which ports can be opened
• Which source IP addresses are allowed
• How long access is permitted
• Which users can request access
• Whether access is controlled through NSGs or supported firewall rules
• Audit history of requests

Defender for Cloud creates or manages deny and temporary allow rules for the selected ports. Existing higher-priority rules can affect the result, so rule evaluation still matters.

---

9. JIT Example

Suppose a VM requires occasional SSH access.

Without JIT

TCP 22:
Open continuously from administrator network

With JIT

Default:
TCP 22 blocked

Request:
Source IP 203.0.113.10
Port 22
Duration 1 hour

After one hour:
Temporary rule expires

This reduces exposure but still requires:

• Strong SSH authentication
• OS hardening
• Patch management
• RBAC
• Monitoring
• Restricted source IP selection

---

10. JIT vs Azure Bastion

JIT and Bastion solve related but different problems.

---

Should Bastion and JIT always be combined?

Not necessarily.

If Bastion is used and:

• VMs have no public IPs,
• NSGs allow RDP/SSH only from the Bastion subnet,
• no other network source can directly reach management ports,

then JIT may add limited value for the Bastion path.

JIT is most valuable where administrators connect directly over:

• A public IP
• A VPN
• ExpressRoute
• A management VNet
• A corporate network

and the management port should remain closed except during approved windows.

A layered architecture may still combine them where policy requires time-bound access even across private networks, but this should be deliberately designed rather than automatically assumed.

---

11. Network Security Groups

NSGs provide stateful Layer 3 and Layer 4 filtering for VM management traffic.

Rules can consider:

• Source IP or service tag
• Destination IP
• Source port
• Destination port
• Protocol
• Direction
• Priority
• Allow or deny action

NSGs may be associated with:

• A subnet
• A network interface
• Both

When NSGs exist at both levels, traffic must be permitted by the effective combination.

---

12. NSG Best Practices for Management Traffic

Use narrow source ranges

Good:

Source:
Approved management subnet

Destination:
VM subnet

Port:
22

Action:
Allow

Poor:

Source:
Internet

Destination:
Any

Port:
22

Action:
Allow

Separate Windows and Linux rules

Avoid one broad rule that permits both SSH and RDP everywhere.

Example:

Windows-management rule:
Source = Bastion subnet
Destination = Windows server subnet
Port = 3389

Linux-management rule:
Source = Bastion subnet
Destination = Linux server subnet
Port = 22

Scope rules to the required assets

Do not permit a management tool to access all workloads merely because it technically can.

Separate:

• Production
• Development
• Shared services
• Domain controllers
• Database servers
• Network appliances

Avoid conflicting subnet and NIC rules

Excessive use of both subnet-level and NIC-level NSGs can make troubleshooting difficult. Microsoft notes that conflicting or priority-ordered NSG rules are a common cause of RDP failures.

Use a consistent policy model and review effective security rules.

---

13. NSGs Are Necessary but Not Sufficient

An NSG does not provide:

• User identity authentication
• MFA
• Password protection
• SSH key management
• Session recording
• OS authorization
• Patch management
• Malware protection
• Command auditing

Therefore:

NSG
 +
Strong authentication
 +
Private connectivity or Bastion
 +
JIT where appropriate
 +
Endpoint security
 +
Logging

is stronger than relying on NSGs alone.

---

14. Point-to-Site VPN

A Point-to-Site VPN allows an individual administrator’s device to connect privately to an Azure VNet.

Administrator laptop
       ↓ encrypted VPN
Azure VPN Gateway
       ↓ private IP
VM

This can be appropriate when administrators need access to:

• Multiple VMs
• Private applications
• Databases
• Storage endpoints
• Internal administration tools

Microsoft’s VM administration guidance compares Point-to-Site VPN with Bastion and JIT as complementary access models.

Bastion vs Point-to-Site VPN

---

15. Jump Hosts

A jump host is a VM used as an administrative entry point.

Administrator
      ↓
Jump host
      ↓
Target VMs

A jump host may be needed when:

• Specialized administration software must be installed.
• Legacy protocols are required.
• A privileged access workstation must exist inside Azure.
• Session tooling cannot run through Bastion.

However, jump hosts introduce additional responsibilities:

• OS patching
• Backup
• Endpoint protection
• Credential protection
• High availability
• Monitoring
• Licensing
• Attack-surface management

Use Azure Bastion instead where it satisfies the requirement. If a jump host is required, treat it as a highly privileged security asset.

---

16. Privileged Access Workstations

Highly privileged administrators should use controlled administrative devices rather than normal daily-use laptops.

A privileged access workstation should have:

• Restricted software
• Strong endpoint protection
• Encrypted storage
• MFA
• Limited browsing and email use
• Device compliance
• Conditional Access enforcement
• Central monitoring

This reduces the risk that compromised user workstations expose VM administrative credentials.

---

17. SSH Security

For Linux management:

• Prefer SSH keys or Entra ID authentication over passwords.
• Disable password authentication where operationally possible.
• Disable direct root login.
• Use individual accounts.
• Protect private keys.
• Rotate compromised keys.
• Restrict source networks.
• Use recent SSH versions and ciphers.
• Monitor failed login attempts.
• Remove unused accounts.

Example conceptual SSH settings:

PermitRootLogin no
PasswordAuthentication no

Any OS-level configuration should first be tested against recovery requirements and emergency-access procedures.

---

18. RDP Security

For Windows management:

• Prefer Entra ID or domain-based individual identities.
• Require Network Level Authentication.
• Avoid shared local administrator accounts.
• Use MFA before reaching the management path.
• Restrict clipboard, drive, and file transfer where necessary.
• Patch Windows regularly.
• Apply account lockout protections.
• Monitor failed sign-ins.
• Use Local Administrator Password Solution where local accounts remain necessary.
• Avoid exposing TCP 3389 to the Internet.

---

19. Zero Trust Principles

Secure VM management should follow Zero Trust:

Verify explicitly

Use:

• Entra ID
• MFA
• Conditional Access
• Device compliance
• RBAC
• OS-level authentication

Use least privilege

Separate:

• VM reader
• VM operator
• Normal OS user
• OS administrator
• Network administrator
• Security administrator

Assume breach

Design for:

• Credential theft
• Compromised administrator endpoints
• Malicious insiders
• Lateral movement
• Audit and forensic requirements

---

20. Management Plane vs Data Plane vs OS Login

These access types should not be confused.

A user may be able to start a VM but not log in to it.

Another user may be able to log in but not resize or delete the Azure VM resource.

This separation is desirable.

---

21. Emergency Access

Even secure environments require a recovery path.

Possible emergency options include:

• Azure Serial Console
• Run Command
• VMAccess extension
• Recovery VM and disk repair
• Break-glass administrative account
• Controlled NSG emergency rule
• Backup restoration

Emergency procedures should be:

• Documented
• Restricted
• Logged
• Tested
• Time-limited
• Reviewed after use

Do not leave a permanent Internet-accessible SSH or RDP rule merely as an emergency mechanism.

---

22. Monitoring and Auditing

Monitor both Azure-side and guest-OS activity.

Azure-side monitoring

Collect:

• Azure Activity Log
• NSG flow information or supported network telemetry
• Defender for Cloud alerts
• JIT access requests
• Bastion diagnostic logs where configured
• RBAC changes
• Public IP assignments
• NSG rule changes
• Firewall policy changes

Guest OS monitoring

Collect:

• Windows Security event logs
• Linux authentication logs
• Successful and failed sign-ins
• Privilege elevation
• New local accounts
• SSH key changes
• Remote administration activity
• Service changes

Send important logs to:

• Log Analytics
• Microsoft Sentinel
• A protected SIEM platform

---

23. Alerts to Configure

Useful alerts include:

• Public IP attached to a protected VM
• NSG rule opens port 22 or 3389 to the Internet
• Excessive failed RDP or SSH attempts
• JIT configuration removed
• Unusual administrator sign-in
• New privileged OS account
• Bastion configuration changed
• VM login role assigned
• Defender for Servers disabled
• Security agent stopped
• Administrator access outside approved hours

---

24. Azure Policy and Governance

Azure Policy can help audit or prevent insecure management configurations.

Potential policies include:

• Audit VMs with public IP addresses.
• Deny management ports open from the Internet.
• Require JIT configuration.
• Require Defender for Servers.
• Require approved VM extensions.
• Deploy diagnostic settings.
• Restrict allowed regions.
• Require Trusted Launch.
• Audit Entra-based VM login configuration.

A common rollout model is:

Audit
  ↓
Remediate existing resources
  ↓
Deny new noncompliant deployments

---

25. Recommended Enterprise Architecture

Privileged administrator device
              ↓
Microsoft Entra ID + MFA
              ↓
Conditional Access
              ↓
Azure RBAC
              ↓
Azure Bastion in hub VNet
              ↓
Hub-and-spoke private routing
              ↓
NSG permits RDP/SSH only from Bastion subnet
              ↓
Target VM private IP
              ↓
Entra ID or controlled OS authentication
              ↓
Logs to Log Analytics / Sentinel

Optional controls:

• Defender for Servers
• JIT for approved direct management paths
• Azure Firewall
• Privileged Identity Management
• Private-only Bastion
• Session or command monitoring
• Azure Policy

---

26. Scenario 1: Production Windows Servers

Requirements

• No public VM IPs
• Administrators need occasional RDP
• Access must be individually attributable
• MFA required
• Central logging required

Recommended solution

• Deploy Azure Bastion in the hub VNet.
• Connect target VMs by private IP.
• Allow TCP 3389 only from the Bastion subnet.
• Use Entra ID authentication where supported.
• Assign Virtual Machine Administrator Login only to the approved administrator group.
• Activate privileged roles through PIM.
• Send Bastion, Azure Activity, and Windows security logs to the monitoring platform.
• Deny direct Internet RDP with Azure Policy and NSGs.

---

27. Scenario 2: Linux Administrators over Corporate VPN

Requirements

• Administrators connect through Point-to-Site VPN.
• SSH should be available only when requested.
• Source IP must be limited.
• Access must expire automatically.

Recommended solution

• Use a private VM without a public IP.
• Require VPN connectivity.
• Configure JIT for TCP 22.
• Restrict temporary access to the administrator’s VPN address range.
• Use Entra ID or SSH certificate/key authentication.
• Disable SSH passwords and root login where supported.
• Log JIT requests and Linux authentication events.

---

28. Scenario 3: Small Development Environment

Requirements

• Five nonproduction VMs
• Occasional developer access
• Cost-sensitive
• No broad corporate VPN

Possible solution

• Use Azure Bastion Developer or another suitable Bastion configuration where its limitations meet requirements.
• Keep VMs private.
• Use Entra ID login.
• Shut down or deallocate unused VMs.
• Restrict management access through RBAC.
• Avoid direct public RDP and SSH.

The exact Bastion SKU should be selected from current feature and pricing requirements rather than assuming every SKU supports native clients, private-only access, recording, or other advanced capabilities.

---

29. Corrections and Clarifications to the Transcript

“Bastion traffic never traverses the public Internet”

More precisely:

• Target VMs do not expose RDP or SSH directly to the Internet.
• Bastion connects to target VMs over private IP.
• The administrator commonly reaches Bastion over TLS through its managed endpoint.
• Private-only Bastion is available in supported configurations.

“JIT automatically closes the port”

JIT manages temporary access through supported NSG and firewall rules.

Its effectiveness depends on:

• Rule priorities
• No conflicting broader allow rule
• Correct policy configuration
• Supported network architecture

Existing higher-priority rules can undermine the intended deny configuration.

“NSGs, JIT, and Bastion should almost always all be used”

NSGs are fundamental.

Bastion and JIT should be selected according to the access path:

• Bastion provides the path.
• JIT provides time-bound port opening.
• Using both may be appropriate, but it is not mandatory in every private Bastion architecture.

“Cost is the main reason not to use Bastion or JIT”

Cost matters, but design decisions also depend on:

• Administrative workflow
• Network topology
• Identity integration
• Feature requirements
• Regional deployment
• Availability
• Compliance
• Operational complexity

---

30. Decision Matrix

---

31. AZ-305 Exam Review

Remember these associations:

• Management traffic → RDP, SSH, WinRM, and similar administrative protocols.
• Azure Bastion → Managed RDP/SSH path to VMs over private IP.
• Bastion does not require public IPs on target VMs.
• Bastion is a connection path, not an OS authorization system.
• JIT VM access → Opens selected ports temporarily.
• JIT is part of Microsoft Defender for Cloud’s Defender for Servers capabilities.
• NSG → Stateful subnet/NIC traffic filtering.
• Point-to-Site VPN → Private network access for individual administrators.
• Entra ID login → Central identity-based Windows or Linux VM authentication where supported.
• Azure RBAC and OS login are separate authorization layers.
• Do not expose TCP 22 or 3389 broadly to the Internet.
• Use multiple controls together, but only where each control adds value.
• A private IP alone does not guarantee security; routing, NSGs, identity, and monitoring still matter.
• JIT reduces exposure time but does not replace strong authentication or patching.

---

Microsoft Reference Documentation

• Azure Bastion overview.
• Developer and administrator access to Azure VMs.
• Azure Bastion native-client connections.
• Azure Bastion RDP connectivity.
• Azure Bastion SSH connectivity.
• Azure Bastion IP-based connections.
• Private-only Azure Bastion deployment.
• Microsoft Entra ID authentication through Bastion.
• Linux VM sign-in using Microsoft Entra ID.
• Just-in-time VM access overview.
• Enable just-in-time VM access.
• Troubleshoot NSG-related RDP access.

---

VM backup recovery deep dive

Azure Virtual Machine Backup and Recovery — Review Notes and In-Depth Guide

1. Overview

Azure VM Backup protects Azure virtual machines against:

• Accidental deletion
• Disk or file corruption
• Failed operating-system updates
• Ransomware
• Application errors
• Administrative mistakes
• Infrastructure failure
• Long-term retention requirements

Azure VM Backup is a managed Azure Backup workload that creates policy-based recovery points for supported Azure VMs and stores backup data through a Recovery Services vault.

A complete design should answer four questions:

How often must backups occur?
How long must recovery points be retained?
What consistency level does the workload require?
How quickly and where must the VM be restored?

Core distinction: Backup restores an earlier state. It does not by itself provide an immediately running standby application.

---

2. Backup Is Not High Availability or Disaster Recovery

These concepts solve different problems.

Example:

One VM fails
    ↓
Availability design keeps service running

Files are deleted
    ↓
Azure Backup restores historical data

Entire region fails
    ↓
Site Recovery or multiregion design restores service

A business-critical VM may require all three:

• High availability
• Backup
• Disaster recovery

---

3. Azure VM Backup Architecture

A typical Azure VM backup design is:

Azure VM
   ├── OS disk
   ├── Data disks
   └── Azure VM backup extension or supported snapshot process
            ↓
      Recovery Services vault
            ↓
      Recovery points

Azure Backup generally uses snapshot-based protection first, followed by transfer or consolidation into the vault tier according to the policy and backup architecture. Instant Restore retains snapshots for faster recovery for a configured period.

---

4. Recovery Services Vault

Azure VM backups are managed through a Recovery Services vault.

The vault provides a management and protection boundary for:

• Backup policies
• Protected VMs
• Recovery points
• Backup jobs
• Restore operations
• Soft delete
• Immutability
• Monitoring
• Cross Region Restore where supported

Important design settings

When creating a vault, evaluate:

• Vault region
• Storage redundancy
• Cross Region Restore
• Soft delete
• Immutable vault
• Private connectivity requirements
• RBAC
• Monitoring
• Resource Guard or multi-user authorization where applicable

A VM is generally backed up to a vault in the same region as the VM.

---

5. Standard and Enhanced Backup Policies

Azure VM Backup supports different policy models.

Standard policy

Typically used for traditional once-per-day VM protection.

The default policy currently performs one daily backup, retains daily recovery points for 30 days, and retains Instant Restore snapshots for two days. Snapshot retention can be configured within supported limits.

Enhanced policy

Enhanced policy supports newer VM configurations and additional capabilities such as:

• Multiple backups per day
• Backup intervals as frequent as every four hours
• Longer Instant Restore snapshot retention
• Zone-resilient snapshot-tier recovery points
• Configurable multi-disk crash-consistent protection for supported VMs

Enhanced policy may be required or preferred for newer VM and disk configurations, but compatibility must be checked against the current VM Backup support matrix.

---

6. Backup Frequency

Backup frequency determines the possible data-loss window.

Example:

Backup once every 24 hours
    ↓
Potential RPO can approach 24 hours

Backup every 4 hours
    ↓
Potential RPO can approach 4 hours

The actual business RPO also depends on:

• Whether backups succeed
• Application consistency
• Database-native backups
• Replication
• Transaction logs
• Restore-point availability

Frequency selection

VM-level backup frequency should not be assumed to satisfy a database’s transaction-level RPO.

---

7. Retention Policies

Retention controls how long recovery points remain available.

A policy can contain different retention periods, such as:

Daily recovery points   → 30 days
Weekly recovery points  → 12 weeks
Monthly recovery points → 24 months
Yearly recovery points  → 7 years

Retention should be based on:

• Business recovery requirements
• Legal obligations
• Compliance
• Audit periods
• Ransomware recovery windows
• Cost
• Data-change rate

Longer retention creates more recovery choices but increases backup-storage consumption.

---

8. Backup Consistency Levels

The transcript mentions application-consistent, crash-consistent, and file-consistent backups. These terms require careful distinction.

---

Application-consistent backup

An application-consistent recovery point coordinates with the operating system and supported applications before the snapshot is taken.

For Windows, this commonly uses Volume Shadow Copy Service writers. For Linux, application-consistent backup can use configured pre-scripts and post-scripts.

It is designed to capture:

• Disk contents
• Flushed application writes
• Application state required for clean recovery
• Consistent multi-disk application data, where supported

Use it for:

• SQL Server
• Transactional applications
• Domain services
• Workloads requiring cleaner application recovery

Important correction

Application-consistent backup does not generally capture active RAM contents as a suspended machine-memory image.

Instead, it aims to quiesce supported applications and flush pending operations so the disk state can be recovered consistently.

---

File-system-consistent backup

A file-system-consistent recovery point ensures the file system is consistent, but applications may not have been fully quiesced.

It generally captures:

• Disk state
• File-system metadata
• Completed file-system operations

Applications may still need transaction-log replay or recovery after restoration.

---

Crash-consistent backup

A crash-consistent recovery point represents the disks as though the VM had lost power at that moment.

It captures completed disk writes but does not necessarily coordinate with applications or flush in-memory application transactions.

Azure Backup can create crash-consistent backups when:

• The VM is stopped
• Application or file-system-consistent processing fails
• Crash-consistent protection is explicitly selected through a supported Enhanced policy configuration

Crash-consistent backup may be adequate for:

• Stateless servers
• Re-creatable systems
• Applications with strong built-in crash recovery
• Situations where application quiescing is unavailable

---

Consistency comparison

---

9. Snapshot-Based Incremental Backup

Azure VM Backup uses incremental technology so that, after the initial protection cycle, only changed data blocks need to be processed for subsequent recovery points.

Conceptually:

Initial backup
    ↓
Full protected disk state

Next backup
    ↓
Changed blocks only

Next backup
    ↓
New changed blocks only

This reduces:

• Backup duration
• Network transfer
• Storage consumption
• Processing overhead

The vault still presents complete logical recovery points to the administrator.

---

10. Instant Restore

Instant Restore retains disk snapshots close to the VM for faster recovery.

Current documented defaults are:

• Standard policy: two days
• Enhanced policy: seven days

Supported configurable ranges include:

• Standard policy: one to five days
• Enhanced policy: one to thirty days

Benefits

• Faster disk restore
• Faster VM restore
• Reduced time to begin recovery
• Useful for recent failures

Trade-offs

• Snapshot storage cost
• Different supported retention limits by policy
• Dependency on the source-region snapshot tier

Older recovery points are typically restored from the vault tier and may take longer.

---

11. Recovery Options

Azure Backup provides multiple recovery paths.

Current VM restore options include:

• Create a new VM
• Restore disks
• Replace existing disks
• Recover individual files and folders
• Restore to another zone or region where supported

---

12. Create a New VM

This option creates a new VM from the selected recovery point.

Recovery point
      ↓
New managed disks
      ↓
New VM

Use it when:

• The original VM was deleted.
• You want a safe recovery test.
• You do not want to overwrite production.
• You need a parallel forensic copy.
• You want to validate data before cutover.

This is often the safest first recovery method because the original VM remains unchanged.

Considerations

You may need to reconfigure:

• Network Security Groups
• Public IP addresses
• Load balancer membership
• Availability Zone
• VM size
• Managed identity
• Extensions
• DNS
• Backup configuration
• Monitoring
• Application integrations

A VM backup protects VM and disk state, but it does not guarantee that every surrounding Azure resource is recreated exactly as part of a simple restore.

---

13. Restore Disks

This option restores the OS and data disks without automatically creating a VM.

Recovery point
      ↓
Restored managed disks

Use it when:

• You want to inspect disks.
• You need a customized VM deployment.
• You want to attach a restored disk to another VM.
• You need to build the VM using Infrastructure as Code.
• The automatic VM creation option is unsuitable.

Microsoft specifically recommends disk restore when additional configuration must be applied through templates, PowerShell, or customized deployment logic.

---

14. Replace Existing Disks

The replace existing option restores disks from a recovery point and replaces the corresponding disks on the original VM.

Existing VM
     ↓
Current OS/data disks replaced
     ↓
Restored disks attached

Use it when:

• The original VM still exists.
• You want to roll back the VM.
• The VM configuration should remain associated with the original resource.

Important limitations include:

• The original VM must still exist.
• The option is unavailable for some VM and backup configurations.
• Selective disk backup can limit create-new-VM or replace-existing functionality.
• Replacing disks modifies source data and should be treated as a high-impact operation.

Restore to a new VM first when validation or forensics are required.

---

15. File and Folder Recovery

Azure Backup can mount or expose disks from a VM recovery point so that individual files and folders can be copied without restoring the entire VM.

This capability is available for supported Resource Manager VMs protected in a Recovery Services vault.

Use file recovery when:

• One user deleted a document.
• One configuration file is corrupt.
• A folder needs to be recovered.
• Restoring the entire VM would be excessive.

Conceptual process:

Select recovery point
      ↓
Generate recovery script or mount access
      ↓
Mount recovery volumes
      ↓
Copy required files
      ↓
Unmount recovery volumes

Important consideration

File recovery is not the same as application-level database recovery. For SQL Server or another transactional application, use the supported workload-aware restore method when consistency matters.

---

16. Cross Zone Restore

Cross Zone Restore can restore supported Azure VMs into another Availability Zone within the same region.

This can help when:

• The original zone is unavailable.
• You need to rebuild in another zone.
• A zonal VM must be recovered without waiting for the source zone.

Current Azure Backup restore documentation includes cross-zonal VM recovery for supported configurations.

Support depends on factors such as:

• VM type
• Encryption
• Recovery-point tier
• Region
• Disk type
• Backup policy

---

17. Cross Region Restore

Cross Region Restore allows supported backups stored with geo-redundant vault storage to be restored in the Azure paired secondary region.

Supported actions can include:

• Create a new VM in the secondary region
• Restore disks in the secondary region

Use cases

• Regional outage
• Disaster-recovery testing
• Compliance testing
• Secondary-region recovery drills
• Primary-region unavailability

Important correction

Choosing GRS does not automatically make every backup immediately available for normal recovery in another arbitrary Azure region.

Cross Region Restore must be supported and enabled, and recovery is generally tied to the Azure paired region and current service support.

---

18. Backup Storage Redundancy

Vault redundancy affects how backup data is replicated.

Common options include:

• Locally redundant storage
• Zone-redundant storage where supported
• Geo-redundant storage

LRS

Provides lower-cost replication inside the primary region.

Appropriate when:

• Regional backup loss is acceptable.
• Another independent copy exists.
• The workload is noncritical.

ZRS

Provides zone resilience within the region where supported.

Appropriate when:

• Backup data must survive a zonal failure.
• Cross-region backup recovery is not required.

GRS

Replicates backup data to a secondary region.

Appropriate when:

• Regional disaster protection is required.
• Cross Region Restore is required and supported.
• Residency rules permit secondary-region storage.

Do not select GRS automatically for every workload. Evaluate data residency, cost, recovery requirements, and supported restoration behavior.

---

19. Encryption

Azure Backup protects data during transfer and at rest.

Depending on the workload and vault configuration, encryption options may include:

• Platform-managed keys
• Customer-managed keys
• Encryption of source VM disks
• Encrypted VM restore support

Microsoft documents backup and restore support for encrypted Azure VMs, but exact compatibility depends on the encryption method and VM configuration.

Customer-managed key considerations

If customer-managed keys are used, protect:

• Key Vault
• Managed identities
• Key permissions
• Key versions
• Purge protection
• Soft delete
• Key availability in the recovery region

A backup may exist but remain unusable if required decryption keys are unavailable.

---

20. Soft Delete and Immutable Vault

Backup data is itself a high-value security target.

Azure Backup provides controls such as:

• Soft delete
• Immutable vault
• RBAC
• Multi-user authorization or Resource Guard in supported scenarios
• Security alerts
• Vault protection controls

An Immutable vault blocks operations that could result in recovery-point loss. When locked, it provides irreversible WORM-style protection against disabling immutability and deleting protected backups before expiry.

Why this matters

Without protected backup controls:

Attacker compromises admin account
        ↓
Deletes production VM
        ↓
Deletes backup recovery points

With protected backup controls:

Attacker attempts deletion
        ↓
Soft delete / immutability / authorization controls
        ↓
Recovery points remain available

---

21. Azure Policy and Backup Governance

Azure Policy can help standardize protection across subscriptions and resource groups.

Possible governance patterns include:

• Audit VMs without backup.
• Automatically configure supported VMs for backup.
• Enforce approved backup policies.
• Restrict vault regions.
• Require diagnostic settings.
• Audit immutable-vault configuration.
• Prevent deletion of required backup resources.

At scale, use:

• Azure Policy
• Backup Center
• Azure Monitor
• Infrastructure as Code
• Standardized vault and policy designs

Microsoft documents centralized protection of multiple VMs using a Recovery Services vault and reusable backup policies.

---

22. Selective Disk Backup

Not every attached disk must necessarily be included in backup.

Selective disk backup can exclude disks that contain:

• Temporary data
• Re-creatable caches
• Large noncritical datasets
• Data protected separately

Benefits:

• Reduced backup-storage consumption
• Shorter backup time
• Lower cost

However, selective disk backup can restrict certain restore operations. For example, some configurations do not support automatic create-new-VM or replace-existing restore options.

Do not exclude disks that contain:

• Application configuration
• Transaction logs required for recovery
• Database data
• Required boot dependencies
• Unique business data

---

23. VM Backup vs Azure Disk Backup

Azure VM Backup protects the VM as a workload.

Azure Disk Backup protects individual managed disks using a Backup vault-based model.

Azure Disk Backup can support multiple backups per day and may be useful where disk-level protection is required without full VM backup.

---

24. Application Workloads Need Layered Protection

A VM-level backup may not be sufficient for applications with strict transactional requirements.

SQL Server example

Use:

Azure VM Backup
      +
SQL Server workload backup

VM Backup protects:

• OS
• Configuration
• VM disks

SQL workload backup protects:

• Databases
• Transaction logs
• Point-in-time database recovery

Why both?

A daily VM backup may provide an RPO approaching 24 hours.

SQL transaction-log backup may provide a much smaller RPO.

The same principle applies to:

• SAP HANA
• Oracle
• Other supported databases
• Domain controllers
• Clustered applications

---

25. Restore Testing

A backup is useful only if it can be restored.

A mature restore-testing process should validate:

• VM creation
• Boot success
• Disk integrity
• Application startup
• Database consistency
• Network connectivity
• DNS
• Identity
• Certificates
• Secrets
• Monitoring
• User access
• Performance

Recommended pattern:

Select production recovery point
       ↓
Restore into isolated network
       ↓
Run automated validation
       ↓
Record results
       ↓
Delete test environment

Do not discover during a real incident that:

• The VM does not boot.
• Required keys are missing.
• The restored VM cannot reach the database.
• DNS points to the wrong address.
• Application credentials have expired.

---

26. Monitoring and Alerts

Monitor:

• Backup job failures
• Backup warnings
• Missing recovery points
• Old last-successful backup
• Policy changes
• Vault redundancy changes
• Soft-delete changes
• Immutability changes
• Restore failures
• Agent or extension health
• Unprotected VMs

Use:

• Backup Center
• Azure Monitor
• Log Analytics
• Azure Alerts
• Azure Policy
• Microsoft Defender for Cloud

---

27. Cost Management

Azure VM Backup costs can include:

Protected-instance charge
        +
Backup storage
        +
Snapshot storage
        +
Long-term retention
        +
Cross-region replication
        +
Restore-related temporary resources

Cost optimization methods include:

• Exclude re-creatable data disks.
• Use appropriate retention.
• Avoid retaining excessive daily recovery points.
• Use weekly/monthly/yearly retention for long-term needs.
• Right-size Instant Restore snapshot retention.
• Delete protection for retired VMs after approved retention requirements are met.
• Use LRS, ZRS, or GRS according to actual recovery needs.
• Review orphaned backup items.
• Separate critical and noncritical backup policies.

The lowest-cost policy is not necessarily the best policy. It must still meet RPO, RTO, legal, and security requirements.

---

28. Recovery Scenario 1 — Accidental File Deletion

Requirement

A user deletes one configuration file.

Recommended recovery

Use file-level recovery.

Choose recovery point
      ↓
Mount backed-up volume
      ↓
Copy one file

Do not restore the complete VM unless required.

---

29. Recovery Scenario 2 — Failed OS Update

Requirement

A Windows update causes the VM to stop booting.

Possible recovery

1. Restore to a new VM and validate.
2. Restore OS disk.
3. Replace the existing VM disks if rollback is approved.
4. Use the restored disk for forensic investigation.

The safest first action is often to restore a separate VM or disk rather than immediately overwrite production.

---

30. Recovery Scenario 3 — VM Deleted

Requirement

The original VM resource no longer exists.

Recommended recovery

• Create a new VM from a recovery point, or
• Restore disks and recreate the VM.

The replace-existing option cannot be used because the original VM no longer exists.

---

31. Recovery Scenario 4 — Regional Failure

Requirement

The primary region is unavailable.

Recommended recovery

If configured and supported:

• Use Cross Region Restore.
• Create a VM or restore disks in the paired secondary region.
• Reconfigure networking, DNS, load balancing, identity, and application dependencies.

For strict recovery-time objectives, evaluate Azure Site Recovery because restoring a VM from backup may take longer than failing over a continuously replicated workload.

---

32. Recovery Scenario 5 — Ransomware

Requirement

VM disks have been encrypted maliciously.

Recommended response

• Isolate affected VMs.
• Preserve forensic evidence.
• Identify the last known clean recovery point.
• Restore into an isolated network.
• Scan and validate the restored VM.
• Rotate credentials.
• Reconnect only after security approval.

Recommended protection layers:

• Immutable vault
• Soft delete
• Restricted backup administration
• Defender for Servers
• Network isolation
• Multiple retained recovery points
• Regular restore testing

---

33. Corrections and Clarifications to the Transcript

“Application-consistent backup captures memory and system state”

This is inaccurate for normal Azure VM Backup.

Application-consistent backup coordinates with the operating system and supported applications to flush or quiesce data before disk snapshots. It does not generally preserve active RAM as a resumable VM-memory image.

---

“File-consistent” terminology

Microsoft documentation commonly uses:

• Application-consistent
• File-system-consistent
• Crash-consistent

“File-consistent” should usually be understood as file-system-consistent.

---

“Backups are stored in Recovery Services vaults”

Correct for Azure VM Backup, but the backup process also uses snapshot-tier recovery points for Instant Restore before or alongside vault-tier protection according to policy.

---

“Replace the existing VM by overwriting it”

The actual restore behavior is more specific:

• The VM resource must still exist.
• Azure restores disks and replaces the source VM’s disks.
• The operation is not supported for every configuration.
• Restore to a new VM or disks is safer for validation.

---

“Create a new VM in a different region”

Creating a VM in another region requires Cross Region Restore or another supported recovery process.

Standard same-region restore does not allow arbitrary recovery into any Azure region.

---

“Always use GRS for backup redundancy”

GRS is not automatically the correct choice.

Use it when:

• Regional backup resilience is required.
• Residency rules permit it.
• Cross Region Restore is needed.
• Cost is justified.

ZRS may be appropriate for zonal protection, while LRS may be acceptable for lower-criticality workloads.

---

34. Quick Decision Matrix

---

35. AZ-305 Exam Review

Remember these associations:

• Recovery Services vault → Azure VM Backup management and recovery points.
• Standard policy → Traditional daily VM backup.
• Enhanced policy → Multiple backups per day and newer protection capabilities.
• Instant Restore → Snapshot-tier recovery for faster restore.
• Application-consistent → Applications are quiesced or flushed before snapshot.
• File-system-consistent → File system is consistent, but applications may require recovery.
• Crash-consistent → Equivalent to disks after sudden power loss.
• Create new VM → Restore a separate VM from recovery point.
• Restore disks → Recover managed disks for custom reconstruction.
• Replace existing → Replace disks on an existing VM.
• File recovery → Restore individual files or folders.
• Cross Zone Restore → Recover supported VMs to another zone.
• Cross Region Restore → Recover in the Azure paired region when supported.
• Selective disk backup → Exclude unnecessary disks but may limit restore options.
• Immutable vault → Prevent destructive changes to recovery points.
• VM backup is not database point-in-time recovery.
• Backup is not high availability.
• Backup is not Site Recovery.
• Always test restores.

---

Microsoft Reference Documentation

• Azure VM Backup overview and consistency types.
• Prepare and configure Azure VM Backup.
• Azure VM Backup support matrix.
• Enhanced Azure VM Backup policy.
• Instant Restore capability.
• Azure VM restore overview.
• Restore Azure VMs through the portal.
• Recover files from an Azure VM backup.
• Selective disk backup and restore.
• Agentless multi-disk crash-consistent backup.
• Configure application-consistent Linux VM backup.
• Recovery Services vault configuration.
• Immutable vault protection.
• Backup and restore encrypted Azure VMs.

---

Azure hybrid backup recovery deep dive

Azure Hybrid Backup and Recovery — Review Notes and In-Depth Guide

1. Overview

Business continuity requires more than just backups.

A complete resiliency strategy consists of:

• Backup
• Disaster Recovery (DR)
• High Availability (HA)
• Business Continuity (BC)
• Monitoring
• Testing
• Security

Azure provides two primary services for protecting workloads:

1. Azure Backup
2. Azure Site Recovery (ASR)

Although they are often discussed together, they solve different problems.

Data Protection
        ↓
Azure Backup

Infrastructure Recovery
        ↓
Azure Site Recovery

AZ-305 Exam Tip: Azure Backup protects data. Azure Site Recovery protects applications and infrastructure.

Microsoft recommends using Backup and Site Recovery together because they address different business continuity requirements rather than replacing each other. (learn.microsoft.com)

---

2. Backup vs Disaster Recovery

This is one of the most common AZ-305 interview questions.

Azure Backup

Purpose:

Recover lost or corrupted data

Examples:

• User deletes a file
• Database corruption
• Ransomware
• Accidental overwrite
• Long-term retention
• Compliance

---

Azure Site Recovery

Purpose:

Recover entire workloads
after infrastructure failure

Examples:

• Datacenter failure
• Hypervisor failure
• Regional outage
• Server failure
• Planned migration
• Disaster recovery testing

---

Comparison

Remember: Backup ≠ Disaster Recovery.

---

3. Business Continuity Layers

A mature enterprise design typically includes multiple protection layers.

Application
      │
High Availability
      │
Azure Backup
      │
Azure Site Recovery
      │
Monitoring
      │
Security

Each layer protects against different failure scenarios.

---

4. Azure Backup

What is Azure Backup?

Azure Backup is Microsoft's managed backup service.

It protects:

• Azure VMs
• Azure Files
• Azure SQL workloads
• SAP HANA workloads
• On-premises servers
• VMware VMs
• Hyper-V VMs
• Azure Blobs (via Backup Vault for supported scenarios)
• Azure Database services (through service-specific backup features)

Azure Backup provides:

• Scheduled backups
• Recovery points
• Long-term retention
• Encryption
• Centralized management
• Soft delete
• Immutable vault support
• Cross-region restore for supported redundancy options

(learn.microsoft.com)

---

5. Recovery Services Vault vs Backup Vault

The transcript only discusses the Recovery Services vault, but Azure now has two vault types.

Recovery Services Vault

Traditionally protects:

• Azure VMs
• Azure Site Recovery
• Azure Backup Server
• MARS Agent
• SQL in Azure VMs
• SAP HANA in Azure VMs

---

Backup Vault

Designed for newer backup scenarios including:

• Azure Blob Backup
• Azure Disk Backup
• Operational backup for selected services
• Modern backup capabilities

(learn.microsoft.com)

AZ-305 Tip

Do not assume all backups use Recovery Services Vault.

---

6. Azure Backup Architecture

Example:

Azure VM
     │
Backup Extension
     │
Recovery Services Vault
     │
Recovery Points

For on-premises:

On-premises Server
        │
Backup Agent
        │
Internet / ExpressRoute / VPN
        │
Recovery Services Vault

---

7. Azure Backup Features

Azure Backup provides:

• Application-consistent backups
• Crash-consistent backups
• Scheduled backups
• Policy-based backup
• Recovery points
• Soft delete
• Immutable backup (supported scenarios)
• Cross-region restore
• Long-term retention
• Encryption
• Central monitoring

---

8. Backup Policies

Instead of configuring every VM individually,

create reusable backup policies.

Example:

Production Policy

Daily backup
Retention:
30 days

Weekly:
12 weeks

Monthly:
24 months

Yearly:
7 years

Policies simplify governance.

---

9. Backup Retention

Retention depends on business requirements.

Example:

Daily
30 days

Weekly
12 weeks

Monthly
24 months

Yearly
10 years

Typical drivers:

• Compliance
• Legal requirements
• Financial regulations
• Audit
• Business policy

---

10. Recovery Points

Each backup creates a recovery point.

Example:

Monday
Tuesday
Wednesday
Thursday
Friday

Restore to:

• Monday
• Wednesday
• Friday

depending on recovery needs.

---

11. Backup Types

Azure Backup supports:

Crash-consistent

Captures disk state.

Fast.

No application coordination.

---

Application-consistent

Coordinates with applications using technologies such as VSS on Windows to produce consistent backups.

Preferred for:

• SQL Server
• Exchange
• SAP HANA
• Other transactional workloads

Application-consistent recovery reduces the need for lengthy crash recovery when restoring supported applications.

---

12. Microsoft Azure Recovery Services (MARS) Agent

The transcript mentions the Recovery Services Agent.

Official name:

Microsoft Azure Recovery Services (MARS) Agent

The MARS agent backs up:

• Files
• Folders
• System state (supported scenarios)

It backs up directly to a Recovery Services Vault.

It does not back up:

• Entire VMware VMs
• Hyper-V VMs
• SQL Server databases
• Full physical servers at image level

(learn.microsoft.com)

---

13. Azure Backup Server (MABS)

The transcript mentions Microsoft Azure Backup Server.

Azure Backup Server (MABS) is based on System Center Data Protection Manager technology.

It protects:

• VMware
• Hyper-V
• SQL Server
• Exchange
• SharePoint
• Windows Servers
• File servers

Typical flow:

On-premises

VMs
SQL
Files

↓

Azure Backup Server

↓

Recovery Services Vault

MABS is useful when centralized on-premises backup management is required.

(learn.microsoft.com)

---

14. Data Protection Manager (DPM)

The transcript references Data Protection Manager.

Important clarification:

Modern deployments generally use:

• Azure Backup Server (MABS)
• System Center DPM (where already deployed)

DPM is a System Center product.

MABS is Microsoft's preferred Azure-integrated backup appliance for many supported hybrid backup scenarios.

New greenfield deployments should generally evaluate MABS unless System Center is already established.

---

15. Azure Site Recovery (ASR)

What is ASR?

Azure Site Recovery provides disaster recovery by replicating workloads to another location.

Supported scenarios include:

• Azure VM replication
• VMware replication
• Hyper-V replication
• Physical server replication

It supports:

• Planned failover
• Unplanned failover
• Test failover
• Failback

(learn.microsoft.com)

---

16. Site Recovery Architecture

Production Site

VM

↓

Continuous Replication

↓

Azure

Replica VM

During disaster:

Failover

↓

Replica VM starts

Business continues.

---

17. Replication

ASR continuously or periodically replicates workload changes depending on the protected platform and configuration.

Unlike backups:

Replication is intended for rapid recovery.

Production VM

↓

Replication

↓

Replica VM

Replication is not a substitute for backup.

If ransomware encrypts production,

replication can also replicate encrypted data.

---

18. Failover Types

Test Failover

Creates isolated environment.

No production impact.

Recommended regularly.

---

Planned Failover

Used during maintenance.

Controlled shutdown.

Minimal data loss.

---

Unplanned Failover

Disaster.

Primary site unavailable.

Recover quickly.

---

Failback

Return workload:

Azure

↓

Original site

after disaster ends.

---

19. Recovery Plans

Recovery Plans automate failover.

Example:

Start Database

↓

Start API

↓

Start Web Servers

↓

Run Script

↓

Notify Team

Supports:

• Automation
• Dependencies
• Scripts
• Azure Automation runbooks
• Manual approval steps

Recovery plans orchestrate failover—they do not replicate data themselves.

---

20. Azure Automation Integration

ASR integrates with Azure Automation.

Example:

Failover

↓

Automation Runbook

↓

Update DNS

↓

Notify Teams

↓

Run Validation

↓

Start Services

Useful for:

• DNS changes
• Firewall rules
• Validation
• Application startup
• Custom scripts

---

21. Backup + ASR Together

Microsoft recommends using both.

Example:

Azure Backup

↓

Protect Data

Azure Site Recovery

↓

Protect Infrastructure

Scenario:

User deletes SQL database

↓

Restore from Backup

---

Entire datacenter lost

↓

Fail over using ASR

---

22. Why Replication Isn't Backup

Suppose ransomware encrypts VM.

ASR:

Encrypted VM

↓

Replicated

↓

Encrypted Replica

Backup:

Recovery Point

↓

Restore Clean Copy

This is why both are needed.

---

23. RPO and RTO

Azure Backup

Typically:

Higher RPO

Longer RTO

because restore takes time.

---

Azure Site Recovery

Typically:

Lower RPO

Lower RTO

because VM already exists as replicated workload.

Business chooses acceptable RPO and RTO based on criticality.

---

24. Hybrid Architecture Example

On-premises

SQL

Files

VMs

↓

Azure Backup Server

↓

Recovery Services Vault

-------------------------

VM Replication

↓

Azure Site Recovery

↓

Azure Region

---

25. Monitoring

Monitor:

Azure Backup

• Failed backups
• Retention
• Vault health
• Storage

ASR

• Replication health
• Replication lag
• Failover readiness
• Recovery plans
• Mobility service health

Use:

• Azure Monitor
• Azure Backup Center
• Azure Site Recovery dashboards
• Log Analytics
• Azure Alerts

Backup Center provides a centralized experience for monitoring backup jobs, vaults, policies, and protected resources. (learn.microsoft.com)

---

26. Security

Protect backups using:

• Soft Delete
• Immutable vaults
• Multi-user authorization (supported scenarios)
• Azure RBAC
• Encryption
• Private endpoints where supported
• Backup vault monitoring
• MFA for privileged operations

Backup data should be protected from accidental and malicious deletion.

---

27. Cost Optimization

Azure Backup

Costs:

• Protected instances
• Backup storage
• Vault storage
• Restore operations (depending on scenario)

ASR

Costs:

• Protected instances
• Replication storage
• Network bandwidth
• Compute after failover
• Test failover resources

Use retention policies and replication only where required by business needs.

---

28. Scenario 1

Customer:

Accidentally deleted SQL database.

Recommended:

Azure Backup

Restore latest recovery point.

---

29. Scenario 2

Customer:

Primary datacenter flooded.

Need application within 30 minutes.

Recommended:

Azure Site Recovery

Fail over replicated VMs.

---

30. Scenario 3

Customer:

Bank requires 7-year retention.

Recommended:

Azure Backup

Long-term retention.

---

31. Scenario 4

Customer:

Manufacturing system.

Need:

• Fast recovery
• Database retention
• Compliance

Recommended:

Azure Backup

Azure Site Recovery

---

32. Corrections to Transcript

"Recovery Services Agent installed on everything"

Not exactly.

MARS protects supported workloads like files and folders.

Other workloads require:

• Azure Backup extension
• Azure Backup Server
• SQL backup integration
• SAP HANA backup integration
• Azure VM Backup

---

"Recovery Services Vault stores replication"

More accurately:

Recovery Services Vault manages:

• Backup metadata
• Recovery points
• Site Recovery configuration

Replication data uses managed storage behind the service depending on scenario.

---

"Azure Backup and ASR optimize costs"

True,

but only if:

• Proper retention selected
• Proper replication scope
• Regular DR testing
• Right workloads protected

Otherwise costs grow quickly.

---

33. Decision Matrix

---

34. AZ-305 Exam Review

Remember these associations:

• Azure Backup → Data protection and long-term retention.
• Azure Site Recovery (ASR) → Disaster recovery and workload replication.
• Recovery Services Vault → Traditional backup and Site Recovery management.
• Backup Vault → Modern backup scenarios (Blob, Disk, operational backups).
• MARS Agent → File and folder backup directly to Azure.
• Azure Backup Server (MABS) → Centralized on-premises backup server.
• DPM → System Center backup product.
• Recovery Point → Point-in-time backup.
• Application-consistent backup → Preferred for transactional applications.
• Crash-consistent backup → Disk-level consistency.
• Planned Failover → Controlled migration or maintenance.
• Unplanned Failover → Disaster scenario.
• Test Failover → Non-disruptive DR testing.
• Failback → Return workloads to the original site.
• Recovery Plan → Automated failover orchestration.
• Backup is not replication.
• Replication is not backup.
• Ransomware can replicate through ASR but cannot overwrite historical Azure Backup recovery points protected by appropriate retention and immutability controls.

---

Microsoft Reference Documentation

• Azure Backup overview. (learn.microsoft.com)
• Azure Backup Center. (learn.microsoft.com)
• Recovery Services Vault overview. (learn.microsoft.com)
• Backup Vault overview. (learn.microsoft.com)
• Microsoft Azure Recovery Services (MARS) Agent. (learn.microsoft.com)
• Azure Backup Server (MABS). (learn.microsoft.com)
• Azure Site Recovery overview. (learn.microsoft.com)
• Azure Site Recovery architecture and replication guidance. (learn.microsoft.com)
• Azure Site Recovery recovery plans. (learn.microsoft.com)
• Azure Well-Architected Framework – Reliability. (learn.microsoft.com)

Network architecture patterns#

Networking questions in AZ-305 are design questions: choose the correct connectivity path, topology, routing model, and security controls for the scenario.

---

Cloud network connectivity

Azure Cloud Network Connectivity – Study Notes (AZ-305 / Azure Architecture)

Overview

Cloud network connectivity in Azure is about securely connecting:

• On-premises data centers ↔ Azure
• Other cloud providers ↔ Azure
• Azure Virtual Networks (VNets) ↔ other VNets
• Azure services ↔ Azure services

The architect must choose the correct connectivity, routing, IP addressing, and topology based on security, latency, cost, scalability, and availability requirements.

---

1. Azure Connectivity Options

A. ExpressRoute (Private Dedicated Connection)

Definition

ExpressRoute is Microsoft's private, dedicated connection between your organization's network and Azure.

Unlike the Internet, traffic travels through a private network provided by a connectivity provider.

On-premises Datacenter
          │
          │
     ExpressRoute Circuit
          │
 Microsoft Edge Router
          │
      Azure Network

Characteristics

• Private connection (does NOT use public Internet)
• Low latency
• High bandwidth
• Predictable performance
• SLA-backed
• More secure than VPN
• Supports redundant circuits

Typical Speeds

• 50 Mbps
• 100 Mbps
• 500 Mbps
• 1 Gbps
• 10 Gbps
• Higher options available

Use Cases

• Enterprise production workloads
• Financial systems
• Healthcare
• Government
• Large database replication
• Disaster recovery
• SAP workloads

Advantages

✔ Lowest latency

✔ Highest reliability

✔ Predictable throughput

✔ No Internet exposure

Disadvantages

• Expensive
• Longer provisioning time
• Requires telecom/connectivity provider

---

B. Azure VPN Gateway

Azure VPN Gateway provides encrypted communication over the Internet.

On-premises
      │
 Internet (Encrypted IPSec Tunnel)
      │
Azure VPN Gateway
      │
 Azure VNet

Types

Site-to-Site VPN

Entire office connects to Azure.

Office Network
      │
 VPN Device
      │
 Internet
      │
VPN Gateway

Users don't manually connect.

Ideal for:

• Branch offices
• Small datacenters
• Hybrid cloud

---

Point-to-Site VPN

Individual users connect from laptops.

Laptop
   │
 VPN Client
   │
 Internet
   │
VPN Gateway

Ideal for:

• Remote workers
• Developers
• Administrators

---

VPN Gateway Features

• IPSec/IKE encryption
• Lower cost than ExpressRoute
• Quick deployment
• Internet dependent

---

When to choose VPN

Choose VPN when:

• Small company
• Development environment
• Budget is limited
• Remote employee access
• Temporary hybrid connection

---

C. VNet Peering

Virtual Network Peering connects two Azure VNets.

VNet A  <------------->  VNet B

Traffic stays inside Microsoft's backbone.

Benefits

• Very low latency
• High bandwidth
• Private communication
• No VPN required
• No public Internet

Types

Local VNet Peering

Same Azure region

East US

VNet1 ---- VNet2

---

Global VNet Peering

Different Azure regions

East US  <-------> West Europe

---

Supports

• Different subscriptions
• Different resource groups
• Different regions
• Same tenant (or supported cross-tenant scenarios)

---

Common Use Cases

Production VNet

↓

Shared Services VNet

↓

Development VNet

↓

Security VNet

---

2. Azure IP Addressing

Every Azure resource communicates using IP addresses.

Examples:

• Virtual Machines
• AKS clusters
• Azure SQL
• Storage Accounts
• App Services
• Functions
• Load Balancers

---

Layer 1 — Microsoft Internal Network

The transcript refers to the hidden networking layer between Microsoft-managed services.

Example:

Storage Account

↓

Private Microsoft Backbone

↓

Azure Backup

↓

Azure Monitor

You don't configure this networking.

Microsoft handles it.

Examples include:

• Managed identities
• Service-to-service communication
• Platform-managed networking

---

Layer 2 — Virtual Network (Private Networking)

This is the networking administrators manage.

Example

VNet

10.0.0.0/16

├── Subnet1
│      VM1
│      VM2
│
├── Subnet2
│      AKS
│
└── Subnet3
       SQL Managed Instance

Uses private IP addresses.

Examples

10.0.0.4

10.0.1.5

172.16.x.x

192.168.x.x

Private IPs are not accessible from the Internet.

---

Dynamic Private IP

Azure assigns automatically.

Good for:

• Most VMs
• Containers
• Temporary resources

---

Static Private IP

Administrator reserves address.

Used for:

• Domain Controllers
• Firewalls
• DNS Servers
• Load Balancers

---

Layer 3 — Public IP

Used when Internet communication is required.

Example

Internet

↓

Public IP

↓

Azure Firewall

↓

VM

Supports:

• Static
• Dynamic

---

Dynamic Public IP

May change after deallocation.

---

Static Public IP

Never changes.

Ideal for:

• DNS records
• APIs
• Public websites
• VPN Gateway
• Bastion
• Firewalls

---

Best Practice

Only assign public IPs when absolutely necessary.

Prefer:

• Private Endpoints
• Azure Bastion
• VPN
• ExpressRoute
• Application Gateway
• Azure Firewall

---

3. Azure Network Topologies

Topology defines how networks are organized.

---

A. Single VNet

VNet

├── Web VM
├── App VM
├── Database

Advantages

Simple

Cheap

Easy

Best For

Development

Testing

Small companies

Proof of Concept

---

B. Mesh (Multiple Peered VNets)

VNet A ---- VNet B

 |            |

 |            |

VNet C ---- VNet D

Every VNet connects with many others.

Advantages

Fast communication

Problems

Too many peerings

Hard to manage

Security becomes difficult.

Traffic monitoring becomes difficult.

Large organizations often avoid full mesh architectures because operational complexity grows rapidly.

---

C. Hub-and-Spoke (Recommended Enterprise Pattern)

Most common Azure enterprise architecture.

                 Hub VNet
             Firewall
             VPN Gateway
             ExpressRoute
             Bastion
             DNS
             Shared Services

        /        |        \

Spoke1     Spoke2      Spoke3

Production Dev Test

Every spoke only peers with the Hub.

---

Hub Contains

Azure Firewall

VPN Gateway

ExpressRoute Gateway

DNS

Monitoring

Security

Identity

Shared services

---

Spokes Contain

Applications

VMs

AKS

Databases

Business workloads

---

Advantages

Centralized security

Centralized routing

Simpler monitoring

Reduced peering complexity

Scalable architecture

Easy governance

Enterprise standard

---

Disadvantages

More planning required

Hub becomes critical infrastructure

---

4. Design Considerations

When designing Azure networking, evaluate:

• Connectivity (VPN, ExpressRoute, Peering)
• Security (Firewall, NSGs, Private Endpoints)
• Performance (latency, bandwidth)
• Cost
• Scalability
• Availability
• Traffic flow
• Monitoring
• Governance

---

5. Architecture Decision Guide

---

6. AZ-305 Exam Tips

Remember these common exam scenarios:

• ExpressRoute → Private, dedicated, high-performance hybrid connectivity.
• VPN Gateway → Encrypted Internet-based connectivity (Site-to-Site or Point-to-Site).
• VNet Peering → Connects Azure VNets over Microsoft's backbone with low latency.
• Private IPs → Internal communication within a VNet.
• Public IPs → Internet access; minimize their use.
• Hub-and-Spoke → Preferred enterprise architecture for centralized security, routing, and governance.
• Mesh Peering → Suitable only for small environments; becomes difficult to manage at scale.

---

Real-World Example

A global company hosts its ERP system in Azure while maintaining an on-premises datacenter.

• Headquarters connects to Azure using ExpressRoute for secure, low-latency access.

• Remote employees connect using Point-to-Site VPN.

• Branch offices use Site-to-Site VPN where ExpressRoute is not available.

• Azure workloads are organized in a Hub-and-Spoke topology:

  • Hub VNet: Azure Firewall, VPN Gateway, ExpressRoute Gateway, Azure Bastion, DNS, monitoring.
  • Production Spoke: Business applications and databases.
  • Development Spoke: Developer environments.
  • Testing Spoke: QA workloads.

• Application servers communicate over private IP addresses.

• Only the web application is exposed through an Application Gateway with a public IP; backend resources remain private.

This design provides strong security, centralized governance, simplified operations, and scalable connectivity.

---

Further Reading

Microsoft Learn

• Azure networking fundamentals
• Azure Virtual Network documentation
• Azure VPN Gateway documentation
• Azure ExpressRoute documentation
• Azure Virtual Network Peering documentation
• Azure Architecture Center – Hub-and-Spoke Network Topology
• Azure Landing Zones network topology and connectivity

Azure Architecture Center

• Cloud Adoption Framework (CAF)
• Enterprise-Scale Landing Zones
• Network security best practices
• Hybrid connectivity guidance
• Private Link and Private Endpoint architectures

Related Topics to Study Next

1. Azure Virtual Networks (VNets)
2. Subnets and IP Address Planning (CIDR)
3. Network Security Groups (NSGs)
4. Azure Firewall
5. Azure Load Balancer
6. Azure Application Gateway
7. Azure Front Door
8. Azure DNS
9. Azure Private Link and Private Endpoints
10. User-Defined Routes (UDRs) and Azure Route Server
11. Azure Bastion
12. Azure Virtual WAN
13. Azure Landing Zones
14. Network Watcher and Connection Monitor
15. Hybrid networking with ExpressRoute and VPN coexistence

These topics build directly on the connectivity concepts covered in this lesson and are frequently tested in Azure architecture certifications such as AZ-305.

---

Hybrid network connectivity

Azure Hybrid Network Connectivity – Complete Study Notes (AZ-305 / Azure Architect)

---

Overview

Hybrid network connectivity allows an organization to securely connect its on-premises infrastructure with Microsoft Azure.

Typical hybrid scenarios include:

• On-premises datacenters ↔ Azure
• Branch offices ↔ Azure
• Remote employees ↔ Azure
• Multiple datacenters ↔ Azure
• Multi-region enterprise connectivity

The two primary Azure hybrid connectivity services are:

1. Azure VPN Gateway
2. Azure ExpressRoute

Many enterprise environments use both together for redundancy, migration, and traffic optimization.

---

1. Azure Hybrid Connectivity Options

Option 1 – Azure VPN Gateway

Definition

Azure VPN Gateway provides encrypted connectivity over the public Internet using IPSec/IKE VPN tunnels.

On-Premises Network
        │
   IPSec VPN Tunnel
        │
     Internet
        │
 Azure VPN Gateway
        │
   Azure Virtual Network

Advantages

• Low cost
• Quick deployment
• Secure encryption
• No dedicated circuit required
• Ideal for smaller organizations

Limitations

• Uses the public Internet
• Higher latency than ExpressRoute
• Performance depends on Internet quality
• Limited throughput compared to ExpressRoute

---

When to Use VPN Gateway

Choose VPN Gateway for:

• Small to medium businesses
• Development environments
• Branch offices
• Remote worker connectivity
• Temporary hybrid deployments
• Budget-sensitive solutions

---

VPN Types

Site-to-Site (S2S)

Entire office connects to Azure.

Office LAN
    │
VPN Device
    │
Internet
    │
Azure VPN Gateway

Users connect automatically.

Typical use:

• Headquarters
• Branch offices
• Small datacenters

---

Point-to-Site (P2S)

Individual devices connect securely.

Laptop
   │
VPN Client
   │
Internet
   │
Azure VPN Gateway

Used by:

• Developers
• Administrators
• Remote employees
• Contractors

---

Option 2 – Azure ExpressRoute

Definition

ExpressRoute provides a private dedicated connection between your on-premises network and Azure.

Traffic never traverses the public Internet.

Datacenter
      │
Private MPLS / Provider
      │
ExpressRoute Circuit
      │
Microsoft Edge
      │
Azure

---

Advantages

• Lowest latency
• Predictable performance
• High bandwidth
• SLA-backed
• Highly secure
• Private connectivity
• Supports regulatory compliance

---

Typical Use Cases

• Financial services
• Healthcare
• Government
• SAP
• ERP
• Large database replication
• Backup and disaster recovery
• Mission-critical workloads

---

VPN vs ExpressRoute Comparison

---

2. Using VPN and ExpressRoute Together

Many organizations deploy both services simultaneously.

Why?

Backup / Failover

          ExpressRoute
Datacenter ------------ Azure
      \

       \

        VPN Backup

If ExpressRoute fails:

• VPN automatically provides connectivity (if configured appropriately).

---

Traffic Segregation

Example:

Benefits:

• Better security
• Lower costs
• Better bandwidth utilization

---

Migration

During migration:

Old connection:

Datacenter
      │
VPN
      │
Azure

Later:

Datacenter
   │
VPN
   │
Azure

+

ExpressRoute

Eventually:

Datacenter
      │
ExpressRoute
      │
Azure

Allows gradual migration with minimal downtime.

---

3. VPN Gateway SKUs

Azure VPN Gateway offers different performance tiers.

The SKU determines:

• Throughput
• Number of tunnels
• Availability
• Cost
• Scalability

---

Generation 1

• Basic
• VpnGw1
• VpnGw2
• VpnGw3
• VpnGw1AZ
• VpnGw2AZ
• VpnGw3AZ

---

Generation 2

• VpnGw2
• VpnGw3
• VpnGw4
• VpnGw5
• VpnGw2AZ
• VpnGw3AZ
• VpnGw4AZ
• VpnGw5AZ

Generation 2 generally offers higher performance and additional capabilities than Generation 1. For current throughput limits and supported features, always check the latest Microsoft documentation because they can change over time.

---

AZ SKUs

Example:

VpnGw2AZ

AZ means:

Availability Zone support

Benefits:

• Zone redundancy
• Better uptime
• Higher availability

Recommended for production environments.

---

4. Active-Active VPN Gateway

Normally:

Gateway A

Active-active:

Gateway A

Gateway B

Both gateways process traffic simultaneously.

Benefits:

• High availability
• Automatic failover
• Better throughput
• Improved resiliency

Recommended for enterprise production deployments.

---

5. Route-Based vs Policy-Based VPN

Route-Based VPN (Recommended)

Uses routing tables.

Sometimes called:

• Dynamic routing

Supports:

• Multiple tunnels
• VNet-to-VNet
• BGP
• ExpressRoute coexistence

Recommended for almost all modern Azure deployments.

---

Policy-Based VPN

Uses static rules.

Traffic is matched using predefined security policies.

Example:

10.1.0.0/16

↓

Allowed

↓

172.16.0.0/16

Advantages:

• Compatible with legacy VPN devices

Disadvantages:

• Less flexible
• Doesn't support many advanced Azure networking features

---

Quick Comparison

---

6. BGP (Border Gateway Protocol)

BGP allows Azure and on-premises routers to automatically exchange routing information.

Without BGP:

Administrator

↓

Manual Route Configuration

With BGP:

Azure Router

⇄

On-prem Router

Automatic route exchange

Benefits:

• Automatic failover
• Dynamic routing
• Reduced administration
• Large enterprise scalability

---

7. ExpressRoute Global Reach

Normally:

Datacenter A

↓

Azure

↓

Applications

With Global Reach:

Datacenter A

      │

Azure Backbone

      │

Datacenter B

Azure becomes the private backbone connecting your on-premises sites.

Benefits:

• Eliminates extra WAN circuits
• Simplifies networking
• Reduces operational complexity
• Can reduce networking costs depending on the environment

Common for multinational organizations.

---

8. ExpressRoute FastPath

Normally:

ExpressRoute

↓

Gateway

↓

Azure Resources

FastPath:

ExpressRoute

↓

Azure Resources

The data path bypasses parts of the gateway processing for supported traffic, reducing latency and improving throughput.

Benefits:

• Lower latency
• Higher throughput
• Better storage replication
• Better HPC performance

Typical workloads:

• SAP
• SQL replication
• High Performance Computing
• Large storage synchronization

Typically enabled only where the performance benefits justify the additional cost and design complexity.

---

9. Azure Virtual WAN

Definition

Azure Virtual WAN is a Microsoft-managed networking service that centralizes hybrid connectivity across Azure regions, branches, remote users, and VNets.

Instead of managing many individual VPNs and gateways, Virtual WAN provides a single managed architecture.

---

Traditional Hybrid Networking

Branch 1 → VPN

Branch 2 → VPN

Branch 3 → VPN

Azure

Many independent connections.

---

Virtual WAN

        Branch 1

             \

Branch 2 ---- Virtual WAN Hub ---- Azure VNets

             /

        Branch 3

Much easier to manage.

---

Virtual WAN Components

Virtual WAN

Top-level networking service.

---

Virtual Hub

Central routing point.

Contains:

• Routing
• Connectivity
• Security
• Traffic management

---

VPN Gateway

Supports branch connectivity.

---

ExpressRoute Gateway

Supports private connectivity.

---

Remote User VPN

Point-to-Site connectivity.

---

Firewall Integration

Supports:

• Azure Firewall
• Secure Hub
• Centralized inspection

---

Routing Intelligence

Automatically optimizes routing.

---

Benefits

• Centralized management
• Easier branch onboarding
• Global connectivity
• Automatic routing
• Reduced operational overhead
• Built-in resiliency
• Scales to thousands of sites

---

10. Partner Integration

Virtual WAN integrates with many certified Customer Premises Equipment (CPE) vendors, including:

• Cisco
• Palo Alto Networks
• Fortinet
• Juniper
• Check Point
• VMware SD-WAN
• Aruba
• Versa Networks

This simplifies deployment using existing enterprise networking hardware.

---

11. Monitoring and Diagnostics

Azure provides built-in tools to monitor hybrid connectivity:

• Azure Monitor
• Network Watcher
• Connection Monitor
• VPN Gateway metrics
• ExpressRoute metrics
• Log Analytics
• Azure Alerts

Key metrics include:

• Tunnel status
• Throughput
• Latency
• Packet loss
• BGP status
• Gateway CPU utilization

---

12. Real-World Enterprise Example

A global financial company is migrating to Azure.

Requirements

• Secure hybrid connectivity
• High bandwidth for trading systems
• Branch office connectivity
• Remote employee access
• Regulatory compliance
• High availability
• Future scalability

Recommended Architecture

Headquarters
      │
ExpressRoute
      │
Azure Hub

      │
Hub Firewall

      │
Hub VNet

 ├── Production

 ├── Development

 ├── Test

 └── Shared Services

Additional components:

• Branch offices → VPN via Virtual WAN
• Remote employees → Point-to-Site VPN
• Backup connectivity → VPN Gateway
• Inter-datacenter connectivity → ExpressRoute Global Reach
• Centralized security → Azure Firewall
• Dynamic routing → BGP
• High availability → Active-active VPN Gateway

This design combines performance, resilience, centralized management, and security.

---

AZ-305 Exam Tips

Remember these key design choices:

• VPN Gateway: Secure, encrypted Internet-based connectivity for hybrid environments.
• ExpressRoute: Private, dedicated connectivity with predictable performance for enterprise workloads.
• Use both VPN and ExpressRoute when you need backup connectivity, phased migration, or traffic segregation.
• Route-based VPN is the default recommendation for new Azure deployments; use policy-based VPN only for legacy compatibility.
• BGP automates route exchange and improves scalability.
• ExpressRoute Global Reach connects multiple on-premises sites through Microsoft's backbone.
• ExpressRoute FastPath improves throughput and lowers latency for supported high-performance workloads.
• Azure Virtual WAN centralizes hybrid networking for large, distributed organizations.

---

Decision Matrix

---

Microsoft Learn Reference Documentation

Hybrid Connectivity

• Azure VPN Gateway documentation
• Azure ExpressRoute documentation
• Azure Virtual WAN documentation
• ExpressRoute Global Reach documentation
• ExpressRoute FastPath documentation
• Azure VPN Gateway FAQ and SKUs
• Border Gateway Protocol (BGP) with Azure VPN Gateway

Azure Architecture Center

• Hybrid Network Architecture
• Hub-and-Spoke Network Topology
• Cloud Adoption Framework (CAF)
• Enterprise-Scale Landing Zones
• Azure Landing Zone Networking
• Azure Firewall Architecture Guide
• Azure Virtual WAN Design Guidance

---

Related Topics to Study Next

To build a complete Azure networking foundation, study these topics next in order:

1. Azure Virtual Networks (VNets)
2. IP Addressing and Subnet Design
3. Network Security Groups (NSGs)
4. User-Defined Routes (UDRs)
5. Azure Route Server
6. Azure Firewall
7. Azure Bastion
8. Azure Load Balancer
9. Azure Application Gateway
10. Azure Front Door
11. Azure Private Link and Private Endpoints
12. Azure DNS
13. Azure DDoS Protection
14. Network Watcher and Connection Monitor
15. Enterprise-Scale Landing Zone Networking

These topics complement hybrid connectivity concepts and are heavily emphasized in Azure Architect (AZ-305) solution design scenarios.

---

Network routing

Azure Network Routing – Complete Study Notes (AZ-305 / Azure Architect)

---

Overview

Network routing determines how network traffic travels between Azure resources, Virtual Networks (VNets), on-premises datacenters, and the Internet.

Azure automatically creates routes, but architects often customize routing to:

• Improve security
• Control traffic flow
• Centralize inspection
• Connect hybrid environments
• Optimize performance
• Reduce operational complexity

AZ-305 Design Principle: Routing is not just about reaching a destination—it is about ensuring traffic takes the correct path for security, compliance, and performance.

---

1. Why Modify Routing?

By default, Azure automatically routes traffic within a VNet and to connected networks. However, default routing may not satisfy enterprise requirements.

Common reasons to customize routing:

1. Custom Network Topologies

Examples:

• Hub-and-Spoke
• DMZ architecture
• Multi-tier applications
• Shared services networks

---

2. Traffic Isolation

Keep different workloads separated.

Example:

Web Tier
     │
     ▼
Application Tier
     │
     ▼
Database Tier

You may want all traffic between tiers to pass through a firewall or inspection device.

---

3. Forced Tunneling

Force Internet-bound traffic to pass through your on-premises network or a centralized Azure firewall instead of going directly to the Internet.

VM
 │
 ▼
VPN / ExpressRoute
 │
 ▼
On-prem Firewall
 │
 ▼
Internet

Benefits:

• Centralized logging
• Corporate security policies
• Regulatory compliance
• Malware inspection

---

4. Security

Send traffic through:

• Azure Firewall
• Third-party firewalls
• IDS/IPS appliances
• Proxy servers

instead of allowing direct communication.

---

5. Performance Optimization

Different traffic can take different routes.

Example:

• Storage replication → ExpressRoute
• User browsing → Internet
• Internal APIs → Private VNet

---

2. Azure Routing Types

Azure supports three primary routing mechanisms.

---

A. System Routes (Default Routes)

Definition

System routes are automatically created and managed by Azure.

You normally do not configure them.

Azure understands:

• VNet address space
• Subnets
• Peered VNets
• VPN Gateways
• ExpressRoute

Example:

VNet

10.0.0.0/16

├──Subnet A

├──Subnet B

└──Subnet C

Azure automatically knows:

10.0.1.x → Subnet A

10.0.2.x → Subnet B

10.0.3.x → Subnet C

No administrator configuration required.

---

Typical System Routes

Azure automatically creates routes for:

• Local VNet traffic
• Internet
• Virtual network peering
• VPN Gateway
• ExpressRoute
• Virtual appliances (when configured)

---

Advantages

• Automatic
• Reliable
• No maintenance
• Good for most workloads

---

B. User-Defined Routes (UDRs)

Definition

User-Defined Routes (UDRs), also called custom routes, override or supplement Azure's system routes.

You create a Route Table and associate it with one or more subnets.

Subnet

↓

Route Table

↓

Custom Routes

---

Why Use UDRs?

UDRs let you control where traffic goes next (the next hop).

Common scenarios:

• Send traffic to Azure Firewall
• Send traffic to a virtual appliance (NVA)
• Force traffic through VPN
• Force traffic through ExpressRoute
• Redirect traffic between VNets

---

Next Hop Options

When creating a UDR, you specify a Next Hop.

Common next hops:

Virtual Appliance

VM

↓

Firewall VM

↓

Internet

Used with:

• Palo Alto
• Fortinet
• Cisco
• Check Point

---

VPN Gateway

Azure

↓

VPN Gateway

↓

On-premises

---

ExpressRoute Gateway

Traffic leaves Azure through ExpressRoute.

---

Internet

Traffic exits directly to the Internet.

---

None

Traffic is dropped (black-holed).

Useful for blocking unwanted traffic.

---

Example

Without UDR:

VM

↓

Internet

With UDR:

VM

↓

Azure Firewall

↓

Internet

Much more secure.

---

C. Border Gateway Protocol (BGP)

Definition

BGP is a dynamic routing protocol used between Azure and external networks.

Instead of manually configuring every route, routers automatically exchange routing information.

---

Without BGP

Administrator manually creates routes.

10.10.0.0/16

↓

VPN

Every new subnet requires updates.

---

With BGP

Azure Router

⇄

On-prem Router

Routes update automatically.

---

Benefits

• Automatic route learning
• Dynamic failover
• Less administration
• Enterprise scalability
• Better hybrid networking

---

Common Uses

• VPN Gateway
• ExpressRoute
• Large enterprises
• Multi-region deployments
• Multi-cloud networking

---

3. Outbound Internet Connectivity

Azure resources often require outbound Internet access.

Examples:

• Windows Update
• Linux package updates
• Downloading software
• API calls
• Azure DevOps agents
• Docker image downloads

Azure provides several options.

---

A. Azure Load Balancer (Outbound Rules)

Load Balancer can provide outbound SNAT for backend resources.

VM1

VM2

↓

Azure Load Balancer

↓

Internet

Use when you already have a Standard Load Balancer and need outbound connectivity for backend instances.

---

B. Azure NAT Gateway (Recommended for Outbound)

Definition

Azure NAT Gateway enables outbound Internet connectivity without assigning public IPs directly to VMs.

VM

↓

Private IP

↓

NAT Gateway

↓

Public IP

↓

Internet

---

Benefits

• VMs remain private
• Scalable outbound SNAT
• Static public IP(s)
• Simple management
• High availability
• Better than individual VM public IPs

---

Best Use Cases

• Private application servers
• AKS worker nodes
• Backend services
• VM Scale Sets

Exam Tip: NAT Gateway is the preferred Azure-native solution when VMs need outbound-only Internet access.

---

C. Azure Firewall

Azure Firewall provides centralized security and routing.

VM

↓

Azure Firewall

↓

Internet

Capabilities include:

• Application rules (FQDN filtering)
• Network rules (IP/Port)
• Threat intelligence
• DNAT/SNAT
• Logging
• TLS inspection (Premium SKU)
• IDPS (Premium SKU)

---

Best For

• Enterprise environments
• Centralized egress
• Compliance
• Security inspection

---

D. Network Virtual Appliances (NVAs)

NVAs are third-party virtual appliances running as Azure VMs.

Examples:

• Palo Alto
• Fortinet
• Cisco
• Check Point
• Sophos

---

Why Use NVAs?

Organizations often already use these products on-premises and want consistent security policies across hybrid environments.

Typical capabilities:

• Firewall
• IDS/IPS
• Secure Web Gateway
• VPN concentrator
• Proxy
• URL filtering

---

4. Hub-and-Spoke with Routing

Most enterprise Azure environments use a Hub-and-Spoke architecture.

                Hub VNet
          ┌─────────────────────┐
          │ Azure Firewall      │
          │ VPN Gateway         │
          │ ExpressRoute GW     │
          │ Shared Services     │
          └─────────┬───────────┘
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
 Production     Development      Test
   Spoke           Spoke         Spoke

Routing is centralized in the Hub.

Benefits:

• Easier monitoring
• Centralized security
• Lower operational complexity
• Better governance

---

5. Real-World Example

A media company migrates a three-tier application to Azure.

Requirements

• Separate Web, App, and Database tiers
• Inspect all outbound Internet traffic
• Connect securely to on-premises
• Enable automatic routing

Solution

• Hub-and-Spoke architecture
• UDRs to send all outbound traffic to Azure Firewall
• Azure NAT Gateway for subnets requiring outbound-only Internet access
• BGP between Azure VPN/ExpressRoute Gateway and on-premises routers
• System routes retained for local VNet communication

Result:

• Secure east-west traffic
• Controlled Internet egress
• Dynamic hybrid routing
• Centralized management

---

Decision Matrix

---

AZ-305 Exam Tips

Remember these common scenarios:

• System Routes → Automatically managed by Azure.
• User-Defined Routes (UDRs) → Override or supplement default routing to control traffic flow.
• BGP → Dynamic route exchange for VPN Gateway and ExpressRoute.
• NAT Gateway → Preferred solution for outbound Internet access without exposing VMs to inbound traffic.
• Azure Firewall → Centralized inspection, filtering, and policy enforcement for outbound and east-west traffic.
• Network Virtual Appliances (NVAs) → Third-party security appliances used when specific vendor capabilities or existing investments are required.
• Hub-and-Spoke → Enterprise pattern that centralizes routing, connectivity, and security.

---

Microsoft Learn Reference Documentation

Routing and Connectivity

• Azure Virtual Network routing overview
• User-Defined Routes (Route Tables)
• Azure Route Server
• Border Gateway Protocol (BGP) with VPN Gateway
• Azure ExpressRoute routing
• Azure VPN Gateway routing

Outbound Connectivity

• Azure NAT Gateway documentation
• Azure Load Balancer outbound rules
• Azure Firewall documentation
• Azure Firewall Premium features
• Virtual Network NAT design guidance

Architecture Center

• Hub-and-Spoke network topology
• Enterprise-scale Landing Zones
• Cloud Adoption Framework (CAF)
• Azure networking best practices
• Network security architecture

---

Related Topics to Study Next

To master Azure networking and AZ-305, continue with:

1. Azure Virtual Networks (VNets)
2. CIDR and IP Address Planning
3. Subnets and Service Endpoints
4. Network Security Groups (NSGs)
5. Azure Route Server
6. Azure Load Balancer
7. Azure Application Gateway
8. Azure Front Door
9. Azure Firewall
10. Azure NAT Gateway
11. Azure Bastion
12. Azure DDoS Protection
13. Azure Private Link & Private Endpoints
14. Network Watcher & Connection Monitor
15. Azure Virtual WAN

Studying these topics together will give you a comprehensive understanding of Azure network design, routing, and hybrid connectivity—key areas for the AZ-305 Azure Solutions Architect Expert exam.

---

Securing external network traffic

Azure Securing External Network Traffic – Complete Study Notes (AZ-305 / Azure Solutions Architect)

---

Overview

When Azure resources are accessible from the Internet (users, APIs, websites, mobile apps, partners), they become potential attack targets.

Azure follows a Defense-in-Depth strategy—using multiple layers of security rather than relying on a single firewall or access control.

AZ-305 Design Principle: Never rely on one security control. Combine network, identity, application, and monitoring controls to minimize the attack surface and improve resilience.

---

1. Defense-in-Depth (Core Security Concept)

Definition

Defense-in-Depth means applying multiple independent security layers so that if one control fails, others continue protecting the workload.

Instead of:

Internet
   │
Firewall
   │
Application

Azure recommends:

Internet
   │
Azure DDoS Protection
   │
Azure Front Door / Application Gateway (WAF)
   │
Azure Firewall
   │
Network Security Groups (NSGs)
   │
Application Security Groups (ASGs)
   │
Identity (Microsoft Entra ID)
   │
Application Authentication
   │
Monitoring (Microsoft Defender for Cloud / Azure Monitor)

Each layer provides additional protection.

---

Defense-in-Depth Layers

1. Physical Security

Microsoft secures Azure datacenters through:

• Biometric access
• 24/7 surveillance
• Security personnel
• Hardware protection

---

2. Identity & Access

Control who can access resources.

Examples:

• Microsoft Entra ID
• Multi-Factor Authentication (MFA)
• Conditional Access
• Role-Based Access Control (RBAC)
• Managed Identities

---

3. Perimeter Security

Protect Internet-facing workloads.

Typical services:

• Azure Firewall
• Azure DDoS Protection
• Azure Front Door
• Application Gateway (WAF)

---

4. Network Security

Control traffic within Azure.

Services:

• Network Security Groups (NSGs)
• Application Security Groups (ASGs)
• User-Defined Routes (UDRs)
• Azure Firewall
• Private Endpoints

---

5. Compute Security

Protect VMs and containers.

Examples:

• Microsoft Defender for Servers
• Disk Encryption
• Trusted Launch
• Endpoint protection

---

6. Application Security

Protect applications.

Examples:

• Microsoft Entra authentication
• Managed Identity
• Azure Key Vault
• Secure coding
• Web Application Firewall (WAF)

---

7. Data Security

Protect stored information.

Examples:

• Encryption at rest
• Encryption in transit (TLS)
• Azure Key Vault
• Microsoft Purview
• Azure Information Protection

---

Benefits

• Reduced attack surface
• Multiple security layers
• Better breach containment
• Improved compliance
• Faster incident response

---

2. Traffic Filtering and Routing

Traffic filtering controls:

• Who can connect
• What ports are allowed
• Which protocols are permitted
• Where traffic is routed

Azure primarily uses:

• Network Security Groups (NSGs)
• User-Defined Routes (UDRs)
• Application Security Groups (ASGs)

---

A. Network Security Groups (NSGs)

Definition

NSGs act as stateful Layer 3/Layer 4 firewalls that control inbound and outbound traffic.

They filter traffic based on:

• Source IP
• Destination IP
• Port
• Protocol (TCP/UDP/ICMP)
• Direction

---

Example

Allow HTTPS only:

Internet

↓

Port 443

↓

Web VM

Block everything else.

---

NSG Characteristics

Stateful firewall

Supports:

• Allow rules
• Deny rules
• Priority values
• Inbound rules
• Outbound rules

---

NSG Rule Evaluation

Rules are processed from the lowest priority number to the highest.

Example:

First matching rule is applied.

---

Typical Uses

• Allow RDP only from administrators
• Allow SQL only from application subnet
• Block Internet access
• Restrict management ports

---

B. User-Defined Routes (UDRs)

UDRs determine where traffic goes.

Instead of:

VM

↓

Internet

Route through firewall:

VM

↓

Azure Firewall

↓

Internet

Common scenarios:

• Forced tunneling
• Centralized inspection
• Hub-and-Spoke routing
• Traffic redirection to NVAs

---

C. Application Security Groups (ASGs)

Definition

ASGs group VMs logically instead of using IP addresses.

Example:

Web Servers

App Servers

Database Servers

Instead of creating NSG rules using individual IP addresses, use ASGs.

---

Example

Allow:

Web ASG

↓

App ASG

Allow:

App ASG

↓

Database ASG

Benefits:

• Easier rule management
• Better scalability
• Less administrative overhead
• Follows the Principle of Least Privilege

---

Principle of Least Privilege

Only allow the minimum communication required.

Example:

Web

↓

App

↓

Database

Do not allow:

Internet

↓

Database

or

Web

↓

Database

unless explicitly required.

---

3. Azure Firewall

Definition

Azure Firewall is Microsoft's fully managed, cloud-native stateful firewall.

Unlike NSGs, Azure Firewall provides centralized inspection and policy enforcement across multiple VNets.

---

Capabilities

Network Rules

Filter:

• IP
• Port
• Protocol

---

Application Rules

Filter based on:

• FQDNs
• URLs
• Web categories (Premium SKU)

Example:

Allow:

*.microsoft.com

Block:

socialmedia.com

---

DNAT

Publish internal resources securely.

---

SNAT

Enable outbound Internet access while hiding private IP addresses.

---

Threat Intelligence

Microsoft threat feeds can:

• Alert
• Deny known malicious IPs and domains

---

Intrusion Detection & Prevention (Premium)

Detects:

• Exploits
• Malware
• Known attack signatures

---

TLS Inspection (Premium)

Decrypts, inspects, and re-encrypts outbound HTTPS traffic for deeper security analysis.

---

Benefits

• Fully managed
• High availability
• Automatic scaling
• Central logging
• Native Azure integration
• Suitable for Hub-and-Spoke architectures

---

Azure Firewall vs NSGs

Best Practice: Use NSGs for subnet/VM protection and Azure Firewall for centralized perimeter and egress control.

---

4. Azure Firewall vs Network Virtual Appliances (NVAs)

Azure Firewall

Advantages:

• Fully managed
• Automatic updates
• Native Azure integration
• Easier operations
• Built-in high availability

---

NVAs

Examples:

• Palo Alto
• Fortinet
• Cisco
• Check Point
• Sophos

Advantages:

• Advanced vendor-specific features
• Existing enterprise policies
• Specialized compliance requirements

Disadvantages:

• Customer-managed
• Manual patching
• Higher operational overhead

---

Decision Guide

Choose Azure Firewall when:

• You want a managed Azure-native solution.
• You need centralized logging and policy management.

Choose an NVA when:

• Your organization has standardized on a specific security vendor.
• You require advanced capabilities not available in Azure Firewall.

Many enterprises deploy Azure Firewall + NVA together during migrations or to meet specialized security requirements.

---

5. Data Residency

Definition

Data residency means storing and processing data within a specific geographic region to comply with legal or regulatory requirements.

Examples:

• GDPR (European Union)
• Financial regulations
• Healthcare regulations
• Government data sovereignty rules

---

Azure Regions

Choose regions carefully:

Examples:

• Sweden Central
• West Europe
• North Europe
• UK South

---

Azure Policy

Azure Policy can enforce:

• Allowed regions
• Resource location restrictions
• Naming conventions
• Compliance rules

Example:

Allow deployments only in:

• Sweden Central
• North Europe

Reject all other regions automatically.

---

6. Securing Public Endpoints

The transcript mentions "Service Firewall." In Azure terminology, this generally refers to service-level firewall capabilities available on many Azure PaaS services (for example, Azure Storage, Azure SQL Database, Azure Key Vault, Azure Cosmos DB), rather than a single Azure service called "Service Firewall."

Many Azure services allow you to restrict access using:

• Allowed public IP addresses
• Virtual Network rules
• Private Endpoints
• Trusted Microsoft services
• Service-specific firewall rules

---

Example – Azure Storage Firewall

Allow access only from:

Corporate Office IP

+

Azure VNet

Block all other traffic.

---

Best Practices

• Prefer Private Endpoints over public access whenever possible.
• If public access is required, restrict it to trusted IP ranges.
• Enable logging and monitoring for public endpoints.
• Regularly review firewall rules.

---

7. Monitoring and Threat Detection

Security controls should be combined with monitoring.

Recommended Azure services:

• Microsoft Defender for Cloud
• Azure Monitor
• Log Analytics
• Microsoft Sentinel (SIEM/SOAR)
• Network Watcher
• Azure Activity Log

Monitor:

• Failed connections
• Port scans
• Firewall rule hits
• Threat intelligence alerts
• Unexpected traffic patterns

---

8. Real-World Example

A global financial company is migrating customer-facing applications to Azure.

Requirements

• Protect Internet-facing applications
• Meet financial compliance requirements
• Restrict communication between application tiers
• Centralize outbound traffic inspection
• Ensure customer data remains within the EU

Recommended Architecture

Internet
     │
Azure DDoS Protection
     │
Application Gateway (WAF)
     │
Azure Firewall
     │
Hub VNet
     │
 ├── Web Subnet (NSG + ASG)
 ├── App Subnet (NSG + ASG)
 └── Database Subnet (NSG + ASG)

Additional controls:

• UDRs route outbound traffic through Azure Firewall.
• Azure Policy restricts deployments to EU regions.
• Private Endpoints are used for Storage and SQL.
• Microsoft Defender for Cloud monitors threats.
• Microsoft Sentinel aggregates logs for security operations.

This design minimizes the attack surface, centralizes inspection, and satisfies compliance requirements.

---

Decision Matrix

---

AZ-305 Exam Tips

• Defense-in-Depth means multiple independent security layers, not a single firewall.
• NSGs secure subnets and network interfaces with Layer 3/Layer 4 rules.
• ASGs simplify NSG management by grouping workloads instead of using IP addresses.
• UDRs redirect traffic through Azure Firewall or NVAs.
• Azure Firewall provides centralized, managed network security with application and network rules.
• Azure Firewall Premium adds TLS inspection and Intrusion Detection & Prevention (IDPS).
• Azure Policy enforces governance such as allowed Azure regions.
• Prefer Private Endpoints over public endpoints for PaaS services.
• When public endpoints are necessary, use service-level firewall rules, least privilege, and monitoring.

---

Microsoft Learn Reference Documentation

Network Security

• Azure Firewall documentation
• Azure Firewall Premium features
• Network Security Groups (NSGs)
• Application Security Groups (ASGs)
• User-Defined Routes (UDRs)
• Azure DDoS Protection
• Azure Virtual Network security overview

Governance

• Azure Policy documentation
• Azure Landing Zones governance
• Cloud Adoption Framework (CAF)

Private Connectivity

• Azure Private Link
• Private Endpoints
• Azure Storage firewall and virtual network rules
• Azure SQL Database firewall rules
• Azure Key Vault networking

Security Operations

• Microsoft Defender for Cloud
• Microsoft Sentinel
• Azure Monitor
• Network Watcher

Architecture Center

• Hub-and-Spoke Network Topology
• Enterprise-Scale Landing Zones
• Zero Trust Architecture
• Azure Security Benchmark

---

Related Topics to Study Next

To complete your Azure networking and security knowledge, study these topics next:

1. Azure DDoS Protection
2. Azure Application Gateway & Web Application Firewall (WAF)
3. Azure Front Door
4. Azure Private Link & Private Endpoints
5. Service Endpoints vs Private Endpoints
6. Azure Firewall Manager
7. Network Security Groups (advanced scenarios)
8. Azure Bastion
9. Microsoft Defender for Cloud
10. Microsoft Sentinel
11. Azure Policy & Azure Blueprints (governance)
12. Zero Trust Architecture
13. Azure Landing Zones (network and security)
14. Network Watcher & Connection Monitor
15. Azure Security Benchmark (ASB)

Mastering these topics will prepare you for enterprise Azure network security design and the networking and security scenarios commonly tested in the AZ-305 Azure Solutions Architect Expert certification.

Migration architecture#

• Azure Migrate — assessment and migration support for servers, databases, web apps, and containers.
• Database Migration Service — minimal downtime migration for SQL Server and open-source databases.
• Rehost — fastest path, minimal changes.
• Refactor — move to managed platform services while keeping core code.
• Rearchitect — redesign for cloud-native operation and scalability.

Reference docs:

• https://learn.microsoft.com/azure/migrate/overview
• https://learn.microsoft.com/azure/dms/dms-overview

Well-Architected Framework review#

Every AZ-305 design should reference the five pillars:

---

Study Plan (10–12 Weeks)#

---

Key Resources#