Cloud computing concepts, architectures, and multi-cloud strategies
View All Tags
I have been working on a comprehensive approach to bringing network automation and documentation into a development style workflow. Rather than replacing the traditional ITSM approach to change management it moves infrastructure towards a CI/CD approach to releases with automation and baked in documentation.
I have been playing around with enforza.io for a while and it's a great solution for low cost internet egress across AWS and Azure. The platform give an easy to manage low cost NVA which can be scaled out to cloud spokes to give consistent egress policy. As HA (High Availability) is crucial for any production environment, I wanted to investigate how easy it was to combine more than one enforza instance to achieve a highly available egress solution.
Adam Stuart has a rather excellent rundown of the various ways you can approach SD-WAN connectivity into Azure cloud, providing comprehensive technical guidance for Azure-based deployments. Much of the same applies in AWS although I have often said that AWS networking is more complex and akin to something dreamt up by a stoned developer who couldn't even spell BGP. One of the legacy options included at the end of Adam's article is the cloud edge topology where you deploy physical hardware into a carrier neutral facility (CNF) like Equinix and use that as an interconnect between your SD-WAN and an ExpressRoute or Direct Connect circuit. This got me thinking about the uncertainty many organisations face when deciding how their overall cloud connectivity should evolve.
This article explores the journey from simple single-site connectivity to sophisticated multi-cloud SD-WAN architectures, examining the trade-offs, and implications of each approach. We'll walk through real-world topologies that organisations I have worked with commonly implement, from basic VPN connections to cloud-native SD-WAN NVA hubs, helping you understand which approach might be right for your organisation's scale and maturity level.
The impending deadline of Azure IP armageddon is nearly upon us. In September a fairly major shift is taking place in Azure which will see a change to the default behaviour for outbound internet for Azure VMs. The change itself has been fairly well discussed but you can now get ahead of the curve with Azure Private Subnet and start building things as they will be after September.
The topic of documentation always comes up in tech and it's one that has had a lot of attention in world of software development which has led to some excellent solutions. In the world of infrastructure, however, the solutions have not been as readily available or adopted.
Most people think of Azure Public Load Balancer as that thing that spreads web traffic across multiple servers. Fair enough - that's what it does best. But it's actually a Swiss Army knife for network address translation that can solve some tricky connectivity problems you might not expect.
In my previous post, I shared some basic latency tests across Azure networks. The results were pretty predictable: the closer things are physically, the faster they communicate. Not exactly groundbreaking.
But when I expanded my testing to include longer distances and different connection methods, I stumbled onto something genuinely surprising: PrivateLink connections can actually be faster than direct VNET peering - sometimes significantly so.
When I set out to explore network latency in Azure, I had a simple goal: to understand how physical distance affects performance. After all, we've all heard that farther apart means slower connections. But I wanted specifics - exactly how much slower? And how consistent is that performance? I also wanted to see how long lived TCP connections performed across the Azure network.
I'm sharing what I've learned from my first round of tests, setting a baseline that we can build on later.
I like to point out to people that it's easier to train a network person on cloud than it is to train a cloud person on networks. It's a glib generalisation but it holds true for the most part because there is so much to networking that comes from history and quite a lot of grounding that a seasoned network engineer or architect will already understand. A big chunk of the AWS and Azure networking certification covers BGP and that's one of the reasons they are considered quite hard for some but quite easy for others. BGP is a topic that many very experienced network engineers in enterprise networking can get through their entire career without touching, but for those who operate at scale or work with MSP and telco networks it's bread and butter.
I've been exploring a pretty niche feature preview that you can find documented here. In some cases, you might want to expand the size of a subnet, but if you have a constrained IP space, you might not have contiguous space available. Here's what I've found you can do.
A little while ago I set out to find a way to measure the overhead that FQDN filtering places on HTTPS web traffic. I've shared the results here, but I thought I'd take the opportunity to discuss the methodology in a bit more detail.
I found an interesting little field hidden in plain sight in Microsoft documentation. A clever chap recently said this to me: 'if you can figure out what problem the engineers were trying to solve then it makes it easier to understand why the product works the way it does'.
When you create a VNet in Azure or a VPC in AWS, you need to allocate a CIDR range for your subnets. There are key differences between these cloud providers when expanding networks, which can create challenges. Knowing these rules from the start helps you plan your CIDR ranges better. I'll start with what's similar across AWS and Azure, then look at the differences.
I took a look at egress security a little while ago and advocated for the 'less is more' approach for most organisations due to the proliferation of VPCs and vNets and the risk of either having a very large amount of very expensive firewalls providing very little value or, perhaps worse, another pet in the form of centralised internet egress. But I think there may be another way.
Let's explore solutions for global site load balancing.
The reason I fell down the rabbit hole with regard to finding my public IP was because of a section in an old Azure networking book my friend was reading. It said:
To allow Azure internal communication between resources in Virtual Networks and Azure services, Azure assigns public IP addresses to VMs, which identifies them internally. Let's call these public IP addresses AzPIP (this is an unofficial abbreviation). You can check the Azure internal Public IP address bound to the VM with the command dig TXT short o-o.myaddr.google.com.
After 20+ years implementing network and cloud infrastructure across finance, retail, healthcare, and public sector, I've seen a clear pattern: cloud success strongly links to an organisation's readiness. Yet surprisingly few organisations do thorough readiness checks before starting their cloud journey.
I used to run a hosted Linux web server, which was great for stuff like all those weird little scripts and things I wanted to run 'always on'. After a while I put a few websites on it, and some websites for friends, and my little brother, and the local residents association, and next thing I knew I was running a load of instances of WordPress. I was also constantly fending off the advances of hackers who were forever finding exploits in the famously insecure blogging platform.
The Case for Application-Level Controls
I've noticed that an organisation's approach to securing outbound internet traffic often reflects its security maturity more than its technical requirements. System-to-system communication, such as API calls to cloud services, presents fundamentally different challenges compared to user browsing. Understanding these differences is crucial for implementing effective security controls without unnecessary complexity or risk.