DynamoDB LSI vs GSI: SAA-C03 Indexing Guide

A Local Secondary Index (LSI) shares the same partition key as the base table but uses a different sort key, supporting strong consistency. A Global Secondary Index (GSI) allows a completely different partition and sort key, enabling flexible queries across the entire table with eventual consistency.

What is a Local Secondary Index (LSI) and when should you use it?

Think of an LSI as a way to reorganize your data within a single partition. It uses the same partition key as your base table but allows you to define a different sort key. This is a lifesaver when you need to perform multiple different queries on the same set of items. However, there's a catch: you must create LSIs when you first create the table. You can't just add one later on a whim.

From an architectural standpoint, LSIs are powerful because they support strongly consistent reads. If your application cannot tolerate stale data, an LSI is your go-to. Just keep in mind the 10GB limit per partition key value. If your data grows beyond that, DynamoDB will throw a write error, making LSIs a risky choice for rapidly scaling datasets.

How does a Global Secondary Index (GSI) differ from an LSI?

GSIs are the 'wild west' of DynamoDB indexing—they give you total freedom. Unlike LSIs, a GSI can have a completely different partition key and sort key from the base table. This means you can query across all partitions, effectively turning a non-key attribute into a searchable primary key. The best part? You can create or delete GSIs at any time without rebuilding your table.

While GSIs offer incredible flexibility, they come with a trade-off: they only support eventual consistency. When you write to the base table, the GSI is updated asynchronously. For the SAA-C03 exam, remember that GSIs are the primary tool for solving 'cross-partition' query requirements. If the scenario asks for a way to find users by email when the partition key is UserID, a GSI is the only correct answer.

How do LSIs and GSIs impact your RCUs and WCUs?

Indexing isn't free; it costs you in terms of throughput. An LSI shares the provisioned read and write capacity (RCUs and WCUs) of the base table. This makes them simpler to manage but can lead to contention if your index queries are heavy. You're essentially fighting for the same resources as your main table operations.

GSIs, on the other hand, have their own dedicated provisioned throughput. This is a double-edged sword. While it prevents GSI queries from slowing down your base table, it means you're paying for additional RCUs and WCUs. Be careful with 'write amplification'—every time you update an item in the base table, DynamoDB must also update every GSI where that item appears. If you have five GSIs, one write to the base table could potentially trigger six write operations, quickly eating through your budget.

Which consistency model should you choose for your index?

Consistency is a frequent flashpoint on the SAA-C03 exam. With LSIs, you have the luxury of choice: you can perform eventually consistent reads or strongly consistent reads. This is critical for financial transactions or inventory systems where seeing the most recent update is non-negotiable.

GSIs are strictly eventually consistent. There is a slight lag between the write to the base table and the update appearing in the GSI. In most real-world scenarios, this millisecond delay is negligible, but for the exam, it's a key differentiator. If a question mentions 'strong consistency' and 'indexing' in the same breath, your brain should immediately pivot toward LSIs or querying the base table directly using the primary key.

How do you decide between LSI and GSI for a real-world scenario?

When you're staring at a scenario on the exam, ask yourself two questions: 'Do I need strong consistency?' and 'Is my data per partition under 10GB?' If the answer to both is yes, an LSI is a viable candidate. However, in 90% of modern AWS architectures, GSIs are the preferred choice because they don't impose the restrictive 10GB partition limit and offer far more query flexibility.

Consider a scenario where you have an 'Orders' table partitioned by CustomerID. If you need to find all orders placed on a specific date regardless of the customer, an LSI won't help because it's locked to the CustomerID. You need a GSI with 'OrderDate' as the partition key. Mastering this distinction is the difference between a passing score and a struggle.

How can practice exams help you master DynamoDB indexing?

Understanding the theory of DynamoDB is one thing, but applying it to tricky, multi-choice scenarios is where most students stumble. The SAA-C03 exam loves to throw 'distractor' answers at you that look correct but fail on a technicality—like suggesting an LSI for a cross-partition query. This is why high-quality practice is non-negotiable.

At Cert Sensei, we provide 1,000 expert-curated AWS Solutions Architect Associate practice questions designed to mimic the actual exam's complexity. We don't just tell you that 'B' is the right answer; we provide detailed expert reasoning so you understand the 'why' behind the indexing choice. Plus, our domain-level analytics show you exactly where you're weak—whether it's DynamoDB indexing or VPC peering—so you can stop wasting time on what you already know and focus on the gaps.

❓ Frequently Asked Questions