Anyone who’s spent time with cloud infrastructure has probably heard the acronym “VPC.” It’s a standard building block of cloud architecture. But what are they really? Why does it make sense to architect cloud infra using VPCs?

In this post, we’ll discuss how VPCs work, why you should use them, both in Timescale and your cloud architecture overall, and how they can help secure the services running your cloud-based application.

What's a VPC?

VPC stands for “virtual private cloud.” In a nutshell, it’s a container (in the generic sense, not Docker) for creating network connectivity between the different components and building blocks within public cloud providers like AWS. In the old days, physical servers that needed to communicate with each other were connected with Ethernet cables to network switches in a data center.

In the cloud world, EC2 instances and other serverless components are the “servers,” and VPCs are the “network switches.” That analogy oversimplifies things just a bit, but it’s a good starting point for a mental picture if you’re new to cloud networking.

VPCs are often used to create security perimeters within cloud infrastructure because, by default, instances and services placed in a VPC can communicate only with other endpoints in the same VPC. The “by default” is important, though, because there are often cases where you’d like endpoints in one VPC to be able to communicate with endpoints in a different VPC.

✨

Editor's Note: if you need a step-by-step guide on configuring VPC peering between Timescale and AWS, from the fundamentals to advanced use cases, check out this blog post.

VPC Peering

VPC peering is the simplest way to create connectivity between two different VPCs that allows endpoints in one to communicate with endpoints in another. Imagine a complex cloud service offering with an architecture made up of different tiers or microservice groups. Database, backend, frontend, for example. Each of those with different security requirements, and often built and operated by different teams.

A typical scenario would place each of those groups in a separate VPC, and VPC peering then creates the connectivity between them that allows communication between the groups. To extend our old-school networking analogy, VPC peering is like an Ethernet cable that creates connectivity between servers connected to two different network switches.

Why Use VPC Peering? Common Examples and Use Cases

Integration of Timescale with AWS

A very common scenario we see is that customers have separate sets of Amazon services that put data into Timescale (ingest) and services that get data out (query). Those services are often built by different teams, sit in separate AWS VPCs, and maybe even separate AWS accounts. Examples of Amazon services our customers like to use with Timescale are Lambda, IoT Core and IoT Greengrass, Kinesis, and Managed Kafka—you can read more about them in this blog post.

A diagram of a common Timescale VPC peering scenario: customers who have separate sets of Amazon services that put data into Timescale Cloud (ingest) and services that get data out (query)

Now, each VPC that customers create in Timescale can peer with multiple other AWS VPCs, making it smooth to integrate Timescale within a complex infrastructure of AWS services, as represented by the figure above.

Previously, each Timescale VPC could peer with only a single external VPC, forcing our customers to use less-than-ideal solutions to create connectivity between Timescale and the rest of their AWS infrastructure. These solutions were sometimes painful because they conflicted with their established architectural best practices or security policies. Everything is solved now, thanks to this upgrade!

To start using VPCs and multiple peering connections in Timescale, just sign up and navigate to the VPC page on the left menu. If you’re still not in Timescale, you can create an account for free.

Data analytics by distributed teams

Apart from integration with other AWS services, another common scenario we see for VPC peering is one where analysts who are distributed all over the world may need access to the same Timescale database for their daily analytics tasks. Analysts may be in different offices globally or connected via VPN to regional hubs, with each office or VPN hub attached to a separate VPC.

A diagram of another common Timescale VPC peering scenario: analysts all over the world may need access to the same Timescale Cloud database for their daily analytics tasks

With all the regional VPCs peered to the central infrastructure, services can remain secure while still allowing access for analysts distributed globally. It also avoids suboptimal paths through proxies in other parts of the world that may introduce latency or performance issues for the users.

How Does This Work in Timescale?

When users create services (database instances) in Timescale, by default, they are placed in a public VPC. This means those services have public IP addresses and are reachable from the Internet at large.

While this might be okay for basic testing or development, customers typically don’t want Timescale services exposed to the Internet for production use. So since early in our history, Timescale has supported the ability for users to create up to three private VPCs and attach their Timescale services to those. The VPCs created in Timescale are owned and managed by Timescale—they are not part of the customer’s AWS account.

Previously, for each Timescale VPC, users could create one peering connection to a single VPC in their own AWS infrastructure. This step created connectivity between services running in Timescale VPCs and endpoints in the customer’s other AWS VPC.

Creating a peering connection to a single VPC in the Timescale Cloud UI

Many customers requested the ability to peer multiple AWS VPCs with their Timescale services. So with this new improvement, users can now peer each Timescale VPC with an unlimited number of other VPCs. The UI now shows a list of peering connections for each Timescale VPC, along with status indicators for each connection.

Peering Timescale Cloud VPCs with AWS VPCs in the Timescale Cloud UI

After creating a peering connection in the Timescale UI, users will need to log into their AWS console to accept the peering connection request before the connection is established.

How Much Does VPC Peering Cost?

Timescale charges about $20 / month for each Timescale service (database) that is attached to a Timescale VPC. There is no additional charge for VPC peering connections on top of the base charge for attaching a service to a VPC. That was already the case for the single peering connections we previously supported and is not changing with this multiple peering connection improvement.

Wrap-Up

VPCs are a standard building block of cloud infrastructure, and here at Timescale we’re continuously improving our product to meet our customers’ needs for access and connectivity to Timescale. With multiple peering connections for Timescale VPCs, we’ve made it substantially easier to interconnect Timescale Cloud with the rest of your AWS infrastructure.

Multiple peering connections for Timescale VPCs are now available to configure in the Console for all customers across all AWS regions that we support. Please reach out to Timescale Support (support@timescale.com) or your Customer Success representative for more information or configuration assistance. Every Timescale Cloud customer (and free trial) has access to technical consultative support at no extra cost!

Speaking of a free trial: if you still haven’t tried Timescale, you can sign up for one here. You’ll get full access to the platform for the first 30 days, no credit card required.

Got VPC? Here's Why You Use Them