<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>QnA on blog.212clab</title><link>https://212clab.pages.dev/en/qna/</link><description>Recent content in QnA on blog.212clab</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 02 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://212clab.pages.dev/en/qna/index.xml" rel="self" type="application/rss+xml"/><item><title>How a Stateless Service (ECS) Accesses a Private DB</title><link>https://212clab.pages.dev/en/qna/2026-05-02-ecs-private-db-sg/</link><pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate><guid>https://212clab.pages.dev/en/qna/2026-05-02-ecs-private-db-sg/</guid><description>&lt;h2 id="one-liner"&gt;One-liner&lt;/h2&gt;
&lt;p&gt;Add the ECS task&amp;rsquo;s Security Group as an &lt;strong&gt;inbound source&lt;/strong&gt; in the RDS Security Group. Reference the SG itself — not an IP address.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="why-you-cant-use-ips"&gt;Why You Can&amp;rsquo;t Use IPs&lt;/h2&gt;
&lt;p&gt;ECS Fargate assigns a &lt;strong&gt;new IP every time a task starts&lt;/strong&gt;:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;Task A: 10.0.1.23 → terminates
Task B: 10.0.2.87 → new task (different IP)
Task C: 10.0.1.45 → scale-out (yet another IP)
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Because tasks scale in and out with auto-scaling, registering IPs in a Security Group is impractical.&lt;/p&gt;</description></item><item><title>iptables vs Security Group</title><link>https://212clab.pages.dev/en/qna/2026-05-02-iptables-vs-sg/</link><pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate><guid>https://212clab.pages.dev/en/qna/2026-05-02-iptables-vs-sg/</guid><description>&lt;h2 id="one-liner"&gt;One-liner&lt;/h2&gt;
&lt;p&gt;iptables is an &lt;strong&gt;OS kernel-level&lt;/strong&gt; firewall; Security Group is an &lt;strong&gt;AWS VPC-level&lt;/strong&gt; virtual firewall. iptables runs inside the host; SG runs outside the host (at the hypervisor).&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="where-each-operates"&gt;Where Each Operates&lt;/h2&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;[Internet]
 ↓
[AWS VPC]
 ↓
[Security Group] ← Hypervisor (ENI) level — filters traffic before it reaches EC2
 ↓
[EC2 instance]
 ↓
[iptables] ← OS kernel (netfilter) level — filters traffic inside EC2
 ↓
[Application]
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;SG filters traffic &lt;strong&gt;before&lt;/strong&gt; it ever reaches the EC2 instance. iptables filters inside EC2 at the kernel level.&lt;/p&gt;</description></item><item><title>NLB vs ALB</title><link>https://212clab.pages.dev/en/qna/2026-03-22-nlb-vs-alb/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://212clab.pages.dev/en/qna/2026-03-22-nlb-vs-alb/</guid><description>&lt;h2 id="one-liner"&gt;One-liner&lt;/h2&gt;
&lt;p&gt;NLB is an &lt;strong&gt;L4 (TCP/UDP)&lt;/strong&gt; load balancer; ALB is an &lt;strong&gt;L7 (HTTP/HTTPS)&lt;/strong&gt; load balancer. NLB forwards packets as-is, while ALB parses HTTP requests before routing them.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="how-each-layer-works"&gt;How Each Layer Works&lt;/h2&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;NLB (L4):
 Client → [NLB: forward TCP packet] → Server
 - Does not inspect packet contents
 - Routes by IP + Port only

ALB (L7):
 Client → [ALB: parse HTTP request] → Server
 - Inspects Host header, URL path, HTTP method
 - Makes routing decisions based on request content
&lt;/code&gt;&lt;/pre&gt;&lt;hr&gt;
&lt;h2 id="key-differences"&gt;Key Differences&lt;/h2&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;&lt;/th&gt;
 &lt;th&gt;NLB&lt;/th&gt;
 &lt;th&gt;ALB&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;OSI layer&lt;/td&gt;
 &lt;td&gt;L4 (TCP/UDP)&lt;/td&gt;
 &lt;td&gt;L7 (HTTP/HTTPS)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Routing basis&lt;/td&gt;
 &lt;td&gt;IP + Port&lt;/td&gt;
 &lt;td&gt;Host, Path, Header, Method&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Latency&lt;/td&gt;
 &lt;td&gt;~100µs (ultra-low)&lt;/td&gt;
 &lt;td&gt;~1ms&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Static IP&lt;/td&gt;
 &lt;td&gt;Yes (1 per AZ)&lt;/td&gt;
 &lt;td&gt;No (DNS-based)&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Throughput&lt;/td&gt;
 &lt;td&gt;Millions of requests/sec&lt;/td&gt;
 &lt;td&gt;Tens of thousands of requests/sec&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Protocols&lt;/td&gt;
 &lt;td&gt;TCP, UDP, TLS&lt;/td&gt;
 &lt;td&gt;HTTP, HTTPS, gRPC, WebSocket&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;hr&gt;
&lt;h2 id="routing-capabilities"&gt;Routing Capabilities&lt;/h2&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;NLB:
 - Port-based routing only
 - :443 → Target Group A
 - :8080 → Target Group B

ALB:
 - api.example.com/users → User service
 - api.example.com/orders → Order service
 - admin.example.com/* → Admin service
 - Header X-Version: v2 → V2 service
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;With ALB, a single load balancer can route to multiple services by Host or Path. With NLB, you&amp;rsquo;d have to split by port or deploy separate NLBs.&lt;/p&gt;</description></item></channel></rss>