Say I have set up this service in account A, and I want it to monitor & control resources in accounts B and C. I'm planning to create IAM roles in B & C, then use STS in A to get access to the resources, like in https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html. I assume the service is allowed to have access to multiple different accounts at once. This solution is more easily scaled should I need to monitor resources in accounts E, F, G...
An alternative is to deploy the service in accounts B & C, then there is no need for cross account access, but harder to scale.
I'm not sure which approach is better and am a beginner in AWS. Any help appreciated, thanks.
Your approach of creating an identical IAM Role in each account is good.
This is frequently done with 3rd-party services, such as a virus-scanning service since it gives them access to accounts that might belong to other companies, but permissions are limited to what was granted via the IAM Role.
The approach is also much easier to manage than putting your service in each account, since it would need additional permissions to deploy, monitor and maintain those services. By doing it all from your own AWS Account, you have access to everything necessary to maintain and operate your service.
Please note that your service would call AssumeRole(), providing the ARN (Amazon Resource Name) of the IAM Role you wish to assume. The ARN includes the Account Number. AWS STS would then provide back some temporary credentials that your service can use to access resources using the permissions of that IAM Role.
So, it is not quite accurate to say "I assume the service is allowed to have access to multiple different accounts at once". Rather, AssumeRole needs to be called for each account 'assumed' separately, and the credentials returned will be different for each AWS Account. So, they aren't being accessed "all at once", but rather "one per set of credentials".