Selection Guide · Cloud Infrastructure
Choose Object Storage Classes: GCS, S3 and Azure Blob
Storage-class selection goes beyond monthly GB price. Access frequency, retrieval charges, minimum retention, request counts and restore latency change total cost. Google Cloud…
Technical review:
Architecture and operating model
Storage-class selection goes beyond monthly GB price. Access frequency, retrieval charges, minimum retention, request counts and restore latency change total cost. Google Cloud Coldline/Archive, S3 archive options and Azure Archive do not share identical access behavior.
Do not equate Google Cloud archive classes with offline archive modes in Azure/S3. S3 includes both instant and restore-based options. Verify region, redundancy and API behavior for the selected class.
Lifecycle transitions and deletions are separate rules. Short retention or frequent recovery can erase archive savings. Include a ransomware recovery day requiring full-dataset retrieval in cost/time planning.
- 1Access/retention
- 2Class/region
- 3Retrieval/restore test
- 4Total-cost decision
Design parameters
- Access profile
- Measure retrieved GB and object counts; small-object requests can change costs.
- RTO
- Sum restore waiting, download and application startup.
- Retention period
- Check minimum durations and early-deletion conditions in current tariffs.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Platform | Example class families | Validation point |
|---|---|---|
| Google Cloud | Standard/Nearline/Coldline/Archive | Online access, retrieval and minimum duration |
| AWS | S3 Standard/IA/Glacier options | Instant or restore-based mode |
| Azure | Hot/Cool/Cold/Archive | Archive rehydration and redundancy |
Worked example
For 10 TB with 1% monthly access, assume 100 GB retrieval, but one annual full restore adds 10 TB. Model storage GB-month + retrieval GB + requests + egress + early deletion. This is a calculation model without tariffs, not a price quote.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Archive cheap but bill high | Retrieval, request or early-deletion costs. | Map bill items to actual access metrics. |
| RTO missed | Restore waiting or network limit. | Measure restore plus download for the full dataset. |
Acceptance checks
- Read current region-specific tariffs.
- Measure retrieved GB and object count.
- Verify minimum retention.
- Pilot full restore.
- Check lifecycle deletion separately.
- Compare all three on equal access assumptions.
Related concepts
Cost boundaries
Cost includes more than purchase price or a monthly resource bill. Licensing scope, storage, egress, backup, support, operating effort and disruption impact are separate items. Compare equal service levels, capacity and time periods; a cheaper option may exclude an obligation. Compare forecast and actual spending by resource or business unit. Assess underuse risk for commitments and uncontrolled growth for flexible models. Verify pricing and licensing conditions against official documents at decision time.
Retention and capacity
Retention defines which recovery points are kept and for how long. Daily, weekly and monthly points do not represent identical change patterns; full-copy creation and chain dependencies affect physical capacity. Retention decisions combine business requirements, applicable obligations and technical capacity. Longer retention does not automatically provide better recovery: the right point must be discoverable and readable. When changing a policy, test whether existing points are deleted immediately or handled differently by the product.
RTO and end-to-end recovery time
RTO specifies how soon a service must become usable after an incident. Downloading a backup or booting a VM accounts for only part of that duration. Record detection, approval, infrastructure preparation, data transfer, application startup and business validation separately. Define exactly what starts and stops the test clock. The same technical restore duration can produce different business interruptions when dependencies or access approvals introduce additional waiting.
Capacity and usable headroom
Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.
Durability and power loss
Survival of committed data depends on write guarantees across the database, OS, filesystem, controller and disks. Do not disable safety settings for speed without understanding caches and flush behaviour. Power-loss-protected storage helps but does not prove correctness of the entire chain. Run failure and recovery tests in a controlled lab, not production. Validate application records and supported consistency checks rather than merely opening a sample file.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.