This article is an English translation of the Japanese edition.
Consider what to do if the "$0.005 per In-use public IPv4 address per hour" statement is too high I discussed one of the measures described in the "Aggregating ALBs using host-based routing" section of the report.
It is easy to come up with the advantages, but when it comes to the disadvantages, there are some areas that I have not thought of, so I have tried to sort them out while communicating with support.
I hope this will be helpful to you when you consider ALB consolidation as a way to reduce costs.
Constraints Perspective
ALB deployments must be on the same subnet
This is the biggest constraint when consolidating systems that are already configured. When considering adding new services to an existing ALB, the size of the subnet should also be a concern. (Addresses may be scarce for configurations that scale out)
Possible violation of service quotas
The service quotas listed in the linked document include the following, but this should be kept in mind as the Target Groups per Action per Application Load Balancer and Target Groups per Application Load Balancer cannot be raised.
| Name | Default | Adjustable |
|---|---|---|
| Application Load Balancers per Region | 50 | Yes |
| Certificates per Application Load Balancer (excluding default certificates) | 25 | Yes |
| Listeners per Application Load Balancer | 50 | Yes |
| Target Groups per Action per Application Load Balancer | 5 | No |
| Target Groups per Application Load Balancer | 100 | No |
| Targets per Application Load Balancer | 1,000 | Yes |
ALB Attribute Change Impact
When ALB is aggregated, changes to ALB attributes, including connection timeouts and HTTP/2 enable/disable settings, affect all hosts.
Need to integrate security policies
Regarding the security policy to be set when creating HTTPS listeners, it is necessary to set a security policy that is supported by the assumed client of each host at the time of ALB aggregation, which may lower the security level.
Availability Perspective
I recently learned about Cell-based Architecture as an effort to minimize the extent of failure (Blast Radius), but have you heard of it?
cf. Guidance for Cell-Based Architecture on AWS
I honestly find it difficult to be aware of the need to minimize the range of failure (Blast Radius) in terms of availability, while at the same time balancing costs.
ALB node failures have a greater impact when they occur
When communication is temporarily disrupted due to a failure of an ALB node, for example, the impact of the failure on multiple hosts is an anti-pattern in the sense that the scope of the failure increases.
Impact when using Route53 failover routing
When configuring ALB failover via Route 53, an anomaly in a particular target group may also affect routing for other target groups.
If “Evaluate Target health” is set to “Yes” when creating an alias record to ALB via Route53, and any one of the target groups associated with ALB is found to be Unhealthy, ALB itself will be considered as abnormal. If any of the target groups associated with the ALB is found to be Unealthy, the ALB itself is considered to be abnormal.
Therefore, if an error occurs in a specific target group, queries to other healthy target groups are also routed to failover destinations, making it difficult to isolate the failure.
Operational Perspectives
Increased operational load due to mixed ALB logs
This is partly due to the change in the ALB attribute, but if you are analyzing logs, you will need to change the filtering conditions, etc. because ALB logs will be mixed in.
Top comments (0)