Embedding base64 building photos in DynamoDB items approaches size limits and slows reads. What should developers do?
Select an answer to reveal the explanation.
Short Explanation
Photos aren’t attributes—they’re objects. Put the image in S3 and leave a skinny pointer in DynamoDB so reads stay fast and under the size cap.
Full Explanation
Building photos embedded as base64 inside DynamoDB items inflate attribute size, approach the 400 KB item limit, and slow every case read that only needed status or address metadata. Store the photos in Amazon S3 and keep object references plus small metadata attributes on the DynamoDB item so inspectors still locate a case quickly while image bytes live in object storage designed for large media. The application loads thumbnails or full images on demand via the object key or a pre-signed URL rather than paying item-size and RCU costs on every metadata GetItem.
There is no “DynamoDB large-item mode” that safely lifts items past 400 KB for this pattern—the distractor invents a feature; respect the published item size limit. Compressing photos into sort key names is not a storage strategy, corrupts key design, and cannot hold binary image payloads. Emailing photos to a shared inbox abandons durable, permissioned AWS storage and creates an unworkable retrieval and retention model for a municipal inspection system of record.
Exam caveat: pair S3 object keys with optional CloudFront or pre-signed URLs for download; never treat DynamoDB as a general-purpose blob store for civic media. Operational check: migrate a representative photo out of an item into S3, shrink the DynamoDB item well below the size limit, and verify GetItem latency and payload size improve while the photo still opens correctly from the stored object key.