Amazon Quick separates private user access from private data connections

An employee opening Amazon Quick and an AI agent querying an internal database make different network journeys. AWS’s 21 October implementation guide separates them: PrivateLink-powered VPC endpoints handle supported user and API access, while Quick VPC connections let the service reach supported private data sources. Configuring one does not automatically configure the other.[1]

Two paths through the corporate network

Amazon Quick brings together search, analytics, research and automation. Its Quick Sight component can query relational databases. Quick Agents and workflows can call internal APIs or privately hosted model-context-protocol servers. Quick Research can combine enterprise and public information when authorized. Each of these features implies a different route for requests and, potentially, a different set of identity and network controls.[1]

In the documented architecture, a company first connects its on-premises environment to an AWS virtual private cloud using Direct Connect or Site-to-Site VPN. A VPC endpoint takes authorized employee and API traffic privately to the service. Separately, a Quick VPC connection creates interfaces in the company's VPC so data-fetching operations can reach supported private sources. Endpoint policies, security groups, routing, DNS and identity management are additional layers. None is a substitute for the others.[1]

For private knowledge-base connections, the support boundary is particularly narrow: AWS lists Amazon Redshift. Confluence, SharePoint, Box, Google Drive, OneDrive and S3 do not use that Quick VPC-connection mechanism. S3 bucket policies can restrict access through an S3 endpoint separately. A product’s ability to index a source therefore does not establish which private network route supports it.[1]

Where public endpoints remain necessary

The guide lists 13 action-connector and flow-management APIs that the Quick API VPC endpoint does not support. Automation using those operations needs a route to the public API endpoint. Browser authentication and some static assets, client-side metrics and integrations also require controlled outbound access. The architecture can protect selected data paths without making every part of the application air-gapped.[1]

Access restrictions have another important boundary. Quick’s IP and VPC endpoint rules cover web, embedded and mobile access; they do not restrict the public API. AWS directs administrators to IAM conditions such as source IP or source VPC endpoint for API controls. A successful private-browser test therefore does not establish that the API has the same restriction.[1]

Network access and permission to read

The enterprise also must decide what the employee is allowed to learn after reaching the system. Identity federation, row- and column-level data permissions and connector authorization govern access after the network is in place. An agent capable of executing a legitimate database query may still reveal an unauthorized record if application permissions are too broad. Conversely, a carefully restricted user interface is not enough when an automation connector has a highly privileged service account.[1]

AWS recommends testing connectivity before enforcing endpoint restrictions. A useful check follows both journeys: can the employee reach the service through the expected private address, and can Quick reach only the intended source through its separate connection? Testing a request that should fail is as informative as testing one that should succeed. The architecture becomes meaningful when routing and permissions agree about the boundary.[1]

Report an error or suggest a correction