amazonaws 접미 규칙을 한 줄에 두면 빠르게 안정화되나요?

범위가 매우 넓어 S3·기타 업무 API까지 같은 출구를 타 다른 지연을 만들 수 있습니다. 처음에는 bedrock 접두 패턴과 실제 확인된 STS·SSO 라인부터 좁히는 편이 안전합니다.

OpenAI 같은 외부 LLM 호출도 같은 그룹에 넣어도 되나요?

같은 머신에서 Chat Completions 같은 공개 호스트를 쓰면 api.openai.com 등을 동일 또는 인접 전략 그룹에 두어도 됩니다. 회사별 프록시·로그 규칙만 따로 검토하면 됩니다.

Bedrock 타임아웃? Agent Toolkit 분기·Clash (2026)

AWS 에이전트 툴링이랑 분기 규칙이 왜 엮여 있나요

AWS Agent Toolkit이라는 이름은 시간이 지나면서 IDE 확장, 샘플, 모델 런타임 가이드를 아우르는 넓은 말입니다. 실제 트래픽에서는 Amazon Bedrock 에이전트·런타임 호출 전에 STS에서 자격 증명을 받거나, 같은 머신에서 OpenAI 호환·타 벤더 API까지 동시에 쓰는 경우가 많아집니다. 이때 속도 테스트에서 빠르다고만 보는 노드를 바꾸는 문제가 아니라 특정 호스트만 규칙 테이블 밖으로 빠져 DIRECT나 엉뚱한 노드에서 나가 버리면 전체 시간 초과로 보입니다.

2026년 5월 즈음 커뮤니티에서 자주 재현되는 말입니다. 브라우저의 AWS 로그인 흐름은 괜찮은데 같은 VS Code 세션에서 에이전트가 Bedrock 호출까지 가면 시간 초과가 난다는 이야기입니다. 여기에는 대략 두 가지가 겹칩니다. 브라우저가 쓰는 SSO 페이지와 boto 계열 SDK가 붙는 STS 호스트 이름이 한 규칙 묶음에서 다르게 처리되거나, AI SaaS용 규칙이 amazonaws.com 줄과 순서 없이 함께 있으면 한쪽 라인만 잘못된 출구로 빠져 전체 플로가 멈춥니다.

이 페이지는 속도 테스트가 아니라 로그에 나타난 호스트를 모으고, 같은 전략 그룹에 묶으며, GEOIP나 MATCH 같은 넓은 규칙보다 더 위쪽에 새 규칙을 놓아야 하는지를 정합니다. 단일 제공자 전용 패턴은 Anthropic 분기 안내에 두고, 여기서는 STS와 Bedrock·에이전트 관련 문자열만 다룹니다. 같은 IDE를 쓰는 경우에는 Cursor 글과 같이 참고하면 좋습니다.

흔하게 보이는 끊김 패턴

아래 패턴 하나만 맞더라도 Clash 규칙 순서나 시스템 레벨 터널 포함 여부부터 보는 게 이득입니다.

콘솔에서 시작한 테스트 호출마다 “성공했다” 했더니 같은 자격증명으로 IDE 속 Toolkit만 멈춥니다.
knowledge 검색 결과를 돌려보는 순간 장시간 회선이 타임아웃되거나 HTTP 504와 비슷한 메시지만 남습니다.
여러 리전·모델을 바꿀 때 STS 토큰은 살아 있는데 새 리전의 Bedrock 런타임 엔드포인트만 직통으로 깨져 보입니다.
OpenAI처럼 API 키가 직접 있는 호출만 되고, Toolkit이 따라가야 하는 SSO·OIDC 리디렉션이 순환 상태에 걸린다면 트래픽 문자열까지 같이 검토해야 합니다.
EKS나 Lambda 대신 순수 노트북으로만 실험하는데 브라우저 VPN 탭에서는 정상이라고 놓치고 노드만 교체했습니다.

증상만 보고 즉시 답이라고 규정하기 어렵기 때문에 먼저 mihomo·Clash 연결 패널에 나타나는 호스트 문자열 목록을 기록합니다.

어떤 호스트부터 묶을지

AWS가 문서화한 DNS 이름은 리전별로 조금씩 다르고, 프리뷰 기능까지 쓰면 접두 문자열도 자주 추가됩니다. 아래 목록은 출발점이며 반드시 본인 환경의 연결 로그를 기준으로 좁히세요.

자격 증명(STS 등): 글로벌이라면 sts.amazonaws.com, 리저널이라면 sts.<region>.amazonaws.com 패턴처럼 짧거나 리전 문자열을 포함합니다.
Bedrock 런타임과 컨트롤 플레인: 호스트에 bedrock-runtime·bedrock·bedrock-agent 같은 토큰이 섞입니다. 새 서비스가 붙어도 .amazonaws.com 접미는 공통적으로 붙습니다.
Knowledge/OpenSearch 계열: Knowledge 기능이 켜져 있으면 OpenSearch 서버리스 등 데이터 플레인 문자열 추가가 함께 나옵니다. STS가 이미 붙더라도 API 호스트 문자열 묶음이 다르면 별 규칙이 필요합니다.
SSO·IAM Identity Center 페이지: 브라우저에서 여는 시작 URL에 쓰인 호스트와 boto 등 SDK가 붙을 때 나타나는 STS 호스트 묶음이 서로 다를 때가 많습니다. 규칙에 한쪽만 들어 있으면 “인증은 되고 Bedrock 호출만 시간 초과”처럼 느껴질 수 있습니다.
OpenAI 등 외부 LLM 호스트: 같은 PC에서 테스트하는 경우 api.openai.com 등을 같은 전략 그룹에 넣거나, 사내 허브라면 허브 호스트를 인접 전략 그룹으로 두면 됩니다.

처음부터 amazonaws.com 접미 하나로 전부 덮면 관리는 빠를 수 있으나 다른 AWS 트래픽까지 같은 출구로 밀립니다. STS와 Bedrock 런타임 줄기부터 시작해 로그로 조금씩 정확하게 바꿉니다. 정책상 아웃바운드 자체가 막히는 회선이라면 여기 방법보다 회사 규칙부터 따르세요.

팁

IDE 디버깅 패널이나 개발자 도구에 문자열이 잘 안 보일 때 코어 패널의 PROCESS-NAME 또는 SRC-IP 규칙으로 프로세스 단위 행만 모으면 붙인 호스트를 빠르게 모을 수 있습니다.

전략 그룹 설계

전용 전략 그룹 이름을 예를 들어 PROXY_AWS_DEV처럼 붙여 두었다면 가장 먼저 확인할 것은 핑 순위가 아니라 TCP 연결이 길게 유지되고 Bedrock 스트리밍 응답이 중간에서 끊기지 않는 출구입니다. 속도 테스트에서 상위였다가 자동 전환 그룹처럼 출구가 자주 바뀌면 TLS 세션이 잘려 “응답 절반에서 멈춤” 형태의 시간 초과가 나올 수 있습니다.

브라우저 SSO와 STS·Bedrock 호출을 처음에는 같은 그룹에 묶어도 됩니다. 순환 새로 고침이나 Invoke만 반복 실패가 분명해지면 SSO 전용 그룹을 하나 더 만드는 식으로 나눕니다. OpenAI 등 외부 LLM 호스트를 같은 전략에 넣을지는 비용·감사 정책에 따라 다릅니다. YAML 전체 구조와 DNS 모드는 YAML 공통 정리와 같이 맞춰 두면 이후 서비스가 늘어도 추적이 쉽습니다.

규칙 예시와 순서

아래는 개념 스케치입니다. 전략 그룹·노드 이름은 자기 프로필에 맞게 바꾸고, 리전 문자열은 실제 사용 리전으로 교체하세요. 문자열이 안정되면 RULE-PROVIDER로 작은 묶음을 관리하는 편이 유지보수에 유리합니다.

# Conceptual excerpt — adapt regions/groups/providers to your profile
proxy-groups:
  - name: PROXY_AWS_DEV
    type: select
    proxies:
      - NODE_AWS_PRIMARY
      - NODE_AWS_BACKUP
      - PROXY_DEFAULT

rules:
  - DOMAIN-KEYWORD,sso,PROXY_AWS_DEV
  - DOMAIN-SUFFIX,sts.us-west-2.amazonaws.com,PROXY_AWS_DEV
  - DOMAIN-KEYWORD,bedrock-runtime,PROXY_AWS_DEV
  - DOMAIN-KEYWORD,bedrock-agent,PROXY_AWS_DEV
  - DOMAIN-KEYWORD,aoss,PROXY_AWS_DEV
  - DOMAIN-SUFFIX,api.openai.com,PROXY_AWS_DEV
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

DOMAIN-KEYWORD는 초기 재현에 빠르지만 과대 매칭이 생길 수 있으니 로그에 찍힌 호스트가 확정되면 접미를 좁히거나 DOMAIN 한 줄로 내리는 작업을 이어가면 됩니다.

STS·Bedrock용 규칙 행이 GEOIP나 MATCH보다 위쪽에 있는지 항상 확인하세요. 아래에 남아 있으면 “완전 실패”보다 간헐적인 시간 초과처럼 보일 때가 많습니다.

주의

이 글은 조직 정책·이용 약관을 위반하는 우회를 돕지 않습니다. 허용된 네트워크에서 라우팅 불일치로 생기는 지연을 줄이는 설정만 다룹니다.

시스템 프록시·환경 변수·터널

IDE 하위 프로세스는 브라우저만큼 시스템 프록시를 따르지 않을 수 있습니다. 셸에 남아 있는 HTTP_PROXY·HTTPS_PROXY 값이 Clash와 역전되면 동일 호스트라도 출구가 갈라집니다. 상용 ZTNA나 다른 VPN이 동시에 올라와 있으면 마지막에 잡힌 네트워크 확장만 살아 남는 경우도 있으니 재현할 때는 한 번에 변수 하나씩만 바꿉니다.

fake-ip 계열 DNS를 쓰는 경우 SSO 리디렉션이 순환처럼 보일 수 있으니 DNS 모드와 예외 목록을 함께 점검합니다.
WSL 게스트 안에서 테스트한다면 같은 호스트라도 선택된 네트워크 경로가 호스트 OS와 다를 수 있어 mixed-port 가이드를 함께 읽어 두면 원인 분석이 빨라집니다.
Git·npm 같은 개발 트래픽까지 동시 관리해야 하면 환경 변수 순서 정리 안내가 개발 도구 분기 페이지에 정리되어 있습니다.

점검 순서 요약

실행 중인 코어 프로필이 rule 모드인지 확인합니다.
Toolkit·SDK를 재현하는 동안 연결 패널의 호스트 이름을 기록합니다.
각 호스트를 STS·Bedrock·SSO·OpenAI 중 어디에 해당하는지 태깅합니다.
추출한 호스트 줄을 PROXY_AWS_DEV 전략에 묶었을 때 GEOIP·MATCH보다 순서 상 위쪽에 놓았는지 다시 검토합니다.
문제 패턴별로 노드 교체 테스트를 줄여 가며 원인 후보 목록만 남깁니다.

자주 묻는 질문

amazonaws 접미 규칙을 한 줄에 두어도 되나요?

범위가 매우 넓어 S3·Lambda 등 업무별 AWS 트래픽까지 같은 출구를 타 새 지연을 만들 수 있습니다. 처음에는 STS·Bedrock 런타임에 실제 로그로 확인된 호스트 문자열부터 좁힙니다.

OpenAI 같은 외부 호스트도 같은 전략에 넣어도 되나요?

같은 머신에서 연속 테스트한다면 api.openai.com을 동일 전략에 넣어도 됩니다. 다만 회사 프록시·로그 정책을 함께 검토하세요.

정리

AWS Agent Toolkit이나 Bedrock 연동은 STS·SSO·런타임·Knowledge·외부 LLM 호스트가 한 작업 흐름에 같이 들어옵니다. 한 호스트만 엉뚱한 출구를 타도 전체가 시간 초과로 보이기 쉬우니 로그로 문자열을 모으고 전략 그룹에 매핑한 뒤 규칙 순서를 위에서 아래로 다시 읽는 습관이 가장 큰 이득입니다.

범용 VPN 앱은 대부분 전체 트래픽을 한 방향으로 밀어 넣기 때문에 개발자 도구 호스트 단위로 원인을 좁히기 어렵습니다. YAML 한 장으로 호스트 묶음을 명시해 두면 문제가 생겼을 때도 후보를 빠르게 줄일 수 있습니다. 최신 클라이언트는 다운로드 페이지에서 확인할 수 있으며, 프로필을 정리한 뒤 Clash를 내려받아 Bedrock·STS 전용 전략 그룹부터 맞춰 보시기 바랍니다.