3) they don't support text as a sender. In many countries you can have "MyCompany" as a sender instead of a generic number or short code. This makes the communication much more effective.
4) They claim the pricing will be different for transactional & marketing traffic, but it's not clear how , they just provide one only price list.
5) first 100 messages to US numbers free (each month). I expect they will be soon abused and they will retire this offering.
6) they don't support 2-way communication
7) SMS prices usually go down when volumes increase
> 3) they don't support text as a sender. In many countries you can have "MyCompany" as a sender instead of a generic number or short code. This makes the communication much more effective.
They do support it in some countries [1]:
> AWS.SNS.SMS.SenderID
> A custom ID that contains up to 11 alphanumeric characters, including at least one letter and no spaces. The sender ID is displayed as the message sender on the receiving device. For example, you can use your business brand to make the message source easier to recognize.
> Support for sender IDs varies by country. For example, messages delivered to U.S. phone numbers will not display the sender ID.
> If you do not specify a sender ID, the message will display a long code as the sender ID in supported countries. For countries that require an alphabetic sender ID, the message displays NOTICE as the sender ID.
Twilio's cost structure is probably dominated by SMS charges from telco operators and customer acquisition, not their AWS bill. So I doubt it, but feel free to cite data that shows I'm wrong. (I read their s-1 and I don't think it got into that granularity of cost accounting)
But they also spend a bundle with AWS... Amazon can reach the same pricing with the telcos, but will have lower infrastructure costs. Twilio would honestly be a good acquisition for AWS, but maybe Bezos feels like doing it himself.
I think it's a market where winning is about customer acquisition and retention, not necessary cost-control, though I'll grant that could become more important over time.
Can we contrast the aggressive Amazon platform vs customer dynamic with other cloud providers?
Why would a new company opt for Amazon at the risk of being copied and competed with as we're seeing with Netflix, Twilio, and numerous Amazon store vendors? Why not go with Google or Microsoft?
Netflix has a lot of customers, IMO because they developed great recommendation IP, they have a large content library, and have invested heavily into customer acquisition and marketing to build a consumer brand.
Netflix will use AWS infrastructure if it benefits their business and go elsewhere if it doesn't. The fact that the two companies compete in some ways is pretty much irrelevant to Netflix's (operational) decision of hosting provider.
You said "considering that Twilio hosts with AWS" as if that's the competitive disadvantage they face vs. Amazon. However, their cost structure would be the same if they hosted on Azure, Google Cloud, Rackspace, or anywhere else. So yes, Amazon may compete on price but I'm not seeing how Twilio being on AWS factors into it given that they need to incur server hosting costs somewhere.
Excellent news - I have been waiting for this for a while.
NOTE: Seems to be having issues sending SMSs to Australian mobile numbers - I've been tweaking and sending on the dashboard for a while now and nothing is coming through. Never mind - early days yet.
Am surprised at the cost differences between countries too - seems to be a lot more expensive than other third part SMS services I am using at the moment. (Comparatives - .009 cents for most US carriers, and 19 cents for most Aussie carriers!)
Oh, the US pricing is incredibly good. It is the overseas carriers that are a problem (especially here in Australia). The international pricing is 2x to 4x the price of some of the popular third party SMS service providers.
More like "Amazon AWS introduces worldwide SMS spamming". They changed their service from opt-in to opt-out. Even after the recipient opts out, the spammer can override and opt them back in against their will.[1] There's even an API for doing that in bulk.
Amazon's service seems to be one-way. They don't seem to support SMS receive at all. They just blast out crap from their own shortcodes.
There is still a lot of dependency by the carriers to adhere to this which most do not. They have no systems in place to differentiate. So while you may think your message is transactional, it may still get blocked for spam because the carriers aren't smart enough to know the difference.
When I did programmatic SMS for a project ~10 years ago, I just used SMTP and the email equivalent of the SMS address. I haven't done similar projects since then, so I'm curious if there is some reason that approach would no longer work.
In addition to having to know the carrier, the text message itself sometimes includes email-style metadata (like FROM, SUBJECT, MESSAGE, etc) that varies by carrier, so its difficult to control the experience. Its one of those things thats good for a personal project but not for a service that sends lots of text messages to users.
I didn't know this until I just tried it, but doing it over email supports replies (at least on AT&T), which is pretty cool.
Another problem is throttling and support. If you end up on the bad side of their spam filter it's tough to convince them to unblock you. They all have API's now that you can pay for access to, so they try and push you that route.
Many telcos throttle limit that route. I know of one company who used that method for sending texts from alarming to their oncalls. When they had a major incident and lots of pages went out, AT&T ended up blocking them from sending messages that way for a few hours, and they got warnings from the other major ones.
No, lots of alternatives already. And given the more complex AWS Console and documentation compared to alternatives I don't think it will make much difference to whether someone who wants to start spamming your phone will think "ah yes since I can now send SMS with AWS now is the time to start spamming"
Considering it does NOT look to support inbound or voice probably very little impact. (edit) i some how always forget the most important NOT operators.
Low impact in the short term, potentially huge impact in medium term (1-2 years). The pattern for other AWS services is that they will drive down price until they are low price provider and quickly close feature gaps. Adding inbound to SMS seems like a natural next step.
Also, SMS is a substantial part of Twilio's business. Even though Twilio has been adding new extensions to their product, the majority of usage is tied to a small set of API calls.
Twilio now has a company with a huge developer audience going straight after their core business. One that is willing to be very aggressive on price to win share.
Yes -- this is why it seems risky to invest in Twilio long-term.
Sure, they have the developers today, but if WhatsApp leaves, and Amazon can cross-sell more of their existing customers what they'd otherwise get from Twilio, that's a big problem long-term. Twilio has a bit of a moat with their carrier/provider relationships, but that won't hold up against Amazon's entry.
Time will tell, I guess. The stock has been going crazy the past few days, though
Really nice to have precise SMS delivery reports automatically pushed to Cloudwatch Logs. Makes it fit very nicely into the whole AWS offering (eg. automatically trigger a Lambda function to act upon a failed delivery).
Now, when would they make something like that that would go backwards? I want to strap a GSM module to a balloon, let it fly around the world and SMS it's position every so often.
I wonder if AWS uses a startup/company's reliance/traffic on their service to investigate what services to offer people. Using metrics for client services/infrastructure running equates to demand and possible revenue insights, (eg Twilio) could be used to dictate what to build next.
Sneaky, and would make me reconsider building on the platform if that were the case.
[edit] Makes sense, since we've seen them use this same method for their products and Amazon Basics™ line of products.
This'll be nice to receive SMS alerts on deployment or monitoring failures when using other AWS services. I don't think it compares to Twilio, since it seems to be more for alerts than for your main application use; you could cobble together something that creates a new SNS topic for each (user, phone number), but I'd doubt my ability to keep so many topics organized.
I'm surprised at the variability of pricing by different vendors in this space. I would have imagined they would all be competing on breadth of API rather than price.
An SMS to a number on a particular network provider should cost pretty much the same for all Messaging Platform Providers originating from the same countries.
..but why? How is this relevant to their business? I mean, I do understand that AWS and Amazon (the e-commerce) don't have anything in common, but why to focus on such a product that already exists (and that's even better)?
It's an addition to SNS, which is AWS's notification service -- you set alerts, and if a server goes down, or any other thing you set up a trigger for, it messages you. It's just expanding to new markets.
Their goal is the be the infrastructure of the internet. This is an infrastructure product. Yes there are competitors, but if you're already using other AWS services, there's a good chance you'll use their solution for any given problem.
Great news! Amazon will get into any kind of service that is part of an infrastructure. There are a one-stop shop of building blocks required to build a web service. Their inventory is only going to get diverse and bigger.
Much more expensive in Europe (e.g. major networks in Poland Twilio $0.03467, AWS $0.03897 - 0.07711)
https://www.twilio.com/sms/pricing
http://aws.amazon.com/sns/sms-pricing/