<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cloud on The David Page</title><link>https://thedavidpage.pages.dev/posts/cloud/</link><description>Recent content in Cloud 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/index.xml" rel="self" type="application/rss+xml"/><item><title>"Policy ArmResourceId has incorrect formatting" Has Nothing to Do With ARM Resource IDs</title><link>https://thedavidpage.pages.dev/posts/cloud/azure/front-door/waf-policy-arm-resource-id-formatting-error/</link><pubDate>Sun, 02 Aug 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/azure/front-door/waf-policy-arm-resource-id-formatting-error/</guid><description>&lt;p&gt;&lt;strong&gt;&lt;code&gt;Policy ArmResourceId has incorrect formatting&lt;/code&gt; — an Azure CLI error message that cost me a whole debugging session, when the real reason was just a hyphen in the policy name.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;Setting up an Azure Front Door WAF Policy through the CLI, I ran into an error that — as it turns out — a lot of other people have been hitting for over three years, ever since it was first reported back in December 2022.&lt;/p&gt;</description></item><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>When RDS Proxy Eats 70% of Your Total CloudWatch Ingestion Cost</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/rds/rds-proxy-cloudwatch-log-cost/</link><pubDate>Sun, 02 Aug 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/rds/rds-proxy-cloudwatch-log-cost/</guid><description>&lt;p&gt;&lt;strong&gt;Pulling up a client&amp;rsquo;s Cost Explorer, I found RDS Proxy responsible for 70% of their total CloudWatch Logs ingestion cost — while their actual &amp;ldquo;RDS Proxy&amp;rdquo; line item looked completely normal.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;My first reaction, and the first reaction of nearly every client I&amp;rsquo;ve shown this number to, is always the same: &lt;em&gt;&amp;ldquo;I&amp;rsquo;m already paying for RDS Proxy by the vCPU-hour — why is it also eating into my CloudWatch bill? Aren&amp;rsquo;t those two completely separate things?&amp;rdquo;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>AWS Lambda's /tmp Directory Isn't as Clean as You Think</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/lambda/lambda-tmp-warm-start-persistence/</link><pubDate>Sun, 02 Aug 2026 08:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/lambda/lambda-tmp-warm-start-persistence/</guid><description>&lt;p&gt;&lt;strong&gt;Assuming every Lambda invocation runs in a fresh, isolated environment is a very reasonable guess. It&amp;rsquo;s also wrong.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;A lot of developers write Lambda functions on the assumption that each invocation starts in a completely clean, isolated sandbox — new environment, empty disk, nothing left behind from whatever ran before. That assumption is exactly what &amp;ldquo;serverless&amp;rdquo; seems to promise. It isn&amp;rsquo;t quite what happens.&lt;/p&gt;
&lt;h2 id="-whats-actually-happening-warm-starts"&gt;🔍 What&amp;rsquo;s actually happening: warm starts&lt;/h2&gt;
&lt;p&gt;To keep invocations fast, Lambda reuses the same underlying execution environment (container) for consecutive invocations whenever it can — this is a &lt;strong&gt;warm start&lt;/strong&gt;, as opposed to spinning up a brand-new one from scratch (a &lt;strong&gt;cold start&lt;/strong&gt;). Reusing the container is exactly what makes warm invocations fast.&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><item><title>The Invisible Files on S3: Paying for Data You Can't See (Incomplete Multipart Uploads)</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/s3/s3-incomplete-multipart-uploads/</link><pubDate>Sat, 01 Aug 2026 14:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/s3/s3-incomplete-multipart-uploads/</guid><description>&lt;p&gt;&lt;strong&gt;A large upload to S3 dies mid-transfer. The parts that already made it up don&amp;rsquo;t just vanish — they keep sitting there, billed every month, invisible to the console and to &lt;code&gt;aws s3 ls&lt;/code&gt;.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;When an application uploads a large file to S3 using multipart upload and the connection drops partway through, the obvious assumption is: the upload failed, nothing happened, no harm done. That assumption is wrong in a way that quietly costs money.&lt;/p&gt;</description></item><item><title>iam:PassRole + Wildcard: The Privilege Escalation Hiding in Plain Sight</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/iam/iam-passrole-privilege-escalation/</link><pubDate>Sat, 01 Aug 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/iam/iam-passrole-privilege-escalation/</guid><description>&lt;p&gt;&lt;strong&gt;A developer account with nothing but &lt;code&gt;lambda:CreateFunction&lt;/code&gt; and a wildcard &lt;code&gt;iam:PassRole&lt;/code&gt; can walk itself up to full Administrator — no exploit, no misconfigured bucket, just permissions doing exactly what they were asked to do.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;This one doesn&amp;rsquo;t show up as a vulnerability scan finding or a CVE — it&amp;rsquo;s a permissions grant that looks completely reasonable in a policy review, right up until someone connects the dots.&lt;/p&gt;
&lt;h2 id="-the-convenient-habit"&gt;😱 The convenient habit&lt;/h2&gt;
&lt;p&gt;To make deployments easier, it&amp;rsquo;s extremely common to grant developer accounts &lt;code&gt;iam:PassRole&lt;/code&gt; against &lt;code&gt;*&lt;/code&gt; (a wildcard covering every role in the account). The reasoning is simple and, on its own, sounds harmless: developers need to attach an IAM role to whatever they deploy — a Lambda function, an EC2 instance — and wildcarding &lt;code&gt;PassRole&lt;/code&gt; means nobody has to update a policy every time a new role gets created.&lt;/p&gt;</description></item><item><title>Archiving Millions of Small Files to Glacier: When the 'Cheap Storage' Trick Backfires</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/s3/glacier-small-files-cost-trap/</link><pubDate>Fri, 10 Jul 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/s3/glacier-small-files-cost-trap/</guid><description>&lt;p&gt;&lt;strong&gt;S3 Glacier Deep Archive is famous for dirt-cheap long-term storage. Point a Lifecycle Rule at millions of tiny log files, though, and &amp;ldquo;cheap&amp;rdquo; can flip into &amp;ldquo;more expensive than doing nothing at all.&amp;rdquo;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;I once confidently set up an S3 Lifecycle Rule: &lt;em&gt;&amp;ldquo;any object older than 30 days automatically transitions to Glacier Deep Archive.&amp;rdquo;&lt;/em&gt; Simple, standard cost-optimization advice. The catch: the bucket in question held millions of small log files, each only a few KB.&lt;/p&gt;</description></item><item><title>The NAT Gateway 'Trick' That Was Actually Billing You for ECR, Not S3</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/networking/nat-gateway-s3-gateway-endpoint/</link><pubDate>Thu, 18 Jun 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/networking/nat-gateway-s3-gateway-endpoint/</guid><description>&lt;p&gt;&lt;strong&gt;A client&amp;rsquo;s NAT Gateway bill hit a record ~$3,000/month. VPC Flow Logs pointed straight at S3 — except the client swore they barely used S3. Here&amp;rsquo;s what was actually going on.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;A client came to us about a month after going live with a new system built by a different vendor — one they no longer had a maintenance contract with. Their first full invoice after launch showed a &lt;strong&gt;NAT Gateway bill at a record high, roughly $3,000/month&lt;/strong&gt;. Standard architecture on their end: ECS services running in private subnets for security, NAT Gateway for outbound access. Textbook setup on paper — which made a bill that high, right out of the gate, more confusing, not less.&lt;/p&gt;</description></item><item><title>That CloudWatch Logs Insights Query Just Cost You $2.50</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/cloudwatch/cloudwatch-logs-insights-expensive-queries/</link><pubDate>Tue, 05 May 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/cloudwatch/cloudwatch-logs-insights-expensive-queries/</guid><description>&lt;p&gt;&lt;strong&gt;One click on CloudWatch Logs Insights, a few seconds waiting for results — and a bill for scanning half a terabyte of logs.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;CloudWatch Logs Insights is a genuinely convenient SQL-like log query tool. The way AWS bills for it, though, catches a lot of people off guard.&lt;/p&gt;
&lt;h2 id="-the-common-mistake"&gt;😱 The common mistake&lt;/h2&gt;
&lt;p&gt;Open Logs Insights, pick a log group that&amp;rsquo;s accumulated 6 months of logs (~500 GB), type a broad search query with no explicit time range set, hit &lt;strong&gt;Run&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>DynamoDB On-Demand Has a Ceiling — and Flash Sales Find It</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/dynamodb/dynamodb-on-demand-flash-sale-throttling/</link><pubDate>Fri, 10 Apr 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/dynamodb/dynamodb-on-demand-flash-sale-throttling/</guid><description>&lt;p&gt;&lt;strong&gt;On-Demand is marketed as scale-to-anything with zero capacity planning. It isn&amp;rsquo;t quite that — and a flash sale is exactly the kind of event that finds the gap.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;DynamoDB On-Demand is pitched as the effortless auto-scaling option — no need to pre-calculate WCU/RCU. That word &amp;ldquo;automatic&amp;rdquo; comes with a fine-print condition that matters a lot the first time you hit it.&lt;/p&gt;
&lt;h2 id="-the-disaster-scenario"&gt;😱 The disaster scenario&lt;/h2&gt;
&lt;p&gt;A system runs smoothly at a steady ~1,000 requests/second. At midnight, a flash sale kicks off, and traffic jumps to ~20,000 requests/second within seconds.&lt;/p&gt;</description></item><item><title>Cutting a Client's CloudFront Bill by ~87% with AWS's New Flat-Rate Plans</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/cloudfront/cloudfront-flat-rate-pricing/</link><pubDate>Mon, 02 Mar 2026 10:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/cloudfront/cloudfront-flat-rate-pricing/</guid><description>&lt;p&gt;&lt;strong&gt;A client came to us in shock over their CloudFront bill — $1,500/month during their peak sales period. Here&amp;rsquo;s how we got it down to $200/month.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;A client reached out to us after opening their AWS invoice during their busiest sales month of the year and seeing &lt;strong&gt;CloudFront alone hit ~$1,500/month&lt;/strong&gt;, with the vast majority of that coming from data transfer out to their customers. They weren&amp;rsquo;t looking for a full re-architecture — they just wanted to know: &lt;em&gt;is this normal, and can anything be done about it?&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The MTU 9001 Trap: Flaky Connections Over VPC Peering and VPN</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/networking/mtu-9001-path-mtu-discovery-black-hole/</link><pubDate>Fri, 20 Feb 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/networking/mtu-9001-path-mtu-discovery-black-hole/</guid><description>&lt;p&gt;&lt;strong&gt;Ping works. SSH works. But the moment the app sends a large payload over VPN or cross-region peering, it just&amp;hellip; hangs. This is why.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;This is a classic debugging trap that can burn a new DevOps engineer several days, precisely because the system never throws a clear error log.&lt;/p&gt;
&lt;h2 id="-the-confusing-symptom"&gt;😱 The confusing symptom&lt;/h2&gt;
&lt;p&gt;Two EC2 instances in different VPCs, connected over VPC peering, VPN, or Direct Connect. Ping between them responds fine. SSH works fine too. But the moment the application transfers a large file, or sends a long JSON payload over an API call on that same connection, the request hangs indefinitely until it eventually times out.&lt;/p&gt;</description></item><item><title>The Hidden Cost of Cross-AZ Data Transfer on AWS</title><link>https://thedavidpage.pages.dev/posts/cloud/aws/networking/cross-az-data-transfer-cost/</link><pubDate>Wed, 14 Jan 2026 09:00:00 +0700</pubDate><guid>https://thedavidpage.pages.dev/posts/cloud/aws/networking/cross-az-data-transfer-cost/</guid><description>&lt;p&gt;&lt;strong&gt;Multi-AZ for high availability quietly turned into a network bill bigger than the compute bill — here&amp;rsquo;s why.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Hi everyone 👋&lt;/p&gt;
&lt;p&gt;This is one of those &amp;ldquo;hidden landmines&amp;rdquo; on AWS: things that never throw a clear error, never show up in a StackOverflow top answer, but can quietly make a system flaky or burn thousands of dollars a month. First up: cross-AZ data transfer.&lt;/p&gt;
&lt;h2 id="-the-assumption-that-gets-everyone"&gt;😱 The assumption that gets everyone&lt;/h2&gt;
&lt;p&gt;Everyone knows data transfer &lt;em&gt;out to the internet&lt;/em&gt; costs money. Far fewer people realize that &lt;strong&gt;traffic between Availability Zones inside the same Region isn&amp;rsquo;t free either&lt;/strong&gt; — a lot of us assume &amp;ldquo;it&amp;rsquo;s all internal, so it&amp;rsquo;s free.&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>