One ALB rule, zero legacy commits: shipping a feature around an app nobody will touch

A walkthrough published on dev.to lays out a pattern for adding a requirement to a legacy application without editing it: create a Lambda target group, add an Application Load Balancer listener rule that matches one URL path, and let the default rule keep sending everything else to the existing EC2 instance ^[3][8][12]. It matters because the two familiar options are both bad ones: ask the team mid-rewrite to squeeze in the feature, or open a codebase nobody fully understands any more ^[2].

The mechanics are unremarkable, which is the point. An ALB already does content-based routing on path, hostname, headers or query parameters ^[4]. A listener watches a protocol and port, in the example HTTP on 80, and evaluates its rules in priority order, first match wins, with a default rule catching everything unmatched ^[5]. A target group is just a set of destinations, and AWS supports both Instance and Lambda target types; Lambda target groups need no health check because Lambda manages its own availability ^[6]. So the new path gets its own target group, and the legacy instance group keeps receiving general traffic under the default rule ^[8].

The consequence of first-match-wins is the part worth getting right before you touch the console. The new rule has to sit above the default rule and above any broader existing rule that would also match, or the request keeps going to the legacy app and you debug a 404 in something you swore not to touch ^[1].

The author frames this as surgical: intercept exactly one path, leave 100% of existing behaviour untouched, no redeployment of the legacy app, no coordination with the rewrite team, no regression risk ^[10]. The first four hold up. The last is scoped to application code, not to the system. Nothing was committed, but two pieces of shared production configuration were added, and the ALB now makes the routing decision before either backend sees the request ^[9][3]. Neither the function nor the EC2 app knows the other exists ^[9]. That decoupling is the feature and also the liability: the only artefact recording that /lambda is handled somewhere else is a listener rule, and listener rules are not in either team's repository.

Two operational notes. Because the Lambda target group carries no health checks, there is no target-health signal for that path; whatever monitoring you have on the function is the monitoring you have ^[2]. And Lambda bills for execution time, which is why the source recommends it for specific paths without constant traffic rather than for the hot path ^[7].

The published text stops mid-sentence at registering the function with the target group, so the listener rule itself, its priority number and its path pattern are not shown ^[13]. Anyone implementing this from the article is filling in the most failure-prone step from their own judgement. Before shipping it, check what an authentication or session layer in front of the ALB does with a request that never reaches the application, and decide where the rule is documented so the rewrite team inherits it rather than discovers it.

What to watch is whether the rule count stays at one. The pattern assumes the prerequisites already exist: an ALB, an EC2 instance running the legacy app, and a Lambda function holding the new logic ^[11]. Each of those is cheap to add again, and a load balancer holding a dozen undocumented path exceptions is a second application with no repository.