Typically, you need one sidecar per network.
Each Cyral sidecar is deployed as an auto-scaling, high availability cluster that presents a single, load-balanced address for client connections. Configured correctly, a deployed sidecar spans multiple availability zones to provide fault redundancy. All the repositories protected by the sidecar cluster are available at this address, for both DDL/DML and administrator use.
Typically, for all of your data repositories in a given cloud network you will deploy a single sidecar cluster. A single sidecar cluster can protect multiple instances and types of repositories, such as PostgreSQL, MongoDB, and so on. It is important to maintain any network isolation that you may have, so it is typical to deploy a sidecar inside each VPC that has a data repository. If your VPC contains many repositories, a single sidecar will do, but if you have distributed data across different environments such as separate ‘dev’ and ‘production’ VPCs, separate sidecars will allow you to maintain that isolation.
Ensuring your sidecar is in the same region as your data repository will also ensure there is no performance impact from network latency. Deploying the sidecar in the same VPC as the data repository(s) ensures performance and network isolation.
Separate dev sidecars is also a great idea for testing changes and upgrades before they go into production. Cyral supports these best practices and so does not charge on a ‘per sidecar’ basis to encourage isolation.
