# AWS Management Console Private Access — adoption decision matrix

Use this when someone asks *"should we turn on Console Private Access?"* AWS [announced](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-management-console-private/) on **June 15, 2026** that console traffic can flow entirely through VPC endpoints — no public internet required.

> Confirm current scope in [AWS Console Private Access documentation](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html) — commercial Regions only; supported service consoles expand monthly.

## 1. What job are you hiring Private Access for?

| Job | Console Private Access fit | Existing alternative |
|-----|---------------------------|----------------------|
| **Prove console traffic never hits the public internet** | Strong — 100% browser traffic via PrivateLink VPC endpoints | VPN to corporate network + IP allow lists on public console (weaker proof) |
| **Restrict which AWS accounts operators can open in the console** | Strong — VPC endpoint policies allow/deny by account, org, OU | SCPs + IAM only (no network-path proof) |
| **Break-glass ops from an air-gapped or classified VPC** | Strong (post–June 15, 2026) | AWS CLI/API from bastion with outbound restrictions |
| **Day-to-day application deployment** | Weak — use CI/CD, IaC, and service APIs | CodePipeline, Terraform, CDK |
| **Internal SaaS / employee app access** | Wrong tool — use [AWS Verified Access](/patterns/zero-trust-vpc/) | Verified Access + IdP |
| **Third-party SaaS consumption without internet** | Partial overlap — PrivateLink for AWS console only | [PrivateLink for SaaS vendors](/blog/aws-vpc-networking-best-practices-for-production/) |

## 2. Prerequisites (do these before the pilot VPC)

- [ ] **Hybrid connectivity** — Direct Connect or Site-to-Site VPN if operators start on-premises ([AWS Security Blog walkthrough](https://aws.amazon.com/blogs/security/access-accounts-with-aws-management-console-private-access/))
- [ ] **us-east-1 endpoints** — default console DNS resolves here even if workloads live elsewhere
- [ ] **DNS owner** — Route 53 private hosted zones + Resolver inbound for on-prem forwarding
- [ ] **Split-horizon plan** — `docs.aws.amazon.com` and `health.aws.amazon.com` have **no** VPC endpoints; document the public-internet exception for auditors
- [ ] **Monthly config pull** — `https://configuration.private-access.console.amazonaws.com/{region}.config.json` (AWS updates monthly)
- [ ] **Cost approval** — model scenarios in [`private-access-cost-model.csv`](private-access-cost-model.csv) before provisioning 161 endpoints per Region

## 3. Cost guardrails (June 2026 benchmark)

| Scenario | Endpoints (3 AZ) | Modeled monthly (hours only) |
|----------|------------------|------------------------------|
| Pilot (12 services) | 12 | ~$263/mo |
| Full single Region (us-east-1) | 161 | ~$3,526/mo |
| Two Regions (us-east-1 + eu-west-1) | 307 | ~$6,727/mo |

AWS charges **no Console Private Access surcharge** — you pay PrivateLink endpoint hours and data processing only.

## When NOT to adopt yet

- Operators rarely use the console and all changes flow through IaC — **CLI/API + pipelines** are cheaper.
- You cannot operate monthly DNS/endpoint updates — stale config breaks new service consoles silently.
- GovCloud or China partitions are in scope — this launch is **commercial Regions** only.
- You need private access to **docs** and **health** widgets without any public DNS path — not supported today.

## Opinionated recommendation

**Adopt Console Private Access** when compliance requires network-path isolation **and** operators legitimately need the console from controlled VPCs.

**Stay on VPN-to-public-console** only if your threat model accepts internet transit and you lack budget for endpoint sprawl.

**Prefer IaC + break-glass CLI** when console usage is <5% of operational changes.