A county fraud team needs to explore how vendors, subcontractors, purchase orders, and shared addresses connect across years of procurement data. Lookups are relationship-heavy, not simple primary-key gets. Which AWS database service fits this graph-style investigation?
Select an answer to reveal the explanation.
Short Explanation
Fraud rings look like spider webs—who paid whom, who shares an address, which shell company links two bids. Neptune is built for that web. A plain key get or a glacier of CSVs will not walk those edges cleanly.
Full Explanation
County fraud investigations often ask relationship questions: which vendors share subcontractors, which purchase orders connect through shell entities, and which addresses appear across supposedly independent bids. Those are graph traversals—multi-hop walks over edges—not simple primary-key retrievals. Amazon Neptune is a managed graph database designed for that model: you store entities as nodes and relationships as edges, then query with Gremlin or openCypher (or SPARQL for RDF) to explore procurement networks across years. For a fraud team hunting connected parties in municipal purchasing data, Neptune matches the relationship-heavy investigative pattern far better than a flat key-value store or cold file archive.
Amazon DynamoDB with only GetItem on a vendor ID partition key retrieves one item efficiently but does not naturally walk multi-hop vendor–subcontractor–address graphs without heavy application-side stitching and multiple round trips that reinvent a graph engine. ElastiCache Memcached as the system of record for procurement edges is wrong on two axes: Memcached is a volatile cache without rich graph query semantics, and it must not be the durable ledger for audit-sensitive procurement links. S3 Glacier Deep Archive with manual CSV downloads may retain historical dumps cheaply, but it is an archival retrieval path, not an interactive graph investigation platform for analysts following edges in near real time.
Exam caveat: graph fit is about query shape (relationships and hops), not about “big data” alone. Neptune is not required for every analytics problem—if the work is columnar aggregations, Redshift or Athena may fit better. Here the stem emphasizes relationship-heavy lookups, which is the graph signal.
Operational check: model a sample fraud subgraph (vendor, subcontractor, PO, address), run multi-hop queries that would be painful as repeated GetItem calls, confirm Neptune query latency meets investigator workflow needs, and keep an immutable export or audit trail so court-admissible evidence is not solely dependent on a mutable live graph.