Isso é realmente possível por meio do Gerenciamento de identidade e acesso (IAM) da AWS , que permite que você use controlar o acesso a serviços e recursos da AWS para seus usuários (facilitar o uso do IAM em vez das principais credenciais da conta para o uso diário da AWS é altamente recomendado).
Entre vários outros, o IAM permite o seguinte caso de uso:
Fine-grained access control to your AWS resources: IAM enables you to control access to AWS service APIs and to specific resources. IAM also enables you to add specific conditions to control how a user can use AWS, such as time of day, their originating IP address, or whether they are using SSL.
A respectiva granularidade varia entre os serviços AWS disponíveis (ela tende a aumentar com o tempo), mas, felizmente, a granularidade da API do EC2 é alta e o que você está procurando está prontamente disponível - por exemplo, você pode querer verificar o AWS Policy Generator recomendado, selecione o tipo Política do IAM e o serviço Amazon EC2 , que permitirá selecionar a ação AssociateAddress .
Consequentemente, você deve conseguir atingir seu objetivo criando um usuário dedicado do IAM para a tarefa em questão, elaborando uma política do IAM essencialmente limitada a AssociateAddress (talvez DisassociateAddress como bem) e atribuir essa política ao usuário do IAM - por exemplo, a política pode ser assim:
{
"Statement": [
{
"Action": [
"ec2:AssociateAddress",
"ec2:DisassociateAddress"
],
"Effect": "Allow",
"Resource": "*"
}
]
}