<?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 DevOps &amp; Rock&#39;N&#39;Roll</title>
    <link>https://artazar.pages.dev/tags/aws/</link>
    <description>Recent content in Aws on DevOps &amp; Rock&#39;N&#39;Roll</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 19 Aug 2026 15:55:02 +0700</lastBuildDate>
    <atom:link href="https://artazar.pages.dev/tags/aws/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Letting Claude loose on an AWS account with Prowler</title>
      <link>https://artazar.pages.dev/blog/13-claude-prowler-security-scan/</link>
      <pubDate>Tue, 11 Aug 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/13-claude-prowler-security-scan/</guid>
      <description>&lt;p&gt;I had been meaning to run a proper security audit of one of our AWS accounts for months. The task kept losing to more urgent things, because it isn&amp;rsquo;t a single job — it&amp;rsquo;s install a scanner, work out its permissions, run it for an hour, then read several thousand findings and decide which twelve actually matter.&lt;/p&gt;&#xA;&lt;p&gt;So I gave the whole thing to Claude Code and watched. The interesting part wasn&amp;rsquo;t that it worked; it was where the effort actually went.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Karpenter consolidation without the pager fatigue</title>
      <link>https://artazar.pages.dev/blog/11-karpenter-consolidation-spot/</link>
      <pubDate>Tue, 16 Jun 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/11-karpenter-consolidation-spot/</guid>
      <description>&lt;p&gt;Karpenter&amp;rsquo;s consolidation is the feature that pays for the migration. It watches your cluster, notices that the workload fits on cheaper capacity, and rearranges the nodes to match. On a fleet running mostly spot, the savings are real and continuous — when I went through &lt;a href=&#34;https://artazar.pages.dev/blog/04-cutting-the-eks-bill/&#34; &gt;the cost optimisation exercise&lt;/a&gt;, it was one of the few changes that measurably moved the bill.&lt;/p&gt;&#xA;&lt;p&gt;It is also a machine that deliberately deletes your nodes, all day, forever. If your workloads aren&amp;rsquo;t ready for that, consolidation turns into a steady drip of alerts that eventually teaches everyone to ignore the alerting channel — which is a worse outcome than paying for the oversized nodes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IRSA to Pod Identity: notes from the migration</title>
      <link>https://artazar.pages.dev/blog/10-irsa-to-pod-identity/</link>
      <pubDate>Tue, 02 Jun 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/10-irsa-to-pod-identity/</guid>
      <description>&lt;p&gt;IRSA has been the way to give a Kubernetes pod an AWS identity since 2019, and it works. It also requires an OIDC provider per cluster, a trust policy per role that names a specific cluster&amp;rsquo;s OIDC issuer, and a mental model involving projected service account tokens that you re-derive from scratch every time something breaks.&lt;/p&gt;&#xA;&lt;p&gt;EKS Pod Identity does the same job with less machinery. I&amp;rsquo;ve now moved a few clusters over and it&amp;rsquo;s mostly good news, with a couple of edges worth knowing before you start.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Terragrunt: deleting the boilerplate you were told to write</title>
      <link>https://artazar.pages.dev/blog/09-terragrunt-less-boilerplate/</link>
      <pubDate>Tue, 19 May 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/09-terragrunt-less-boilerplate/</guid>
      <description>&lt;p&gt;Terragrunt exists to keep you DRY, and then you open a mature Terragrunt repository and find ninety &lt;code&gt;terragrunt.hcl&lt;/code&gt; files that are eighty percent identical. There&amp;rsquo;s a joke in there somewhere.&lt;/p&gt;&#xA;&lt;p&gt;It isn&amp;rsquo;t Terragrunt&amp;rsquo;s fault. The default onboarding path — copy the folder next door, change the inputs — is the fastest way to a working stack and the slowest way to a maintainable one. Here&amp;rsquo;s what I strip out when I inherit one of these.&lt;/p&gt;</description>
    </item>
    <item>
      <title>EKS Access Entries: one ARN, one cluster, no sharing</title>
      <link>https://artazar.pages.dev/blog/07-eks-access-entries/</link>
      <pubDate>Tue, 21 Apr 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/07-eks-access-entries/</guid>
      <description>&lt;p&gt;EKS Access Entries replaced the &lt;code&gt;aws-auth&lt;/code&gt; ConfigMap and made cluster authorization a proper AWS API object instead of a YAML blob that you edited with trembling hands, hoping you wouldn&amp;rsquo;t lock yourself out. It&amp;rsquo;s a genuine improvement. But moving auth into the API surface also moves it into Terraform state, and that&amp;rsquo;s where it gets interesting.&lt;/p&gt;&#xA;&lt;p&gt;The error that sent me down this road:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;Error: creating EKS Access Entry (test-spain-001:arn:aws:iam::123456789012:role/PlatformAdmin):&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;ResourceInUseException: The specified access entry resource is already in use&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;on this cluster.&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;My first reaction was the wrong one: &lt;em&gt;are access entries global? Did creating one for cluster A break cluster B?&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Fargate profiles and the art of waiting your turn</title>
      <link>https://artazar.pages.dev/blog/06-fargate-profile-deletion/</link>
      <pubDate>Tue, 07 Apr 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/06-fargate-profile-deletion/</guid>
      <description>&lt;p&gt;There is a special kind of Terraform error that only shows up when you destroy things. Your &lt;code&gt;apply&lt;/code&gt; has been green for months, everyone is happy, and then one day you run a &lt;code&gt;terragrunt destroy&lt;/code&gt; on a test cluster and get this:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;Error: deleting EKS Fargate Profile (test-spain-001:test-spain-001-karpenter-2a):&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;operation error EKS: DeleteFargateProfile, https response error StatusCode: 409,&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;ResourceInUseException: Cannot delete Fargate profile&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;test-spain-001-karpenter-2a because cluster test-spain-001 currently has&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;Fargate profile test-spain-001-karpenter-2b in status DELETING&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Run it again — it works. Run it on the next cluster — it fails again. Welcome to the club.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cutting the EKS bill: what actually moved the needle</title>
      <link>https://artazar.pages.dev/blog/04-cutting-the-eks-bill/</link>
      <pubDate>Tue, 15 Jul 2025 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/04-cutting-the-eks-bill/</guid>
      <description>&lt;p&gt;Every cost optimisation article opens with a list of twenty things you should do. Most of them save single-digit percentages and cost you a week each. This is the shorter, more honest version: the things that actually changed my EKS bill, roughly in order of return per hour of effort, and the ones that didn&amp;rsquo;t.&lt;/p&gt;&#xA;&lt;p&gt;Context so the numbers mean something: three clusters, a few hundred pods, mixed prod and dev, one region, Karpenter-managed nodes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
