Redis Cloud Bring your own Cloud

Describes how to provision your Redis Cloud subscription to use an existing cloud provider account.

Redis Cloud Bring your own Cloud (BYOC) allows organizations to use their own cloud infrastructure to deploy Redis Cloud.

By default, Redis hosts the infrastructure that runs Redis Cloud. However, if your organization has specific requirements, you may need to have more control over your data residency or security options. Redis Cloud BYOC lets you fulfill these requirements while still having a fully managed service experience of Redis Cloud. Like standard Redis Cloud, Redis manages deployment, scaling, monitoring, and support, so you can focus on building applications while Redis manages the backend.

Redis Cloud BYOC availability requires approval from Redis. If you're interested, contact sales.

Benefits of Redis Cloud BYOC

Redis Cloud BYOC has some benefits over standard Redis Cloud:

• Full Data Control: All data stays within your environment, giving you complete control over data security and reducing risks associated with data sovereignty.
• Simplified Compliance: BYOC simplifies adherence to regulatory standards like GDPR, HIPAA, and compliance frameworks like SOC 2 and PCI DSS since data remains within your own cloud account.
• Maximize Cloud Commitments: Infrastructure costs are billed directly through your cloud provider account, enabling you to fully utilize existing commitments.
• Separation of Costs: Customers pay Redis only for licensing and management, while infrastructure costs go directly to the cloud provider, offering clear visibility into each cost stream.
• Instant Access Control: You can revoke Redis’ access to your environment at any time, offering complete control over data and infrastructure.

Redis Cloud BYOC Use cases

Consider using Redis Cloud BYOC if you have specific organizational needs or requirements, such as:

• Data Residency and Compliance: Organizations operating in heavily regulated industries (such as finance, healthcare, and government) can use Redis Cloud BYOC to meet strict data residency and sovereignty requirements, ensuring sensitive data remains within their controlled environments.
• Cloud spend optimization: Companies with significant cloud provider commitments can use Redis Cloud BYOC to optimize their cloud spend. Since infrastructure costs are billed directly through the cloud provider, customers can fully utilize existing cloud provider discounts, improving cost efficiency.
• Enhanced Security and Control: Redis Cloud BYOC is ideal for organizations that require a higher degree of security and control over their data. By keeping data within your own cloud account, you can use existing security policies, tools, and procedures in your cloud’s security infrastructure. In this way, you can minimize external access to your data, and adhere to more strict organizational security guidelines.

Set up Redis Cloud BYOC

To set up Redis Cloud BYOC on Amazon Web Services (AWS):

1. Create the Identity and Access Management (IAM) resources needed to let Redis create, monitor, and maintain deployment infrastructure.

2. Set your AWS Account as a BYOC Cloud account on Redis Cloud.

After you set up your cloud account, you can create a new Redis Cloud Pro subscription or an Active-Active database that uses your cloud account.

Redis Cloud BYOC pricing

With Redis Cloud BYOC, you pay for the Redis Cloud service, including database management, monitoring, and support. You also pay for the underlying cloud infrastructure, including virtual machines, storage, and networking, directly to your cloud provider.

When you create a database, you'll see the costs for the Redis Cloud service, but not the costs for the underlying cloud infrastructure. You can view and manage those costs in your cloud provider account.

Avoid Redis Cloud BYOC service disruption

To keep your Redis Cloud BYOC service and all databases running without issues:

• Do not stop, delete, or modify Redis-managed resources through the cloud provider - including VPCs, subnets, virtual machines, and other infrastructure.
• Do not change roles or access policies.

If you make any infrastructure changes, whether or not they are listed above, it may violate our SLA commitments. See Appendix 1 in our Terms of Service for more details.