How do you use Plugsky with AWS Bedrock workflows?

Key facts

Plugsky endpoint	POST https://api.plugsky.com/v1/chat/completions (OpenAI-compatible REST with a bearer key)
Bedrock API style	AWS SigV4-signed InvokeModel and Converse calls through AWS SDKs
Auth	Authorization: Bearer sk-live-…; store the key in Secrets Manager or SSM Parameter Store
Networking	HTTPS from Lambda, ECS or EC2; VPC, on-prem and air-gapped deployments for stricter boundaries
Streaming	Server-sent events on chat completions; Bedrock uses its own event stream format
Tools and JSON	Function calling and JSON mode are live; Bedrock tool use maps to the OpenAI tools array
Hybrid patterns	Overflow, fallback, dev/test and side-by-side model comparison next to existing Bedrock routes
Product status	Chat, streaming, embeddings and agents are live; batch and assistants are coming soon

TL;DR

• Treat Plugsky as a parallel route, not a Bedrock API replacement.
• Call it over HTTPS with a bearer key from any AWS compute service.
• Keep keys in Secrets Manager or SSM — never in Lambda environment plaintext.
• Bedrock Guardrails, Knowledge Bases and Agents stay on AWS.
• Route by workload: latency, cost, residency or model preference.

How it works, step by step

1. Decide which workloads move: overflow chat, evaluation, embeddings or regulated fallback.
2. Store the Plugsky key in AWS Secrets Manager and grant read access to one IAM role.
3. Package the OpenAI SDK in your Lambda layer or container image.
4. Call https://api.plugsky.com/v1 from your handler with a strict timeout.
5. Add a router that sends a share of traffic to Plugsky and the rest to Bedrock.
6. Log model, region and latency for both paths so comparisons stay honest.
7. Expand or roll back by changing the routing split, not the application code.

Original data

Try it yourself

Open the OpenAI migration checker →

How Plugsky fits around Bedrock

Bedrock and Plugsky are different API surfaces. Bedrock uses AWS SDKs with SigV4 signing and IAM authorization. Plugsky uses a plain HTTPS endpoint with an OpenAI-compatible body and a bearer key. That means there is no drop-in header swap — you write a small client, but you gain a second provider you can route to without changing application logic.

Common hybrid patterns:

• Overflow: keep Bedrock primary and spill to Plugsky when throttling or capacity bites.
• Fallback: fail over when a Bedrock region degrades.
• Evaluation: run the same prompts through both and compare on your own tasks.
• Residency: pin specific workloads to a Plugsky region or private deployment.

What does not map: Bedrock Guardrails, Knowledge Bases and Agents have no direct Plugsky equivalent, and batch and assistants are coming soon, so keep those pipelines on AWS for now.

Calling Plugsky from a Lambda

A minimal Python handler with the key loaded from Secrets Manager at cold start:

import json, os, boto3
from openai import OpenAI

_secret = None
def api_key():
    global _secret
    if _secret is None:
        sm = boto3.client("secretsmanager")
        _secret = sm.get_secret_value(SecretId=os.environ["PLUGSKY_SECRET_ARN"])["SecretString"]
    return _secret

client = OpenAI(api_key=api_key(), base_url="https://api.plugsky.com/v1")

def handler(event, context):
    resp = client.chat.completions.create(
        model="plugsky-pro",
        messages=[{"role": "user", "content": event["prompt"]}],
        max_tokens=512,
    )
    return {"statusCode": 200, "body": json.dumps({
        "text": resp.choices[0].message.content,
        "model": resp.model,
    })}

Grant the execution role secretsmanager:GetSecretValue on that one secret and nothing else. Set the Lambda timeout slightly above the client timeout so a stalled upstream does not consume the full function budget.

Mapping Bedrock-style calls

If your code already builds Bedrock Converse requests, keep a thin adapter that converts them once instead of rewriting call sites:

• Messages: Bedrock's content blocks map to OpenAI content strings or parts; text-only prompts are a direct copy.
• Tools: Bedrock tool specifications use inputSchema; convert to function.parameters.
• Inference config: maxTokens becomes max_tokens, and temperature/topP keep their names.
• Stop sequences: stopSequences becomes stop.
• Streaming: Bedrock emits its own event stream; Plugsky emits SSE frames. Both project down to a token callback, which is the interface your adapter should expose.

Add one adapter test per routed model so schema changes surface in CI.

When to keep Bedrock in the loop

Bedrock remains the better choice when you depend on AWS-native governance and integration: IAM-only authorization without static keys, Guardrails for policy enforcement, Knowledge Bases for managed RAG, PrivateLink networking and Marketplace procurement. Plugsky adds value where those constraints do not apply — flat self-serve plans, 30+ models behind one API, and deployment options from managed cloud to air-gapped environments.

A clean split: regulated and AWS-embedded paths stay on Bedrock; high-volume chat, extraction and embeddings go to Plugsky; and a router decides per request based on tenant, region or model. Record which provider answered every request in your logs, because residency and audit reporting will need it.

Honest comparison

Capability	Plugsky	AWS Bedrock	Hybrid router
API style	OpenAI-compatible REST	SigV4 AWS SDKs	Both
Auth	Bearer API key	IAM roles and policies	Both credential types
Model access	30+ models behind one endpoint	Region-dependent multi-vendor catalogue	Union of both
AWS-native features	No equivalent to Guardrails or Knowledge Bases	Deep AWS integration	Keep Bedrock-native pieces
Residency	Region pin plus VPC, on-prem and air-gapped options	AWS regions	Policy per route
Ops effort	Managed API	Managed AWS service	One extra route to monitor

Frequently asked questions

Can Plugsky replace Bedrock's InvokeModel API?

No. Plugsky is OpenAI-compatible, not SigV4-signed. You write an adapter or a router and call it over HTTPS with a bearer key.

Can I call Plugsky from Lambda?

Yes. Package the OpenAI SDK or use plain HTTPS, store the key in Secrets Manager or SSM, and set explicit timeouts on both the Lambda and the client.

How do I authenticate from AWS?

Use a bearer API key read at runtime from Secrets Manager. Avoid putting the key directly in Lambda environment variables.

Should I keep Bedrock?

Yes, for AWS-native features such as Guardrails, Knowledge Bases, Agents and PrivateLink, and for workloads bound to AWS procurement.

How does streaming differ?

Bedrock uses its own event stream format; Plugsky returns SSE frames in the OpenAI format. Normalize both into a token callback in your adapter.

What about batch and fine-tuning?

Those endpoints are coming soon on Plugsky. Keep those pipelines on Bedrock until they ship.

How do I choose which requests go where?

Route by tenant, region, task type or measured quality. Start with a small percentage to Plugsky, compare evals and logs, then expand.

Can I keep data in a specific region?

Yes. Plugsky supports region pinning (me-central-1, eu-west-1, us-east-1, ap-southeast-1) and private deployment options for stricter boundaries.