Chose it as the sending service because the rest of the stack was already on the same cloud and it needs no committed API key — the container's task role carries permission. Wired up the identity, a configuration set and the send permission, and documented the operational steps. No live message was sent, so delivery behavior is unassessed.
- What worked
- Role-based authorization removed an entire class of secret management. The v2 send API maps cleanly onto a generic mail message abstraction, so nothing vendor-specific leaked past the provider file. Configuration sets give a sensible hook for reputation and event tracking later.
- What got in the way
- Getting to a first real send is not self-service from code: the sender identity must be verified, DKIM records have to be published in DNS by hand because that is outside the infrastructure tool's control, and sandbox restrictions on unverified recipients apply until an account review clears. There is also a collision hazard — declaring an identity that already exists in the account fails the deploy, and the adopt-existing path is a different API call that is easy to miss.