A permitting database EC2 host needs a simple, cost-effective boot disk plus a separately tuned data disk. What volume layout should the architect use?
Select an answer to reveal the explanation.
Short Explanation
Boot on sensible gp3, data on its own tuned volume—like keeping the engine oil separate from the cargo hold. You size and IOPS-tune the data disk without overpaying for the OS disk. One cold mush volume fights both jobs.
Full Explanation
A permitting database EC2 host that needs a simple, cost-effective boot disk plus a separately tuned data disk should use gp3 for the boot volume and attach a separate data volume sized and IOPS-tuned for the application. Splitting OS and data lets the county keep the boot volume modest while provisioning performance where the database actually needs it, which is standard resilient and economical EBS layout practice.
Placing OS and database files on one cold HDD volume to maximize density fails performance for a permitting database and mixes dissimilar I/O on the wrong medium. Using only instance store for both boot and data and snapshotting hourly fails durability on stop/hibernate and is a poor primary store for permitting records. Attaching twenty tiny gp2 boot volumes and striping the operating system across them fails as needless complexity and is not the simple cost-effective boot-plus-data pattern the question seeks.
Exam caveat: the data volume type (gp3, io2, etc.) should follow measured database IOPS; the key architectural point is separation of boot and data with gp3 as a sensible boot default. Operational check: create gp3 root, attach a dedicated data volume for database files, tune IOPS/throughput on the data volume, and include both volumes in backup and restore runbooks.