Cloud Storage Explained: Complete Guide to Object, Block and File Storage, Security, Performance and Cost Optimization
Introduction: What Is Cloud Storage?
Cloud storage is a technology that allows organizations and applications to store data on infrastructure operated by a cloud provider and access that data through networks, APIs, operating-system interfaces or storage protocols.
Instead of purchasing physical disks, storage arrays and data-center infrastructure, organizations can provision storage as a cloud service and scale capacity according to application requirements.
Cloud storage is now a fundamental component of modern infrastructure.
Applications use cloud storage for:
- Databases
- Application files
- Images
- Videos
- Backups
- Logs
- Machine-learning datasets
- Archives
- Software artifacts
- Virtual-machine disks
- Container images
- Data lakes
- Disaster recovery
- Static websites
The architecture is closely connected to the concepts discussed in CorgiNetwork’s Cloud Computing Explained, because storage is one of the fundamental resources consumed by cloud applications.
NIST’s storage-security guidance covers data protection, isolation, authentication, authorization, encryption, restoration assurance and incident response across storage infrastructure.
The most important concept to understand is that cloud storage is not one technology.
Modern cloud platforms generally provide three major storage models:
CLOUD STORAGE
|
+--------------+--------------+
| | |
v v v
Object Block File
Storage Storage Storage
| | |
S3/Blob VM Disks Shared Files
/Buckets Databases File Systems
Data Lakes Applications NAS-like
Understanding these models is essential before designing a production cloud architecture.
1. The Three Major Types of Cloud Storage
Cloud storage can broadly be divided into:
- Object storage
- Block storage
- File storage
They solve different problems.
| Storage Type | Main Concept | Typical Use |
|---|---|---|
| Object | Objects + metadata | Backups, media, archives, data lakes |
| Block | Raw storage volumes | VMs, databases, applications |
| File | Shared filesystem | Shared application files |
| Archive | Long-term low-access storage | Compliance, historical data |
Choosing the wrong storage model can affect:
- Performance
- Application architecture
- Scalability
- Availability
- Cost
- Backup strategy
- Security
2. Object Storage Explained
Object storage stores information as independent objects.
An object normally consists of:
Object
|
+-- Data
|
+-- Metadata
|
+-- Identifier
A simplified structure looks like:
Bucket
|
+-- images/
| +-- photo01.jpg
| +-- photo02.jpg
|
+-- videos/
| +-- video01.mp4
|
+-- backups/
+-- backup-2026-09-20.tar
Unlike a traditional filesystem, object storage does not depend on the same directory-and-block model used by conventional disks.
This makes it particularly useful for very large datasets.
3. Amazon S3
Amazon Simple Storage Service, commonly known as S3, is one of the best-known object-storage platforms.
AWS describes S3 as a highly durable object-storage service and provides features including versioning, replication, encryption and lifecycle management.
The basic S3 hierarchy is:
AWS Account
|
v
Bucket
|
+-- Object
+-- Object
+-- Object
Applications can interact with S3 through:
- AWS Console
- AWS CLI
- REST APIs
- SDKs
- Infrastructure as Code
- Application frameworks
For example:
aws s3 ls
or:
aws s3 cp backup.tar.gz s3://example-backup-bucket/
S3 is particularly useful for:
- Backups
- Static assets
- Images
- Videos
- Logs
- Data lakes
- Archives
- Software packages
4. Azure Blob Storage
Microsoft Azure provides object storage through Azure Blob Storage.
Blob Storage is designed for large amounts of unstructured data such as:
- Images
- Documents
- Video
- Audio
- Backups
- Logs
- Data archives
Microsoft’s Azure Blob Storage security documentation describes encryption, encryption scopes, versioning, soft delete, immutable storage and backup/recovery capabilities.
The basic architecture is:
Storage Account
|
v
Container
|
+-- Blob
+-- Blob
+-- Blob
5. Google Cloud Storage
Google Cloud provides object storage through Cloud Storage.
Google describes Cloud Storage as a service supporting features such as:
- Encryption
- Object versioning
- Retention policies
- Lifecycle management
- Object holds
- Customer-managed encryption keys
- Soft delete
The official Google Cloud Storage documentation provides detailed information about these capabilities.
A simplified architecture is:
Google Cloud Project
|
v
Bucket
|
+-- Object
+-- Object
+-- Object
6. Object Storage vs Traditional File Systems
A traditional filesystem might look like:
/
├── var
│ ├── log
│ └── www
├── home
│ └── user
└── etc
Object storage instead uses objects identified through keys or object names.
For example:
bucket:
users/1001/avatar.jpg
users/1002/avatar.jpg
backups/server-01.tar
The apparent directory structure is often part of the object naming convention rather than a conventional filesystem hierarchy.
This difference matters when designing applications.
7. Block Storage Explained
Block storage provides storage volumes that behave more like traditional disks.
A virtual machine may see:
/dev/sda
/dev/sdb
/dev/nvme0n1
The cloud provider manages the physical storage infrastructure while the operating system manages the filesystem and data structures on the virtual disk.
A simplified architecture:
Cloud VM
|
v
Virtual Disk
|
v
Block Storage Service
|
v
Physical Storage Infrastructure
Block storage is commonly used for:
- Virtual machines
- Databases
- Enterprise applications
- Boot volumes
- High-performance workloads
It is therefore closely related to virtualization. CorgiNetwork’s Virtualization Explained provides the foundation for understanding how virtual machines consume virtualized compute, networking and storage resources.
8. File Storage Explained
File storage provides shared filesystem access.
Multiple workloads can access the same filesystem:
File Storage
|
+--------+--------+
| | |
VM01 VM02 VM03
| | |
+--------+--------+
This model is useful for applications requiring shared files.
Examples include:
- Shared application content
- Enterprise applications
- User home directories
- Media-processing workflows
- Shared configuration
- Legacy applications
File storage can therefore be more appropriate than object storage when an application expects conventional filesystem operations.
9. Object vs Block vs File Storage
The difference can be summarized as follows:
| Characteristic | Object | Block | File |
|---|---|---|---|
| Access model | API | Disk/block device | Filesystem |
| Scalability | Very high | High | High |
| Typical access | HTTP/API | OS I/O | File protocols |
| Databases | Usually indirect | Excellent | Possible |
| Backups | Excellent | Excellent | Good |
| Media | Excellent | Possible | Good |
| Shared filesystem | No | Usually no | Yes |
| Data lakes | Excellent | Poor fit | Possible |
| VM boot disk | No | Excellent | No |
| Long-term archive | Excellent | Possible | Possible |
There is no universally “best” storage type.
The correct choice depends on the application.
10. Cloud Storage Architecture
A typical cloud application might use all three storage models simultaneously:
Internet
|
v
Load Balancer
|
v
Application Tier
/ | \
/ | \
v v v
Block Object File
Storage Storage Storage
| | |
Database Media Shared
/ VM Disk Backups Files
This architecture is common because different workloads have different storage requirements.
For example:
- Database → block storage
- User images → object storage
- Shared documents → file storage
- Long-term backups → archive/object storage
11. Cloud Storage Performance
Storage performance is not determined by capacity alone.
Important characteristics include:
- Latency
- Throughput
- IOPS
- Request rate
- Object size
- Concurrent connections
- Network bandwidth
- Storage class
- Access pattern
Latency
Latency measures how long an operation takes.
Throughput
Throughput measures how much data can be transferred per unit of time.
IOPS
Input/output operations per second are especially important for workloads performing many small disk operations.
A database may therefore have very different storage requirements from a video archive.
12. Storage Workload Profiles
Before selecting storage, identify the workload.
High-transaction database
Needs:
- Low latency
- High IOPS
- Predictable performance
- Strong durability
Video archive
Needs:
- Large capacity
- High throughput
- Low storage cost
- Infrequent access support
Application assets
Needs:
- Fast retrieval
- High availability
- HTTP/API access
- Global delivery integration
Backup repository
Needs:
- Durability
- Versioning
- Retention
- Recovery
- Cost efficiency
The storage design should therefore begin with the workload rather than the storage product.
13. Storage Classes and Tiers
Cloud providers offer different storage classes or access tiers.
A typical model is:
Frequently Accessed
|
v
Hot / Standard
|
v
Cool / Infrequent
|
v
Archive
|
v
Deep Archive
The less frequently data is accessed, the more attractive lower-cost storage tiers can become.
However, storage cost is not simply the monthly price per GB.
You should consider:
- Storage cost
- Retrieval charges
- Request charges
- Data transfer
- Lifecycle transitions
- Replication
- Management overhead
14. Cloud Storage Lifecycle Management
Data changes throughout its lifetime.
For example:
Day 0
New Data
|
v
Standard Storage
|
v
30 Days
Cool Storage
|
v
180 Days
Archive
|
v
7 Years
Delete
AWS S3 Lifecycle supports rules that can transition objects between storage classes or expire objects according to defined policies.
Google Cloud Storage similarly supports Object Lifecycle Management, allowing rules to automatically perform actions when objects meet specified conditions.
Azure Blob Storage provides lifecycle-management policies that can move blobs between access tiers or delete data according to defined conditions.
Lifecycle policies are therefore one of the most useful tools for controlling long-term storage costs.
15. Storage Versioning
Versioning preserves previous versions of data.
Consider a file:
document.pdf
Without versioning:
document.pdf
|
v
Updated
|
v
Old version lost
With versioning:
document.pdf
Version 1
Version 2
Version 3
Version 4
This can help recover from:
- Accidental deletion
- Application errors
- Incorrect updates
- Some ransomware scenarios
- User mistakes
AWS documents S3 Versioning as a mechanism for preserving, retrieving and restoring previous object versions.
Azure Blob Storage also supports versioning, while Google Cloud Storage provides Object Versioning.
16. Versioning Is Not the Same as Backup
This distinction is extremely important.
Versioning:
Same Storage
|
+-- Old Version
+-- Current Version
Backup:
Primary Environment
|
v
Independent Backup
|
v
Separate Recovery Location
If an attacker gains administrative access to a storage environment, simply having versions in the same administrative boundary may not provide sufficient recovery protection.
A robust backup architecture should consider:
- Separate accounts/projects
- Separate credentials
- Immutable copies
- Cross-region replication
- Offline or isolated copies
- Retention policies
NIST’s storage-security guidance specifically addresses restoration assurance and data protection as storage-security concerns.
17. Object Immutability
Some data must not be modified or deleted for a defined period.
Examples:
- Financial records
- Compliance archives
- Legal evidence
- Audit logs
- Security records
- Certain backup datasets
This can be achieved using immutable storage mechanisms.
Google Cloud Storage provides retention policies and object retention controls.
Azure Blob Storage supports time-based retention and immutable storage capabilities.
AWS provides S3 Object Lock for write-once-read-many style protection.
The architecture becomes:
Application
|
v
Storage
|
v
Immutable Retention
|
v
Recovery / Compliance
18. Cloud Storage Encryption
Encryption should protect data both:
- In transit
- At rest
A simplified architecture:
Application
|
| TLS
v
Cloud Storage API
|
| Encryption
v
Storage Infrastructure
Modern cloud storage services provide server-side encryption capabilities.
For example, AWS states that S3 applies server-side encryption as a base-level protection for objects stored in S3.
Google Cloud Storage provides encryption options including customer-managed encryption keys through Cloud KMS.
Azure supports encryption scopes and integration with key-management services for Blob Storage.
19. Customer-Managed Encryption Keys
Organizations with stronger control requirements may use customer-managed keys.
The architecture becomes:
Application
|
v
Storage Service
|
v
Encryption
|
v
Customer-Managed Key
|
v
Key Management Service
This gives organizations more control over:
- Key rotation
- Access policies
- Key lifecycle
- Auditing
- Separation of duties
Google Cloud documents customer-managed encryption keys through Cloud KMS for Cloud Storage.
20. Cloud Storage Access Control
Storage security depends heavily on authorization.
An access request should conceptually pass through:
Request
|
v
Authentication
|
v
Authorization
|
v
Policy Evaluation
|
v
Storage Object
Important questions include:
- Who can read the object?
- Who can write?
- Who can delete?
- Who can modify policies?
- Which application can access the bucket?
- Which users can administer the storage account?
Cloud storage should follow the same least-privilege principles described in CorgiNetwork’s Cloud Security Explained architecture.
21. Public Storage Exposure
One of the most dangerous configuration mistakes is unintentionally making sensitive storage publicly accessible.
For example:
Internet
|
v
Public Bucket
|
+-- Customer Data
+-- Backups
+-- Documents
This architecture can expose sensitive information.
A safer design is:
Application
|
Authenticated API
|
Authorization
|
Private Storage
Public access should therefore be an explicit requirement rather than a default configuration.
22. Cloud Storage and IAM
Storage security and IAM cannot be separated.
A secure storage design should distinguish between:
Storage Administrator
Application
Developer
Security Team
Backup System
End User
Each identity should have different permissions.
For example:
| Identity | Read | Write | Delete | Admin |
|---|---|---|---|---|
| Application | Yes | Yes | No | No |
| Developer | Limited | Limited | No | No |
| Backup System | Yes | Yes | Restricted | No |
| Storage Admin | Yes | Yes | Yes | Yes |
| Public User | Limited | No | No | No |
The exact permissions should depend on the workload.
23. Cloud Storage Monitoring
Storage activity should be monitored.
Useful events include:
- Object creation
- Object deletion
- Permission changes
- Policy changes
- Authentication failures
- Unusual downloads
- Large data transfers
- Encryption changes
- Lifecycle events
A monitoring architecture might look like:
Storage
|
+---- Access Logs
|
+---- Audit Logs
|
+---- API Logs
|
+---- Security Events
|
v
SIEM
|
v
Detection
|
v
Incident Response
This connects cloud storage security directly with CorgiNetwork’s SIEM Explained and Intrusion Detection and Prevention Systems coverage.
24. Cloud Storage Backup Architecture
A production backup strategy should not depend on a single copy.
A simplified model is:
Production
|
+----------+----------+
| |
v v
Local Backup Cloud Backup
|
+------+------+
| |
Region A Region B
| |
+------+------+
|
Immutable Copy
The exact design depends on:
- Recovery Point Objective
- Recovery Time Objective
- Compliance
- Budget
- Data volume
- Application criticality
25. RPO and RTO
Two important disaster-recovery concepts are:
Recovery Point Objective — RPO
How much data loss can the organization tolerate?
For example:
RPO = 15 minutes
means the organization aims to recover to a point no more than approximately 15 minutes behind the failure, subject to the actual backup/replication design.
Recovery Time Objective — RTO
How quickly must the service be restored?
For example:
RTO = 1 hour
means the recovery design targets restoring service within approximately one hour.
Cloud storage architecture should be designed around these requirements rather than around storage capacity alone.
26. Cloud Storage Replication
Replication creates additional copies of data.
Possible architectures include:
Region A
|
+---- Primary Storage
|
v
Region B
|
+---- Replica
Replication can improve:
- Disaster recovery
- Geographic resilience
- Business continuity
- Data locality
- Availability
AWS documents cross-region replication as one option for creating copies across geographically separated regions.
However, replication is not automatically a backup.
If corrupted or malicious data is replicated immediately, the replica may also contain the corruption.
Therefore:
Replication + versioning + retention + independent recovery controls
is generally stronger than replication alone.
27. Cloud Storage and Ransomware
Storage systems must also be designed for destructive attacks.
A simplified ransomware scenario:
Compromised Identity
|
v
Storage Access
|
v
Files Modified / Deleted
|
v
Backup Also Targeted
A stronger architecture introduces independent protection:
Compromised Identity
|
v
Primary Storage
|
+---- Versioning
|
+---- Immutable Retention
|
+---- Independent Backup
|
+---- Restricted Backup Credentials
Azure’s documentation specifically identifies versioning, soft delete and point-in-time restore as mechanisms that can contribute to recovery from accidental or malicious deletion.
28. Cloud Storage Cost Optimization
Storage costs can grow quickly.
A simplified cost model is:
Total Cost =
Storage
+
Requests
+
Retrieval
+
Data Transfer
+
Replication
+
Management
Cost optimization should therefore consider actual workload behavior.
For example:
Frequently Used
|
v
Standard Tier
|
v
Rarely Used
|
v
Cool Tier
|
v
Archive
AWS S3 Lifecycle can automatically transition objects to lower-cost classes or expire data based on rules.
Google Cloud and Azure provide similar lifecycle-management capabilities.
29. Data Lifecycle Management
A mature storage architecture defines the complete data lifecycle:
Create
|
v
Active
|
v
Less Frequently Used
|
v
Archive
|
v
Retention
|
v
Secure Deletion
At each stage, define:
- Storage class
- Access permissions
- Encryption
- Retention
- Backup
- Monitoring
- Deletion policy
This prevents cloud storage from becoming an unmanaged collection of old data.
30. Cloud Storage and Compliance
Certain workloads have regulatory requirements involving:
- Retention
- Encryption
- Access control
- Auditability
- Data residency
- Data deletion
- Immutability
NIST’s storage-security work emphasizes security management, authentication, authorization, configuration control, data protection, isolation, restoration and encryption.
Cloud storage architecture should therefore begin with the organization’s regulatory and business requirements rather than simply selecting the cheapest storage class.
31. Cloud Storage Architecture for Web Applications
Consider a modern web application:
INTERNET
|
v
CDN / WAF
|
v
Load Balancer
|
v
Web Application
|
+----------+----------+
| |
v v
Application Data Object Storage
|
Images / Videos
|
v
CDN
The application stores large media files in object storage rather than directly on application servers.
This has several architectural advantages:
- Application servers remain stateless
- Storage can scale independently
- Media can be delivered through a CDN
- Backups become easier
- Multiple application instances can access the same data
32. Cloud Storage for Databases
Databases often require block storage because database engines perform structured read/write operations against storage volumes.
A simplified model:
Application
|
v
Database
|
v
Block Storage
|
v
Backup
|
v
Object Storage
This illustrates how multiple storage models can coexist in one architecture.
The database uses block storage for active workloads while backups can be stored as objects.
33. Cloud Storage for Data Lakes
Object storage is particularly important for data lakes.
A simplified architecture:
Data Sources
|
+---- Applications
+---- Logs
+---- Databases
+---- IoT
+---- APIs
|
v
Object Storage
|
+------+------+
| |
Raw Processed
| |
+------+------+
|
v
Analytics / AI
Object storage provides a scalable foundation for large collections of unstructured and semi-structured data.
34. Cloud Storage Security Checklist
Before deploying production storage, verify:
Access Control
- Public access reviewed
- Least privilege implemented
- Administrative permissions restricted
- Service identities reviewed
- MFA enabled for privileged users
Encryption
- Encryption at rest enabled
- TLS used for data in transit
- Key policies reviewed
- Key rotation considered
- Customer-managed keys used where required
Recovery
- Versioning enabled where appropriate
- Backups configured
- Immutable copies considered
- Recovery tested
- RPO defined
- RTO defined
Monitoring
- Storage access logged
- Administrative actions logged
- Permission changes monitored
- Unusual downloads detected
- Security events integrated with SIEM
Lifecycle
- Storage tiers defined
- Lifecycle policies configured
- Retention requirements documented
- Expiration policies reviewed
- Archive strategy defined
35. Common Cloud Storage Mistakes
Mistake 1: Choosing storage based only on price
The cheapest storage class may not provide the required access performance.
Mistake 2: Treating versioning as a complete backup
Versioning helps recovery but does not automatically create an independent backup.
Mistake 3: Making buckets or containers public
Public access should be deliberate and tightly controlled.
Mistake 4: Giving applications excessive permissions
Applications should not receive administrative access simply because they need to read or write data.
Mistake 5: Ignoring lifecycle policies
Unused data can accumulate for years and create unnecessary costs.
Mistake 6: Never testing recovery
A backup that has never been restored should not be assumed to be reliable.
Mistake 7: Storing secrets in object storage without proper controls
Sensitive credentials require dedicated access controls and secret-management practices.
Mistake 8: Ignoring data-transfer costs
Moving large amounts of data between regions, services or external networks can significantly affect the total cost.
36. Cloud Storage Decision Framework
When selecting a storage architecture, ask:
Question 1
Does the application need a filesystem?
Yes → File Storage
Question 2
Does the application need a virtual disk?
Yes → Block Storage
Question 3
Does the application primarily store large independent objects?
Yes → Object Storage
Question 4
Is the data rarely accessed?
Consider an archive/cool storage tier.
Question 5
Is recovery important?
Consider versioning, backup and immutable storage.
Question 6
Is the data sensitive?
Implement encryption, IAM and monitoring.
Question 7
Is the dataset growing continuously?
Use scalable storage and lifecycle management.
37. Cloud Storage: AWS vs Azure vs Google Cloud
| Capability | AWS | Azure | Google Cloud |
|---|---|---|---|
| Object Storage | Amazon S3 | Azure Blob Storage | Cloud Storage |
| Main Unit | Bucket/Object | Container/Blob | Bucket/Object |
| Versioning | Yes | Yes | Yes |
| Encryption | Yes | Yes | Yes |
| Lifecycle | Yes | Yes | Yes |
| Retention | Yes | Yes | Yes |
| Immutable Controls | Object Lock | Immutable Blob Storage | Retention/Object Holds |
| Customer Keys | KMS | Key Vault | Cloud KMS |
For the broader cloud-platform comparison, CorgiNetwork’s AWS vs Azure vs Google Cloud remains the appropriate companion article.
The important point is that the architectural concepts are similar even though terminology and implementation differ.
38. Cloud Storage and Cloud Networking
Storage is not isolated from networking.
Applications must reach storage services through:
- Private networks
- Public endpoints
- Private endpoints
- Service endpoints
- VPN connections
- Dedicated cloud connectivity
The network path can therefore affect:
- Security
- Latency
- Throughput
- Availability
- Cost
CorgiNetwork’s Cloud Networking Explained covers the VPC, subnet, routing, NAT, VPN and firewall concepts required to understand these architectures.
39. Cloud Storage and Infrastructure
Storage is one component of a broader infrastructure architecture:
Cloud Infrastructure
|
+-----------------+-----------------+
| | |
Compute Network Storage
| | |
VM VPC/VNet Object
Containers Subnets Block
Serverless Routing File
| | |
+-----------------+-----------------+
|
Security
|
IAM / Encryption / Logs
This is why cloud storage design should not be performed independently from compute, networking and security.
40. Final Cloud Storage Architecture
A production-grade architecture can combine multiple storage technologies:
USERS
|
v
CDN / WAF / Edge
|
v
Load Balancer
|
v
Application Tier
/ | \
/ | \
v v v
Database Object File
| Storage Storage
| | |
Block Disk Media Shared Data
| | |
+--------+---------+
|
Backup / Recovery
|
+-----------+-----------+
| |
Immutable Copy Secondary Region
| |
+-----------+-----------+
|
Monitoring / SIEM
Security surrounds the entire architecture:
IAM
+
Least Privilege
+
Encryption
+
Key Management
+
Versioning
+
Immutable Retention
+
Lifecycle Management
+
Monitoring
+
Backup
+
Disaster Recovery
Frequently Asked Questions
What is cloud storage?
Cloud storage is a storage service provided through cloud infrastructure that allows applications and users to store and retrieve data without directly managing the underlying physical storage infrastructure.
What are the three main types of cloud storage?
The three major types are object storage, block storage and file storage.
What is object storage best for?
Object storage is particularly useful for backups, media, archives, logs, static assets and large unstructured datasets.
What is block storage best for?
Block storage is commonly used for virtual-machine disks, databases and applications that require disk-like storage.
What is file storage best for?
File storage is useful when applications require shared filesystem access.
Is cloud storage secure?
Cloud storage can provide strong security controls, but security depends on configuration, IAM, encryption, network design, monitoring and recovery architecture.
Is cloud storage a backup?
Not necessarily. Storage and backup are different concepts. A storage system may be the primary copy of data, while backup is designed to provide recoverability from deletion, corruption, failure or attack.
Should I enable versioning?
Versioning can be valuable for data that needs protection against accidental overwrite or deletion, but it should be combined with appropriate lifecycle and recovery controls.
What is the difference between S3, Azure Blob and Google Cloud Storage?
All three are major cloud object-storage services, but they belong to different cloud ecosystems and differ in APIs, pricing, integrations, identity models and platform-specific features.
How can cloud storage costs be reduced?
Use appropriate storage tiers, lifecycle policies, retention rules and deletion policies while considering request, retrieval, replication and data-transfer costs.
Conclusion
Cloud storage is much more than renting disk space from a cloud provider.
A well-designed storage architecture begins with the application’s requirements and then selects the appropriate combination of:
Object Storage + Block Storage + File Storage + Backup + Replication + Security + Lifecycle Management
Object storage is ideal for large collections of independent objects, block storage provides disk-like volumes for demanding workloads, and file storage provides shared filesystem access.
Security must be integrated throughout the architecture.
That means:
IAM → Encryption → Network Security → Versioning → Backup → Immutable Storage → Monitoring → Recovery
AWS documents versioning, encryption, replication and lifecycle capabilities for S3; Azure documents versioning, soft delete, immutability and lifecycle controls for Blob Storage; and Google Cloud provides versioning, retention, lifecycle management and encryption controls for Cloud Storage.
For the broader architecture, this article connects directly with CorgiNetwork’s Cloud Computing Explained, IaaS vs PaaS vs SaaS, AWS vs Azure vs Google Cloud, Cloud Networking Explained, Cloud Security Explained, Virtualization Explained, and SIEM Explained articles.
The result is a connected Cloud & DevOps knowledge cluster where cloud infrastructure, networking, storage and security reinforce one another.
Official Technical Resources
- NIST — Security Guidelines for Storage Infrastructure
- AWS — Amazon S3 Data Protection
- AWS — S3 Lifecycle Management
- AWS — S3 Versioning
- AWS — S3 Security Best Practices
- Microsoft — Secure Azure Blob Storage
- Microsoft — Azure Blob Lifecycle Management
- Google Cloud — Cloud Storage Overview
- Google Cloud — Object Lifecycle Management