Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. Amazon DynamoDB enables customers to offload the administrative burdens of operating and scaling distributed databases to AWS, so they don’t have to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling.
Amazon DynamoDB takes away one of the main stumbling blocks of scaling databases, the management of the database software and the provisioning of hardware needed to run it. Customers can deploy a non-relational database in a matter of minutes. DynamoDB automatically partitions and re-partitions your data and provisions additional server capacity as your table size grows or you increase your provisioned throughput. In addition, Amazon DynamoDB synchronously replicates data across three facilities in an AWS Region, giving you high availability and data durability.
Q: What does read consistency mean? Why should I care?
Amazon DynamoDB stores three geographically distributed replicas of each table to enable high availability and data durability. Read consistency represents the manner and timing in which the successful write or update of a data item is reflected in a subsequent read operation of that same item. Amazon DynamoDB exposes logic that enables you to specify the consistency characteristics you desire for each read request within your application.
Q: What is the consistency model of Amazon DynamoDB?
When reading data from Amazon DynamoDB, users can specify whether they want the read to be eventually consistent or strongly consistent:
Eventually Consistent Reads (Default) – the eventual consistency option maximizes your read throughput. However, an eventually consistent read might not reflect the results of a recently completed write. Consistency across all copies of data is usually reached within a second. Repeating a read after a short time should return the updated data.
Strongly Consistent Reads — in addition to eventual consistency, Amazon DynamoDB also gives you the flexibility and control to request a strongly consistent read if your application, or an element of your application, requires it. A strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.
Q: Does DynamoDB support in-place atomic updates?
Amazon DynamoDB supports fast in-place updates. You can increment or decrement a numeric attribute in a row using a single API call. Similarly, you can add or remove to a set of strings atomically as well. View our documentation for more information on atomic updates.
Q: Why is Amazon DynamoDB built on Solid State Drives?
Amazon DynamoDB runs exclusively on Solid State Drives (SSDs). SSDs help us achieve our design goals of predictable low-latency response times for storing and accessing data at any scale. The high I/O performance of SSDs also enables us to serve high-scale request workloads cost efficiently, and to pass this efficiency along in low request pricing.
Q: DynamoDB’s storage cost seems high. Is this a cost-effective service for my use case?
As with any product, we encourage potential customers of Amazon DynamoDB to consider the total cost of a solution, not just a single pricing dimension. The total cost of servicing a database workload is a function of the request traffic requirements and the amount of data stored. Most database workloads are characterized by a requirement for high I/O (high reads/sec and writes/sec) per GB stored. Amazon DynamoDB is built on SSD drives, which raises the cost per GB stored, relative to spinning media, but it also allows us to offer very low request costs. Based on what we see in typical database workloads, we believe that the total bill for using the SSD-based DynamoDB service will usually be lower than the cost of using a typical spinning media-based relational or non-relational database. If you have a use case that involves storing a large amount of data that you rarely access, then DynamoDB may not be right for you. We recommend that you use S3 for such use cases.
It should also be noted that the storage cost reflects the cost of storing multiple copies of each data item across multiple facilities within an AWS Region.
Q: Is DynamoDB only for high-scale applications?
No. DynamoDB offers seamless scaling so you can start small and scale up and down in line with your requirements. If you need fast, predictable performance at any scale then DynamoDB may be the right choice for you.
Click “Sign Up” to get started with Amazon DynamoDB today. From there, you can begin interacting with Amazon DynamoDB using either the AWS Management Console or Amazon DynamoDB APIs. If you are using the AWS Management Console, you can create a table with Amazon DynamoDB and begin exploring with just a few clicks.
Q: What kind of query functionality does DynamoDB support?
Amazon DynamoDB supports key-value GET/PUT operations using a user-defined primary key. The primary key is the only required attribute for items in a table and it uniquely identifies each item. You specify the primary key when you create a table.
A primary key can either be a single-attribute hash key or a composite hash-range key. A single attribute hash primary key could be, for example, “UserID”. This would allow you to quickly read and write data for an item associated with a given user ID.
A composite hash-range key is indexed as a hash key element and a range key element. This multi-part key maintains a hierarchy between the first and second element values. For example, a composite hash-range key could be a combination of “UserID” (hash) and “Timestamp” (range). Holding the hash key element constant, you can search across the range key element to retrieve items. This would allow you to use the Query API to, for example, retrieve all items for a single UserID across a range of timestamps.
Q: How do I update and query data items with Amazon DynamoDB?
After you have created a table using the AWS Management Console or CreateTable API, you can use the PutItem or BatchWriteItem APIs to insert items. Then you can use the GetItem, BatchGetItem, or, if composite primary keys are enabled and in use in your table, the Query API to retrieve the item(s) you added to the table.
Q: Does Amazon DynamoDB support conditional operations?
Yes, you can specify a condition that must be satisfied for a PUT, update, or delete operation on an item to be completed. For example, you could choose to update an item only if it has a certain value. You could also choose to PUT an item into the table only if no record exists for the primary key you have specified. Conditional operations allow users to implement optimistic concurrency control systems on DynamoDB. For more information on conditional operations, please see our documentation.
Q: Does Amazon DynamoDB support increment or decrement operations?
Yes, Amazon DynamoDB allows atomic increment and decrement operations on scalar values.
Q: When should I use Amazon DynamoDB vs a relational database engine on Amazon RDS or Amazon EC2?
Today’s web-based applications generate and consume massive amounts of data. For example, an online game might start out with only a few thousand users and a light database workload consisting of 10 writes per second and 50 reads per second. However, if the game becomes successful, it may rapidly grow to millions of users and generate tens (or even hundreds) of thousands of writes and reads per second. It may also create terabytes or more of data per day. Developing your applications against Amazon DynamoDB enables you to start small and simply dial-up your request capacity for a table as your requirements scale, without incurring downtime. You pay highly cost-efficient rates for the request capacity you provision, and let Amazon DynamoDB do the work over partitioning your data and traffic over sufficient server capacity to meet your needs. Amazon DynamoDB does the database management and administration, and you simply store and request your data. Automatic replication and failover provides built-in fault tolerance, high availability, and data durability. Amazon DynamoDB gives you the peace of mind that your database is fully managed and can grow with your application requirements.
While Amazon DynamoDB tackles the core problems of database scalability, management, performance, and reliability, it does not have all the functionality of a relational database. It does not support complex relational queries (e.g. joins) or complex transactions. If your workload requires this functionality, or you are looking for compatibility with an existing relational engine, you may wish to run a relational engine on Amazon RDS or Amazon EC2. While relational database engines provide robust features and functionality, scaling a workload beyond a single relational database instance is highly complex and requires significant time and expertise. As such, if you anticipate scaling requirements for your new application and do not need relational features, Amazon DynamoDB may be the best choice for you.
Q: How does Amazon DynamoDB differ from Amazon SimpleDB?
Which should I use?Both services are non-relational databases that remove the work of database administration. Amazon DynamoDB focuses on providing seamless scalability and fast, predictable performance. It runs on solid state disks (SSDs) for low-latency response times, and there are no limits on the request capacity or storage size for a given table. This is because Amazon DynamoDB automatically partitions your data and workload over a sufficient number of servers to meet the scale requirements you provide. In contrast, a table in Amazon SimpleDB has a strict storage limitation of 10 GB and is limited in the request capacity it can achieve (typically under 25 writes/second); it is up to you to manage the partitioning and re-partitioning of your data over additional SimpleDB tables if you need additional scale. While SimpleDB has scaling limitations, it may be a good fit for smaller workloads that require query flexibility. Amazon SimpleDB automatically indexes all item attributes and thus supports query flexibility at the cost of performance and scale.
Amazon CTO Werner Vogels' DynamoDB blog post provides additional context on the evolution of non-relational database technology at Amazon.
Q: When should I use Amazon DynamoDB vs Amazon S3?
Amazon DynamoDB stores structured data, indexed by primary key, and allows low latency read and write access to items ranging from 1 byte up to 64KB. Amazon S3 stores unstructured blobs and suited for storing large objects up to 5 TB. In order to optimize your costs across AWS services, large objects or infrequently accessed data sets should be stored in Amazon S3, while smaller data elements or file pointers (possibly to Amazon S3 objects) are best saved in Amazon DynamoDB.
The data model for Amazon DynamoDB is as follows:
Table: A table is a collection of data items – just like a table in a relational database is a collection of rows. Each table can have an infinite number of data items. Amazon DynamoDB is schema-less, in that the data items in a table need not have the same attributes or even the same number of attributes. Each table must have a primary key. The primary key can be a single attribute key or a “composite” attribute key that combines two attributes. The attribute(s) you designate as a primary key must exist for every item as primary keys uniquely identify each item within the table.
Item: An Item is composed of a primary or composite key and a flexible number of attributes. There is no explicit limitation on the number of attributes associated with an individual item, but the aggregate size of an item, including all the attribute names and attribute values, is 64KB.
Attribute: Each attribute associated with a data item is composed of an attribute name (e.g. “Color”) and a value or set of values (e.g. “Red” or “Red, Yellow, Green”). Individual attributes have no explicit size limit, but the total value of an item (including all attribute names and values) cannot exceed 64KB.
Q: Is there a limit on the size of an item?
The total size of an item, including attribute names and attribute values, cannot exceed 64KB.
Q: Is there a limit on the number of attributes an item can have?
There is no limit to the number of attributes that an item can have. However, the total size of an item, including attribute names and attribute values, cannot exceed 64KB.
Q: What are the APIs?
- CreateTable – Creates a table and specifies the primary index used for data access.
- UpdateTable – Updates the provisioned throughput values for the given table.
- DeleteTable – Deletes a table.
- DescribeTable – Returns table size, status, and index information.
- ListTables – Returns a list of all tables associated with the current account and endpoint.
- PutItem – Creates a new item, or replaces an old item with a new item (including all the attributes). If an item already exists in the specified table with the same primary key, the new item completely replaces the existing item. You can also use conditional operators to replace an item only if its attribute values match certain conditions, or to insert a new item only if that item doesn’t already exist.
- BatchWriteItem – Inserts, replaces, and deletes multiple items across multiple tables in a single request, but not as a single transaction. Supports batches of up to 25 items to Put or Delete, with a maximum total request size of 1 MB.
- UpdateItem – Edits an existing item's attributes. You can also use conditional operators to perform an update only if the item’s attribute values match certain conditions.
- DeleteItem – Deletes a single item in a table by primary key. You can also use conditional operators to perform a delete an item only if the item’s attribute values match certain conditions.
- GetItem – The GetItem operation returns a set of Attributes for an item that matches the primary key. The GetItem operation provides an eventually consistent read by default. If eventually consistent reads are not acceptable for your application, use ConsistentRead.
- BatchGetItem – The BatchGetItem operation returns the attributes for multiple items from multiple tables using their primary keys. A single response has a size limit of 1 MB and returns a maximum of 100 items. Supports both strong and eventual consistency.
- Query – Gets one or more items using the table primary key, or from a secondary index using the secondary index key. You can narrow the scope of the query by using comparison operators on the range key value, or on the secondary index key. Supports both strong and eventual consistency. A single response has a size limit of 1 MB.
- Scan – Gets one or more items and attributes by performing a full scan across the table. The items returned may be limited by your specifying filters against one or more attributes. This API can thus be used to enable ad-hoc querying of a table against attributes which are not the table’s primary key. However, since it is a full table scan without an index, it should not be used for any application query use case that requires predictable performance. The result set of a scan API request will be eventually consistent. You can think of the Scan API as an iterator. Once the aggregate size of items scanned for a given Scan API request exceeds a 1 MB limit, the given request will terminate and fetched results will be returned along with a LastEvaluatedKey (to continue the scan in a subsequent operation).
Q: What data types does DynamoDB support?
Amazon DynamoDB supports three scalar data types: Number, String, and Binary. Additionally, Amazon DynamoDB supports multi-valued types: Number Set, String Set, and Binary Set.
No. You can store any amount of storage you can put into an Amazon DynamoDB table. As the size of your data set grows, Amazon DynamoDB will automatically spread your data over sufficient machine resources to meet your storage requirements.
Q: Is there a limit to how much throughput I can get out of a single table?
No, you can increase the throughput you have provisioned for your table using UpdateTable API or in the AWS Management Console. DynamoDB is able to operate at massive scale and there is no theoretical limit on the maximum throughput you can achieve. DynamoDB automatically divides your table across multiple partitions, where each partition is an independent parallel computation unit. DynamoDB can achieve increasingly high throughput rates by adding more partitions.
If you wish to exceed throughput rates of 10,000 writes/second or 10,000 reads/second, you must first contact Amazon through this online form.
Q: Does Amazon DynamoDB remain available when I ask it to scale up or down by changing the provisioned throughput?
Yes. Amazon DynamoDB is designed to scale its provisioned throughput up or down while still remaining available.
Q: Do I need to manage client-side partitioning on top of Amazon DynamoDB?
No. Amazon DynamoDB removes the need to partition across database tables for throughput scalability.
Q: How highly available is Amazon DynamoDB?
The service runs across Amazon’s proven, high-availability data centers. The service replicates data across three facilities in an AWS Region to provide fault tolerance in the event of a server failure or Availability Zone outage.
Q: How does Amazon DynamoDB achieve high uptime and durability?
To achieve high uptime and durability, Amazon DynamoDB synchronously replicates data across three facilities within an AWS Region.
Global secondary indexes are indexes that contain hash or hash-and-range keys that can be different from the keys in the table on which the index is based.
For efficient access to data in a table, Amazon DynamoDB creates and maintains indexes for the primary key attributes. This allows applications to quickly retrieve data by specifying primary key values. However, many applications might benefit from having one or more secondary (or alternate) keys available to allow efficient access to data with attributes other than the primary key. To address this, you can create one or more secondary indexes on a table, and issue Query requests against these indexes.
Amazon DynamoDB supports two types of secondary indexes:
- Local secondary index — an index that has the same hash key as the table, but a different range key. A local secondary index is "local" in the sense that every partition of a local secondary index is scoped to a table partition that has the same hash key.
- Global secondary index — an index with a hash or a hash-and-range key that can be different from those on the table. A global secondary index is considered "global" because queries on the index can span all items in a table, across all partitions.
Secondary indexes are automatically maintained by Amazon DynamoDB as sparse objects. Items will only appear in an index if they exist in the table on which the index is defined. This makes queries against an index very efficient, because the number of items in the index will often be significantly less than the number of items in the table.
Global secondary indexes support non-unique attributes, which increases query flexibility by enabling queries against any non-key attribute in the table.
Consider a gaming application that stores the information of its players in a DynamoDB table whose primary key consists of UserId (hash) and GameTitle (range). Items have attributes named TopScore, Timestamp, ZipCode, and others. Upon table creation, DynamoDB provides an implicit index (primary index) on the primary key that can support efficient queries that return a specific user’s top scores for all games.
However, if the application requires top scores of users for a particular game, using this primary index would be inefficient, and would require scanning through the entire table. Instead, a global secondary index with GameTitle as the hash key element and TopScore as the range key element would enable the application to rapidly retrieve top scores for a game.
A GSI does not need to have a range key element. For instance, you could have a GSI with a key that only has a hash element GameTitle. In the example below, the GSI has no projected attributes, so it will just return all items (identified by primary key) that have an attribute matching the GameTitle you are querying on.
Q: When should I use global secondary indexes?
Global secondary indexes are particularly useful for tracking relationships between attributes that have a lot of different values. For example, you could create a DynamoDB table with CustomerID as the primary hash key for the table and ZipCode as the hash key for a global secondary index, since there are a lot of zip codes and since you will probably have a lot of customers. Using the primary key, you could quickly get the record for any customer. Using the global secondary index, you could efficiently query for all customers that live in a given zip code.
To ensure that you get the most out of your global secondary index's capacity, please review our best practices documentation on uniform workloads.
Q: How do I create a global secondary index for a DynamoDB table?
All GSIs associated with a table must be specified at table creation time. At this time, it is not possible to add a GSI after the table has been created. For detailed steps on creating a Table and its indexes, see here. You can create a maximum of 5 global secondary indexes per table.
Q: Does DynamoDB Local support global secondary indexes?
Yes. DynamoDB Local is an offline version of DynamoDB that is useful for developing and testing DynamoDB-backed applications. You can download the latest version of DynamoDB Local here.
Q: What are projected attributes?
The data in a secondary index consists of attributes that are projected, or copied, from the table into the index. When you create a secondary index, you define the alternate key for the index, along with any other attributes that you want to be projected in the index. Amazon DynamoDB copies these attributes into the index, along with the primary key attributes from the table. You can then query the index just as you would query a table.
Q: Can a global secondary index key be defined on non-unique attributes?
Yes. Unlike the primary key on a table, a GSI index does not require the indexed attributes to be unique. For instance, a GSI on GameTitle could index all items that track scores of users for every game. In this example, this GSI can be queried to return all users that have played the game "TicTacToe."
Q: How do global secondary indexes differ from local secondary indexes?
Both global and local secondary indexes enhance query flexibility. An LSI is attached to a specific primary key hash value, whereas a GSI spans all primary key hash values. Since items having the same primary key hash value share the same partition in DynamoDB, the "Local" Secondary Index only covers items that are stored together (on the same partition). Thus, the purpose of the LSI is to query items that have the same primary key hash value but a different range key. For example, consider a DynamoDB table that tracks Orders for customers, where CustomerId is the primary key.
An LSI on OrderTime allows for efficient queries to retrieve the most recently ordered items for a particular customer.
In contrast, a GSI is not restricted to items with a common primary key hash value. Instead, it spans all items of the table just like the implicit primary index. For the table above, a GSI on ProductId can be used to efficiently find all orders of a particular product. Note that in this case, no GSI range key is specified, and even though there might be many orders with the same ProductId, they will be stored as separate items in the GSI.
In order to ensure that data in the table and the index is co-located to the same partition, LSIs limit [MC4] the total size of all elements (tables and indexes) to 10 GB per hash key value. GSIs do not enforce data co-location, and have no such restriction.
When you write to a table, DynamoDB atomically updates all the LSIs affected. In contrast, updates to any GSIs defined on the table are eventually consistent.
LSIs allow the Query API to retrieve attributes that are not part of the projection list. This is not supported behavior for GSIs.
Q: How do global secondary indexes work?
In many ways, GSI behavior is similar to that of a DynamoDB table. You can query a GSI using its hash key element, with conditional filters on the GSI range key element. However, unlike a primary key of a DynamoDB table, which must be unique, a GSI key can be the same for multiple items. If multiple items with the same GSI key exist, they are tracked as separate GSI items, and a GSI query will retrieve all of them as individual items. Internally, DynamoDB will ensure that the contents of the GSI are updated appropriately as items are added, removed or updated.
DynamoDB stores a GSI’s projected attributes in the GSI data structure, along with the GSI key and the matching items’ primary keys. GSI’s consume storage for projected items that exist in the source table. This enables queries to be issued against the GSI rather than the table, increasing query flexibility and improving workload distribution. Attributes that are part of an item in a table, but not part of the GSI key, primary key of the table, or projected attributes are thus not returned on querying the GSI index. Applications that need additional data from the table after querying the GSI, can retrieve the primary key from the GSI and then use either the GetItem or BatchGetItem APIs to retrieve the desired attributes from the table. As GSI’s are eventually consistent, applications that use this pattern have to accommodate item deletion (from the table) in between the calls to the GSI and GetItem/BatchItem.
DynamoDB automatically handles item additions, updates and deletes in a GSI when corresponding changes are made to the table. When an item (with GSI key attributes) is added to the table, DynamoDB updates the GSI asynchronously to add the new item. Similarly, when an item is deleted from the table, DynamoDB removes the item from the impacted GSI.
Q: Can I create global secondary indexes for hash-based tables and hash-range schema tables?
Yes, you can create a global secondary index regardless of the type of primary key the DynamoDB table has. The table can have just a primary hash key, or a primary hash and range key.
Q: What is the consistency model for global secondary indexes?
GSIs support eventual consistency. When items are inserted or updated in a table, the GSIs are not updated synchronously. Under normal operating conditions, a write to a global secondary index will propagate in a fraction of a second. In unlikely failure scenarios, longer delays may occur. Because of this, your application logic should be capable of handling GSI query results that are potentially out-of-date. Note that this is the same behavior exhibited by other DynamoDB APIs that support eventually consistent reads.
Consider a table tracking top scores where each item has attributes UserId, GameTitle and TopScore. The primary hash key is UserId, and the primary range key is GameTitle. If the application adds an item denoting a new top score for GameTitle "TicTacToe" and UserId "GAMER123," and then subsequently queries the GSI, it is possible that the new score will not be in the result of the query. However, once the GSI propagation has completed, the new item will start appearing in such queries on the GSI.
Q: Can I provision throughput separately for the table and for each global secondary index?
Yes. GSIs manage throughput independently of the table they are based on. You need to explicitly specify the provisioned throughput for the table and each associated GSI at creation time. You can use the Create Table Wizard of the DynamoDB Console which can assist you in distributing your total throughput among your tables and indexes.
Depending upon on your application, the request workload on a GSI can vary significantly from that of the table or other GSIs. Some scenarios that show this are given below:
- A GSI that contains a small fraction of the table items needs a much lower write throughput compared to the table.
- A GSI that is used for infrequent item lookups needs a much lower read throughput, compared to the table.
- A GSI used by a read-heavy background task may need high read throughput for a few hours per day.
As your needs evolve, you can change the provisioned throughput of the GSI, independently of the provisioned throughput of the table.
Consider a DynamoDB table with a GSI that projects all attributes, and has the GSI key present in 50% of the items. In this case, the GSI’s provisioned write capacity units should be set at 50% of the table’s provisioned write capacity units. Using a similar approach, the read throughput of the GSI can be estimated. Please see DynamoDB GSI Documentation for more details.
Q: How does adding a global secondary index impact provisioned throughput and storage for a table?
Similar to a DynamoDB table, a GSI consumes provisioned throughput when reads or writes are performed to it. A write that adds or updates a GSI item will consume write capacity units based on the size of the update. The capacity consumed by the GSI write is in addition to that needed for updating the item in the table.
Note that if you add, delete, or update an item in a DynamoDB table, and if this does not result in a change to a GSI, then the GSI will not consume any write capacity units. This happens when an item without any GSI key attributes is added to the DynamoDB table, or an item is updated without changing any GSI key or projected attributes.
A query to a GSI consumes read capacity units, based on the size of the items examined by the query.
Storage costs for a GSI are based on the total number of bytes stored in that GSI. This includes the GSI key and projected attributes and values, and an overhead of 100 bytes for indexing purposes.
Q: Can DynamoDB throttle my application writes to a table because of a GSI’s provisioned throughput?
Because some or all writes to a DynamoDB table result in writes to related GSIs, it is possible that a GSI’s provisioned throughput can be exhausted. In such a scenario, subsequent writes to the table will be throttled. This can occur even if the table has available write capacity units.
Q: How often can I change provisioned throughput at the index level?
Tables with GSIs have the same daily limits on the number of throughput change operations as normal tables.
Q: How am I charged for DynamoDB global secondary index?
You are charged for the aggregate provisioned throughput for a table and its GSIs by the hour. In addition, you are charged for the data storage taken up by the GSI as well as standard data transfer (external) fees. If you would like to change your GSI’s provisioned throughput capacity, you can do so using the DynamoDB Console or the UpdateTable API.
Q: Can I specify which global secondary index should be used for a query?
Yes. In addition to the common query parameters, a GSI Query command explicitly includes the name of the GSI to operate against. Note that a query can use only one GSI.
Q: What API calls are supported by a global secondary index?
The API calls supported by a GSI are Query and Scan. A Query operation only searches index key attribute values and supports a subset of comparison operators. Because GSIs are updated asynchronously, you cannot use the ConsistentRead parameter with the query. Please see here for details on using GSIs with queries and scans.
Q: How do I modify or delete a global secondary index after table creation?
Indexes cannot be created, modified, or dropped after the table is created.
Q: Are GSI key attributes required in all items of a DynamoDB table?
No. GSIs are sparse indexes. Unlike the requirement of having a primary key, an item in a DynamoDB table does not have to contain any of the GSI keys. If a GSI key has both hash and range elements, and a table item omits either of them, then that item will not be indexed by the corresponding GSI. In such cases, a GSI can be very useful in efficiently locating items that have an uncommon attribute.
Q: Can I retrieve all attributes of a DynamoDB table from a global secondary index?
A query on a GSI can only return attributes that were specified to be included in the GSI at creation time. The attributes included in the GSI are those that are projected by default such as the GSI’s key attribute(s) and table’s primary key attribute(s), and those that the user specified to be projected. For this reason, a GSI query will not return attributes of items that are part of the table, but not included in the GSI. A GSI that specifies all attributes as projected attributes can be used to retrieve any table attributes. See here for documentation on using GSIs for queries.
Q: How can I list GSIs associated with a table?
The DescribeTable API will return detailed information about global secondary indexes on a table.
Q: What data types can be indexed?
All scalar data types can be part of a GSI key (hash and range attributes). Set types cannot be part of a GSI key (hash or range attributes).
Q: Are composite attribute indexes possible?
No. But you can concatenate attributes into a string and use this as a key.
Q: What data types can be part of the projected attributes for a GSI?
You can specify attributes with any data types (including set types) to be projected into a GSI.
Q: What are some scalability considerations of GSIs?
Performance considerations of the primary key of a DynamoDB table also apply to GSI keys. A GSI assumes a relatively random access pattern across all its keys. To get the most out of secondary index provisioned throughput, you should select a GSI key hash element that has a large number of distinct values, and a GSI range key element that is requested fairly uniformly, as randomly as possible.
Q: What new metrics will be available through CloudWatch for global secondary indexes?
Tables with GSI will provide aggregate metrics for the table and GSIs, as well as breakouts of metrics for the table and each GSI.
Reports for individual GSIs will support a subset of the CloudWatch metrics that are supported by a table. These include:
- Read Capacity (Provisioned Read Capacity, Consumed Read Capacity)
- Write Capacity (Provisioned Write Capacity, Consumed Write Capacity)
- Throttled read events
- Throttled write events
For more details on metrics supported by DynamoDB tables and indexes see here.
Q: Can I auto-scale my tables and indexes in DynamoDB?
While this is not a native function, there are recommended third party libraries located in the Developer Resources section of the DynamoDB web page.
Local secondary indexes enable some common queries to run more quickly and cost-efficiently, that would otherwise require retrieving a large number of items and then filtering the results. It means your applications can rely on more flexible queries based on a wider range of attributes.
Before the launch of local secondary indexes, if you wanted to find specific items within a hash key bucket (items that share the same hash key), DynamoDB would have fetched all objects that share a single hash key, and filter the results accordingly. For instance, consider an e-commerce application that stores customer order data in a DynamoDB table with hash-range schema of customer id-order timestamp. Without LSI, to find an answer to the question “Display all orders made by Customer X with shipping date in the past 30 days, sorted by shipping date”, you had to use the Query API to retrieve all the objects under the hash key “X”, sort the results by shipment date and then filter out older records.
With local secondary indexes, we are simplifying this experience. Now, you can create an index on “shipping date” attribute and execute this query efficiently and just retieve only the necessary items. This significantly reduces the latency and cost of your queries as you will retrieve only items that meet your specific criteria. Moreover, it also simplifies the programming model for your application as you no longer have to write customer logic to filter the results. We call this new secondary index a ‘local’ secondary index because it is used along with the hash key and hence allows you to search locally within a hash key bucket. So while previously you could only search using the hash key and the range key, now you can also search using a secondary index in place of the range key, thus expanding the number of attributes that can be used for queries which can be conducted efficiently.
Redundant copies of data attributes are copied into the local secondary indexes you define. These attributes include the table hash and range key, plus the alternate range key you define. You can also redundantly store other data attributes in the local secondary index, in order to access those other attributes without having to access the table itself.
Local secondary indexes are not appropriate for every application. They introduce some constraints on the volume of data you can store within a single hash key value. For more information, see the FAQ items below about item collections.
Q: What are Projections?
The set of attributes that is copied into a local secondary index is called a projection. The projection determines the attributes that you will be able to retrieve with the most efficiency. When you query a local secondary index, Amazon DynamoDB can access any of the projected attributes, with the same performance characteristics as if those attributes were in a table of their own. If you need to retrieve any attributes that are not projected, Amazon DynamoDB will automatically fetch those attributes from the table.
When you define a local secondary index, you need to specify the attributes that will be projected into the index. At a minimum, each index entry consists of: (1) the table hash key value, (2) an attribute to serve as the index range key, and (3) the table range key value.
Beyond the minimum, you can also choose a user-specified list of other non-key attributes to project into the index. You can even choose to project all attributes into the index, in which case the index replicates the same data as the table itself, but the data is organized by the alternate range key you specify.
Q: How can I create a LSI?
You need to create a LSI at the time of table creation. It can’t currently be added later on. To create an LSI, specify the following two parameters:
Indexed Range key – the attribute that will be indexed and queried on.
Projected Attributes – the list of attributes from the table that will be copied directly into the local secondary index, so they can be returned more quickly without fetching data from the primary index, which contains all the items of the table. Without projected attributes, local secondary index contains only primary and secondary index keys.
Q: What is the consistency model for LSI?
Local secondary indexes are updated automatically when the primary index is updated. Similar to reads from a primary index, LSI supports both strong and eventually consistent read options.
Q: Do local secondary indexes contain references to all items in the table?
No, not necessarily. Local secondary indexes only reference those items that contain the indexed range key specified for that LSI. DynamoDB’s flexible schema means that not all items will necessarily contain all attributes.
This means local secondary index can be sparsely populated, compared with the primary index. Because local secondary indexes are sparse, they are efficient to support queries on attributes that are uncommon.
For example, in the Orders example described above, a customer may have some additional attributes in an item that are included only if the order is canceled (such as CanceledDateTime, CanceledReason). For queries related to canceled items, an local secondary index on either of these attributes would be efficient since the only items referenced in the index would be those that had these attributes present.
Q: How do I query local secondary indexes?
Local secondary indexes can only be queried via the Query API.
To query a local secondary index, explicitly reference the index in addition to the name of the table you’d like to query. You must specify the index hash attribute name and value. You can optionally specify a condition against the index key range attribute.
Your query can retrieve non-projected attributes stored in the primary index by performing a table fetch operation, with a cost of additional read capacity units.
Both strongly consistent and eventually consistent reads are supported for query using local secondary index.
Q: How do I create local secondary indexes?
Local secondary indexes must be defined at time of table creation. The primary index of the table must use a hash-range composite key.
Q: Can I add local secondary indexes to an existing table?
No, it’s not possible to add local secondary indexes to existing tables at this time. We are working on adding this capability and will be releasing it in the future. When you create a table with local secondary index, you may decide to create local secondary index for future use by defining a range key element that is currently not used. Since local secondary index are sparse, this index costs nothing until you decide to use it.
Q: How many local secondary indexes can I create on one table?
Each table can have up to five local secondary indexes.
Q: How many projected non-key attributes can I create on one table?
Each table can have up to 20 projected non-key attributes, in total across all local secondary indexes within the table. Each index may also specifify that all non-key attributes from the primary index are projected.
Q: Can I modify the index once it is created?
No, an index cannot be modified once it is created. We are working to add this capability in the future.
Q: Can I delete local secondary indexes?
No, local secondary indexes cannot be removed from a table once they are created at this time. Of course, they are deleted if you also decide to delete the entire table. We are working on adding this capability and will be releasing it in the future.
Q: How do local secondary indexes consume provisioned capacity?
You don’t need to explicitly provision capacity for a local secondary index. It consumes provisioned capacity as part of the table with which it is associated.
Reads and writes to LSI’s consume capacity by the standard formula of 1 unit per 1KB of data read or written each second, with the following differences:
When writes contain data that are relevant to one or more local secondary indexes, those writes are mirrored to the appropriate local secondary indexes. In these cases, write capacity will be consumed for the table itself, and additional write capacity will be consumed for each relevant LSI.
Updates that overwrite an existing item can result in two operations– delete and insert – and thereby consume extra units of write capacity per 1KB of data.
When a read query requests attributes that are not projected into the LSI, DynamoDB will fetch those attributes from the primary index. This implicit GetItem request consumes one read capacity unit per 1KB of item data fetched.
Q: How much storage will local secondary indexes consume?
Local secondary indexes consume storage for the attribute name and value of each LSI’s primary and index keys, for all projected non-key attributes, plus 100 bytes per item reflected in the LSI.
Q: What data types can be indexed?
All scalar data types (Number, String, Binary) can be used for the range key element of the local secondary index key. Set types cannot be used.
Q: What data types can be projected into a local secondary index?
All data types (including set types) can be projected into a local secondary index.
Q: What are item collections and how are they related to LSI?
In Amazon DynamoDB, an item collection is any group of items that have the same hash key, across a table and all of its local secondary indexes. Traditional partitioned (or sharded) relational database systems call these shards or partitions, referring to all database items or rows stored under a hash key.
Item collections are automatically created and maintained for every table that includes local secondary indexes. DynamoDB stores each item collection within a single disk partition.
Q: Are there limits on the size of an item collection?
Every item collection in Amazon DynamoDB is subject to a maximum size limit of 10 gigabytes. For any distinct hash key value, the sum of the item sizes in the table plus the sum of the item sizes across all of that table's local secondary indexes must not exceed 10 GB.
The 10 GB limit for item collections does not apply to tables without local secondary indexes; only tables that have one or more local secondary indexes are affected.
Although individual item collections are limited in size, the storage size of an overall table with local secondary indexes is not limited. The total size of an indexed table in Amazon DynamoDB is effectively unlimited, provided the total storage size (table and indexes) for any one hash key does not exceed the 10 GB threshold.
Q: How can I track the size of an item collection?
DynamoDB’s write APIs (PutItem, UpdateItem, DeleteItem, and BatchWriteItem) include an option, which allows the API response to include an estimate of the relevant item collection’s size. This estimate includes lower and upper size estimate for the data in a particular item collection, measured in gigabytes.
We recommend that you instrument your application to monitor the sizes of your item collections. Your applications should examine the API responses regarding item collection size, and log an error message whenever an item collection exceeds a user-defined limit (8 GB, for example). This would provide an early warning system, letting you know that an item collection is growing larger, but giving you enough time to do something about it.
Q: What if I exceed the 10GB limit for an item collection?
If a particular item collection exceeds the 10GB limit, then you will not be able to write new items, or increase the size of existing items, for that particular hash key. Read and write operations that shrink the size of the item collection are still allowed. Other item collections in the table are not affected.
To address this problem , you can remove items or reduce item sizes in the collection that has exceeded 10GB. Alternatively, you can introduce new items under a new hash key value to work around this problem. If your table includes historical data that is infrequently accessed, consider archiving the historical data to Amazon S3, Amazon Glacier or another data store.
Fine Grained Access Control (FGAC) gives a DynamoDB table owner a high degree of control over data in the table. Specifically, the table owner can indicate who (caller) can access which items or attributes of the table and perform what actions (read / write capability). FGAC is used in concert with AWS Identity and Access Management (IAM), which manages the security credentials and the associated permissions.
Q: What are the common use cases for DynamoDB FGAC?
FGAC can benefit any application that tracks information in a DynamoDB table, where the end user (or application client acting on behalf of an end user) wants to read or modify the table directly, without a middle-tier service. For instance, a developer of a mobile app named Acme can use FGAC to track the top score of every Acme user in a DynamoDB table. FGAC allows the application client to modify only the top score for the user that is currently running the application.
Q: Without FGAC, how can a developer achieve item level access control?
To achieve this level of control without FGAC, a developer would have to choose from a few potentially onerous approaches. Some of these are:
- Proxy: The application client sends a request to a brokering proxy that performs the authentication and authorization. Such a solution increases the complexity of the system architecture and can result in a higher total cost of ownership (TCO).
- Per Client Table: Every application client is assigned its own table. Since application clients access different tables, they would be protected from one another. This could potentially require a developer to create millions of tables, thereby making database management extremely painful.
- Per-Client Embedded Token: A secret token is embedded in the application client. The shortcoming of this is the difficulty in changing the token and handling its impact on the stored data. Here, the key of the items accessible by this client would contain the secret token.
Q: How does DynamoDB FGAC work?
With FGAC, an application requests a security token that authorizes the application to access only specific items in a specific DynamoDB table. With this token, the end user application agent can make requests to DynamoDB directly. Upon receiving the request, the incoming request’s credentials are first evaluated by DynamoDB, which will use IAM to authenticate the request and determine the capabilities allowed for the user. If the user’s request is not permitted, FGAC will prevent the data from being accessed.
Q: How much does DynamoDB FGAC cost?
There is no additional charge for using FGAC. As always, you only pay for the provisioned throughput and storage associated with the DynamoDB table.
Q: How do I get started?
Refer to the Fine-Grained Access Control section of the DynamoDB Developer Guide to learn how to create an access policy, create an IAM role for your app (e.g. a role named AcmeFacebookUsers for a Facebook app_id of 34567), and assign your access policy to the role. The trust policy of the role determines which identity providers are accepted (e.g. Login with Amazon, Facebook, or Google), and the access policy describes which AWS resources can be accessed (e.g. a DynamoDB table). Using the role, your app can now to obtain temporary credentials for DynamoDB by calling the AssumeRoleWithIdentityRequest API of the AWS Security Token Service (STS).
Q: How do I allow users to Query a Local Secondary Index, but prevent them from causing a table fetch to retrieve non-projected attributes?
Some Query operations on a Local Secondary Index can be more expensive than others if they request attributes that are not projected into an index. You an restrict such potentially expensive “fetch” operations by limiting the permissions to only projected attributes, using the "dynamodb:Attributes" context key.
Q: How do I prevent users from accessing specific attributes?
The recommended approach to preventing access to specific attributes is to follow the principle of least privilege, and Allow access to only specific attributes.
Alternatively, you can use a Deny policy to specify attributes that are disallowed. However, this is not recommended for the following reasons:
- With a Deny policy, it is possible for the user to discover the hidden attribute names by issuing repeated requests for every possible attribute name, until the user is ultimately denied access.
- Deny policies are more fragile, since DynamoDB could introduce new API functionality in the future that might allow an access pattern that you had previously intended to block.
Q: How do I prevent users from adding invalid data to a table?
The available FGAC controls can determine which items changed or read, and which attributes can be changed or read. Users can add new items without those blocked attributes, and change any value of any attribute that is modifiable.
Q: Can I grant access to multiple attributes without listing all of them?
The IAM policy panguage supports a rich set of comparison operations, including StringLike, StringNotLike, and many others. For example, the following policy snippet matches all attributes beginning with “public_”
Q: How do I create an appropriate policy?
We recommend that you use the DynamoDB Policy Generator from the DynamoDB console. You may also compare your policy to those listed in the Amazon DynamoDB Developer Guide to make sure you are following a recommended pattern. You can post policies to the AWS Forums to get thoughts from the DynamoDB community.
Q: Can I grant access based on a canonical user id instead of separate ids for the user based on the identity provider they logged in with?
Not without running a “token vending machine”. If a user retrieves federated access to your IAM role directly using Facebook credentials with STS, those temporary credentials only have information about that user’s Facebook login, and not their Amazon login, or Google login. If you want to internally store a mapping of each of these logins to your own stable identifier, you can run a service that the user contacts to log in, and then call STS and provide them with credentials scoped to whatever hash key value you come up with as their canonical user id.
Q: What information cannot be hidden from callers using FGAC?
Certain information cannot currently be blocked from the caller about the items in the table:
- Item collection metrics. The caller can ask for the estimated number of items and size in bytes of the item collection.
- Consumed throughput The caller can ask for the detailed breakdown or summary of the provisioned throughput consumed by operations.
- Validation cases. In certain cases, the caller can learn about the existence and primary key schema of a table when you did not intend to give them access. To prevent this, follow the principle of least privilege and only allow access to the tables and actions that you intended to allow access to.
- If you deny access to specific attributes instead of whitelisting access to specific attributes, the caller can theoretically determine the names of the hidden attributes if “allow all except for” logic. It is safer to whitelist specific attribute names instead.
Each DynamoDB table has provisioned read-throughput and write-throughput associated with it. You are billed by the hour for that throughput capacity if you exceed the free tier.
Please note that you are charged by the hour for the throughput capacity that you provision for your table, whether or not you are sending requests to your table. If you would like to change your table’s provisioned throughput capacity, you can do so using the AWS Management Console or the UpdateTable API.
In addition, DynamoDB also charges for indexed data storage as well as the standard internet data transfer fees
To learn more about DynamoDB pricing, please visit the DynamoDB pricing page.
Q: What are some pricing examples?
Here is an example of how to calculate your throughput costs using US East (Northern Virginia) Region pricing. To view prices for other regions, visit our pricing page.
If you create a table and request 10 units of write capacity and 200 units of read capacity of provisioned throughput, you would be charged:
$0.01 + (4 x $0.01) = $0.05 per hour
If your throughput needs changed and you increased your reserved throughput requirement to 10,000 units of write capacity and 50,000 units of read capacity, your bill would then change to:
(1,000 x $0.01) + (1,000 x $0.01) = $20/hour
To learn more about DynamoDB pricing, please visit the DynamoDB pricing page.
Q: Do your prices include taxes?
Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax. For example, our prices for the Asia Pacific (Tokyo) Region are inclusive of Japan consumption tax.
Reserved Capacity is a billing feature that allows you to obtain discounts on your provisioned throughput capacity in exchange for:
- A one-time up-front payment
- A commitment to a minimum monthly usage level for the duration of the term of the agreement.
Reserved Capacity applies within a single AWS Region and can be purchased with 1-year or 3-year terms. Every DynamoDB table has provisioned throughput capacity associated with it. When you create or update a table, you specify how much read or write capacity you want it to have. This capacity is what determines the read and write throughput rate that your DynamoDB table can achieve. Reserved Capacity is a billing arrangement and has no direct impact on the performance or capacity of your DynamoDB tables. For example, if you buy 5,000 write capacity units of Reserved Capacity, you have agreed to pay for that much capacity for the duration of the agreement (1 or 3 years) in exchange for discounted pricing.Q: How do I buy Reserved Capacity?Log into the AWS Management Console, go to the DynamoDB console page, and then click on "Purchase Reserved Capacity”. This will take you to a form you can fill out to purchase Reserved Capacity. Make sure you have selected the AWS Region in which your Reserved Capacity will be used. Please allow up to two weeks for your purchase request to be processed. You will be notified by email when your purchase request has been processed.
Q: Can I cancel a Reserved Capacity purchase?
No, you cannot cancel your Reserved Capacity and the one-time payment is not refundable. You will continue to pay for every hour during your Reserved Capacity term regardless of your usage.
Q: What is the smallest amount of Reserved Capacity that I can buy?
The smallest Reserved Capacity offering is 5,000 write capacity units and 5,000 read capacity units.
Q: Are there APIs that I can use to buy Reserved Capacity?
Not yet. We will provide APIs and add more Reserved Capacity options over time.
Q: How many Reserved Capacity purchases can I make?
Currently, each AWS account can make one Reserved Capacity purchase. We will expand our Reserved Capacity offering in future to allow more Reserved Capacity purchases per account.
Q: Can I move Reserved Capacity from one Region to another?
No. Reserved Capacity is associated with a single Region.
Q: Can I provision more throughput capacity than my Reserved Capacity?
Yes. When you purchase Reserved Capacity, you are agreeing to a minimum usage level and you pay a discounted rate for that usage level. If you provision more capacity than that minimum level, you will be charged at standard rates for the additional capacity.
Q: How do I use my Reserved Capacity?
Reserved Capacity is automatically applied to your bill. For example, if you purchase 5,000 write capacity units of Reserved Capacity and you have provisioned 6,000, then your Reserved Capacity purchase will automatically cover the cost of 5,000 write capacity units and you will pay standard rates for the remaining 1,000 write capacity units.
Q: What happens if I provision less throughput capacity than my Reserved Capacity?
A Reserved Capacity purchase is an agreement to pay for a minimum amount of provisioned throughput capacity, for the duration of the term of the agreement, in exchange for discounted pricing. If you use less than your Reserved Capacity, you will still be charged each month for that minimum amount of provisioned throughput capacity.
Q: Can I use my Reserved Capacity for multiple DynamoDB tables?
Yes. Reserved Capacity is applied to the total provisioned capacity within the Region in which you purchased your Reserved Capacity. For example, if you purchased 5,000 write capacity units of Reserved Capacity, then you can apply that to one table with 5,000 write capacity units, or 100 tables with 50 write capacity units, or 1,000 tables with 5 write capacity units, etc.