Two Email Services, One Side Project: My Azure Communication Services Identity Crisis
I have been setting up email notifications for my side project, and I decided to give Azure Communication Service a try. I expected a fairly straightforward experience: provision a resource, get an endpoint, wire it into my app, and move on.
Instead, I found myself instantly confused. Not only are there two different resources that seem to do email, but they also feel sparsely covered by azurerm.
That left me wondering whether they don’t get much use, or whether the product team didn’t spend much time worrying about automation use cases. I genuinely don’t know.
The Swiss Army Knife Resource
The first thing I ran into was what feels like the Swiss army knife of the offering:
resource "azurerm_communication_service" "example" {
name = "example-communicationservice"
resource_group_name = azurerm_resource_group.example.name
data_location = "United States"
}
When I open this thing up in the portal, it can do everything: Telephony and SMS, Email, Advanced Messaging. It presents itself as the all-in-one communications platform.
The portal experience is packed with helpful “beginner” boilerplate. It’s very much Day Zero material — just kicking the tires, trying to find my belly button. There are “get started now” guides and copy-paste code snippets clearly designed for spinning up a quick POC. It feels optimized for someone experimenting, not someone trying to stand up something durable and automated.
Part of me wonders whether these tutorials disappear once I prove myself as a mature Azure Communication Services user. I doubt it, but in the moment it felt like I was stuck in onboarding mode whether I wanted to be or not.
The Totally Different Email Resource
Then I discovered there’s a completely separate resource:
resource "azurerm_email_communication_service" "example" {
name = "example-emailcommunicationservice"
resource_group_name = azurerm_resource_group.example.name
data_location = "United States"
}
This is the Azure Email Communication Service. Not to be confused with the Azure Communication Service that also does email.
At this point, I became even more confused. Why are there two things that appear to overlap? Is one deprecated? Is one the “real” future and the other just legacy? Is this another situation where a service spawns multiple slightly mutated forms with overlapping names?
The portal experience for the email-specific resource is almost the opposite of the Swiss army knife one. There’s no beginner-friendly “Try this” material. But there’s also almost nothing that an advanced user — like me, or at least someone trying to behave like one — would expect. I couldn’t immediately find obvious endpoints. I didn’t see much in the way of monitoring. I provisioned this new thing, and it felt like I was staring at an empty shell.
What’s the Big Deal?
The core of my confusion isn’t just that there are two resources. It’s that they both appear to handle email, yet neither gives me a clean, end-to-end story from provisioning to production use.
The general azurerm_communication_service resource feels like the front door. It’s broad, feature-rich, and onboarding-heavy. The azurerm_email_communication_service resource feels specialized, but oddly bare. One is full of tutorials and POC snippets. The other is quiet and minimal.
As someone trying to automate this with Terraform, I expect clarity: one resource for one responsibility. Instead, I’m left guessing which one I’m supposed to build around. If I choose the wrong one, am I building on something that’s going away? If I choose both, am I overcomplicating a simple requirement — just sending email notifications from a side project?
Conclusion
Right now, my experience with Azure Communication Service for email feels more like navigating product boundaries than solving a technical problem. I started out just wanting to send notifications. Instead, I’m trying to understand why there are two similarly named resources, why their portal experiences are so different, and how I can possibly automate this thing in a sustainable way.
Maybe there’s a clean mental model behind it. Maybe it makes perfect sense once you’ve lived with it long enough. But as someone approaching it fresh, I’m left asking a simple question: which one am I actually supposed to use?