Hacker News Reader

Comment by jalino23 | Hacker News Reader

this is why as a frontend developer. Im scared to deploy to aws. there so many things in the dashboard to get wrong if you don’t know what you’re doing. and I don’t know what I’m doing. I stick to digital ocean and netlify

View on HN

I agree. The AWS interfaces are poorly designed, difficult enough to use well that "mistakes" are statistically guaranteed to happen.

It is laughable to hold those who make S3 buckets public accountable yet underplay the contribution of interface design. It's as if the NTSB had a report template with only a single checkbox for "pilot error".

S3 buckets are private by default. I'm pretty sure it warns you very heavily when making items public too.

Yeah, AWS lets you do things--especially related to billing--that can really burn you if you make a mistake or don't know what you're doing. But making S3 buckets public is something they've really put guardrails on over time.

I’ve always found the main issue is not how easily you can make a bucket public, it’s knowing how to utilize a private bucket to serve assets or media in the first place.

They are now, but IIRC that was not previously the case.

S3 Buckets have _always_ been private by default.

S3 buckets are now very clearly labelled as being public, perhaps even private by default.

Not so long ago this wasn't the case and various grey hat services would let you explore public buckets via a nice interface / API. What you could find was pretty shocking.

The idea of "don't use it if you don't know how" still applies though. In this world so many things can go wrong if you don't understand what button does what but that's not an excuse imho - AWS isn't designed for non technical people.

This used to be worse than it is now. Today there’s all kinds of warnings about buckets that can be publicly accessed. It takes quite a bit of work to make one public, not something you’d do without knowing anymore.

1) I think your opinion here is 3-4 years out of date. Check out the modern interfaces.

2) at a bank's scale it should not be using the console for anything in production.

Banks also use Excel and VBA macros for a lot of things that deeply scare me. It feels like the planet’s financial systems are kept together by spit and prayer.

Never ever use the dashboard to configure your production deployments, on any cloud. From the moment you create the account, use automation (Terraform, provider-specific stuff like CF, whatever) to create resources. The learning curve is not that big, and you will have certainty about, and control over, what is running in your account.

Does AWS have a way to export your infrastructure to a terraform file? Like if I start doing things via the dashboard and later want to use terraform?

Terraform has the ability to import it

In my experience you need to find each resource one by one, and then import each one. Sometimes by name, some by ARN, some by something else. The import approach is time consuming.

No, but Terraform has a way of importing it (via the `terraform import` command), although it is clunky to use for an account with lots of resources.

CloudFormation (the AWS-provided IaC product) may have something, though.

I saw "aws-prod-infrastructure" and "terragen" on the AWS blog recently, which are claimed to solve this. I haven't tried them.

I've used terraformer. It generates a bunch of HCL that's useful but verbose, and you can target certain kinds of resources with it. It'll do in a pinch but can't say I loved it.

Every time I use Terraform I want to make a Lisp dialect that describes cloud infrastructure.

emacs probably has one… :-p

Emacs is the best OS I've ever used.

I disagree. If you don't fundamentally understand how the services work on their own, or how to repair them outside of your selected framework, you're setting yourself up for failure down the road.

You'll also have very little visibility in how to effectively test your configuration and ensure the security you _think_ you have is actually in place and functioning correctly.

I'm not suggesting any type of "framework" (which suggests inversion of control). Terraform, CF, etc make the same API calls that the console does, they just keep state. Whether you understand the services is orthogonal to whether you use automation to deploy them.

Reply on news.ycombinator.com