Hi Everyone, We are currently having a aws network setup made up of transit gateways. I thought of moving that to AWS WAN, completely without transit gateways. 1.Will there be any cons by moving to WAN 2.Cost is one of our main concern, when thinking of shield and waf in each region in inspection segment/NFG having separate shield/Waf(advanced shield) seems costly is there any way to handle these security thing globally rather than regionally

How large is the nw? How many tgws? We moved and reduced a lot of complexity and the nw is much simpler now. With oy a few tgws it may not be worth. On the second item not sure what you are asking as it depends on your ingress architecture and ingress endpoints.

Currently we are having 9 transit gateways. Second thing is like for north south ingress/egress inspection. Is there any good ways than having a same inspection VPC and same security resources in each region. Or having that kind of security structure is ideal.

Ok. That may make sense for migration to vwan. There are some limitations if you have direct connect etc. For ingress, egress inspection there are a few patterns for centralized inspection vpc. I can share some high level patterns for the migration and inspection architecture. Share your email id. I can share patterns I worked on recently.

Thank you so much, Email - vinusan129@gmail.com

Hi @Vinusan Uruththiramoorthy, I had flagged your message but didn’t have the change to reply yet. On my previous project, I’ve helped my client to migrate from their multi-region transit gateway and hybrid flat network (AWS and Cisco SDWAN) to a multi-region hybrid segmented network using AWS CloudWAN and Cisco SDWAN. Cisco SDWAN connected the company’s on-premise locations with Direct Connects and VPN Site-to-Site tunneling a multiple regions across the globe. There was no network segmentation and Transit Gateways in those regions were peered and used to interconnect VPCs whereas some traffic was routed through on-premise firewall for inspection. The whole stack, as with many network implementations, was 80% manual effort which is why we wanted to address a few things: • Avoid the usage of VPC peering connections (which still existed even though we had TGW too) • Avoid backhauling traffic to on-premise firewalls • Benefit from dynamic route propagation • Introduce network segmentation • Introduce clear north/south and east/west traffic inspection strategies • ... We ended up with setting up AWS IPAM (which we didn’t use before), allocated a new empty cloud range that could serve for net-new networking and designed a concept of global pool, zone pools, region pools and custom pools. This would allow us to re-route traffic for a given region, a given zone or a given specific range if we want to. Our 3-region implementation contains an

egress

VPC with an AWS network firewall for north/south, an

inspection

VPC with an AWS network firewall for east/west and the Global/Core network (a.k.a. CloudWAN) with 5 main segments (

nonprod

,

shared

,

prod

,

inspection

and

sdwan

) whereas VPC’s would be associated with either

nonprod

,

shared

or

prod

and on-premise networks with

sdwan

and whereas the

inspection

segment is where the post-inspected traffic would land. With the custom pool concept in IPAM and some static route provisioning we were able to seamlessly migrate existing network ranges into this. Everything from the first to the last resource is fully managed by IaC (Terraform) and at some point build up to a 1,000 resources. A blogpost was launched by AWS about our implementation but pulled offline due to concerns from the company about exposing to much internal details. Happy to address any questions you might have for your setup !