Amazon Quick on a private network: PrivateLink's two planes and where they leak

When someone from compliance asks whether Amazon Quick "goes over the internet", the honest answer has two parts, and almost every design I have reviewed answers only one. User traffic into Quick uses PrivateLink interface endpoints. Quick's traffic out to your on-premises database, your private MCP server or your internal API uses something else: ENIs that Quick itself injects into your VPC. DNS, endpoint policy, IP/VPC restriction and IAM sit on top of those two planes, and each layer covers less than its name suggests. The useful question is not "is it private?", it's "which byte still leaves for the internet, and who decided that was fine?".

Why this matters now

While Quick was just BI, the VPC connection existed so Quick Sight could read PostgreSQL, SQL Server or Oracle behind a Direct Connect. The problem was well understood and the blast radius fit inside a dashboard. What changed is who uses that same VPC connection. It now carries Quick Agents calling MCP servers hosted on your network, Quick Flows and Quick Automate invoking action connectors, and Quick Research and Apps in Quick pulling from private sources. The ENI that used to run a SELECT for a chart now carries an agent's tool call.

In financial environments this matters in two places. Regulation: CMN Resolution 4.893 and PCI-DSS expect you to show the data path and control who enters the perimeter. The AWS post lists HIPAA, FedRAMP and PCI-DSS as the usual triggers. Audit: "traffic stays on the AWS backbone" only works as evidence if you can say which domains still leave through NAT, and some do.

The 21 Oct 2026 post is a good walkthrough. What it doesn't do, and isn't meant to, is say where each control stops working. That's what this piece covers: the documented limits of each layer, and the cost of keeping all of it working for years, not the cost of building it once.

The two planes of private Quick access, and what stays public

Ingress (user to Quick) over interface endpoints. Egress (Quick to your data) over VPC connection ENIs. Dashed lines are traffic no endpoint covers.

🏢 On-premises: rede corporativa

DNS corporativo forward de .quicksight.aws.amazon.com (network)
Oracle / SQL Server porta do banco liberada só para o SG do Quick (data)
Servidor MCP privado API interna por IP (compute)

📡 Rede: Direct Connect ou Site-to-Site VPN

Direct Connect rota para o CIDR da VPC (network)

🟧 AWS: VPC do cliente (2 AZs no mínimo)

Route 53 Resolver inbound 2+ ENIs (network)
VPCE quicksight-website policy só com aws:PrincipalAccount / aws:OrgId (security)
VPCE quicksight (API) policy por ação; 13 APIs fora (security)
ENIs da VPC connection SG QuickSight-VPC, VPC ID imutável (network)
VPCE secretsmanager / redshift / glue S3 por gateway (security)

🤖 AWS: Amazon Quick (Enterprise)

Quick Sight, Agents, Flows, Automate Identity Center, RLS/CLS (ai)

🌐 Externo: saída pública que continua obrigatória

*.cloudfront.net, *.execute-api, *.kinesisvideo sign-in do Identity Center (external)

Flows

user -> dns: resolves the site name
dns -> resolver: forwards the private zone
user -> dx: HTTPS 443
dx -> vpce-web: console and dashboards
dx -> vpce-api: API calls
vpce-web -> quick: PrivateLink (ingress)
vpce-api -> quick: PrivateLink (ingress)
quick -> eni: assumes execution role, uses ENIs
eni -> dx: data and tool-call egress
dx -> db: SQL query
dx -> mcp: action connector / MCP
eni -> sm: credentials without leaving the VPC
user -> public: assets, metrics, sign-in via NAT/proxy

Ingress plane: interface endpoints, DNS and what the policy accepts

Ingress uses two interface endpoints with different jobs: com.amazonaws.<region>.quicksight-website for the site and com.amazonaws.<region>.quicksight for the API (with a -fips variant). If administrators sign in as IAM users, add console and signin too. Place each one in at least two AZs, with a security group that accepts only 443 from the corporate CIDR.

DNS is where the first thing breaks. The API endpoint, with private DNS on, takes over quicksight.<region>.amazonaws.com by itself. The website endpoint doesn't: its private name is not the public URL. You create a private hosted zone for <region>.quicksight.aws.amazon.com with an alias A record pointing at the endpoint. But a private hosted zone only answers associated VPCs, so corporate DNS has to forward that zone to a Route 53 Resolver inbound endpoint. Without the forward, the browser resolves the public IP, access still works, and nobody notices PrivateLink is being bypassed. Test with nslookup from inside the corporate network and expect an IP from the VPC CIDR.

The website endpoint policy is almost decorative. Principal, Action and Resource must be "*", and the condition only accepts aws:PrincipalAccount or aws:OrgId. It stops your network from becoming a doorway into another account's Quick, which helps against exfiltration, but it doesn't control what the user does. The API endpoint accepts action-level restriction, and that's where being specific pays off.

Egress plane: the VPC connection is an injected ENI, not PrivateLink

When Quick needs to fetch data, it doesn't go through the interface endpoint. To create a VPC connection (Enterprise only), you supply a VPC ID, at least two subnets in different AZs, at least one security group, and an execution role that trusts quicksight.amazonaws.com. Quick assumes that role and creates ENIs in your subnets with ec2:CreateNetworkInterface. From then on your network decides: route table, NACL, security group and the Direct Connect route.

Three details turn into incidents if you don't know them. The VPC ID can't change after creation: reorganizing the network means recreating the connection and repointing every data source. The PARTIALLY AVAILABLE status means one ENI is down and the connection still works. It's exactly the state nobody watches until the second AZ fails. Connections created before 27 Apr 2023 use a non-stateful security group and need an inbound rule that lets return traffic in on every port (0–65535) from the source's SG. If yours dates from then, recreate it.

For on-premises database host names, enter the Resolver inbound IPs in the DNS resolver endpoints field. Without them Quick resolves through public DNS and can't find the host. Credentials go to Secrets Manager through an interface endpoint in the same VPC as the ENIs, so that even the password lookup doesn't leave through NAT.

One limitation changes the design: the Quick Index knowledge base VPC connection currently supports only Amazon Redshift. Confluence, SharePoint, Box, Google Drive, OneDrive and S3 can't use it.

The ENI security group is now the agent's network allow-list: The same VPC connection serves Quick Sight and Quick Agents calling private MCP. In practice, the egress of the QuickSight-VPC SG and the routes on those subnets define everything an agent can reach on your network. If the SG opens the whole on-premises CIDR because "BI needed it", the agent inherits that reach. Split subnets and security groups by purpose (analytical data on one side, action tools on the other), even if it costs a second VPC connection.

Enforcing endpoint-only access: where the restriction stops

Quick's IP/VPC restriction (update-ip-restriction --enabled --vpc-endpoint-id-restriction-rule-map vpce-...=Name) blocks anything that doesn't come from the approved endpoint. It has four properties you need to know before turning it on in production.

It covers web, embedded and mobile, but not the public API. Anyone with credentials can call any operation from any IP. For the API the control is IAM: an aws:SourceVpce or aws:SourceIp condition in a deny policy, ideally in an SCP. Here's the catch: 13 APIs don't work through the interface endpoint (the 8 action connector ones, such as CreateActionConnector, and 5 Flows ones, such as ListFlows). A blanket aws:SourceVpce deny breaks the automation that manages connectors. You write the exception with NotAction for those operations and run that automation from a controlled path with public egress.

UpdateIpRestriction replaces the whole map. A script that sends only the new rule deletes the others. Run describe-ip-restriction first, or better, keep the map versioned and always apply the full state.

A rule takes up to 10 minutes to apply and is global, enforced in every Region and managed only from the account's Region. The limit is 100 rules combined, with IP and VPC rules OR'ed together.

Lockout is real. Without a rule covering your own access, the console won't let you save. But anyone on a source outside the list loses access the moment you turn it on. Publicly embedded dashboards then work only through the endpoint.

What stays public, and what keeping the rest private costs

The documentation lists the domains the browser reaches, and several have no endpoint: *.cloudfront.net (CSS and JS), *.execute-api.<region>.amazonaws.com (client metrics), *.kinesisvideo.amazonaws.com (automation streaming), <region>.signin.aws and, with IAM Identity Center, browser sign-in, which requires the public sign-in and Identity Center endpoints. No public IP is needed, but NAT or a proxy is. Your compliance report should say "the data and API path is private; static assets, telemetry and authentication leave through an inspected proxy". Writing "zero internet" claims something the documentation itself contradicts.

Now the recurring cost, in us-east-1. An interface endpoint costs US$ 0.01 per hour per ENI, plus US$ 0.01 per GB for the first 1 PB. Website and API in 2 AZs are 4 ENIs, about US$ 29/month. Add console and signin, another US$ 29. Secrets Manager, Redshift and Glue in 2 AZs, roughly US$ 44 more. The most expensive piece is the one nobody budgets: a Resolver inbound endpoint costs US$ 0.125 per ENI per hour, with at least two, so about US$ 182/month, plus US$ 0.40 per million queries. If you already have a shared Resolver inbound in a central network VPC, reuse it: it's the biggest line item and there's nothing Quick-specific about it.

Anti-patterns I find in this design

Website endpoint without on-premises DNS forwarding: PrivateLink exists, the browser resolves the public IP and access works from outside. It's a silent failure that only shows up in nslookup or VPC Flow Logs.
Treating IP/VPC restriction as an API control: it doesn't cover the public API. Without aws:SourceVpce in IAM or an SCP, a leaked credential calls everything from anywhere.
Blanket aws:SourceVpce deny with no exception: the 13 action connector and Flows APIs don't go through the endpoint, and the automation that manages connectors stops working without an obvious error.
A script that calls UpdateIpRestriction with only the new rule: the map is replaced whole, the other rules disappear and an entire branch office loses access within 10 minutes.
One VPC connection for BI and agents with the whole on-premises CIDR open: the agent inherits BI's network reach, and the blast radius of a prompt injection becomes the corporate network.
Keeping a VPC connection from before 27 Apr 2023: the non-stateful SG requires return traffic open on 0–65535, a rule no auditor accepts without questions.

Well-Architected lens

security: Layered defense with clear roles: website endpoint policy scoped by aws:OrgId, API endpoint policy by action, IP/VPC restriction for web and mobile, an SCP with aws:SourceVpce and NotAction for the 13 APIs outside the endpoint, RLS and CLS on the data. Restriction map changes land in CloudTrail; alarm on UpdateIpRestriction.
reliability: Two AZs on every endpoint and on the VPC connection, an alarm whenever status leaves AVAILABLE (including PARTIALLY AVAILABLE), and Direct Connect with a backup VPN, because the VPC connection has no other path to on-premises.

What I would do: I'd start with the report I'll hand the auditor, and only then create the first endpoint: which domains leave through the proxy, which controls cover the API and which cover the browser. Then I'd build two security groups and two VPC connections, one for analytical data and one for agent tools, because I've seen a "temporary" BI security group last four years. The restriction map would go into code from day one, applied as full state. The lesson I carry from financial platforms: the expensive control isn't the one you configure, it's the one you think is active and isn't, and in Quick that control is DNS forwarding.

Verdict

Use the full design (website and API endpoints, VPC connection, Resolver inbound, IP/VPC restriction and an SCP with aws:SourceVpce) when you have regulated on-premises data, agents calling private tools, and an auditor who will ask for the path of every byte. If Quick only reads Redshift and S3 in the same account and sign-in goes through Identity Center, a VPC connection with service endpoints covers most of the risk, and IP restriction on the corporate egress covers the browser for well under US$ 300/month. Either way, document what stays public. That sentence is what separates a defensible design from a promise the documentation contradicts.

Rating: Recomendado com ressalvas / Recommended

References

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.