Glossary
Virtual Private Cloud (VPC)
Your own private network inside someone else’s cloud. A VPC gives an organisation isolated address space, subnets and firewall rules on AWS, Google Cloud or Azure, which is where regulated workloads such as a dedicated chat server are expected to live.
General definition
A Virtual Private Cloud (VPC) is the networking boundary a cloud provider gives each customer: a software-defined network that behaves like a private data-centre LAN but runs on shared physical infrastructure. The customer chooses an address range (for example 10.0.0.0/16), divides it into subnets across availability zones, decides which subnets can reach the internet and which are private, and controls traffic with security groups and network access control lists. AWS uses the term VPC; Google Cloud also calls it VPC; Azure’s equivalent is the Virtual Network (VNet).
- Public and private subnets: load balancers sit in public subnets; databases, message servers and model inference stay in private ones with no inbound route from the internet
- Gateways: an internet gateway for public traffic, a NAT gateway so private instances can fetch updates without being reachable
- Private connectivity: VPC peering, transit gateways and private endpoints (such as AWS PrivateLink) connect to other VPCs and to provider services without crossing the public internet
- Hybrid links: site-to-site VPN or a dedicated line (AWS Direct Connect, Azure ExpressRoute) joins the VPC to an on-premise network
- Logging: flow logs record accepted and rejected traffic for security review
The VPC is why the phrase “runs in your own cloud account” carries weight in security reviews. A workload inside the customer’s VPC is subject to the customer’s firewall rules, identity policies, logging and region choice, which settles data residency and makes the deployment auditable with the tools the organisation already uses. It is the cloud counterpart of an on-premise server and the building block of a private cloud assembled from public-cloud parts.
A VPC is not a compliance certificate and not encryption. It isolates the network; the workload still has to encrypt data in transit and at rest, control access, keep audit logs and follow the retention rules that apply to it. What the VPC removes is the class of risk that comes from a vendor’s shared, multi-tenant environment and from data crossing the public internet to reach it.
In the Ethora ecosystem
Ethora’s dedicated deployment runs inside the customer’s own VPC. Ethora TechOps stand up and operate the platform (ejabberd, the Node.js API, MongoDB, the media server for calls and the AI agent runtime) in the customer’s AWS, DigitalOcean or other cloud account, in the region the customer chooses, which is the pattern on the self-hosted chat server on AWS page. The result is single-tenant: one customer, one cluster, inside a network perimeter the customer controls, with its own Grafana and Prometheus monitoring.
That placement is what lets Ethora sign a BAA and a DPA on dedicated plans and offer EU-only residency: the data never leaves the customer’s account, and the customer’s SIEM, backups and access policies apply to the chat platform like any other internal system. Self-hosted customers who prefer to run the Docker deployment themselves get the same VPC placement with their own operations team.
