<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AWS on Yash Chudasama</title>
    <link>https://www.yashchudasama.com/tags/aws/</link>
    <description>Recent content in AWS on Yash Chudasama</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>Copyright © 2026, Yash Chudasama; all rights reserved.</copyright>
    <lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.yashchudasama.com/tags/aws/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cloud Architecture for Real-Time Media Workloads</title>
      <link>https://www.yashchudasama.com/blog/tech/cloud-media-workloads/</link>
      <pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.yashchudasama.com/blog/tech/cloud-media-workloads/</guid>
      <description>Cloud providers are optimized for request-response workloads. Real-time media — WebRTC, voice AI, live streaming — breaks their assumptions in fundamental ways.&#xA;Standard cloud architecture patterns (load balancers, auto-scaling groups, stateless microservices) don&amp;rsquo;t work for media. Here&amp;rsquo;s what does, and why the default advice from cloud providers will cost you latency, money, or both.&#xA;Why Media Workloads Are Different A typical web request hits a load balancer, gets routed to any available instance, processes for 50-200ms, and returns.</description>
    </item>
  </channel>
</rss>
