AKS ACR Private Endpoint Terraform – Secure Azure Networking

VNet, ACR, Private DNS, and Intent-Driven Networking with Terraform

AKS ACR Private Endpoint Terraform is a common requirement when securing container image. Designing an Azure Virtual Network is rarely just about “connecting things together”.
Once you introduce AKS, Azure Container Registry, and Private Endpoints, networking becomes a first-class architectural concern — not an implementation detail.

In this article, we’ll walk through a real-world Azure networking scenario:

AKS deployed into a dedicated subnet
Azure Container Registry exposed only via Private Endpoint
Name resolution handled through Azure Private DNS
All resources provisioned using Terraform, following an intent-driven, modular design

This example is based on the FoggyKitchen Terraform VNet module and demonstrates how networking decisions made early directly affect security, scalability, and operational clarity later.

📐 Design notes

The short video below focuses on the architectural intent behind AKS + ACR private integration. It explains why network boundaries, DNS discipline, and explicit trust paths must be designed *before* workload placement, scaling, or automation. This design-level discussion complements the hands-on Terraform implementation described below.

Why AKS + ACR changes your VNet design

A very common AKS journey looks like this:

Create a VNet
Add a subnet for AKS
Attach an ACR
Everything works — until security requirements appear

At that point, teams realize they need:

Private access to ACR
No public internet exposure
Predictable DNS resolution
Clear separation of responsibilities inside the VNet

This is where ad-hoc subnet design breaks down.

From raw Terraform resources to intent-driven modules

If you’re just starting with Azure networking, defining VNets and subnets using raw Terraform resources is a perfectly valid learning path.

I’ve previously covered this foundational approach step by step in a separate article:

👉 Azure VNet with Terraform – A Practical Introduction (without modules)
https://foggykitchen.com/2025/07/22/azure-vnet-terraform/

That article focuses on:

azurerm_virtual_network
azurerm_subnet
understanding address spaces and basic layout

It’s an excellent starting point — but it doesn’t scale well once Private Endpoints, AKS, and multiple services enter the picture.

Building on the module-based VNet design

This article assumes you’re already familiar with a module-based VNet approach, where:

subnet purpose is explicit
address spaces are intentional
future workloads are anticipated

That design is explained in detail here:

👉 Designing Azure VNets with Purpose-Driven Subnets (Terraform Modules Explained)

The current example builds directly on that foundation.

The target architecture

At a high level, the deployment consists of:

VNet: fk-vnet-aks (10.10.0.0/16)
AKS subnet: fk-subnet-aks (10.10.8.0/22)
Private Endpoint subnet: fk-subnet-private-endpoints (10.10.20.0/24)
Azure Container Registry fkacrprivate with Private Endpoint fk-acr-pe
Private DNS Zone: privatelink.azurecr.io

The diagram shows two critical flows:

Data plane: AKS nodes pulling container images via the Private Endpoint
Control plane: DNS resolution handled through Azure Private DNS linked to the VNet

Figure 1. AKS pulling images from ACR via Private Endpoint inside a single Azure VNet

Why Private Endpoints deserve a dedicated subnet

Private Endpoints are not “just another NIC”.

They:

create network interfaces inside your VNet
require predictable IP addressing
benefit from isolation and clarity

That’s why the design uses a dedicated subnet for Private Endpoints, instead of mixing them with AKS or application workloads.

This decision pays off later when:

more private services are added
routing and NSGs become more complex
troubleshooting DNS vs networking issues

Private DNS: the often-missed piece

Creating a Private Endpoint alone is not enough.

Without proper DNS:

AKS will still resolve ACR to a public endpoint
image pulls will fail or go over the internet
debugging becomes painful

In this setup:

a Private DNS Zone (privatelink.azurecr.io) is created
the VNet is linked to the zone
A records are automatically created for the ACR private endpoint

This ensures that:

fkacrprivate.azurecr.io → private IP inside the VNet

Verification in Azure Portal

The screenshots below are not meant to be a step-by-step guide. Their purpose is to confirm the architectural intent behind the Terraform configuration.

They demonstrate that:

the Private DNS zone (privatelink.azurecr.io) exists
the VNet is explicitly linked to that zone
A records are automatically created for the ACR private endpoint
DNS resolution is scoped correctly to the VNet where AKS runs

In other words:

when AKS resolves fkacrprivate.azurecr.io,
it receives a private IP address inside the VNet, not a public one.

This is the critical condition that allows AKS to pull container images without any public network exposure.

Figure 2.Virtual Network link attached to the Private DNS zone

Figure 3. DNS A records created for the ACR private endpoint

Terraform perspective: clarity over cleverness

What’s intentionally not shown in detail here:

full Terraform code listings
every variable and output
step-by-step AKS creation

That material belongs in courses, not blog posts.

Instead, the goal of this article is to show:

why the network is shaped this way
how Private Endpoints affect design
where DNS fits into the picture

The actual implementation lives in the FoggyKitchen example repository:

👉 https://github.com/foggykitchen/terraform-az-fk-vnet/tree/main/examples/04-vnet-private-endpoints

Does this blog give away future course content?

Short answer: no — and deliberately so.

This article:

explains architectural intent
shows relationships between components
builds mental models

It does not:

replace hands-on labs
walk through AKS internals
teach advanced troubleshooting
cover production-grade variations

Future courses (AKS Advanced, Azure Flagship, Networking modules) will go much deeper — including:

multiple node pools
private AKS API servers
UDRs and advanced routing
real-world failure scenarios

This blog prepares the ground — it doesn’t harvest the crop.

Where this fits in the FoggyKitchen learning path

If you’re building your Azure skills incrementally:

Azure VNet with Terraform (raw resources)
Azure VNet Terraform Module (intent-driven design)
AKS + ACR with Private Endpoints (this article)
AKS Fundamentals with Terraform / OpenTofu (hands-on)

👉 Start with AKS Fundamentals
Learn how AKS actually consumes this network design in practice.

From Network Design to Real AKS Workloads

In this article, you’ve seen how to design an Azure VNet that supports private AKS clusters, ACR access via Private Endpoints, and scoped DNS resolution.

In AKS Fundamentals with Terraform / OpenTofu, you’ll see how AKS actually uses this network design in practice — from cluster creation to pulling images from a private registry, step by step and hands-on.

🔒 Lifetime • ⏱️ Self-paced • 🧪 Real labs