AWS pre:Invent 2025 security announcements

AWS Security Incident Response offers metered pricing & adds AI Agent

What is it?

RedBear were a launch partner for the AWS Security Incident Response service at re:Invent 2024. The initial launch very much priced the service at Enterprise customers with a fairly significant fixed monthly fee. That has now changed with new metered pricing model that charges customers based on the number of security findings ingested.

On top of that the service has been updated to add an AI agent. This agent adds context and evidence to any incidents, enabling the responder to focus on analysis.

Why should I care?

For most of our customer, the service was out of reach. The new metered pricing approach has massively changed the game. Not only that, but the AI enhancement has taken what we think is a really important tool (always be prepared with your incident response, people) and made it significantly more efficient for investigations.

How can I use it?

It’s available today. To get started you need to delegate your Security account as the Security Incident Response master. From that account, you can enable it across your Org. You will also need to do a one-off exercise to set up a service-linked role. It’s that simple.

Amazon S3 Block Public Access Org wide

What is it?

The ability to block public access to S3 buckets at an account level was introduced several years ago. The next logical step was to add Organization level support. Well, that’s exactly what this AWS pre:Invent 2025 announcement has introduced! A default block public policy can be applied at the OU or entire Org level.

Why should I care?

Blocking public access to S3 buckets is critical. This secure by default approach will help to avoid accidental leakage of information through public buckets. Of course, you will still be able to intentionally make a bucket public (I’d argue there is no use case for that with services such as Amazon Cloudfront). CISOs will sleep a little easier tonight.

How can I use it?

You can enable it from the Organizations console in the master account today. You just need to set an Amazon S3 policy and apply it to the Org or OUs as you see fit.

Enforce encryption in transit within and across VPCs in a Region

What is it?

This new feature provides a centralized tools to audit and enforce encryption-in-transit for all traffic inside and between VPCs within a region. It’s supported by all AWS services and all of the more recent EC2 instances running on the Nitro platform. Older instances will need to be re-launched on Nitro based instances.

It supports two modes:

Monitor — Log the encryption status of traffic (e.g., hardware-layer, TLS or both) using a new encryption-status field in VPC Flow Logs, helping identify unencrypted (plaintext) flows.
Enforce — You can switch to enforce mode after all resources have been migrated to encryption-compliant infrastructure. You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of the AWS network).

Why should I care?

VPC Encryption Controls helps you guarantee that all traffic inside and between your VPCs is encrypted without relying on each team or service to do so individually. Instead of manually checking TLS configurations, upgrading legacy instances, or hunting for unencrypted flows, you gain a central point that can monitor where plaintext traffic exists. Once ready, you can enforce that only encrypted-capable resources can operate in your VPCs and that traffic is encrypted. This reduces security risk, simplifies compliance (with PCI-DSS for example) and eliminates the operational burden of maintaining your own encryption-in-transit standards across a large or complex AWS environment.

How can I use it?

To get started, you can enable monitor mode in your VPCs. VPC Flow log records will then show you your unencrypted flows. You can then update any resources, if required and ensure your own applications are using TLS. Once you see no more unencrypted flows, it’s time to enable enforcement.

Clearly, you want to start with a non-production environment and built out your knowledge from there!

What is it?

A simple but essential AWS pre:Invent 2025 announcment. Both ALBs and NLBs now offer support post-quantum key exchange options for the Transport Layer Security (TLS) protocol. This introduces new TLS security policies with hybrid post-quantum key agreement, combining classical key exchange algorithms with post-quantum key encapsulation methods.

Why should I care?

Quantum is coming.

Post-quantum TLS (PQ-TLS) security policies protect your data in transit against potential “Harvest Now, Decrypt Later” (HNDL) attacks, where adversaries collect encrypted data today with the intention to decrypt it once quantum computing capabilities mature. This quantum-resistant encryption ensures long-term security for your applications and data transmissions, future-proofing your infrastructure against emerging quantum computing threats.

How can I use it?

You can enable the post-Quantum TLS policies today in your load balancer configurations at no cost.

What is it?

AWS NAT Gateways have up until now been an availability zone (AZ) level resource. If you were operating in a region with 3 AZs, you needed to spin up 3 NAT Gateways, one per AZ, if you wanted to ensure availability. It’s a maintenance burden – you also end up with 3 private route tables.

You can now create a single NAT Gateway that automatically expands and contracts across AZs in your VPC, to maintain high availability while offering simplified setup and management. As a bonus, you don’t need to create a public subnet to host this new regional NAT GW!

AWS NAT Gateways have up until now been an availability zone (AZ) level resource. If you were operating in a region with 3 AZs, you needed to spin up 3 NAT Gateways, one per AZ, if you wanted to ensure availability. It’s a cost and maintenance burden – you also end up with 3 private route tables.

You can now create a single NAT Gateway that automatically expands and contracts across AZs in your VPC, to maintain high availability while offering simplified setup and management. As a bonus, you don’t need to create a public subnet to host this new regional NAT GW!

Why should I care?

Regional NAT Gateways mean simplified management, greater security and even greater availability. You can expand from 2 to 3 AZ usage without having to think about the NAT Gateway infra.

How can I use it?

To setup a regional NAT Gateway, you can select regional at configuration time. Be careful with the the IP mode.

• Manual mode requires more maintenance as you will remain responsible for scaling across AZs,
• Automatic will allow auto-scaling but mean that your public IP may not be static. However, you can get around this using IPAM and a public IPv4 policy. This does add a level of complexity, particularly if you don’t expect to be expanding and contracting your AZ usage. In this case, the manual mode may be better as a once off activity (but see pricing comment below!).

Be aware that this won’t save you money! You are still charged by gateway hours so if you spin up a regional gateway across 3 AZs, that’s billed as 3 zonal NAT Gateways. There are no changes to traffic charges.

What is it?

Let’s clear up the confusion. This is not a feature of AWS Network Firewall. You don’t need a Network Firewall to use the Proxy as it is a standalone VPC feature. Perhaps, the service naming team need some help at AWS?

AWS Network Firewall Proxy provides granular security controls to inspect and filter outbound connections from your VPC. It aims to prevent data exfiltration and malware intrusion.

The proxy acts as an intermediary between your workloads and the internet, inspecting and filtering traffic to comply with your security policies. You can configure your applications to route HTTP and HTTPS traffic via the Proxy. The proxy filters both the outbound requests from your clients and the inbound response from the allowed destinations based on the security policies you set. You can also configure the proxy to decrypt HTTPS traffic and filter it based on any of the header attributes such as the URL path and other attributes.

It’s an adjunct to existing rules in AWS Network Firewall that block traffic to low reputation domains.

Why should I care?

Monitoring and managing outbound traffic from your VPCs is important. It can help to avoid exfiltration of data and installation of malware by attempts to connect to command and control servers.

Plus, bonus!, you don’t need the relatively expensive AWS Network Firewall to use this new proxy feature.

How can I use it?

To setup up a Network Firewall Proxy, you need to have a NAT Gateway running in your VPC. Just for fun, this can’t be one of the new regional NAT Gateways. It need to be the OG NAT Gateway, now known as a zonal NAT Gateway.

If you have one of these, it’s a simple case of setting up some proxy rules. Rules can address the DNS lookup phase, the pre-request sending phase or the pre-response forwarding stage. You then create and attaching the proxy to the NAT Gateway.

It’s currently in preview and only available in the us-east-2 region during the preview.

What is it?

This final AWS pre:Invent 2025 announcement allows Secrets Manager to be used with your third party Software-as-a-service (SaaS) solutions. You can use Secrets Managed to manage the rotation of secrets associated with those solutions. It supports multiple different rotation strategies inline with your SaaS provider, without the overhead of using your own solution, such as a Lambda function. With this launch, you can secure your SaaS secrets using the familiar AWS Secrets Manager.

Why should I care?

Managing secrets across multiple platforms is hard. This release aims to simplify and secure the process to a single provide for all your secrets. It provides auditability through existing AWS mechanisms (such as Cloudtrail) and simplifies maintenance of secrets.

It’s clearly meant to compete with other solutions such as Hashicorp Vault

How can I use it?

At launch, there are only 3 supported SaaS providers, Salesforce, BigID and Snowflake. Expect to see a lot more over the next few months as this gains some momentum.