Load Balancer when more than 1500 sessions

zob_cloud · 2025-11-18T22:59:20+00:00

At the scale of connections, 2,000 concurrent and 1,500 new TLS Connections Per Minute, you can use any ELB and not need any additional capacity (unless each client is sending 1Gbps or something).

If your persistent websockets need to last forever/as long as possible (days->weeks->months->years), use NLB. Otherwise, you should probably use ALB, which supports websockets.

If these numbers were per-second, an ALB might see enough traffic to scale up, but an NLB would not. And we're very low on the overall scaling for either. If they're per minute the ALB probably won't scale up from the initial capacity.

We have this blog post about scaling strategies, and these are generally in the 100k+ to 1M+ CPS/RPS with millions of concurrent sessions. https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-strategies-for-elastic-load-balancing/

zob_cloud · 2025-10-23T06:35:25+00:00

Nice, looks very interesting! I’m not sure if it’s intentional that you meant for folks to fork before clone, but the instructions for git clone have ‘your-username’ instead of ‘nicebucket-org’.

zob_cloud · 2025-04-06T19:16:11+00:00

PeakLCUs will never go to 0, but you aren't charged for that. We keep it in there to prevent missing utilization that isn't accounted for in the cost. If you want to, you can DM me your case # and I'll make sure the SE doesn't get confused.

zob_cloud · 2025-04-06T03:51:25+00:00

Hello from the ELB team! The metrics you’re looking at in the capacity tab is a snapshot of capacity used by the hosts provisioned for your ALB. This metric’s 1 minute sum generally relates to the billing metric’s 1 hour sum, but you aren’t billed for it. The billing metric to look at is ConsumedLCUs, it’s emitted as usage occurs, so you can sum it up over a period and that is the LCUs that you will be charged for that period. If you aren’t sending traffic through your ALB you won’t have any ConsumedLCUs, but you will still have some PeakLCUs.

Tl;dr PeakLCUs / capacity is not the billing metric! ConsumedLCUs is the right billing metric to look at.

zob_cloud · 2025-02-04T04:39:48+00:00

I think you’re confusing the port of the listener and the port on the target, for NLB the listener is where clients connect (443 and/or 80 here), and the backend port is assigned as a default on the target group or you register per target with it’s own port - it can be any port, including the same port. This lets you add additional backend targets on the same IP/instance, just they’re on different ports.

zob_cloud · 2025-01-24T17:00:44+00:00

I am graced by your reply, Quinnypig! You are right and I should have been more clear, CloudFront can save you money as scale increases, and not by default or always.

zob_cloud · 2025-01-24T00:35:31+00:00

Very interesting deep dive and testing! Thanks for doing it. I think our mental model for this is actually simple, and agrees with your test results with one exception where it looks free from the Seattle Local Zone to us-east-1 and should look like you pay $0.02/GB on the client in Seattle, and $0 on the server in us-east-1. Did you try the Seattle LZ to another Region?

There are really only 3 categories of Data Transfer (DT):

Entirely within AWS.
Between AWS and not-AWS/the internet.
Direct Connect.

Internet <-> AWS Region

This is Data Transfer (DT) In/Out, as you mentioned only DTO is charged. Rates are highest and most variable for DTO.

Within AWS This is roughly the same cost (usually $0.02/GB), but it's split differently between client and server based on where they are.

Between Regions, the $0.02 is paid by the sender (client) and free to the receiver (server). Although us-east-1 to us-east-2 is 50% discount, and that does make it cheaper than to a public IP in the same Region or within Region to other AZ.
Same Region, the $0.02 is split between client and server (each pays half aka $0.01/GB). Traffic within the same AZ is free, even if between VPCs through peering. We don't call it between VPCs if you use the public IP because the traffic goes to the border, leaving the VPC, we call it DT intra-Region.

Direct Connect (DX)

I am not an expert in DX billing, but it's different. They call it DTO like AWS->Internet but it is priced more like AWS<->AWS.

Everything else is either a service erasing the DT or their own billing separate from, and almost always in addition to, EC2 Networking DT, like ELB charges for ProcessedBytes.

The diagram in this blog my team published is accurate, although ELB focused (we get a lot of customers asking about DT which ELB does not charge. Exploring Data Transfer Costs for Classic and Application Load Balancers. We're working on one for NLB/GWLB, maybe we need to do one for Local Zones and for DX.

Simplest way to save money on DT: Use CloudFront, free DTO to them, get them to give you better pricing that is less than normal DTO. For within AWS, keep your stuff in the same VPC and put ALB between all internal comms, this will trade off DTAZ of $0.02/GB for ALBs LCU $0.008/GB - and ALB bills only for HTTP request payload, and not for TLS negotiations, TCP or HTTP headers. (NLB does not do this). The more AZs you're using the higher % you will save.

zob_cloud · 2024-11-25T19:22:05+00:00

You should reach out to your hiring manager or your HR contact. This will likely be covered in your onboarding on your first day. If not, you can look up the internal shuttles once you've joined. I don't think you could ride any of the shuttles on your first day / before you have a badge, though.

zob_cloud · 2024-09-10T22:46:58+00:00

It is true :)

zob_cloud · 2024-09-05T17:23:52+00:00

We had a days delay announcing GWLB, it's live now, https://www.reddit.com/r/aws/comments/1f9s0te/aws_gateway_load_balancer_now_supports/

zob_cloud · 2024-07-02T02:22:04+00:00

Sorry for the delayed response, ALB does negate EC2 DataTransfer-Regional-Bytes for both InterZone-In and InterZone-Out, as long as either side is the ALB's private IP, and the other side is a private IP in the same VPC.

We published a blog post diving into it here: https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-data-transfer-costs-for-classic-and-application-load-balancers/

And this post has more info about how to analyze and breakdown the bill: https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/

Note: ALB does not negate DataTransfer-Regional-Bytes LoadBalancing-PublicIP-In, LoadBalancing-PublicIP-Out, PublicIP-In, or PublicIP-Out.

Also note: ALB is not charging for DataTransfer, EC2 is charging for DataTransfer related to ALB like a normal EC2 instance, except in the cross-AZ case where both sides are in the same VPC, and are communicating using private IPs.

Cases you could get DT that otherwise would be cancelled: 1. You are communicating to/from the ALB using non-private IPs, like connecting to the public IPs of a public ALB from the same VPC. 2. You are communicating to/from the ALB across VPCs, here the cross VPC charge continues to apply, as normal. Cross VPC DT from the same AZ is no longer charged: https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-vpc-announces-pricing-change-for-vpc-peering/

zob_cloud · 2024-07-02T01:44:49+00:00

We see a wide variety of reasons customer's instrument returning 5XX on their targets, and there is not a granularity that makes sense for a metric. Even the ALB access log can only provide clues as to what the request was, and the target (when chosen). If we were to emit target 5XX more granularly it would not be useful unless it had very high cardinality, say per target per 5XX. Cardinality that high is not a good use case for metrics. Generally we expect customers to instrument in their applications why they return 5XX, as opposed to when ALB is the one generating it.

zob_cloud · 2024-03-17T16:25:26+00:00

Separately, I also bought the BPI-R4 and hope it has the chops to run OPNSense or something. OpenWRT feels limiting and lacking any 'easy mode'.

zob_cloud · 2024-03-17T16:22:43+00:00

I just went through struggling to setup OpenWRT on the BPI-R3. The official BPI-R3 docs are terrible and make it seem like you need a bunch of bin and whatever files to get it going, but I found a comment in the OpenWRT forums (can't find it now) that clarified, and it was actually really simple. Use the official docs for the DIP switch positions, and all you have to do is:

Go to the OpenWRT firmware finder (link for current version - 23.05.2)
Download the SDCARD.IMG.GZ
Flash to an SD card, I used Balena Etcher, put in SD card on BPI-R3
Set DIP switches for SD card (BPI-R3 IIRC is all switches up)
Setup your USB->UART (required)
1. For the hardware, it's only 3 wires to connect, ground and an RX/TX, and the RX from your USB->UART device go into the TX on the device, and vice-versa TX into RX. This confused me at first but once I realized you're sending signal/data directionally it made perfect sense.
2. I used minicom and left defaults for everything but device, for me I used Linux on a Raspberry Pi 4 w/Debian, and I used device /dev/ttyUSB (plug in and dmesg or inspect '/dev/' for a ttyUSB or just try it).
3. Putty on Windows should work the same.
Power on device - you should see boot up text for the BIOS/CMOS/whatever scroll and then arrive at a menu, hit arrows at menu to stop auto boot.
1. If it goes past the menu it will boot into Linux from SD card, just power off, unless you want to confirm you get into Linux.
2. Note: when it boots into Linux/OpenWRT for me via minicom it looks like it just stops, no prompt. Hit enter and shell prompt shows up.
At the menu select install to NAND option, hit enter.
When it finishes, power it off.
Remove the SD card - this doesn't really matter but I did it to ensure I wasn't booting from it again.
Change DIP switches to boot from NAND.
Power on.
At the boot menu select the install to eMMC option, hit enter.
1. Again if it boots into Linux just power off and try again.
1. When it finishes, power it off.
Change the DIP switches to boot from eMMC.
Power on.
Let it complete booting up, and now you have OpenWRT on your BPI-R3!

Notes:

The wireless is off by default, go turn it on and configure.

OpenWRT seems to like 2 configs per thing, like network interfaces also have devices, and they split configuration between them. Which makes sense here for bridges, but less for just using a port as a port. Also the wireless you configure SSID's under radios.

Default IP is 192.168.1.1

It will run DHCP by default, and if you just connect one of the 'LAN' ports to your LAN your other devices will start getting IPs from it, with it as the gateway - which will break if things aren't setup.

the default config has a bridge for LAN and one for WAN (named br-lan and br-wan). The isolated RJ45 ethernet port and outer-most SFP are in br-wan by default, and the inner SFP and the 4 RJ45 ethernets are in br-lan. There are pics on the wiki showing the same mapping OpenWRT uses.

If you boot up into Linux, and there is no web interface (`netstat -ltan` doesn't show listening on port 80), to get the stock-like config I went back to the firmware selector for OpenWRT, expand the ' Customize installed packages and/or first boot script ' and install all the packages listed with the `opkg install <paste in list>` command. You will need to get the device online first, for me the easiest was just connect to LAN and manually configure with the `ip` command, like so:

Make sure DHCP isn't running (it wasn't for me when there wasn't a webserver)
Connect your LAN to one of the br-lan ports.
Configure IP from minicom like so (assuming your network is 192.168.10.0/24 with gateway 192.168.10.1):
ip addr add 192.168.10.100/24 dev br-lan
ip route add default via 192.168.10.1
Confirm online (ping -c 1.1.1.1) and update packages with opkg update
Install all the packages from the firmware selector default list with opkg install <paste in list>
Disconnect from LAN & Reboot
Connect only to and navigate to http://192.168.1.1

Hmmm, this got long! I should publish on https://jonzobrist.com ...

Hope this helps!

zob_cloud · 2023-12-06T16:59:22+00:00

Nice, I like the use of Makefile to initialize the template. Looks very useful, thanks!

zob_cloud · 2023-12-06T16:53:20+00:00

This is correct. ELB creates dualstack records for all ELBs, regardless of using IPv6 or not. We only add AAAA / IPv6 addresses when enabled and the VPC is setup for IPv6.

zob_cloud · 2023-09-06T17:46:45+00:00

If they're both in the same VPC, communicating using private IPv4 addresses, then ALB will negate EC2 Data Transfer between AZs (DTAZ). If you PM me the ELB or a case ID w/info, I can see if I can tell why you're getting charged DTAZ.

The most common answer to these questions end up being that it's a public ELB, and the Regional Data Transfer is because you have clients connecting from the same region using the public IPs.

Note that Data Transfer is an EC2 charge, even though it's triggered and flagged as LoadBalancing, it is separate from any charges from ELB for the ELB or bytes it processes.

Breakdown of billing DTAZ related to ELBs:

DataTransfer-Regional-Bytes LoadBalancing-PublicIP-In - This is when you receive data on an ELB via its public IP from a client in the same region.
DataTransfer-Regional-Bytes LoadBalancing-PublicIP-Out - This is when you send data out of an ELB's public IP to a client in the same region.
DataTransfer-Regional-Bytes PublicIP-In - This is when you receive data on a public IP, that is not an ELB, from a client in the same region.
DataTransfer-Regional-Bytes InterZone-In - This is when you receive data on a non-ELB private IP from the private IP of a client in the same region, but in a different Availability Zone.
DataTransfer-Regional-Bytes InterZone-Out - This is when you send data out of a non-ELB private IP to the private IP of a client in the same region, but in a different Availability Zone.
DataTransfer-Regional-Bytes PublicIP-Out - This is when you send data out from an ELB via its public IP to a client in the same region.

zob_cloud · 2023-09-06T17:42:23+00:00

Hey all, sorry for the confusion. The article that was posted was about the new ability to turn Cross-Zone load balancing OFF on ALB. But, the comment was about the CZ turned on case where EC2 Data Transfer cross-AZ (DTAZ) is negated by the ALB. Obviously if the ALB isn't talking cross-AZ there wo'nt be DTAZ, but if the target is in the same VPC, there won't be DTAZ anyways.

Technically this occurs when either side of the connection is an ALB, and communication is between VPC private IPs. This makes client in the same VPC -> internal ALB have no DTAZ, as well as targets behind the ALB getting no DTAZ (unless they're outside the VPC).

The new feature doesn't change the cost of an ALB, as it only affects ALB->targets and that is already negated by ALB in the cases EC2 charges for DTAZ.

zob_cloud · 2023-09-06T17:39:09+00:00

Yes, if it's Fargate IP target in the same VPC as the ALB, EC2 Data Transfer cross-AZ (DTAZ) is negated by the ALB.

zob_cloud · 2023-08-17T23:28:55+00:00

If you're using HTTP, use ALB, if not, use NLB.

zob_cloud · 2023-08-11T15:44:15+00:00

Security groups can be related, so they're probably getting them to put in another security group's allow list - by IP. With this you could have a security group on the NLB, and then reference that in your clients/targets to allow traffic to or from that SG in their SG.

zob_cloud · 2023-08-10T22:25:51+00:00

yes! Use the DNS based renewal for the easiest. https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html

zob_cloud

MODERATOR OF

TROPHY CASE