<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Peering on Kiglo</title>
    <link>https://page.kiglo.org/tags/peering/</link>
    <description>Recent content in Peering on Kiglo</description>
    <generator>Hugo</generator>
    <language>ko-kr</language>
    <lastBuildDate>Sun, 21 Dec 2025 10:00:00 +0900</lastBuildDate>
    <atom:link href="https://page.kiglo.org/tags/peering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>VPC 세팅과 Peering vs TGW</title>
      <link>https://page.kiglo.org/posts/iac-terraform-networking/</link>
      <pubDate>Sun, 21 Dec 2025 10:00:00 +0900</pubDate>
      <guid>https://page.kiglo.org/posts/iac-terraform-networking/</guid>
      <description>&lt;h2 id=&#34;네트워크-레이어-설계의-핵심&#34;&gt;네트워크 레이어 설계의 핵심&lt;/h2&gt;
&lt;p&gt;클라우드 인프라의 뼈대인 VPC를 설계할 때, &amp;ldquo;가용영역(AZ)은 무조건 최대로 쓸수록 좋다&amp;quot;는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 &lt;strong&gt;비용, 성능, 관리 복잡성&lt;/strong&gt; 사이의 균형점이 필요하다고 생각합니다.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;azavailability-zone-전략-3az-2az&#34;&gt;AZ(Availability Zone) 전략: 3AZ? 2AZ?&lt;/h2&gt;
&lt;p&gt;대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 &lt;strong&gt;2개의 AZ&lt;/strong&gt;가 더 효율적인 경우도 얼마든지 있습니다.&lt;/p&gt;
&lt;h3 id=&#34;1-topology-aware-routingtar의-수학적-한계와-fallback&#34;&gt;1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback&lt;/h3&gt;
&lt;p&gt;Kubernetes의 &lt;strong&gt;Topology Aware Routing&lt;/strong&gt;은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 &amp;lsquo;버그&amp;rsquo;처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
