Securing Quick access from corporate networks with AWS PrivateLink

When enterprise data sits behind a corporate firewall or in a private on-premises data center, there’s no direct network path from AWS, even though the AI agents and dashboards in Amazon Quick can query virtually any data source. Administrators must make sure their sensitive enterprise data isn’t exposed to the public internet while being accessible for AI-driven insights and actions.

For many enterprises, routing traffic over the public internet introduces unacceptable risk. Regulatory frameworks such as HIPAA, FedRAMP, and PCI-DSS often mandate that sensitive data remain within controlled network boundaries. Even where compliance isn’t the primary driver, exposing internal data paths increases the attack surface, complicates audit trails and introduces variable latency that can degrade the user experience.

This walkthrough shows you how to connect on-premises data sources to Amazon Quick privately, without traffic traversing the public internet. It assumes you already have AWS Direct Connect or an AWS Site-to-Site VPN linking your on-premises environment to your virtual private cloud (VPC). From that foundation, we configure VPC endpoints powered by AWS PrivateLink so that Quick can reach your private resources over the AWS backbone, then layer security groups and VPC endpoint policies for defense in depth.

By the end, you will have a network architecture that keeps traffic between Quick and your on-premises data sources off the public internet, reducing the attack surface, providing consistent low-latency connectivity, and giving you a clear audit trail for compliance.

Amazon Quick and establishing private network connectivity

Amazon Quick is an AI-powered workspace that brings search, analytics, research, and automation into a single conversational experience. Understanding which components reach your private network, and how, determines the architecture in the sections that follow.

Data access in Amazon Quick falls into two paths. User-facing traffic covers anyone opening the Quick console, interacting with a dashboard, making an API call, or using Quick Desktop. All this routes through VPC endpoints (see VPC endpoints for user and API access), keeping user sessions off the public internet.

Data-fetching traffic is when Quick itself reaches into your network to pull data. This is handled by VPC connections (see VPC connections for data source access), and it’s where most of the architectural decisions lie. The features and integrations that initiate data-fetching connections are:

• Amazon Quick Sight queries on-premises databases (PostgreSQL, MySQL, SQL Server, Oracle, and others) directly through ENIs placed in your VPC. This is the heaviest consumer of VPC connections.
• Amazon Quick Flows and Amazon Quick Automate are separate automation features. Flows handle repeatable tasks. Automate handles complex, multi-system orchestration with human-in-the-loop. Both invoke action connectors, including MCP servers hosted privately in your VPC. Any workflow that calls an internal API routes through this path.
• Quick Agents underpin all conversational interactions and can invoke action connectors directly. When a custom agent calls a privately hosted MCP server or internal API, traffic flows through the VPC connection.
• Amazon Quick Index builds a unified search layer across connected sources such as Confluence, SharePoint, and Amazon Simple Storage Service (Amazon S3). For data inside your VPC or on premises, knowledge base VPC connections are currently supported only for Amazon Redshift. Sources such as Confluence, SharePoint, Box, Google Drive, OneDrive, and Amazon S3 can’t use a Quick VPC connection today (see Supported VPC data sources). You can still restrict Amazon S3 bucket access to a VPC endpoint through a bucket policy, which is a separate mechanism.
• Amazon Quick Research accesses enterprise sources behind the firewall alongside public internet data for its citation-backed reports, using the VPC connection when reaching private sources.
• Apps in Quick build interactive web applications on top of structured data and action connectors, inheriting the same VPC connectivity as Quick Sight and Flows.
• Quick Spaces organize content from the preceding features but don’t initiate their own data connections.

These two traffic paths require two distinct private connectivity mechanisms that work together:

• VPC endpoints (AWS PrivateLink): Handle user-facing traffic such as accessing the Quick website, making API calls, and administrative access. These keep user traffic off the public internet.
• VPC connections: Handle data source traffic. Amazon Quick reaches into your VPC (and by extension, your on-premises network) to fetch data from databases, Amazon Redshift knowledge base sources, and internal APIs. These are configured within the Quick console.

Configuring private connectivity

This section walks through the four building blocks in order: VPC endpoints for user and API access, VPC connections for data source access, VPC endpoints for AWS data services, and outbound access to required external domains.

Prerequisites

Before configuring private connectivity for Quick, make sure the following are in place:

• An active AWS account with an Amazon Quick Enterprise subscription (VPC connections require Enterprise edition).
• An existing VPC in the AWS Region where Quick is deployed.
• A supported AWS Region. Quick website VPC endpoints are not available in the AWS China Regions or the AWS GovCloud (US) Regions.
• An AWS Direct Connect connection or Site-to-Site VPN established between your on-premises network and your VPC. This is the private path that carries traffic from your data center into AWS.
• AWS Identity and Access Management (IAM) permissions to create and manage VPC endpoints, security groups, and Quick administration. To create VPC connections, the administrator’s IAM identity also needs quicksight:CreateVPCConnection, quicksight:DescribeVPCConnection, quicksight:ListVPCConnections, quicksight:UpdateVPCConnection, quicksight:DeleteVPCConnection, ec2:DescribeSubnets, ec2:DescribeVpcs, ec2:DescribeSecurityGroups, iam:ListRoles, and iam:PassRole scoped to the VPC connection execution role.
• Access to your organization’s DNS management (Route 53 private hosted zones or on-premises DNS forwarders), as private DNS resolution routes traffic through VPC endpoints rather than public addresses.

VPC endpoints for user and API access (AWS PrivateLink)

VPC endpoints powered by PrivateLink handle all user-facing traffic to Amazon Quick, including the website, API calls, and embedded content. They prevent users from needing to traverse the public internet to access the Amazon Quick console.

As shown in Figure 1: (1) a client on the corporate network sends a request to Quick; (2) the request travels over AWS Direct Connect, through the Direct Connect gateway, into your VPC; (3) the Quick VPC endpoint evaluates the endpoint policy and allows or denies the request; (4) allowed requests reach Amazon Quick over the AWS network.

Planning your VPC endpoint architecture

When planning your endpoint architecture, begin by identifying the AWS Region where your Quick account is deployed, as VPC endpoints must be in the same Region. Choose subnets across multiple Availability Zones for endpoint ENI placement, and make sure those subnets have routes to your on-premises network through Direct Connect or VPN.

Design security groups that restrict traffic on the endpoint ENIs to only required ports and source ranges. If you want all traffic routed privately (including the calls Amazon Quick makes to Amazon S3, Amazon Redshift, and Amazon Athena), plan VPC endpoints for those services as well (see Configuring data source VPC endpoints).

Creating VPC endpoints for Quick

Quick requires two interface VPC endpoints for full private access:

• Website access endpoint – Service name com.amazonaws.<region>.quicksight-website. This handles the bulk of user traffic to the Quick console. Private DNS names for the Quick website differ from the public URL, so you must create an A record for <region>.quicksight.aws.amazon.com pointing to the VPC endpoint.
• API access endpoint – Service name com.amazonaws.<region>.quicksight. This handles programmatic API calls. When private DNS is enabled, existing API calls to quicksight.<region>.amazonaws.com automatically route through the VPC endpoint with no additional DNS configuration. For FIPS compliance, use com.amazonaws.<region>.quicksight-fips.

Note: Not every Quick API is available through the API VPC endpoint. The following 13 APIs are not supported: the action connector APIs (CreateActionConnector, DeleteActionConnector, DescribeActionConnector, DescribeActionConnectorPermissions, ListActionConnectors, SearchActionConnectors, UpdateActionConnector, UpdateActionConnectorPermissions) and the flow APIs (GetFlowMetadata, GetFlowPermissions, ListFlows, SearchFlows, UpdateFlowPermissions). Automation that manages action connectors or flows programmatically needs a path to the public API endpoint. See Quick and interface VPC endpoints.

If administrators sign in to Amazon Quick as IAM users through the VPC, also create the AWS Management Console endpoints:

• com.amazonaws.<region>.console.
• com.amazonaws.<region>.signin.

To create the website endpoint in the Amazon Virtual Private Cloud (Amazon VPC) console:

1. Open the Amazon VPC console. In the navigation pane, under PrivateLink and Lattice, choose Endpoints, then choose Create endpoint.
2. Enter a Name tag (for example, my-quicksight-vpc-endpoint) and, for Type, choose AWS services.
3. Under Services, search for com.amazonaws.<region>.quicksight and select com.amazonaws.<region>.quicksight-website (Figure 2).

Figure 2: Naming the endpoint and selecting the Quick website endpoint service

4. Under Network settings, select your VPC. Under Additional settings, keep Enable private DNS name selected.
5. Select subnets in at least two Availability Zones, then select the security group for the endpoint ENIs (Figure 3).

Figure 3: Selecting the VPC, private DNS, subnets, and security group for the endpoint

6. Choose a Policy (see the following Setting up VPC endpoint policies section), add tags, and choose Create endpoint (Figure 4).

Figure 4: Choosing the endpoint policy and creating the endpoint

7. Repeat these steps for the API endpoint, com.amazonaws.<region>.quicksight.

Configuring DNS resolution

For the website endpoint, create an A record for <region>.quicksight.aws.amazon.com and point it to the VPC endpoint DNS name. This way, when users on your corporate network resolve the Quick URL, traffic routes through the private endpoint rather than the public internet. For the API endpoint, enabling private DNS on the VPC endpoint is sufficient, as API calls automatically resolve to the endpoint’s private IP addresses.

A Route 53 private hosted zone only answers queries from inside the VPCs associated with it. Because your users connect from the corporate network, configure your on-premises DNS servers to forward queries for <region>.quicksight.aws.amazon.com to a Route 53 Resolver inbound endpoint in the VPC (or host an equivalent record in your on-premises DNS). Finally, validate DNS resolution from your corporate network to confirm that requests resolve to private IPs within your VPC rather than public addresses.

To create the record in Route 53:

1. In the Route 53 console, choose Hosted zones, then Create hosted zone.
2. For Domain name, enter <region>.quicksight.aws.amazon.com (for example, us-east-1.quicksight.aws.amazon.com). Scoping the zone to your Region avoids overriding other Quick host names. Choose Private hosted zone, associate your VPC, and choose Create hosted zone (Figure 5).

Figure 5: Creating a private hosted zone in Amazon Route 53

3. In the new hosted zone, choose Create record (Figure 6).

Figure 6: Creating a record in the new private hosted zone

4. Leave Record name blank, choose record type A, turn on Alias, choose Alias to VPC endpoint, select your Region and the website endpoint’s DNS name, and choose Create records (Figure 7).

Figure 7: Creating an alias A record that points to the Quick website VPC endpoint

Setting up VPC endpoint policies

VPC endpoint policies restrict which accounts or organizations can use the endpoint. For Quick, policies can be scoped by AWS account ID or Organization ID. To change a policy, open the endpoint in the Amazon VPC console, choose the Policy tab, and choose Edit Policy (Figure 8).

Important limitation: For the Quick website endpoint, the Principal, Action, and Resource fields must all be set to *. Conditions might only be specified against the aws:PrincipalAccount or aws:OrgId attributes. More restrictive action-level policies are only supported on the API endpoint.

Website endpoint policy example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

Figure 8: Opening the endpoint policy from the VPC endpoint details page

API endpoint policy example (restricted to specific actions):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "quicksight:DescribeUser",
                "quicksight:ListUsers"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": ["012345678901"]
                }
            }
        }
    ]
}

Figure 9: Editing a custom VPC endpoint policy

VPC connections for data source access

While VPC endpoints handle user-facing traffic, VPC connections handle the server-side path, meaning Amazon Quick reaches into your VPC to access databases, Amazon Redshift knowledge base sources, and internal APIs.

How VPC connections work

Amazon Quick Enterprise edition is fully integrated with Amazon VPC. When you create a VPC connection in Amazon Quick, you are adding elastic network interfaces (ENIs) into your VPC subnets. These ENIs allow Quick to exchange network traffic with resources within your VPC and, by extension, anything reachable from that VPC, including on-premises systems connected through Direct Connect or VPN.

All standard VPC security controls apply to this traffic. Route tables, network ACLs, subnets, and security groups govern traffic to and from Quick in the same way they govern traffic between any other instances in your VPC. This means you can connect to:

• Private databases not exposed to the public internet.
• On-premises data sources reachable through Direct Connect or VPN.
• Internal APIs accessible by IP address within your network.

Create a dedicated security group (for example, QuickSight-VPC) for the VPC connection ENIs. On each data source’s security group, allow inbound traffic on the database port from that security group ID.

Note for VPC connections created before April 27, 2023: The security group attached to the Quick network interface is not stateful. You must add an inbound rule that explicitly allows return traffic from your data source’s security group on all ports (0–65535), because return packets use randomly allocated destination ports. Connections created after that date use standard stateful behavior. See Security groups: inbound and outbound rules.

Creating the execution role

Amazon Quick doesn’t create the VPC connection execution role for you. Before you add the connection, create a dedicated IAM role (recommended), or update an existing role that already trusts Quick, such as aws-quicksight-service-role-v0 used in the screenshots in this post. The role needs:

• A permissions policy that grants the Amazon Elastic Compute Cloud (Amazon EC2) actions Quick uses to manage its ENIs (Figure 10).
• A trust policy that allows quicksight.amazonaws.com to assume the role. Only roles with this trust policy appear in the Execution role list in the Quick console.

Permissions policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": "*"
        }
    ]
}

Figure 10: Adding the Amazon EC2 permissions required by the VPC connection execution role

Trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": { "Service": "quicksight.amazonaws.com" },
            "Action": "sts:AssumeRole"
        }
    ]
}

Configuring a VPC connection

To create a VPC connection in the Quick console:

1. Sign in to Amazon Quick as an administrator. Choose your profile icon in the upper-right, then choose Manage account (Figure 11). If you don’t see this option, you’re not a Quick administrator.

Figure 11: Opening Manage account from the Quick profile menu

2. In the navigation pane, under Security, choose Manage VPC connections (Figure 12), then choose Add VPC connection.

Figure 12: Manage VPC connections under Security on the Manage account page

3. Provide the following (Figure 13):
   1. A descriptive VPC connection name.
   2. The VPC ID of the target VPC. This can’t be changed later.
   3. The Execution role you created in the previous step.
   4. At least two subnets in different Availability Zones.
   5. At least one security group ID.
   6. (Optional) If your database host name must be resolved through private DNS, enter the IP addresses of your Route 53 Resolver inbound endpoints under DNS resolver endpoints.
4. Choose ADD.

Figure 13: Adding a VPC connection in the Quick console

The connection status shows UNAVAILABLE until Quick finishes provisioning the ENIs, then changes to AVAILABLE. A status of PARTIALLY AVAILABLE means one of the ENIs is unavailable, but the connection can still be used.

Configuring data source VPC endpoints

VPC endpoints (PrivateLink, used here for AWS service APIs) and VPC connections (Quick ENIs placed in your VPC; see VPC connections for data source access) are different mechanisms. Quick accesses other AWS services (Amazon S3, Amazon Redshift, Amazon Athena, AWS Secrets Manager) when retrieving data for dashboards and analytics. If you want all traffic to remain private, including the calls Amazon Quick makes to these AWS services, create interface or gateway VPC endpoints for each:

* Athena isn’t supported as a VPC connection data source. The Athena endpoint keeps Athena API traffic on AWS PrivateLink only.

Create these endpoints in the same VPC where the Amazon Quick ENIs are placed. Make sure route tables and security groups allow traffic between the Amazon Quick subnets and the endpoint subnets.

Enabling access to required external domains

While data traffic between Quick and your on-premises sources stays on the private network, users’ browsers still need to reach a set of domains for sign-in, static assets, client-side metrics, and integrations. Even with VPC endpoints configured, domains without VPC endpoint support need outbound connectivity, typically through your corporate proxy or firewall. If your account uses IAM Identity Center, browser sign-in also requires the public AWS sign-in and IAM Identity Center endpoints (see Secure user access and identity federation).

Required external domains

Source: Domains accessed by Quick.

Configuration guidance:

• For domains with VPC endpoint support (the Quick website and API, signin.aws.amazon.com, and Amazon S3), create the corresponding VPC endpoints and DNS records.
• For domains without VPC endpoint support, allow them through your corporate internet egress (outbound proxy or firewall). If user traffic egresses through your VPC, use a NAT gateway in a public subnet.
• If your security posture requires URL-level filtering, use an outbound proxy or AWS Network Firewall domain filtering rules to allow only the domains listed earlier.
• Test from a corporate workstation (or an instance in the same egress path): nslookup and curl against each domain confirm DNS resolution and routing.

Enforcing VPC endpoint restrictions

After your endpoints are configured and tested, you can enforce that all access to your Quick account must come through the VPC endpoint, blocking general internet access entirely. As a result, users can only reach Quick from your corporate network through the private path you’ve established.

Quick provides IP and VPC endpoint restriction controls that limit account access to a predefined list of IP ranges, VPC IDs, or VPC endpoint IDs. For example, you can create a rule that allows access only from the VPC endpoint used for Direct Connect, meaning anyone attempting to reach Quick from the public internet will be denied.

To configure through the Quick console (only administrators signed in with IAM credentials can access the restrictions page):

1. Choose your profile icon, then Manage account. Under Security, choose Manage IP/VPC restrictions.
2. In the Restriction field, enter the VPC endpoint ID (for example, vpce-001122def), enter a Description, and choose Add (Figure 14).
3. Choose Save changes to apply the rule.
4. Turn on Enforce restrictions.

Figure 14: Adding a VPC endpoint rule on the IP and VPC endpoint restrictions page

Alternatively, configure through the AWS Command Line Interface (AWS CLI):

aws quicksight update-ip-restriction \
--aws-account-id ACCOUNT_ID \
--region REGION \
--enabled \
--vpc-endpoint-id-restriction-rule-map \
vpce-001122def=CorporateVpcEndpoint

Note: UpdateIpRestriction replaces the entire rule map. Retrieve your current rules with aws quicksight describe-ip-restriction and include any existing rules in the update.

Key considerations:

• IP and VPC endpoint rules apply to Quick web, embedded, and mobile access, meaning they don’t restrict access to the public API. To restrict API calls from specific sources, use IAM policies with aws:SourceIp or aws:SourceVpce conditions.
• Make sure your own IP or VPC endpoint is included in the rules before enabling restrictions, otherwise you will lock yourself out.
• Rules can take up to 10 minutes to take full effect.
• You can combine IP rules and VPC endpoint rules, such that traffic is allowed if it satisfies either rule type. You can add up to 100 IP and VPC endpoint rules combined.
• IP and VPC endpoint rules are enforced across all AWS Regions for your account, but you can only add or manage them from the AWS Region where your Quick account was created.
• If you have publicly embedded dashboards, they will only be accessible through the VPC endpoint once restrictions are enabled.

After you enforce the restrictions, only traffic arriving through the specified VPC endpoint (or allowed IP ranges) can reach your Quick account. All other access is denied.

Secure user access and identity federation

Private network connectivity keeps traffic off the public internet, but it doesn’t answer the question of who can access what within Quick. This section covers how to integrate your corporate identity provider, control user provisioning, and enforce fine-grained access segmentation across Quick components.

Integrating with AWS IAM Identity Center

Important: For Quick accounts integrated with IAM Identity Center, browser-based authentication requires access to the public AWS sign-in and IAM Identity Center endpoints. VPC endpoints don’t provide this browser sign-in path. Public IP addresses aren’t required. Provide outbound connectivity through a NAT gateway or proxy. See Considerations for private access in the IAM Identity Center User Guide.

Amazon Quick uses AWS IAM Identity Center as the central point for workforce identity management. IAM Identity Center connects to your existing corporate identity provider (IdP) using SAML 2.0 for authentication and SCIM 2.0 for automatic user and group provisioning. This provides:

• Automatic user provisioning and deprovisioning synced from your IdP.
• Group membership synchronization – when a user is added to or removed from a group, that change propagates to Quick.
• Single sign-on (SSO) using existing corporate credentials.
• Temporary credentials through assumed IAM roles – no long-lived Quick-specific passwords.

For a step-by-step guide on setting up IAM Identity Center with your identity provider, see Getting started with IAM Identity Center.

Role-based access in Quick

Quick supports three base roles that determine what a user can do:

• Admin – Full management access including data source configuration, VPC connections, security settings, user management, and SPICE capacity purchasing.
• Author – Can create and publish dashboards, build agents, configure Spaces, manage data sources, create flows, and build apps.
• Reader – Can view published dashboards, interact with agents, use Spaces they’ve been granted access to, and consume Quick Research reports.

These roles are mapped to IAM roles that federated users assume at sign-in. By managing role assignment in your IdP, you maintain a single source of truth for who has what level of access.

Additionally, Quick supports custom permissions profiles that can override default role permissions at the account, role, or user level. User-level permissions override role-level, which in turn override account-level. This gives administrators granular control beyond the three base roles.

User segmentation with Spaces

Quick Spaces provide an additional layer of access segmentation beyond roles. Each Space can be configured with specific user and group permissions, meaning:

• A finance team Space containing sensitive revenue dashboards and financial knowledge bases is only accessible to the finance group.
• A sales team Space with CRM-connected agents and pipeline dashboards is restricted to sales users.
• Cross-functional Spaces can be shared across multiple groups with appropriate permissions.

Space-level access is controlled by the groups synced from your identity provider, so adding a new team member to the appropriate group automatically grants them access to the relevant Spaces.

Row-level security in Quick Sight

For dashboards backed by structured data, Quick Sight supports row-level security (RLS) that restricts which data rows each user or group can see. RLS is configured through dataset rules, which are a permissions dataset that maps users or groups to the field values they can access.

For example, a regional sales dashboard can be configured so that:

• The EMEA sales group only sees rows where region = 'EMEA'.
• The NA sales group only sees rows where region = 'NA'.
• The VP of Sales sees all rows.

RLS rules are evaluated based on the user’s identity as determined by IAM Identity Center, meaning the same identity federation that controls sign-in also governs data-level access. This applies equally to traditional dashboard views and AI-powered natural language queries. The same security policies restrict what data the AI can reference when generating answers.

Column-level security

In addition to row-level restrictions, Quick Sight supports column-level security (CLS) to hide sensitive columns from specific users or groups. For example, a dataset containing employee information might restrict the salary and SSN columns to only the HR group, while other groups can still access non-sensitive columns in the same dataset.

How identity ties to private connectivity

The identity layer and network layer work together:

1. A user on the corporate network authenticates through your IdP → IAM Identity Center → Quick.
2. Their request reaches Quick through the VPC endpoint (the private network path; see VPC endpoints for user and API access).
3. Quick evaluates their identity to determine role, Space access, and RLS/CLS policies.
4. When Quick fetches data from an on-premises source, it uses the VPC connection (ENIs in your VPC; see VPC connections for data source access) to reach the database over Direct Connect.
5. The response is returned to the user through the same private path.

Apart from the sign-in and static-asset traffic described under Enabling access to required external domains, no traffic traverses the public internet, and at every point the user’s identity determines what they can see and do.

Validation and testing

Before enforcing restrictions in production, validate end-to-end connectivity for each access pattern:

Monitoring

For ongoing visibility, enable VPC Flow Logs on all endpoint and VPC connection ENIs to capture traffic metadata. Monitor CloudWatch metrics on VPC endpoints (ActiveConnections, BytesProcessed, PacketsDropped) and set alarms for connection failures or unexpected traffic sources. These logs also serve as the audit trail referenced in your compliance documentation.

Troubleshooting common issues

Security best practices

Neither network isolation nor identity controls alone is sufficient. This architecture relies on both: network controls prevent unauthorized access paths, while identity controls prevent unauthorized data access within authorized sessions. The practices below maintain both layers.

• Least-privilege endpoint policies: Restrict website endpoints by aws:PrincipalAccount or aws:OrgId. On API endpoints, scope policies to only the specific actions your automation requires rather than allowing all quicksight:* actions.
• Layered security groups: Apply security groups to both VPC endpoint ENIs (user traffic) and VPC connection ENIs (data traffic). On endpoint ENIs, restrict inbound HTTPS to your corporate CIDR ranges. On VPC connection ENIs, use a dedicated security group, restrict outbound to only the database ports and destinations Quick needs, and reference that security group in each data source’s inbound rules.
• Enable VPC Flow Logs on all endpoint ENIs: These logs capture traffic metadata for security monitoring, anomaly detection, and compliance auditing. They also provide the audit trail that regulatory frameworks require for controlled network boundaries.
• Audit endpoint policies regularly: Review endpoint policies quarterly. Use AWS Config rules to detect drift from your baseline configuration.
• Separate VPC connections by sensitivity: If you have multiple data environments (dev, staging, production), create separate VPC connections with distinct security groups to prevent cross-environment access.
• Monitor with CloudWatch: Set alarms on PacketsDropped and ActiveConnections metrics. Unusual patterns may indicate misconfiguration or attempted unauthorized access.

Example Requirements and AWS Configuration

The following examples show how the configuration in this post can address common security network requirements. Evaluate them against your own requirements with your security team.

Cost considerations

Cost optimization tips:

• Use gateway endpoints (no additional charge) for S3 instead of interface endpoints where possible.
• Consolidate endpoint ENIs: each endpoint only needs ENIs in the AZs where the Amazon Quick VPC connection subnets reside.
• Enable VPC Flow Logs selectively on endpoint ENIs rather than the entire VPC.
• Consider whether all external domains need NAT gateway access or whether a targeted proxy would be more cost-effective for your traffic patterns.

Conclusion

This architecture establishes four complementary controls: VPC endpoints keep user traffic private, VPC connections give Quick a private path to your data sources, identity federation determines who can access what, and VPC endpoint restrictions make the private path mandatory. Each layer is independently auditable and maps to specific compliance requirements (see Compliance mapping).

With this in place, Quick Agents can query your on-premises databases, Quick Research can investigate enterprise sources behind the firewall, Quick Sight dashboards can visualize sensitive data, and Quick Flows can orchestrate internal systems, all without your data traversing the public internet. The AI capabilities are unchanged. The exposure is removed.

To implement, start with the VPC endpoints for user and API access, and validate user access before progressing to the VPC connections for data source access. Enable VPC endpoint restrictions only after confirming all access patterns work through the private path. For identity federation setup and advanced RLS/CLS configuration, refer to the IAM Identity Center documentation.

About the authors