A media analytics business stores public product photos, private medical-study exports, and event data awaiting nightly transformation. It wants one Azure Storage account to simplify operations, but the datasets require different naming rules, access control, retention, throughput, and recovery. Putting every file into a hot blob container is easy at first and expensive later. Conversely, forcing an analytics pipeline to consume deeply archived objects may break the daily reporting deadline. The storage architecture needs to follow the data lifecycle, not one team’s preferred SKU.
For Microsoft AZ-305, semi-structured and unstructured storage design includes service fit, performance, durability, protection, and cost. The existing high-scale Azure storage specialist explains broad service-family selection. This article concentrates on Azure Blob Storage and Azure Data Lake Storage Gen2: namespaces, tiers, redundancy, access mechanisms, and deletion or recovery behavior that affect real applications.
Classify objects by interface and access frequency
An application serving images over HTTP generally uses object access patterns: write an object, retrieve by name, replace or version it, and apply cache rules. An analytics pipeline may navigate a directory-like hierarchy and require efficient rename or permission operations over folders. An old Windows application may expect an SMB file share and should not be migrated to Blob Storage by assuming a URL is a filesystem mount. Identify the interface expectation before pricing capacity.
For each dataset, measure object size distribution, daily reads, mutation frequency, retention period, required restoration time, and the number of consumers. A million tiny log objects behave differently from a few huge video archives. Document which data is a system of record, which is reproducible from other inputs, and which is temporary staging that should be expired after a validated pipeline run.
Distinguish ordinary blob semantics from hierarchical namespace
Azure Data Lake Storage Gen2 uses Azure Blob Storage with a hierarchical namespace to support directory-oriented operations that can help analytic and big-data workloads. That can improve workloads involving folder-level operations and permissions, but it also changes how clients should interact with the service. The Data Lake Storage Gen2 documentation outlines the interface and namespace implications.
A data engineering application that organizes events by date and customer may need directory-based organization and access policies. A simple image service may not benefit from the added namespace features. Choose the namespace deliberately at account design time according to supported capabilities, feature compatibility, and existing tooling; do not assume every storage option is interchangeable after production data is deployed.
Choose access controls that match the user journey
Azure RBAC can grant management or data-plane roles at supported scopes, while storage-specific access controls and SAS tokens address different scenarios. An application accessing its own private files should usually rely on an appropriately scoped workload identity where supported. A third-party recipient needing temporary access to one object may require a narrowly scoped time-limited SAS or application-mediated download instead of broad account keys.
Do not embed storage account keys inside mobile code or an unprotected website. If shared-key access is used at all, treat it as high-impact access and plan key rotation and monitoring. For hierarchical namespaces, consider both role assignments and supported path-level ACL behavior. A customer who can authenticate to your application still should not be able to fetch another customer’s blob simply by guessing the object name.
Model hot, cool, cold, and archive behavior
Storage tiers represent cost and retrieval trade-offs. Frequently served data belongs in an appropriate online tier; infrequent or historical objects may suit lower-cost options when access frequency and retention justify them. Archive is a different workflow because rehydration is required before an archived object is normally readable. A compliance record that might need retrieval within minutes should not be placed into a slow restore path without business approval.
Account for operations, data retrieval, early deletion charges, transitions, and the effect of rehydration on user workflows. The cheapest capacity rate can be the wrong total price for data that is repeatedly retrieved or deleted soon after archiving. Lifecycle management rules should follow proven age and access patterns instead of a universal schedule copied from another team.
Select replication for the failure that must be survived
Locally redundant, zone-redundant, and geographically redundant storage options protect different failure classes and have different availability and access semantics. Determine whether the business needs to survive one device fault, an Availability Zone impairment, or loss of an entire Region. Geo-redundancy does not necessarily make a secondary readable at all times, and customer-initiated failover capabilities depend on the chosen redundancy and service configuration.
The Azure disaster-recovery and paired-region design helps place object replication inside full application recovery. A second copy of an object is not enough if the recovery application cannot resolve its endpoint, use its encryption keys, or find matching database records. Also remember that replication can carry an accidental deletion or corrupted value to the secondary; versioning and backups address different risks.
Separate durability, soft delete, versioning, and immutability
Versioning can preserve prior object states after overwrites, while soft delete can assist with accidental removal under a configured retention policy. Immutable storage and legal hold features address records that must resist unauthorized modification or deletion. They may conflict with ordinary lifecycle cleanup if rules are designed independently. Set retention from data classification, legal policy, and incident requirements instead of enabling every feature by default.
Run a deliberately destructive test in a nonproduction container: overwrite an object, delete it, then attempt recovery using the supported protection configuration. Document which recovery mechanism produced the original bytes and how long that took. A platform SLA and a storage redundancy setting do not establish that an application can recover from a user’s mistaken delete.
Keep analytics and operational paths distinct
Analytics workloads often benefit from partitioned object layouts, efficient columnar files, and data catalog metadata. A data lake containing unsorted tiny JSON files can create many requests and expensive query overhead. Decide which files are raw immutable input, which are curated transformations, and which are disposable intermediate outputs. Establish schema validation, ownership, and lifecycle per zone of the lake so mistakes do not propagate silently.
The Azure landing-zone governance model applies to data too: subscriptions, workload identities, storage policy, centralized logs, and approved private connectivity need common controls with accountable owners. A shared analytical lake should not become a backdoor that bypasses the application’s customer authorization because it uses a different storage API.
Test performance with real data sizes and access patterns
Use a representative distribution of file sizes, concurrency, request methods, and regions. Measure client throughput, service throttling, latency, and transfer charges. For an analytics pipeline, compare ingestion and query time after organizing files differently; for a customer API, test secure downloads of both small and large objects during a scale event. Include storage account limits and the effect of multiple applications sharing one account.
Fail one dependency deliberately: deny an approved identity, misconfigure private DNS, restore a previous object version, and rehearse the regional access path. AZ-305 storage architecture succeeds when the data interface, access policy, durability, restore time, and cost all satisfy the same documented business requirement. Storage is an application contract, not simply a container for bytes.