Importance of Right Network Architecture vs Cost
An Architect, CTO, or technical decision-maker has a huge responsibility to approve and adopt the “right network architecture” that is aligned with the business requirement.
We have seen enterprises who picked the wrong or compromised network architecture and then paid the price, way more than the initial cost to build and run the network, in the long run.
Here we are sharing some nuggets for the technical decision-makers
- Bad architecture can cost you a lot in the long run. A lot more than what you have spent on building and running it
- Don’t make long term architecture decisions based on short-term problems
- Right architecture is more important than the feature set
- Simple architecture is the best architecture
Building architecture and putting a design is a one-time deal, but you end up running that design for years to come. As an architect, if you don’t make smart choices to build the correct architecture, your enterprise will be paying a lot more.
Also, think about support. You need a trusted and seasoned support partner working side by side when a problem arises.
Let me give you an example. Here is an architecture a customer wanted to go with.
This customer wanted to use Aviatrix Transit to build the encrypted transit peering within an AWS region, across multiple AWS regions and clouds (GCP). The customer also wanted to deploy AWS-TGW using Aviatrix Controller but just to attach the AWS-TGW with the AVX-Transit-GW.
Essentially all the red-lines in the topology above were to be controlled and managed by Aviatrix. For VPC1, VPC2, and so on, they wanted to do it manually. Thinking that it was just a one-time job.
In order to save few $$$, they wanted to make just one comprises in the architecture and I will explain how costly that one compromise could be in the long run
Customer did not want to use Aviatrix’s AWS-TGW Orchestration/Control to attach the Spoke VPCs with AWS-TGW
- Aviatrix Controller won’t be able to monitor and propagate existing and new routes
- Application VPC routes must be updated manually
- AWS-TGW route tables must be updates manually
- Transit VPC route table must be updated manually
- Customer will lose the Aviatrix Controller’s TGW Audit functionality
- This could be a huge operational burden on the team
- Customer will not be providing proper alerts about the route updates and warnings about incorrect or duplicate routes
- No network correctness
- In the future, if Aviatrix build a functionality where any new route update will require admin approval, then the customer might not be able to use that functionality
- Besides that, there are other functionalities that Aviatrix is planning to build for AWS-TGW and Aviatrix-TGW that probably won’t work in such a network design
- No way to do network segmentation for workloads in different VPCs
- No Security Domain functionality available
- Potential of AWS-TGW sprawl
- Multiple AWS-TGW might be needed for traffic separation
- Huge management overhead
- Some of the Aviatrix Flight-Path functionality might be broken in future
- In the future, if Aviatrix releases, capacity planning, and monitoring tools, that might not work in this type of architecture
- Adding the Firewall in the architecture will not be possible. This could be a huge compliance and security risk a customer would be taking for security-sensitive data
- For the User-VPN use-case, the customer must accommodate VPN subnets manually on TGW and Aviatrix Transit
- Aviatrix support won’t be able to solve and troubleshoot end-to-end because the VPCs were not attached by Aviatrix Controller
- Customer is taking the risk of not having end-to-end Encryption
- AWS-TGW does not provide encryption for Spoke VPCs
- This could be a moot point in this architecture because the customer decided to use AWS-TGW as an attachment but it is important to call out for compliance, audit, GDPR, and security reasons