ReceiveMessageWaitTimeSeconds is the length of time, in seconds, for which a ReceiveMessage action waits for a message to arrive. This is used to configure long polling.

When a consumer receives and processes a message from a queue, the message remains in the queue. Amazon SQS doesn't automatically delete the message. Because Amazon SQS is a distributed system, there's no guarantee that the consumer actually receives the message (for example, due to a connectivity issue, or due to an error in the consumer application). Thus, the consumer must delete the message from the queue after receiving and processing it.

Immediately after a message is received, it remains in the queue. To prevent other consumers from processing the message again, Amazon SQS sets a visibility timeout, a period of time during which Amazon SQS prevents other consumers from receiving and processing the message. The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours.
Therefore, the best thing the Developer can do in this situation is to increase the VisibilityTimeout API action on the queue

DelaySeconds controls the length of time, in seconds, for which the delivery of all messages in the queue is delayed.

RedrivePolicy is a string that includes the parameters for the dead-letter queue functionality of the source queue as a JSON object.

1."duplication" & SQS message duplication can be removed by increasing Visibility Timeout.

This is used to schedule a scaling action at a specific time and date rather than dynamically adjusting according to load.

With target tracking scaling policies, you select a scaling metric and set a target value. Amazon EC2 Auto Scaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and the target value. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value. In addition to keeping the metric close to the target value, a target tracking scaling policy also adjusts to the changes in the metric due to a changing load pattern.
For example, you can use target tracking scaling to:
1. Configure a target tracking scaling policy to keep the average aggregate CPU utilization of your Auto Scaling group at 70 percent.
2. Configure a target tracking scaling policy to keep the request count per target of your Elastic Load Balancing target group at 800 for your Auto Scaling group.

In Simple Autoscaling Policy, you define the threshold value and upper bound. The alarm monitors the metric values. When the metric value breaches the threshold, the scaling policy acts. The instances are added or removed as per the policy.

Step scaling policies increase or decrease the current capacity of a scalable target based on a set of scaling adjustments, known as step adjustments. The adjustments vary based on the size of the alarm breach. All alarms that are breached are evaluated by Application Auto Scaling as it receives the alarm messages.

1."maintain aggregate CPU utilization at 70%" redirects to Target tracking scaling policy as we have to maintain capacity at specified target.

Amazon ECS cluster is a logical grouping of tasks or services & IAM role should be applied to the ECS task definition, not the ECS cluster.

With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task. Applications must sign their AWS API requests with AWS credentials, and this feature provides a strategy for managing credentials for your applications to use. Instead of creating and distributing your AWS credentials to the containers or using the EC2 instance’s role, you can associate an IAM role with an ECS task definition or RunTask API operation. Therefore, the most secure solution is to use a separate IAM role with the specific permissions required for an individual service and associate that role to the relevant ECS task definition. This should then be repeated for the remaining 5 services.

Identity-based policies attached to the ECS service can be used to control permissions for viewing, launching, and managing resources within ECS. However, for this solution we need to control the permissions for an ECS task to access other AWS services. For this we need to use IAM Roles for Tasks.

With IAM Roles for Tasks you apply the permissions directly to the task definition. This means multiple services can share the underlying single EC2 instance and only have the minimum privileges required, there is no need to use multiple instances.

1."Each service requires specific permissions to various AWS services" which redirect us to IAM roles as they are required to specify permissions & to specify different permissions to various services, IAM role should be applied to the ECS task definition, not the ECS cluster.