Author Andy Mahy | B2Bi Managing Consultant
Deployment Models for B2B Integrations on AKS
Running a B2B integration platform such as B2Bi or SFG on Azure Kubernetes Service (AKS) opens up a lot of flexibility, but the architecture you choose has a big impact on security, performance, and how much effort is needed to run it day to day. There’s no single “right” design. Instead, there are a few common deployment patterns, each with advantages and drawbacks depending on your priorities.
Separate Clusters for DMZ and Application Layer
One option is to deploy two AKS clusters inside the same VNET. The first cluster handles the DMZ functions such as Sterling Secure Proxy and Perimeter Servers. The second cluster is for the core application layer: B2Bi engines, adapters, APIs, Control Center, and so on.
With both clusters stretched across multiple availability zones, this design gives strong resilience. It also helps satisfy compliance teams by showing a clear split between what faces the outside world and what sits inside the business network.
On the technical side, Azure Load Balancers or Application Gateways handle inbound traffic, while a NAT Gateway secures outbound traffic. Premium Azure Files with zone-redundant storage is usually required, since multiple pods across zones need to share data. A key consideration here is latency: database and MQ connections must stay under 10ms, so they should be placed as close as possible to the application cluster.
The benefit is strong separation and high availability. The trade-off is cost and complexity—two clusters mean double the work for patching, upgrades, scaling, and monitoring. Some auditors may still argue that a shared VNET is not strict enough isolation.
Separate Clusters in Separate VNETs
If you need the strongest possible isolation, the next step is to put each cluster into its own VNET. The DMZ and application environments can then be connected with VNET peering or a NAT gateway.
This model is often paired with a hub-and-spoke design, where shared services such as Active Directory or logging live in the hub and the DMZ/Application clusters sit in separate spokes. Peering ensures traffic stays private, but it does still directly link the networks, which may raise compliance questions.
The pros are obvious: maximum isolation, independent management of each cluster, and the flexibility to enforce completely different scaling or security policies. But this comes with the highest cost, not only in infrastructure but also in operational effort. You’ll need separate CI/CD pipelines, monitoring stacks, RBAC policies, and secrets management. Network routing also becomes more complex, and latency must be carefully controlled to keep DB access below the 10ms requirement.
Single Cluster, Separate Namespaces
At the other end of the spectrum, you can keep everything in one AKS cluster and separate the DMZ and application workloads by namespaces. This is simple to manage and cost-effective, but it relies heavily on Kubernetes features like NetworkPolicies and RBAC to keep things properly isolated.
In AKS, Calico or Cilium is often used to enforce namespace-level network rules. It works, but there’s still only one control plane and one set of nodes. Any cluster-wide change—an upgrade, a patch, or even a misconfigured policy—affects all namespaces. The Word doc also highlights that mixing production and non-production namespaces in one cluster is a poor practice, because you can’t test cluster-level changes safely without risking production.
The upside is low overhead and fast scaling. The downside is that the isolation is weak, and in highly regulated industries it will almost certainly not pass security reviews.
Single Cluster with Separate Subnets or Node Pools
This model keeps one cluster but introduces more physical separation by running DMZ and App workloads on different node pools or subnets.
With AKS, node pools can be tailored for the workload. DMZ nodes might be lightweight, while the App nodes can be compute-optimised (for example F-series VMs) to handle transformation-heavy processing. Kubernetes taints and tolerations are used to make sure pods only land on their assigned node pools. At the Azure level, Network Security Groups can enforce subnet-level firewall rules. You can also bring in Azure Firewall or a Web Application Firewall to strengthen ingress and egress.
This design avoids the heavy overhead of running two full clusters but gives stronger isolation than just namespaces. It’s easier to scale each side independently, too. The compromises are that the control plane is still shared, and costs can rise if node pools are over-provisioned to meet peaks. It also requires careful configuration of NSGs and pod scheduling rules.
Single Cluster, Single Subnet
Finally, there’s the simplest deployment: a single cluster and a single subnet where all workloads run together. Security in this case depends entirely on Kubernetes network policies and Azure NSGs.
By default AKS allows unrestricted outbound traffic, which means you’ll likely need an Azure Firewall if you want proper control and protection against data exfiltration. Monitoring also becomes critical, using tools like Azure Network Watcher and container network observability to spot misconfigurations or leaks.
The appeal is obvious: one cluster, one subnet, very little overhead. It’s cheap and quick to spin up. But the lack of isolation makes it unsuitable for sensitive production systems. It’s fine for development, testing, or small-scale environments, but risky for anything else.
Final Thoughts
These patterns form a spectrum between maximum isolation and minimum management overhead.
- Two clusters in separate VNETs give the strongest separation but are costly and complex.
- A single cluster with split node pools or subnets offers a practical middle ground.
- Namespaces or a single-subnet model are the cheapest and simplest, but not secure enough for serious production use.
In making the choice, think about compliance requirements, latency constraints, operational maturity, and budget. A few constants always apply: keep database latency under 10ms, use Premium Azure Files with ZRS for storage, avoid burstable node types in production, and control egress traffic with an Azure Firewall.
Related Articles
