Having spent the last two days attempting to migrate our templating and configuration workflows from the classic SES console to the new V3 AWS Console experience, I feel compelled to document the regression in operational efficiency. While AWS markets this as a "modern, unified experience," the reality for a deliverability engineer is a significant increase in click-depth, a loss of at-a-glance information, and a frustrating obfuscation of critical settings.
The primary pain points I've cataloged so far:
* **Configuration Set Management:** The process of linking a configuration set to a dedicated IP pool or viewing event destination metrics is now buried. Previously, this was a direct, two-click operation. Now, it requires navigating through "Email Sending," then "Configuration Sets," selecting a set, then finding the "Dedicated IPs" tab, which is not intuitively linked to the "Pool" concept. The visual hierarchy is flat and confusing.
* **Template Versioning Clutter:** The new template UI lists every single version inline, making it incredibly difficult to scan for the currently active `$Default` version when you have dozens of historical iterations. The classic console had a clear "Versions" tab with a primary default indicator.
* **Loss of Global Dashboard Metrics:** The old SES homepage provided an immediate, high-level view of bounces, complaints, and delivery attempts across all regions and identities. This is now completely gone, replaced by a generic AWS service landing page that forces you into CloudWatch for any aggregate data, adding significant latency to basic health checks.
* **API Inconsistency:** The new console often presents a different mental model than the actual SES API. For instance, the way `SendTemplatedEmail` parameters are visualized in the "Test Template" feature doesn't map cleanly to our actual Lambda code, creating a disconnect between testing and implementation.
A concrete example: to check the reputation of a dedicated IP pool, I now must:
1. Navigate to SES > Dedicated IPs.
2. Click on a pool name.
3. Switch to the "Dedicated IPs" tab *within* the pool detail page.
4. Click on an individual IP address to see its reputation metrics.
Previously, reputation was a column directly visible in the pool list view. This is a 4x increase in navigation for a fundamental monitoring task.
I've resorted to using the AWS CLI for most operations now, as the console has become a hindrance. For instance, simply listing all verified identities with their verification status:
```bash
aws sesv2 list-email-identities --query "Identities[?{Name:Name,VerificationStatus:VerificationStatus}]" --output table
```
The console provides no equivalent bulk, sortable view. Has anyone else developed workarounds or found hidden efficiencies in the new interface? Or are we all just accepting a permanent reduction in operational visibility for the sake of AWS's visual consistency?
—Alex
—Alex
I completely feel your pain on the template versioning clutter. I'm relatively new to managing our email infrastructure, and just this morning I wasted fifteen minutes trying to find which template version was actually live. The inline list is a nightmare for scanning.
Your point about the configuration set management being buried is one I haven't hit yet, but it sounds like I will soon as we scale up. Does the new interface at least offer any better tools for training someone new on the platform, or is the learning curve just universally steeper now? I'm worried about documenting these new paths for our team.
I've found that confusion about live template versions is a huge drain. A workaround I use is to prefix the active version number in the template name itself, like "Welcome_Email_v4". Not ideal, but it bypasses the clutter.
For training new team members, I'd say the curve is definitely steeper. The navigation is less intuitive, so your documentation will need to be very step-by-step, almost like a click-by-click map. Screenshots are going to be essential now.
Automate the boring stuff.
That naming workaround is a solid idea for keeping track of the live version. It's a classic case of managing state outside the system when the UI fails to surface it properly.
It makes me wonder if the migration path here is to stop using the SES console for template management entirely. If the workflow is already painful enough to require external naming conventions, maybe a shift to managing templates via the AWS CLI or SDK, driven by your CI/CD pipeline, is the better play. You can version everything in git and promote a specific version to "live" by deploying it.
Your comment about screenshots is spot on. The moment a process becomes "click-by-click map" territory, it's a sign the abstraction has failed and you're now documenting workarounds for the platform itself.
I hear you on the click depth, especially with configuration sets. It feels like they prioritized a consistent top-level menu across services over preserving the workflows power users had internalized. What's interesting to me is that the classic console was never exactly intuitive either, but muscle memory is powerful.
The loss of at-a-glance information is my biggest gripe too. I've started keeping key metrics pinned in a separate dashboard (CloudWatch), which kind of defeats the purpose of a consolidated "experience."
Have you sent this specific feedback via the "Feedback" button in the console? They actually do route that to the service teams, and volume matters. Sometimes a polite but detailed list of regressions from a long-time user can shift a priority.
~Harry
That "consistency over utility" trade-off is exactly the problem. They've standardized the menu at the expense of the workflow. You're absolutely right that the old console was no masterpiece, but it was predictable. You built mental shortcuts.
The part about CloudWatch dashboards is the real kicker. It's an admission that the console's new "unified experience" is less unified than the old one, because now you have to externalize the data you actually need to watch. It adds another system to manage, permissions to set, a dashboard to maintain. All because the primary tool can't surface three key metrics in a usable way.
I use the feedback button with the bitterness of a thousand stalled pipelines. I hammer it every time I have to click through four screens to verify a dedicated IP is warmed up. Whether it helps is an act of faith, but it's the only lever we've got.
Speed up your build
That's a good point about the feedback button. I haven't been using it, I just get frustrated and close the tab. I didn't think it actually went to the team, I figured it was just a generic suggestion box that no one reads.
If it does go to the service team, I'll start using it next time I get lost. Maybe if enough of us from smaller teams complain about the same click-depth issues, they'll tweak it. The "muscle memory" point is so true. I'm new to this, so I never learned the old console. But even I can feel how the new navigation adds friction just trying to find basic things like sending quotas.
Oh, the configuration set point hits so close to home. I just tried to link a new campaign to a warm IP pool last week and got completely lost in that exact sequence. The step where you have to find the "Dedicated IPs" tab feels completely disconnected from the actual action you're trying to take.
And yes, it absolutely flattens the workflow. You used to have a clear mental map: config set -> pool assignment. Now it's a scavenger hunt. I've started using the CLI for those specific tasks, which honestly feels like a step backwards for a visual console.
Yeah, that scavenger hunt feeling is exactly it. I was trying to explain the pain to our junior marketer yesterday, and the mental map point is perfect. Their confusion over how the pieces connect just confirms it's not intuitive.
It's ironic that the CLI becomes the better visual interface here. You can define your entire workflow - config set, IP pool, event destinations - in one declarative command or config file, which actually gives you that clear, at-a-glance view the console took away.
automate everything