How many balancers should be used on a project?

Question

Amazon Web Services

There is a small site on WP, based on AWS (although I think the question is more general - and may be applicable to other cloud providers)
There are two environments - development and production. Development is extremely rare, sometimes the test server is turned off altogether.
At the moment, the project has two separate balancers - one redirects traffic to the test server, the second, respectively, to the production. In fact, the balancer simply performs the role of a redirect - there is 1 server behind the balancer - there is nowhere to balance it.
Personally, I don't see the point in using 2 different balancers, although a colleague says "This is a safer architectural pattern than using a common ALB for both work and testing."
I would like to hear some other opinion on this issue, because. I don't understand what security is here - I see more useless "winding up" on the project and a useless payment for 2 balancers.

Answer 1

In general, according to the mind of the virgins and the environment, the environment should not intersect at all.
Extra rules in the product balancer are not good.
I think that there should be 2 balancers / 2 servers / 2 bases / 2 buckets in s3, etc. etc.
What is the balancer fee? As far as I remember, the payment for the balancer is based on the amount of traffic / requests. Do you have a million people going to the dev balancer there?

Answer 2

Get all development infrastructure in terraform and only bring it up when needed, then delete everything (stop EC2, disable/don't autoscaling in dev) Create a separate aws account and/or child aws organization for this - that's the right way to do it! Dev and Prod should be different accounts - best practices!

Answer 3

I will support Vadim : describe this infrastructure as code and raise the test bench only when you need it
Ideally, yes - it's better to create a second AWS account (and link them to an organization for centralized management) so that changes to the test infrastructure do not accidentally touch the prod.
The separation approach, as described by your colleague, is correct (the points below describe far from all cases, so it occurred to me while the answer was writing):
1. The test traffic does not overlap with the sales traffic, which allows you to measure the load (and plan, including infrastructure costs, with AWS you just pay for the load) on the application directly on the balancer (if you still have more load and you will have to apply horizontal scaling - add an application node behind the balancer)
2. The test traffic does not overlap with the sales traffic - there will be no collisions, "extra" load on the balancer, a surge of errors in the monitoring of the balancer due to the test stand
3. Rules on the balancer can be anonymized (not related to the environment) and tested before implementation in production - important for the development of the application