
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/microvm/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-lambda-microvms-agent-sandbox</guid>
    <title>AWS Lambda MicroVMs — 에이전트가 짠 코드를 VM 격리로 실행한다는 것, 그리고 스냅샷이 만드는 새 문제</title>
    <link>https://www.youngju.dev/blog/2026-07-16-lambda-microvms-agent-sandbox</link>
    <description>AWS가 2026년 6월 22일 Lambda MicroVMs를 출시했습니다. Firecracker 마이크로 VM을 서비스로 파는 물건이고, 노린 시장은 명확합니다 — 사용자나 AI가 생성한 코드를 테넌트별로 격리해 실행하는 일. 컨테이너의 공유 커널 문제를 VM 경계로 치우고, 부팅 대신 미리 만들어 둔 Firecracker 스냅샷에서 되살아나 시작 지연을 없앱니다. 그런데 바로 그 스냅샷이 다른 종류의 문제를 만듭니다 — 같은 이미지에서 뜬 모든 MicroVM은 바이트 단위로 동일한 메모리에서 출발하고, Firecracker 문서 스스로가 이 패턴을 &quot;안전하지 않다&quot;고 부릅니다. 이 글은 검증된 스펙, 스냅샷 유일성 문제와 VMGenID가 고치는 범위, VM 경계가 막지 않는 것(기본값이 열린 인터넷 이그레스라는 점 포함), 공식 요금에서 직접 계산한 비용, 그리고 쓰지 말아야 할 경우를 정리합니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>security</category><category>firecracker</category><category>microvm</category><category>aws-lambda</category><category>sandboxing</category>
  </item>

    </channel>
  </rss>
