Confused by the role requirement of ECS

The only necessary role is the Container Instance IAM role. This role allows the ECS agent (running on your EC2 instance) to communicate with Amazon ECS.

There are five other roles that you may also find useful, for different purposes:

• ECS Service-Linked role (SLR) - This role enables Amazon ECS to manage a variety of AWS resources associated with your application on your behalf. When using a Service, this role allows Amazon ECS to manage the load balancer (Classic Load Balancers, Application Load Balancers, and Network Load Balancers) and service discovery (with Route 53) associated with your service. When using task networking, this role allows Amazon ECS to attach and detach Elastic Network Interfaces (ENIs) to your tasks. This role is required when using AWS Fargate.
• Service Scheduler IAM role - Prior to the introduction of the ECS Service-Linked role (SLR), this role was used in conjunction with a Service to enable Amazon ECS to manage the load balancer associated with your service. If you want to use an Elastic Load Balancer (whether a Classic Load Balancer, an Application Load Balancer, or a Network Load Balancer) with your ECS service, you can use this role. Now that the ECS SLR is available you can use either of the two roles, but you may still wish to use this role if you want to restrict the permissions that are granted to Amazon ECS to cover specific load balancer resources.
• Auto Scaling IAM role - This role is used in conjunction with a Service and allows the Application Auto Scaling service to scale the desired count of your Service in or out.
• Task IAM role - This role can be used with any Task (including Tasks launched by a Service). This role is very similar to an EC2 instance profile, but allows you to associate permissions with individual Tasks rather than with the underlying EC2 instance that is hosting those Tasks. If you are running a number of different applications across your ECS cluster with different permissions required, you can use the Task IAM role to grant specific permissions to each Task rather than ensuring that every EC2 instance in your cluster has the combined set of permissions that any application would need.
• Task execution role - This role is required when using AWS Fargate and replaces the Container Instance IAM role, which is unavailable for the FARGATE launch type. This role enables AWS Fargate to pull your container images from Amazon ECR and to forward your logs to Amazon CloudWatch Logs. This role is also used (on both the Fargate and the EC2 launch types) to enable private registry authentication and secrets from AWS Secrets Manager and AWS Systems Manager Parameter Store.

Using my Administrator role, when creating an ECS Cluster, I too was blocked by... "ECS Cluster Unable to assume the service linked role. Please verify that the ECS service linked role exists."

And I verified that indeed the role, AWSServiceRoleForECS, existed.

The Fix? By exercising the "Get Started" wizard, it (re)configured something under the covers and now my Administrator roles is allowed to assume AWSServiceRoleForECS and successfully creates cluster.

In addition to this very good explanation of @samuel-karp, today I ran into a problem when migrating from classic ELB to the ALB in combination of custom task_role_arn for ECS services.

Although I followed the instructions described behind the link Task IAM role, the Error was

Unable to assume role and validate the specified targetGroupArn. Please verify that the ECS service role being passed has the proper permissions.

The thing is that the service seems to register itself at the load balancer. It only worked when I exchanged the Principal from ecs.amazonaws.com to

"Principal": { "Service": "ecs-tasks.amazonaws.com" }