This does not provide a solution for preventing impact to the production workloads. The limit parameter should be used to ensure the table's RCUs are not fully used.

To understand deeply about RCUs, eventually consistent RCUs and other RCUs, their differences. Read 2 min- blog : https://kaustubhsharma.com/blog/RCU-and-WCU

A Scan operation in Amazon DynamoDB reads every item in a table or a secondary index. By default, the scan operation processes data sequentially.

Scan always returns a result set. If no matching items are found, the result set is empty.

A single scan request can retrieve a maximum of 1 MB of data. Optionally, DynamoDB can apply a filter expression to this data, narrowing the results before they are returned to the user.

Sequential scans are slower than parallel scans and the Developer needs to minimize scan execution time.

Performing a scan on a table consumes a lot of RCUs. A Scan operation always scans the entire table or secondary index. It then filters out values to provide the result you want, essentially adding the extra step of removing data from the result set. To reduce the amount of RCUs used by the scan so it doesn’t affect production workloads whilst minimizing the execution time, there are a couple of recommendations the Developer can follow.

Firstly, the Limit parameter can be used to reduce the page size. The Scan operation provides a Limit parameter that you can use to set the page size for your request. Each Query or Scan request that has a smaller page size uses fewer read operations and creates a "pause" between each request.

Secondly, the Developer can configure parallel scans. With parallel scans, the Developer can maximize usage of the available throughput and have the scans distributed across the table’s partitions.

A parallel scan can be the right choice if the following conditions are met:

• The table size is 20 GB or larger.
• The table's provisioned read throughput is not being fully used.
• Sequential Scan operations are too slow.

Therefore, to optimize the scan operation the Developer should use parallel scans while limiting the rate as this will ensure that the scan operation does not affect the performance of production workloads and still have it complete in the minimum time.

The table is only using half of the RCUs during non-peak hours so there are RCUs available. You could increase RCUs and perform the scan faster, but this would be more expensive. A better solution is to use parallel scans with the limit parameter.

To read more about RCUs and their types & WCUs: https://kaustubhsharma.com/blog/RCU-and-WCU

.1." optimize the scan execution time" -  So, to optimize scan time when all RCUs are still not in use, best way to use parallel scans & limit parameters.

This is not a valid method of invalidating the cache with API Gateway.

An Application Programming Interface (API) allows two systems to communicate with one another.

An endpoint is one end of a communication channel. When an API interacts with another system, the touchpoints of this communication are considered endpoints.

To call a deployed API, clients submit requests to the URL for the API Gateway component service for API execution, known as execute-api.

The base URL for REST APIs is in the following format:

where 

• {restapi_id}= API identifier,
• {region} = Region, and 
• {stage_name} = stage name of the API deployment.

This is not a valid method of invalidating the cache with API Gateway.

When you enable caching for a stage, API Gateway caches responses from your endpoint for a specified time-to-live (TTL) period, in seconds. API Gateway then responds to the request by looking up the endpoint response from the cache instead of making a request to your endpoint. The default TTL value for API caching is 300 seconds. The maximum TTL value is 3600 seconds. TTL=0 means caching is disabled.

You do not need to wait as you can pass the HTTP header Cache-Control: max-age=0 whenever you need to in order to invalidate the cache.

You can enable API caching in Amazon API Gateway to cache your endpoint's responses. With caching, you can reduce the number of calls made to your endpoint and also improve the latency of requests to your API.

When you enable caching for a stage, API Gateway caches responses from your endpoint for a specified time-to-live (TTL) period, in seconds. API Gateway then responds to the request by looking up the endpoint response from the cache instead of making a request to your endpoint. The default TTL value for API caching is 300 seconds. The maximum TTL value is 3600 seconds. TTL=0 means caching is disabled.

A client of your API can invalidate an existing cache entry and reload it from the integration endpoint for individual requests. The client must send a request that contains the Cache-Control: max-age=0 header.

The client receives the response directly from the integration endpoint instead of the cache, provided that the client is authorized to do so. This replaces the existing cache entry with the new response, which is fetched from the integration endpoint.

To grant permission for a client, attach a policy of the following format to an IAM execution role for the user.

This policy allows the API Gateway execution service to invalidate the cache for requests on the specified resource (or resources).

Therefore, as described above the solution is to get the partners to pass the HTTP header Cache-Control: max-age=0.

1." invalidate the API cache" - which can be done by passing the HTTP header Cache-Control: max-age=0

The file extension for ECS or Lambda deployments should be “.yaml”, not “.yml”.The name of the AppSpec file for an EC2/On-Premises deployment must be appspec.yml

This is the file name you should use for the file that defines the build instructions for AWS CodeBuild.

This is a file you can use with Elastic Beanstalk if you want to deploy a worker application that processes periodic background tasks.

The application specification file (AppSpec file) is a YAML-formatted or JSON-formatted file used by CodeDeploy to manage deployment. The AppSpec file defines the deployment actions you want AWS CodeDeploy to execute.

The name of the AppSpec file for an EC2/On-Premises deployment must be appspec.yml. The name of the AppSpec file for an Amazon ECS or AWS Lambda deployment must be appspec.yaml.

Therefore, as this is an ECS deployment the file name must be appspec.yaml.

1."defined the deployment actions" & ""The name of the AppSpec file for an Amazon ECS or AWS Lambda deployment must be appspec.yaml.