A city permitting database on Amazon Aurora PostgreSQL sees sudden IOPS spikes when inspectors sync field photos and plan reviews after lunch. Storage grows unpredictably as new permit years open. Which design best meets the spiky I/O and growing footprint without constant manual resize tickets?
Select an answer to reveal the explanation.
Short Explanation
Think of Aurora’s storage like a municipal warehouse that adds floor space as boxes arrive—you do not call a contractor every Friday to pour more concrete. Size the IOPS/performance path for the after-lunch surge, and let storage grow with the permit archive.
Full Explanation
Amazon Aurora’s storage layer automatically grows in increments as the municipal permitting database accumulates new years of applications, plan reviews, and inspector photo metadata, so the city avoids a standing ticket queue to enlarge fixed gp2 volumes whenever a new fiscal year opens. That growth model directly answers the unpredictable footprint problem: storage expands with data rather than requiring operators to forecast and manually resize disks ahead of every surge in filed permits. For the after-lunch IOPS spikes—when field inspectors sync photos and plan packages—the architect still provisions or tunes Aurora performance characteristics (for example, Aurora I/O-Optimized or appropriate instance and buffer settings) so the permit desk’s service-level objectives hold without waiting on volume growth operations. Conceptually, Aurora separates durable, auto-growing cluster storage from the compute that serves queries, which matches civic systems whose data estate expands year over year while traffic remains bursty.
Keeping a fixed gp2 volume under classic RDS fails the growth requirement: operators must still issue resize or migration work when storage or baseline IOPS ceilings are hit, and weekly vertical instance upgrades treat CPU as a substitute for storage elasticity. Moving permit blobs into ElastiCache Redis confuses cache with system of record; Redis is volatile memory for hot scratchpad data, not a substitute for Aurora’s durable relational store, and it does not eliminate the need for a database that survives restarts and audits. Replacing Aurora with a single EC2 instance store volume trades managed durability and Multi-AZ design for local-disk speed that disappears when the instance stops, which is unacceptable for a city permitting system of record.
Exam caveat: auto-growing storage does not mean “ignore performance sizing.” Spiky IOPS still need an explicit performance path; Aurora’s automatic growth addresses capacity floor space, not every latency SLO by itself. Also distinguish Aurora storage growth from RDS gp2/gp3 volume behaviors—answers that only resize instances miss the storage model the question targets.
Operational check: after cutover, confirm Aurora storage is increasing with permit-year growth without manual volume tickets; load-test an after-lunch inspector sync window and verify IOPS/latency stay within the permit desk SLO; ensure backups and Multi-AZ (or Aurora replicas) remain configured so civic continuity is not traded away for elasticity.