AWS Builder Center
Encrypting a Volume with VeraCrypt: What "Encrypted" Actually Means for a Folder

Encrypting a Volume with VeraCrypt: What "Encrypted" Actually Means for a Folder

This lab walked through building exactly that kind of container using VeraCrypt, then proved the concept by actually storing a file inside it and watching the whole thing vanish on dismount.

There's a meaningful difference between encrypting a file and encrypting a volume, and it's not just a matter of scale. A single encrypted file still reveals its own existence, its name, its size, roughly when it was last touched. An encrypted volume, done properly, hides all of that. The container itself looks like undifferentiated noise from the outside, and everything inside it, file names, folder structure, free space, metadata, disappears into that same noise until the correct password unlocks it. This lab walked through building exactly that kind of container using VeraCrypt, then proved the concept by actually storing a file inside it and watching the whole thing vanish on dismount.

What Full Disk Encryption Is Actually Protecting

Full disk encryption converts essentially everything on a disk or volume into unreadable ciphertext, encrypting data as it's written and decrypting it transparently as it's read, with the process invisible to whatever application is actually using the files. The lab's definition was precise on one point worth repeating: full disk encryption covers everything except the master boot record (MBR), the small amount of information needed to even begin the boot process. Beyond that exception, the entire filesystem, not just file contents but file names, folder names, free space, and metadata, becomes part of the encrypted whole.
That last detail is what actually distinguishes volume-level encryption from simply encrypting individual files one at a time. Encrypting a file with a password protects its contents, but the file still exists as a visible object on the filesystem: its name, size, and timestamps are all still readable without ever opening it. A properly encrypted volume denies an attacker even that much. Until the volume is mounted with the correct credentials, there's no file list to browse, no names to read, nothing to even confirm what's inside, or that anything meaningful is inside at all.

Building the Container

I used VeraCrypt, a widely used open-source disk encryption tool, to create an encrypted volume as a file-based container rather than encrypting an entire physical disk directly. The Volume Creation Wizard walked through several deliberate choices, each one worth understanding rather than just clicking through:
Container type: encrypted file container. Rather than encrypting an entire partition or physical drive, this creates a single file that, once formatted, functions as a self-contained encrypted filesystem. That file can be moved, backed up, or deleted exactly like any other file, while still behaving like a mounted disk once properly opened.
Volume size: 5 MB. Small for this lab's demonstration purposes, but the same mechanism scales to volumes of any practical size; the encryption principle doesn't change with container size.
Password: a dedicated password specific to this volume, separate from any system login credential. This is worth emphasizing on its own: a volume's password is the single point of failure (and the single point of protection) for everything inside it. There's no recovery path that bypasses it, which is precisely the point, but it also means the password has to be both strong and something you won't lose access to.
Filesystem: FAT, default cluster size. A deliberately simple, broadly compatible filesystem choice appropriate for a small demonstration container.
One step in the wizard is easy to dismiss as filler but is actually doing real cryptographic work: before formatting, VeraCrypt asks you to move the mouse randomly within the wizard window for at least 30 seconds, while a Random Pool, Header Key, and Master Key are being generated. That mouse movement is a genuine entropy source, true randomness is hard for a deterministic computer to generate on its own, and human mouse movement is one practical way to inject real unpredictability into the random number generation that the encryption keys are actually built from. Skipping that step, or barely moving the mouse, would mean weaker, more predictable keys underneath otherwise correctly-configured encryption.
After formatting, VeraCrypt produced the actual container file,  My Volume , sitting on the desktop like any other file, giving no outward indication that it was anything other than an ordinary, meaningless blob of data.

Mounting the Volume and Proving the Concept

With the container built, I returned to VeraCrypt's main window, selected an available drive letter ( I: ), pointed it at the  My Volume  file, and clicked Mount. Supplying the correct password unlocked it, and Windows immediately presented drive  I:  as a normal, browsable disk, indistinguishable in behavior from any other mounted drive, just backed by encrypted storage rather than a physical disk.
To actually demonstrate the point rather than just trust the theory, I created a simple text file, wrote some content into it, and then copied that file directly into the mounted  I:  drive. From the user's perspective, nothing about that copy operation looked any different from copying a file to any other folder. That's intentional, and it's actually the whole value proposition: encryption that requires special handling or awkward workflows to use correctly gets worked around or abandoned. Encryption that behaves exactly like a normal drive gets used consistently, because it doesn't ask anything extra of the person using it.
Then came the step that actually proves the security model: I switched back to VeraCrypt and clicked Dismount. The  I:  drive disappeared entirely from "This PC", not just locked, not showing an access-denied error, but gone, as if it had never existed. The only thing left behind on the desktop was the original  My Volume  file, back to looking like an unremarkable, unreadable blob with no visible indication of the file, folder structure, or content it actually contained.

Why This Specific Behavior Is the Point

The lab's own framing captured the actual threat model this defends against directly: if an attacker gains remote access, or even complete physical access, to a compromised machine, they still can't locate the encrypted volume's contents, its file names, its folder structure, any of it, without the correct password. That's a meaningfully stronger property than "the attacker can see there's a protected file here, but can't open it." In this model, the attacker often can't even confirm that sensitive data exists on the system at all, since the container file itself is indistinguishable from random data without the key to interpret it.
A few things stood out about why this matters beyond the specific lab exercise.
Hiding metadata is a genuinely different security property than hiding content. A locked file still announces its own existence: a filename like  financial_records_2026.xlsx.encrypted  tells an attacker exactly what they're looking at and what it's probably worth their time to attack, even before they can open it. A dismounted VeraCrypt volume reveals none of that. The attacker sees one file with no name indicating its purpose and no way to tell what, if anything, is actually stored inside.
Password strength does all the real work, same as with WPA2. This connects directly to lessons from the wireless security labs earlier in the same broader set of training: the cryptography underneath VeraCrypt is sound. What actually determines whether the volume survives an attacker trying to crack it offline is the strength of the password chosen when the container was created. A weak or short password undermines everything else done correctly in the setup.
Entropy matters at the moment of key generation, not just password strength. The deliberate mouse-movement step is a reminder that strong encryption depends on genuinely random keys underneath, not just a strong password layered on top of weak randomness. Both pieces have to be solid for the whole system to hold.
Usability is what makes encryption actually get used. A mounted VeraCrypt volume behaves exactly like a normal drive letter. Files copy into it the same way they'd copy anywhere else. That design choice isn't incidental, it's what makes the difference between encryption people actually adopt into their daily workflow and encryption that gets skipped because it's inconvenient.
This lab was a clean, hands-on demonstration of something that's easy to state abstractly but more convincing once actually watched happen: an encrypted volume isn't just a locked file, it's a container that can make its own existence functionally invisible once dismounted. Mounted, it behaves exactly like any other disk. Dismounted, there's nothing left to even investigate, just an unremarkable file with no name, structure, or metadata hinting at what it protects.
That's the real value of volume-level encryption over simply encrypting individual files one at a time: it doesn't just protect the data, it removes the data's visibility as a target in the first place.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article