Advertise on podcast: AWS Bites

What if you could make your AWS containers start up to 10× faster, without changing your application code? In this episode of AWS Bites, we explore practical ways to speed up container startup on AWS, from smaller Docker images and multi-stage builds to smarter compression with gzip and zstd. We discuss the trade-offs between download size and decompression speed, and why optimizing container images is still the best place to start. Then we dive into SOCI (Seekable OCI), an AWS-developed open-source technology that enables lazy loading of container images. Instead of waiting for every image layer to download and unpack, SOCI lets containers start sooner and fetch the files they need on demand. We explain how this works under the hood, including containerd snapshotters, FUSE, zTOCs, compressed spans, and HTTP Range requests. We also explore SOCI support across ECS Fargate, SageMaker, EKS, and ECS on EC2. We share the results of our own open-source benchmark covering 44 configurations and 1,320 ECS task executions. We compare small and large container images, gzip versus zstd, SOCI versus traditional image pulling, ARM64 versus x86-64, and Fargate versus EC2 running Amazon Linux 2023 or Bottlerocket. In some cases, SOCI delivered up to 10× faster container startup for large images on Fargate! Finally, we explain how to create and publish SOCI indexes, explore the tools involved, and discuss when these optimizations are worth adopting. Most importantly, we explain why time to useful work matters more than container startup time alone. Resources mentioned Container startup benchmark: source code and interactive resultsThe hidden design compromises of Docker layersBuilding x86 Rust containers from Apple SiliconAWS deep dive: Lazy loading container images with SOCISOCI Snapshotter on GitHubAWS SageMaker SOCI documentationECS roadmap: SOCI snapshotter supportECS roadmap: containerd support Sponsor Thanks to fourTheorem for powering AWS Bites. We help teams build cloud systems that are simple, scalable, and cost effective. Visit fourtheorem.com. Chapters 00:00 Introduction: How to make containers start faster on AWS01:20 Why container startup speed matters: scaling, deployments, and latency03:17 Docker image optimization: smaller images, multi-stage builds, and caching05:33 gzip vs zstd: Compression trade-offs and faster image pulls08:31 Introducing SOCI (Seekable OCI) and lazy loading09:17 Traditional container startup: Why downloading every layer is slow10:40 How SOCI works: Snapshotters, FUSE, and on-demand file loading15:25 SOCI support on AWS: Fargate, SageMaker, EKS, and ECS on EC216:55 SOCI internals: Container layers, zTOCs, gzip spans, and HTTP Range requests21:54 Our benchmark methodology: 44 configurations and 1,320 ECS tasks24:48 Benchmark results: gzip vs zstd and up to 10× faster startup with SOCI26:56 Fargate vs EC2, Bottlerocket vs Amazon Linux, and ARM64 vs x8628:30 Getting started with SOCI: Index generation, ECR, and OCI tools31:38 Key takeaways: When to use zstd, when to use SOCI, and what to measure33:39 Listener questions, fourTheorem sponsor, and closing Send us your AWS questions Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, Bluesky, or LinkedIn: Eóin: Bluesky | LinkedInLuciano: X/Twitter | Bluesky | LinkedIn

We take a deep dive into Amazon S3 Files, AWS's exciting new managed file system backed by S3! We kick things off by exploring why S3 isn't a traditional file system, covering everything from the lack of true directories and atomic renames to immutable objects and POSIX access control differences. We then walk through the existing solutions people have used to bridge that gap, like S3FS FUSE, MountPoint for S3, FSx for Lustre, and Storage Gateway. From there, we get into the heart of the episode: how S3 Files works, how to set it up, and how it uses EFS under the hood as a caching layer. We share our own real-world benchmarking results comparing S3 Files against various EFS configurations across Lambda and Fargate, and we discuss a real customer project where we put S3 Files to the test. We also cover the important caveats like eventual consistency, the 60-second write-back delay, the lack of cross-account bucket support, and the cost model so you can make an informed decision. Resources mentioned Episode 124: S3 PerformanceEpisode 95: Mounting S3 as a FilesystemAmazon S3 FAQs: S3 FilesfourTheorem S3 Files demo code on GitHubAmazon documentation: Understanding how synchronization worksSponsor Thanks to fourTheorem for powering AWS Bites. We help teams build cloud systems that are simple, scalable, and cost effective. Visit fourtheorem.com. Chapters 00:00 Introduction: Why S3 is amazing but not a file system, and what S3 Files promises to solve01:47 Why S3 is not a file system: no true directories, immutable objects, no atomic renames, expensive listings, and POSIX differences05:23 Existing solutions for mounting S3 as a file system: S3FS FUSE, Python fsspec, Hadoop S3A, MountPoint, FSx for Lustre, File Cache, and Storage Gateway07:16 How S3 Files works: NFS-based access, EFS caching layer, streaming from S3, and supported compute services like EC2, ECS, EKS, and Lambda09:49 Setting up S3 Files: buckets, file system resources, import and expiration rules, mount targets, access points, VPC requirements, and NFS port configuration13:42 S3 Files performance numbers from AWS documentation: throughput, IOPS, latency figures, and why real-world benchmarking is recommended15:39 Benchmarking S3 Files vs EFS configurations on Lambda and Fargate: small and large file reads and writes, memory/CPU impact, and key findings19:48 Downsides and limitations: NFS only, no hard links, no atomic renames, eventual consistency, the 60-second write-back delay, and large-scale rename performance warnings23:05 Real-world project experience: a SaaS multi-tenant architecture, cross-account bucket limitation discovered, and how the team worked around it27:52 Cost breakdown: EFS-equivalent cache pricing, S3 storage costs, reads from cache vs. S3 directly, and how S3 access tiers still apply29:50 Final recap and take: when S3 Files shines, when to be cautious, mixed access pattern warnings, and an invitation to share your own experiences33:42 ClosingSend us your AWS questions Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, Bluesky, or LinkedIn: Eóin: Bluesky | LinkedIn Luciano: X/Twitter | Bluesky | LinkedIn

If you’re curious about building with LLMs, but you want to skip the hype and learn what it takes to ship something reliable in production, this episode is for you.We share our real-world experience building AI-powered apps and the gotchas you hit after the demo: tokens and cost, quotas and throttling, IAM and access friction, marketplace subscriptions, and structured outputs that do not break your JSON parser.We focus on Amazon Bedrock as AWS’s managed inference layer: how to get started with the current access model, how to choose models, how pricing works, and what to watch for in production.We also go deep on structured outputs: constrained decoding, schema design that improves output quality, and how to avoid “grammar compilation timed out”. In this episode, we mentioned the following resources: fourTheorem: Bedrock structured outputs guide https://fourtheorem.com/amazon-bedrock-structured-outputs/Amazon Bedrock https://aws.amazon.com/bedrock/Bedrock docs https://docs.aws.amazon.com/bedrock/latest/userguide/Bedrock pricing https://aws.amazon.com/bedrock/pricing/Structured outputs https://docs.aws.amazon.com/bedrock/latest/userguide/structured-outputs.htmlCross-region inference https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.htmlQuotas https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.htmlThrottling help https://repost.aws/knowledge-center/bedrock-throttling-errorPrompt caching https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.htmlTroubleshooting error codes https://docs.aws.amazon.com/bedrock/latest/userguide/troubleshooting-api-error-codes.html Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠https://twitter.com/eoins⁠ | ⁠https://bsky.app/profile/eoin.sh⁠ | ⁠https://www.linkedin.com/in/eoins/⁠ - ⁠https://twitter.com/loige⁠ | ⁠https://bsky.app/profile/loige.co⁠ | ⁠https://www.linkedin.com/in/lucianomammino/

AWS Lambda is fantastic for small, stateless code on demand. But when your “function” starts looking like a workflow (retries, backoff, long waits, human approvals, callbacks), classic Lambda patterns can feel like a fight: 15-minute max runtime, no built-in state, and orchestration glue everywhere (Step Functions, queues, schedules, and state you did not want to own). In this episode of AWS Bites, Eoin and Luciano explore AWS Lambda Durable Functions, announced at re:Invent 2025. It’s still Lambda (same runtimes and scaling), but with durable execution superpowers: named steps, automatic checkpointing, and the ability to suspend and resume from a safe point without redoing completed work. We unpack the replay/resume model under the hood, when this approach shines, and the gotchas (determinism, idempotency, replay-aware logging, debugging resumed runs). To make it real, we share how we rebuilt PodWhisperer v2 using Durable Functions to orchestrate a GPU-powered WhisperX pipeline, LLM refinement, speaker naming, and caption generation. In this episode, we mentioned the following resources: AWS announcement blog post: https://aws.amazon.com/blogs/aws/build-multi-step-applications-and-ai-workflows-with-aws-lambda-durable-functions/ Durable Functions best practices: https://docs.aws.amazon.com/lambda/latest/dg/durable-best-practices.html The replay model deep dive (Dev.to): https://dev.to/aws/the-replay-model-how-aws-lambda-durable-functions-actually-work-2a79 Build workflows that last (Dev.to): https://dev.to/aws/aws-lambda-durable-functions-build-workflows-that-last-3ac7 Testing Durable Functions in TypeScript (Dev.to): https://dev.to/aws/testing-aws-lambda-durable-functions-in-typescript-5bj2 Developing Durable Functions with AWS SAM (Dev.to): https://dev.to/aws/developing-aws-lambda-durable-functions-with-aws-sam-ga9 Hands-on notes: https://www.andmore.dev/blog/lambda_durable_functions/ PodWhisperer (open source): https://github.com/fourTheorem/podwhisperer/ WhisperX: https://github.com/m-bain/whisperX Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - https://twitter.com/eoins | https://bsky.app/profile/eoin.sh | https://www.linkedin.com/in/eoins/ - https://twitter.com/loige | https://bsky.app/profile/loige.co | https://www.linkedin.com/in/lucianomammino/

AWS just made Lambda… less serverless. Lambda Managed Instances (Lambda MI) brings managed EC2 capacity into Lambda, and it changes the rules: environments stay warm, a single environment can handle multiple concurrent invocations, and scaling becomes proactive and asynchronous instead of “spin up on demand when traffic hits.”In this episode of AWS Bites, Eoin and Luciano break down what Lambda MI unlocks (and what it costs): fewer traditional cold starts, but a new world of capacity planning, headroom, and potential throttling during fast spikes. We compare it to Default Lambda, explain how the new scaling signals work, and what “ACTIVE” really means when publishing can take minutes on a new capacity provider.To make it real, we built a video-processing playground: an API, a CPU-heavy processor, and a Step Functions workflow that scales up before work and back down after. We share the practical lessons, the rough edges (regions, runtimes, mandatory VPC, minimum 2 GB + 1 vCPU, concurrency pitfalls), and the pricing reality: requests + EC2 cost + a 15% management fee. In this episode, we mentioned the following resources: Lambda Managed Instances official docs: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.htmlOur example repo (video processing playground): https://github.com/fourTheorem/lambda-miConcurrency mental model reference (Vercel Fluid Compute): https://vercel.com/fluidLambda MI Node.js runtime best practices (concurrency considerations): https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-nodejs-runtime.html Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

Love AWS Fargate, but occasionally hit the “I need more control” wall (GPUs, storage, network bandwidth, instance sizing)? In this episode of AWS Bites, Eoin and Luciano put the brand-new Amazon ECS Managed Instances (ECS MI) under the microscope as the “middle path” between Fargate simplicity and ECS on EC2 flexibility. We unpack what ECS MI actually is and where it fits in the ECS spectrum, especially how it changes the way you think about clusters and capacity providers. From there we get practical: we talk through the pricing model (EC2 pricing with an additional ECS MI fee that can be a bit counterintuitive if you rely heavily on Reserved Instances or Savings Plans), and we share what it feels like to finally get GPU support in an experience that’s much closer to Fargate than to “full EC2 fleet management”. To make it real, we walk through what we built: a GPU-enabled worker that transcribes podcast audio using OpenAI Whisper, including the end-to-end setup in CDK (roles, capacity provider wiring, task definitions, and service configuration). Along the way we call out the rough edges we ran into, like configuration options that look like they might enable Spot-style behavior, and the operational realities you should expect, such as tasks taking roughly 3–4 minutes to start when ECS needs to provision fresh capacity. We close by mapping out the workloads where ECS MI shines (queue-driven GPU jobs, HPC-ish compute, tighter storage/network control) and the scenarios where it’s probably the wrong choice, like when you need custom AMIs, SSH access, or stricter isolation guarantees. In this episode, we mentioned the following resources: Amazon ECS Managed Instances: ⁠https://aws.amazon.com/ecs/managed-instances/⁠ ECS Managed Instances documentation: ⁠https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html⁠ Amazon Bottlerocket (what it is): ⁠https://aws.amazon.com/bottlerocket/⁠ Our CDK ECS MI template: ⁠https://github.com/fourTheorem/cdk-ecs-mi-template⁠ Ep 42. How do you containerise and run your API with Fargate?: ⁠https://awsbites.com/42-how-do-you-containerise-and-run-your-api-with-fargate/⁠ Ep 72. How do you save cost with ECS?: ⁠https://awsbites.com/72-how-do-you-save-cost-with-ecs/⁠ Ep 10. Lambda or Fargate for containers?: ⁠https://awsbites.com/10-lambda-or-fargate-for-containers/⁠ Ep 38. How do you choose the right compute service on AWS?: ⁠https://awsbites.com/38-how-do-you-choose-the-right-compute-service-on-aws/⁠ Ep 143. Is App Runner better than Fargate?: ⁠https://awsbites.com/143-is-app-runner-better-than-fargate/⁠ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

We dive deep into Strapi, an open-source headless CMS that's changing how we approach content management and CRUD applications. In this episode, we explore how Strapi separates content from presentation, allowing marketing teams to manage content independently while developers maintain full control over the frontend experience. We discuss the powerful features that caught our attention, including the visual content type builder, dynamic zones, components, and the innovative blocks editor that stores content as JSON rather than HTML. We also cover practical aspects like local development workflows, data synchronization between environments, and deployment strategies on AWS. While we highlight some rough edges around documentation and minor bugs, we share our overall positive experience and provide insights into when Strapi might be the right choice for your next project. In this episode, we mentioned the following resources: Strapi CMS: https://strapi.io/Strapi on GitHub: https://github.com/strapi/strapiStrapi Docs: https://docs.strapi.io/Strapi S3 Provider: https://www.npmjs.com/package/@strapi/provider-upload-aws-s3Strapi installation and pre-requisites: https://docs.strapi.io/cms/installation/cliThe React Block Content renderer: https://github.com/strapi/blocks-react-rendererContentful: https://www.contentful.com/Storyblok: https://www.storyblok.com/Sanity: https://www.sanity.io/HyGraph: https://hygraph.com/Byline CMS: https://bylinecms.app/ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

What if “Java is too old for serverless” is the myth holding your team back in 2025? We put it to the test with Mark Sailes (ex-AWS, Java-on-Lambda expert). In this AWS Bites episode we get specific: when Java is the right call for Lambda and when it isn’t, how to hit real latency targets, and the exact levers that matter in production—SnapStart, provisioned concurrency, smart JVM/GC settings, and whether GraalVM is worth it. We compare vanilla Java, Micronaut, Quarkus, and Spring Boot for startup and memory, share realistic p95/p99 expectations, and outline fast feedback loops with Testcontainers and LocalStack.If Java on Lambda sounds risky, this might change your mind. Stick around for Mark’s tuning checklist and our verdict on when to bet on Java vs pick another runtime. Big shoutout to fourTheorem for powering yet another episode of AWS Bites. At fourTheorem, we believe the cloud should be simple, scalable, and cost-effective, and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, or trying to keep cloud spend under control our team has your back. Visit ⁠⁠⁠⁠https://fourTheorem.com⁠⁠⁠⁠ to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: Mark Sailes's website and books: https://www.sailes.co.uk/booksMark's YouTube channel: https://youtube.com/@javainthecloudRunning Java effectively on serverless (ServerlessLand): https://serverlessland.com/content/service/lambda/guides/effectively-running-java-on-serverless/1-introductionLambda execution visualizer: https://lambda-sim.sailes.co.uk/Lambda SnapStart for Java simulator: https://www.sailes.co.uk/learn/lambda-snapstartPenna logging library for Java: https://github.com/hkupty/pennaTestcontainers for Java: https://java.testcontainers.org/Localstack: https://docs.localstack.cloud/aws/Micronaut: https://micronaut.io/Quarkus: https://quarkus.io/GraalVM: https://www.graalvm.org/AWS response to the Log4j issue: https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

What if AWS built an IDE to rival your favorite editor? Turns out they did!In this episode of AWS Bites, we dive into Kiro, an AI centric fork of VS Code that tries to turn an empty repo and a loose idea into working software. Kiro imports your VS Code world, then guides you through requirements, design, and a clear task plan before an agent gets to work. We share what clicked, what tripped us up, and how Kiro’s spec driven approach compares to Cursor or Claude Code. We also cover status, limits, pricing, and what this could become if AWS leans in with deep cloud integration. Stick around for our take on whether you should switch or wait. Big shoutout to fourTheorem for powering yet another episode of AWS Bites. At fourTheorem, we believe the cloud should be simple, scalable, and cost-effective, and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, or trying to keep cloud spend under control our team has your back. Visit ⁠⁠⁠https://fourTheorem.com⁠⁠⁠ to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: Kiro website: https://kiro.dev/ Kiro docs on Agent Hooks: https://kiro.dev/docs/hooks/ Kiro docs on Steering: https://kiro.dev/docs/steering/ Kiro pricing plans blog: https://kiro.dev/blog/pricing-plans-are-live/ Cargo Lambda: https://www.cargo-lambda.info/ Episode 64: how do you write Lambda functions in Rust?: https://awsbites.com/64-how-do-you-write-lambda-functions-in-rust/ Kiro GitHub issue: https://github.com/kirodotdev/Kiro/issues/2004 Amazon Q developer CLI: https://github.com/aws/amazon-q-developer-cli Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/ ⁠⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

What if AWS had its own version of Killed by Google? Well… turns out it kind of does.In this episode of AWS Bites, we explore the AWS Product Lifecycle page, the official place where AWS quietly lists products and services that are being deprecated, shut down, or closed to new customers. If you rely on AWS in production, this is a page you’ll want to bookmark.We walk through what’s on the list today, from Amazon Pinpoint to IoT Analytics and beyond, and we even throw in some predictions of what might be next to hit the chopping block. App Runner vs Beanstalk? API Gateway REST vs HTTP? Let the speculation begin! Big shoutout to fourTheorem for powering yet another episode of AWS Bites. At fourTheorem, we believe the cloud should be simple, scalable, and cost-effective, and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, or trying to keep cloud spend under control our team has your back. Visit ⁠⁠https://fourTheorem.com⁠⁠ to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: AWS Product Lifecycle Page: ⁠⁠https://aws.amazon.com/products/lifecycle/⁠⁠AWS Blog – Introducing the AWS Product Lifecycle Page: ⁠⁠https://aws.amazon.com/blogs/aws/introducing-the-aws-product-lifecycle-page-and-aws-service-availability-updates/⁠⁠AWS Bites Episode 98 – Amazon Pinpoint Quota Changes: ⁠⁠https://awsbites.com/98⁠⁠AWS Bites Episode 74 – API Gateway REST vs HTTP: ⁠⁠https://awsbites.com/74⁠⁠AWS Bites Episode 76 – AWS Copilot: ⁠⁠https://awsbites.com/76⁠⁠AWS Bites Episode 143 – Is App Runner Better than Fargate?: ⁠⁠https://awsbites.com/143⁠⁠API Gateway Routing Rules: ⁠⁠https://aws.amazon.com/blogs/compute/dynamically-routing-requests-with-amazon-api-gateway-routing-rules/⁠⁠Alexa+ and the future of generative AI at Amazon: ⁠⁠https://www.aboutamazon.com/news/devices/new-alexa-generative-artificial-intelligence⁠⁠ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

Amazon Aurora DSQL promises to bring a truly serverless experience to SQL databases. But does it actually deliver? In this episode of AWS Bites, we put Aurora DSQL to the test. We explore what makes it exciting, how it compares to traditional Aurora Serverless, and where it falls short. You’ll hear what changed since our last Aurora deep dive, and why DSQL might be the PostgreSQL-compatible serverless database you’ve been waiting for. Big shoutout to fourTheorem for powering yet another episode of AWS Bites. At fourTheorem, we believe the cloud should be simple, scalable, and cost-effective, and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, or trying to keep cloud spend under control our team has your back. Visit ⁠https://fourTheorem.com⁠ to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: AWS Blog – Amazon Aurora DSQL is Now Generally Available: ⁠https://aws.amazon.com/blogs/aws/amazon-aurora-dsql-is-now-generally-available/⁠AWS Blog – Introducing Amazon Aurora DSQL: ⁠https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/⁠Aurora DSQL Deep Dive by Amazon: ⁠https://www.youtube.com/watch?v=GCdAngjKZY4⁠DSQL Example Application by fourTheorem: ⁠https://github.com/fourTheorem/dsql-example/⁠PlanetScale Docs – Why Does PlanetScale Not Recommend Constraints: ⁠https://planetscale.com/docs/vitess/operating-without-foreign-key-constraints#why-does-planetscale-not-recommend-constraints-⁠Marc Bowes – How to Spend a Dollar with DSQL: ⁠https://marc-bowes.com/dsql-how-to-spend-a-dollar.html⁠Alessandro Volpicella – Amazon DSQL Pricing Guide: ⁠https://awsfundamentals.com/blog/amazon-dsql-pricing-guide⁠BinaryHeap Blog – First Look at DSQL (The Naughty List): ⁠https://binaryheap.com/first-look-dsql/⁠AWS Bites – Aurora Deep Dive (Episode 122): ⁠https://awsbites.com/122⁠ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

Cost is always top of mind when building in the cloud, and recently AWS has introduced some changes worth paying attention to. In this episode of AWS Bites, we explore a shift that caught many by surprise: the “free” INIT phase for Lambda’s managed runtimes is going away. That cold start time that used to fly under the billing radar? It's now part of the cost. We dig into what this means for your workloads, who might feel the impact, and whether this gives languages like Rust and Go an extra edge. But it’s not all bad news. AWS has also rolled out new pricing tiers for CloudWatch Logs, making it cheaper for high-volume accounts. On top of that, there are new options to send logs directly to S3 or Firehose, helping simplify pipelines and reduce costs. We close with a few tips to help you keep your Lambda and logging spend under control. If you're building on AWS and care about efficiency, this is one you won't want to miss. Big shoutout to fourTheorem for powering yet another episode of AWS Bites. At fourTheorem, we believe the cloud should be simple, scalable, and cost-effective, and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, or trying to keep cloud spend under control our team has your back. Visit https://fourTheorem.com to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: AWS Blog – Tiered Pricing for AWS Lambda: https://aws.amazon.com/blogs/compute/introducing-tiered-pricing-for-aws-lambda/Luc van Donkersgoed – When is the Lambda INIT phase free and when is it billed?: https://lucvandonkersgoed.com/2022/04/09/when-is-the-lambda-init-phase-free-and-when-is-it-billed/AWS Bites – Explaining Lambda Runtimes (Episode 104): https://awsbites.com/104-explaining-lambda-runtimes/AWS Blog – Standardized Billing for Lambda INIT Phase: https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/Lambda Cold Start Benchmarks by Maxim David: https://maxday.github.io/lambda-perf/Duckbill Group Blog – Lambda Logs Just Got Cheaper: https://www.duckbillgroup.com/blog/lambda-logs-just-got-cheaper/AWS Bites – Becoming a Logs Ninja with CloudWatch (Episode 35): https://awsbites.com/35-how-can-you-become-a-logs-ninja-with-cloudwatch Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠⁠ | ⁠⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠⁠ | ⁠⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

Picture this. You’ve got a web app built with Rust and Solid.js. It started life running on a dusty on-prem server, but now it's time to move it to the cloud. The clock is ticking. You could take the well-worn AWS path: set up a VPC, configure subnets, attach an ALB, define IAM roles, and deploy with Fargate. Or you could try something different. In this episode of AWS Bites, we share the real story of migrating a monolithic containerized app to AWS App Runner. It promises to take your code, build it, deploy it, and scale it with minimal effort. But does it really deliver? We compare App Runner with Fargate based on hands-on experience. You’ll learn where App Runner shines, where it gets in the way, and how we handled everything from custom domains to background job processing. You’ll also hear when we would still choose Fargate, and why. If you've ever hoped for a Heroku-like experience on AWS, or you want to simplify your container deployments without giving up too much control, this episode is for you. AWS Bites is brought to you in association with fourTheorem. At fourTheorem, we believe serverless should be simple, scalable, and cost-effective — and we help teams do just that. Whether you’re diving into containers, stepping into event-driven architecture, or scaling a global SaaS platform on AWS, our team has your back. Visit https://fourTheorem.com to see how we can help you build faster, better, and with more confidence using AWS cloud! In this episode, we mentioned the following resources: Last Week in AWS: The 17 Ways to Run Containers on AWS: https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/GitHub Issue - App Runner scale to zero discussion: https://github.com/aws/apprunner-roadmap/issues/9Custom Domain with CloudFormation (Mark van Holsteijn, Xebia): https://xebia.com/blog/configure-custom-domain-for-aws-apprunner-service-using-cloudformation/AWS Docs - App Runner hosted zone IDs: https://docs.aws.amazon.com/general/latest/gr/apprunner.html Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠https://bsky.app/profile/eoin.sh⁠⁠⁠ | ⁠⁠⁠https://www.linkedin.com/in/eoins/⁠⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠https://bsky.app/profile/loige.co⁠⁠⁠ | ⁠⁠⁠https://www.linkedin.com/in/lucianomammino/

We discuss common use cases and challenges for copying data between S3 buckets and S3-compatible object storage services. We share our experience building an open source Node.js CLI tool called S3-Migrate to efficiently migrate data with separate source and destination credentials. We cover performance considerations like streaming, chunk sizes, concurrency and parallelism. AWS Bites is brought to you in association with fourTheorem. If you need a friendly partner to support you and work with you to de-risk any AWS migration or development project, check them out at ⁠⁠⁠fourtheorem.com⁠⁠⁠ In this episode, we mentioned the following resources: s3-migrate CLI tool: https://github.com/lmammino/s3-migrateDigitalOcean Spaces Object Storage: https://docs.digitalocean.com/products/spaces/Cloudflare R2: https://www.cloudflare.com/en-gb/developer-platform/products/r2/Backblaze B2: https://www.backblaze.com/cloud-storageWasabi Cloud Storage: https://wasabi.com/Linode / Akamai Object Storage: https://www.linode.com/products/object-storage/MinIO (Self-hosted S3-compatible storage): https://min.io/Basecamp / Hey’s move away from S3: https://world.hey.com/dhh/it-s-five-grand-a-day-to-miss-our-s3-exit-b8293563AWS re:Post - How to move objects between S3 buckets: https://repost.aws/knowledge-center/move-objects-s3-bucketAWS Labs - Utility for S3 Migration: https://github.com/awslabs/utility-for-s3-migrations3s3mirror (Java-based tool): https://github.com/cobbzilla/s3s3mirrorrclone S3 Support: https://rclone.org/s3/knox-copy (Ruby-based, deprecated): https://github.com/goodeggs/knox-copyFlexify.io (paid cloud migration service): https://flexify.io/ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠https://bsky.app/profile/eoin.sh⁠⁠ | ⁠⁠https://www.linkedin.com/in/eoins/⁠⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠⁠ | ⁠⁠https://bsky.app/profile/loige.co⁠⁠ | ⁠⁠https://www.linkedin.com/in/lucianomammino/

In this episode, we provide an overview of AWS Step Functions and dive deep into the powerful new JSONata and variables features. We explain how JSONata allows complex JSON transformations without custom Lambda functions, enabling more serverless workflows. The variables feature also helps avoid the previous 256KB state size limit. We share examples from real projects showing how these features simplify workflows, reduce costs and enable new use cases. AWS Bites is brought to you in association with fourTheorem. If you need a friendly partner to support you and work with you to de-risk any AWS migration or development project, check them out at ⁠⁠fourtheorem.com⁠⁠ In this episode, we mentioned the following resources: JSONata and variables official launch post: https://aws.amazon.com/blogs/compute/simplifying-developer-experience-with-variables-and-jsonata-in-aws-step-functions/JSONata exerciser: https://try.jsonata.org/Stedi JSONata playground: https://www.stedi.com/jsonata/playgroundEpisode 103: Building GenAI Features with Bedrock https://awsbites.com/103-building-genai-features-with-bedrock/Episode 63: How to automate transcripts with Amazon Transcribe and OpenAI Whisper https://awsbites.com/63-how-to-automate-transcripts-with-amazon-transcribe-and-openai-whisper/ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter, BlueSky or LinkedIn:- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠https://bsky.app/profile/eoin.sh⁠ | ⁠https://www.linkedin.com/in/eoins/⁠- ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠⁠ | ⁠https://bsky.app/profile/loige.co⁠ | ⁠https://www.linkedin.com/in/lucianomammino/