You have a web application that is currently running on three M3 EC2 instances in three different AZs. You have an Auto Scaling group configured to scale from three to thirty instances. When reviewing your CloudWatch metrics, you see that sometimes your Auto Scaling group hosts fifteen instances. The web application is reading and writing to a DynamoDB-configured backend, configured with 800 Write Capacity Units and 800 Read Capacity Units. Your DynamoDB Primary Key is the Company ID. You are hosting 25 TB of data in the database.

Answer options:

A.Add a caching layer in front of your web application by choosing ElastiCache Memcached instances in one of the AZs.
B.Double the number of Write Capacity Units in your DynamoDB instance because the instance is probably being throttled when the customer accesses the website and your web application.
C.Change your Auto Scaling group configuration to use Amazon C3 instance types, because the web application layer is probably running out of compute capacity.
D.Implement an Amazon SQS queue between your DynamoDB database layer and the web application layer to minimize the large burst in traffic the customer generates when everyone arrives at the office at 9:00AM and begins accessing the website.
E.Use data pipelines to migrate your DynamoDB table to a new DynamoDB table with a primary key that is evenly distributed across your dataset. Update your web application to request data from the new table.

Answer – E
The AWS documentation provide the following information on the best performance for DynamoDB tables
The optimal usage of a table`s provisioned throughput depends on these factors:
The primary key selection.
The workload patterns on individual items.
The primary key uniquely identifies each item in a table. The primary key can be simple (partition key) or composite (partition key and sort key).
When it stores data, DynamoDB divides a table`s items into multiple partitions, and distributes the data primarily based upon the partition key value. Consequently, to achieve the full amount of request throughput you have provisioned for a table, keep your workload spread evenly across the partition key values. Distributing requests across partition key values distributes the requests across partitions.
Option A is incorrect because ElastiCache should be in front of the DynamoDB instance instead of the web application.
Option B is incorrect because the read capacity units should be improved instead of the write capacity units.
Option C is incorrect because the computer capacity of instances is not the major issue. We should improve the improper primary key in the DynamoDB instance.
Option D is incorrect because this may help however it does not fix the root cause of the problem.
For more information on DynamoDB best practises please visit the link:
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html
Note:
One of the AWS forumns is explaining the steps for this process in detail.
Based on that, while importing data from S3 using datapipeline to a new table in dynamodb we can create a new index.
Please find the steps given below.
1. Log into AWS console, select DynamoDB 
2. Select table you want to copy
3. Click Export/Import. Export/Import uses dataPipeline and EMR to copy DynamoDB table to S3 and from S3 to DynamoDB table
4. If you have not already, you need to create two IAM roles for Export/Import. Documentation is available here
5. Select Export table option ( Detailed documentation for exporting table data to S3 is available here
6. You will need to specify 
a. S3 bucket where the table data will be copied and another bucket where the log files for the operation will be stored. You can use the same bucket
b. The percentage of the throughput capacity you have provisioned for the table that you want to use for reading data from the table ( to copy to S3). The default is 25%. Increasing the percentage will speed up the backup
c. The IAM roles : The values will be defaulted
7. Select "create data pipeline" option and the backup will be scheduled. The backup could take time depending on size of the table
8. Once export is complete, check logs to verify there are no errors
9. Note details of the hash and range key of the table
10. Delete the table
11. Create table with the right index. Set the provisioned throughput 
12. Import into table from S3 using the Import option
13. Once complete, verify there are no errors
For more information please view the following link:
https://forums.aws.amazon.com/thread.jspa?threadID=149069