Best Practices in AWS Management

You see this stuff all the time:

* Person starts $consultingCo

* Person creates website for $consultingCo

* Person adds "blog" section to website

* Writes a few vague, high-level pieces like this

* Spams them everywhere

* Almost all new business still comes from Chamber of Commerce mixer

* Person loses interest and stops updating "blog"

It reads like it's trying to get the attention of a CIO at some Midwestern Widget factory.

I'm always on board with idea of spreading knowledge and ideas around. High-level, introductory pieces are also good.

BUT... You've got to know your audience. The typical HN reader is not going to find an article like this novel or useful, and might even find it off-putting. The type of people you want to read this article are probably not avid HN readers.

All that aside, you've also got some pretty dangerous generalizations like:

> "Is my data just key/value pairs? If yes, use DynamoDB. If no, keep going."

Yikes. I really hope deeper considerations are being paid to choosing a database technology beyond "Welp, it's just k:v, let's use NoSQL!"

If you have some novel, technical insight into utilizing AWS, please share it here. This article does not qualify.

I think it is very hard to have such a list without over-generalizing or writing a book.

The piece could use some rework. The idea is nice, a series on best practices, but the execution needs to be looked at.

P.s. AWS has a whitepaper on the subject which is an OK read for starters in the area. I would redirect any reader of this post to the collection of whitepapers by Amazon. They also have the same for security. They cover the basics.

[0] https://aws.amazon.com/whitepapers/architecting-for-the-aws-...

- dismissing DynamoDB unless you're doing "just key/value pairs" is IMO too reductive. You can go a long way with DynamoDB, and for smaller tables it has the most bang for your bucks (plus it's dead easy to set up and configure)

- building and maintaining your own DB cluster should not be your first move, even if you think you need "a high level of engineering". Start with a managed RDS instance and only if you reach its limits should you consider rolling your own (unless, of course, you already have an exquisitely tuned DB that you need to migrate to AWS. But honestly, as long as you're migrating, shouldn't you take the opportunity to move to something with less maintenance?)

- managed RDS is fine, but, once again, DynamoDB will frequently be cheaper.