45 TB in Six Weeks: Data Movement, Tiering, and Access in One Design
Northwind Productions holds 45 TB of video masters on an on-premises NAS. Everything must be in Azure within six weeks. The dedicated uplink is 60 Mbps and is shared with business traffic. After migration, about 300 GB of new footage arrives each day. Of the existing 45 TB, 32 TB is footage older than two years that is rarely touched but must be retrievable within 24 hours; the remaining 13 TB is actively edited every week. Editors in three offices need drive-letter access to the active footage using their existing Active Directory accounts. A separate rendering application reads all footage through REST APIs and today authenticates with a storage account key that a contractor rotates manually; the last rotation left the application offline for four hours.
1. Show whether the WAN link can carry the backfill and the steady-state increment, and select the migration mechanism.
Read the worked answer
Backfill math. 45 TB is 45 x 8 = 360 terabits, i.e. 360,000 gigabits. At 60 Mbps (0.06 Gbps) and ignoring overhead, that is 360,000 / 0.06 = 6,000,000 seconds, or about 69 days of a completely saturated link. The window is 42 days, and the link is shared. The network path is not viable.
Verdict: use Azure Data Box for the 45 TB backfill. A single appliance offers roughly 80 TB of usable capacity, so one device covers it with headroom; order early because shipping and ingest time are part of the six weeks. Note that Data Box handles a one-time seed only.
Steady state math. 300 GB/day is 2,400 gigabits per day, or 2,400 / 86,400 = 0.028 Gbps, about 28 Mbps sustained if spread evenly across 24 hours. It fits inside 60 Mbps, but it consumes nearly half the link and will collide with business traffic during working hours. Options: schedule transfers into an overnight window, apply bandwidth throttling, or justify a link upgrade or ExpressRoute as part of the post-migration operating model. The chosen mechanism must be automated, since this is now a daily production pipeline rather than a project.
2. Recommend the storage layout and tiering plan. What does your archive decision mean for the editors who need drive-letter access?
Read the worked answer
Three distinct stores, because the workloads have three distinct access patterns.
- Active 13 TB: Azure Files (standard, hot) with Entra Kerberos or AD DS authentication, which is what preserves drive-letter SMB access for the three offices with existing AD identities. Add Azure File Sync on a server in each office for local caching so editors are not pulling 4K masters over the WAN. Directory-level line-of-sight to a domain controller matters for AD DS auth; Entra Kerberos avoids that dependency for hybrid identities.
- Archive 32 TB: Blob storage, Archive tier. Cheapest per GB, and the 24-hour retrieval requirement is achievable through rehydration: standard priority can take up to 15 hours, high priority is typically under an hour for blobs under 10 GB, and large masters take longer. Build a restore workflow rather than assuming instant access.
- API access: Blob containers over REST for the rendering application.
The trap: Azure Files has no archive tier. Archived footage cannot live on the SMB share. The editors' restore path must therefore be an explicit workflow: rehydrate the blob to Hot, then copy it into the Azure Files share, then notify the editor. If editors genuinely expect to browse the archive interactively, the archive tier is the wrong choice and the 24-hour requirement needs to be renegotiated as a restore SLA, not a browse SLA.
3. Remove the key-based authentication dependency without breaking the rendering application. What are the limits of your fix?
Read the worked answer
Fix
- Give the rendering application a system-assigned managed identity (or a user-assigned one if it runs across several resources).
- Grant that identity Storage Blob Data Reader at the container or account scope through Azure RBAC. Data-plane roles are separate from management-plane roles; Contributor alone will not read blobs.
- Set AllowSharedKeyAccess = false on the storage account so no key-based path remains, and remove the key from App Service application settings.
- Put the storage account behind a private endpoint and confirm the application's VNet integration can reach it.
- Alert on authorization failures so the next change surfaces in minutes, not hours.
Limits to state explicitly
- Managed identity only works for workloads running in Azure with a supported host. If the same code also runs on-premises or in another cloud, that instance needs a federated workload identity credential or a certificate, not a shared key.
- Disabling shared key breaks anything else still using it, including some tools, scripts, and legacy SDKs. Inventory first, then flip the switch.
- The four-hour outage was a process failure as much as a technical one: removing the secret removes the rotation event, but the deployment pipeline still needs a rollback plan.