Everything you needed to know about object storage

What object storage is

Object storage keeps data as self-contained objects in a flat address space. Each object normally contains three things: the data itself, a unique identifier or key, and metadata describing it. The system retrieves the object by its key through an API rather than by traversing a traditional disk volume or a shared folder hierarchy.

A bucket is the logical container. Inside it, an object might have a key such as finance/2026/invoices/10482.pdf. That looks like a folder path to a human, but in many object stores it is simply one long name. The apparent folders are prefixes used by interfaces and applications to organise listings.

That design removes much of the overhead associated with maintaining conventional file-system trees at enormous scale. An object platform can spread data across many devices and locations while presenting one namespace to the application. The application asks for a key; the platform decides where the bytes live.

Object, file and block storage are different tools

The easiest way to understand object storage is to compare it with the two other common models.

File storage presents folders and files through protocols such as SMB or NFS. It suits shared drives, team documents and applications that expect to open, edit and rename files in a hierarchy. Permissions and file locking are familiar, but very large namespaces can become difficult to scale and manage.

Block storage presents raw volumes to a server. The operating system places a file system or database on top. It offers low latency and predictable performance, which is why it is used for databases, virtual machines and transactional workloads. It also requires more management and does not carry rich per-object metadata by itself.

Object storage presents an API. It is designed for scale, durability and relatively simple operations: create an object, retrieve it, list it, copy it or delete it. It excels when applications can treat content as complete objects rather than repeatedly changing small parts of a file in place.

These are workload choices, not a security ranking. A database volume may belong on block storage. A departmental working share may belong on file storage. A billion images, backup chunks or log files are natural object-storage workloads. Any of those data types can also be selected for Offline Secure Storage® when the requirement is to place a protected copy behind a materially stronger separation boundary.

What the S3 API means

Amazon Simple Storage Service popularised an object-storage interface that became a de facto industry standard. When a product says it is “S3 compatible”, it usually means existing tools can use familiar operations and authentication patterns to work with it.

Compatibility is not the same as identity. Providers differ in supported API calls, consistency behaviour, object-lock implementation, replication, identity controls, performance, egress charging and operational limits. An application tested against one S3-compatible service should not be assumed to behave identically against every other one.

The useful question is not simply “does it support S3?” It is “which operations and controls does our workload rely on, and have we tested those against this service?”

How data is identified and organised

Every object has a key that is unique within its bucket. Applications often construct keys from dates, customer identifiers, content hashes or apparent folder names. Good key design helps with lifecycle rules, access policies, search and migration.

Metadata is one of object storage's defining strengths. System metadata records properties such as size, content type, checksum and modification time. User metadata can record business context such as case number, retention class, owner or sensitivity. Tags may provide a separate, policy-friendly way to classify objects.

Metadata is useful only if it is governed. If an organisation cannot say which data sits in which bucket, who owns it, how long it should remain and what classification applies, the platform's scale becomes a liability. A badly governed bucket can become the largest unlabelled cupboard the organisation has ever owned.

Durability is not availability

Object-storage providers often quote durability using a string of nines. Durability is a provider design measure for resisting media and infrastructure loss over a period. It is usually achieved through replication, erasure coding, integrity checking and automated repair. It is not the probability that a customer can recover a known-good dataset after compromise, deletion or corruption.

Availability is different. It measures whether the service can be reached when requested. A copy can remain perfectly durable while an outage, identity failure, network problem or account suspension makes it temporarily unavailable.

Neither figure proves recoverability. A highly durable service can faithfully preserve encrypted, corrupted or maliciously altered data. It can also process an authorised deletion exactly as designed. Durability protects against certain platform failures. Recovery depends on versions, retention, independent access, tested restoration and, for the most important data, separation from the environment that can damage the primary copy.

Consistency and application behaviour

Consistency describes when a write becomes visible to later reads and listings. Major cloud object stores now commonly provide strong read-after-write consistency, but assumptions still need checking, particularly across replication targets, gateways and third-party S3-compatible products.

Applications should also expect network operations to fail occasionally. Uploads may time out after the service has received the data, retries may create duplicate work, and large files may be transferred in multiple parts. Robust integrations use checksums, idempotent operations, sensible retries and explicit completion checks rather than treating an HTTP success code as the whole evidence trail.

Versioning, retention and Object Lock

Versioning keeps previous versions when an object is overwritten or deleted. It is valuable for accidental changes and some malicious activity, but it can increase storage costs quickly and may still be defeated by a principal with permission to remove versions or change the bucket configuration.

Retention policies prevent an object version from being removed until a specified date. Legal holds preserve selected objects until the hold is explicitly released. These are useful governance and recovery controls when they are correctly configured and independently administered.

Object Lock is the S3 term commonly associated with write-once, read-many behaviour and requires versioning. In governance mode, a principal with the specific bypass permission may be able to override retention. In compliance mode, an existing protected version cannot normally be deleted before expiry, even by the account's root user. That protection applies to locked versions for their retention period. It does not remove the service endpoint, prevent new malicious writes, or protect every surrounding identity, key, application and configuration. The exact implementation and prerequisites must be verified with the provider.

Immutability is not the same as being offline. An immutable bucket remains a live service endpoint with identities, APIs, policies and a management plane. Immutability protects retained object versions. Physical disconnection removes the network path. Mature recovery designs may use both because they address different failure modes.\n\n## Object storage and Offline Secure Storage® are not competing formats\n\nObject storage describes how software organises and retrieves data. Offline Secure Storage® describes a security architecture around data selected for stronger protection. Comparing them as though they were two equivalent storage tiers is misleading.\n\nOSS is not limited to one file type, one application or a narrow emergency backup. It can hold whichever business data an organisation decides must remain protected: documents, databases, application exports, virtual machine images, media, design files, records, encryption material or data exported from an object store. The suitability of each item depends on the required access pattern and recovery plan, not on a Firevault content restriction.\n\nThe material security difference comes from architecture. Firevault uses dedicated physical drives, bunker custody, identity-verified controlled access and Layer 1 physical disconnection between authorised sessions. When disconnected, there is no live network path from a compromised production account, cloud control plane or remote administrator to the protected data. Object Lock and access policy remain valuable controls, but they operate inside a connected service and therefore address a different set of risks.\n\nNo single control makes data invulnerable. Availability, retention, restore testing, authorised access and operational procedures still matter. The point is that deliberate physical separation removes a class of remote attack paths that connected object storage, however well configured, cannot remove while it remains online.

Encryption and key ownership

Object storage should encrypt data in transit and at rest. The harder question is who controls the keys and what happens when key access fails.

Provider-managed encryption is operationally simple. Customer-managed keys can improve separation and auditability, but they add a dependency: deleting, disabling or misconfiguring the encryption key can make otherwise intact objects unreadable. If the storage and its keys are controlled by the same compromised identity path, the theoretical separation may be weaker than it appears.

For sensitive data, document the key owner, recovery process, rotation policy and emergency access route. Test restoration with the controls that would exist during a real incident, not with an administrator quietly bypassing them.

Identity is the real perimeter

Most object-storage incidents are not caused by someone breaking the storage algorithm. They arise from exposed credentials, public buckets, excessive permissions, vulnerable applications, compromised automation or mistakes in policy.

The minimum useful control set is straightforward:

• keep buckets private by default;
• grant workloads only the operations and prefixes they require;
• separate read, write, delete and policy-administration permissions;
• use short-lived workload identities rather than long-lived access keys;
• block public access centrally where the platform supports it;
• log data access and configuration changes to an independently protected destination;
• alert on policy changes, bulk reads, unusual egress and deletion activity;
• require separate approval for retention changes and destructive actions.

A bucket policy is code. It should be reviewed, tested and monitored like any other security-critical configuration.

The costs that do not appear in the storage rate

The headline price per gigabyte is only one part of object-storage economics. A realistic model includes requests, retrieval charges, data transfer, replication, minimum storage durations, early-deletion fees, monitoring, key-management calls and the labour required to restore data.

Small objects can be disproportionately expensive because request counts grow faster than stored capacity. Archive tiers may be cheap to hold but slow or costly to retrieve. Moving data out of a cloud can cost more than keeping it there for months. Replication can double capacity while cross-region transfer adds another charge.

Before committing, model a normal month, a growth month and a recovery month. The recovery scenario should include the volume retrieved, number of objects, destination, required time and every service that must be running to complete the restore.

Object storage as backup

Object storage is widely used as a backup target because it scales, supports automation and can combine versioning with retention controls. That does not make every object bucket a backup.

A backup needs a defined source, schedule, retention policy, integrity check, monitoring, restore procedure and tested recovery objective. A second copy written into another bucket under the same account and identity boundary may protect against hardware failure while doing little against account compromise.

The stronger pattern separates duties and failure domains. Backup software can write new objects without being able to remove protected versions. Retention administration sits with a different authority. Logs leave the account. A further protected copy is held outside the reachable management plane. That copy may contain data exported from object storage or any other critical system. In a Firevault architecture, dedicated hardware and physical disconnection make this more than another account, bucket or policy boundary.

Object storage as archive

Archive is about long-term retention, not merely low access frequency. The design needs to preserve authenticity, readability, context and disposal rules for as long as the record matters.

That means retaining metadata and checksums, documenting file formats, planning migrations before formats or applications become obsolete, applying legal holds correctly and proving that expired records are destroyed. Cheap capacity without an information-governance model produces a large, durable problem rather than a trustworthy archive.

Cold and archive object tiers are still connected services. Retrieval may be delayed, but the management plane remains online. “Cold” describes access economics and latency. It does not mean physically disconnected.

Object storage and data lakes

Object storage is the common foundation for modern data lakes because it can hold structured, semi-structured and unstructured data at large scale. Compute engines read from the shared object layer rather than keeping all data inside one database.

The flexibility creates its own risks. Without catalogue ownership, schema controls, lineage and lifecycle rules, a data lake becomes a data swamp. Sensitive records may be copied into analytical zones with broader access than the source. Temporary extracts become permanent. Machine-learning workloads can multiply copies and derived data faster than governance teams can see them.

Treat the catalogue, permissions and deletion workflow as part of the data platform, not optional administration around it.

When object storage is the right choice

Object storage is usually a strong fit when the workload contains many complete files or blobs, needs enormous scale, benefits from rich metadata, is accessed through applications or backup software, and can tolerate API rather than file-system semantics.

It is less suitable for low-latency transactional databases, workloads that constantly edit small parts of the same file, legacy software that requires a mounted volume, or teams that need normal shared-drive locking and browsing without a gateway.

Gateways can present object storage as a file share, but they do not erase the differences. Caching, rename behaviour, locking, latency and failure handling still need testing.

A practical buying checklist

Before selecting a platform, ask:

1. Which API operations and compatibility features does the workload require?
2. What are the durability and availability commitments, and across how many failure domains?
3. Are versioning, retention and legal hold included, and who can override them?
4. Can storage administration, key administration and backup administration be separated?
5. Where are the data, replicas, metadata, logs and encryption keys held?
6. What does a full recovery cost and how long has it taken in a real test?
7. How are bulk deletion, policy changes and unusual downloads detected?
8. How will data be exported without proprietary tooling or prohibitive charges?
9. What happens when the identity provider, network or provider control plane is unavailable?
10. Which copy remains recoverable if the production account is fully compromised?

The tenth answer determines whether the architecture contains a storage service or a recovery strategy.

How object storage and Offline Secure Storage® work together

A resilient design does not require an organisation to choose one storage model and discard the other. Object storage can remain the scalable, API-led working platform for applications, backups, archives and data lakes. Offline Secure Storage® can hold whichever selected data warrants a materially stronger separation boundary.

A practical pattern is:

1. keep production and frequently accessed data on the storage model that suits the workload;
2. use versioning, retention, least privilege and independent logs inside the connected platform;
3. export selected critical data to dedicated physical hardware under independent bunker custody;
4. disconnect that hardware at Layer 1 between identity-verified access sessions; and
5. perform and record recovery tests so the protected copy is proven usable.

This also supports the 3-2-1-1-0 discipline: three copies, two media types, one off-site copy, one offline copy, and zero errors verified through recovery testing. Object storage may provide one or more connected copies. OSS provides the physically disconnected copy. The final zero still depends on a successful, evidenced restore.

The controls are complementary, but they are not interchangeable. Object Lock governs retained versions inside a connected service. OSS removes the live network path to selected data between authorised sessions. Neither removes the need for retention governance, recovery planning and testing.

Frequently asked questions

Is object storage the same as cloud storage? No. Object storage is a storage model. It can run in a public cloud, a private cloud, an on-premises appliance or a managed data centre. Consumer cloud drives may use object storage underneath while presenting a file-like interface.

What is a bucket? A bucket is a logical container for objects. It is also commonly the boundary for region, access policy, versioning, retention, logging and lifecycle settings.

What is an object key? It is the unique name used to retrieve an object from a bucket. A key can contain slashes and look like a folder path, although the underlying namespace may be flat.

Is S3 a type of storage or an Amazon product? It is both a named Amazon service and the source of the API conventions adopted by many other object-storage products. “S3 compatible” should always be checked against the specific features an application uses.

Can object storage be immutable? Yes. Version retention, legal holds and Object Lock can prevent protected versions from being changed or deleted for a defined period. Immutability does not remove network reachability or management-plane risk.

Is object storage a backup? Not by itself. It becomes part of a backup system when copying, retention, monitoring, integrity checking and restoration are designed and tested around it.

Is cold object storage offline? No. Cold or archive tiers change price and retrieval time. They remain managed, network-addressable services even when retrieval takes hours.

Why can object storage bills rise unexpectedly? Capacity, request volume, retrieval, data transfer, replication and minimum-duration charges are priced separately. Recovery activity can produce a very different bill from normal operation.

Can ransomware reach object storage? It can if compromised credentials or connected applications have enough permission to overwrite, delete or encrypt objects. Versioning, retention, least privilege and an offline recovery copy reduce different parts of that risk.

Does Offline Secure Storage® replace object storage? They solve different questions. Object storage determines how applications store and retrieve large numbers of objects. Offline Secure Storage® determines how chosen data is placed behind dedicated hardware, controlled access and physical disconnection. OSS can hold whatever data the organisation chooses, including exports or backup sets from object storage, and its architecture provides materially stronger protection against remote compromise while disconnected.

Sources and further reading

1. Amazon S3 documentation: data protection and storage management
2. Amazon S3 documentation: Object Lock
3. Microsoft Azure architecture guide: data storage models
4. Google Cloud: object storage introduction
5. NIST SP 800-209: Security Guidelines for Storage Infrastructure
6. MITRE ATT&CK T1490: Inhibit System Recovery
7. UK NCSC: ransomware-resistant backups

Where object storage fits in a resilient estate

Object storage solves a scale and access problem. It gives applications a durable, programmable place to put enormous numbers of objects, and it does that extremely well. Versioning, retention and Object Lock can make it a strong part of a backup and archive design. Those capabilities should not be mistaken for a stronger security architecture than OSS: they remain controls within a connected identity and management plane.

The boundary is reachability. If the organisation's most privileged identities, production applications or automation can still reach every recovery copy, one compromised control plane can become a common failure domain.

Use object storage where scale, metadata and API access matter. Use immutability where retained versions must resist alteration. Use Offline Secure Storage® for any chosen data that warrants dedicated hardware, independent custody, identity-verified access and no network path between authorised sessions. This may be a recovery set, sensitive records, irreplaceable intellectual property or any other material data. Object storage may feed that protected copy, but it does not sit above OSS in the resilience architecture.

For the related comparisons, read Air gap vs immutable backup, Hot, warm and cold storage explained and The 3-2-1-1-0 backup rule. If you are defining the isolated copy for your organisation, buy your Vault or use the OSS Concierge for secondary guidance.

Mark Fermor is the co-founder of Firevault.