S4 Firewall
LLM token budget 및 runaway-loop control
자체 VPC 안에서 동작하는 forwarding proxy로, LLM traffic 앞단에 pre-emptive spend firewall을 둡니다. app은 base_url만 변경하면 됩니다(OpenAI-compatible, Anthropic Messages-compatible, Bedrock-compatible). 모든 request는 synchronous attribute → reserve → budget/anomaly → forward → reconcile pipeline을 거칩니다. 핵심 역할은 runaway-loop circuit breaker입니다: budget이 초과될 request를 relay 전에 결정론적으로 block합니다.
S4 Firewall은 LLM token spend 앞단에 budget과 circuit breaker를 두는 forwarding proxy이며, 두 layer를 명확히 분리합니다. Layer 1인 hard cap은 deterministic하고 pre-emptive합니다. cumulative spend를 알고 있으므로 reservation이 running total을 configured hard cap보다 높이는 request는 relay 전에 block됩니다 — over-cap request를 100% pre-emptive block하며 chaos test로 고정됩니다. Layer 2인 loop block은 best-effort behavioral layer입니다. agent loop, near-duplicate call chain, in-session amplification을 detect해 blast radius를 제한합니다. spend는 feature / tenant / customer별로 attribution되며, streaming response는 chunk 단위로 pass-through되어 time-to-first-token이 보존됩니다.
해결하고자 하는 과제
LLM 토큰 지출은 에이전트 루프, 유사 중복(near-duplicate) 호출 체인, 세션 내 증폭 등 제어 불능 상태가 되기 매우 쉽습니다. 이로 인해 인지하기도 전에 한 달 예산을 순식간에 소진해 버릴 수 있습니다. 출력 토큰 수는 응답이 반환되기 전에는 알 수 없기 때문에, 요금이 발생하기 전에 지출을 차단하는 메커니즘이 없다면 사후에 어떤 기능, 테넌트, 고객이 비용을 발생시켰는지 역추적해야 합니다. 결국 지출이 실제 의도한 작업이 아닌 제어되지 않는 루프를 따르게 되는 것이 문제입니다.
작동 원리
- 1
base_url을 지정하기만 하면 됩니다
S4 Firewall은 자체 Amazon VPC 내부에서 실행되는 forwarding proxy입니다. 애플리케이션은 base_url만 변경하면 됩니다. 방화벽이 OpenAI 호환, Anthropic Messages 호환, Bedrock 호환 인테이크를 수신하고 각 요청을 이미 사용 중인 업스트림 프로바이더로 전달합니다. 스트리밍 응답은 버퍼リング 없이 청크 단위로 그대로 통과하므로 time-to-first-token이 그대로 유지됩니다.
- 2
하나의 동기식 파이프라인에서 속성 분류, 예약 및 결정 수행
전달하기 전에 모든 요청은 동기식 attribute -> reserve -> budget/anomaly -> forward -> reconcile 파이프라인을 거칩니다. 요청을 특정 기능, 테넌트, 고객に 연결하고 최악의 시나리오 비용(입력 토큰은 지금 계산, 출력은 max_tokens에 출력 속도를 곱해 산정)을 예약한 뒤, 예산 계층과 대조하여 전송할지 차단할지 결정합니다.
- 3
두 개의 레이어로 차단하고 실제 사용량과 대조하여 정산
Layer 1 하드 캡은 결정론적이며 선제적입니다. 예약이 설정된 상한을 초과하는 요청은 전달 전에 100% 차단됩니다(동일한 상태에서 동일한 결정이 나오며, chaos test를 통해 확인됨). Layer 2 루프 블록은 행동 기반의 best-effort 방식으로 작동하며, 에이전트 루프, near-duplicate 호출 체인, 세션 내 증폭을 감지하여 피해 범위를 제한합니다. 응답이 반환되면 프로바이더가 보고한 usage를 단일 진실 공급원(source of truth)으로 삼아 예약 내역과 대조하여 reconcile합니다.
주요 특징
Deterministic hard cap: over-budget request를 relay 전에 block합니다(tenant / feature / customer budget hierarchy).
런어웨이 루프 회로 차단기: agent loop와 near-duplicate call chain을 감지해 blast radius를 제한합니다.
Drop-in: OpenAI / Anthropic / Bedrock 호환 base_url, streaming passthrough(TTFT 유지), 자체 VPC에서 실행.
포함 사항
- Amazon Linux 2023 기반 arm64 AMI(c6g / c7g Graviton 인스턴스에서 작동, 인스턴스 시간당 요금 측정)
- OpenAI 호환, Anthropic Messages 호환, Bedrock 호환 인테이크를 제공하는 forwarding proxy(애플리케이션은 base_url만 바꾸면 되며, 스트리밍은 청크 단위로 바로 유입되어 TTFT가 보존됨)
- Layer 1 하드 캡 — 결정론적이고 선제적인 서킷 브레이커. 중계 전 예산을 초과하는 모든 요청을 100% 차단(chaos test를 통해 확인)
- Layer 2 루프 블록 — 에이전트 루프, near-duplicate 호출 체인, 세션 내 증폭을 감지하여 피해 범위를 제한하는 best-effort 행동 기반 레이어(100% 보장이 아니며, dry-run 섀도 모드 포함)
- reserve-then-reconcile 토큰 회계 — 최악의 경우 비용(입력은 즉시 계산, 출력은 max_tokens * 출력 요율로 가격 책정)을 예약하고, 응답 후 프로바이더가 보고한 usage를 source of truth로 삼아 대조하여 reconcile
- 기능/테넌트/고객별 토큰 지출 속성 분류, Amazon CloudWatch(namespace S4/Firewall)로의 전송 및 옵션으로 제공되는 counts-only 감사 원장(프롬프트 및 응답 본문은 저장하지 않음)
- 원클릭 CloudFormation 템플릿(단일 인스턴스용 cfn-single.yaml 및 내부 로드 밸런서 뒤에 중복으로 배치되는 플릿용 cfn-ha.yaml), 최소 권한 IAM 역할 제공, 별도의 컨트롤 플레인이나 데이터베이스 불필요
주요 활용 사례
폭주하는 에이전트가 한 달 예산을 소진해 버리기 전에 결정론적인 하드 캡을 통해 선제적으로 중단시키고자 하는 경우
기능, 테넌트, 고객별로 토큰 지출을 분류하고, IAM principal보다 상세한 단위로 예산을 할당하고자 하는 팀
프롬프트나 응답 본문을 제3자에게 넘기지 않고, 콘텐츠가 아닌 토큰 수만 기록하는 원장으로 LLM 트래픽을 통제하고자 하는 경우
애플리케이션의 base_url을 가리키는 것만으로 자체 VPC 내에서 OpenAI, Anthropic, Bedrock 호환 트래픽에 대한 통합 예산을 운영하고자 하는 경우
자주 묻는 질문
폭주하는 에이전트를 100% 차단할 수 있나요?
당사는 두 레이어를 명확히 구분합니다. Layer 1 하드 캡은 결정론적이고 선제적이며, 예약을 초과하는 요청은 전달 전에 100% 차단됩니다(동일한 상태에서 동일한 결정이 도출되며, chaos test를 통해 입증됨). 반면 Layer 2 루프 감지는 best-effort 방식으로 작동합니다. 폭주는 몇 차례 호출이 발생한 후에만 감지할 수 있으며 그 시점에는 이미 요금이 발생했으므로, 100% 방지를 보장하기보다 피해 범위를 최소한의 요청 수나 금액으로 한정하는 기능입니다. 규제(enforce)를 시작하기 전에 오탐 차단(false-block)율을 측정할 수 있도록 dry-run 섀도 모드를 지원합니다.
출력 토큰 수를 미리 알 수 없는데 어떻게 청구 전에 지출을 차단하나요?
단순 추정이 아닌 reserve-then-reconcile 방식으로 수행됩니다. 중계 이전 단계에서는 최악의 시나리오 비용(입력 토큰은 바로 계산하고, 출력은 max_tokens * 출력 요율로 가격 산정)을 기반으로 예약을 실행하여 하드 캡을 결정합니다. 응답이 반환되면 프로바이더가 보고한 usage를 source of truth로 사용하여 예약 내역과 reconcile을 진행합니다. 토큰 수는 프로바이더 간에 규격화되며 입력, 출력, cached-read, cache-write로 분류되어 각 공급업체의 실제 요금표에 맞춰 회계 처리됩니다.
프롬프트는 어디에 저장되거나 전송되나요?
S4 Firewall 자체는 프롬프트나 응답을 저장 또는 전송하지 않습니다. 유일한 아웃바운드 호출은 애플리케이션이 원래 전송했을 프로바이더 요청뿐이며, 방화벽이 불필요한 egress를 유발하지 않습니다. 원장과 메트릭에는 토큰 개수만 반영되며 본문은 포함되지 않습니다(counts-not-content, property test를 통해 검증됨). 프롬프트가 외부로 노출되는 경로는 선택하신 업스트림에 따라 다릅니다. 이 AMI가 프로비저닝할 수 있는 VPC 인터페이스 엔드포인트(PrivateLink)를 통해 Amazon Bedrock으로 연결하면 호출은 AWS 내부 경계에 유지되지만, 퍼블릭 인터넷의 외부 공급업체로 라우팅하는 트래픽은 VPC를 벗어나 인터넷으로 나가게 됩니다.
별도의 컨트롤 플레인이나 데이터베이스가 필요한가요?
아니요, 필요 없습니다. 별도의 컨트롤 플레인이나 외부 데이터베이스가 존재하지 않습니다. 예산 상태는 인스턴스별로 메모리에 유지되며, 재부팅 시 처음부터 다시 산출됩니다. 데이터 플레인은 향상된 capability가 전혀 없는 보안이 강화된(hardened) systemd 유닛 아래에서 작동하는 단일 정적 바이너리이며, 최소 권한의 IAM 역할(업스트림 모델 호출, S4/Firewall namespace로 제한된 CloudWatch PutMetricData, 원장 버킷으로의 write-only PutObject)만 부여됩니다. 외부로의 텔레메트리 home-call이나 license-key check도 없습니다.
요금은 어떻게 청구되며 어떻게 배포하나요?
과금은 AMI 시간당 요금(인스턴스 시간 단위 측정)으로 산정되며 연간 계약 옵션이 제공됩니다. c6g / c7g(Arm) 인스턴스에서 작동합니다. 배포 시에는 포함된 CloudFormation 템플릿(단일 인스턴스용 cfn-single.yaml, 내부 로드 밸런서 뒤의 이중화 플릿용 cfn-ha.yaml)을 사용하며, 선택적으로 Bedrock VPC 인터페이스 엔드포인트를 생성할 수도 있습니다. 그 후 애플리케이션의 base_url을 방화벽으로 설정하면 완료됩니다.
요금제 모델
시간당 software fee + EC2(c6g class, Arm). instance type별 metered 과금.
