This site covers cloud platforms, networking and web hosting from the point of view of someone who has to operate the result rather than only choose it. The topics follow the categories the site itself is organised around, and the emphasis throughout is on decisions that are expensive to reverse.
Sizing is the first of those. Most small deployments are provisioned from a guess and then never revisited, which produces two failure modes at once: instances too large to be economical and instances too small to survive a modest traffic spike. The useful approach is to measure the actual working set, choose the smallest instance that holds it with headroom, and set an alert on the resource that will run out first. Memory is usually that resource, and memory pressure is the failure that presents as mysterious slowness rather than as an error.
Networking is where cloud platforms differ most from a single server. Traffic between regions is billed, traffic leaving the provider is billed at a higher rate, and traffic within a region is often free. A design that moves large volumes of data between regions can cost more in transfer than in compute, and that is discovered on an invoice rather than in a benchmark. Establishing which flows are billable before building something is considerably cheaper than restructuring it afterwards.
Managed services are worth evaluating on operational burden rather than on price alone. A managed database costs more per month than the same database on a plain instance, and it removes backups, patching, failover and the risk of losing the only copy of the data to an unattended disk failure. For a small team the managed option is usually correct, because the alternative is not cheaper, it is simply unbilled work that gets skipped until it becomes an incident.
Hosting a website raises a narrower set of questions. Terminate TLS with a certificate that renews without intervention. Serve static assets with cache headers long enough to be useful and a versioned filename so a change is picked up immediately. Put the site behind something that absorbs traffic spikes, because the cheapest way to survive attention is not to serve every request from the origin. And keep the deployment reproducible, so that recovering from a lost server is a documented procedure rather than an act of memory.
Backups deserve a separate mention because they are the control most often assumed and least often tested. A backup that has never been restored is a hypothesis. Restoring one, to a throwaway instance, on a schedule, is what converts it into a fact. The restore is also where the gaps appear: a database dump without the uploads directory, an archive encrypted with a key nobody recorded, or a snapshot of a filesystem that was mid write.
None of the above depends on a particular provider. The providers differ in naming, in billing granularity and in which managed services they offer well, but the operational questions are the same everywhere: what runs out first, what is billed, what happens when a component fails, and how long recovery takes when it does.
A last point on complexity. Every additional component in a deployment is another thing that can fail, another thing to patch and another thing to understand at three in the morning. A single well configured server with automated backups and a documented rebuild is more reliable in practice than an elaborate architecture nobody has exercised. Add components when a measured limit forces it, and prefer the boring option each time there is a choice, because the boring option is the one that will still be understood in a year.