{
  "$type": "site.standard.document",
  "canonicalUrl": "https://justingarrison.com/blog/2024-02-08-fargate-is-not-firecracker",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreib5rcd3pkxrxxsrzya5tdcci66nxhqlb6c7pcctjayesf5lqckzmu"
    },
    "mimeType": "image/png",
    "size": 1274912
  },
  "description": "A common misconception that AWS never corrected anyone about.",
  "path": "/blog/2024-02-08-fargate-is-not-firecracker",
  "publishedAt": "2024-02-09T06:17:30.000Z",
  "site": "at://did:plc:p7uix7mresfq4nfzxp3klgfa/site.standard.publication/3mmdn7mg2qm2d",
  "textContent": "This was the biggest un-truth that I saw while working at AWS on the EKS team.\nOn an almost weekly basis a customer would want to use AWS Fargate for a variety of reasons and one of them would be because it used Firecracker. For some reason--AWS marketing--that was better than traditional EC2 Xen virtualization.\n\nAnd no one at AWS would correct them.\n\nThere was an unspoken policy to never point out that Fargate didn't actually use Firecracker to create \"microVMs\" for each container.\nJust let customers believe what they wanted to.\nOf course all of the documentation and blog posts make it _sound_ like Fargate uses Firecracker, but you have to read between the lines and know how companies push you to believe something that's not true.\n\nLet's look at what the main documentation page says (ephasis mine):\n\n> Firecracker was developed...to improve the customer experience of services like AWS Lambda and AWS Fargate.\n\nOr how about this blog from 2020 Under the hood: AWS Fargate data plane.\nSurely this will tell the truth of what Fargate uses, and it does.\nIt spends 80% of the article explaining that Fargate has moved away from Docker and now uses containerd, but it has to mention Firecracker even if it's not used.\n\n> Fargate can leverage a VM-based runtime for containers such as Firecracker VMM by simply switching containerd’s runtime plugin to firecracker-containerd instead of runC.\n\nOf course it _can_ switch out runC, but that's anything but \"simple\" at Amazon's scale.\nAnd by \"scale\" I mean people scale, not technology.\nThe politics involved would cost a lot more cycles than the technology challenges.\n\nSo what _does_ Fargate use?\n\nSurprisingly, there's information right on the Firecracker documentation page under the \"Why did you develop Firecracker?\" section.\nIt's speaking about Lambda but you could see how this could be the same architecture used for Fargate.\n\n> ...we used per-customer EC2 instances to provide strong security and isolation between customers\n\nDoes Fargate guarantees hardware isolation between your containers? Nope.\n\nDoes Fargate gets rid of \"noisy neighbor\" problems from EC2? Nope.\n\nDoes Fargate have hardware virtualization isolation between you and someone else? Yep, just like EC2.\n\nDoes Fargate lower operational burden by never having to worry about an operating system ever again? Nope. The operational burden shifts to other areas like \"how do we get EBS volumes or GPUs?\" and \"how do we shift all our daemons to side cars?\" and \"why is this costing us so much more money than EC2?\".\n\nYou spend all that operational time working around Fargate, but at least you don't have any pesky servers. 🙄\n\nShould I care?\n\nNot really.\n\nIf it's been working for you then great!\nYou're the exact target market they built it for.\n\nPeople often think that Fargate is magic.\nThat there's some special technology implementation detail that only Amazon can do.\n\nIn reality, AWS builds on AWS with extremely rare cases of behind the scenes special sauce.\n\nJust make sure you're not lying to yourself about how much \"heavy lifting\" is being removed and how much is being shifted to something else.\n\nDisclaimer: I worked on the containers and EKS team from April 2020 through Janurary 2024. The implementation of Fargate may have changed, but the lies remain the same.",
  "title": "Fargate Is Not Firecracker"
}