왜 지금 Claude Platform on AWS 에서 분할 이야기가 나오나

2026년 들어 공식 채널에서 Claude Platform on AWS가 반복해서 언급되며, 많은 조직이 Bedrock 관리형 엔드포인트를 통해 Anthropic 계열 추론 API를 받아들입니다. 과거에는 브라우저에서 Anthropic 콘솔이나 타사 래핑 페이지만 여는 정도였다면 이제는 AWS Console 안의 카탈로그 페이지, 조직 차원의 IAM·KMS 연동 확인, 특정 VPC 엔드포인트 허용 여부처럼 콘솔 HTML과 TLS API가 한 번에 겹치는 패턴으로 바뀌었습니다.

이때 회사 노트북에는 이미 와이드한 GEOIP 기반 분할 규칙과 Clash Verge Rev 같은 데스크톱 UI가 깔린 경우가 많습니다. 문제는 “AWS는 지나가는데 Anthropic API만 가끔 멈춘다” 혹은 “콘솔만 영원히 스피너 도는데 Postman 테스트는 간헐 성공한다”처럼 한 덩어리로 보고 있던 트래픽이 실제로는 여러 접미 호스트 줄로 갈린다는 점입니다. 본 글에서는 그 줄을 사용자가 직접 클립보드 로그 레벨에서 나누는 방법만 다룹니다. 계정 규약·네트워크 정책을 어기는 우회 방법은 포함하지 않습니다.

AWS Console 과 Anthropic 호출이 겹치는 지점 정리

실무에서는 최소 다음 세 줄을 떼어 놓고 생각하는 편이 낫습니다.

  • 콘솔·브라우저 출입: console.aws.amazon.com, signin.aws.amazon.com, 종종 붙는 *.awsapps.com(조직별 SSO)·리다이렉트용 하위 호스트.
  • AWS API 패밀리(Bedrock 등): 사용 리전별 bedrock-runtime.<region>.amazonaws.com·bedrock.<region>.amazonaws.com 패턴 및 공통 제어 플레인인 sts.amazonaws.com처럼 서비스마다 접두가 다른 amazonaws 계열 호스트들.
  • 직접 Anthropic API 라인: SDK나 테스트 스크립트가 직접 api.anthropic.com 같은 퍼블릭 이름을 타는 분기. Bedrock 과 병행 테스트할 때 이 줄이 놓치기 쉽습니다.

한 줄이라도 회사 허용망에서는 DIRECT로 두지만 개발자 가정에서는 해외 우회 노드로만 보내야 하는 같은 정책이 존재할 수 있습니다. 이때 줄마다 속도·지연·패킷 드랍 특성이 달라 MATCH 한 방에 모든 것을 처리하려 들면 한쪽 줄만 깨져도 증상이 전체처럼 느껴집니다. 이전에 올린 AWS MCP 와 IDE 가 만나는 AWS API 분할 가이드 의 전제인 “STS·리전·로그인 호스트 분리” 와 같은 맥락입니다만, 이번 주제에서는 Claude 이름이 붙은 양쪽 API 경로와 콘솔 페이지를 동시에 봐야 합니다.

참고: 각 리전의 정확한 FQDN 은 시간이 지나면 달라질 수 있습니다. 따라서 규칙은 항상 직접 턴에서 찍힌 실패 문자열을 기준으로 보강하세요.

범용 ChatGPT·Claude 분할 글과의 관계

히스토리가 비슷한 ChatGPT 와 Claude 를 같이 두는 규칙 예시 글 을 그대로 AWS 시나리오에 붙여 쓸 수는 없습니다. 이유는 OpenAI 또는 Anthropic 순수 호스트와 AWS 전용 서브 도메인 의 조합 순서와 WSS 또는 긴 업로드 채널(Bedrock 블록 전송 포함) 때문에 TLS 세션 시간이 크게 나뉘기 때문입니다. 그 글에서 제안했던 패턴 일부(DOMAIN-SUFFIX 축 선택)만 가져오고, 본 글에서는 amazonaws.com 전체를 한 줄에 몰 때 생기는 위험과 그 변형을 추가로 적습니다.

증상을 세 버킷으로 나누기

첫째, AWS Console 카드 UI만 회전하고 네트워크 탭에 JS 번들 불러오기 타임아웃이 찍히면 브라우저 프로필이 붙어 있는 콘솔 전용 줄을 보세요.

둘째, 언어 SDK나 CLI에서만 Bedrock 또는 InvokeModel 종류 호출에서 HTTP 599·TLS handshake hang처럼 보이면 STS 가정부터 맞았는지, 그리고 실제 접속한 호스트 문자열 전체가 어떤 RULE 에 걸렸는지 순서부터 의심합니다.

셋째, Anthropic API 키로 직접 붙인 스크립트에서만 간헐 403·503이면 AWS 조직 규약과 무관하게 상대 이름이 다른 퍼블릭 도메인이라 전혀 다른 proxy-group 이 이미 선택되었을 수 있습니다. 증상 문장을 줄마다 붙여 두면 디버깅 속도가 비약적으로 빨라집니다.

도메인 묶음을 설계할 때의 실무 패턴

아래 패턴 이름은 사용자 정의 레이블이며 Mihomo 또는 Clash Meta 프로필에 그대로 옮길 때 팀 컨벤션에 맞춰 줄이면 됩니다. 핵심은 넓게 잡히는 줄을 아래에 두지 말 것입니다.

  • GROUP-A-login: 콘솔 초기 페이지·중앙 SSO·리디렉션 루프를 다룹니다.
  • GROUP-B-sts-global: AssumeRole 과 관련되는 글로벌 STS 호스트 줄에만 높은 가용 우선 순위를 줄 수 있습니다.
  • GROUP-C-bedrock-per-region: 실제 테스트 중인 각 리전에 대해 DOMAIN-SUFFIX, 를 복사해 넣거나 rule-provider 에서 패턴 업데이트를 받도록 합니다.
  • GROUP-D-anthropic-direct: anthropic.com 과 하위 문자열 줄을 다른 노드 라인업과 연결합니다.

회사 허브에서 내부 DNS 가 amazonaws 결과를 다른 곳으로 보냄(split-horizon) 과 같은 레이어도 겹칠 때가 있습니다. 그 경우에는 Clash 레벨뿐 아니라 어떤 DNS 서버 이름이 실제로 응답했는지 까지 대조해야 합니다. 같은 질문을 브라우저 DNS over HTTPS 결과와 비교해 보면 금방 갈립니다.

proxy-groups 와 rules 축약 YAML 예시

예시에서는 이름과 노드 줄을 플레이스홀더로 두었습니다. 구독에 있는 진짜 proxies 명칭과 맞바꿔 넣어야 실행됩니다.

YAMLproxy-groups:
  - name: "AWS-Claude-Console"
    type: select
    proxies:
      - DIRECT
      # stable proxies for SSO redirect + cookies ...

  - name: "AWS-Bedrock-Runtime"
    type: url-test
    url: "https://bedrock-runtime.us-east-1.amazonaws.com"
    interval: 120
    tolerance: 50
    proxies:
      - DIRECT
      # low jitter pool for inference ...

  - name: "Anthropic-PublicAPI"
    type: select
    proxies:
      - DIRECT
      # outbound pool allowed by policy ...

rules:
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS-Claude-Console
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS-Claude-Console
  # paste every tested region hostname explicitly
  - DOMAIN-SUFFIX,bedrock-runtime.us-east-1.amazonaws.com,AWS-Bedrock-Runtime
  - DOMAIN-SUFFIX,bedrock.us-east-1.amazonaws.com,AWS-Bedrock-Runtime
  # hoist STS ahead of broad GEOIP matches if needed
  - DOMAIN-SUFFIX,sts.amazonaws.com,AWS-Bedrock-Runtime
  - DOMAIN-SUFFIX,api.anthropic.com,Anthropic-PublicAPI
  - DOMAIN-SUFFIX,anthropic.com,Anthropic-PublicAPI
  # verify nothing above GEOIP/MATCH steals these lines

tolerance 값을 넉넉히 줄수록 패킷 레이턴시가 들쭉날쭉한 노드 풀에서도 그룹이 덜 깜빡입니다. 너무 작으면 건강한 노드 교체 루프로 보이던 연결이 끊긴 것처럼 재현되어 실제 문제와 섞입니다. 이 부분과의 트레이드오프는 이미 작성해 둔 health-check 허용오차 가이드 Windows 편 에서 같은 논리로 설명되어 있습니다.

실측 순서 로그부터 TUN 까지

다음 순서대로 따라가면 새 직무 온보딩 PC 한 대에서 문제를 빠르게 고정 포인트로 줄일 수 있습니다. 각 줄마다 새로 적힌 FQDN 을 즉석에서 프로필에 반영하면 반복 테스트가 줄어듭니다.

  1. 증상 버킷(콘솔/SDK/직통 API 중 어디에서만인지)을 정리한 뒤 TUN 과 시스템 프록시 토글이 서로 간섭하지 않았는지 Clash Verge 상태 표시줄부터 확인합니다. 동시에 켠 경우 운영체제마다 루프백 순서가 꼬이기도 합니다.
  2. 브라우저 네트워크 탭에 찍힌 호스트 문자열과 패킷 캡처에 보인 목적 주소를 대조해 동일 라우팅인지 확인합니다.
  3. Mihomo 추출 로그 레벨 또는 대시보드 상의 정책 매칭 열에서 “첫 줄에서 멈춘 이름”을 확인합니다.
  4. enhanced-mode: fake-ip 를 쓰면 예외 목록(fake-ip-filter) 에 콘솔 이름을 넣을지 테스트합니다.
  5. curl -v https://sts.amazonaws.com 과 실제 테스트 중인 리전 Bedrock 문자열 두 개를 순서 바꿔 찍으며 TLS 인증서 체인이 동일 라인 노드 아래에서 끝까지 오는지 봅니다.
  6. 마지막으로 IPv6 활성 상태 가 OS 전역에서 다른 경로를 타며 IPv4 분할 줄을 피했는지 점검합니다. 허브가 IPv6 까지 허용하는데 클라이언트 라우팅표만 다른 경우 간헐성이 크게 줄어들기도 합니다.

주의: 외부에서 가져오는 규칙 세트 하나에 과도하게 의존하면 AWS 전체 줄이 예기치 않은 노드 풀로 흘러갈 수 있습니다. 프로덕션 계정 접속이 있는 장비라면 허브에서 검증한 로컬 스니펫 우선 적용 후에만 규칙 프로바이더 를 켜두는 패턴을 권장합니다.

자주 묻는 질문

Q. 브라우저 AWS Console 만 되면 애플리케이션 Anthropic 호출에서만 멈춥니다. A. 앞 장에서 나눈 세 줄처럼 경로 레이블이 다른지 먼저 적어 보세요.

Q. Clash Verge Rev 에서 같은 프로필이면 충분한가요? A. UI 만 다르고 코어 규격이 Mihomo 패밀리면 YAML 본체는 같은 논리로 작동합니다. 다만 업데이터가 백업 프로필을 덮어쓰므로 사람이 수정한 순서 줄을 버전 관리해야 합니다.

마무리

Claude Platform on AWS 라는 이름은 한 줄로 들리지만 현장 패킷은 콘솔 JS 번들 줄, STS·IAM 인증 줄, 리전별 Bedrock 런타임 줄, 그리고 때로 등장하는 별도 Anthropic API 줄로 갈립니다. 이 줄들을 사용자가 규칙 파일에서 무의식적으로 한 덩어리로 묶으면 “AWS Console 과 API 가 모두 간헐 실패처럼” 보이지만 실제 매칭은 서로 다른 RULE 에 있을 수 있습니다. 운영을 단순화하려 들수록 디버깅은 오히려 느려집니다.

상용 브라우저 전용 VPN 과 패널형 일체 툴은 Mihomo 수준까지 DOMAIN-SUFFIX 순서와 규칙 프로바이더 단위로 패킷 줄을 접기 어렵고, 콘솔 무한 로딩과 장시간 Anthropic API 호출이 같은 세션에 겹치는 환경에서 반복 테스트에 드는 시간이 길어집니다.

반면 같은 YAML 규격을 따르는 Clash 공식 사이트 계열 패키지는 노드 테스트·건강검사 같은 운영 파라미터를 한 프로필에 묶어두고 스크린샷과 문단으로 설명이 이어져 온보딩 비용까지 줄입니다. 필요한 리전 줄만 채운 뒤 첫 요청부터 끝 응답까지 한 줄 로그를 버전 관리에 넣어도 교육 비용은 크게 내려갑니다. 설치 흐름은 문서 허브에 정리돼 있고, 패턴을 바로 적용하고 싶다면 무료로 Clash 공식 사이트 를 다운로드해서 동일 분할 줄을 통째로 옮겨 테스트해 보시길 권합니다.