One big thing not mentioned here: the massive collection of managed services AWS gives you at no cost.
The biggest example is probably IAM, which makes it easy to control which servers can take what actions on which other services. And can also be integrated directly into external tools like Vault.
Want to use service discovery? No need to set up Consul/Istio/etc., just use the managed service. Same with load balancers, and VPCs, and SSM, and route53, etc.
Sure, in 2020 none of those services are that hard to replicate pieces of, and open source tools abound. But setting up those tools all takes time.
Only other nit is that the article makes it sound like Terraform and IaC is meant to abstract away AWS vs GCP such that one terraform module _could_ be deployed to either just by changing some string value from "AWS" to "GCP". I don't believe any serious (and good) efforts are being made in that space, and you won't find any popular modules like that on https://registry.terraform.io/.
I can't tell if your comment is a particularly rude way of picking the nit that "nothing is free, the cost (e.g., of IAM) is built into other services" or if you really find it absurd that the nominal price of many AWS services is $0 or something else entirely.
I apologize for my rudeness. I wasn't adding anything with that comment. I did find the parent comment jarring, as if it was willfully ignoring the downsides in an effort to promote AWS. That's in a comment thread that otherwise seemed like a candid discussion of the pros, the cons, and how it's a good deal for some but a worse deal for others.
Of course, the cost is built into other services. As pointed out, AWS can get very expensive for many use cases, and that's exactly what you're paying for: access to managed services.
Beyond that by developing on AWS you are taking steps to lock yourself into using their system - your configuration isn't portable to other services. So the time/manpower you spend configuring AWS-specific things is another cost associated exclusively with its use.
You don't seem to understand what a 'service' is. In particular, you seem to think a service is something that operates on resources called 'instances'. Here's the Wikipedia definition of a web service:
> a server running on a computer device, listening for requests at a particular port over a network, serving web documents (HTML, JSON, XML, images), which serve in solving specific domain problems over the Web (WWW, Internet, HTTP)
Clearly IAM is a service.
Further, the service needn't operate on resources called "instances" in order to provide value--few AWS services offer "instance" resources and yet they deliver value to customers and are consequently priced. IAM isn't priced directly, but rather the operating cost for the service is built into other AWS services, presumably to encourage people towards security best-practices (charging for IAM might dissuade users from building securely).
Apologies for the confusion! I picked BeyondCorp as there seems to be a number of references to it as a more general-cloud term than anything Google Cloud specific.
At Transcend, we use a bastion host (like others have mentioned). The key difference that we do that I don't think has been covered is that our bastion only makes outgoing connections, and has no open ports to the world.
Using the AWS SSM managed service, we can create bastions that have no ingress at all.
This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:
1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.
2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.
I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith
For sure, VPNs will always be used. I think it'll take a BeyondCorp SaaS company to really take off (or have it become a more "Managed"auth method from the big cloud providers).
At Transcend we are able to do it because we had an early focus on protecting our internal apps, but obviously it's a lot harder to migrate hundreds of services than to start out with a newer approach.
I loved not having to use a VPN back when I worked at Google though, and am glad to see that the open source world is starting to offer some tools to play around with.
This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:
1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.
2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.
I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith
The library discussed is available on Github here: https://github.com/transcend-io/secret-value and is on npm to download via `yarn add @transcend-io/secret-value`