EC2 के अंदर Firecracker VM के साथ ब्राउज़र को 1 सेकंड से कम समय में शुरू करना

 (browser-use.com)
2 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Browser Use Cloud हर ब्राउज़र सेशन के लिए अलग Firecracker VM का उपयोग करते हुए नए सेशन का start time 1 सेकंड से कम तक लाता है और लागत को ब्राउज़र के प्रति घंटा $0.06 से घटाकर $0.02 कर देता है
  • पुरानी Unikraft architecture idle cost के लिए फायदेमंद थी, लेकिन traffic spike के समय इंसानों को capacity adjust करनी पड़ती थी, जिससे load test के दौरान production 45 मिनट तक बंद रहा
  • नई architecture का अपना control plane ब्राउज़र fleet को real time में मॉनिटर करता है और EC2 host placement, scaling, और draining को CloudWatch से अधिक बारीकी से तय करता है
  • नियमित EC2 पर Firecracker चलाने वाली nested virtualization अपनाने के बदले, 2MB memory pages, userfaultfd, vCPU pinning, real-time priority, और headless Chromium patches से bottleneck कम किए गए
  • VM cold start 400ms से कम है, और 10,000-session stress test में public API के हिसाब से browser creation latency p50 825ms, p99 1.35 सेकंड रही, जबकि सभी ब्राउज़र सफलतापूर्वक शुरू हुए

तेज़, अलग-थलग और सस्ता क्लाउड ब्राउज़र

  • Browser Use Cloud का लक्ष्य ब्राउज़र को तेज़ी से शुरू करना है, साथ ही सेशनों के बीच state isolation बनाए रखना और लागत कम करना है
  • एक सेशन में Chromium, filesystem, cookies, cache, proxy settings, downloads, और कभी-कभी logged-in customer session तक शामिल होते हैं
  • अगर एक ब्राउज़र दूसरे ब्राउज़र की state पढ़ सके तो यह security समस्या बन जाती है, इसलिए हर सेशन को host और दूसरे सेशनों से अलग रखना पड़ता है
  • आम समाधान ऐसा VM है जिसके पास अपना CPU, memory, disk, और network device हो, लेकिन लगातार बनाए जाने और सेशन खत्म होने के बाद फेंक दिए जाने वाले cloud browser environment के लिए यह बहुत भारी और महंगा है
  • नई architecture सभी Browser Use Cloud सेशनों को एक-एक छोटे Firecracker VM में चलाती है, और इन VM को Amazon EC2 पर चलाया जाता है

Unikraft को छोड़ने की वजह

  • पुरानी architecture में cloud browser चलाने के लिए Unikraft का उपयोग किया गया था
  • Unikraft पूरा Linux boot किए बिना purpose-built छोटी image, यानी unikernel, लोड करता है
  • unikernel तेज़ी से शुरू होता है और उपयोगकर्ता न होने पर बंद किया जा सकता है, इसलिए idle cost कम रहती है
  • bottleneck traffic spike के समय browser capacity को तेज़ी से बढ़ाने में था
    • Unikraft में अच्छा built-in autoscaling नहीं था
    • engineers को variables बदलकर instances manually जोड़ने पड़ते थे
    • एक load test ने production को 45 मिनट तक बंद कर दिया
  • दोबारा निर्माण के बाद Firecracker का उपयोग किया गया
    • Firecracker VM को create, monitor, और run करने की layer देता है
    • यह हर VM को CPU, memory, disk, और network devices देता है और host व दूसरे VM से अलग रखता है

अपने control plane से browser scaling का automation

  • Firecracker हर ब्राउज़र को VM दे सकता है, लेकिन यह VM की संख्या, placement, और scale करने का समय अपने-आप तय नहीं करता
  • Browser Use ने अपना control plane बनाया जो browser fleet को मॉनिटर करता है और scale up/down तय करता है
  • जब उपयोगकर्ता ब्राउज़र मांगता है, control plane spare capacity वाली machine चुनता है
  • traffic बढ़ने पर यह अधिक machines शुरू करता है, और घटने पर हटाई जाने वाली machines पर नए ब्राउज़र नहीं भेजता
  • control plane fleet को real time में देखता है
    • AWS monitoring service CloudWatch आमतौर पर 1 मिनट की window में प्रतिक्रिया देती है
    • control plane को ऐसी जानकारी होती है जो सामान्य metrics में नहीं होती, जैसे अभी boot हो रहे ब्राउज़र, हटाई जा रही machines, या वे machines जिन्हें नया session नहीं मिलना चाहिए
  • user requests stateless edge router से होकर control plane तक जाती हैं, और control plane spare EC2 host चुनता है

नियमित EC2 पर Firecracker चलाने की वजह

  • AWS में Firecracker चलाने का सामान्य तरीका .metal instances का उपयोग करना है
    • .metal में पूरा physical server किराए पर लिया जाता है, जहाँ Firecracker सीधे चलता है
  • Browser Use ने नियमित EC2 चुना
    • नियमित EC2 machines अधिक तेज़ी से मिल सकती हैं
    • maintenance cost कम है
    • hosts prebuilt image से boot होते हैं और start होने के लगभग 30 सेकंड बाद ब्राउज़र दे सकते हैं
  • अगर hosts को अधिक तेज़ी से जोड़ा जा सके, तो paid idle capacity घटती है और ग्राहकों पर डाली जाने वाली लागत भी कम होती है
  • इसकी कीमत VM के अंदर VM structure है
    • नियमित EC2 खुद पहले से AWS isolation layer के अंदर चलता है
    • उसके अंदर फिर browser VM चलाया जाता है
    • जब browser VM host से मदद मांगता है, तो उसे दो VM layers से गुजरना पड़ता है, जिससे latency बढ़ती है
  • Browser Use ने तेज़ scale-up और कम लागत के लिए यह trade-off चुना और Firecracker execution path को तेज़ बनाने पर ध्यान दिया

request से usable browser तक का flow

  • जब उपयोगकर्ता ब्राउज़र मांगता है, control plane spare capacity वाली machine चुनता है
  • वह machine stored browser VM को restore करती है और उसके अंदर Chromium शुरू करती है
  • जब Chromium controllable state में आ जाता है, तो यह connection URL लौटाता है
  • उपयोगकर्ता का agent इस URL से connect करता है
  • Browser Use WebSocket के ज़रिए Chrome DevTools Protocol(CDP) से Chromium को control करता है
    • CDP, Chrome का remote control API है, जिससे button click, text input, page reading, और screenshot capture जैसी चीज़ें की जा सकती हैं
  • latency पैदा करने वाले मुख्य bottleneck तीन थे
    • VM memory restore
    • Chromium startup
    • anti-bot security से detect न होने वाली stealth बनाए रखना

पहला bottleneck: memory restore

  • production browser शुरू से boot नहीं होते, बल्कि snapshot से resume होते हैं
  • snapshot एक stored VM है जो पहले से boot हो चुका है और Chromium शुरू होने के ठीक पहले रोका गया है
  • VM resume, fresh boot से तेज़ है, लेकिन शुरुआती cold start में page faults कुल VM exits का 72% थे
  • VM resume से CDP-ready browser तक पहुँचने में शुरुआत में 9.8 सेकंड लगते थे
  • इसकी वजह यह थी कि जब restored VM पहली बार memory को touch करता है, तो host को उस memory को फिर से map करना पड़ता है
    • यही event page fault है
    • nested VM में page fault दो VM layers से गुजर सकता है, इसलिए यह महंगा पड़ता है
  • समाधान memory को बड़े units में map करना था
    • पहले 4KB pages के साथ restore किया जाता था
    • अब 2MB pages का उपयोग होता है
    • हर page 512 गुना अधिक memory cover करता है, जिससे browser wake-up के दौरान page faults बहुत घट जाते हैं
  • Linux के missing memory pages handling API userfaultfd के लिए custom handler भी जोड़ा गया
    • VM चलाने से पहले वह memory लोड की जाती है जिसे Chromium पहले access करने की संभावना रखता है
    • इससे Chromium startup के समय page fault storm रुकता है
  • इस बदलाव से VM resume से command स्वीकार करने वाले browser तक का समय 9.8 सेकंड से घटकर 3.1 सेकंड रह गया
  • missing memory संभालने के लिए browser VM के रुककर host से request करने की संख्या प्रति resume लगभग 100,000 बार से घटकर लगभग 1,100 बार रह गई, यानी लगभग 91 गुना कमी
  • छोटे optimizations भी जुड़ते गए
    • मौजूद ही नहीं रहे पुराने PS/2 keyboard को खोजने में लगने वाली 500ms जांच बंद कर दी गई
    • readiness check को HTTP polling से vsock log reading में बदला गया
    • browser driver log में ready message लिखता है, host उसे vsock से पढ़ता है, और ready message को 1ms से कम समय में detect कर लेता है

दूसरा bottleneck: Chromium startup और CPU placement

  • Chromium startup के समय renderer, compositor, और V8 isolate एक साथ बनते हैं, इसलिए CPU उपयोग बहुत अधिक होता है
  • startup के बाद browser automation अपेक्षाकृत शांत होती है
    • agent click करता है, इंतज़ार करता है, पढ़ता है, फिर click करता है
    • browser ज़्यादातर page, network response, और अगले agent action का इंतज़ार करता है
  • इस विशेषता की वजह से एक host पर कई ब्राउज़र packing किए जा सकते हैं
  • startup के समय CPU burst को दो चरणों में संभाला गया
    • browser resume होने और Chromium शुरू होने के दौरान vCPU को unpinned रखा जाता है
    • Linux browser CPU work को fixed core से बांधे बिना पूरे host में फैला सकता है
    • browser के ready report करते ही vCPU को stable core पर pin किया जाता है
  • अगर शुरुआत से pinning कर दी जाए, तो कई ब्राउज़र साथ शुरू होने पर वे एक ही hot core पर इकट्ठा हो जाते हैं और कुछ launches fail हो जाते हैं
  • hyperthread handling भी बदली गई
    • एक physical CPU core अक्सर sibling threads वाले दो logical CPU की तरह दिखता है
    • अगर दो browser VM को एक-एक sibling मिले, तो वे उसी physical core के लिए प्रतिस्पर्धा करते हैं
    • nested environment में यह प्रतिस्पर्धा launch failure के रूप में दिखती है
    • अब हर browser को जिस physical core का उपयोग करना है, उसके दोनों sibling threads दिए जाते हैं
  • हर pinned vCPU thread को real-time priority दी गई
    • इससे Linux VM को कम महत्वपूर्ण कामों के पीछे रोके नहीं रखता और तुरंत चलाता है
    • बदलाव से पहले 1,000-browser test में creation के तुरंत बाद 17% session खो जाते थे
    • बदलाव के बाद उसी test में loss 0 रहा

बिना स्क्रीन वाला stealth browser

  • headless browser बिना दिखने वाली window के चलता है, जबकि headful browser laptop के browser की तरह window, graphics, और rendering frames के साथ चलता है
  • plain headless Chromium, anti-bot उपायों का उपयोग करने वाली websites पर आसानी से detect हो जाता है
  • Browser Use के stealth benchmark के अनुसार plain headless Chromium का block से बचने का rate सिर्फ 2% था
  • वही Chromium अगर दिखने वाली window वाले headful mode में चले, तो सिर्फ rendering की वजह से block bypass rate 50% हो जाता है
  • यही वजह है कि कई providers headful browser चलाते हैं और भले कोई स्क्रीन न देख रहा हो, फिर भी display server, GPU, और compositor की लागत उठाते हैं
  • Browser Use browser को ही बदलकर पूरी तरह headless execution बनाए रखता है
  • पहला component Chromium fork है
    • कई stealth tools browser start होने के बाद हर page में JavaScript inject करके automation छिपाते हैं
    • उदाहरण के लिए वे navigator.webdriver value को overwrite करते हैं ताकि website को true की जगह false दिखे
    • websites detect कर सकती हैं कि ऐसे values overwrite किए गए हैं
    • Browser Use Chromium के low-level हिस्सों को patch करता है ताकि ऐसी values शुरुआत से expose ही न हों
  • दूसरा component fingerprinting है
    • browser fingerprint, browser और machine information का संयोजन है जिसे website पढ़ती है
    • इसमें operating system, screen size, fonts, graphics output, audio, timezone, language जैसी सैकड़ों details शामिल होती हैं
    • Browser Use macOS, Windows, और Linux के हजारों वास्तविक fingerprints का उपयोग करता है
  • इन browsers ने stealth benchmark में 81% और Halluminate BrowserBench में 84.8% block bypass rate दर्ज किया
  • स्क्रीन न होने की वजह से browser चलाने की लागत कम है और scaling आसान है

सही browser से connect करना

  • जब browser तैयार हो जाता है, उपयोगकर्ता CDP से connect करता है
  • public URL एक WebSocket URL होता है
  • browser fleet के आगे simple edge routers लगे होते हैं
  • router WebSocket connection स्वीकार करता है, control plane से उस browser की location पूछता है, और raw CDP bytes को सही VM तक भेजता है
  • router तय नहीं करता कि browser कहाँ चलेगा
  • अगर एक router बंद हो जाए, तो दूसरा router नया connection संभाल सकता है
  • placement की जिम्मेदारी control plane की है, router सिर्फ bytes forward करता है

नतीजे और अगला चरण

  • अभी हर browser session नियमित EC2 के अंदर चलने वाले छोटे VM snapshot से resume होता है, और उसके भीतर headless Chromium चलता है
  • VM cold start 400ms से कम है
  • public API के हिसाब से browser creation latency p50 825ms और p99 1.35 सेकंड है
  • ये आंकड़े ऐसे 10,000-session stress test में मापे गए जहाँ सभी ब्राउज़र सफलतापूर्वक शुरू हुए
  • BrowserArena की independent leaderboard ने Browser Use को $0.02/hr और 100% reliability के साथ पहला स्थान दिया
  • इस infrastructure में सबसे बड़ी बची हुई लागत Chromium खुद है
    • resume के बाद भी Chromium startup में p50 के हिसाब से लगभग 545ms लगते हैं
  • मौजूदा snapshot Chromium शुरू होने के ठीक पहले के समय पर बनाया जाता है
    • सभी ब्राउज़र एक जैसे और साफ़ state से जागते हैं, फिर अपना-अपना Chromium शुरू करते हैं
  • अगला कदम Chromium के पहले से चल रहे होने के बाद snapshot बनाना है
    • तब नया session browser शुरू नहीं करेगा, बल्कि पहले से जीवित browser के साथ जाग सकेगा
  • यह काम जटिल है
    • चल रहे browser में खुले devices, timers, graphics state, network state, और fingerprint state होती है
    • freeze से पहले इन states को सुरक्षित बनाना होगा
    • restore के बाद हर browser पिछली browser copy की तरह नहीं, बल्कि अपने अलग browser की तरह दिखना चाहिए
  • Browser Use Cloud अभी cloud.browser-use.com पर उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • एंटी-बॉट बायपास को बेंचमार्क की तरह पेश करना काफ़ी अनैतिक लगता है। एंटी-बॉट का मकसद अवांछित बॉट्स को रोकना है, लेकिन ऐसी सेवाएँ आख़िरकार वेब को इंसानों के लिए और कम अनुकूल तथा ज़्यादा महंगा बना देती हैं
    साइटें ऑटोमेटेड एक्सेस को लगातार रोकने की कोशिश करती रहेंगी, और कंटेंट तक पहुँच की बाधाएँ और बढ़ेंगी। वेब पर पहचान सत्यापन की मांग बढ़ने की वजह सिर्फ़ आयु-सीमा या “बच्चों की सुरक्षा” नहीं, बल्कि बॉट डिफेंस और विज्ञापन राजस्व की सुरक्षा जैसे बड़े प्रभाव भी लगते हैं

    • मैं ऐसी चीज़ें वेबसाइट बदलाव पहचानने के लिए इस्तेमाल करता हूँ। जिन लेखकों को मैं पसंद करता हूँ उनमें कुछ के पास RSS नहीं है, और बड़े घरेलू उपकरण जैसी महंगी चीज़ों के लिए मैं कीमत में बदलाव देखने हेतु हमेशा price monitoring सेट करता हूँ
      जिन साइटों में API नहीं है, वहाँ मैं scraper भी इस्तेमाल करता हूँ, और अपनी पूरी खरीदारी हिस्ट्री को डेटाबेस में index करके analysis के लिए रखता हूँ। बेवकूफ़ाना bot detection को बायपास करने में और ज़्यादा समय नहीं लगाना चाहता, और अगर डेटा तक किसी और तरीके से पहुँचना संभव न हो तो मैं उसके लिए पैसा देने को भी तैयार हूँ। वैसे भी यह ऐसा cat-and-mouse game है जिसमें scraper आख़िरकार जीत ही जाते हैं, और बस संसाधन जलते हैं
    • सार्वजनिक वेबसाइट scraping अनैतिक है या नहीं, इस पर बहस हो सकती है। कुछ मामलों में, साइट तकनीकी बाधाएँ खड़ी करे या cease-and-desist भेजे तब भी अदालतों ने इसे क़ानूनी माना है
      हालाँकि residential proxy उपलब्ध कराना अनैतिक हो सकता है। ऐसे प्रॉक्सी में residential connections देने वाले लोग अक्सर जानते ही नहीं कि उन्हें ऐसी सेवा में शामिल कर लिया गया है
    • सिर्फ़ इसलिए किसी चीज़ को अनैतिक नहीं कहा जा सकता कि आप वह कर रहे हैं जो दूसरा नहीं चाहता। वजह और इरादा ज़्यादा मायने रखते हैं
      अगर मैं किसी कॉन्सर्ट का टिकट पाने के लिए 24 घंटे कंप्यूटर के सामने नहीं बैठ सकता, तो अपनी पसंदीदा बैंड का टिकट खरीदने के लिए निजी बॉट इस्तेमाल करना अनैतिक कहना मुश्किल है। लेकिन अगर मकसद scalping हो, तो मैं मानता हूँ कि वह अनैतिक है। एंटी-बॉट का एंटी-बॉट उन कामों को संभव बनाने के लिए होता है जिन्हें दूसरे लोग ऑटोमेट नहीं होने देना चाहते, और शायद Hacker News के काफ़ी पाठकों ने कभी न कभी ऐसा किया होगा। अगर यह सिर्फ़ मुनाफ़े के लिए हो तो अच्छा नहीं, लेकिन अगर इससे scalpers के ख़िलाफ़ मौका मिलता हो, तो यह ठीक लगता है
    • मैं ऐसी कंपनियों को जानता हूँ जो ऐसे software को automate करती हैं जो सिर्फ़ वेब से ही उपलब्ध है और जिसका API support कमज़ोर है या है ही नहीं। आम तौर पर यह काफ़ी महंगा software होता है, लेकिन login सुरक्षा के लिए इसमें CAPTCHA built-in होता है
      वे कई SaaS tenants में से सिर्फ़ एक होते हैं, इसलिए इतने बड़े ग्राहक नहीं कि CAPTCHA हटाने की मांग कर सकें, तो वे बस इस पाबंदी को बायपास कर लेते हैं
    • इसका इस्तेमाल वे लोग करते हैं जो चाहते हैं कि उनका headless browser ब्लॉक न हो

  • यहाँ जो बात छूटी है, वह यह कि सामान्य EC2 instances पर nested virtualization इस साल फरवरी से संभव हो गया है। इससे पहले Firecracker VM चलाने के लिए metal EC2 instances इस्तेमाल करने पड़ते थे

    1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • यह काफ़ी नया फ़ीचर है, और आधिकारिक रूप से अभी भी recommended नहीं है, लेकिन अब तक यह बहुत अच्छी तरह काम कर रहा है। आख़िरकार अब bare metal चलाने की ज़रूरत नहीं रही
    • metal instances को start और stop होने में बहुत समय लगता है

  • इतना सब करने के बाद भी उन्होंने अब तक Chromium ही चुना, यह थोड़ा चौंकाने वाला है
    हमारा web-access MCP server[0] काफ़ी सरल सेटअप में browser instances को subprocess के रूप में चलाता है, और stability, CPU, तथा memory usage में सबसे बड़ा सुधार तब मिला जब हमने Chrome से Lightpanda[1] पर स्विच किया। लेख के अंत में जैसा कहा गया है, तेज़ी से शुरू होने वाला browser शायद वह browser भी हो सकता है जो शुरू में कम memory allocate करता हो
    [0]: https://github.com/EratoLab/web-access-mcp
    [1]: https://lightpanda.io

    • stealth कारणों से हमने इंजन के रूप में Chromium बनाए रखने का फ़ैसला किया
      LightPanda जैसे browsers में stealth बिल्कुल नहीं है और उन्हें detect करना बहुत आसान है। जो चीज़ें ज़रूरी नहीं हैं उन्हें हटाकर Chromium को और तेज़ बनाने के तरीके मौजूद हैं। शुरू से पूरा इंजन फिर से बनाए बिना भी, और हमारी सर्वोच्च प्राथमिकता stealth खोए बिना, Chromium उस प्रदर्शन तक पहुँच सकता है। भाषा समस्या नहीं है; C++ भी Zig जितना performant है, लेकिन मैं मानता हूँ कि Chromium का bloated होना एक बड़ी समस्या है

  • मैं ApiFlash नाम की screenshot API चलाता हूँ, और EC2 के Firecracker की जगह AWS Lambda container images में Chromium पैकेज करके इस्तेमाल करता हूँ
    AWS Lambda isolation और auto-scaling मुफ़्त में देता है, इसलिए screenshot जैसे bursty stateless workloads के लिए यह आदर्श है। मुझे लगता है कि browser-use solution के लगभग वही फ़ायदे मिलते हैं, लेकिन architecture कहीं ज़्यादा सरल रहता है। trade-off AWS Lambda cold start है, लेकिन व्यवहार में लगातार आने वाली calls के बीच hot functions reuse हो जाती हैं। अगर call volume काफ़ी हो, तो peaks smooth हो जाते हैं और cold starts भी उतनी बार नहीं होते

    • हमने जो बनाया है, वह हर use case के लिए ज़रूरी नहीं है
      Lambda के साथ हमें जो समस्याएँ मिलीं, वे थीं 15 मिनट की execution limit, cost, snapshot mechanism का न होना, और execution host पर low-level control की कमी। हम अधिकतम 4 घंटे तक support करते हैं और ज़रूरत हो तो इससे ज़्यादा भी चला सकते हैं। फिर भी ज़्यादातर सामान्य web automation use cases के लिए Lambda काफ़ी से भी ज़्यादा है
    • वह solution काफ़ी महंगा लगता है

  • उन्होंने कहा “अगला: Chromium startup को छोड़ना”, लेकिन क्या पहले से चल रहे browsers के एक समूह को warm pool में रखकर incoming requests को allocate नहीं किया जा सकता?
    उपयोगकर्ता के नज़रिए से latency लगभग शून्य के क़रीब होगी। ट्रैफ़िक पैटर्न के हिसाब से warm pool को बढ़ाने-घटाने के लिए prediction logic चाहिए होगी, लेकिन यह सबसे आसान समाधान लगता है

    • warm pool काम करता है, लेकिन लक्ष्य उसी को replace करना है
      warm pool अच्छा है, लेकिन वह अंततः resources खाता है, और pool को हमेशा गर्म रखने तथा संतुलित रखने के लिए browsers को लगातार शुरू करते रहना पड़ता है। आगे के बदलावों के साथ हमारी योजना है कि Chromium startup बनाए रखते हुए VM को 50ms के भीतर तैयार कर दें, ताकि warm pool को पूरी तरह मात दी जा सके। कुछ ग्राहकों को विशेष parameters और features चाहिए होते हैं, जिससे warm pool की complexity बढ़ जाती है। सामान्य path तेज़ हो सकता है, लेकिन exception paths बहुत धीमे हो सकते हैं; हम यह सुनिश्चित करना चाहते हैं कि अनुरोधित browser को चाहे जो भी features चाहिए हों, speed तेज़ रहे

  • Firecracker बेहतरीन तकनीक है। मैं इसे एक interview startup में इस्तेमाल करता हूँ जो coding interviews और व्यक्तिगत workspace के लिए isolated runtimes चलाता है, और यह बहुत stable तथा हैरान कर देने जितना lightweight है
    Go SDK के साथ integrate करना भी बहुत आसान था

  • userfaultfd का ज़्यादा इस्तेमाल होते देखना बढ़िया है। page faults होने पर memory को कैसे और कहाँ से लाना है, इस पर यह पूरी तरह नियंत्रण देता है, इसलिए यह वाकई बहुत शक्तिशाली API है

  • यह सही है कि सामान्य EC2 भी पहले से VM ही है, लेकिन मेरी समझ से कुछ खास EC2 ऐसे हैं जो hypervisor access देते हैं, इसलिए Firecracker भी संभव हो जाता है। अगर मैं ग़लत हूँ तो सुधारें

    • सही है। सिर्फ़ c8i, m8i, r8i instance types समर्थित हैं, और इसे nested virtualization कहा जाता है[1]
      [1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • जब हमें बड़े machines, यानी AWS metal instances की ज़रूरत थी, तब metal और उसी आकार के VM के बीच CPU-heavy workloads में performance का फ़र्क़ लगभग 10~20% था

  • मैं समझना चाहता हूँ कि Firecracker की ज़रूरत क्यों है। क्या इसे सीधे container में नहीं चलाया जा सकता? isolation की चिंता समझ में आती है, लेकिन browser और container escape का मेल हो तो क्या वह अरबों डॉलर वाला CVE नहीं होगा?

    • ज़्यादातर mature या security-conscious providers containers को सुरक्षित isolation boundary नहीं मानते। Microsoft शायद एक अपवाद लगता है, लेकिन यह उनकी internal policy failure है या policy enforcement capability की कमी, यह साफ़ नहीं है
      containers, VMs की तुलना में कहीं बड़ा attack surface देते हैं, और चूँकि industry standard में इन्हें सुरक्षित नहीं माना जाता, इसलिए container escape CVE प्रबंधन में लगने वाले संसाधन भी संभवतः VM escape की तुलना में कम होते हैं
    • kernel mailing list देखें तो container escape exploits आजकल लगभग हर हफ़्ते आ रहे हैं
    • microVMs का snapshot लिया जा सकता है और rollback भी किया जा सकता है। containers में ऐसा होता है, मैंने तो नहीं सुना

  • क्या इसे .metal नहीं होने वाले instances पर चलाने के लिए kernel patch की ज़रूरत नहीं होगी? लगता है PVM patch चाहिए