AWS 고객들, IPv4에서 벗어날 수 없다

 (tty.neveragain.de)
1P by GN⁺ | ★ favorite | 댓글 1개
  • AWS는 2024년 2월부터 전용 퍼블릭 IPv4 주소에 시간당 $0.005를 부과하지만, AWS 서비스 제약 때문에 고객이 IPv6로 비용을 피하기 어려움
  • 과금 대상은 Elastic Load Balancer, EC2/Elastic IP, 퍼블릭 IP가 설정된 ECS Fargate 작업, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway 등으로 넓음
  • EC2, VPN, Transit Gateway, Direct Connect, Network Firewall 등은 IPv6 기반에서 동작하지만, API Gateway, Lambda, ECS, App Runner 같은 핵심 서비스는 IPv6-only 서브넷을 거부하거나 제대로 지원하지 않음
  • 내부를 듀얼스택으로 구성해도 서비스 API 엔드포인트의 90% 이상이 IPv6를 지원하지 않아, VPC에서 퍼블릭 IPv4 없이 S3, Systems Manager, SQS 등을 쓰기 어려움
  • 대형 고객에게는 청구서의 1% 미만인 경우가 많아 전환 동기가 약하고, SMB·취미 사용자·스타트업은 10~30% 비용 증가를 겪을 수 있어 부담이 더 큼

2024년 2월부터 전용 퍼블릭 IPv4 과금

  • AWS는 2024년 2월부터 전용 퍼블릭 IPv4 주소마다 시간당 $0.005를 부과함
    • 월 거의 $4, 연간 $40 이상에 해당함
    • AWS 소유 IP에 적용되며, 고객이 라우팅 가능한 퍼블릭 IPv4 블록을 가져오는 BYOIP 주소는 과금되지 않음
  • 과금 대상은 퍼블릭 IPv4를 직접 쓰는 주요 리소스 전반에 걸쳐 있음
    • Elastic Load Balancer
      • 가용 영역당 주소 1개를 사용함
      • 최소 2개가 필요하며 IPv4를 끌 수 없음
    • EC2 인스턴스와 Elastic IP
    • 퍼블릭 IP가 설정된 ECS Fargate 작업
    • Global Accelerator IP
    • Site-to-site VPN IP
    • RDS
    • Managed NAT Gateway
  • 공유 IPv4 주소는 제외됨
    • CloudFront 배포나 API Gateway 엔드포인트에 쓰이는 공유 주소는 과금 대상이 아님
    • VPC 외부 Lambda 함수가 사용하는 퍼블릭 IPv4 주소도 제외됨

비용이 크게 늘어나는 구성

  • 3개 가용 영역에 구성된 퍼블릭 Elastic Load Balancer는 기본 가격이 50% 이상 증가함
  • Managed NAT Gateway는 기본 가격이 약 10% 늘어남
    • NAT Gateway는 가용 영역 단위 중복성을 제공하지 않음
    • 아웃바운드 연결이 중요하면 각 가용 영역마다 NAT Gateway가 필요함
  • 특히 주소를 많이 낭비하는 두 가지 패턴이 영향을 크게 받음
    • VPC마다 여러 Load Balancer를 두는 구성
      • 여러 CloudFormation 템플릿이나 Terraform 모듈을 조합하거나, Kubernetes ingress controller가 서비스마다 Load Balancer를 만들 때 발생함
      • 하나의 Load Balancer가 여러 URL과 서비스를 처리할 수 있음
    • Managed NAT Gateway를 피하려고 EC2 인스턴스와 Fargate 작업에 퍼블릭 IPv4를 의도적으로 붙이는 구성
      • 아이러니하게도 가용 영역당 퍼블릭 IPv4 주소가 약 10개에 도달하기 전까지는 이 방식이 여전히 더 저렴함

현재 사용량 확인 방법

  • 퍼블릭 IPv4 주소 사용량은 이미 계정에 집계되고 있음
    • 현재는 $0로 표시되지만, 2024년 2월부터 시간당 $0.005가 청구됨
  • 확인 경로는 다음과 같음
    • Billing Dashboard > Bills
      • Virtual Private Cloud 섹션에서 PublicIPv4:InUseAddress로 표시됨
    • Cost Explorer
      • PublicIPv4:InUseAddress만 포함하도록 필터링해 일별·시간별 사용량을 볼 수 있음
      • 멤버 계정 단위 그룹화도 가능함
    • VPC > VPC IP Address Manager > Public IP insights
      • 퍼블릭 IPv4 사용량 개요를 볼 수 있음
      • IPAM의 이 부분은 무료임
      • 계정·리전 단위 데이터만 보여주며, 일시적으로 사용된 주소는 잡지 못해 데이터가 불완전함

IPv6 도입의 두 가지 방식

  • IPv4 주소에는 비용이 붙고 IPv6 주소는 무료이므로, 겉으로는 IPv6 전환이 자연스러운 선택처럼 보임
  • IPv6에는 사설 주소 개념이 없어 Managed NAT Gateway와 그 비용을 피할 수 있음
  • IPv6 도입 방식은 크게 두 가지임
    • 듀얼스택
      • 모든 시스템에 IPv4와 IPv6 주소를 함께 설정함
    • 내부 IPv6-only
      • 내부는 IPv6만 사용하고, 일반 사용자와 맞닿는 엣지나 CDN에서만 IPv4 연결성을 제공함
  • 미국 대통령실 메모랜덤은 듀얼스택 운영이 유지하기에 지나치게 복잡하고 불필요해졌으며, 표준화 기구와 주요 기술 기업들이 IPv6-only 배포로 이동하기 시작했다고 명시함
  • AWS의 기본 IPv6 네트워크 지원 자체는 비교적 잘 갖춰져 있음
    • IPv6-only 서브넷에서 IPv6-only EC2 인스턴스를 구성할 수 있음
    • 로컬 DNS, 시간 서비스, 호스트 구성, 보안 등 IPv6 네트워크에서 기대되는 기능이 동작함
    • VPN, Transit Gateway, Direct Connect, Network Firewall도 IPv6를 지원함

AWS 서비스 사용 단계에서 막히는 IPv6

  • 병목은 네트워크 자체보다 다른 AWS 서비스와 연결하는 단계에서 나타남
  • API Gateway, Lambda, ECS, App Runner 같은 핵심 서비스는 IPv6-only 서브넷 구성을 거부하거나 오류를 냄
    • Elastic Load Balancer는 Not enough IP space available 같은 오류를 낼 수 있음
  • 내부를 듀얼스택으로 구성해도 충분하지 않음
    • 많은 서비스가 서브넷에 IPv6가 설정돼 있어도 이를 무시함
    • IPv4 대상에만 연결할 수 있는 경우가 많음
  • VPC에서 퍼블릭 IPv4 주소 없이 서비스 API를 쓰기 어렵거나 불가능한 사례가 많음
    • EC2 인스턴스에서 aws s3 ls 실행이 실패함
    • 인스턴스 접속과 관리를 위한 권장 방식인 Systems Manager가 동작하지 않음
    • ECS Task에서 SQS 접근이 불가능함
  • AWS IPv6 지원 현황에 따르면 서비스 API 엔드포인트의 90% 이상이 IPv6를 지원하지 않음
  • SES SMTP, ECR repository 엔드포인트도 동작하지 않으며, CloudFront는 IPv6 origin에 연결할 수 없음
    • ECR에서 ECS 작업을 시작할 수는 없지만, IPv6를 지원하는 Docker Hub에서는 가능함
    • Docker Hub는 pull에 rate limit을 적용함

PrivateLink는 대체 수단이지만 비용 제약이 큼

  • 많은 서비스는 PrivateLink로 연결할 수 있음
    • 고객 VPC로 직접 연결하므로 퍼블릭 IP 주소가 필요 없음
    • 모든 서비스를 지원하지는 않음
  • PrivateLink는 서비스별·가용 영역별로 과금됨
    • 엔드포인트당 월 약 $9임
    • 예를 들어 Secrets Manager, EC2, SSM, SSM-Messages를 3개 가용 영역에서 연결하면 VPC당 연간 $1,200 이상이 됨
    • 추가 트래픽 요금도 붙음

IPv4 과금이 IPv6 전환으로 이어지기 어려운 이유

  • 규모가 있는 고객에게 IPv4 과금은 대체로 청구서의 1% 미만 수준이라 큰 변화로 느껴지지 않음
    • 이 비용만으로 의미 있는 엔지니어링 투자가 일어나기 어려움
  • SMB, 취미 사용자, 스타트업에게는 요금이 청구서의 10~30% 까지 늘어날 수 있음
    • 이들은 비용을 피하기 위해 IPv6를 도입할 동기가 큼
    • 하지만 AWS 서비스의 IPv6 지원 공백 때문에 IPv4 비용을 피할 방법이 제한됨
  • 최근 IPv4 확보 비용을 고려하면 IPv4 주소 과금 자체는 필요할 수 있음
  • AWS 서비스 전반의 IPv6 지원이 성숙했다면 더 많은 고객이 IPv6-only 환경으로 이전할 수 있음
  • 현재 IPv6는 AWS에서 1급 시민으로 보기 어려우며, 이 상황에서는 IPv4 과금이 개인 계정, 학습, 자격증 준비, 오픈소스 지원 목적의 AWS 사용을 덜 매력적으로 만듦

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 오래전 Amazon에서 주니어 개발자였을 때, 내부 시스템을 모두 리전별 버전으로 쪼개고 리전 간 호출은 제한된 게이트웨이로만 허용하는 대규모 내부 프로젝트가 있었음
    이유는 내부 IPv4 주소가 고갈됐기 때문이었음
    “그냥 IPv6로 바꾸면 안 됐나?”라는 질문에 담당 Principal PM은 “현재 보유한 내부 네트워크 장비 중 IPv6를 지원하지 못하는 장비가 너무 많아서, 교체하려면 전 세계 연간 생산량에 가까운 장비를 사서 전부 설치해야 했을 것”이라는 식으로 답했음
    Amazon이 IPv4 쪽에서 악의적으로 구는 것처럼 보기 쉽지만, AWS 시스템 규모를 생각하면 오래된 네트워크 하드웨어를 전부 교체하는 일이 짧은 기간에는 너무 큰 프로젝트였을 가능성도 충분히 믿을 만함

    • 그게 몇 년도였는지 기억나는지 궁금함
      약간은 헛소리였거나, 적어도 사실을 창의적으로 포장한 것 아닌가 하는 의심이 듦. 예를 들어 실제로는 전부 IPv6 지원이 있었지만, 공포·불확실성·의심에 찬 네트워크 엔지니어들이 켜기 싫어했을 수도 있음
      내가 본 대부분의 네트워크 장비는 주변에서 IPv6를 실제로 쓰기 훨씬 전부터 듀얼 스택이었고, 미국 정부나 군 요구사항 때문에 들어간 것이라고 늘 생각했음
    • 그 regionalisation 기억남. 옆에서 보기에도 “재밌는” 일이었음. 나는 처음부터 리전별로 만들어진 신규 서비스 쪽에 있었음
      그 프로젝트 PM이 누구였는지는 기억나지 않지만, 그때 TPM이 만들어낼 수 있는 가치를 진짜로 존중하게 됐음
      비용과 네트워크 장비 교체 필요성이 IPv6로 가지 않은 강한 이유 중 하나였다는 말은 맞음. Amazon은 여러 이유로 자체 설계·제작한 네트워크 장비를 썼고, 아마 지금도 그럴 것임
      그 장비들은 전부 고정 메모리 용량이라 IPv6 라우팅 테이블 등을 감당할 만큼 메모리를 늘리려면 교체해야 했음. IPv6 전용을 택했더라도 기존 장비로는 부족했을 것이고, 어차피 IPv4/IPv6 듀얼 스택 없이는 통과하기도 어려웠음
    • 그 PM은 아마 Laura Grit이었을 것 같고, 실제로는 TPM이었을 거라고 봄. Laura는 지금 Distinguished Engineer임
      항상 엄청난 규모의 프로젝트를 하는 듯하고, IPv4는 이제 그중 작은 축에 속함. 지금 하는 큰 프로젝트 몇 가지는 아쉽게도 공유할 수 없음
      몇 번 시간을 내줘서 현명한 조언을 받은 적이 있고 고맙게 생각함
    • 오래된 네트워크 하드웨어를 모두 교체하는 일이 짧은 기간에는 너무 큰 프로젝트라면, Amazon은 내부 어디서나 IPv6를 지원할 수 있도록 교체를 마칠 때까지 IPv4 과금을 짧은 일정으로 밀어붙이면 안 됨
    • 그렇다고 IPv6 단계적 도입을 안 해도 되는 건 아님. 이 문제를 영원히 미룰 수는 없음
      분명히 이미 절차를 시작했겠지
      그렇겠지? AWS가 머리를 모래에 박고 이걸 무시하고 있다고는 상상하기 어려움

  • AWS가 제대로 동작하는 IPv6를 제공하는 건 인센티브에 명백히 어긋나 보임. AWS의 영향력 도구들, 예컨대 Well-Architected 기준이나 인증은 엔드투엔드 주소 지정이 있는 인터넷식 아키텍처가 아니라, 애매하게 주소가 붙은 10.x RFC1918 네트워크 미로를 만들도록 강하게 몰아감
    AWS 권장사항의 세계에서는 “공인 IP 주소”라는 개념 자체가 위험 신호이고, AWS는 추가 비용을 받고 그런 주소를 표시하고 “완화”하는 도구까지 권장함
    고객이 보안이라는 명목으로 복잡한 인프라를 구축하는 데 노력을 쓰게 만들면 강한 락인 효과가 생김. 실제로는 불필요한 복잡성, 주소 모호성 등으로 보안을 해치는데도 그럼

    • Azure도 이걸 통째로 따라 하고 있음
      “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN” 같은 제품이 얼마나 나왔는지 셀 수도 없게 됐고, 전부 IPv4를 대규모로 굴리기 위한 것임
      IPv6를 제대로 동작하게 만들었다면 이런 제품은 문자 그대로 하나도 필요 없었음
      대신 Azure는 IPv6도 NAT 처리하므로, IPv4 때문에 강제되는 NAT를 피하려고 IPv6를 쓸 수도 없음. 2023년에도 IPv6를 지원하지 않고 앞으로도 그럴 가능성이 큰 새 제품을 내놓고 있음
      문서에는 아직도 제한사항이 한 페이지 전체로 남아 있음: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      이게 IPX에서 IPv4로 넘어가는 전환이었다고 생각해보면 얼마나 말이 안 되는지 보임. 이 페이지에 “IPv4 제한사항: 모든 VM은 최소 하나의 IPX 주소를 포함해야 함” 같은 식으로 적혀 있는 셈임
      이상하게 들리지 않나? 1999년에 고객을 IPX에서 IPv4로 이전시키고 있었고, IPv6 지원은 대략 2001~2003년에 나타났음. 수십 년이 지났는데도 “아직 모든 게 IPv4를 지원하지 않으니 IPX+IPv4가 필요하다”던 Novell NetWare 이전 시절 같은 느낌임
      이 목록은 절대 전체 제한사항이 아님. 대부분의 PaaS 제품이 IPv6를 지원하지 않으므로, IaaS+PaaS 해법은 결국 대부분 IPv4를 써야 함
    • AWS만의 문제가 아님. Microsoft, 보안 감사자, 침투 테스터, 사이버 보험사 등도 대체로 공개 주소 지정 가능한 엔드포인트를 두지 말라고 요구함
      왜 그런지는 이해하지 못하겠지만, 어떤 대형 기술 회사가 엔드투엔드 주소 지정을 모범 사례로 밀기 전까지는 위험 신호를 만들지 않기 위해 기존 통념을 따를 수밖에 없음
    • Azure에서 일하고 있는데, 내 경험상 고객들이 이걸 원하고 그럴 만한 이유도 있음
      고객은 자신이 소유하지 않은 머신 위에서도 침입과 데이터 유출을 막기 위해 자기만의 사설 네트워크를 원함. 더 나아가 배터리 포함식으로 잘 갖춰진 PaaS 서비스도 그 네트워크 안에 넣고 싶어함
    • 이 둘이 관련 있다고 확신하진 않음. AWS가 원했다면 IPv6가 내부 네트워크 문제를 모두 해결하는 만병통치약이라고 홍보할 수 있었고, 실제로 동작한다면 경쟁사들이 따라잡기 어려웠을 것임
      내 추측으로는 이유가 더 평범함. AWS의 서비스 수까지 고려하면 IPv4 지원이 그냥 더 쉬움
    • 내부 서비스에 대한 외부 접근을 막는 것이 어떻게 보안을 해치는지 모르겠음

  • AWS 고객으로서 나는 IP 자체에서 벗어나고 싶음. IP, BGP, DNS 같은 낡은 프로토콜로 구성된 복잡한 네트워킹 시스템을 관리하는 건 시간 낭비임
    워크로드에 강한 신원을 연결하고, 어떤 워크로드가 어떤 워크로드와 데이터를 주고받을 수 있는지만 정책으로 적용하게 해주면 됨
    데이터가 한 워크로드에서 다른 워크로드로 어떻게 가는지는 내 관심사가 아니어야 하고, 그냥 되게 해주면 됨

    • 완전히 동의함. 참고로 이런 감각 때문에 요즘 그런 일을 해주는 클라우드 “플랫폼”이 많이 생겨나고 있음
      가상화된 데이터센터, 즉 흉내 낸 네트워킹의 구성요소 동물원에 빠지는 대신 전부 추상화해버리는 것임
    • 그 감정은 타당하지만, 이런 주장은 사람들이 로우코드 해법을 말할 때 하는 논리와 비슷함
      현실에서는 한 번도 제대로 동작한 적이 없고 앞으로도 그럴 수 없음. 실제 워크로드를 수행하고 최적화하려면 고려해야 할 뉘앙스와 세부사항이 너무 많음
    • “큰 그림을 보는 사람들”도 그 큰 그림이 세부사항을 해결하지 못하면 갑자기 세부사항을 신경 쓰게 됨
    • Heroku 같은 건가? 몇 년 동안 Heroku를 안 써봐서 지금 상태는 모름
    • 인터넷 프로토콜 없이 인터넷을 원한다는 건가?

  • AWS에서 IPv6 전용으로 갈 때 내 경험상 가장 큰 문제는 GitHub가 아직 IPv6를 못 한다는 점임. 수많은 소프트웨어가 뭔가를 받으려고 GitHub에 접속할 수 있다고 가정함
    공개 NAT64 서비스를 쓸 수는 있지만, 진지한 용도에는 그리 믿을 만하지 않음: https://nat64.xyz/
    AWS는 NAT 게이트웨이 트래픽에 엄청난 비용을 청구하고, IPv4 전용 호스트로 가는 트래픽만 가로채도록 설정할 수 있는지도 모르겠음. 틀렸다면 알려주면 좋겠음
    이 외에는 AWS에서 IPv6 전용으로 쓰는 것이 흠잡을 데 없이 동작하고 더 저렴함. 사설 네트워크용 이그레스 게이트웨이가 무료임. 물론 IPv4를 신경 쓰지 않는다는 전제가 필요함

    • GitHub가 모회사인 Microsoft의 IPv6 배포 흐름을 따라가지 못한 건 아쉬움
    • AWS에서 듀얼 스택 네트워크를 쓰면 DNS에서는 IPv6를 선호하되 IPv4도 여전히 동작하지 않나? 일반 인터넷 이그레스가 필요한 대부분의 것들을 그렇게 설정해두고 있음

  • 내 생각에는 Lambda와 S3가 IPv6를 지원하지 않는 것이 진짜 문제이고, AWS는 먼저 이들을 듀얼 스택으로 만들어 IPv6로 접근 가능하게 한 뒤 가격 변경을 했어야 함
    기술적으로 S3에는 별도의 듀얼 스택 엔드포인트가 있긴 하지만, 어차피 이 변경에 대응하려면 애플리케이션 설정을 바꿔야 해서 별 도움이 안 됨

  • 애초에 AWS가 IPv6 지원에서 앞서 있는 이유의 절반은 미국 정부가 이전을 시작하라고 내린 정책 의무화 때문임
    비용 관점에서 새 비용이 대형 고객에게는 사소하다는 점은 맞지만, 가장 큰 고객들의 정책 의무화가 갖는 힘을 과소평가하면 안 됨. 정책 준수를 위해 자체 대안을 만들겠다는 위협만으로도 AWS가 결국 지원 우선순위를 높이게 만들 수 있음

    • 맞음. 별로 좋아하지 않는 생각이지만, “서버 쪽”에서 IPv6를 장려할 다른 방법이 점점 없어 보임
      클라이언트, 즉 최종 사용자 쪽은 잘 가고 있는 듯함. Google이 요즘 최종 사용자 IPv6 트래픽을 거의 50%로 보고하는 걸 보면 그렇음

  • 개인적으로 가장 나쁜 건 CloudFront가 사용자 지정 오리진의 IPv6를 지원하지 않는 점임
    별도 Fargate 컨테이너를 오리진으로 많이 돌린다면 공인 IPv4 주소를 켜야 하고, 곧 작은 컨테이너 비용이 두 배가 됨
    Amazon은 레거시 IPv4 사용에 추가 요금을 부과하기 전에 자기 인프라가 실제로 IPv6를 지원하게 만들어야 함

    • 맞음. 이상하게도 이게 제일 아픔
      Amazon이 거대한 괴물을 만들었고 수많은 서비스 전체에 IPv6를 배포하는 일이 엄청난 작업이라는 건 알지만, CloudFront가 지금 당장도 아니고 어제부터 IPv6 오리진을 지원하지 못할 이유는 보이지 않음
      상대적으로 그렇게 어려워 보이지도 않고, 다른 제한사항을 우회할 좋은 도구가 될 수도 있음
      솔직히 지금까지는 Amazon의 의사결정이 결국 고객의 최선의 이익을 염두에 둔다고 느꼈는데, 이제는 그렇지 않음. 앞으로 좋지 않은 신호라고 봄

  • 미국에 진짜 ISP 경쟁이 있었다면 큰 도움이 됐을 것임
    내가 세 들어 사는 곳은 Seattle 근교 교외인데도 실제 광대역 ISP는 하나뿐임. 어떤 정의로도 시골이 아닌데 Comcast가 유일한 선택지임. 가격과 서비스는 그 현실을 그대로 반영함

    • 이 분야에서 법적으로 강제된 독점이 가능하게 만든 끝없는 로비에 감사해야 함. 전화회사에도 똑같이 했음
      우연히 “Comcast뿐”인 게 아니라, 법적 규제로 “Comcast뿐”이 된 것임
    • Comcast는 IPv6를 지원함. 2016년에 IPv6 지원률 98% 에 도달했음
    • 소비자는 IPv6를 알지도, 신경 쓰지도 않으므로 경쟁이 ISP의 구현을 유도하지는 못함
      Comcast를 불평하는 게 재밌는 점은, 내가 Comcast를 쓸 때는 네이티브 IPv6가 있었음. 지금 쓰는 제공자는 NAT46을 통한 IPv6만 있음
    • Starlink가 다른 선택지가 될 수도 있음
      폭우 때 성능 저하 같은 단점은 있지만, 긍정적인 후기도 몇 개 봤음
    • IPv6 도입은 고객을 큰 독점 사업자로 더 몰아넣을 것임. 안정적으로 동작하게 만들 전담 네트워크 엔지니어링 인력을 감당할 수 있는 곳이 그들뿐이기 때문임
      대부분은 지금 IPv6 인터넷이 두 개 있다는 사실을 모름. Cogent 쪽과 Hurricane Electric 쪽이 있고, 둘은 규모가 비슷하며 서로 연결을 거부함. 그래서 이걸 알고 양쪽에서 전송망을 사거나, 양쪽에서 전송망을 사는 네트워크에서 사야 함
      내가 아는 최소 한 대형 사업자는 아직도 터널 위에서 v6를 돌리고 있음. 많은 곳에서 v6 트래픽은 최적이 아닌 경로를 타고, 기업 네트워크는 각 데이터센터마다 v4 연결이 있을 수 있지만 v6는 “Dave 책상 밑의 그 박스” 하나로 전부 보내지는 식임
      그런데도 Google이나 Cloudflare처럼 전담 팀이 패킷 도착을 보장하는 곳에서 v6 도입률을 재고는 스스로 등을 두드리고 있음

  • “IPv4에서 벗어날 수 없다”는 표현은 적절함. IPv6 전용 VPC를 만들 수는 있지만, 여러 AWS 서비스부터 패키지 저장소까지 너무 많은 것이 깨짐: https://blog.devopstom.com/ipv6-only-ec2/
    결국 IPv4를 켜거나, NAT64 게이트웨이를 직접 돌리거나, 누군가 운영하는 NAT64를 신뢰해야 함: https://nat64.net 및 http://v4-frontend.netiter.com

  • “IPv6에는 사설 주소 개념이 없으니 Managed NAT Gateway와 그 장엄한 가격에 작별”이라는 말은 AWS 안에서는 그럴지 몰라도, IPv6에는 fc00::/7의 Unique Local IPv6 주소가 있고 NAT를 정말 사랑한다면 NAT66도 있음

    • 맞음, AWS를 가리킨 말이었고 그걸 분명히 했어야 했음
      다만 ULA는 자주 권장되지 않고, NAT66은… 그냥 안 됨
      최근에 들은 바로는 Microsoft가 Azure의 IPv6를 전부 NAT 중심으로 만들었다고 함. 정말 이상함
답변달기