What happens when you upload a file to the cloud

You drag a PDF onto the Google Drive icon. Within seconds, it vanishes from your Desktop and reappears in the browser tab showing your cloud folder. The user-facing experience is magical: a file moved from here to there. The actual journey is considerably less magical and has at least a dozen distinct steps, each of which shapes what “safe in the cloud” actually means.

Understanding those steps is not a matter of trivia. It’s what lets you make sense of “encrypted in transit”, “encrypted at rest”, and every other phrase on a cloud provider’s security page. Without the pipeline in your head, those phrases are just adjectives.

Step 1: your device reads the file

Before anything leaves your computer, the cloud client (the Google Drive app, the browser upload widget, the iCloud sync daemon) reads the file from disk. On a laptop with full-disk encryption, the file is decrypted into memory at this point — full-disk encryption protects against a stolen powered-off laptop, not against software running on an unlocked one.

The client then:

• Computes a checksum (typically SHA-256) to confirm integrity later.
• Optionally splits large files into chunks for parallel upload.
• Optionally compresses the data.

If you have a client-side encryption layer like Cryptomator, this is also where the plaintext gets encrypted with your key. After that point, nothing downstream sees plaintext. Without that layer, plaintext travels all the way to the provider (wrapped in TLS, but plaintext as far as the provider is concerned).

Step 2: the TLS tunnel

The client opens an HTTPS connection to the provider. TLS 1.2 or 1.3 wraps the upload in a cryptographic tunnel:

• Confidentiality — nobody on the network path can read the content.
• Integrity — nobody can modify it mid-flight without detection.
• Authentication — your client verifies it’s talking to the real Google / Apple / Microsoft / Dropbox server via the provider’s TLS certificate.

This is what “encrypted in transit” refers to — the data in motion between your device and the provider.

What TLS doesn’t do:

• Hide that you’re uploading (destination, timing, size).
• Protect the data after it reaches the provider.
• Stop a compromised or misconfigured TLS setup at either end.

The encryption at rest vs in transit article unpacks this layer in depth.

Step 3: network hops

Your packets don’t go directly from your laptop to the provider’s servers. They traverse:

• Your local network (home router, Wi-Fi access point, Ethernet switch).
• Your ISP’s infrastructure.
• Transit providers that move traffic between ISPs.
• Usually, the provider’s CDN/edge network (Google Fronts, CloudFront, Fastly, Cloudflare) before reaching the actual data center.

Every hop sees TLS ciphertext. Every hop can see metadata — who you’re talking to, how much traffic, when. For most purposes this is fine; TLS protects the content. For threat models where the metadata matters (journalists, dissidents, certain regulated contexts), additional tools like Tor or a VPN hide which provider you’re even using.

Step 4: arriving at the provider’s edge

Your upload first lands at one of the provider’s edge servers — a server physically close to you, often in your country or region. The edge server:

• Terminates the TLS connection (your encrypted tunnel ends here; the data continues inside the provider’s own network).
• Authenticates your account (validates your OAuth token, session cookie, or API key).
• Runs basic abuse checks (rate limits, malware scanning if the provider does it).

Inside the provider’s network, the data may travel over encrypted backbone links between data centers. Major providers now encrypt their internal traffic by default; not all smaller providers do.

Step 5: storage-side encryption

The file is written to the provider’s storage system (Google’s Colossus, AWS S3, Microsoft Azure Storage, etc.), and encrypted at rest during the write. This is typically AES-256 with keys managed by the provider’s Key Management Service (KMS).

What this means in practice:

• The file on disk is ciphertext.
• The provider holds the key.
• When you (or anyone with access) requests the file, the provider decrypts it on-the-fly during retrieval.

This defends against physical theft of drives and against attackers who compromise parts of the infrastructure without reaching the KMS. It does not defend against:

• The provider itself reading your file (they have the key).
• A subpoena served on the provider.
• A KMS compromise at the provider.

For the subset of your documents where “the provider could hand over plaintext” is unacceptable, client-side encryption closes that gap.

Step 6: replication across data centers

Modern cloud providers don’t keep your file in one place. For durability, they replicate it:

• Within a data center: multiple disks, multiple racks.
• Across data centers in a region: typically 3+ availability zones.
• Optionally across regions: for disaster recovery and geographic availability.

The promise from providers like S3 is “eleven 9s of durability” — 99.999999999% — achieved by making so many copies that simultaneous loss of all of them is statistically negligible.

This is good for availability. It also means your file now exists in many more physical places than you think. Encryption-at-rest applies to each copy, so that isn’t a confidentiality concern; but if you’re thinking about how “delete” works (and this site has articles about that), the replication story matters.

Step 7: indexing, thumbnails, previews

Depending on the service, the provider does more than just store the bytes:

• Search indexing: text is extracted from documents (OCR on scanned PDFs, field-by-field from Office files) and added to an index so you can search by content.
• Thumbnail generation: image and document previews are rendered and cached.
• Metadata extraction: EXIF from photos, page count from PDFs, duration from videos.
• Malware scanning: for shared files.
• Content policies: hash-based matching against known-illegal content (CSAM), known-copyrighted content, etc.

All of these require the provider to be able to read your file — which reminds us that “encrypted at rest” is a statement about disks, not about the provider’s access. If you encrypted client-side before upload, most of these features don’t work, because the provider sees opaque ciphertext. That’s the tradeoff.

Step 8: the version and access log

Every modern cloud storage service keeps:

• Version history of your file, so you can roll back edits.
• Access logs of who viewed or modified it.
• Retention policies that control how long trash and old versions live.

These live in the provider’s databases, separate from the storage itself. When you “delete” a file, you’re usually creating a new version marked as deleted — the bytes hang around for days to weeks before physical deletion.

What to do with this understanding

• Trust claims in context. When a provider says “encrypted in transit and at rest”, you now know they mean TLS on the wire (step 2) and AES-at-rest in storage (step 5). That’s the floor.
• Ask about step 1. Does the service offer client-side encryption, so that plaintext never leaves your device in the first place?
• Ask about step 7. What does the provider read? What can’t they read? For sensitive data, the less they can read, the better — at the cost of search and previews.
• Ask about step 6. How many copies? Where? Does the provider offer regional data residency?
• Ask about step 8. Are access logs kept? For how long? Can you see them?

The companion article, How to read a cloud provider’s security page like a skeptic, maps those questions onto what providers actually publish.

An upload is a sequence, not an event. Every point along the sequence has a decision attached; understanding the sequence turns cloud security from vibes into something you can reason about.