Organizations in financial services, healthcare, defense, and government face a persistent operational dilemma: their most sensitive workloads run in network-isolated VPCs with zero internet access, but until now, the AWS Management Console required internet connectivity. Security teams had to choose between operational efficiency and network controls.
AWS Management Console Private Access eliminates that trade-off. The feature now routes all console traffic, authentication, static assets, console-only APIs, and service calls, through AWS PrivateLink VPC endpoints. No internet gateway. No NAT gateway. No proxy allowlists to maintain.
This guide walks you through a production-ready deployment that extends your existing data perimeter controls to browser sessions.
What You Need Before Starting
Network infrastructure:
- A VPC in your target AWS Region
- Optional: AWS Direct Connect, AWS Site-to-Site VPN, or Amazon WorkSpaces for user access
- Route 53 Resolver inbound endpoint if you're routing traffic from on-premises
IAM prerequisites:
- Management account access to create resource control policies (RCPs)
- Permissions to create VPC endpoints and endpoint policies
- CloudTrail enabled in the target Region
Baseline your current state: Run this CloudTrail Insights query over the past 30 days:
eventName = ConsoleLogin
Review sourceIPAddress, vpcEndpointId, and awsRegion fields. Document which identity types your users rely on: root user, IAM users, SAML federation, or IAM Identity Center. Identify a pilot organizational unit (OU) or account that doesn't host production workloads, you'll test access restrictions there first.
Critical: Don't pilot in a shared production account. A misconfigured sign-in policy can lock everyone out. Choose a dedicated test account and configure a break-glass principal before you enforce network restrictions.
Step-by-Step Implementation
1. Create the Three Private Access Endpoints
In your target VPC, create these interface VPC endpoints:
com.amazonaws.<region>.console
com.amazonaws.<region>.signin
com.amazonaws.<region>.console-static
The third endpoint handles static assets and console-only APIs. If your VPC has any internet path, you can skip it. If you're running fully isolated, it's required.
For each endpoint:
- Select at least two subnets across availability zones
- Attach a security group that allows inbound HTTPS (port 443) from your user source networks
- Enable private DNS for the console and signin endpoints only (not for console-static)
2. Configure DNS Resolution
For VPCs with Direct Connect or Site-to-Site VPN:
Create a Route 53 Resolver inbound endpoint in the VPC. Configure your corporate DNS forwarder to send queries for:
*.console.aws.amazon.com
*.signin.aws.amazon.com
...to the Resolver endpoint's IP addresses.
For workloads running directly in the VPC (EC2, WorkSpaces):
Private DNS resolution works automatically. The VPC's DNS resolver will return the endpoint's private IPs.
3. Build Your VPC Endpoint Policies
Start with a permissive policy to validate connectivity, then layer in restrictions.
Console endpoint policy (identity perimeter):
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-yourorgid"
}
}
}
]
}
This prevents personal AWS accounts from accessing the console through your network. Users can only sign in to accounts inside your organization.
Sign-in endpoint policy (pre-authentication resource perimeter):
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceOrgID": "o-yourorgid"
}
}
}
]
}
Before authentication completes, the sign-in service evaluates aws:ResourceOrgID. This blocks authentication attempts to accounts outside your organization.
4. Layer in Sign-In Resource Control Policies
Attach an RCP to your pilot OU that restricts console access to expected networks:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "signin:ConsoleLogin",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-yourpilot"
}
}
}
]
}
Add a break-glass exemption:
{
"Effect": "Allow",
"Action": "signin:ConsoleLogin",
"Resource": "*",
"Condition": {
"StringEquals": {
"signin:PrincipalArn": "arn:aws:iam::account:role/EmergencyAccess"
}
}
}
The break-glass role can authenticate from any network. Don't skip this step.
5. Add Service-Specific VPC Endpoints
Console Private Access routes console UI traffic through your VPC, but direct browser requests to AWS service APIs only carry VPC context if the service has its own endpoint.
Create endpoints for every service your team uses:
com.amazonaws.<region>.ec2
com.amazonaws.<region>.s3
com.amazonaws.<region>.lambda
Your network perimeter service control policies (SCPs) that condition on aws:SourceVpc will now apply to console sessions. Without these endpoints, some service calls won't carry VPC context, and your SCP will inadvertently block them.
Validation: Verify It Works
Test 1: Confirm DNS Resolution
From a workload in the VPC, run:
nslookup us-east-1.console.aws.amazon.com
You should see private IPs (10.x, 172.x, or 192.168.x) that match your endpoint's network interfaces. If you see public IPs, private DNS isn't configured correctly.
Test 2: Access the Console
Open a browser from your test workload and navigate to:
https://<region>.console.aws.amazon.com
Sign in with a principal in your pilot OU. If authentication succeeds and the console loads, Private Access is working.
Test 3: Verify Network Enforcement
From outside your VPC (your laptop, a personal device), attempt to sign in to an account in the pilot OU. The sign-in RCP should deny the request. Check CloudTrail for:
eventName = ConsoleLogin
errorCode = AccessDenied
If the login succeeds, your RCP isn't attached to the correct OU or the condition isn't evaluating as expected.
Test 4: Confirm Resource Perimeter
From your VPC, attempt to sign in to a personal AWS account. The sign-in endpoint policy should block it. You won't see a CloudTrail event because the request is denied at the VPC endpoint before it reaches the sign-in service.
Maintenance and Ongoing Tasks
Expand to Additional Regions:
Repeat the endpoint creation and DNS configuration in each Region where your users access the console. Sign-in RCPs are global, but VPC endpoints are regional.
Monitor for Policy Violations:
Set up a CloudWatch Logs Insights query for denied console logins:
fields @timestamp, userIdentity.principalId, errorCode, sourceIPAddress
| filter eventName = "ConsoleLogin" and errorCode = "AccessDenied"
| sort @timestamp desc
Review weekly. Repeated denials from the same principal may indicate a misconfigured workstation or a user attempting to bypass controls.
Update Service Endpoints as You Adopt New Services:
When your team starts using a new AWS service, create its VPC endpoint immediately. Without it, console actions for that service won't carry aws:SourceVpc context, and your network perimeter SCPs may block legitimate requests.
Audit Your Break-Glass Role Quarterly:
Verify that the role credentials are stored securely and that the role's permissions are scoped to emergency access only. If you haven't used it in 12 months, test it in a non-production account to confirm it still works.
Review Endpoint Policies Every Six Months:
As your organization structure changes (new OUs, account moves, mergers), your aws:PrincipalOrgID and aws:ResourceOrgID conditions remain valid, but exemptions tied to specific account IDs or role ARNs may need updates.
Private Access extends the same data perimeter controls you already use for API traffic to interactive browser sessions. If you've built identity, resource, and network perimeters for programmatic access, this is the natural next layer.
