What actually happens when you send a one-time code, and why Australia's 1 July 2026 deadline changes the AWS side of it
Most of us have typed a 6-digit code into an app at some point. It's such a routine moment that nobody really thinks about it, until you're the one building it, and "just send a text with a code" turns out to hide a surprising number of decisions.
I recently built OTP delivery on AWS, right as Australia's new SMS Sender ID Register started reshaping how that delivery actually works. It ended up being a good example of how a small feature can touch cost, infrastructure, and compliance timelines all at once. Writing it up here in case it saves someone else a bit of time.
What's actually happening behind that text message
As a user, the flow feels like one step. Type your number in, get a text, type the code back. Underneath that, there are really four separate jobs going on:
- Generate. Something creates a short, random, hard to guess code.
- Store. That code gets saved somewhere, tied to your session, with an expiry, usually 5 to 10 minutes.
- Deliver. The code gets sent to you, almost always over SMS.
- Verify. When you type it back in, whatever generated it checks your input against what it stored, and checks it hasn't expired yet. The first two and the last one are just application logic. Nothing AWS specific about them. The interesting engineering decision is really in step 3. How does the SMS actually get delivered, and who owns that pipeline?
The AWS side has more options than you'd expect
Search "how to send SMS on AWS" and you'll find a handful of overlapping services, and it's not obvious at first how they relate to each other.
Amazon SNS is historically the go-to for "just send an SMS," using its Publish API. Since late 2024 though, SNS's SMS sending actually routes through AWS's newer messaging backend under the hood, so it's really more of a thin pub/sub wrapper than a separate delivery engine.
AWS End User Messaging (SMS) is the direct, current API for sending SMS. You get full control over origination identities, configuration sets, and two way messaging.
AWS End User Messaging Notify is a newer, managed layer on top of the same service, built to remove the setup friction of registering your own number.
There's also an OTP specific API pair (send and verify) where AWS generates and checks the code for you, for a fee per successful verification. If you already have your own generate and verify logic, and most teams do, this one's easy to skip.
So once you rule out reinventing SNS or paying AWS for OTP logic you already have, the real decision comes down to two paths. Register your own number, or use Notify's shared, managed identity.
Own number vs Notify: the actual trade off
Registering your own number gets you the lower per message cost and full control over branding. The trade off is carrier registration, which takes real time to clear, plus a small monthly lease fee for the number itself.
Notify skips that registration wait almost entirely by using a shared, pre approved sender identity, with fraud protection built in. You pay a premium per message for the convenience.
At low monthly volume, the fixed cost of leasing your own number eats up most of the savings, so the two options land close together in price. As volume grows, owning the number pulls ahead, since that fixed lease cost gets spread across more messages, and the gap can turn into a real number depending on scale.
So it's less "which is objectively better" and more, do you need to move today, or can you afford to wait for the cheaper path.
Here's roughly how the numbers play out at different monthly volumes, based on standard SMS pricing to Australian numbers plus a typical long code lease fee.
| Messages per month | Own number | Notify |
|---|---|---|
| 500 | ~$42 | ~$43 |
| 1,000 | ~$62 | ~$85 |
| 2,000 | ~$102 | ~$170 |
| 3,000 | ~$142 | ~$255 |
At 500 messages the two are basically a rounding error apart, since the fixed monthly lease on your own number eats most of the saving. Past a thousand or so, the gap opens up fast, and by 3,000 messages you're looking at over $100 a month difference. Worth running your own numbers before deciding, but this is the shape of the trade off.
One thing I still can't fully explain: I hit ACCESS_DENIED_CONTACT_SUPPORT trying to create a Notify configuration through the console UI. No clear reason given, no obvious account issue. Out of curiosity I tried creating the same configuration through the CLI instead, and it went active immediately, no error at all. I don't have a confirmed explanation for why the two paths behaved differently on the same account, but if you hit that error in the console, it's worth trying the CLI or API directly before opening a support case.
The wrinkle: Australia's new SMS Sender ID rules
This is the part that actually raised the stakes for me. Australia is rolling out the SMS Sender ID Register, run by the ACMA, aimed at stopping scammers from spoofing trusted brand names in text messages. From 1 July 2026, any branded sender ID, the name shown at the top of a text instead of a phone number, has to be registered, and telcos are required to check registrations before carrying that traffic.
The practical effect is that unregistered sender IDs now get labelled "Unverified" on the recipient's phone, and ACMA has been telling businesses to apply as early as possible since last minute applications may not get processed by telcos in time.
This is where the two AWS paths actually diverge, and it's worth being precise about it, since it changes the trade-off more than I first realized.
If you register your own number and send under your own brand's sender ID, that sender ID is exactly what the ACMA rules are about. Skip registration, and your customer sees "Unverified" at the top of the message instead of your brand name, grouped together with other unverified traffic, including actual scam texts. For an OTP, that's a bad place to land. The exact moment you want a customer to trust the message is the exact moment it now looks like everything they've been warned about.
Notify works differently. The sender identity that shows up on the recipient's phone isn't your brand at all, it's AWS's own shared identity, AWSNOTIFY. Your brand name is something you configure, and it appears inside the message body text via whichever template you pick (AWS gives you a handful of pre-approved ones to choose from), not as the sender ID field itself. So Notify doesn't get flagged "Unverified" the way an unregistered branded sender ID does, you're not trying to show your own brand as the sender in the first place, so the ACMA registration question for branded sender IDs doesn't really apply to it.
That's a real point in Notify's favor beyond just skipping the registration wait, it also sidesteps this specific trust-signal risk entirely. The trade-off is the flip side of the same thing: your customer sees "AWSNOTIFY," not your business's name, at the top of the text. Whether that matters depends on how much brand recognition in the sender line itself matters for your use case, versus having your name appear in the message body instead.
Separately, telcos and message providers that don't participate in the register at all are not permitted to carry branded SMS traffic from 1 July 2026. If you go the own-number route, it's worth checking with whoever is actually carrying your SMS traffic, not just assuming registration is someone else's problem, since a non-participating provider can mean messages blocked outright, not just relabelled.
So the real shape of the trade-off: own number gets you full brand control (your name as the actual sender), at the cost of a registration process now carrying a hard regulatory deadline. Notify skips both the registration wait and the "Unverified" risk entirely, at the cost of your brand appearing in the message text rather than the sender line.
A rough way to think about it
If I had to boil it down:
If you're pre launch, testing, low volume, and need to move fast, a managed or shared identity like Notify is the pragmatic choice. Don't burn weeks on registration for a feature you're still validating.
If you're established with predictable volume sending to Australian numbers long term, start the sender ID registration early regardless of which path you pick, since the 1 July 2026 deadline applies either way if you want a branded sender ID.
If cost matters more than speed at real scale, own your number once volume justifies it. The lease fee stops mattering and the per message savings add up.
The takeaway
"Just send an SMS" is one of those tasks that looks like a five minute API call and turns out to be a small system. A generate, store, verify loop you own, a delivery layer with real cost trade offs, and now, at least for Australian numbers, a compliance deadline sitting on top of all of it. Worth mapping out properly rather than defaulting to whatever the first tutorial shows you.
References
AWS End User Messaging, SMS and Voice documentation: docs.aws.amazon.com/sms-voice
ACMA, about the SMS Sender ID Register: acma.gov.au/about-register
ACMA, sending text messages with your business or organisation name: acma.gov.au/sending-text-messages-your-business-or-organisation-name
ACMA, registering sender IDs: acma.gov.au/registering-sender-ids
Researched and drafted with help from Claude (Anthropic).
Top comments (0)