The way external access management works for Bitbucket is that a user creates an IAM User and attaches certain permissions to it. This allows the usage of IAM Users through ACCESS_KEY_ID and ACCESS_SECRET_KEY.

This leads to some disadvantages such as:

1- It forces the user to share long-term access keys.
2- It prevents your users from using what's called "keys rotation" - a security mechanism that changes credentials to resources that are defined by the user.
3- It prevents your users from controlling who really uses these keys.

The advantages of using IAM Roles improves the sections above:
1- Role-based authentication is session-based credentials rather than long-term.
2- It allows your users to rotate keys, meaning that even if the keys
are compromised, it's only temporary until they are replaced.
3- It allows your users to define which entities are allowed to use the role (e.g. a bitbucket role / AWS account which is associated with bitbucket / etc.).

As a suggestion, the setup between your user and a pipeline can be as follows:

1- Bitbucket creates on its behalf an AWS IAM Entity (IAM User / IAM
Role / etc.), and shares the ARN (ARN is the "amazon identifier"
for this IAM entity) and maybe another thing which is called "external_id"
in amazon terms.
2- Your users create an IAM Role, which allows only the entity from
step (1) to assume it.
3- Your users also attaches the desired permissions to their Role -
access to services such as ECS / ECR / Lambda to perform deployments, for
example.
4- In the bitbucket-pipelines.yml file, instead of giving the
access-key and secret-key (even if they are secured-variables), the user provides their IAM-Role ARN.
5- Bitbucket can now use this IAM-Role in order to perform requests on
behalf of your user, and yet no party needs to share any secrets with the
other.