Originally sourced from msdynamicsworld.com, April 20 2020. Expanded and rewritten for technical accuracy.
Making Sense of Azure IoT
Azure’s IoT portfolio has grown significantly over the years, giving architects and administrators a broad set of services to build end-to-end IoT solutions. As explored by Chris Pietschmann on Build5Nines, understanding how these services relate to one another is the first step to designing a solid IoT architecture.
Key Azure IoT Services
- Azure IoT Central – A managed application platform for building and deploying IoT solutions without deep cloud expertise.
- Azure IoT Hub – A scalable, bidirectional messaging broker that connects IoT devices to backend services.
- IoT Device Provisioning Service (DPS) – Enables zero-touch, just-in-time provisioning of devices to IoT Hub.
- Azure Maps – Geospatial services for location-aware IoT applications.
- Azure Time Series Insights – A managed service for storing, visualizing, and querying time-series data from IoT devices.
- Azure IoT Edge – Moves cloud intelligence (AI, analytics, business logic) closer to the device, reducing latency and bandwidth usage.
- Azure Sphere – A secured, high-level microcontroller platform for connected devices.
- Azure Digital Twins – Creates graph-based models of physical environments, enabling richer analytics and simulation.
The Lambda Architecture Pattern for IoT
A recurring design pattern in large-scale IoT systems is the Lambda Architecture. This pattern addresses the challenge of processing high-velocity data streams from thousands or millions of devices while still supporting historical batch analysis.
Lambda Architecture has three layers:
- Batch layer – Processes and reprocesses the full historical dataset at scheduled intervals, producing accurate but latency-tolerant results.
- Speed (stream) layer – Processes incoming data in near real-time, compensating for the latency of the batch layer.
- Serving layer – Merges batch and real-time views, making results available for queries.
On Azure, this pattern is commonly implemented using IoT Hub for ingestion, Azure Stream Analytics or Azure Databricks for real-time processing, Azure Data Lake Storage for the batch layer, and Azure Synapse Analytics or Cosmos DB for the serving layer.
Planning Web App Security on Azure
Karim Vaes posed a common architectural question: “What do I put in front of my web application to secure it?” Azure offers several overlapping services, and choosing correctly requires understanding their distinct roles.
Application Gateway vs. Azure Front Door
Both Application Gateway and Azure Front Door can be configured as a Web Application Firewall (WAF), but they differ in important ways:
| Feature | Application Gateway | Azure Front Door |
|---|---|---|
| WAF support | Yes | Yes |
| Detection-only mode | Yes | Yes |
| VNet injection | Yes (regional) | No (public endpoint only) |
| Global distribution | No (regional) | Yes (global PoPs) |
| Acts as reverse proxy | Yes (regional) | Yes (global) |
Front Door vs. Traffic Manager
Both services support multi-region deployments, but through different mechanisms:
- Azure Traffic Manager is DNS-based. It redirects clients to the appropriate regional endpoint at DNS resolution time. It does not proxy traffic, so it cannot cache or inspect HTTP payloads.
- Azure Front Door is a reverse proxy operating at Layer 7 (HTTP/HTTPS). Because it terminates connections, it can cache content, perform SSL offloading, and inspect or rewrite requests.
Caching: Front Door vs. Azure CDN
Both Azure Front Door and Azure CDN provide edge caching, but their primary use cases differ:
- Azure Front Door caches content to accelerate web application delivery. It is optimized for dynamic and semi-static web workloads.
- Azure CDN is purpose-built for distributing large static files globally from edge points of presence (PoPs), making it the better fit for high-throughput media or file distribution scenarios.
All of the services discussed — Application Gateway, Front Door, Traffic Manager, and Azure CDN — include some form of DDoS attack mitigation, either natively or through integration with Azure DDoS Protection.
Creating an Azure Storage Account with PowerShell
Chris Pietschmann on Build5Nines walked through using the Azure PowerShell Az module to create Storage Accounts and Storage Containers programmatically. Storage Accounts underpin a wide range of Azure services — virtual machine disks, diagnostic logs, Blob storage, and more.
Storage Account Naming Rules
Storage Account names must follow stricter conventions than most Azure resources:
- Between 3 and 24 characters in length.
- Lowercase letters and numbers only — no hyphens, underscores, or special characters.
- Must be globally unique across all Azure customers.
Creating a Storage Account
# Install the Az.Storage module if not already present
Install-Module -Name Az.Storage -Scope CurrentUser
# Log in to Azure
Connect-AzAccount
# Create a new Storage Account
New-AzStorageAccount `
-ResourceGroupName "myResourceGroup" `
-Name "mystorageaccount" `
-Location "eastus" `
-SkuName "Standard_LRS" `
-Kind "StorageV2"Code language: PHP (php)Creating a Storage Container
Before creating a container, you must retrieve a Storage Account context. This context tells subsequent cmdlets which account to target.
# Retrieve the Storage Account context
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName "myResourceGroup" `
-Name "mystorageaccount"
$ctx = $storageAccount.Context
# Create a new Blob container
New-AzStorageContainer `
-Name "mycontainer" `
-Context $ctx `
-Permission OffCode language: PHP (php)The -Permission parameter controls public access: Off means no public access, Blob allows public read access to blobs only, and Container allows public read access to the container and its blobs.
Pietschmann also covered Storage Account pricing tiers (Hot, Cool, and Archive access tiers for Blob storage) and the importance of the Az.Storage PowerShell module, which is part of the broader Az module suite.
Preparing for the Azure Architect Design Exam
Microsoft Senior Cloud Advocate Thomas Maurer shared preparation advice for the Azure Architect Technologies and Azure Architect Design certification exams.
Recommended Study Resources
- Microsoft Learn – Free, structured learning paths aligned to exam objectives. A recommended starting point for anyone new to Azure certifications.
- Microsoft Docs – The official technical documentation. Exam questions are frequently grounded in documented service behaviors and best practices, making Docs essential reading.
Key Exam Topic Areas
Both the Architect Technologies and Architect Design exams cover a broad set of domains. Based on the advice shared by Maurer, major topic areas include:
- Monitoring and observability – Logging strategies, Azure Monitor, Application Insights, and cost optimization.
- Identity and security – Azure Active Directory, role-based access control (RBAC), managed identities, and Key Vault.
- Data storage – Choosing between SQL, NoSQL, Blob, and other storage services based on workload requirements.
- Business continuity and disaster recovery – Backup strategies, geo-redundancy, availability zones, and SLA targets.
- Infrastructure and networking – Virtual networks, hybrid connectivity, load balancing, and compute options.
Candidates are advised to work through scenario-based questions and understand not just what each service does, but when to choose it over alternatives — a key skill tested in the Architect Design exam in particular.