Just be sure to stay mindful of the costs of being on multiple providers. In this example, it doubles your outage footprint, because a regional outage on either provider would disrupt your service. It will also moot some of your cost savings, as you can't take advantage of the free local transfer (e.g. EC2 > Elastic Transcoding > EC2 is free; GC > Elastic Transcoding > GC is not).
Unless there's a specific feature that you need in GCP, AWS is a safer bet from scalability, stability, support and cost.
GCE has an edge on performance, per minute billing, custom machine types, and some datacenters in areas AWS doesn't cover, however they're learning how to be a public cloud, so you will run into beta level bugs, scalability issues, support issues (they also limit how many people can open a ticket in your org), and stability problems. If you do go GCP, make sure you have a rep and a high level support contract, otherwise it's going to be hard when you run into issues.
Nice, I really like that way of putting it. The promise of the Cloud is, indeed, that it is supposed to abstract you from that, but Reserved Instances reveal what is actually happening behind the curtain.
k8s master, or any number of internal tools.
There is no harm with the discount. The harm is only with lock in. Once you reserve instances, you can not change the type (different CPU / memory ratio), region or the number of instances. Once you reserve, you have to pay for your instances 24x7, whether you use it or not. If you require more capacity than reserved, you need to pay the full rate. If you require less capacity, then you need to pay for the unused capacity. You don't have all these headaches with Google Cloud pay per go and automatic discounts. You simply use as many resources as you want and you get the discounts automatically.
There's also a handy-dandy TCO calculator that further explores these dynamics here: https://cloud.google.com/pricing/tco
Let me know if any other details would be useful!
One of the most underrated features IMO in AWS is being able to connect services without worrying about passing around, rotating, expiring, etc. any credentials. For instance if you use any of the client or CLI libraries on an EC2 instance, it automatically uses the instance profile credentials. It can also be used to solve the bootstrapping problem of a new instance that needs access to secrets.
(That said, it seems like a huge oversight to me that AWS itself doesn't offer a dedicated secret store to further take advantage of this, since it's something every web app needs. And actually writing the IAM policies can be a bit of a nightmare, it's a whole skill in and of itself to learn to find the 2 or 3 separate docs pages you need to cross-reference to be able to write a policy).
Yes, Google Cloud can manage secrets for you. For example, you can spin up an instance and let Google Cloud handle SSH key creation, copying it to instance, auto-rotating it periodically, deleting it when a user is removed from project, connecting to services from Cloud instances is taken care for you.
If you build inside AWS, you have to pay for cross-region bandwidth like transferring data between the east region and the west region.
If you choose Google Cloud, cross-region bandwidth is also free!