How we run Firecracker VMs inside EC2 and start browsers in less than 1s
131–140 of 251 posts
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#132Something elided here is that nested virtualization on regular EC2 instances has only been possible since February this year[1] - before this, you had to use a metal EC2 instance to run Firecracker VMs. 1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#133Earlier quoted context omitted.
Sure, you're right. I edited to remove that bit. Thanks for calling me out. I was getting frustrated for having felt like I was extremely clear in what I wrote and the person kept repeating something that I had clarified. > At any rate, warm pools aren't cost free. If you overestimate demand, you'll waste too much money on idle resources. Depends on how you're running your business. If it is your hardware, it isn't m…
It depends on how you think about spare capacity on your hardware. They're an opportunity cost. Every idle cycle and bit of unallocated memory could be spent doing something else valuable. Consider the most extreme example of GPUs: CoreWeave was founded by repurposing nearly-useless GPUs their founders had on hand to mine Bitcoin (correction: Ethereum) that was obsoleted by ASICs and other specialized mining hardware…
EC2 has preemptable and reserved pricing. It is possible to build autosizing solutions, this is what Google did with AppEngine and later GCP Functions/Cloud Run. Just like optimizing start times, it is also possible to optimize those idle resources. For me, I'd go with the idle resources as the lower hanging fruit over trying to shave ms off making things available on-demand, since it affects the customer experience first.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#134Kubernetes + Kata would have helped with scaling here, I think.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#135> Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark. > Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider. Seems very unethical, no? Who uses service providers like this? The whole point of an…
To me archiving the internet is way more ethical than putting bulk of the content behind paywall.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#136What is firecracker needed? Couldn’t this just run in a container directly? I understand some of the isolation concerns but a browser and container breakout is a billion dollar CVE, no?
You can take a snapshot of a microVM and roll back. I've never heard of this being done with containers.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#137What is firecracker needed? Couldn’t this just run in a container directly? I understand some of the isolation concerns but a browser and container breakout is a billion dollar CVE, no?
If you follow the kernel mailing list container breakout exploits are currently a weekly occurrence
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#138Saving state before launch of the browser for quick startup is interesting but how do you configure it? I suppose you don't? Or post configure?
The state does not contain the browser config, since it's configured just before it starts running (and we currently snapshot before Chromium starts). In our case, we prepare the environment, load files that we need later and then we create the state. Once we start, we instantly start Chromium with the config requested by the customer.
I have tried it before by saving the entire memory state of the VM actively running but man oh man were there alot of bugs. My idea was different I was playing with spinning browsers on spot nodes and swap them over + state if they were revoked.
You thinking custom Chromium startup sequence for that?
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#139> Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark. > Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider. Seems very unethical, no? Who uses service providers like this? The whole point of an…
For example, at a startup a few years ago, one of the many technological things we needed to do was to monitor marketplaces for suspected counterfeit and contract-violating gray market goods for ~100 brands. And we couldn't just ask for data feeds, because, well, the marketplaces make money off of all those sales. And the off-the-shelf third-party data solutions were useless crap quality, worse than your average vibe-coding. So I made a bespoke crawler that gently and accurately tracked the data we needed, including global geofencing. So gently, I never got a whiff of disapproval or countermeasures (like throttling, 403, nor data poisoning). We were putting insignificant load on the marketplaces, for the purpose of helping to make the market better for both consumers and legitimate businesses. It was like a single "secret shopper" unobtrusively walking around some parts of a store. (And I also made an iOS app that did something different for actual secret shoppers in physical stores, for legitimate supply chain traceability for customers' brands.) Personally, I love the marketplaces, and hate the counterfeits, and this was my version of PG's advice that startups should be a little bit naughty.
Two of the problems with the current AI scrapers, which are destroying servers, and inviting backlash:
1. The gold rush situation brings out many of the crappiest people in the world. And also many who aren't crappy might behave in a crappy manner. (The latter, maybe because they're just emulating what they see, or extrapolating from the ethical temperature of prior industry norms, like surveillance capitalism in everything.)
2. Many of these scrapers are shockingly bad at what they do, and grossly inefficient. Almost like they're just pounding the same unchanging resources to DoS the servers for competitors. Or to drive sites to a protection racket company that's set up so they can also monitor cleartext. Or (Occam's Razor) just plain bad at what they do, and the people who pay for the salaries and computer resources either don't know or don't care.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#140Earlier quoted context omitted.
Its unethical because you're intentionally bypassing restrictions. Just because others do it doesn't mean its okay. If you saw a sign in a store that said "1 per person" or "for registered guests only", would you ignore it?
Was Rosa Parks unethical for sitting down on a bus? The point is that the context matters: both the users context and the context of the restriction. It’s not as clear cut as “ignoring restrictions = bad”. The restriction itself can be unethical, in the same way that bypassing a restriction can be unethical.