Saving on egress switching from AWS to Hetzner
blog.fleetdm.com
blog.fleetdm.com
Startup: use <aws|azure|gcp> because it's quick to get started. It's easy to scale it up 100X in 5 minutes for when you make it big. And it provides a long list of easy to use services that are overpriced per use, but which free you to focus on your business rather than complex DevOps.
Then once you scale to the point that you're comparing your salaries and your ops cost, you find smaller services to handle the expensive part of your business. Ones that do exactly what you need, not much else, and charge accordingly. Maybe they're self-operated, or maybe they're other companies with a narrow focus.
Then you write a blog post about how everyone is crazy to use <cloud> since it's so expensive, and you don't know why you ever thought they were a good idea.
How many companies actually shift their infra vendor?
I mean it makes sense in a way and I'm not saying it is a bad thing, just a pattern I've noticed.
E: hehe there it is, they’re already here
Seeing some of the replies to tweets that appear here I’ve lost faith in the HN audience’s ability to observe and discuss
Pattern, not problem :)
Let's also be realistic here: CloudFront is a good solution if you need a file to be served over CDN with low latency in multiple regions. Raw s3 or just a web server is much cheaper if you don't need low latency over multiple regions.
US offerings being way more overpriced than EU alternatives also boils down to the much larger capital/war-chest US tech companies have at their disposal to spend on Ops to conquer a market, a fact reflect in those prices but also in things like dev salaries, office equipment, etc.
EU offerings are better priced because most EU companies, who aren't bankrolled by some mega VC fund, cannot afford to pay US levels of pricing.
Using Cloud services that are obviously more expensive than self-hosted options reduces both numbers- less time to launch stuff, but less money. The point is that in early-stage startups, the costs are so low that paying an order of magnitude more for Operations may not move the second number by very much at all, since most of the money is paying for developers.
The machines were there fully paid. But w aws I’d be up in 10 minutes w a lot less arguing . I’m convinced this might be part of AWS edge in big players
Then you get into serverless and suddenly they can’t log into production anymore, and they have to instrument their code, and work within finite resources - all that stuff they ignored in college about manipulating datasets larger then core memory are suddenly relevant.
When we did our transition to serverless we found that the people who complained the loudest about their traditional servers being mysteriously corrupted were actually the same that had obtained admin rights “so they could work faster” and were going into the servers and blowing away configuration files, altering permissions, and making other changes. Once there was no more ssh and no more root privileges our outages dropped two thirds. Today it’s mostly third party outages impacting us and people deploying untested code to production.
What we did find is our operational expenditure over three years tripled. So basically capital expenditure.
I’m not sure how they warped that into self congratulatory success.
The people complaining now complain that it turns out the promise of total automation was a lie. None of it is very robust and all of it is painful.
From a maintenance perspective, it's brilliant. Over time, cruft accumulates on my VPSes however disciplined I intend to be when I spin one up. Now, I no longer have to remember all of the ugly hacks I had to implement to get a particular new app I wanted to try out working, I just deploy and it's done.
Because compared to a staff of 50 doing anything the costs of an ec2 instance for a week are irrelevant?
Because finance already has AWS in system as a vendor?
Because pricing is public?
Because costs hit your budget not ITs so you have more authority?
Orgs can easily spend 5x what it would cost internally on AWS because of friction avoiding factors like this.
You can ask the cloud to deploy a container to Kubernetes. You can rent a VM with Hetzner. You can rent rack space in a data center. You can build your own data center. You can build your own server hardware.
Depending on the scale you operate, you'll draw the line somewhere where it makes sense to you (which may change over time).
Dev teams will still operate best when they can deploy containers to Kubernetes and without having to design their own server hardware. You now need to build abstractions in house. Maybe you can sell these to other people? Congratulations you are now a cloud provider.
Jeez really? We have like, binaries deployed to machines over here.
It may not be fatal to your business; it's not going to be a top 3 reason you succeed or fail! But it does make a difference.
To stay in your metaphor, moving faster is not a guarantee to arrive at your target earlier. As long as everything works fine, using k8s is great. When you have to dig deep to solve a problem, a stack with less layers might be a huge advantage.
Realistically I wish someone would just write an orchestrator that runs Go processes and nginx and glues it all together.
"Marketing" as you said, made this concept of "container", but I think using the words "process" and "namespaces" is still ok.
I'm not saying "marketing" as to say it was coined by non technical people, but rather that it's a way to "sell" the feature. Like you go see your manager and say "I'm going to containerize the application" vs saying "I'm going to add some isolation settings to the process"
Not quite what you're asking for but you can get close, on bare metal, with:
- ssh to set up a systemd service, scp to deploy your binary, then ssh again to restart your service
- dokku (containers are optional) with its cli
For the first option, once you've set up nginx on the server you can easily automate the addition of a new systemd service for a new app with a simple shell script. That done, it is a matter of less than a minute to add a new app and even quicker to update and restart an existing one.
For the second option, it is installed with a single bash command and supports Heroku build packs which means for many systems there's virtually (or exactly) no config needed. Just run the cli from within your app folder. If you do want containers they are automatically found and deployed too.
I've done most deployment methods from the simplest (above) through to complete Terraform builds, and once they are automated all that matters is that the method you choose supports your needs. Go for the simplest option that does that.
As others have pointed out it is relatively easy to deploy small k3s clusters on Hetzner Cloud.
I can confirm that. I've been running a few servers with them and my experience is that the older ones had a failure every 2-3 years. Usually it was a disk, sometimes the power supply. Once 2 of 3 disks failed but I managed to rebuild the array (it was the HDD era so it took several hours), no data needed to be restored from backup.
But since 2018 I had no failures at all. And I'm happy to see their ecosystem grow.
If I'm targeting AWS, Azure, etc. Then I'm going to leverage their services in a lot of cases. Wether it's AWS Dynamo DB, or hosted PostgreSQL, there are places you will save in either resources or personnel.
A set of Dokku servers behind a load balancer can go a long way. Kubernetes further still. Taking the issue of DB management, static assets or backups goes a long way to freeing up time to make solutions without buying into lockin too much.
Setup one that doesn't eat your wallet is what makes it hard.
Granted, thinking about this up front is ideal, but it’s better to start an mvp and build from there than to be paralized by perfection at the outset and not build anything at all.
It’s totally overkill for the article’s use case, but it enables many cool things that need sustained bandwidth, and has been pretty fun.
Remember to set them crypto mining so you're kept warm at night.
Also agreed with sibling comment that 1Gbps is pretty slow nowadays. Do you know if that can be customized?
(And yeah, 42U.)
We used the extra space for spare parts.
Is this so different from the cloud? Even an EC2 instance should be assumed to be a single point of failure and you also need multiple (preferably in different AZs or regions) if uptime is important.
Old and boring things, DNS, load balancer, yada-yada.
If you save thousand(s) it is still could be cheaper.
If you want to save some money write the scripts yourself and run them in a cron job. Took me a couple hours and I'm no sysadmin.
To me the best thing to do is move all your services into k8s and automate you DB (use open source). Then you can move to any provider when you realise the cloud pricing is shit.
I went to their home page to try and find more information about colo pricing, but it's all hidden behind a contact form.
Their site design seems very 1998, makes me feel really nostalgic.
Wonder what if Netflix turns around, and blue oceans [0] its video delivery infrastructure [1][2], like Cloudflare did for text/html. We do know that video has all but eaten up the attention that text/html once had on the Internet [3]
[0] https://en.wikipedia.org/wiki/Blue_Ocean_Strategy#Concept
[1] https://news.ycombinator.com/item?id=28584738
Storing a large number of "cold" or "long tail" bytes is a different physical problem when it comes to storage and IO. And that's also the exact problem you have when hosting lots of third party content (or apps, or lambdas, or anything else). There you're also optimizing for bytes stored:served, but have to place it on cheaper media and with less duplication to make the physical space/power/dollar constraints work.
They certainly could change their business model and infra. But then they end up looking a lot more like a commercial CDN with hierarchal stores, more centralized POPs at IXPs, etc.
Disclaimer: Principal at AWS. Used to work on Amazon CloudFront and a bit of time in AWS Elemental, served a lot of video & streaming bits. Everything above is public domain knowledge.
> For example, with a 3-year term for a 42U cabinet, it would be $400 a month for 3 years, and that includes 1G already. After that, for another 3 years, would it be $340/mo for 1G, plus $500/mo for the 42U cabinet, which is $840/mo (more than double)? In both cases, is a /27 always included with the 1G port (pending justification)?
> Yes, you are understanding what our standard rates are without the promotion. Yes, we include the /27 with service. Our promotion is currently our most cost effective solution. Let me know if you have any questions.
Do you really want to build a whole 42U rack full of big heavy servers and have your price doubled after your contract expires?
It is certainly possible that the rate increases at some point, but I don't see why either HE or you would want to commit to anything beyond 3 years from now?
If they receive any kind of abuse report, they instantly put you on a 24h timer, but they won't show you contents of that message. If you do not respond in time, they will simply block the IP. What's strange is that I was using Cloudflare in front of Hetzner, but it seems that Cloudflare is ratting their users out and forwarding any abuse mail to the owners of "cloud protected" IPs, all without any notification or warning. Hetzner then sends you an email like "Please remove <sitename> from our network within the next 24 hours. This site violates 6.2 of Hetzner's terms and conditions.", where site in question is an obvious mirror/search engine of another social network.
What's perhaps more irritating is that Hetzner Cloud has a tiny LIFO queue of ipv4 addresses unique per customer, so you will get the same IP as soon as you release one. You can imagine what happens to a Rancher-managed k8s cluster with Hetzner node driver when one of those IPs gets a no-route: it will get stuck trying to re-deploy a failed node. Mine eventually fell apart though because I did not attend to it for a couple of years.
I'm now hosting from a proverbial garage (NixOS and cron) but proxying traffic through a cheap cloud VM, which saves me at least $1500/mo.
Whatever you (or your customer) were doing likely hit the point where they assumed the police would be by for a chat.
For this kind of response, you're probably looking at (1) extremist material or (2) CSAM.
Both of which can be found in copious amounts on Reddit and Twitter, and there are multiple services for these where the description of "search engine / mirror for a social network" applies.
Additionally, Hetzner is a German company. Our laws are very strict regarding Nazi content, and absurdly ridiculous when it comes to CSAM - about three quarters of what you can find on fanfiction sites is theoretically illegal here (§184c StGB).
Last week I got an email from them saying my server cost would increase from 30eur/month to 48eur/month. I can take afford the increase, but I wonder how many companies with infra bills of tens or hundreds of thousands will be able to afford a 60% increase in hosting costs.
https://pellegrino.link/2021/05/31/scaleway-object-storage-s...
Similarly, I saved about x100. For sure, the services do not offer the same level of guarantees and speed but depending on my case it was worth a migration.
Looking forward to trying Cloudflare R2 soon!
[0] https://news.ycombinator.com/item?id=28747798
[1] https://blog.cloudflare.com/workers-optimization-reduces-you...
Another awesome thing about Hetzner is that bandwidth internally is free and automatically negotiated (i.e if you send traffic to a Hetzner IP it will flow internally).
One of the hardest things is being able to tell the bandwidth usage and when it’s inside/outside Hetzner.
[0]: https://nimbusws.com
- S3
- VPC
- Compute instances (types don't have to bee too fine grained)
- SQS, SNS
- Some sort of Dynamo and/or RDS functionality.
- Some basic API coordinators, I guess Teraform has providers for lots of stuff these days.
Lambda- and fargate-like things would be a plus, but not strictly necessary.
I feel like 90% of the projects I've ever built could be easily made and scaled with nothing else. Further features hit diminishing returns really fast, and serve to muddy the waters up around what tooling is best, or even what exists.
OVH Cloud might have more of your list.
Though, neither has all of it, and some portions have bad reviews, like DO's object storage is apparently slowish and has other issues.
- Run a container (you give me a container, app.json or a standardized format, and I run it)
- Give me a bundle of files (static hosting), or specify a bucket
- Give me a single function and I'll run it, optionally hooking up a managed domain name through us to it)
Notes on the other things:
- VPC this is actually a bit more complicated, but possible
- SQS/SNS => NATS/Kafka is this enough?
- Dynamo/RDS => Managed Postgres +/- extensions like Citus and Timescale for scale
- Some basic API coordinators => Probably will not do but writing a TF provider is probably far in the future
Paradoxically Lambda and Fargate-like functionality is like one of the easiest to deploy and manage (standing on giants like OpenFaaS/Fission/etc), and would strike me as the easiest for people to actually get started with if I could roll it up with managed DNS.
Traditional object storage scales automatically and is very easy to integrate with (most people write apps to interface with S3 these days, and less SFTP), so there's just that small edge! That "sort of" is what I want to get rid of.
Other smaller clouds have services that are a better fit (OVH has object storage, Scaleway, etc), but Hetzner doesn't yet.
Is there a faster way to mount storage boxes? I suppose SSHFS would be even slower.
https://www.admin-magazine.com/HPC/Articles/Sharing-Data-wit...
I'd be super interested in hearing from someone who has set it up whether it's something an experienced but generalized sys admin could build, or if you need an expert in the matter.
Get an expert, or a consultant. You'd need a really experienced storage admin at the least, and possibly more.
Ceph has much more public resources available (SwiftStack recently got acquired, seemed like they had most of the knowledge in the space), and I've actually set it up a few times now thanks to the excellent Rook[0].
It's definitely a lot easier to set up with Kubernetes (the tradeoff being you need to understand Kubernetes), but it's definitely manageable for a generalized sys admin (albeit one with a bit more experience). I've written about the process:
https://www.google.com/search?q=site%3Avadosware.io+ceph
[0]: https://rook.io
- Some sharp corner cases are definitely out there (issues/bug reports)
- Supported APIs aren't quite as extensive as the other options yet
- The requirements/expectations for
There's also some previous discussion from 2020[0] that was interesting. I actually planned to use SeaweedFS and dip my toes with what I'm calling the "CloseCache" feature -- on-demand nearby proxies for the data that's really in your object storage. The idea was to take advantage of seaweed's excellent proxying features and kick the tires at the same time.
Somewhat off topic but I'd love to pick your brain, would you mind if I sent you an email?
(Yes, I googled it, but I'm looking for a more practical example)
You would use block storage more for a file system mount as a raw device (virtual).
There's overlap and many platforms support both close to interchangeably.
Object storage and block storage are similar -- the difference is usually how they're accessed but isn't necessarily (ex. s3 via FUSE projects can be thought of as block storage). Some examples of the blurring of this line:
- https://github.com/minio/minfs
- https://github.com/archiecobbs/s3backer
- https://github.com/yandex-cloud/geesefs
Hard drives are in the business of "block storage" -- you offer them a block of bytes (if you wanted to you could tell the hard drive exactly where to write the bytes, rather than using the file-based interfaces that are common), they put it on some sort of media (rotational, solid state, whatever), end of story.
Applications often only need a higher abstraction on storage -- not bits and bytes, but instead files or "objects". Most applications don't need the ability to access one or more bytes (in... a block) of an area on disk, they often only want access to entire files (roughly a 1:1 mapping with objects, with how 99% of the people use object storage).
Getting back to the question, block storage is usually interacted with via a completely different set of technologies -- iSCSI[0][1], NVMeOF[2], etc. The idea here is that you're talking to a hard drive on the other end, and it make sense to speak the language (or a language) of hard drives. Object storage is normally interacted with via HTTP. The expected/tolerated latencies using these different technologies are different orders of magnitude.
To rehash, object storage is similar, but seeks to up the level of abstraction and give you access to an consistent but opaque access to files. How is the object storage storing your files? You don't know and you don't care (probably) -- what you care about is how fast your HTTP request returns (or doesn't). This interface here is similar enough to reading and writing files locally but more importantly enables multiple applications to share the same storage without sharing the same hard drive. You can also write certain slices to files as well (this requires some more complicated locking and what not just like it would do locally).
I want to also note that there's a conceptual step between "traditional" block storage and "new age" object storage that others might skip over, that's distributed storage systems like NFS. It's NFS's job to present a file system that when changed, prompts a file system on a completely different machine to change in the same fashion. It's easy to imagine a simple way to make functionality work but of course reality is more complicated. Object Storage arises from the realization that you don't actually have to interact with a "fake"/shimmed version of the local filesystem that appears local but is actually remote -- you can just send a HTTP request over the internet to a machine asking for the file you want when you want it.
Here's a fun thing to think about -- is a database an implementation of object storage? You normally don't ship bytes to databases, you ship records (which you happen to decide the structure of) -- records are closer to files conceptually than they are to a "block" of bytes, even though at the end of the day the digital storage we're referring to is going to be bytes on a storage medium somewhere.
If you really want to get a good instinct for this, dedicate some time to skimming/reading through the Ceph documentation and you'll see how they layer the object storage (and other things) on top of a lower level "block" management[3]. The picture on the first page should be quite instructive.
[0]: https://www.truenas.com/docs/core/sharing/iscsi/
[1]: https://stonefly.com/blog/what-is-internet-small-computer-sy...
Why? Azure egress bandwidth is too expensive for a Tor relay, even for a well-paid software engineer like me. I have ~1.5 Gbps Tor bandwidth. If I were to put that on Azure, I would be paying a mortgage worth of bandwidth fees. Same can apply to AWS and Google Cloud.
However, Big Clouds charge more for bandwidth because (a) they're a leader and (b) they have paid peering deals with Big Telecom (e.g. AT&T, Deutsche Telekom, Telefonica, etc.). Smaller hosts like Hetzner don't peer with those ISPs and rely on "transit", but that also means slightly worse performance to Big Telecom.
In short, big clouds can use their market power and advanced technology to command a premium, whereas smaller clouds have to win over customers with lower prices to make up.
Tor relays are ill-suited for Big Clouds, but then your 5000-node Kubernetes cluster is ill-suited for OVH or Hetzner.
I do use the free Azure credit for Tor Bridges, however.
Wait, this seems backwards to me. I'd expect companies that can peer with Big Telecom to charge you less for bandwidth than companies that have to pay for transit. What am I missing?
I still can't believe that there is no regulation in place to prevent this sort of racketeering.
Is that a typical way to describe cost savings? I would have said 1/2 the cost of AWS. It almost sounds like cloudflare would pay them money (e.g. you go to the store and see something marked 200% off, so you get paid to buy it, like when oil prices went negative).
Related: I've always found the 2x, 10x, etc notation confusing. Does a 2x improvement mean a 100% increase (e.g. 10 -> 20) or a 200% increase (e.g. 10 -> 30)? Would someone ever say a 1x improvement or a 0.5x improvement?
2x savings means you need to double the new price to get the old
10x savings means multiple new price by 10x to get old
59x savings...multiply by 59.
And it still makes me feel nervous that 3x improvement = 200% increase. It seems to me like a big opportunity for misunderstanding.
If even a person asking how it works knew how it worked, how confusing can it be?
"1/59th the price of AWS" is clear because you take the price of AWS and multiply it by 1/59. Probably more clear would be "1.7% the price of AWS".
When I think there's an opportunity for misunderstanding, I point it out. I don't think I'm more likely to misunderstand something than the average person, but I am more likely to speak out if I see something potentially confusing.
I would be interested in seeing a poll where we ask people to estimate "59x cheaper than $200", vs "1/59th of $200" vs "1.7% of $200". Obviously the last one is easiest to do exactly in your head, but we can still get a fair comparison by just seeing whether people are at least in the neighborhood vs way off.
I would also like to see it with 2x, 1/2 and 50%.
Tune in next month for their article on how much fun manually scaling everything is.
This was November 2020 and he mentioned a big overhaul was in the works (of both HN and Arc, the programming language in which it is written).
We've seen new features since then, but the throttling is still there so it seems to still be the same situation regarding fundamental infrastructure.
In fact, before the cloud craze came around, internet services used to run just fine despite autoscaling not being commonplace. For a lot of use-cases, autoscaling is a problem created by the cloud's high prices and is unnecessary if hardware is cheap enough to run continuously.
But hey if you're gonna bring up people costs, shouldn't the simpler stack (because it doesn't need to autoscale) mean less management & maintenance overhead anyway?
I think the interest in this comes from the idea of identifying the needs and optimizing appropriately.
Also it doesn't matter. Cloud vs vps/colo/rented bare metal basically comes down to surplus of cash vs surplus of tech talent.
Any small tech focused company is gonna have more of the latter then the former, and in that situation, cloud doesn't make sense when ansible, k8s, and the like exists.
Or maybe being 38 makes me really old in the way I approach things...
People who manage huge "cloud" installations feels more like what the traditional sysadmin role was. Everything is so different than your personal setup, you have no use of the same skills outside of that particular provider, and there are many concepts that you have to deal with that you never deal with locally.
All that can be done by a competent admin/dev/devops but it takes nontrivial amount of time to setup and maintain. Having solutions integrated into your cloud of choice is a huge time saver.
although I hate to shill for Cloudflare, as I believe they are evil, but anyway there you go
What efforts against censorship? Like how they (actively) cancelled 8chan and Daily Stormer?
I won't go into anti-surveillance much because it's too contentious. Very few recognize or want to acknowledge the downsides of 1.1.1.1.
I honestly don't want to get into it more than that in part because I've forgotten more than I used to know about their various business practices. (I used to work near to this space.) I have a vague idea that they have made centralized (power concentrating) choices in some cases, where they could have made decentralized choices, but I can't recall specific products ATM and, well, I'm only willing to invest so much time in this post. By their literal mission "to build a better internet", we can see from those choices that better is in the eye of the beholder. Just as evil has always been as defined by Google.
I don't mean that Cloudflare is willfully evil. At the time that I was intensely interested in them and formed this opinion I could find no evidence of willfulness, and their products and their operations have all the good protections. But they do get to define 'better' in their own image and in favor of their own interests.
I'm sorry to be so vague.
Their efforts to roll out DNS-over-HTTPS and eSNI/ECH.
> Like how they (actively) cancelled 8chan and Daily Stormer?
I'll admit that was bad of them, but they're still way less cancel-happy than basically the entire rest of Big Tech.
On this topic as its relevant, at Vantage we launched an automated cost recommendation that keeps an eye on egress out of Cloudfront and S3 and recommends when it makes financial sense to switch to another provider (in the linked blog post, Cloudflare) https://www.vantage.sh/blog/cloudflare-specific-cost-recomme... -- this has been very popular with current customers/users.
We're actually in process of adding a bunch of new infrastructure and service providers and should include Hetzner in our list of recommended providers but thought I'd mention for anyone wanting an automated approach to knowing when you hit the financial tipping point, this is one option.
I blame level3 as that’s where it seems to go pear-shaped.
Full on self hosting your own cloud comes usually with a lot more services than "the" cloud does because thats usually why the hoster is considered "small".
In Hetzners case you will for sure at least have to self host a decent RDBMS and it better be replicated, which means more maintenance and servers.
But you do not have to put all your eggs into one basket! There are more than enough ways to split the load and you can even add dedicated servers in the mix too!
It should not be "yep we are on azure, or yup we are on hetzner" but "my job as an architect is to combine the two for maximum value" ;)
My understanding was that they dropped the per-TB billing a few years ago and now it's just uncapped?
The linked blog post mentions October 2021, while in December 2021 AWS lowered pricing for CloudFront where the first terabyte out to internet is now completely free:
https://aws.amazon.com/about-aws/whats-new/2021/11/aws-price...
For larger use cases most cloud providers have custom or private pricing options available. For example in CloudFront pricing page AWS publicly states that "Custom discounted pricing is available for customers willing to commit to a minimum of 10 TB of data transfer per month for 12 months or longer."
I have noted that most of the blog posts like the one linked above talk about migrating workloads around for savings of tens or hundreds of dollars while focusing on low level IaaS (VMs), and completely ignore the benefits of leveraging cloud services, APIs and related software ecosystems instead of DIY.
It seems like you could build out a CDN on OVH using 1-5Gbps unmetered+guaranteed bandwidth and place servers in the US, Europe, and a few PoPs in Asia for relatively cheap, then use GeoDNS for balancing traffic. But it seems like OVH's pricing offerings have been shifting over the last year to remove the "guaranteed bandwidth" in favor of "unmetered bandwidth" (potentially throttled 50%) on more machine types.
It would still require monitoring and managing bandwidth saturation per host, and it's unclear how much extra hassle OVH adds. But in theory it seems easier than setting up and managing colos in many countries?
1) Website assets are generally optimized for size (images, etc.) and so reduce Cloudflare's total cost to service.
2) Cloudflare believes that free tier users who use it for their website assets are more likely to want the other Cloudflare services and therefore convert to paying customers.
E.g., if you’re paying someone $5-7000/month (no idea what an SRE costs) to manage a fleet of say 10 subsystems, their salary should factor into the cost calculations, right?
And the need to use-only-as-needed creates additional burden that doesn't exist with cheaper monthly-paid hardware.
The answer might very well be "it will take less time to manage AWS", but it's not clear. Some might need a pay-stack to handle the cloud's pricing.
“Why doesn’t everyone do this?”
“I did the other thing so I can do … other things.”
Meanwhile on my Hetzner, I log in, tweak stuff directly, and it works. My static site wound up being much easier and more comprehensible when I dropped all the AWS stuff. I don't miss AWS one bit.