HYCU expands SaaS and IaaS backup with protection for AWS Infrastructure as Code

HYCU has announced new data protection capabilities for R-Cloud that protect and restore AWS configurations at a granular level. We explain why this feature will be essential for protecting IaaS workloads, as public cloud adoption increases.

Background

HYCU first announced R-Cloud in February 2023, providing data protection for SaaS-based workloads. The platform has since been expanded to support its 50^th service integration, which we expect will accelerate further during 2024.

SaaS is just one aspect of the myriad locations where modern data and applications can be found. As we show in Figure 1 (a diagram discussing data mobility), the most forward-thinking enterprises expect to have workloads deployed in private data centres, in the public cloud, at the edge and within SaaS platforms.

Figure 1 – 4 pillars of application deployment

In each location, the operational aspect of the deployed architecture is different. On-premises and edge offer much more flexibility and control over the ecosystem, compared to IaaS and SaaS, with SaaS the least transparent in terms of how the application is implemented. This lack of control in SaaS is the classic “double-edged sword”. In one respect, the platform vendor is responsible for features, functionality, data management, security and more. However, the end user gets no direct access to the infrastructure and may only use advertised APIs. Generally, data protection isn’t implemented in SaaS, other than to enable the platform vendor to recover from hardware and software failures.

SaaS

While we might think of SaaS only with respect to IT functions, this represents a narrow view of where SaaS can be used today. The most apparent examples of widespread business SaaS tools are the productivity suites such as Microsoft 365 or Google Workspace. However, SaaS platforms are used for marketing, social media, project planning, messaging, payroll, HR, customer service management, incident management, CRM and many more.

Without realising it, SaaS becomes embedded into business processes and critical to daily business operations. So, imagine what would happen if the data in that platform was lost. We lose data all the time. Primarily, data is accidentally or inadvertently deleted, but there are countless instances of malicious data corruption or system bugs that take down applications. SaaS data needs protecting like any other data asset.

Our post discussing the R-Cloud launch provides much more information on why and how SaaS should be protected. We recommend listening to the embedded podcast for background on the SaaS protection challenge.

IaaS/PaaS

Turning to another one of the four deployment models in our diagram, IaaS represents the bulk of workloads deployed in the public cloud. We should, perhaps, include PaaS here too, specifically for solutions such as managed databases. However, remember that database-as-a-service is simply delivered on IaaS infrastructure, so is just one abstraction away.

One of the biggest differentiators between on-premises deployments of infrastructure and IaaS has been the use of infrastructure as code (IaC). Historically, on-premises systems mostly used GUIs and command lines to configure and manage systems. APIs and IaC are rarely featured in private data centres but are heavily used in the public cloud.

APIs

The API model is powerful because it creates a framework of extensibility and scalability using code to describe infrastructure. An API-based definition provides the template for creating a new application, including everything from the network gateway to load balancers and backend databases. We can also use it for data protection. In this post from 2018, we used IaC to set backup definitions, for example. AWS introduced IaC capabilities with CloudFormation in 2011, spurring the founding of HashiCorp in 2012 to offer equivalent functionality for on-premises infrastructure.

Infrastructure-as-Code (IaC) provides a framework to create repeatable templates that can be extended and widely deployed across public cloud infrastructure. A single “master template” can be used with a few modifications to create security settings, build databases or pretty much anything offered in the public cloud today.

API Management

However, as with all infrastructure, the best practices that dictate clean IaC configurations (not updating in place and keeping tracked copies) are rarely followed to the letter. IaC definitions could be (and are) held in repositories like Git, but configurations are frequently updated in place for convenience and speed. There’s an inevitable “drift” from the expected configuration, even in the most well-maintained environments.

I have plenty of experience with this phenomenon, mainly in the deployment of storage infrastructure, where the assumed configuration is the one in place. This assumption was usually validated with spreadsheets that described the desired configuration. However, without the benefit of having a reference configuration like a spreadsheet, what’s in place can only be assumed to be correct. This made it challenging in some environments to reclaim unused resources or be sure of a configuration before and after a DR incident.

IaC Backup

HYCU has extended R-Cloud to protect IaC for applications running on Amazon Web Services. As we’ve already highlighted, IaC definitions form the core of application deployment and are another data asset in the enterprise. Why protect them? We can think of many obvious reasons.

Expected and observed definitions change. Modifications get made in place and fail to be backported to the Git source definition.
Some definitions are too unwieldy or complex to store effectively in Git or change too frequently. A good example could be security definitions for application or platform access.
Multi-user access can result in changes being lost when more than one user or administrator updates the same set of definitions on a regular basis.
IaC definitions have value and are often the result of tens, if not hundreds, of hours of work. Recreating from scratch would require repeating all the previous steps and be a source of risk in a disaster scenario (like rebuilding an application).
IaC definitions are subject to mistakes or coding errors like any other software. Backup can provide a good audit trail, especially for identifying malicious changes.
The public cloud doesn’t protect your IaC definitions.

We always talk about backup as a failsafe or “get out of jail free card”. If the capability is there, why wouldn’t you protect your IaC assets, just in case?

HYCU R-Cloud now provides IaC protection for AWS EC2, EBS, S3 and Lambda core services. It protects RDS, DynamoDB and Aurora database services. It supports protection for core management services, including IAM, CloudFormation and Key Management Service (KMS). As a first pass, this is a comprehensive level of day-one support.

The Architect’s View®

There’s more to data protection than purely protecting the data within applications. A DR plan from a decade ago would also describe the steps to rebuild the application from the ground up. In the public cloud, that process is fully automated with infrastructure as code.

The benefits of protecting infrastructure definitions are obvious, but we can see other opportunities. IaC backup provides an audit trail for detecting unauthorised or suspicious changes, for example. IaC backup becomes an integral part of disaster recovery or even workload migration planning. The options are many and varied.

HYCU continues to fill the gaps missing in data protection that we first started discussing in 2019. The new AWS protection capabilities address fundamental resiliency objectives that should be part of every IT operation. Just take a moment and think how long it would take to rebuild your AWS infrastructure without a copy of IaC definitions. You may be scared by the answer.