tl;dr If you’re interested in the project itself and do not want to waste your time reading this post 😅, here is the GitHub repo and here is the Proximity project live.

For me, open source is not a side activity, it’s a deliberate part of how I practice coding and architecture.

In the enterprise environments I usually work in as a Chief Cloud & AI Architect, architecture is often constrained by existing platforms, organizational inertia, legacy decisions, political trade-offs.

Those constraints are real — but they also limit experimentation.

An open source side project gives me a different space, a place with no hidden assumptions, no artificial deadlines, no “we’ll fix it later in production” — every decision can stand on its own.

The Proximity project started exactly this way: inspired by a post I found on reddit, it is an open source tool that visualizes walking-distance isochrones from public transport stops (trains, metro, trolleys, buses) across multiple metropolitan areas and a controlled environment that allows me to apply patterns and learn to use frameworks that would otherwise remain somewhat sterile without a clear purpose.

The objective of this post is to show why I treat Proximity as more than a toy project: it is a sandbox for practicing real cloud architecture, experimenting with new frameworks, and stress-testing patterns like serverless, IaC, and AI-assisted development in a space where I can make deliberate, opinionated decisions end to end.

The project

When talking about public transport accessibility, we often rely on simplified assumptions.

• Stops are either “served” or “not served”.
• Areas are either “covered” or “uncovered”.

In practice, accessibility is rarely binary.

What really affects usability is not the presence of a stop, but how far people can realistically walk to reach it. Five minutes on a flat sidewalk is very different from five minutes uphill.

Two stops 300 meters apart can serve very different areas.

Straight-line distance doesn’t represent how people move.

What matters is the REAL walking time: Isochrones model this more accurately by showing where you can actually get to within a given walking time.

The Proximity project uses walking-distance isochrones to make this visible. This problem looks simple on the surface, but it quickly becomes non-trivial when you scale it:

• many cities
• many stops
• many transport types
• multiple distance thresholds
• interactive visualization on desktop and mobile browsers

It forces you to think about data modeling, computation cost, caching, and the frameworks to use.

When I started building, the goal seemed simple: compute walking-distance isochrones for multiple transport stops and display them interactively.

As the project grew, scaling it across cities, transport types, and interactive maps forced deliberate architectural choices.

The Frontend

SPA with Vue and TypeScript:

• TypeScript helps catch errors at compile-time, making the codebase more robust and maintainable than plain JavaScript.
• Vue provides a reactive, component-based framework that is lightweight, easy to reason about, and ideal for building interactive map interfaces.

Maps with Leaflet:

• Leaflet is fast, flexible, and lightweight. It integrates well with tile-based rendering and supports vector overlays and pin points, which I use to show isochrones.

Deployment to a Azure Static Web Apps:

• Benefits: fast global distribution, low cost, automatic HTTPS, and seamless integration with GitHub CI/CD.
• The SPA model pairs perfectly with static hosting, as most logic runs client-side while fetching precomputed data.

The Backend

Azure Functions in C#:

• C# provides strong typing and mature tooling, which helps maintain reliability in serverless code.
• Serverless functions are cheap, scale automatically, and fit perfectly for event-driven tasks like serving requests for metadata or trigger-based operations.

Data storage and caching

On the data side:

• Areas metadata are stored in Azure Table Storage
• Isochrone JSON blobs are stored in Azure Blob Storage with CDN-friendly headers

Benefits: fast, cheap, globally distributed, and easy to update. Most of the data is relatively static, so caching reduces latency and costs.

Isochrone computation

Real-time computation of walking-distance isochrones is too expensive: iterating over the pedestrian network for thousands of stops and stations would be slow. So I opted for offline precomputation using a CLI generator written in C#.

In this setup:

• Mapbox APIs handle the heavy lifting of isochrone calculation
• OpenStreetMap data is retrieved through the Overpass API to collect the stops to analyze
• All results are stored in Blob Storage, ready to be served by the SPA

This approach balances accuracy, performance, and cost without compromising interactivity.

Deploy on Azure

Proximity isn’t just about computing isochrones and displaying them. Running it reliably and securely in the cloud requires careful architectural choices.

Architecture deployed on Azure

Azure function system identity RBAC

Infrastructure as Code (IaC)

All resources are deployed using Infrastructure-as-Code written in Bicep. Benefits:

• Reproducibility: environments can be recreated consistently
• Traceability: every change is tracked in source control
• Ease of iteration: no manual clicks, everything is declarative

Azure network isolation

• All backend services run behind a private endpoint in an isolated Azure virtual network.
• Frontend accesses backend securely through this private link.
• System-assigned identities are used for authentication between services, eliminating the need for secrets in code.

Advantages:

• Strong security posture by default
• Minimizes attack surface
• Simplifies credential management and compliance

CI/CD with GitHub Actions

Both frontend and backend are deployed automatically via 2 GitHub Actions:

1. Builds and deploys SPA to Azure Static Web Apps
2. Builds and deploys Azure Functions

Benefits:

• Fully automated workflow
• Fast and repeatable deployments
• Low operational overhead

Key trade-offs and deliberate architectural choices

• Avoided fully dynamic computation → would be too slow and costly
• Chose serverless → cheap, scalable, low ops overhead
• Avoided monolithic backend → caching and offline computation are simpler with a clean separation
• Opted for TypeScript + Vue → maintainable frontend without unnecessary complexity
• Leaflet → lightweight and flexible for map visualization

Each choice reflects a trade-off between simplicity, performance, and maintainability.

Building Proximity was a technically simple idea on paper, but the process taught me many lessons — both about architecture and about using AI-assisted development.

Highlights

• VS Code + Copilot accelerated development enormously.
• Writing C# code I already knew well, I went from hours to minutes on many tasks.
• For Vue and Leaflet, which were completely new to me, Copilot helped me scaffold components and learn the development paradigm quickly.
• Rapid prototyping and iteration became possible: I could test frontend-backend interactions without blocking myself on unfamiliar frameworks.
• Hands-on experience with new libraries: I now have a solid foundation in Vue and Leaflet, which will inform future projects.

Lowlights

• At first, I let AI drive too much of the frontend implementation because I wanted to see what it would produce.
  • Result: some code is verbose, repetitive, or not as clean as I would have written manually.
  • Lesson: when using AI for new technologies, prepare focused, precise prompts for better results.
• Refactoring is still needed: even with AI, improving structure or fixing repeated patterns takes time.
  • Proper upfront design reduces refactoring and ensures maintainable code.

Key takeaways

• AI can accelerate coding and learning, but it does not replace careful planning.
• Spend time upfront defining prompts, patterns, and architecture, especially with unfamiliar technologies.
• Iterating on real projects is the fastest way to learn frameworks and libraries.
• Trade-offs are unavoidable: balance speed, maintainability, and clarity.
• The Proximity Project became not just a tool, but a learning experience, combining architectural thinking, cloud deployment, and AI-assisted development.

Want to go deeper?

If you made it this far, thank you for reading 😅.

If you’d like to explore more:

• Try the live tool: Proximity project
• Browse the source code: GitHub repo

If you have ideas, suggestions, or spot something that could be improved, please open an issue on GitHub — that’s the best place to discuss features, fixes, and architectural decisions.

TL;DR

The reason for the apparently anomalous behavior of private endpoints is that, although a private endpoint appears in the Azure portal as a network interface (NIC) connected to a subnet, it’s actually implemented completely differently under the hood.

When Azure creates a private endpoint and attaches it to a subnet, what actually happens is that Azure creates explicit routes on all NICs connected to the VNet where the private endpoint is activated.

These same routes are also added to the NICs of all virtual machines connected to networks that are peered with the one where the private endpoint is exposed.

Let me walk you through the details.

The Network Scenario

The situation is shown in the following diagram: there are 2 spoke VNets connected to a hub VNet. The hub contains an Azure Firewall configured to allow any-to-any traffic. The requirement was to avoid exposing the private endpoint externally to spoke networks, and the idea was to not attach any route table to the private endpoint subnet.

In this configuration, we would expect the following connectivity to the storage account:

Expected vs. Actual Behavior

Expected connectivity:

• spoke-01-vm HTTPS to storage-01: ❌ FAIL (missing return route)
• spoke-02-vm HTTPS to storage-01: ✅ OK (same subnet)
• hub-vm-01 HTTPS to storage-01: ✅ OK (direct peering exists)

Actual connectivity:

• spoke-01-vm HTTPS to storage-01: ✅ OK
• spoke-02-vm HTTPS to storage-01: ✅ OK
• hub-vm-01 HTTPS to storage-01: ✅ OK

WHY ?!?!? :-)

Understanding the Root Cause

When examining the effective routes of hub-vm-01, we find the following route:

The same route is present on the NICs of the firewall VMs as well. This means it’s as if storage-01 is connected to both spoke-02 and the hub network.

How the Traffic Actually Flows

When spoke-01-vm tries to contact the storage account:

1. Outbound traffic: Thanks to the route table on its subnet, traffic reaches the firewall and then goes directly to the private endpoint (pip-01), without passing through the peering to spoke-02
2. Return traffic: Since the private endpoint behaves “as if” it’s also connected to the hub, the response from pip-01 can reach spoke-01-vm without needing the routing table and without passing through the firewall, because it only traverses one peering instead of two.

The Solution: Centralized Firewall Control

One effective way to solve this is:

1. Add a route table to the private endpoint subnet that redirects traffic to the firewall
2. Manage access control at the firewall level to block or allow access to that subnet

⚠️Warning⚠️: when a route table is associated with a subnet, by default it is not applied to private endpoints as well, so it’s necessary to remember to enable the option Network Policy for Private Endpoints > Private endpoint network policy > route tables on the subnet.

Why This Approach Works

Centralizing control at the firewall level is an approach I’ve seen applied in numerous contexts, and from a management perspective, it’s generally a good compromise because:

• Centralized security policies: All traffic rules are managed in one place
• Consistent logging and monitoring: All traffic flows through a single inspection point
• Simplified troubleshooting: Network issues can be diagnosed from a central location
• Scalability: New spokes can be added without complex routing configurations

Key Takeaways

1. Private endpoints create implicit routes across all peered VNets, not just the VNet where they’re deployed
2. Portal representation is misleading: While they appear as NICs in a subnet, their routing behavior is different
3. Route tables alone aren’t sufficient for controlling private endpoint access in hub-and-spoke topologies
4. Firewall-centric control provides better security and management capabilities

Related Resources

For more detailed information on this specific topic, check out

• 🔝 Private endpoints are an illusion
• Azure Private Link documentation
• Hub-spoke network topology in Azure
• Azure Firewall in a hub-spoke network

Windows machine

Once the machine is created, go to Azure Portal > virtual machines > vmname > run command > run powershell script

type:

Install-WindowsFeature -name Web-Server -IncludeManagementTools
Remove-Item -Path 'C:\inetpub\wwwroot\iisstart.htm'
Add-Content -Path 'C:\inetpub\wwwroot\iisstart.htm' -Value $($env:computername)

click Run

After a couple of minutes the script will be executed, and IIS will be provisioned and working.

Linux machine

Once the machine is created, go tpo Azure Portal > virtual machines > vmname > run command > run linux shell script

type:

sudo apt-get update
sudo apt-get install -y nginx
sudo rm /var/www/html/index.html
echo $HOSTNAME | sudo tee /var/www/html/index.html

click Run

After a couple of minutes the script will be executed, and IIS will be provisioned and working.

Azure API Management(APIM), on the other hand, is a comprehensive API management platform that helps enterprises manage, secure, and monitor their APIs. It provides features such as API gateway, rate limiting, analytics, and developer portal, making it easier for businesses to expose their services to internal and external consumers.

By using Azure API Manager in front of Azure Open AI instances, enterprises can ensure better control, security, and visibility over their AI deployments. This setup allows for centralized management of API traffic, improved performance through caching and load balancing, and enhanced security with features like authentication and authorization.

In this post, I present a collection of API Management recipes that I have gathered while assisting various customers and partners in exposing one or more instances of Azure OpenAI through Azure API Manager.

Network configuration and integration with an Enterprise-scale landing zone (ESLZ) is out of scope of this post. For a walkthrough that guides the integration of APIM and AOAI in a hub & spoke context, you can also refer to my article available as part of the hub-and-spoke playground project.

The lab used for these walk-throughs consists of the following resources:

• 1 x Azure API Management service (developer SKU) nicold-apim
• 2 x Azure OpenAI service (S0 SKU) apimaoai01 and apimaoai02

This is the list of topic I will cover:

• Add Azure Open AI as APIM backend resource
• Expose apim-001 endpoint as APIM root API
• Implement throttling
• Show in a Response header (aoai-origin) the host of the OpenAI API Called
• Round robin calls between 2 instances of Open AI
• Fallback on a second openAI instance for 60 secs, if the first answers with 429 error (exceeded token rate limit)
• Generate a report of API Usage by access key
• Generate a report of API Usage by source IP
• Generate a report of backends usage over time
• Generate a report of API requests by OpenAI grouped by deployment-id

Add Azure Open AI as APIM backend resource

Go to API Management services > nicold-apim > Backends > Add

• Name: apim-001
• Backend hosting type: Custom URL
• Runtime URL: https://nicold-aoai-001.openai.azure.com/openai
• Authorization credential
  • Headers
    • Name: api-key
    • Key: your endpoint key
• Click [create]

Go to API Management services > nicold-apim > Backends > Add

• Name: apim-002
• Backend hosting type: Custom URL
• Runtime URL: https://nicold-aoai-002.openai.azure.com/openai
• Authorization credential
  • Headers
    • Name: api-key
    • Key: your endpoint key
• Click [create]

Here is the result:

Expose apim-001 endpoint as APIM root API

Go to Azure Portal > API Management Services > nicold-apim > API > Create from Azure Resources > Azure OpenAI Service

• Azure OpenAI instance: nicold-aoai-001
• API Version: 2024-02-01
• Display name: /
• Name: root-api
• Click [review and create] and then [create]

This creates a frontend but ALSO a backend. To use the previously created backend, go to:

API Management Services > nicold-apim > APIs > All APIs > / > Design > Backend > Policies > Base

and change backend-id="openai-root-openai-endpoint" to backend-id="apim-001", then save it.

To test this endpoint, go to: API Management Services > nicold-apim > APIs > All APIs > / > Test > Creates a completion for the chat message

• Deployment-id: gpt4o-001
• API-version: 2024-02-01 (same as used above)
• Request body: {"messages": [{ "role": "system","content": "You are a helpful assistant."},{ "role": "user", "content": "Tell me a joke!"} ]}
• Click: [SEND]

Here is also a PowerShell script to test this configuration:

$openai = @{
   api_key     = "my-api-key"
   api_base    = "https://nicold-apim.azure-api.net/" # your endpoint
   api_version = '2024-02-01'
   name        = 'gpt4o-001' # custom name you chose for your deployment
}

$body = '{
  "messages": [
    { "role": "system","content": "You are a helpful assistant."},
    { "role": "user", "content": "Tell me a joke!"}
  ]}'

# Header for authentication
$headers = [ordered]@{
   'api-key' = $openai.api_key
}

# Send a request to generate an answer
$url = "$($openai.api_base)/deployments/$($openai.name)/chat/completions?api-version=$($openai.api_version)"

$response = Invoke-WebRequest -Uri $url -Headers $headers -Body $body -Method Post -ContentType 'application/json'

# Show response headers
$response.headers
$responseObj = ConvertFrom-Json $response.content

# Show response body
$responseObj.choices.message.content

Implement throttling

The following policy limits access to 10 requests per minute. Paste the XML in: API Management Service > nicold-apim > APIs > All APIs > / > all operations > inbound processing > policies (code editor)

<policies>
    <inbound>
        <base />
        <rate-limit calls="10" renewal-period="60" />
        <set-backend-service id="apim-generated-policy" backend-id="apim-001" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

To limit to 2 calls per IP in 60 seconds, use the following rate-limit XML:

<rate-limit-by-key calls="2" renewal-period="60" counter-key="@(context.Request.IpAddress)" />

To limit to 2 calls per API KEY in 60 seconds, use the following rate-limit XML:

<rate-limit-by-key calls="2" renewal-period="60" counter-key="@(context.Request.Headers.GetValueOrDefault("api-key"))" />

Show in a Response header (aoai-origin) the host of the OpenAI API Called

Paste the XML in: API Management Service > nicold-apim > APIs > All APIs > / > all operations > inbound processing > policies (code editor), in the outbound policy:

<outbound>
    <base />
    <set-header name="aoai-origin" exists-action="override">
        <value>@(context.Request.Url.Host)</value>
    </set-header>
</outbound>

Round robin calls between 2 instances of Open AI

The following policy implements a round-robin between 2 backends: apim-001 and apim-002.

Paste the XML in: API Management Service > nicold-apim > APIs > All APIs > / > all operations > inbound processing > policies (code editor)

<policies>
	<inbound>
		<base />
		<cache-lookup-value key="backend-rr" variable-name="backend-rr" />
		<choose>
			<when condition="@(!context.Variables.ContainsKey("backend-rr"))">
				<set-variable name="backend-rr" value="0" />
				<cache-store-value key="backend-rr" value="0" duration="100" />
			</when>
		</choose>
		<choose>
			<when condition="@(Convert.ToInt32(context.Variables["backend-rr"]) == 0)">
				<set-backend-service backend-id="apim-001" />
				<cache-store-value key="backend-rr" value="1" duration="100" />
			</when>
			<otherwise>
				<set-backend-service backend-id="apim-002" />
				<cache-store-value key="backend-rr" value="0" duration="100" />
			</otherwise>
		</choose>
	</inbound>
	<backend>
		<base />
	</backend>
	<outbound>
		<base />
	</outbound>
	<on-error>
		<base />
	</on-error>
</policies>

💥 In a round robin scenario, in order to work properly, both OpenAI instances must have the same deployments.

Fallback on a second openAI instance for 60 secs, if the first answers with 429 error (exceeded token rate limit)

The following policy uses the apim-001 backend until it responds with 429 ("Requests to ... Operation under Azure OpenAI API version 2024-02-01 have exceeded token rate limit of your current OpenAI S0 pricing tier). When this happens, it switches to the apim-002 endpoint and remains there for 60 seconds.

Paste the following XML in: API Management Service > nicold-apim > APIs > All APIs > / > all operations > inbound processing > policies (code editor)

<policies>
    <inbound>
        <base />
        <cache-lookup-value key="useSecondaryBackend" variable-name="useSecondaryBackend" />
        <choose>
            <when condition="@(!context.Variables.ContainsKey("useSecondaryBackend"))">
                <set-backend-service backend-id="apim-001" />
            </when>
            <otherwise>
                <set-backend-service backend-id="apim-002" />
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
        <choose>
            <when condition="@(context.Response.StatusCode == 429 && !context.Variables.ContainsKey("useSecondaryBackend"))">
                <cache-store-value key="useSecondaryBackend" value="true" duration="60" />
            </when>
        </choose>
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

💥 In a fallback scenario, in order to work properly, both OpenAI instances must have the same deployments.

Generate a report of API Usage by access key

Go to: API Management Services > nicold-apim > logs > New Query (KQL mode):

For a table uses:

ApiManagementGatewayLogs
| where ApimSubscriptionId != ''
| summarize count() by ApimSubscriptionId
| order by count_ desc
| render table

For a pie chart:

ApiManagementGatewayLogs
| where ApimSubscriptionId != ''
| summarize count() by ApimSubscriptionId
| order by count_ desc
| render piechart

Generate a report of API Usage by source IP

Go to: API Management Services > nicold-apim > logs > New QUery (KQL mode):

ApiManagementGatewayLogs
| where ApimSubscriptionId != ''
| summarize count() by CallerIpAddress
| order by count_ desc
| render table

Generate a report of backends usage over time

Go to: API Management Services > nicold-apim > logs > New QUery (KQL mode):

Group by hour

ApiManagementGatewayLogs 
| where ApimSubscriptionId != '' 
| summarize  count() by bin (TimeGenerated, 1h), BackendId 
| render timechart

Group by day

ApiManagementGatewayLogs 
| where ApimSubscriptionId != '' 
| summarize  count() by bin (TimeGenerated, 1d), BackendId 
| render timechart

Column chart

ApiManagementGatewayLogs
| where ApimSubscriptionId != ''
| summarize count() by bin(TimeGenerated, 1h), BackendId
| project TimeGenerated, BackendId, count_
| render columnchart  kind=stacked

Generate a report of API requests by OpenAI grouped by deployment-id

Go to: API Management Services > nicold-apim > logs > New QUery (KQL mode):

ApiManagementGatewayLogs
| extend DeploymentSubstring = extract(@"deployments/([^/]+)", 1, Url)
| where ApimSubscriptionId != ''
| summarize count() by DeploymentSubstring
| render table

# Azure OpenAI metadata variables
$openai = @{
   api_key     = "YOUR_APIKEY_HERE"
   api_base    = "https://your-enpoint-here.openai.azure.com/" # your endpoint
   api_version = '2024-02-01'
   name        = 'your-deployment-name-here' # custom name you chose for your deployment
}

$body = '{
  "messages": [
    { "role": "system","content": "You are a helpful assistant."},
    { "role": "user", "content": "Tell me a joke!"}
  ]}'

# Header for authentication
$headers = [ordered]@{
   'api-key' = $openai.api_key
}

# Send a request to generate an answer
$url = "$($openai.api_base)/openai/deployments/$($openai.name)/chat/completions?api-version=$($openai.api_version)"
$response = IRM -Uri $url -Headers $headers -Body $body -Method Post -ContentType 'application/json'
$response.choices.message.content

The event to monitor is 4688(S): A new process has been created

This event generates every time a new process starts. To recognize the “run-as-administrator” use, it is necessary to check the value of the Token Elevation Type field, in particular, it must contain %%1937

This event is disabled by default, but it can be enabled via GPO for domain machines or using the local security policy for stand alone servers (Local Security Policy > Local Policy > Audit Policy > Audit Process Tracking)

The XPATH query, which can be used as a filter in the Window Event Viewer, is the following

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4688)]]
      [EventData
    [Data
        [@Name='TokenElevationType'] and
        (Data='%%1937')
    ]]</Select>
  </Query>
</QueryList>

The same query can also be used in a Data Collection Rule in Azure:

• Data Source: Windows Event log
• Query Type: Custom
• Xpath Query: [EventData[Data[@Name='TokenElevationType']and(Data='%%1937')]]

As indicated in the official documentation below:

%%1937: Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.

this event is also triggered when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group, so the presence of false positives is possible.

Noisy is an elegant yet robust Python script that is programmed to generate arbitrary HTTP/DNS traffic.

I primarily utilize it on my ‘hub-and-spoke playground’ to generate simulated traffic. This facilitates the exploration and manipulation of Azure firewall configurations.

the hub-and-spoke playground is instead a composite collection of BICEP/ARM templates. These templates are designed to be deployed on Azure, forming a hub and spoke network topology that is in alignment with the Microsoft Enterprise scale landing zone reference architecture. This setup serves as an experimental playground for testing and studying.

The following steps need to be executed from an administrative PowerShell terminal if the machine runs Windows:

#
# STEP1 : install python
#
$version = "3.12.5"
$directory = "Python312"

$pythonSetupFile = "python-" + $version + "-amd64.exe"
$downloadUri = 'https://www.python.org/ftp/python/' + $version + '/' + $pythonSetupFile
Invoke-WebRequest -UseBasicParsing -Uri $downloadUri -OutFile $pythonSetupFile

$installPythonCommand = '.\' + $pythonSetupFile
Start-Process -wait $installPythonCommand -ArgumentList @('/quiet', 'InstallAllUsers=1', 'PrependPath=1', 'Include_test=0')

$env:PATH += ";C:\Program Files\" + $directory + ";"

#
# STEP2: install git
#
$gitVersion = "2.46.0"
$gitSetupFile = "Git-" + $gitVersion +"-64-bit.exe"
$gitDownloadUri = "https://github.com/git-for-windows/git/releases/download/v" + $gitVersion + ".windows.1/" + $gitSetupFile
Invoke-WebRequest -UseBasicParsing -Uri $gitDownloadUri -OutFile $gitSetupFile

$installGitCommand = '.\' + $gitSetupFile
Start-Process -wait $installGitCommand -ArgumentList @('/SILENT')

$env:PATH += "C:\Program Files\Git\cmd;"

#
# STEP3: download noisy repo from github
#
python -m pip install requests
git clone https://github.com/1tayH/noisy.git
cd noisy

#
# STEP4: execute noisy 
#
python noisy.py --config config.json

If you run an Ubuntu machine, you already have python and git installed, so only steps 3 and 4 are required, as shown below:

sudo apt update
sudo apt upgrade

git clone https://github.com/1tayH/noisy.git
cd noisy

python3 noisy.py --config config.json

Azure availability zones are physically separate locations within each Azure region that are tolerant to local failures. Azure availability zones are connected by a high-performance network with a round-trip latency of less than 2ms.

In Azure, each data center is assigned to a physical (availability) zone. Physical zones are mapped to logical (availability) zones in your Azure subscription. You can design resilient solutions by using Azure services that use availability zones.

A proximity placement group is an Azure Virtual Machine logical grouping capability that you can use to decrease the inter-VM network latency associated with your applications. When the VMs are deployed within the same proximity placement group, they are physically located as close as possible to each other.

Understanding the latency implications of different network configurations is essential when designing a high-availability and resilient architecture. It is crucial to consider the impact of latency on application performance and user experience. By measuring latency between virtual machines in various network setups, you can assess the effectiveness of different configurations. This knowledge can help you make informed decisions when building your architecture.

In this blog post I measure the latency between virtual machines deployed in Azure’s West Europe region in the following configurations:

• same v-net, same availability zone, same proximty placement group
• same v-net, across availability zones
• multiple v-nets (in peering), same availability zone
• multiple v-nets (in peering), across availability zones
• multiple v-nets connected in a Hub & Spoke topology and Routing via Azure Virtual Network Gateway
• multiple v-nets connected in a Hub & Spoke topology and Routing via Azure Firewall

Rather than the absolute values, my focus is on assessing the impact in terms of latency of various network configurations.

To measure latency, I used Latte, a Windows network latency benchmark tool available on GitHub. You can find more information on how to measure network latency between Azure VMs using Latte (on Windows) and SOCKPERF (on Linux) at this link.

The Azure hub and spoke playground is a GitHub repository where you can find a reference network architecture that I use as a common base to implement configurations and test networking and connectivity scenarios. I have also used it here as a starting point to build the lab used in this post.

Scenario 1 - one virtual network

In this scenario I have a calling machine in one availability zone and 3 additional machines each in a different availability zone. In availability zone 1 I have also placed both machines in the same proximity placement group to have the best possible latency, as shown below.

Here the measures from spoke01-az-01 (Availability Zone 1).

Takeaways:

• The Proximity Placement Group performs exceptionally well, with latency well below 2ms (only 65 microseconds!)
• When communicating between availability zones, I consistently measured an average latency below 2ms.
• The significant difference in latency between communication from AZ1 to AZ2 and AZ1 to AZ3 is likely due to the non-uniform distance between the three Availability Zones in the West Europe region. These three zones are positioned in a highly pronounced isosceles triangle around Amsterdam.

Scenario 2 - two virtual networks in peering

In this scenario I have measured the impact of a network peering. I have created 3 more machines, in 3 availability zones, on another network, in peering.

Here the measures from spoke01-az-01 (availability zone 1) to machines in another virtual network in peering.

Takeaways:

• Network peering does not add any measurable overhead.
• The latency between two VMs in AZ1, even if they are not in the same proximity group, is almost equal to or even better than the latency between two VMs in the same proximity group. It is possible that spoke-02-az-01 has been provisioned very close to spoke-01-az-01, although it is not guaranteed.

Scenario 3 - two virtual networks in H&S configuration with a Virtual Network Gateway in between

In this scenario I moved to a more classic configuration: I eliminated peering and routed traffic through a central hub and an Azure Virtual Network Gateway.

Here the measures from spoke01-az-01 (availability zone 1) to machines in another virtual network via an Azure Virtual Network Gateway in the Hub Network.

Takeaways

• Latency increased up to 0.8/2.1ms because each packet has to cross 2 peerings and a virtual appliance (Azure Virtual Network Gateway).
• Staying in the same availability zone still has a positive impact on latency. Communication between AZ1 and AZ2 increases latency by a small amount (0.1ms), but in the case of AZ3, latency reaches just over 2ms. However, we are still within the limits stated by Microsoft, as the guaranteed 2ms latency does not account for the presence of a virtual appliance in between.

Scenario 4 - two virtual networks in H&S configuration with an Azure Firewall in between

In this last scenario I implemented the reference architecture described in the cloud adoption framework, that is a hub and spoke, with an Azure Firewall to control all the traffic.

Here the measures from spoke01-az-01 (availability zone 1) to machines in another virtual network and different availability zones, via Azure Firewall in the Hub Network.

Takeaways

• The latency with the Azure Firewall is comparable to that of the Azure Virtual Network Gateway in between.
• There are still situations where the latency is below 2ms or slightly higher (2.4/2.6ms).
• The transit time through the firewall can also vary depending on the capabilities enabled on the server and the number or policy rules that the traffic crosses.

Final thoughts

• Whenever possible, always use Proximity Placement Groups to achieve lower latency.
• Traffic between zones has been consistently measured to be below 2ms.
• Peerings have minimal impact on latency.
• The hub-and-spoke architecture can have an impact on latency, but by using either a VPN Gateway or, preferably, an Azure Firewall as a virtual appliance, the latency remains almost within the 2ms threshold.

Azure Speech Services is a comprehensive suite of cloud-based speech services offered by Microsoft Azure. This suite includes a range of services such as speech-to-text, text-to-speech, speech translation, and speaker recognition. These services harness the power of advanced machine learning algorithms to convert spoken language into written text, generate natural human-like speech from text, translate speech into different languages, and identify speakers based on their unique voice characteristics. Azure Speech Services is designed to handle both real-time and batch processing, making it suitable for a wide variety of applications.

An integral part of Azure Speech Services is the Azure Batch Transcription Service(ABTS). This service is specifically designed to transcribe large volumes of audio data into text. It takes in audio files as input and outputs a detailed transcription of the spoken content in the audio. Azure Batch Transcription Service is particularly useful in scenarios where businesses need to transcribe large amounts of audio data quickly and accurately.

In the context of Azure Batch Transcription Service, network topologies play a critical role in ensuring data privacy and sovereignty. Network topologies determine the path that data travels from the source to the Azure cloud and back. This path can have significant implications for data privacy and sovereignty, especially in scenarios where data needs to cross international borders. By carefully designing the network topology, businesses can ensure that their data remains within specific geographical boundaries, thereby complying with local data protection regulations and maintaining the trust of their customers. Moreover, a well-designed network topology can also enhance the performance of the Azure Batch Transcription Service by reducing latency and increasing throughput.

In this post, I show various networking topologies related to this field, highlighting key features and points of reflection.

A typical workflow

An automatic transcription workflow that uses Azure Batch Transcription Service typically consists of the following steps:

1. Upload audio files to an Azure Storage container.
2. Submit the transcription job to ABTS with parameters such as the audio file URLs, the transcription language, and the transcription model.
3. ABTS asynchronously accesses the storage that contains audio files, reads them, and produces the transcriptions.
4. Once finished, ABTS saves the transcription to destination Azure Storage container.
5. While ABTS runs, the customer can check the transcription status and wait until it completes.
6. The customer retrieves the resulting transcription from the destination Azure Storage container.

Scenario 1: Public internet

In this scenario, I show the default configuration, where ABTS reads data from a storage account that is publicly exposed on the internet, and dumps the results in a storage managed by the service itself, therefore outside the customer’s Azure subscription.

download drawio version of this schema from this link.

In this case, even though confidentiality is guaranteed by managed access through SAS Tokens, the storage and services are all exposed on the internet, thus potentially vulnerable.

• how create a batch transcription https://learn.microsoft.com/en-us/azure/ai-services/speech-service/batch-transcription-create?pivots=speech-cli
• Storage SAS token: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview

Scenario 2: Customer’s destination storage

In this scenario, entirely analogous to the first one, a destination Storage Account is created on the customer’s subscription. At the end of the operation, ABTS copy the contents directly to this storage.

download drawio version of this schema from this link.

Also in this case, confidentiality is guaranteed exclusively by the SAS tokens of the Storage Account, but all communication occurs through the internet to ensure both the customer and the Azure service can access the data they need to work on.

• Specify a destination container URL: https://learn.microsoft.com/en-us/azure/ai-services/speech-service/batch-transcription-create?pivots=speech-cli#specify-a-destination-container-url

Scenario 3: Using Private endpoint

In this scenario, all the resources involved (VM, storage and ABTS) are exposed through private endpoints on a customer’s internal network.

download drawio version of this schema from this link.

Compared to the previous scenario, the upload of data to the storage and the download of results occur through a secure channel internal to the customer’s subscription. However, the storage accounts must remain publicly accessible via the internet to allow ABTS to function properly.

• Speech Service - Private Endpoint: https://learn.microsoft.com/en-us/azure/ai-services/speech-service/speech-services-private-link?tabs=portal
• Azure Storage - Private endpoint: https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints

Scenario 4: Use the Bring your own storage (BYOS) Speech resource for speech to text

this service is currently in preview: to request access use this link

Bring your own storage (BYOS) is an Azure AI technology for customers who have high requirements for data security and privacy. The core of the technology is the ability to associate an Azure Storage account, that the user owns and fully controls with the Speech resource. The Speech resource then uses this storage account for storing different artifacts related to the user data processing, instead of storing the same artifacts within the Speech service premises as it is done in the regular case. This approach allows using all set of security features of Azure Storage account, including encrypting the data with the Customer-managed keys, using Private endpoints to access the data, etc.

In BYOS scenarios, all traffic between the Speech resource and the Storage account is maintained using Azure global network (but all resource must be in the same region), in other words all communication is performed using private network, completely bypassing public internet. Speech resource in BYOS scenario is using Azure Trusted services mechanism to access the Storage account, relying on System-assigned managed identities as a method of authentication, and Role-based access control (RBAC) as a method of authorization.

download drawio version of this schema from this link.

Consider the following rules when planning BYOS-enabled Speech resource configuration:

• Speech resource can be BYOS-enabled only during creation. Existing Speech resource can’t be converted to BYOS-enabled. BYOS-enabled Speech resource can’t be converted to the “conventional” (non-BYOS) one.
• Storage account association with the Speech resource is declared during the Speech resource creation. It can’t be changed later. That is, you can’t change what Storage account is associated with the existing BYOS-enabled Speech resource. To use another Storage account, you have to create another BYOS-enabled Speech resource.
• When creating a BYOS-enabled Speech resource, you can use an existing Storage account or create one automatically during Speech resource provisioning (the latter is valid only when using Azure portal). One Storage account can be associated with many Speech resources. We recommend using one Storage account per one Speech resource.
• It is reccomended that Storage account and the related BYOS-enabled Speech service are located in the same region.

Setup BYOS: https://learn.microsoft.com/en-us/azure/ai-services/speech-service/bring-your-own-storage-speech-resource?tabs=azure-cli#byos-enabled-speech-resource-basic-rules

Move a VM from “no infrasstructure redundancy” to a specific Availability Zone

This scenario is supported by the Azure portal. Let’s start from a VM with the following characteristics:

• Name: machine-01
• Linux
• OS disk LRS 30Gb

to move this VM to a specific Availability Zone, from Azure portal go to:

• machine-01 > availability + scaling > Availability Zones > get Started
• select Target Availability Zone > Zone 1

in this migration:

• A new virtual machine is created
• New NIC is created along with the zonal VM
• you can optionally change target virtual network and subnet
• VM will be stopped during the process to avoid data loss. There will be a brief downtime of few minutes and copy of VM(s) will be created in the target zone
• the machine created will be in another resource group

at the end of the moving process, you can safetly delete the source machine.

Move a VM from an availability zone to another

This is unsupported.

Transform a VM from “availability zone xx” to “no infrastructure redundancy” is also not supported.

If you need to change availability zone to a VM you can follow these steps:

• Turn-off source VM
• Create a full snapshot (ZRS) of the OS disk
• Create a managed disk from the snapshot, in the availability zone target
• Select the OS disk created, and select [create VM] from the disk

More information:

• Availiability Zones: https://learn.microsoft.com/en-gb/azure/reliability/availability-zones-overview?tabs=azure-cli
• https://learn.microsoft.com/en-us/azure/virtual-machines/attach-os-disk?tabs=portal