Disaster Recovery (DR)
Kuroco is offered in two deployment types: the Public SaaS edition, provided on Google Cloud Platform (GCP), and the ISMAP-compliant Private SaaS edition, built as a dedicated environment for each customer on AWS. Both deployment types implement multiple layers of protection depending on the scale of the failure or disaster. This page explains Kuroco's redundancy architecture, its disaster recovery (DR) measures, and how to choose the deployment type and options that best fit your requirements.
The DR measures described on this page (backups in and recovery via the Osaka region) apply to environments built in the Tokyo region. With the Public SaaS edition, you can also choose the US (Iowa) and EU (Finland) regions. For the DR configuration of the US and EU regions, please contact us.
Overview of disaster countermeasures
Different scales of failures and disasters require different countermeasures. Kuroco addresses them at the following two levels.
| Level | Possible events | Kuroco's countermeasure |
|---|---|---|
| AZ (data center) level failure | Fire, power outage, or cooling failure at a single data center; hardware failures; network failures | The multi-AZ architecture keeps the service running on the remaining AZs |
| Region-level disaster | A wide-area disaster such as a major earthquake directly hitting the Tokyo metropolitan area, taking down multiple AZs in the Tokyo region simultaneously for an extended period | Recovery from backups stored in the Osaka region (a hot-standby option is available for the Private SaaS edition) |
A group of data centers within the same region that are geographically separated and have independent power and network facilities. AZs are designed so that a failure in one AZ does not affect the others.
Multi-AZ redundancy (standard)
Kuroco is deployed across multiple AZs by default. Even if an entire data center fails, the service automatically continues running on the remaining AZs. No action is required on your side.
| Deployment type | Platform | Configuration |
|---|---|---|
| Public SaaS | GCP | Multi-AZ across 3 AZs |
| Private SaaS | AWS (dedicated sub-account environment per customer) | Multi-AZ across 2 AZs (standard configuration) |
Note that multi-AZ redundancy covers failures limited to some of the AZs within the region. A wide-area disaster affecting the entire Tokyo region requires the region-level DR described below.
Preparing for region-level disasters (DR)
Backups in the Osaka region (standard)
For both the Public SaaS and Private SaaS editions, backups of Kuroco environments built in the Tokyo region are stored in the Osaka region. Even if the entire Tokyo region is affected by a disaster, your data remains safe in the Osaka region.
Recovery in the event of a region failure
If the entire Tokyo region becomes unavailable, the recovery process differs depending on the deployment type and options.
In a disaster severe enough to take down the entire Tokyo region, recovery demand from the many systems that were running in the Tokyo region is expected to concentrate on the Osaka region, and cloud resources in the Osaka region may become exhausted. Therefore, without the Osaka hot-standby option, restoring from backups may take longer, or the environment may need to be brought up in an overseas region.
Public SaaS
The environment is restored from the backups stored in the Osaka region. We do not provide an SLA (guarantee) for the recovery time, but we will make every effort to restore the service as quickly as possible. There is no charge for the failback after the Tokyo region has recovered.
Private SaaS (standard)
Same as the Public SaaS edition: the environment is restored from the backups in the Osaka region, and we will make every effort to restore the service as quickly as possible. After the Tokyo region has recovered, we perform the failback for a fee of JPY 550,000 (tax included) per occurrence.
Private SaaS + Osaka hot-standby option
With the Private SaaS edition, you can optionally set up a hot-standby environment in the Osaka region.
- A standby environment is kept running in the Osaka region at all times. Because its resources are secured in advance, the failover is far less likely to be affected even if resources in the Osaka region become exhausted during a large-scale disaster.
- In the event of a disaster, executing the failover procedure provided in advance brings up the Osaka environment in about 15 minutes. The procedure is designed to be a simple command-line execution on your own PC, so you can initiate the failover yourself immediately in an emergency.
- After the Tokyo region has recovered, we perform the failback for a fee of JPY 550,000 (tax included) per occurrence.
The Private SaaS edition is available in two forms: Managed, where we provide the infrastructure, and Self-Hosted (BYOC), built within your own AWS account. The Osaka hot-standby option is available with both forms; for Self-Hosted (BYOC) deployments, please contact us about the setup fees. See Is an on-premises version available? for more information.
Delivery-side disaster countermeasures with an SSG architecture
In addition to the CMS infrastructure measures described above, your site architecture itself can be part of your DR strategy.
Because Kuroco is a headless CMS, adopting an SSG (static site generator) architecture means your pre-built static files are served from a CDN plus a highly redundant static file hosting service. With this architecture, even if the CMS (Kuroco) side goes down, your published site continues to be served. In a disaster, the impact is limited to content updates in the admin panel and dynamic features that rely on the API.
If the static file delivery side also requires redundancy, the following approaches can be considered:
- Multi-CDN strategy: Use multiple CDNs in parallel so that delivery continues even if one CDN fails.
- DNS failover: Detect a failure on the delivery side and automatically switch to another delivery destination via DNS.
For details on the SSG architecture, see What is Jamstack? and KurocoFront. The right redundancy setup for the delivery side depends on your requirements, so please contact us via our support team.
Choosing the right plan
The best plan depends on the scale of disaster you need to prepare for and how quickly you need to recover.
| Public SaaS | Private SaaS | Private SaaS + Osaka hot standby | |
|---|---|---|---|
| Platform | GCP | AWS | AWS |
| Multi-AZ configuration | 3 AZs | 2 AZs (standard) | 2 AZs (standard) |
| AZ-level failure | Service continues | Service continues | Service continues |
| Backups in the Osaka region | Yes | Yes | Yes |
| Recovery from a region-level disaster | Best effort | Best effort | About 15 minutes by executing the failover procedure |
| Recovery destination in a region-level disaster | Osaka region (may take longer or fall back to an overseas region if resources are exhausted) | Osaka region (may take longer or fall back to an overseas region if resources are exhausted) | Osaka region (resources secured in advance) |
| Estimated recovery time for a region-level disaster | Not defined | Not defined | About 15 minutes |
| Failback fee | No charge | JPY 550,000 (tax included) per occurrence | JPY 550,000 (tax included) per occurrence |
Use the following as a guideline:
- Protection against AZ-level failures is sufficient, and best-effort recovery is acceptable for a region-level disaster (including cases where recovery takes longer or the environment is brought up in an overseas region) → The Public SaaS edition or the standard Private SaaS edition will cover your needs. An event that takes an entire region in Japan offline for an extended period assumes a wide-area disaster on the scale of a major earthquake hitting the Tokyo metropolitan area, which is extremely rare.
- You need a short recovery time (about 15 minutes) even in a region-level disaster → Consider the Private SaaS edition with the Osaka hot-standby option. This is suited for cases where your business continuity plan (BCP) defines a clear recovery time objective (RTO) for region-level disasters, such as financial services, social infrastructure, or corporate sites with strict BCP requirements.
- You require a deployment within your own AWS account (Self-Hosted/BYOC) → Consider the Private SaaS edition. See Is an on-premises version available? for details.
- Keeping the published site available during a disaster is your top priority (mainly read-only sites) → Consider adopting an SSG architecture, regardless of the deployment type. Even if the CMS side goes down, your published site continues to be served. See Delivery-side disaster countermeasures with an SSG architecture for details.
If you have any questions or would like a quote, please contact us via our support team.
Related pages
Support
If you have any other questions, please contact us or check out Our Slack Community.