AZURE HEROES - Blog

Azure Virtual Network Routing Appliance — A Native Solution for Hub-and-Spoke Routing

Sat, 14 Feb 2026 21:00:00 GMT

A few months back, a customer called me with a familiar frustration. They had a solid hub-and-spoke topology in Azure — around 100 spoke VNets, one per application team, clean isolation, good governance. Textbook setup. The problem? Traffic between their spokes had to pass through an Azure Firewall Premium they'd deployed in the hub, and they were starting to hit the 100 Gbps ceiling. On top of that, their monthly Azure Firewall bill had grown to a point where the finance team was asking questions — and the honest answer was: *"We're mostly using it as a router, not a firewall.

That's an awkward conversation.

They didn't need deep packet inspection between internal spokes. They didn't need L7 filtering. They just needed traffic from Spoke A to reach Spoke B reliably and fast at scale. We looked at third-party NVAs, but the licensing costs, the VM-based throughput caps, and the 250,000 active connection limit made that feel like trading one problem for another.

Then Microsoft released Azure Virtual Network Routing Appliance into public preview in February 2026, and things got interesting.

Why Spoke-to-Spoke Routing Is a Pain in the First Place

If you've worked with Azure long enough, you know that VNet peering is not transitive. Spoke A and Spoke B are both peered to the Hub, but they can't talk to each other through the hub unless you explicitly tell them how.

This trips up a lot of engineers coming from traditional networking. On-premises, your router just… routes. In Azure, the "default gateway" of a subnet doesn't really exist as a routing entity. The virtual NIC itself holds the routing table and sends traffic directly to the destination — bypassing any gateway in between. So if you want Spoke A to reach Spoke B via the hub, you need an actual device sitting in the hub that Azure can use as a next-hop.

Historically, your options were:

Option	The Catch
Azure Firewall Premium	Great firewall, awkward router. Max 100 Gbps, $1.75/hr before data charges, limited BGP support for learning on-prem default routes.
Azure Firewall Standard	Max 30 Gbps, $1.25/hr — even less suited for high-throughput routing.
Third-party NVA	VM-based = VM limits. The 250,000 active connection cap has caught more than a few people off guard at scale. Add licensing, patching, and support contracts on top.

For organizations going cloud-first, there's often a genuine push to avoid third-party NVAs where a native Azure construct can do the job. Until now, there wasn't one.

Enter the Azure Virtual Network Routing Appliance

AVNA is a managed Azure resource that you deploy directly inside your hub VNet. It runs on specialized networking hardware — not regular VMs — which is exactly why the performance numbers look so different from what you're used to.

Here's what makes it different from an NVA or Azure Firewall:

It's a top-level Azure resource — managed just like a VNet, NSG, or Route Table. No OS to patch, no images to manage.
It lives in a dedicated subnet called VirtualNetworkApplianceSubnet.
It's purely a forwarding layer — it routes traffic, full stop. No firewall policy, no DPI, no NAT (though it works alongside NAT Gateway).
High availability is built-in and it's availability zone resilient by default — you don't need a load balancer in front of it. If you put one there anyway, it won't work the way you expect.
Supports NSGs, Admin rules, UDRs, and NAT Gateway natively.

The Architecture

Here's how this looks in a typical hub-and-spoke setup. Each spoke VNet is peered to the hub. You configure UDRs in your spoke subnets to point east-west traffic at the AVNA's IP address as the next-hop. The AVNA handles the rest — forwarding the packet to the right destination spoke. On-premises traffic keeps going through your hub VPN/ExpressRoute gateway, and internet egress still goes through your NAT Gateway or firewall.

Click to set custom HTML

Fig 1 — Hub-and-spoke topology with AVNA as the east-west routing layer

How You Set Up the Routing

This is where it gets a bit architectural. Once AVNA is deployed, you need to decide how your spoke UDRs are structured. Three options:

Option 1 — Keep it granular

Create specific routes per spoke — cloud prefixes go to AVNA, on-premises traffic to the hub gateway, internet to egress. Maximum control, maximum route table management. Fine for small environments, painful at scale.

Option 2 — Everything through AVNA

Point a default route (0.0.0.0/0) in the spokes to the AVNA and let it sort everything — spoke-to-spoke internally, on-prem to the gateway, internet egress onward. Simplest UDR config. Reduces asymmetric routing risk. Trade-off: you lose per-spoke granularity.

✅ Option 3 — RFC1918 via AVNA, default to egress (the sweet spot)

Send all private address space (10/8, 172.16/12, 192.168/16) to the AVNA. Let the default route (0.0.0.0/0) point to your internet egress solution. Cleanly separates spoke-to-spoke routing from internet egress, reduces accidental asymmetric firewall paths, and keeps spoke UDRs simple. Most practitioners land here.

Performance — This Is Where It Gets Serious

Fig 2 — AVNA bandwidth tiers and their capacity limits

Compare 200 Gbps and 8 million concurrent flows to what Azure Firewall Premium offers (100 Gbps) or what a typical NVA VM can do — limited by the VM SKU and that 250,000 connection cap. For high-traffic, east-west-heavy environments, this changes the conversation completely.

⚠️ Heads-up: The capacity tier is selected at deployment time and cannot be changed later without a full redeployment. Size it properly upfront. During preview there's no charge, so you might as well pick 200 Gbps — but when billing kicks in at GA, you'll want to have done that math first.

What About NSGs?

You can attach an NSG to the VirtualNetworkApplianceSubnet to enforce basic Layer 4 filtering between spokes. But be aware — because traffic is both entering and leaving through the same subnet, your rules need to handle both inbound and outbound directions. NSGs are a blunt tool here, and this setup is really suited to spokes in the same security zone where you just need some least-privilege access control. If you need stateful deep filtering, Azure Firewall or a third-party NVA is still the right answer for that layer.

Preview Limitations — Be Honest With Your Stakeholders

What's limited	Details
Not production-ready	Preview only — for testing and evaluation
Instances per subscription	Max 2 (request more via form)
Max throughput	200 Gbps per instance
IPv6	Not supported
Metrics and logs	Not yet exposed — you're flying blind during preview
Tooling	No Azure CLI, PowerShell, or Terraform support yet
Private Endpoint	Global and cross-region Private Endpoint not supported
Regions	East US, East US 2, West Central US, West US, North Europe, UK South, West Europe, East Asia
Cost	Free during preview

The lack of metrics is the one that stings the most in practice. You can't see traffic volumes, connection counts, or error rates. That's fine for a lab, not great if you're trying to build confidence for a GA migration plan.

How to Get Access

Register your subscription for the preview feature flag: Microsoft.network/AllowVirtualNetworkAppliance
Fill out the sign-up form linked on the Microsoft Learn page
Wait for product group approval

It's technically a public preview, but the approval gate and limited region availability make it feel closer to a private preview. Expect some wait time.

My Take

Going back to my customer — we're watching this closely. The numbers look right, the architecture fits, and the idea of removing a $1.75/hr firewall that was doing routing work and replacing it with a native Azure construct is exactly the kind of simplification their platform team has been pushing for.

What I'd want to see before recommending this for production:

Metrics and logging — you need visibility into what's flowing through it
Terraform and CLI support — nobody wants to manage infrastructure only through the portal
Clear GA pricing — the capacity tiers strongly suggest tiered billing; that math needs to make sense vs. alternatives
IPv6 support — more and more environments are running dual-stack

If you're in a hub-and-spoke topology and your routing solution feels like a workaround, this is worth signing up for and testing. Get familiar with it now so you're ready when it hits GA.

Sources:
Microsoft Learn — Virtual Network Routing Appliance Overview
Simon Painter (Azure MVP) — Public preview of Azure Virtual Network Routing Appliance

Legacy Platforms Are Not the Enemy

Sat, 05 Apr 2025 21:00:00 GMT

Almost every platform engineer experiences the same moment when joining a company with a long-running cloud platform.
You open the repository.
You start reading the Terraform code.
You inspect the CI/CD pipelines.
And suddenly… confusion.

Your first instinct — especially if you've come through courses, reference architectures, or cloud conferences — is usually the same:

"This needs a full rewrite. New landing zone. Clean Terraform structure. Modern pipelines. Best practices everywhere."

It sounds smart. It looks professional. And it is one of the most dangerous decisions a platform engineer can make.

Why "Just Rewrite It" Is a Trap

That platform you're frustrated with is not theoretical. It has been running real production workloads for months — sometimes years. It survived:

Incidents and outages
Compliance audits
Security exceptions
Scaling challenges
Real customer pressure

Every ugly conditional, strange module boundary, or pipeline workaround likely exists because something broke in the past. That platform is the reason applications deploy today, teams deliver features, and the business generates revenue.

Destroying it without understanding it is not engineering excellence — it's risk.

Engineering Maturity Starts With Respect

When I mentor platform engineers struggling with legacy Infrastructure as Code or DevOps setups, the first thing I do is stop the wrong kind of enthusiasm. Not because improvement is bad — but because reckless improvement is expensive.

Anyone can design a perfect landing zone on a whiteboard.
Real expertise is improving a live platform without breaking the business.

The "Big Rewrite" Fallacy

A full rewrite assumes you can:

Rediscover years of hidden business rules
Pause feature delivery without business impact
Not miss edge cases that were learned the hard way
Deliver something strictly better — not just prettier

In reality, big rewrites often result in lost functionality, new security gaps, more incidents, and — most painfully — lost trust from stakeholders.

From management's perspective, you don't look like a savior. You look like a source of risk.

How Strong Platform Engineers Handle Legacy Platforms

STEP 1

Understand Before You Judge — Chesterton's Fence

Before removing anything, ask why it exists. That strange Terraform condition or pipeline exception is probably there for a reason:

A regulatory requirement someone negotiated under pressure
A workaround for a critical enterprise customer
A scar from a historical incident that took the platform down

STEP 2

Use the Strangler Pattern for Platforms

You don't rebuild a landing zone overnight. Instead:

Introduce new, well-designed Terraform modules alongside the old ones
Create new pipelines with better standards for new workloads
Let new workloads adopt the new patterns from day one

STEP 3

Apply the Boy Scout Rule to IaC

"Leave the code better than you found it."

Every time you touch the platform — even for a small fix — improve something:

Fix a variable name
Extract a reusable module
Remove duplication
Add a missing comment or README entry

STEP 4

Build Safety Nets Before You Refactor

In platform engineering, safety nets are non-negotiable before touching anything:

terraform plan validations in every pipeline
Policy-as-Code to catch drift and violations
Drift detection on live environments
Integration and canary environments to validate changes safely

The Real Takeaway

Engineering maturity is not about hating legacy platforms. It's about respecting what kept the company alive — and evolving it carefully.

This mindset shift is one of the hardest lessons in platform engineering:

From "I know best practices" → To "I know how to apply them in production."

That shift separates engineers who can design platforms from engineers who can own and evolve them responsibly. And that is what real Platform Engineering is about.

Understanding Azure Network Security: Differentiating Azure Firewall, WAF, DDoS Protection, and NSGs

Thu, 06 Feb 2025 21:00:00 GMT

In the realm of Azure's network security, understanding the distinct roles of services like Azure Firewall, Web Application Gateway (WAF), Distributed Denial of Service (DDoS) Protection, and Network Security Groups (NSGs) is pivotal for crafting a robust security architecture. Each service offers unique functionalities tailored to specific security needs.

Azure Firewall is a cloud-native, fully managed network security service that safeguards Azure Virtual Network resources. It operates at both network and application layers, providing comprehensive traffic filtering. Key features include:

Comprehensive Filtering: Inspects both inbound and outbound traffic, allowing or denying based on predefined rules.
Threat Intelligence Integration: Utilizes Microsoft's threat intelligence to block traffic from known malicious IP addresses and domains.
High Availability and Scalability: Automatically adjusts to changing traffic patterns, ensuring consistent protection without manual intervention.

Web Application Gateway (WAF) is designed to protect web applications from common threats and vulnerabilities, such as SQL injection and cross-site scripting attacks. Deployed with services like Azure Application Gateway or Azure Front Door, WAF offers:

Application Layer Protection: Monitors HTTP/HTTPS traffic, filtering out malicious requests targeting web applications.
Predefined Rule Sets: Employs managed rule sets based on the Open Web Application Security Project (OWASP) guidelines to address prevalent security risks.
Customizable Rules: Allows the creation of tailored rules to meet specific security requirements of applications

Distributed Denial of Service (DDoS) Protection aims to maintain the availability of applications by mitigating the impact of DDoS attacks, which overwhelm resources with excessive traffic. Azure's DDoS Protection provides:

Traffic Monitoring and Mitigation: Continuously observes traffic patterns and automatically mitigates attacks without user intervention.
Integration with Other Services: Combining DDoS Protection with services like WAF enhances overall security posture, offering layered defense mechanisms.

Network Security Groups (NSGs) function as virtual firewalls at the network layer, controlling traffic to and from Azure resources. They offer:

Layer 3 and 4 Filtering: Regulates inbound and outbound traffic based on IP addresses, ports, and protocols.
Association Flexibility: Can be linked to subnets or individual network interfaces, providing granular control over traffic flow.
Rule-Based Access Control: Utilizes security rules to explicitly allow or deny traffic, enhancing network segmentation and security.

Designing a Robust Security Architecture in Azure
To establish a secure and efficient network architecture in Azure, consider the following strategies:

Layered Security Approach: Implement multiple security services in tandem to address various threat vectors effectively.
Strategic Placement of Services:
- Azure Firewall: Deploy at the network perimeter to inspect and filter all traffic entering or leaving the virtual network.
- NSGs: Apply to specific subnets or network interfaces to control internal traffic between resources.
- WAF: Position in front of web applications to protect against application-layer attacks.
- DDoS Protection: Enable at the network level to safeguard against volumetric attacks aiming to disrupt service availability.
Regular Monitoring and Updates: Continuously monitor security logs and update rules and policies to adapt to evolving threats.
Compliance and Best Practices: Align security configurations with industry standards and organizational policies to ensure compliance and optimal protection.

By comprehensively understanding and appropriately implementing Azure's security services, organizations can construct a resilient network infrastructure that effectively mitigates potential threats and ensures the integrity and availability of their applications and data.

Optimizing Azure SQL Database Costs with Hyperscale Elastic Pools

Wed, 22 Jan 2025 21:00:00 GMT

In today's data-driven landscape, organizations often grapple with managing large-scale databases efficiently while keeping costs in check. Azure SQL Database offers a solution tailored for such scenarios: the Hyperscale service tier. This tier is particularly beneficial for applications requiring expansive storage without proportionally high compute resources

One key benefit of the Hyperscale service tier over the General Purpose or Business Critical tiers is the decoupling of storage from compute resources. In Hyperscale, storage can grow to much larger sizes without necessitating an increase in DTU or vCore levels. For example, databases in Elastic Pools may approach the 3 TB storage limit at their current vCore tier. While additional vCores would be required to extend storage capacity beyond this limit in traditional tiers, Hyperscale allows storage to scale independently, eliminating the need for increased compute resources solely for additional storage capacity

Understanding Hyperscale Elastic Pools
Elastic pools in Azure SQL Database allow multiple databases to share a set of resources, optimizing performance and cost. The Hyperscale service tier enhances this model by providing:

Massive Storage Capacity: Support for databases up to 128 TB, accommodating substantial data growth.
Independent Scaling: Decoupled compute and storage resources, enabling tailored performance configurations without unnecessary cost escalations.
Rapid Scaling and Restore: Quick adaptation to workload changes and swift backup operations, ensuring minimal downtime

Architecture
Traditionally, the architecture of a standalone Hyperscale database consists of three main independent components: Compute, Storage ("Page Servers"), and the log ("Log Service"). When you create an elastic pool for your Hyperscale databases, the databases within the pool share compute and log resources. Additionally, if you choose to configure high availability, then each high availability pool is created with an equivalent and independent set of compute and log resources.
The following describes the architecture of an elastic pool for Hyperscale databases:

A Hyperscale elastic pool consists of a primary pool that hosts primary Hyperscale databases and, if configured, up to four additional high-availability pools.
Primary Hyperscale databases hosted in the primary elastic pool share the SQL Server database engine (sqlservr.exe) compute process, vCores, memory, and SSD cache.
Configuring high availability for the primary pool creates additional high availability pools that contain read-only database replicas for the databases in the primary pool. Each primary pool can have a maximum of four high-availability replica pools. Each high-availability pool shares compute, SSD cache, and memory resources for all the secondary read-only databases in the pool.
Hyperscale databases in the primary elastic pool all share the same log service. Since databases in the high availability pools don't have a write workload, they don't utilize the log service.
Each Hyperscale database has its own set of page servers, and these page servers are shared between the primary database in the primary pool, and all secondary replica databases in the high availability pool.
Geo-replicated secondary Hyperscale databases can be placed inside another elastic pool.
Specifying ApplicationIntent=ReadOnly in your database connection string routes you to a read-only replica database in one of the high availability pools.

The diagram (in the top) shows the architecture of an elastic pool for Hyperscale databases

Cost Efficiency with Hyperscale
A notable advantage of the Hyperscale tier is its potential for significant cost reductions, especially for large databases with moderate compute demands:

Compute and Storage Decoupling: Unlike traditional tiers where storage size influences compute costs, Hyperscale allows independent scaling. This means you can allocate extensive storage without incurring high compute charges.
Real-World Savings: In practical scenarios, transitioning to Hyperscale has led to substantial savings. For instance, one of my customer experienced a 50% cost reduction by migrating to Hyperscale, benefiting from its flexible resource allocation.

Convert non-Hyperscale databases to Hyperscale elastic pools using PowerShell
You can use PowerShell commands to convert multiple General Purpose databases and add them to an existing Hyperscale elastic pool named hsep1. For example, the following sample script performs these steps:

Use the Get-AzSqlElasticPoolDatabase cmdlet to list all the databases in the General Purpose elastic pool named gpep1.
The Where-Object cmdlet filters the list to only those database names starting with gpepdb.
For each database, Set-AzSqlDatabase cmdlet starts a conversion. In this case, you're implicitly requesting a conversion to the Hyperscale service tier by specifying the target Hyperscale elastic pool named hsep1.
- The -AsJob parameter allows each of the Set-AzSqlDatabase requests to run in parallel. If you prefer to run the conversions one-by-one, you can remove the -AsJob parameter.

$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1" $dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | % {

Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName "hsep1" -AsJob }

Limitations
Consider the following limitations:

Changing an existing non-Hyperscale elastic pool to the Hyperscale edition isn't supported. The conversion section provides some alternatives you can use.
Changing the edition of a Hyperscale elastic pool to a non-Hyperscale edition isn't supported.
In order to "reverse migrate" an eligible database, which is in a Hyperscale elastic pool, it must first be removed from the Hyperscale elastic pool. The standalone Hyperscale database can then be "reverse migrated" to a General Purpose standalone database.
For the Hyperscale service tier, zone redundancy support can only be specified during database or elastic pool creation and can't be modified once the resource is provisioned. For more information, see Migrate Azure SQL Database to availability zone support.
Adding a named replica into a Hyperscale elastic pool isn't supported. Attempting to add a named replica of a Hyperscale database to a Hyperscale elastic pool results in an UnsupportedReplicationOperation error. Instead, create the named replica as a single Hyperscale database.

Seamless Migration and Flexibility
Migrating to the Hyperscale tier is designed to be straightforward:

Online Conversion: The process involves an initial data copy while the source database remains online, followed by a brief cutover period, minimizing downtime.
Reversibility: If Hyperscale doesn't align with your requirements, reverse migration to other service tiers is possible, offering operational flexibility

Key Considerations
When evaluating Hyperscale for your databases:

Workload Characteristics: Ideal for applications with large data volumes but moderate compute needs, such as archival systems or data warehouses.
Performance Requirements: Ensure that the performance metrics of Hyperscale align with your application's demands.
Cost-Benefit Analysis: Assess the potential savings against your current expenditure to determine the financial viability.

Conclusion
Azure SQL Database's Hyperscale tier offers a compelling solution for managing large databases cost-effectively. Its ability to independently scale compute and storage resources provides organizations with the flexibility to optimize performance without unnecessary expenses. By carefully considering your workload requirements and leveraging Hyperscale's features, you can achieve significant cost savings while maintaining operational efficiency.

Network Segmentation Strategy on Azure for Secure and Efficient Virtual Networks

Fri, 03 Jan 2025 21:00:00 GMT

Most customers I've encountered often approach Azure networking the same way they would with on-premises environments. For instance, they tend to create a dedicated VNet or subnet for each application, believing that this strategy will help organize their resources in the cloud

However, this approach can quickly lead to management complexity, unnecessary overhead, and an inability to fully leverage the scalability and flexibility that Azure provides. What many fail to realize is that networking in Azure—or in any cloud environment—is fundamentally different from on-premises network management.
In the cloud, resources are dynamically managed, and the network architecture should be designed with scalability, security, and flexibility in mind. Azure provides powerful tools that can help streamline network segmentation while ensuring that security is not compromised. In this post, we will explore a network segmentation strategy for Azure and how you can design efficient, secure, and scalable virtual networks.

Why Network Segmentation Matters
Network segmentation in Azure allows you to isolate different parts of your infrastructure for security, management, and performance reasons. By segmenting a network into smaller sub-networks, organizations can achieve:

Improved Security: Isolating sensitive systems or resources from the rest of the network reduces the attack surface and minimizes the risk of lateral movement in the case of a breach.
Optimized Performance: By controlling how traffic flows between segments, you can prioritize traffic for mission-critical applications and prevent congestion from non-essential resources.
Better Compliance: Segmentation enables you to apply specific compliance controls to different segments, such as isolating regulatory workloads or applying stricter monitoring to sensitive data systems.
Simplified Management: Network segmentation simplifies managing complex infrastructures by allowing you to apply specific policies and access controls based on the role of each segment.

Key Elements of Network Segmentation in Azure
Azure provides several key services that allow you to implement network segmentation and secure your virtual networks. Below are the main elements you should focus on when designing a segmentation strategy for Azure.

1. Virtual Networks (VNets)
Virtual Networks (VNets) are the foundation of any Azure network. A VNet provides a logically isolated network that allows you to securely connect Azure resources. By dividing your VNet into smaller segments, you can isolate traffic, control access, and apply specific policies to each segment.

Best practices for using VNets for segmentation:

Create multiple VNets for different environments (e.g., dev, test, production).
Use VNets to separate workloads with different security or performance requirements.
For multi-region or hybrid environments, ensure you properly design the connectivity between VNets.

2. Subnets
Within a VNet, subnets help divide the network into smaller, isolated blocks. Each subnet can be assigned its own Network Security Group (NSG) and Route Table to control traffic, making it easier to manage and secure different parts of the network.

Best practices for using subnets:

Separate critical workloads: Place mission-critical workloads in isolated subnets with strict NSG rules to limit access.
Utilize service-specific subnets: Consider creating subnets for specific services, such as Azure App Services, databases, or Kubernetes clusters.
Consider scalability: Plan for future growth by ensuring subnets are large enough to accommodate the resources you may add in the future.

3. Network Security Groups (NSGs)
NSGs are used to define inbound and outbound traffic rules at the subnet or network interface level. NSGs allow you to specify which IP addresses or ranges can access your resources, ensuring that only authorized traffic can flow between segments.

Best practices for using NSGs:

Use least privilege access by restricting traffic to only necessary ports and protocols.
Apply NSGs to each subnet to isolate traffic based on the workload's security requirements.
Regularly audit and update your NSG rules as part of a continuous security strategy.

4. Azure FirewallAzure Firewall is a managed, cloud-based network security service that provides centralized protection for your Azure VNets. It enables you to enforce security policies across all your network segments, providing a perimeter security layer that protects against threats.

Best practices for using Azure Firewall:

Use Azure Firewall as the central entry/exit point for network traffic to enforce security rules consistently across segments.
Leverage FQDN filtering, application rules, and threat intelligence to protect against malicious activities.
Enable Firewall Policy to streamline policy management for multiple VNets and subnets.

5. Private Endpoints
Azure Private Endpoints enable secure, private connections to Azure services over a VNet. By using private endpoints, you can ensure that services such as Azure Storage, Azure SQL Database, or Azure Key Vault are accessible only within your virtual network, adding an extra layer of security.

Best practices for using Private Endpoints:

Use Private Endpoints to limit access to services and ensure that sensitive data does not traverse the public internet.
Enable private DNS zones to facilitate seamless resolution of private endpoint addresses.
Use Azure Bastion for secure, private remote access to virtual machines within your network without exposing them to the public internet.

6. Azure Bastion
Azure Bastion provides secure and seamless RDP/SSH connectivity to your Azure virtual machines directly from the Azure portal without exposing your VMs to the public internet. It enhances security by eliminating the need for a public IP address on VMs.

Best practices for using Azure Bastion:

Use Azure Bastion for secure administrative access to virtual machines in segmented subnets, particularly in production or sensitive environments.
Ensure that Bastion hosts are deployed in a dedicated subnet with strict access control to prevent unauthorized access.

7. Virtual WAN (vWAN)
Azure Virtual WAN is a networking service that enables you to connect different VNets across regions and on-premises networks. It simplifies the management of large-scale network architectures and ensures secure communication between remote locations.

Best practices for using Azure vWAN:

Use Azure vWAN to simplify and centralize the management of multiple VNets and integrate them with on-premises networks securely.
Consider hub-and-spoke topology for better segmentation, where the central hub acts as the security and routing point for all traffic.

Best Practices for Network Segmentation on Azure

Segment by Function and Security Level: Group resources with similar functions and security requirements into separate subnets and VNets. For example, isolate the database subnet from the web application subnet and place critical systems in higher security zones.
Use Hub-and-Spoke Architecture: A hub-and-spoke model allows you to centralize connectivity, monitoring, and security in the hub while isolating the workloads in the spoke subnets. This design minimizes the attack surface and provides easy management of shared resources.
Leverage Network Peering and Service Endpoints: Use VNet Peering to securely connect VNets, enabling communication between isolated segments without exposing resources to the public internet. Utilize service endpoints to connect to Azure services securely from within a VNet.
Apply Zero Trust Principles: Implement Zero Trust network principles by assuming that every user and device, both internal and external, is untrusted. Ensure robust access control, encryption, and continuous monitoring.
Regularly Audit and Update Network Policies: Security is a continuous process. Regularly audit network segmentation, update NSG rules, and adjust Azure Firewall policies to respond to changing security threats and business needs.

Conclusion
Network segmentation is a critical strategy for enhancing both the security and efficiency of your Azure environment. By segmenting your virtual networks, applying strict access controls, and leveraging Azure's powerful networking tools, you can protect sensitive workloads, optimize traffic, and ensure your cloud infrastructure remains secure.
By following the best practices outlined above, you can build a highly secure, efficient, and scalable network architecture on Azure that supports your business needs while safeguarding your resources. Whether you're managing a hybrid environment, working with sensitive data, or simply need to streamline your network, Azure's segmentation tools provide the flexibility you need to succeed.

Terraform Ephemeral Resources

Sun, 01 Dec 2024 21:00:00 GMT

Terraform 1.10 introduced a groundbreaking concept called ephemeral resources. An ephemeral resource is not persisted to the state file. Take a moment to let that sink in!
Ephemeral resources address a long-standing issue: secret values being stored in the state file as plaintext. With ephemeral resources, your secrets are no longer at risk if the state file is compromised. This solution is particularly valuable for enhancing the security of sensitive data.

Initially, only a few providers support ephemeral resources. As of now, these include:

Microsoft Azure (azurerm):
- azurerm_key_vault_secret
- azurerm_key_vault_certificate
Kubernetes (kubernetes):
- kubernetes_token_request
- kubernetes_certificate_signing_request

This list is expected to expand over time.Declaring an Ephemeral ResourceEphemeral resources introduce a new root-level block in HCL: the ephemeral block. Its syntax resembles a regular resource block:

ephemeral "" "" {
# attributes, meta-arguments, nested blocks
}

ephemeral "" ""
{
# attributes, meta-arguments, nested blocks
}
Similar to normal resources, supported attributes and nested blocks vary based on the resource type.

Using an Ephemeral ResourceReferencing an ephemeral resource is analogous to referencing a data source. Such references use the ephemeral. prefix.
For example:

ephemeral "azurerm_key_vault_secret" "secret" {
# attributes
}
You can access its attributes using ephemeral.azurerm_key_vault_secret.secret..

Ephemeral resources can only be used in contexts where their values are not stored in the state file. Supported contexts include:

Other ephemeral resource blocks
Local values
Ephemeral variable and output blocks (discussed below)
Provider configurations within provider blocks
Provisioner and connection blocks in regular resources

These restrictions ensure the security and temporary nature of ephemeral resources. For example, referencing an ephemeral resource in a state-persisted context would defeat its purpose.
When used in local values, ephemeral references implicitly create ephemeral local values. You cannot explicitly declare ephemeral locals; they are only derived through ephemeral references.

Example: Using Ephemeral Resources

# Read secrets from AWS Secrets Manager
ephemeral "aws_secretsmanager_secret_version" "secret" {
secret_id = ""
}

locals {
# Decode the JSON secret value
credentials = jsondecode(ephemeral.aws_secretsmanager_secret_version.db.secret_string)
}

# Configure the PostgreSQL provider using the credentials
provider "postgresql" {
host = ""
port = 5432
username = local.credentials["username"]
password = local.credentials["password"]
}
In this example, the ephemeral resource aws_secretsmanager_secret_version retrieves a PostgreSQL database password. The password is JSON-decoded into a local value and used to configure the PostgreSQL provider—all without persisting the sensitive data in the state file.
Supported Meta-ArgumentsEphemeral resources support the following meta-arguments:

depends_on: Define explicit dependencies
count: Create multiple identical ephemeral resources
for_each: Create one ephemeral resource for each value in a set or map
provider: Use a provider alias
lifecycle: Hook into the resource lifecycle

However, ephemeral resources do not support the provisioner meta-argument—a best practice you should generally avoid anyway.

The Lifecycle of an Ephemeral ResourceEphemeral resources behave differently from regular resources and data sources. They are opened (or read) when Terraform needs their values and closed when those values are no longer required. The specifics of opening and closing depend on the resource type.
For instance, in HashiCorp Vault, opening a secret means obtaining a lease, and closing it means explicitly ending that lease. Most importantly, ephemeral resources ensure that their values are never stored in the state file.

Summary
Ephemeral resources, variables, and outputs are a powerful addition to Terraform. They eliminate the risk of sensitive values being stored as plaintext in the state file, addressing a long-standing security concern.
While the state file will still contain other sensitive information, such as a complete map of your infrastructure, ephemeral resources significantly reduce its sensitivity. By leveraging these new capabilities, you can build more secure and robust Terraform configurations.
Ephemeral resources mark a significant step forward in Terraform’s evolution, and their adoption is expected to grow rapidly in the coming years.