<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>EC2 on The David Page</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/ec2/</link><description>Recent content in EC2 on The David Page</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 02 Aug 2026 09:00:00 +0700</lastBuildDate><atom:link href="https://thedavidpage.pages.dev/posts/cloud/aws/ec2/index.xml" rel="self" type="application/rss+xml"/><item><title>HTTP 429 When Calling the Gemini API on AWS</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/ec2/http-429-gemini-api-on-aws/</link><pubDate>Sun, 02 Aug 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/ec2/http-429-gemini-api-on-aws/</guid><description>&lt;p&gt;&lt;strong&gt;Running into HTTP 429 calling the Gemini API on AWS — and how our team fixed it.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;While building our capstone project (a RAG chatbot running on EC2 that calls the Gemini API), we hit an error that anyone who&amp;rsquo;s integrated a third-party API has probably run into at least once: &lt;strong&gt;HTTP 429 – Too Many Requests&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;At first we were pretty confused, because everything ran fine locally — no signs of trouble at all. But the moment we deployed to EC2 and tested with multiple concurrent users, requests piled up and Gemini politely declined with a 429.&lt;/p&gt;</description></item><item><title>The IMDSv2 Hop Limit Trap When Running Containers on EC2</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/ec2/imdsv2-hop-limit-container/</link><pubDate>Sat, 01 Aug 2026 18:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/ec2/imdsv2-hop-limit-container/</guid><description>&lt;p&gt;&lt;strong&gt;Switching to IMDSv2 is the right security move, full stop. Do it on an EC2 instance running Docker containers, though, and the app inside loses access to its IAM Role credentials immediately.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;Upgrading from IMDSv1 to IMDSv2 is standard, correct security guidance — it closes off a real class of credential-theft attacks against the EC2 instance metadata service. But flipping that switch on an instance that runs its application inside a Docker container can break AWS SDK access instantly, with no obvious explanation in the error message.&lt;/p&gt;</description></item></channel></rss>