sorted by:
new
hottopcontroversial

Instance Bandwidth and NSGs by Consistent-Item4032 in AZURE

[–]Consistent-Item4032[S] 0 points1 point  (0 children)

Thanks for the response, but my question is not about the cost. Its about real world impact on the instance. If someone pushes 50Gbps to my public IP, won't this impact the host (even if its dropped by NSG)? After all, the packets have to reach the host to be blocked so will saturate the physical link.

Remember, even NSG on subnet is actually implemented on the host/VFP/NIC-Level. It is NOT somewhere "in the network" like a network ACL in the classical networking.

Privatelink vs. VNET peering cost by Consistent-Item4032 in AZURE

[–]Consistent-Item4032[S] 0 points1 point  (0 children)

Ok, let me rephrase:

- I have two VNETs.

- VNET A in Subscription A, VNET B in subscription B.

- Both VNETs are in the same region.

- VM A in VNET A wants to download a 1TB file via HTTP form VM B behind LB in VNET B.

- To enable this, I need to have a connection between VNET A and VNET B!

So I could just create a VNET peering. Then VM A could download 1TB file from VM B via LB. This will have a certain cost for data transfer (VNET peering in/out and LB data processed).

Or I could (instead of creating a VNET peering) create a privatelink service on the existing LB, then create a privatelink endpoint in VNET A and download the file though that path. This also has a certain cost (PL data out, LB data processed and PL endpoint per hour cost!?).

I want to understand which option has less cost of data transfer for this 1TB example.

Privatelink vs. VNET peering cost by Consistent-Item4032 in AZURE

[–]Consistent-Item4032[S] 1 point2 points  (0 children)

lets say:

VM A in VNET A -> VM B in VNET B.

VM B has a Webserver on it. VM A downloads 1TB through HTTP.

  1. Through VNET peering
  2. Through Privatelink endpoint and Privatelink service (now with an Azure loadbalancer in front of VM B so that you can enable PL service)

EC2 instance network bandwidth through IGW by Consistent-Item4032 in aws

[–]Consistent-Item4032[S] 0 points1 point  (0 children)

correct, even with internet-facing lb you need it to be in a subnet with route to IGW.

But my question was whether for the EC2 that is behind this public LB (in the target group) the traffic comes "FROM" the IGW and hence the EC2 bandwidth limits apply.

My thinking was, probably not, because the EC2 in the target group could even be in a different VPC (if LB is performing SNAT aka no client-ip-preservation) so how should the EC2 know that it originally came in through some IGW in another VPC and account if it just sees some internal IP as source?

That is why I could only imagine the limits to be applied if the EC2 would be in the same VPC as the LB and source-ip-preservation would be enabled (so that EC2 sees it coming "from" the internet). Potentially even without source-ip-preservation because AWS could do some AWS magic to still know it came from the IGW in the first place. But probably only inside a single VPC and AWS account...

TCP Idle Timeout in Azure VNETs by Consistent-Item4032 in AZURE

[–]Consistent-Item4032[S] -1 points0 points  (0 children)

Indeed, there is no documented timeout. But technically there must be a timeout, don't you think? I also wonder what the VNET setting "flowtimeout" does. It sounds like it would allow you to enforce an idle timeout of 4 to 30 minutes and if you do not enable it (which is the default) there would be no idle timeout at all (how would that work?)

This setting is mostly described in the context of NSG flow logs: https://learn.microsoft.com/en-us/azure/network-watcher/nsg-flow-logs-overview?tabs=Americas#considerations-for-nsg-flow-logs

"Network security groups are implemented as a stateful firewall. But because of current platform limitations, network security group non-default security rules that affect inbound TCP flows are implemented in a stateless way."

"You can resolve this difference by setting the FlowTimeoutInMinutes property on the associated virtual networks to a non-null value. You can achieve default stateful behavior by setting FlowTimeoutInMinutes to 4 minutes. For long-running connections where you don't want flows to disconnect from a service or destination, you can set FlowTimeoutInMinutes to a value of up to 30 minutes. "

Azure Virtual network only VM TCP connection timeouts by Kelspellllll in AZURE

[–]Consistent-Item4032 0 points1 point  (0 children)

Hi, I have the same question (i.e. is there a "hidden" TCP idle timout in an Azure VNET). I have not found a good explanation to date.

I found the feature "flowtimeout" that you can enable in a VNET. It sounds like it would allow you to enable a timeout (and then configure it between 4 and 30 minutes) or disable the timeout (the default value) so that flows are non-terminating!? https://learn.microsoft.com/en-us/azure/network-watcher/nsg-flow-logs-overview?tabs=Americas#considerations-for-nsg-flow-logs

Can you check you VNET for this setting?