This appears pretty superficial and it gets many things wrong.
> Choose between [DynamoDB] on-demand option (no capacity management) or provisioned option (cheaper).
It's very, very easy for provisioned capacity to be more expensive than on-demand. You need to overprovision because, if you exceed the provisioned throughput, you will get throttled and your application will suffer. Scaling up and down is a slow, opaque process, and you're only allowed to do it something like 5 times per day. If your workload has any idle periods, you're just burning money.
> Avoid using S3 for static web hosting (No HTTPS)
I won't argue that S3 is ideal for static web hosting, but "avoid" is pretty strong and IMO not warranted.
> Do not use AWS Lambda as a general EC2 host
What does this mean? As general compute? This is too simplistic a judgment. Lambda is a versatile service and can be useful in many situations.
> Kinesis: unlimited consumers
No, Kinesis is an extremely limited service. 5 reads per second per shard. In my experience, if you put even two consumers on a stream, you will start to see throttling. The official solution is to fan out to multiple streams. Hacky and super expensive.
> Kinesis 30x cheaper than SQS
This is hilarious. Maybe it's true for some workloads. In my experience, Kinesis is incredibly expensive and SQS is not.
> The official solution is to fan out to multiple streams
Not anymore. Enhanced fanout allows up to 20 consumers, doesn't count against read limits and has lower latency than polling.
> It's very, very easy for provisioned capacity to be more expensive than on-demand.
Reserved capacity will beat on-demand pretty handily, even with massive overprovisioning. Assuming a 50% target and a 16 hour daily duty cycle, reserved provisioned is 20% the cost of running on-demand.
Thanks, I misspoke about fanning out to multiple streams. Dedicated stream consumers are still a hack. They're also expensive and have limitations as Lambda event sources. Kinesis is a service that needs to be used very carefully. It's riddled with landmines for cost and performance.
Regarding Dynamo: I'll echo plexicle's experience that switching to on-demand was an immense cost savings (these were tables that were not being used often, many of them in dev environments).
> Reserved capacity will beat on-demand pretty handily, even with massive overprovisioning. Assuming a 50% target and a 16 hour daily duty cycle, reserved provisioned is 20% the cost of running on-demand.
I don't have the math on hand at the moment.. but switching to on-demand for us resulted in HUGE savings. We weren't overprovisioned either, but we were kind of spiky (in fact we were underprovisioned for a lot of the day).
Also, single consumer for SQS? Completely wrong. It is a common pattern to autoscale a group of workers based on the number of visible messages in a queue. Hundreds or thousands of workers are not out of the question. SQS has no practical limit to its ability to scale.
It seems like they're saying "Don't use this for generic services, only use it as an integration with other AWS services" to which I would say, "What?"
If I recall, https://acloud.guru for example is hosted entirely using Lambda, API GW, S3 and some other AWS services.
> Avoid using S3 for static web hosting (No HTTPS)
Ya, "avoid" is a strong word. I use S3 for tons of static web hosting, because it is exceptionally cheap and I don't have to worry about patching CentOS/Apache/MySQL/PHP and all the other binaries/daemons that I used to. I know how to, I just would rather not when S3 is a couple pence per GB.
That's great if all my company makes is static websites, but if we have a bunch of other CI/CD for other projects, I'm not going to introduce a new tool for people to use to make an already simple pipeline simpler.
Setting up CI/CD via CodePipeline for a static website is trivial. Beyond that, Amplify Console offers an extremely easy experience deploying static websites, with built in blue/green deployments.
THIS! I too was taken aback by the comparison of SQS and Kinesis. In my experience kinesis is significantly more expensive and significantly harder to scale. The only reason you should use it is if you need the throughput and delivery guarantees.
I'm not sure where the article author is going with this, but the official way to host a static web site on S3 with HTTPS is to use ACM and CloudFront:
> Choose between [DynamoDB] on-demand option (no capacity management) or provisioned option (cheaper).
It's very, very easy for provisioned capacity to be more expensive than on-demand. You need to overprovision because, if you exceed the provisioned throughput, you will get throttled and your application will suffer. Scaling up and down is a slow, opaque process, and you're only allowed to do it something like 5 times per day. If your workload has any idle periods, you're just burning money.
> Avoid using S3 for static web hosting (No HTTPS)
I won't argue that S3 is ideal for static web hosting, but "avoid" is pretty strong and IMO not warranted.
> Do not use AWS Lambda as a general EC2 host
What does this mean? As general compute? This is too simplistic a judgment. Lambda is a versatile service and can be useful in many situations.
> Kinesis: unlimited consumers
No, Kinesis is an extremely limited service. 5 reads per second per shard. In my experience, if you put even two consumers on a stream, you will start to see throttling. The official solution is to fan out to multiple streams. Hacky and super expensive.
> Kinesis 30x cheaper than SQS
This is hilarious. Maybe it's true for some workloads. In my experience, Kinesis is incredibly expensive and SQS is not.