Cloud Planning
Cloud storage and backups
Choose cloud storage by workload and access needs, then design protected backups and check recovery against business targets.
Choose cloud storage for how an application reads, changes and shares data. Design backups for the loss events the business must recover from. A stored copy does not show that the team can restore a usable service within its recovery targets.
Match storage to the workload
Does the application fetch named objects through an API, use a disk-like volume, or need a shared filesystem? Record data volume, object or file sizes, read and write patterns, access methods and the people or services that need access.
| Storage interface | A useful starting case | Check before choosing |
|---|---|---|
| Object | Documents, images, exports and backup sets accessed as objects | API compatibility, object sizes and request pattern |
| Block | A virtual machine disk or application needing a volume | Capacity, I/O, attachment rules and filesystem ownership |
| File | Applications or staff needing shared paths | Protocol, concurrent access, permissions and network path |
These are access interfaces, not performance grades. A block volume can hold a filesystem without becoming a managed shared file service. An object store can hold files, but software expecting filesystem locking or in-place changes needs its compatibility checked.
Decide how quickly data must be available
Access frequency is only part of a tier decision. Check how long a reader can wait, how often data changes, how long it remains stored, and how much may be retrieved during an incident. Retrieval, request, transition and minimum-duration charges can offset a lower storage charge.
Provider archive labels describe different access paths. Some archive classes permit immediate reads with higher access charges; others require a restore or rehydration step. Keep an accessible recovery copy if the agreed recovery time cannot accommodate that step.
Use access requirements to guide tier choices
A storage class is separate from the storage interface. Amazon S3 describes class selection by use case and performance access requirements, with options for frequently accessed, changing or unknown access patterns, and for infrequently or rarely accessed objects.
For example, Amazon S3 Standard is its default class, and its documentation also describes S3 Intelligent-Tiering for changing or unknown access patterns. Treat these as provider-specific examples, not universal tier names. Compare the access path and performance requirements of the service under consideration.
Amazon S3 Storage Classes by Access Pattern
- S3 StandardFrequently accessed data
- S3 Intelligent-TieringChanging or unknown access patterns
- S3 Glacier Instant RetrievalInfrequent access with immediate retrieval
- S3 Glacier Flexible RetrievalRarely accessed data with moderate retrieval time
Design backups around loss events
Name the loss events to cover, such as accidental deletion, a damaging update or compromised production credentials. Decide which data, application components and settings must return together. Version history may help with an overwritten object, but check its retention, deletion controls and application coverage.
Set a recovery time objective (RTO), the longest acceptable interruption before service is usable, and a recovery point objective (RPO), the greatest acceptable age of recovered data. Business owners agree on these limits.
A backup schedule is only part of a proposed RPO: failed jobs, missing data and restoration steps can change the result.
For each important data set, record the source, destination, frequency, retention, backup owner and restore owner. Include the configuration and keys needed to use recovered data, with secure access arranged for an incident.
Set recovery targets from business impact
Assign RTO and RPO values to each workload based on business impact, rather than choosing arbitrary targets. AWS guidance recommends using predefined workload tiers where practical, or setting objectives for individual workloads if tiering is not possible.
Consider workload dependencies, operational requirements and cost when turning targets into a recovery approach. The effect of downtime may also change over time: AWS gives the example of a manufacturing line that must remain shut until the next shift once an outage passes a certain point.
Avoid targets that are too lenient for business needs or stricter than those needs. AWS guidance cautions that zero time to recover and zero data loss may not be achievable, and that unnecessarily strict targets can require a costlier, more complicated recovery strategy.
Check protection and cost together
Restrict who can read, change or delete backups. Consider a recovery copy or retention control that remains usable if production credentials are compromised, and check how the chosen configuration enforces it.
Replication can carry a damaging change to another live copy; a protected earlier recovery point addresses that different risk.
Estimate costs from the intended configuration: live capacity, copies, retention, requests, retrieval, data movement and temporary restore resources. Cost both normal use and a substantial recovery. Use current rates for the exact service, region and billing arrangement.
Critical Backup and Recovery Metrics
- RTO (Recovery Time Objective)
- Max acceptable downtime before service is usable
- RPO (Recovery Point Objective)
- Max acceptable data age at recovery
- Retention Period
- How long backups are kept before deletion
- Protected Recovery Copy
- Backup copy isolated from production changes
Verify the storage service’s controls
For example, Microsoft says Azure Storage encrypts all data written to a storage account and provides fine-grained control over data access. Confirm that permissions configured for the workload and recovery copies suit the intended access requirements.
Require recovery evidence
Plan a controlled restore from a known recovery point. Rebuild the required data and settings, complete an application action, and compare elapsed time and recovered data age with the agreed RTO and RPO.
Record missing dependencies and repeat affected steps after changes.
Keep a short decision record for each workload: storage interface, tier, owner, data location, access requirements, protected recovery points, cost assumptions, recovery targets and the latest restore evidence.
In this guide
- Object, block and file storage comparedCompare object, block and file storage by access method, sharing needs and application behaviour before choosing a cloud service.
- Choosing storage tiers from access patternsUse read frequency, retrieval time and retention to choose object-storage tiers, then check total lifecycle and recovery costs.
- Testing cloud backups against recovery requirementsPlan an isolated cloud-backup restore, measure usable recovery against RTO and RPO, and record what the test actually proves.
