> Please. Even for an advanced VPC configuration, you're looking at 1-2 hours tops for setup.
We use DynamoDB. A lot of it. It is a non-trivial setup to get a dynamic, scaling solution to route traffic efficiently to the DynamoDB endpoints. Our SQS traffic sometimes also experienced extreme latency when we would send large groups of messages.
So forgive me if I greet your derisive tone and silverbacking with skepticism; I've got a product in the market already. I have correspondence from the AWS support explaining that it is in fact very difficult to operate at the scale we want to with some AWS Services that aren't supported, and the S3 connection was also not trivial. This is especially so if you're managing multiple discrete apps that don't coordinate usage or bandwidth spikes, as is common in large enterprise settings. Which is, ultimately, what we're doing.
> Complex tools are always going to have a learning curve.
There is no justification for the current mess that is Amazon's documentation for the VPC feature set. The only reason they get away with it is that AWSClassic is a giant band-aid which will be grandfathered onto customers with scaled products.
Arguing that things like Heroku or Digital Ocean or managed Kubernetes are bad and EC2 is good simply because it uses a hypervisor model instead of a container model is grandstanding and nonsensical, plain and simple.
The startup world has 0 use for this kind of thinking. What matters is how quickly you can deploy, and how efficiently and inexpensively you can scale if you get a hit. Everything else is ego, and useless in this environment.
There are systems that need AWS's model, but they're for specialist products. The vast majority of products can and do deploy in DO or Heroku just fine. And if they're sustaining people and serving customers, who are we to judge?