<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AKS on Nahuel Hernandez</title>
    <link>https://nahuelhernandez.com/tags/aks/</link>
    <description>Recent content in AKS on Nahuel Hernandez</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 22 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://nahuelhernandez.com/tags/aks/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Translating an AWS EKS Stack to Azure AKS: The Architectural Decisions Behind a Real Migration</title>
      <link>https://nahuelhernandez.com/blog/translating_eks_to_aks_migration/</link>
      <pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://nahuelhernandez.com/blog/translating_eks_to_aks_migration/</guid>
      <description>There is a comforting table on Microsoft Learn that maps AWS services to Azure services. RDS to Flexible Server. Cognito to Entra ID B2C. SQS to Service Bus. ECR to ACR. S3+CloudFront to Blob+Front Door. The table is correct. It is also misleading, because it implies the migration is a translation problem.
It is not. The translation is the easy part. The hard part is the sequence of architectural decisions you have to make once you accept that some services do not translate cleanly, that some Azure equivalents are better, that some are worse, and that doing a literal one-to-one mapping is the most expensive way to ship.</description>
    </item>
    
  </channel>
</rss>
