Let’s talk about moving to the cloud. When we shift our heavy workloads to platforms like Atlassian Cloud, whether that’s Jira, Confluence, or Jira Service Management, it feels like a huge weight is lifted off our shoulders. You don’t have to worry about server racks, cooling, or hardware failures anymore.
Because of this, it’s easy to fall into the trap of thinking, "Atlassian has my back for everything now". But that is actually a dangerous misconception.
There is a concept called the Shared Responsibility Model. Think of it like renting an apartment. The landlord (Atlassian) is responsible for the building's security, the plumbing, and making sure the roof doesn't cave in. But the stuff inside your apartment, your TV, your jewelry, your family photos? That is entirely on you.
Atlassian makes sure the infrastructure is up and running, but the actual data you create, your intellectual property, customer details, and project roadmaps, is your responsibility. If an integration goes rogue and scrambles your configurations, or someone accidentally deletes a massive project, Atlassian’s large infrastructure backups will not easily help you restore that specific mistake.
To truly protect your data, you need to understand two key concepts: BYOS and BYOK and apply them in context of primary copy of the data (Atlassian apps) and secondary copy of the data (backup data) They might sound like corporate jargon, but they are incredibly straightforward once you break them down. Let's dive in.
Imagine you are paying a storage facility to hold your furniture. BYOS is basically saying, "I like your moving service, but I want you to put my furniture in my own personal garage, not your warehouse".
In the Atlassian ecosystem, native backups have some strict limitations:
Bring Your Own Storage changes the game. Instead of Atlassian holding your backups in their locked ecosystem, BYOS pipelines your data directly into your own cloud storage. This means sending data to your own Amazon AWS S3 bucket or your Microsoft Azure Blob account.
A Note on BYOS Security: People often worry about the security of moving their backups, but modern cloud storage systems (like AWS S3 or Azure Blob) encrypt your data by default. Because you own the environment, you can instantly revoke the backup vendor's access to your data if needed. This gives BYOS a "kill switch" characteristic for your backups.
If BYOS is about where the safe is kept, BYOK is about who holds the key to that safe.
By default, in context of the primary copy of the data Atlassian automatically encrypts your data to make your life easier. It is very secure, but because Atlassian holds the encryption keys, they could theoretically decrypt your data.
Bring Your Own Key means you use your own cryptographic key, usually managed in your own AWS Key Management Service (KMS) or an Azure equivalent, to lock up your data. Atlassian still hosts the encrypted data, but every time they need to read a Jira issue or display a Confluence page, their system must knock on your AWS account's door and ask permission to use your key.
Warning: There is a major risk with BYOK. If you accidentally delete your encryption key, your data is gone forever. It is completely unrecoverable, meaning you are taking on the ultimate responsibility.
The honest answer depends on what keeps you up at night.
|
Feature |
BYOK (Bring Your Own Key) |
BYOS (Bring Your Own Storage) |
|
Core Concept |
You manage and control the encryption keys used to secure your data in the cloud. |
You manage and control the storage infrastructure where a vendor's application saves your data. |
|
Primary Goal |
Data Security, Cryptographic Control, and Privacy. |
Data Sovereignty, Centralization, and Storage Cost Control. |
|
What You Own |
The master cryptographic key (often kept in a Hardware Security Module or Key Management System). |
The physical or cloud storage bucket (e.g., your AWS S3 bucket, Google Cloud Storage, or Azure Blob). |
|
Vendor Role |
The vendor stores data on their servers but must request access to your key to encrypt/decrypt it. |
The vendor runs their application but reads/writes the resulting data directly to your servers/buckets. |
|
Vendor Lock-in |
Makes leaving easier: Revoke the key to render the vendor's copy useless. |
Makes leaving easier: Simply disconnect the software; no migration needed as data is already in your environment. |
|
Cost Impact |
Usually involves extra costs for dedicated Key Management Systems (KMS) or HSMs. |
Often saves money by avoiding premium SaaS storage markups; you pay standard cloud storage rates. |
|
Compliance |
Proves unauthorized parties (including vendor/government) cannot read your data. |
Proves exactly where your data lives geographically and ensures you have complete control. |
Choose BYOS if:
Choose BYOK if:
Absolutely. Combining them creates what security experts call "Zero Trust Data Protection". You use Atlassian's BYOK to lock down your live primary environment. Then, you pipeline your backup data into your own storage bucket (BYOS), where it is encrypted by default. You own the lock, and you own the vault.
If managing these backups, storage buckets, and recovery pipelines sounds overwhelming, that’s exactly where Revyz steps in. Built specifically for Atlassian Cloud (Jira, Confluence, and Jira Service Management), Revyz is designed to bridge the gap in the Shared Responsibility Model and make BYOS effortless.
Here is how Revyz puts you in the driver's seat:
Moving to the cloud does not mean giving up ownership. Whether you choose to control where your data sleeps (BYOS), who gets to unlock it (BYOK), or use a platform like Revyz to manage it all, the important thing is that you are taking the wheel. Don't wait for a disaster to figure out what the Shared Responsibility Model actually means for your team.