Firewall Architecture in the Cloud
In my last blog, I explained why you need a firewall in the cloud. Now, let’s talk about the how. Typically, customers have two different deployment models of their cloud network infrastructure: the flat VNet/VPC and then the hub and spoke model (most network engineers will recognize this model, shout out to DMVPN). There is this concept of the “Landing Zone,” which is more a framework than a thing. A good landing zone will pay for itself as you scale out your cloud environment, as it allows you to add workloads in a modular approach. If you find that you have to re-invent the wheel each time you move a workload to the cloud, then take that as a sign. It is time to evaluate your landing zone.
Below, you’ll find an example of the two architectures mentioned with a few pros and cons for each.
NOTE: I will use Azure for these examples, but the same principles apply to any cloud.
Flat VNet/VPC
|
PROS |
CONS |
|
Easier to manage (at first), friendlier to ClickOps |
Very prone to misconfiguration |
|
|
Blast radius for network changes/state file is the entire cloud footprint rather than the specific prefix (VNet/VPC) |
|
|
Prone to finding limitations for different clouds for single VNet/VPC |
|
|
As the environment grows larger, the management overhead multiplies drastically |
|
|
Very hard to achieve macrosegmentation |
Hub and Spoke
| PROS | CONS |
| Once landing zone is set up, workloads become modular deployments and very rarely require any changes to the hub | More expensive due to peering. Not much, but enough to call out |
|
The blast radius for network changes/state file is the VNet/VPC the changes are being conducted in |
More complex than flat architectures |
|
Bypasses most VNet/VPC limitations since you will deploy a new VNet/VPC for each workload and life cycle |
|
|
Macro segmentation by workload very achievable |
|
|
Resource organization becomes easier with very defined silos for resources |
|
Conclusion
At this point, there are probably two reactions:
- That looks just like what we have deployed… Is that what we need?
- I’m not in the cloud yet, can this guy just tell me which architecture I should deploy?
The answer to both of those questions are the words that any executive hates: “It depends.” There are some very key factors in what architecture you should deploy and follow. Some of those factors include (not in any particular order):
- What size is the team that will be administering the environment?
- What are the plans for workloads going into the cloud? (Is there a target workload for the near future? Or is the organization going cloud first?)
- What SLAs are expected for the workloads that are being migrated to the cloud?
- What skillset does the organization have?
- Are there any compliance requirements for the workloads?
There are plenty more, but this is an example of what we at ivision help customers map out when planning a cloud journey. It is important to have a clear vision and a defined North Star for this journey. If not, the moment you realize the vision is gone is typically when the cloud bill is outrageous and there aren’t a lot of answers as to why it is so expensive.
Interested in consulting ivision for your cloud needs? Check out our current cloud capabilities or reach out to get started today.
