Les politiques de ressources AWS Sign-In tuent l'accès à la console à partir de l'extérieur de votre réseau

If you've ever wanted a clean, native way to block Management Console logins from coffee shop Wi-Fi or unexpected IPs, AWS just shipped exactly that. Sign-In now supports resource-based policies and RCPs that let you deny console pre-authentication and token issuance unless the request comes from your corporate IP ranges or VPCs.

Two Phases, Four Statements, One Break-Glass Principal

The policy generation isn't the usual raw JSON dump. You feed parameters to aws signin put-resource-permission-statement -- source IP CIDR, VPC ID, requested region, and an optional excluded principal ARN. AWS Sign-In constructs the policy for you. You get four deny statements in two pairs: one pair blocks the signin:Authenticate action (pre-auth), the other blocks signin:CreateOAuth2Token and signin:AuthorizeOAuth2Access (post-auth). Each pair covers network source and, for VPC-based rules, region binding to prevent VPC ID collisions across regions. That break-glass principal uses signin:PrincipalArn (pre-auth) or aws:PrincipalArn (post-auth) to bypass the network condition, so you don't lock yourself out if your VPN changes.

Enforcement is a two-step dance. First you create the permission statements, then you call put-console-authorization-configuration to flip the switch. Until you run that second command, nothing happens. Smart design: you can inspect the generated policy before it bites anyone.

From One Account to Your Whole Org

Single account policies work fine for small shops. For organizations running 100+ accounts, attach these as resource control policies (RCPs) at the OU or organization level in AWS Organizations. RCPs apply automatically to every account in scope. When a sign-in is denied by an RCP, CloudTrail records "Authorization denied because of a resource control policy" -- distinct from the account-level denial message, so your compliance team can pinpoint the enforcement layer.

CloudTrail Logging and the Data Perimeter Context

Every allowed and denied sign-in lands in CloudTrail. A successful sign-in shows ConsoleLogin: Success. A blocked attempt shows ConsoleLogin: Failure with errorCode: AccessDenied and a human-readable error message identifying the policy type. That's audit-ready evidence for regulatory compliance without extra tooling.

These sign-in policies slot directly into the broader AWS data perimeter framework. Combine them with AWS Management Console Private Access to lock down both ends: only your network can reach the sign-in, and only approved accounts are reachable from your network. The identity perimeter and resource perimeter round out the control set.

If you've been hacking together VPC endpoint policies and NACLs to manage console access, this feature replaces that mess with a single API call. No additional cost, all commercial regions. The only thing left is to decide which network ranges get the privilege of accessing your console.

Source: Restrict AWS Management Console access to expected networks with sign-in resource-based policies and RCPs
Domain: aws.amazon.com