For AWS-hosted applications, you can add PolyScale's IP addresses to your Databases’ security group to restrict access to only these sources for the TCP port of the specific database. For example, MySQL uses
A current list of IP addresses that can be added to the DB's security group are lited below. Please note that this list continues to grow as our AWS edge network expands.
This list can also be retrieved by querying the TXT record:
$ dig -t txt allowlist.polyscale.global +short
Our public endpoints are configured to route your application traffic to the nearest PolyScale Point Of Preence (POP), much like a content delivery network.
This is accomplished by pointing your application's database configuration to
postgres.polyscale.global). Then, configure your database security group to allow traffic from each of the endpoints in the allow list.
PolyScale publishes a VPC endpoint service, which enables connectivity to the PolyScale service directly from within a VPC as an endpoint consumer. This configuration utilizes AWS PrivateLink, which ensures that all traffic between PolyScale's endpoint and your database never leaves the Amazon network and effectively provides a direct 10Gps connection per Availability Zone, capable of bursting up to 40Gbps.
For example, if your application exists in the us-east-1 region, you can simply create a VPC Endpoint, enter the service name
com.amazonaws.vpce.us-east-1.vpce-svc-01cf0410dc501085b, configure security groups, and then once the connection request is accepted, connect to PolyScale using the private DNS name
us-east-1.mysql.polyscale.global. For those who do not want to use our public endpoints, this is the recommended method for connecting to PolyScale.
In addition to VPC Endpoint Services, it is also possible to peer your VPC directly with the PolyScale VPC in a specific region. This is similar to consuming an Endpoint Service, except it is also necessary to configure route tables for subnets where your application resides and risks the potential for a CIDR conflict with PolyScale's private subnet ranges (in which case, VPC Peering would not be the correct method for interfacing with PolyScale services).
Publicly accessible databases significantly increase security risks and exposure to potential security attacks and are strongly discouraged.
PolyScale supports encrypted MySQL connections between clients and the origin database server using the TLS (Transport Layer Security) protocol. TLS/SSL is enabled for MySQL connections to PolyScale as default however to esnure that a secure connection is used, the MySQL client must be configured to both require a secure connection and to verify the supplied server certificate.
TLS is sometimes referred to as SSL (Secure Sockets Layer) but MySQL does not actually use the SSL protocol itself is obsolete. Generally it should be expected that TLS v1.2 will be used for all encrypted connections, although v1.3 is also supported if both client library and server are set to use it.
PolyScale's global edge network employs a DNS failover policy for all database connection endpoints (e.g.
mysql.polyscale.global). In the unlikely event of a Point of Presence (PoP) outage, PolyScale will automatically flag the region as failed, remove the record from DNS, and route traffic via the next closest PoP.
PolyScale DNS includes multiple regions, so requests will always be served by the region that provides the lowest latency.