Skip to content

Private endpoints

Connect your services to AWS PrivateLink endpoints to eliminate public internet exposure

With Tiger Cloud, you can connect your services to AWS PrivateLink endpoints. A private endpoint in your VPC routes traffic to your service over the AWS backbone, without crossing the public internet or requiring VPC peering. This page describes how to create a private endpoint on the AWS side, claim it in Tiger Console, attach a service to it, and publish the service hostname in your own private DNS zone.

Private networking does not turn off console passwordless connections. If your security policy requires users to connect through your private network, also turn off passwordless database access for each service.

You control DNS resolution for your service over PrivateLink. In a private hosted zone attached to your VPC, you point the standard service hostname at your VPC endpoint. Because you publish the same hostname that the public internet path uses, your connection strings and the service certificate work as before.

Prerequisites for this procedure

To follow these steps, you'll need:

LimitValue
Services per VPC endpoint1
VPC endpoints per service2

Each VPC endpoint serves a single service, so create one endpoint for every service you connect to. Each service accepts up to two endpoints, which lets you reach it from two VPCs.

AWS also applies its own default quota of 50 interface and Gateway Load Balancer endpoints per VPC, which you can raise through AWS Support.

Tiger Cloud serves PrivateLink from two Availability Zones in each region. Create your VPC endpoint in both of them: one for the connection to work, the second so it survives the loss of an Availability Zone.

RegionAvailability Zone IDs
ap-northeast-1apne1-az1, apne1-az4
ap-south-1aps1-az1, aps1-az3
ap-southeast-1apse1-az1, apse1-az2
ap-southeast-2apse2-az1, apse2-az2
ca-central-1cac1-az1, cac1-az2
eu-central-1euc1-az1, euc1-az2
eu-central-2euc2-az1, euc2-az2
eu-west-1euw1-az2, euw1-az3
eu-west-2euw2-az2, euw2-az3
sa-east-1sae1-az1, sae1-az2
us-east-1use1-az1, use1-az6
us-east-2use2-az1, use2-az2
us-west-2usw2-az3, usw2-az4
Important

Match on the Availability Zone ID, such as use1-az1, not the Availability Zone name, such as us-east-1a. AWS maps names to physical zones differently in every account, so the same name points to a different zone for you than it does for Tiger Cloud. When you choose subnets, the AWS console shows both in the us-east-1a | use1-az1 form.

Take the following steps to connect your Tiger Cloud service to a PrivateLink endpoint.

  1. Copy the alias for your region
    1. In Tiger Console, select Security > Private Endpoints > Manage endpoints.

    2. Under Create the endpoint, copy the Alias for the region in which you need to create the connection. Choose the region of your AWS resources.

      Copying the region alias in the Manage endpoints panel
  2. Create a VPC endpoint in AWS
    1. In AWS Console, go to VPC > Endpoints > Create endpoint.

    2. Optionally provide a name tag for your endpoint.

    3. Under Type, select PrivateLink Ready partner services.

      AWS create endpoint settings
    4. Under Service settings > Service name, paste in the alias your copied in Tiger Console and click Verify service. Wait for the Service name verified. success message.

      AWS endpoint service settings
    5. Select the VPC that contains the resources you want to connect to Tiger Cloud, then choose the subnets where the endpoint’s private IPs are created. Select a subnet in both of the Availability Zones listed for your region in Availability zones. Selecting only one leaves you without failover, and selecting any other Availability Zone creates an interface that cannot reach your service.

      Selecting a subnet in each of the two Availability Zones, listed by Availability Zone ID
    6. Optionally configure the security groups and tags, then click Create endpoint.

    7. Copy the VPC endpoint ID of your new endpoint. You claim the connection with this ID:

      The VPC endpoint ID of a new AWS endpoint
  3. Claim the connection
    1. In Tiger Console > Security > Private Endpoints, click Manage endpoints.

    2. Under Claim it, paste your VPC endpoint ID into Endpoint identifier, then click Claim connection. Tiger Cloud links the connection to the project you are working in, and it appears in the list.

      Claiming a private endpoint connection with the endpoint identifier
      Note

      You can claim a VPC endpoint against one project only.

      Your VPC endpoint ID can also take a minute to become claimable after you create the endpoint in AWS.

  4. Attach a service

    Under Services click Attach service. Select your service from the dropdown and click Attach. You can attach a service to one private endpoint.

  5. Publish the service hostname in your private DNS

    You resolve your service hostname to your VPC endpoint in a private hosted zone that you control.

    1. In Route 53, create a private hosted zone for <project-id>.tsdb.cloud.timescale.com. Set Type to Private hosted zone.

      Creating a private hosted zone for the project domain

      Under VPCs to associate with the hosted zone, select the region and the VPC that contains your resources. If you already have a private hosted zone for this domain, use it instead of creating another.

      Associating the private hosted zone with the VPC that contains your resources
    2. In that zone, create a record for your service hostname, <service-id>.<project-id>.tsdb.cloud.timescale.com. Create an A record, enable Alias, choose Alias to VPC endpoint, then select your region. An alias record resolves in a single step and Route 53 does not charge for queries to it, so prefer it over a CNAME.

      The endpoint dropdown lists three names for your endpoint: one regional and one for each Availability Zone. Select the regional name, which has no Availability Zone in it:

      vpce-<id>-<hash>.vpce-svc-<id>.<region>.vpce.amazonaws.com

      The zonal names carry the Availability Zone just before .vpce-svc-, as in vpce-<id>-<hash>-us-east-1a.vpce-svc-<id>.... The regional name resolves across every healthy interface, so traffic fails over if an Availability Zone goes down. A zonal name pins traffic to one zone and fails with it.

      Creating an A record aliased to the regional VPC endpoint name
    3. If your service has a read endpoint, add a second record for <service-id>-repl.<project-id>.tsdb.cloud.timescale.com, pointing at the same VPC endpoint. This is the address of your service‘s replicas, shown as Read endpoint in your connection details.

    4. If you use the connection pooler, it is reached at the primary hostname on its own port, so it needs no record of its own. Add the pooler port to your connection string instead.

      Find your service ID and project ID in your connection details.

    Note

    Your private hosted zone overrides public DNS for everything under it, in every VPC you associate it with. A zone for <project-id>.tsdb.cloud.timescale.com takes over resolution for all services in that project, not only the ones you add records for. A hostname in that zone with no record returns NXDOMAIN instead of falling back to the public address, so clients in those VPCs can no longer reach that service over the internet. Add a record for every service those clients connect to.

  6. Test the connection

    Run these from an EC2 instance inside the VPC you associated with the hosted zone. They fail from anywhere else, including your laptop, because the hostname resolves to private addresses.

    1. Check that your zone resolves the hostname to your endpoint:

      Terminal window
      dig +short <service-id>.<project-id>.tsdb.cloud.timescale.com

      You get one private IP for each Availability Zone your endpoint spans. Two addresses means both zones can serve you. One address means the endpoint exists in a single Availability Zone and you have no failover.

      No answer at all means the zone is not resolving. Check that the hosted zone is associated with this VPC, and that the record name matches the hostname exactly.

    2. Check that the endpoint accepts connections on the port for this endpoint:

      Terminal window
      nc -zv <service-id>.<project-id>.tsdb.cloud.timescale.com <port>

      A timeout here, rather than a refusal, usually means the endpoint’s security group does not allow inbound traffic on that port from this instance.

    3. Connect, verifying the certificate:

      Terminal window
      psql "postgres://tsdbadmin@<service-id>.<project-id>.tsdb.cloud.timescale.com:<port>/tsdb?sslmode=verify-full"

      sslmode=verify-full is the point of publishing Tiger Cloud‘s hostname rather than the endpoint’s own name: it proves you reached your service privately and that the certificate matches. If this succeeds, your setup is correct. For how to supply the certificate and make this mode your default, see Connect with a stricter SSL mode.

    4. If you added a record for the read endpoint, repeat the check against it, using its own port:

      Terminal window
      psql "postgres://tsdbadmin@<service-id>-repl.<project-id>.tsdb.cloud.timescale.com:<port>/tsdb?sslmode=verify-full"
    Warning

    Ports are specific to each endpoint. Tiger Cloud uses the standard 5432 where it can, but this is not guaranteed, and your primary and your read endpoint listen on different ports. Never assume a port: always use the one shown for that endpoint in your connection details.

If you set up PrivateLink before Tiger Cloud supported private DNS that you control, you configured your connection by adding the endpoint IP address in Tiger Console, and Tiger Cloud published the DNS records for you. That flow is retired.

To see whether this applies to you, open Security > Private Endpoints in Tiger Console and look at the IP Address column for your connection. If it is empty, you are already resolving through your own zone and you can skip this section. If it shows an address, follow the steps below to move to your own private DNS.

  1. Publish the hostname in your own zone

    Create the records described in Publish the service hostname in your private DNS, then run the checks in Test the connection before you continue.

    While your connection still has an IP address configured, the dig output shows which records are answering: one private IP per Availability Zone your endpoint spans means your own zone is live, and a single IP address means you are still resolving through the records Tiger Cloud publishes. If your endpoint spans a single Availability Zone, both answers are one address, so compare it against the IP address shown in Tiger Console instead.

  2. Remove the IP address in Tiger Console

    In Security > Private Endpoints, remove the IP address from your connection. This deletes the DNS records that Tiger Cloud published and hands resolution to your zone.

    Warning

    Your own zone must already resolve the service hostname before you remove the IP address, otherwise connections fail until your DNS is in place. If that happens, add the IP address back in Tiger Console to restore the records Tiger Cloud publishes, then try again once your zone resolves the hostname.

  • To detach a service from a private endpoint connection, go to Security > Private Endpoints, expand the arrow in the Services column, and click the trash icon next to the service connection string.
  • To edit or remove an endpoint connection, go to Security > Private Endpoints and click the three dots next to the connection in the list. Select Edit or Disconnect, respectively. You need to detach all services from a private endpoint connection before deleting it.