Description

How we proceed with cloud main connectivity depends on a discussion with SSC. In particular, we need to know (1) does our AAW hub IP /16 range / AAW AKS /16 IP range conflict with any cloud main IP ranges? (2) if "yes", what is the risk of peering anyway? (E.g. if there's a very small overlap with low risk, then it may still be worth peering.)

If there is overlap and the risk is high, then the recommendation of the cloud networking team was to re IP the aaw hub VNET and re IP the cloud-main-system subnet. Both new IP ranges would be assigned to us by cloud networking team.

Depending on the resolution above, the solution might be to peer AKS VNET directly with cloud main internal hub, in which case traffic through the egress gateway doesn't need to first pass through the AAW hub firewall. Alternatively, it could be that the Hub vnet gets peered with the cloud main internal hub, with the understanding that egress to cloud main only goes through the egress gateway so that the source IP of incoming traffic is from the cloud-main-system subnet (assigned to us by cloud networking team).

Note: it was confirmed that we cannot implement NAT rules through Azure firewall if the traffic is not outbound to the internet. In this case, we're communicating between two private networks, so network address translation is not possible.

Note: the scope of the above solution is only communication with cloud main services; communicating with on-prem services is out of scope for this proposal.

StatCan / aaw

Figure out next steps for cloud main connectivity #1323

Description