AWS re:Invent produces hundreds of announcements. Most are incremental. A handful change how you should architect AWS environments at a fundamental level. Here are the five security launches from re:Invent 2024 that fall into the second category, and what they mean for teams building on AWS in 2026.
1. Resource Control Policies: Closing the “Compromised Admin” Gap
Service Control Policies (SCPs) have existed since AWS Organisations launched in 2017. They constrain what IAM principals in an account can do. The gap: if an IAM principal is compromised, SCPs do not prevent that principal from exfiltrating data by sharing resources - S3 buckets, KMS keys, Secrets Manager secrets, RDS snapshots - with an external account.
Resource Control Policies (RCPs) address this. Where SCPs control actions on the subject side (“this principal cannot do X”), RCPs control actions on the resource side (“this S3 bucket cannot be accessed by principals outside the Organisation boundary, regardless of who is asking”).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyExternalS3Access",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
}
]
}Applied at the Organisation root, this policy prevents any S3 bucket in any account from being made accessible to principals outside the Organisation - even if a compromised IAM principal attempts to modify the bucket policy, even if an administrator makes an error, even if someone deliberately tries to exfiltrate data via cross-account sharing. The RCP is evaluated before any resource-level policy.
The security model shift: previously, preventing data exfiltration via resource sharing required either blocking the relevant APIs via SCP (preventing any sharing, including legitimate cross-account access) or auditing resource policies continuously. RCPs allow you to permit legitimate cross-account access within the Organisation while preventing exfiltration outside it, all in a single policy at the management account level.
2. Declarative Policies: Enforcement With Pre-Deployment Impact Analysis
Declarative Policies set and enforce baseline configurations for specific AWS services across an Organisation - currently EC2 configurations. The two most immediately useful enforcement targets:
IMDSv2 required everywhere. Instance Metadata Service v2 requires a session-oriented flow with a PUT request to get a session token before any metadata can be fetched. IMDSv1 is vulnerable to SSRF attacks - a web application that fetches arbitrary URLs can be tricked into fetching http://169.254.169.254/latest/meta-data/iam/security-credentials/, retrieving instance credentials and enabling lateral movement. IMDSv2’s PUT requirement breaks SSRF-based metadata theft.
The problem with enforcing IMDSv2 via SCP was that you could not know what would break before enabling it. Declarative Policies include a pre-enforcement impact analysis: run the analysis, get a report of which instances and launch templates in which accounts are still using IMDSv1, fix them, then enable enforcement. The “what breaks if I enforce this?” question has an answer before you enforce it.
AMI source account allowlisting. Enforce that EC2 instances can only be launched from AMIs in an approved list of AWS account IDs. Prevents supply chain attacks via rogue AMIs - a compromised CI pipeline that substitutes a backdoored AMI hits this control even if it has the IAM permissions to describe and run instances.
Unlike SCPs, Declarative Policies also support custom error messages. When a developer’s terraform apply fails because the AMI they chose is not on the allowlist, they see a message explaining why and linking to the process for getting an AMI approved, rather than an opaque access denied error that lands in the security team’s inbox as a support ticket.
3. Centralised Root Access Management
The traditional AWS root user guidance was: create the account, set a strong password, enable MFA, put the credentials in a safe, never use them again. The problem: “in a safe” means different things to different organisations, root credentials for hundreds of accounts in an AWS Organisation are a significant liability, and the break-glass procedure for using root credentials is rarely tested.
The new model eliminates stored root credentials for member accounts. Root tasks (recovering locked-out accounts, certain billing and support operations) are performed through AWS Organisations using short-lived credentials scoped to the specific task, approved through the management account. No member account needs to have root credentials that could be stolen, shared, or forgotten in a password manager.
For security teams, this is a significant improvement in the AWS Organisations threat model: there are no root credentials to compromise in member accounts, the blast radius of a management account compromise is reduced (root tasks require approval), and the audit trail for root-level actions is centralised.
4. GuardDuty Extended Threat Detection: Multi-Stage Attack Sequences
GuardDuty has historically generated findings at the single-event level - one finding per anomalous API call, suspicious IP, or unusual behaviour. The problem with single-event findings at scale is alert fatigue: a large AWS environment generates hundreds of GuardDuty findings per day, the majority of which are either benign or represent isolated events that do not constitute a complete attack.
Extended Threat Detection uses ML models that correlate findings across services and time to detect multi-stage attack sequences. The canonical example: a finding that an IAM user called GetCallerIdentity from an unusual IP, followed by ListBuckets from the same IP, followed by bulk GetObject calls across multiple buckets, is a single extended finding - “credential exfiltration and data access sequence” - rather than three unrelated medium-severity findings that might individually be dismissed.
The practical implication for security operations: Extended Threat Detection findings represent a prioritised, correlated view of activity that is more actionable than raw GuardDuty findings. Teams with limited SOC capacity benefit from this filtering. Teams with sophisticated SIEM setups can use extended findings as a high-priority alert tier alongside standard GuardDuty findings.
5. AWS Security Incident Response Service
The fifth launch is more operationally significant for mid-size teams than for enterprises: a managed service that provides automated triage of GuardDuty alerts, a 24/7 incident management console, and access to AWS security experts for incident response support.
For organisations without a dedicated security operations function, this addresses the gap between “GuardDuty is on” and “someone is actually responding to GuardDuty findings at 3am.” The automated triage component applies the same contextual analysis as Extended Threat Detection to suppress false positives before they reach on-call engineers.
What Changes in Practice
The combined effect of these launches is a meaningful improvement in the security baseline achievable without significant custom engineering:
- RCPs at the Organisation root prevent the most common data exfiltration pattern (cross-account resource sharing)
- Declarative Policies with impact analysis make IMDSv2 enforcement achievable without a lengthy impact assessment project
- Centralised root access management eliminates a credential category that was a persistent liability
- Extended Threat Detection reduces the SOC burden of GuardDuty at scale
Apply RCPs and Declarative Policies at the Organisation level as baseline controls. Enable Extended Threat Detection if you are already using GuardDuty (it is additive, not a replacement). Evaluate Security Incident Response if your organisation does not have 24/7 security operations coverage.
The re:Invent 2024 security launches are notable because they address structural gaps in the AWS security model rather than adding new detective controls on top of existing architecture. That is the rarer and more valuable category of announcement.