In the weekend I already covered the biggest container related releases of last week, so today I focus on a couple of other big announcements: Advanced Request Routing for ALBs and Service Control Policies in Organizations.

ALB Advanced Request Routing

Last week saw a significant update to the Application Load Balancer’s capabilities. It’s now been possible for quite a while to do path-based and hostname-based routing and that was already quite useful. This enabled you to do things like using separate backends for different parts of your application, or run multiple sites behind a single ALB. Especially with the support for Lambda as a backend this became an excellent way to modernise parts of your application without needing to restructure.

What AWS calls Advanced Request Routing however gives a lot more options. You are no longer limited to either a path or hostname but can route traffic based on any HTTP header, the query string, and even the source IP. This offers a lot of potential advantages, including special considerations for specific users or IP addresses. Both things that can be useful if you wish to test an update to your application. For example, you can deploy a new version and only route your own traffic there or implement some sort of A/B testing.

It also includes the ability to differentiate between request methods, which means you can use a dedicated backend for upload requests, like a Lambda function that stores it in S3. All of this becomes even more powerful through the ability to combine rules with both AND and OR statements.

I’ll be honest, this is a pretty big thing and while I suspect most people will hardly use these functionalities, I’m quite excited about it. Unfortunately, and as expected, there is no CloudFormation support for the new routing capabilities yet¹.

Service Control Policies in Organizations

The term “this changes everything” is often overused, but in this case it might be quite relevant. The addition of Service Control Policies might sound like a relatively dull sounding feature, but there is a lot of power in this. In short, SCPs allows you to set guardrails on your accounts or organizational units.

Let’s see what that actually means with a simple but frequent use case. Assume that for data integrity reasons none of your data is allowed to leave Australia². An easy way to prevent this would be to ensure that your team can’t spin up any resources in other regions. So, up until now, how would you do this? For a long time the answer was that you couldn’t, but last year AWS finally introduced the ability to limit region access to IAM policies. That was great, but also a lot of work as for every new user, role, or group you’d need to add these limitations. With a Service Control Policy you can instead manage this at the Organization level, so you no longer need to think about that within the account itself.

And that is the main idea behind these SCPs; you can handle a lot of the high-level work at the Organization level and be sure that nobody within the account can break past them by accident. Hopefully, this will give you some ideas, and feel free to share in the comments what you’re planning to do with this.