5 ms·
Back when I worked at AWS and t1s were still the big thing, we had a policy of telling customers to never run a production site on a t1.micro . I would say the
by sudosteph 9y ago
Back when I worked at AWS and t1s were still the big thing, we had a policy of telling customers to never run a production site on a t1.micro . I would say the same about t2s for the most part. AWS needs to do a better job of putting big red warnings all over the docs or console or something. Even though the details really are all there in the docs, it's very easy for people to get lulled into a sense of false security if they're following along with a blog post or just not going over the docs in depth. But really, reading the service docs in depth, does pay off.
Totally agree that it should not be "general computing" categorized though. That category in general is too vague to be useful really. They should clearly demarcate between production service hosts and development-oriented instance types.
- jedberg 9y ago> we had a policy of telling customers to never run a production site on a t1.micro It's perfectly safe to run a production site on a t1.micro, as long as you follow good principles regarding monitoring and autoscaling. You'd be a fool to run a production website on any instance type without those failsafes, but with them in place, a t1/t2.micro is no worse than any other. And in fact, since they boot so quickly, they are really nice with auto-scaling.
- sudosteph 9y agoI should clarify, "single t1.micro". Some customers just really refused to do any autoscaling config at all, so best we could do is show them how to backup and restore. But it's true that t1s really were very inconsistent in performance compared to the other families. T2s may be better, but I don't have insight on that.