Private Endpoint Access

This page describes a feature that is not enabled by default. Ask your Quilt manager to enable it for you.

The Data Perimeter concept

Establishing a data perimeter pattern that only allows access to trusted principals from trusted networks is a best practice to guarantee your organization's data security. A data perimeter helps protect your data from unintended access and potential configuration errors via built-in barriers.
You can restrict Amazon S3 bucket access to a particular VPC and VPN traffic via a data perimeter pattern, which prevents leaked S3 credentials from bypassing your organization's VPN.
Quilt already has private IPs for all Quilt services (Lambda functions, API Gateway, Quilt catalog API).
To implement a data perimeter, you will need to take the following steps.

1. Configure an Amazon S3 Gateway endpoint

To limit access to Amazon S3 from your VPC you use gateway VPC endpoints. Note that there is no additional charge for using gateway endpoints.
Follow the official AWS instructions to create a gateway endpoint.
Alternatively you can use AWS PrivateLink for Amazon S3 to provision interface VPC endpoints (interface endpoints) in your VPC. These are assigned private IP addresses from subnets in your VPC.

2. Configure NAT gateway

To allow Quilt services access AWS endpoints other than S3 the traffic from the subnets where Quilt is deployed to the internet should be routed through NAT gateway.
Follow the official AWS instructions to create a NAT gateway.

3. Configure and deploy a Service Control Policy and Amazon S3 bucket policy

Access should be restricted to trusted networks and principals:
  • Allowed VPCs
  • Allowed IP ranges
  • Specific AWS services used by Quilt:
    • AWS Glue
    • Amazon Athena
    • Amazon CloudWatch
  • Principals exempt from network restriction
The easiest way to do this is via a Service Control Policy (SCP)
An SCP defines a guardrail on any action that the account's administrator delegates to the IAM users and roles in the account.
For instructions on enabling SCPs, see the AWS documentation on "Enabling and disabling policy types"

Example Service Control Policy

The example policy below denies access ("Effect": "Deny") to all Amazon S3 buckets prefixed with the string quilt unless any of the following conditions is met:
  1. 1.
    A Source VPC matches either vpc-LOCAL or vpc-VPN.
  2. 2.
    The principal making the request has NetworkRestrictedExempt tag attached.
  3. 3.
    The request comes from IP range - or -
  4. 4.
    The call to the S3 bucket is beng made by an AWS service principal (the idenitifer for a service, "aws:PrincipalIsAWSService"), such as CloudWatch, or by an AWS service to another service ("aws:ViaAWSService").
"Version": "2012-10-17",
"Statement": [
"Sid": "PreventUnexpectedNetworksButAllowAWSServices",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"Null": {
"aws:PrincipalTag/NetworkRestrictedExempt": "true"
"NotIpAddressIfExists": {
"aws:SourceIp": [
"Bool": {
"aws:PrincipalIsAWSService": "false",
"aws:ViaAWSService": "false"
SCPs should be used in parallel with identity-based or resource-based policies to IAM users or roles, or explicit S3 bucket policies

Making sure everything is correctly set up

After doing steps above please check your canaries status to make sure everything works as expected.

Important considerations

  1. 1.
    There can only be one gateway endpoint per VPC.
  2. 2.
    Your S3 buckets must be in the same region as the gateway endpoint.
  3. 3.
    Keeping traffic on private networks will incur Transit Gateway, inter-VPC, and Interface Endpoint charges.
  4. 4.
    The DNS of any VPN clients must assign AWS global and regional S3 service names to the Interface Endpoint IP addresses.

Further reading