Ceph RGW S3 object storage and multisite replication guide

Why Ceph RGW S3 object storage needs a topology decision first

Before you create the first bucket, you need to decide how your Ceph Object Gateway (RGW) deployment is divided into realms, zonegroups and zones. If you need S3-compatible storage on your own Ceph cluster and expect it to span two or more sites, this layout is the foundation everything else rests on. Buckets, users, replication settings and client endpoints all depend on it, and it is far cheaper to settle it on an empty cluster than after data has landed.

Ceph RGW offers S3 and Swift-compatible APIs and has documented multisite configuration, so the feature set is not the open question. The harder part is that a multisite layout is difficult to change once it carries data. Renaming zones, moving a bucket to a different zonegroup or splitting a zone that has grown into a second site all require careful planning and testing. A single-cluster bucket deployment rarely forces that kind of decision. A multisite one does, and the cost of getting it wrong grows with every object written.

Replication between zones is asynchronous. A client that writes to one site cannot assume the object is yet visible at the other site, and a failover plan has to account for that lag. Application behavior adds another layer: S3 clients are configured with endpoints, credentials and sometimes path-style or virtual-hosted-style addressing, and those settings are tied to the topology you choose. Confirm with your application owners which endpoints each client uses, how they authenticate, and whether they tolerate eventual consistency across sites before you commit to a design.

This page covers how to choose that topology, how the realm, zonegroup and zone model maps to your sites and failure domains, and what to check before buckets are created. It also covers the sequence of decisions that follows, from zone placement to the endpoints and load balancing your clients will use. It does not cover single sign-on or identity integration, which belongs to the Ceph SSO topic, nor security hardening of RGW and the cluster network, upgrades to a maintained release, or CRUSH rule and placement group tuning. Those are sibling topics and are referenced where they affect the topology decision.

Action before you start: write down the number of sites, the expected growth per site, which sites must accept writes, and which application teams will connect. That list determines the layout more than any single feature does, and it gives a partner or internal team the information needed for a fixed-scope estimate.

Which RGW components and settings shape the design

A multisite RGW deployment is a stack of named objects: realms, zonegroups, zones, periods, gateways, pools, users and the load balancer in front. Each one carries a different amount of replication behavior, and some are far harder to change once data is in place, so decide them before the first bucket is created.

Realm and its namespace

A realm is the top-level container that groups zonegroups and holds the shared configuration that all sites replicate. Every site in the same replication domain must belong to the same realm, and the realm name becomes part of how sites identify each other. Confirm which sites will share one realm and whether any sites need to stay fully isolated in separate realms, because moving a zonegroup between realms later is a disruptive change.

Zonegroup and its endpoints

A zonegroup holds the zones that share a bucket namespace and replicate with each other, and it lists the endpoints clients use to reach them. Its master zone is the only zone that accepts metadata changes such as bucket and user creation. Plan which site is the metadata master before onboarding, since moving that role changes where administrative writes land and affects every client that creates buckets.

Zones and their roles

A zone is one independent RGW deployment backed by its own Ceph cluster, and it is the unit that stores data for one site. Each zone has a role within its zonegroup, and zones can be given data-only or metadata-plus-data behavior depending on the design. Changing a zone's endpoints, name or placement after data exists requires careful sequencing, so record each zone's cluster, location and endpoints in the design document.

Period and commit workflow

The period is the versioned snapshot of realm, zonegroup and zone configuration that RGW distributes across sites. Changes take effect only after a period update is committed, and the commit increments the epoch that every site must reach. Treat configuration edits as controlled changes: stage them, commit once, and confirm each secondary zone has pulled the new period before resuming client writes or further changes.

RGW daemons per zone

The RGW daemons in a zone handle S3 and Swift requests and run the replication workers that move data and metadata to peer zones. Decide how many gateways each zone runs, which of them serve client traffic, and which handle sync, since a single gateway doing both can become a bottleneck. Resizing or splitting these roles later changes throughput and failover behavior, so test sync under load at the planned gateway count.

Pools each zone uses

Each zone creates a set of RADOS pools for metadata, bucket indexes, data and logs, and their names are tied to the zone name. These pools are where objects and sync state physically live, so renaming a zone or reusing pools from another zone causes data to be misplaced or lost. Confirm the pool layout with your Ceph team before creating buckets, and treat storage class mapping to pools as a decision to revisit only through a planned migration.

Users, keys and sync credentials

S3 access keys belong to RGW users, which are scoped to tenants and carry quotas and capabilities, while zones authenticate to each other with system users that hold the sync credentials. Access keys and the system user secret must be created in the realm and distributed to every site, and rotating them is a coordinated change across zones. Decide the tenant model and who can create users before the first client connects, because retrofitting tenants changes bucket names and access policies.

Ingress and load balancer

The load balancer or ingress in front of the gateways determines which endpoint clients see, how TLS is terminated, and how traffic fails over between gateways in a zone. Choose the endpoint DNS names, certificate placement and health checks together, since clients and zonegroup endpoints both depend on them. Changing the public endpoint later affects every application configuration and, if it is listed in the zonegroup, requires a period commit.

Decisions to settle before the first zone is created

This table compares the main design choices for an RGW deployment, with the situations where each option fits and the operational cost it carries. Read each row as a decision to close with your team before any zone is created, since several of them are hard to reverse once data is written. Exact replication policy options vary by release, so confirm them against the Ceph release you plan to run.

Decision	Option	Operational trade-off	When to choose it
Single zone or multisite	Single zone in one cluster	Simplest to run, one place to monitor and back up, no cross-site replication	Single site, or when a second copy is handled by an external backup or DR tool
Single zone or multisite	Multisite with two or more zones	Adds sync health monitoring, replication lag tracking and conflict handling for failover	When objects must exist at a second site for DR, locality or a defined recovery target
Number of zonegroups	One zonegroup	One namespace of zones that replicate among themselves, fewer moving parts	Most deployments that need replication between sites under one administrative domain
Number of zonegroups	Several zonegroups	Separate replication domains, more configuration to keep consistent, more sync states to watch	When sites must be isolated from each other for legal, tenancy or operational reasons
Master zone	Pick one master per zonegroup	Metadata changes route through the master, so its outage affects configuration changes	When one site is the primary administrative location and failover is a planned runbook step
Realms	One realm	Single configuration scope and simpler period management	Most single-organization deployments
Realms	Several realms	Independent period and configuration history, extra tooling and naming discipline	When unrelated organizations or regulatory boundaries must be configured separately
Replication scope	Whole zone replication	All buckets replicate, lowest configuration effort, replicates data you may not want to copy	When every bucket has the same residency and recovery requirement
Replication scope	Per-bucket replication policy	Fine-grained control per bucket, more policy objects to create, review and audit	When some data must stay local or only selected datasets need a second copy. Confirm policy options for your release
Authentication backend	Local RGW users	Fastest to start, credentials managed in Ceph, separate lifecycle from your directory	Small teams, service accounts, or environments without a central directory
Authentication backend	LDAP	Central identity, but group-to-bucket mapping and directory availability become part of the storage path	When the directory is the authority for staff and access reviews must happen there
Authentication backend	Keystone	Fits OpenStack identity, adds a dependency on the Keystone service and its token handling	When the platform already runs OpenStack and Keystone is the identity source
Authentication backend	STS temporary credentials	Short-lived credentials for applications, needs a trust model and token lifetime policy	When workloads need temporary access tied to an identity provider rather than static keys
Load balancing	cephadm-managed ingress	Ceph deploys and manages the ingress services, fewer components outside Ceph, upgrades tied to cephadm	When the team wants the RGW front end lifecycle to follow the cluster
Load balancing	External load balancer	Uses existing network tooling and certificate processes, adds a component that Ceph does not manage	When the organization already standardizes on an appliance or cloud load balancer and its change process

How to build Ceph RGW multisite replication step by step

This sequence takes two Ceph clusters from release selection to a working RGW multisite setup, where objects written to the primary zone are verified in the secondary zone. Each step ends with a check you can run before moving on.

Confirm the release and target versions
Choose Squid (19.2.x) or Tentacle (20.2.x) before any host is built, and use the same release on both sites. Per the Ceph releases page, Squid's estimated end of life is October 31, 2026, and Tentacle's is June 1, 2027, so a Squid build starts with less supported time ahead. Confirm the current point release, such as Tentacle 20.2.4 or Squid 19.2.7 at the time of writing, and read its release notes. Done when the planned version is written into the design record and every host in the inventory is assigned to that release.
Bootstrap each cluster with cephadm
On each site, bootstrap a cluster with cephadm. It starts a single-node cluster with one Monitor and one Manager, and you then add the remaining hosts and OSDs, using one dedicated drive per OSD as the hardware recommendations advise. Your team or the partner performs this on each cluster, keeping the clusters separate. Check: the cluster status reports no unexplained warnings, every host appears in the orchestrator host list with the labels you planned, and the expected number of OSDs is up and in.
Deploy RGW daemons on each site
Using an orchestrator service specification, place Ceph Object Gateway daemons on the hosts you reserved for RGW in each cluster. Keep RGW on hosts that have enough memory for peak load, since the hardware recommendations advise sizing for peak use. Check: the orchestrator lists every RGW daemon as running, and each daemon accepts an HTTP connection on its configured port. Record the daemon names and ports, because the zone endpoints you create in the next step depend on them.
Create the realm, zonegroup and master zone
On the primary site, create the realm, then the zonegroup marked as master, then the master zone with endpoints that clients and the other site can reach. Use stable names or the ingress address as endpoints, not individual host names, so later changes do not require rebuilding the zone. Commit the period so the configuration is published. Check: the period output lists the zonegroup and master zone with the expected endpoints, and the period epoch has advanced after the commit.
Join the secondary zone to the realm
On the secondary site, pull the realm configuration from the primary using a system user's credentials, which should be stored in your secrets manager. Create the secondary zone in the same zonegroup with its own endpoints, then commit the period. This is the point where the two sites begin to exchange metadata and data. Check: the sync status on the secondary zone reports metadata and data sync progressing without errors, and the sync state eventually reports caught up once initial data has moved.
Place the ingress for load balancing
Deploy the cephadm ingress service in front of the RGW daemons on each site, with a virtual IP address and the TLS certificates your policy requires. Confirm with the Object Gateway documentation and your network team how the ingress handles connection failures for your S3 clients before go-live. Check: repeated requests to the virtual endpoint are served by more than one RGW daemon, and stopping one RGW daemon during a test upload does not fail the upload.
Create users, buckets, policies and lifecycle rules
Create the users and tenants that own data, then create buckets with an S3 client against the master zone. Apply bucket policies that grant only the actions each user needs, and set lifecycle rules for expiration or transition where your retention design calls for them. Check: a restricted test user can perform the permitted actions and receives denials for the rest, and the lifecycle configuration read back from the bucket matches the rules in your design document.
Enable replication and verify with a test upload
Confirm which buckets replicate and how. Zones in one zonegroup exchange data by default once the secondary has joined, but some designs need bucket-level sync policy, so confirm the behavior for your release against the Object Gateway documentation before relying on it. Upload a test object with an S3 client to a bucket on the primary, then read it back from the secondary. Check: the object appears in the secondary zone with a matching checksum, and the sync status shows no pending errors for that bucket.

How Ceph multisite sync behaves in production

Multisite replication on the Ceph Object Gateway is asynchronous, so a write accepted in one zone is not guaranteed to be readable in another zone at the same moment. Before you design applications around RGW multisite, plan for eventual consistency across sites. In the usual model, metadata (users, buckets and their configuration) and object data are synchronized between zones within a zonegroup through the RGW sync process, and the two kinds of sync can progress at different speeds. Ask your Ceph release's documentation to describe the exact sync states, the commands that report sync status, and which operations are replicated automatically in that release.

Replication lag is the window in which a client may see stale or missing data. A client that writes to the primary zone and reads from a secondary zone can get an older version of an object, a 404 for an object that exists elsewhere, or a bucket listing that does not yet show recent uploads. Application teams should decide which reads must be strongly consistent (usually by reading from the zone that accepted the write) and which can tolerate lag. Measure lag in your own environment under realistic write rates, and confirm with the release documentation which sync status output and metrics your monitoring should alert on.

Failover of the master zone is a deliberate operational procedure, not an automatic event. The master zone holds authoritative metadata changes for the zonegroup, so promoting a secondary zone requires an explicit period update and a decision about writes that the failed zone may have accepted but not yet replicated. Plan a runbook that covers who authorizes promotion, how client endpoints and load balancers are repointed, how the former master is rejoined without overwriting newer data, and how you reconcile any divergence. Validate each step in a non-production realm first, and confirm the exact commands and their order for your release in the Object Gateway documentation.

Deletes and versioned objects need explicit planning because they change what replicates. A delete on one zone is propagated as a change to other zones, so an object deleted on a secondary can disappear for clients elsewhere after sync. With bucket versioning enabled, delete markers and noncurrent versions replicate as separate records, which affects storage consumption and lifecycle rules in each zone. Lifecycle expiration rules that run in one zone may interact with sync in ways that differ across releases. Test a delete, an overwrite and a versioned delete across two zones, and record which zone's lifecycle policy removes data.

Before going live, ask your implementation team or Ceph support to confirm four things for your exact release: the sync behavior and status reporting, the documented failover and rejoin steps, the known limits and open issues affecting multisite and versioning, and the supported upgrade path for a multisite realm. Treat this summary as orientation only. The Ceph release notes and Object Gateway documentation for the version you run are the authoritative source, and any runbook you adopt should be rehearsed against that version.

What drives the effort and cost of RGW multisite

This table lists the factors that most change the effort and cost of an RGW multisite build, with the way to keep each one manageable. Read each row as a question to settle in the written scope before a fixed-scope quote is prepared. The main takeaway is that the number of zones, the bucket and object count, and the identity design usually matter more to effort than raw storage capacity.

Driver	Why it changes effort or cost	How to keep it down
Sites and zones	Each zone adds a cluster to build, monitor, upgrade and test, and each zone pair adds replication paths to validate.	Start with the fewest zones that meet your recovery and locality needs, and add zones in later phases once the first pair is stable.
Buckets and objects	Bucket count and object count drive index sizing, sync backlog, resharding behavior and the time needed for validation and migration.	Agree naming and bucket-per-tenant rules early, and benchmark index and sync behavior with a realistic object count before sizing.
WAN bandwidth and latency	Multisite sync moves every write across the WAN, so limited bandwidth or high latency lengthens sync lag and complicates failover testing.	Measure link capacity and latency between sites, set sync bandwidth limits deliberately, and confirm the expected recovery point before design freeze.
Authentication integration	Connecting RGW to LDAP, Keystone, OPA or STS, and mapping users to tenants, adds identity design, testing and ongoing access reviews.	Decide the identity source and user-to-tenant mapping in the scope document, and limit the first release to one authentication method.
Lifecycle and retention rules	Lifecycle expiration, transitions and legal hold requirements must be designed, tested per bucket and reviewed across zones.	Standardize a small set of lifecycle templates, and document which rules replicate and which are zone-local.
Client application count	Each S3 client needs endpoint, credential, TLS and behavior testing, and applications that depend on specific S3 features need extra validation.	Inventory clients and their S3 feature use early, then group them into a short list of tested client profiles.
Compliance evidence needs	Assessors may ask for configuration baselines, access logs, replication status records and tested recovery runbooks, which add documentation and collection work.	Confirm the evidence list with your assessor before build, and design logging and configuration export into the initial deployment.
Existing Ceph operator skill	A team already running cephadm or Rook clusters needs less training and fewer handover sessions, while a new team needs more runbook and operations work.	Record current skills and staffing in the scope, and plan knowledge transfer and runbook reviews as named deliverables.
Cost components	Cost is mainly people (design, build, testing, handover) and infrastructure (servers, drives, network and sites). Recurring items include operations and upgrade work.	Ask each quote to separate one-time build work from recurring support, and confirm which infrastructure the client supplies. Fixed-scope quotes depend on a written scope, so changes to the drivers above should be agreed in writing.

How the RGW design changes by deployment model

A single-site deployment places one zone in one zonegroup within one realm, often with no replication partner. The build is the simplest of the five layouts because RGW serves S3 requests directly from its gateway hosts and the design work centers on capacity, load balancing and access control. Multisite objects can be added later, but this tab assumes replication is out of scope for now.

What changes in the build:

Create one realm, one zonegroup and one zone, and treat the zone as the place where all buckets live.
Place RGW daemons behind a load balancer and decide how TLS terminates at that layer or at the gateway.
Define the pool and storage class layout for the zone before buckets exist, since moving data later is more work.
Keep the zone's endpoints in a single DNS namespace so clients have one address to use.

What to verify:

Confirm that bucket creation, object upload, multipart upload and lifecycle expiry work through the load balancer under your client load.
Confirm that the zone configuration can be exported and restored, and that the restore has been rehearsed.
Confirm the access model for users, tenants and bucket policies before application teams start writing data.

Check with your DeployOpen or Ceph engineers whether a single-zone plan leaves a clean path to adding a secondary zone.

Access control for RGW buckets, users and endpoints

Access to Ceph Object Gateway data is decided at several layers: who the user is, which policy applies to a bucket, which credentials a client holds, and which network paths reach the gateway and its admin and sync endpoints. The cards below cover the topic-specific controls for each layer. Cluster-wide identity and Dashboard concerns are covered in the Ceph SSO and identity integration and Ceph security hardening topics.

Least-privilege bucket policies

Bucket policies on RGW define which users, roles and actions may reach a bucket and its objects. Write them per application, grant only the S3 actions each workload needs, and avoid wildcard principals on production buckets. Before go-live, test each policy with a client that should be denied, because a missing Deny is easy to miss in a review of allow statements.

IAM and STS role use

The RGW implementation of the AWS IAM and STS APIs lets applications assume temporary roles instead of holding long-lived keys. Decide which workloads need roles, define trust policies that name the allowed principals, and set session lengths that match the job. Confirm the exact IAM and STS actions your chosen client libraries call against your release before you rely on them.

RGW user and access key lifecycle

Each RGW user holds one or more S3 access key pairs, and every key is a standing credential. Record an owner and purpose for each user, set a rotation schedule, and disable keys during offboarding and before deleting users. Ask your team to check for keys that no active application uses, since unused keys are a common source of exposure in object storage.

TLS on RGW and ingress endpoints

Clients should reach RGW only over TLS, whether the gateway terminates it directly or an ingress or load balancer does. Decide where certificates terminate, who issues and renews them, and whether traffic between the ingress and RGW is also encrypted. Confirm the minimum TLS version and cipher configuration with your security team, and verify the certificate chain from each client network.

Admin API and sync endpoint restriction

The RGW admin API and the endpoints used for multisite sync expose powerful operations, including user management and metadata replication. Restrict them to the replication network and to named administrative hosts, and keep them off the client-facing listener. Review firewall and ingress rules after each multisite change, because a new zone endpoint can quietly widen exposure.

MFA, LDAP, Keystone and OPA integration

RGW supports authentication through LDAP and Keystone, multi-factor authentication, and Open Policy Agent integration. Choose the source of truth for each user population, decide which controls apply to human and machine access, and document the failure behavior when the external service is unreachable. Confirm the configuration steps for your release, since these integrations differ in setup effort and operational dependencies.

How to test that replication works and fails safely

Replication is only proven when the team has tested it against written pass criteria, and those criteria should be agreed before the first test runs. For a Ceph Object Gateway (RGW) multisite design, the test plan should cover normal operation, the failover path and the failure path, because each one exposes a different weakness. Write down the expected result for every test, the evidence that will be captured, and who signs off. A test without a recorded expectation tends to be judged by whether it looked fine on the day. Start with client-side checks. Run S3 client conformance tests against the RGW endpoint that applications will use, including the load balancer or virtual IP in front of it, not only a gateway address inside the cluster. Then run object round trips in both directions: write through zone A and read through zone B, and the reverse. Use objects of several sizes, including multipart uploads, and compare checksums on read. Confirm that delete markers, versioning and object metadata behave the same way in both zones, since those are the behaviors applications most often depend on. Next, test access controls and lifecycle behavior. Attempt actions that bucket policies and IAM-style permissions should deny, from users in each tenant, and record every case that is allowed when it should not be. For lifecycle expiration, create test buckets with short expiration rules, confirm that objects expire on schedule in the primary zone, and confirm that the expiration does not leave the secondary zone in a different state. Ask the team to confirm how the RGW version in use handles lifecycle processing across zones, because this is a version-dependent area that should be checked, not assumed. The failover drill and the failure test are where the design earns its keep. For a planned master zone failover, record the time to promote the secondary, the state of in-flight writes, and the client behavior during cutover. For the failure test, cut one zone or the network link between zones, keep writing to the surviving zone, restore the link, and observe how sync catches up. Check sync status after bulk uploads and after recovery, and confirm that no object is lost or silently divergent. The team should define in advance the maximum acceptable lag, the allowed recovery window and the action if either is missed. These numbers must come from the business requirements and the team's own environment, not from a generic default.

Running RGW multisite after handover

Once the multisite zones are live, the operations team owns sync health, the data they hold, the upgrade path and the documents that let someone other than the builders respond to an incident. The four areas below connect because a sync fault, a lost realm configuration or an undocumented failover step can each leave one zone serving stale or missing objects.

Monitoring sync, health and capacity

Track multisite sync status per zone pair, gateway process health, load balancer or ingress health in front of each RGW endpoint, capacity per zone, and error rates on S3 requests. Sync lag and a stalled data log are the earliest signs of trouble, so alerts should fire on sync state rather than only on gateway uptime. Confirm with your Ceph release which radosgw-admin sync commands and Dashboard views your operators will use.

Backing up realm and period configuration

Export the realm, period and zonegroup definitions on a schedule and after every change, because a multisite topology cannot be rebuilt from bucket data alone. Include zone definitions and their endpoints, and store the exports outside the cluster they describe. Restoring them is a tested procedure, so schedule a restore exercise in a separate environment rather than assuming the exports are complete.

Backing up users, keys and access

Protect the RGW user records, access and secret keys, quotas and any bucket policies or ACLs that sit outside the bucket data itself. Keys are needed to read replicated buckets in a recovered zone, and rotating them without an inventory breaks client applications. Record which keys belong to which applications and owners, and confirm how your chosen authentication backend, such as LDAP or Keystone, is backed up alongside RGW.

Upgrading RGW with the cluster

Upgrade gateways in the same ordered cycle as monitors, managers and OSDs, using the cephadm process for your target release, and do not let one zone run a release far ahead of its peers for longer than the vendor guidance allows. After each gateway step, check that sync resumes and that the sync state returns to healthy before moving to the next zone. Confirm the supported version skew between zones for your release before scheduling.

Checking sync after each upgrade step

Run a fixed verification after every upgrade step: confirm sync status across all zone pairs, write a test object in each zone and confirm it appears in the others, and review error logs for sync retries. Record the results in the change ticket so a regression can be tied to a specific step. Agree the acceptance criteria and the rollback decision point before the window opens, not during it.

Handover documentation set

Hand over a topology diagram showing realm, zonegroup, zones and the replication paths between them, plus a zone and endpoint inventory with owners and ingress addresses. Add runbooks for failover, failback and recovery of a zone, and a lifecycle and policy catalog listing each bucket lifecycle rule, bucket policy and retention setting with its owning application. Keep these under version control and review them after every topology or release change.

Questions teams ask before building Ceph RGW multisite

How much does a Ceph RGW multisite build cost?

The cost is set by the written scope, not by a list price. Ceph itself is licensed under LGPL-2.1 or LGPL-3, and the project does not sell a paid edition, so the cost you pay is for hardware, network, staff time and professional services. The main drivers are the number of sites and zones, the raw and usable capacity you need, how many gateways and load balancers sit in front of RGW, the identity integrations, and how much testing and runbook work you want. Ask any provider, DeployOpen included, to break the quote into one-time work (design, build, validation, cutover) and recurring work (support, upgrades, monitoring). Hardware and bandwidth between sites are usually separate purchases, so ask which of these the quote includes.

How long does a Ceph RGW multisite implementation take?

Duration depends on how many zones are involved, whether the sites already run Ceph, and how quickly the client can provide access and decisions. The phases are topology design, cluster and gateway build at each site, realm and zone configuration, replication validation with test buckets, identity and policy setup, and handover. Delays most often come from waiting for network paths between sites, hardware delivery, identity system access, and sign-off on the zone topology. Ask for a phased timeline in the written scope that names the client dependencies for each phase, and confirm which milestones are fixed and which depend on client input.

What does our team need to provide for a multisite build?

Expect to provide network access between sites on the ports Ceph and RGW use, including the messenger ports and the gateway endpoints, and firewall change approval. You will also need access to your identity systems if RGW will authenticate users through LDAP, Keystone or STS, and a named owner who can approve the realm, zonegroup and zone layout. Decisions on replication scope, which buckets replicate and which stay local, and failover expectations need a business owner, not only engineers. Confirm these items with your network, identity and data owners before work starts so they appear in the statement of work.

Can our internal team build Ceph RGW multisite without a partner?

Yes, if you have people who already operate Ceph and understand multisite behavior. The Ceph documentation covers realms, zonegroups and zones, and cephadm handles container deployment, so a capable team can build it alone. The risk lies in the first multisite build: mistakes in zone layout, sync configuration, or failover design are harder to undo once buckets hold data. Ask whether your team has run a multisite sync test, restored from a second zone, and written a runbook. A partner is most useful for independent design review, a fixed-scope build with documented validation, and a handover that your staff can operate.

Does Ceph RGW replace a commercial object storage product?

Ceph RGW provides S3-compatible and Swift-compatible APIs and documented multisite replication, so it can serve many object storage workloads that run on self-hosted infrastructure. Whether it replaces a specific commercial product depends on the features your applications call, the compliance evidence you must produce, and the support model you need. Check your application's S3 API calls, bucket policy and lifecycle needs, object lock or versioning requirements, and the performance you need at your scale. Confirm each of these against the Ceph release you plan to run, because feature support differs between releases.

How does DeployOpen scope a fixed-scope Ceph RGW quote?

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that scope. For multisite work, the written scope normally lists the sites and zones, the hardware and network inputs you supply, the RGW features in use (authentication, bucket policies, lifecycle, load balancing), the validation tests, the documentation handed over, and the client dependencies with their owners. Anything outside the scope, such as hardware procurement or ongoing support, is listed separately. Ask for the scope document, the assumptions behind it, and the change process if a dependency slips.

What recurring work comes after a Ceph RGW multisite build?

After handover, the recurring work is monitoring replication lag and sync health, applying maintained Ceph releases, keeping TLS certificates and identity integrations current, testing failover and restores, and reviewing capacity. Ceph's maintained releases receive periodic backports and security fixes, so an upgrade plan is part of ongoing operations. Ask which of these your team will run, which a support agreement would cover, and how upgrade windows are scheduled across sites. DeployOpen offers ongoing support and upgrades as retainers, and the terms are agreed separately from the build.

How DeployOpen scopes, builds and hands over RGW multisite

DeployOpen scopes Ceph RGW S3 object storage and multisite replication as a written, fixed-scope engagement inside your own infrastructure. The work covers realm, zonegroup and zone layout, bucket and lifecycle design, load balancing and the validation steps that show replication behaves as designed. Ongoing support is available as a retainer once the cluster is in service.

How we scope

The written scope names the zones, sites and replication direction for your RGW deployment.
It records the bucket, user and authentication model, including whether RGW uses LDAP, Keystone or STS.
Sizing inputs such as object count, growth and failure domains are agreed before any hardware is ordered.

How we build

RGW daemons are deployed with cephadm, then realm, zonegroup and zone are configured in documented order.
Bucket policies, lifecycle rules and user quotas are drafted, version controlled and reviewed with your owners.
Load balancing in front of RGW endpoints is built and tested before replication is switched on.

How we hand over

Replication tests cover object writes in one zone, their arrival in the peer zone, and deletes and versioned objects.
Documentation covers the zone map, endpoints, authentication settings, lifecycle rules and the runbook for resyncing a zone.
Your team receives a walkthrough of failover, sync status checks and the upgrade path to supported Ceph releases.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrades, including moving off Squid before its estimated end of life, can be planned under a retainer.
Re-testing after changes to RGW, authentication or replication topology can be scoped under the same agreement.