KubeMQ
ConnectorsAWS (SQS & SNS)Concepts

Configuration

Why the KubeMQ AWS connector is opt-in, how CONNECTORS_AWS_ENABLE opens port 4566, and the accept-any vs static credential postures.

The AWS connector is configured server-side under the Connectors.Aws block of the KubeMQ server config, exposed as ten CONNECTORS_AWS_* environment variables. Like most wire-protocol connectors, it is opt-in — disabled by default — because enabling it opens a new HTTP listener. A stock server does not serve AWS until you turn it on. See the Configuration reference for the full field table and the TOML/Env/Docker equivalents.

The only thing clients configure is the endpoint override via the KUBEMQ_AWS_URL environment variable (default http://localhost:4566), mapped to AWS_ENDPOINT_URL_SQS / AWS_ENDPOINT_URL_SNS. Everything below is broker-side server configuration.

Enable the connector

The connector is off until you enable it. Set its enable variable to true:

docker run -d \  --pull always \  --platform linux/amd64 \  --name kubemq \  --hostname kubemq \  -p 127.0.0.1:4566:4566 \  -p 127.0.0.1:50000:50000 \  -e STORE_ENGINE=next \  -e STORE_NEXT_ACK_POLICY=strict \  -e STORE_STORE_PATH=/kubemq/store \  -e API_BIND_ADDRESS=0.0.0.0 \  -e CONNECTORS_AWS_ENABLE=true \  -v kubemq-data:/kubemq/store \  europe-docker.pkg.dev/kubemq/images/kubemq-next:latest

Enabling the connector opens a new HTTP listener on port 4566. That port is not bound until CONNECTORS_AWS_ENABLE=true, and it must differ from the server's enabled gRPC/REST/HTTP ports — a collision aborts startup. This is precisely why the connector is opt-in rather than on by default: like five of the seven wire-protocol connectors, it does not bind a listener until explicitly enabled (only Kafka and RabbitMQ / AMQP 0-9-1 are on by default). The enable variable is CONNECTORS_AWS_ENABLE — the prefix carries the underscore (CONNECTORS_AWS_*), unlike the MQTT connector's CONNECTORSMQTT_*. To disable it again, set CONNECTORS_AWS_ENABLE=false (a config-only rollback; no data migration).

Credentials: accept-any vs static

The connector supports two credential postures. See Authentication for the full treatment.

Accept-any mode (default — no credentials configured)

When no credentials are configured, the credential store is empty: the connector parses the AccessKeyId and uses it as the ClientID, and logs once that it is running without credential verification.

Dummy credentials are still required. Even in accept-any mode the request must carry a syntactically valid SigV4 signature with an sqs/sns credential scope. An unsigned request is rejected with IncompleteSignature — the only SigV4-exempt action is SNS ConfirmSubscription. The signature is not cryptographically verified, but its presence and shape are. So the SDK must be given an access key and secret (any non-empty value).

Static credentials (CONNECTORS_AWS_CREDENTIALS_DATA)

Set CONNECTORS_AWS_CREDENTIALS_DATA to a JSON (optionally base64-encoded) array of credentials. Each entry carries an AccessKeyId, a SecretAccessKey, and an optional ClientID (defaulting to the AccessKeyId):

[
  {
    "AccessKeyId": "AKIA...",
    "SecretAccessKey": "secret...",
    "ClientID": "billing"
  }
]

When credentials are configured, SigV4 is fully verified: the access key must match a configured credential, and the signature is checked with a constant-time compare. The authenticated ClientID becomes the identity used for per-channel write/read authorization and the stamped sqs_sender_id tag. An empty key or secret is a configuration error.

SigV4 over plain HTTP is unencrypted on the wire. HTTPS is provided by the server-wide Security block — there is no AWS-specific TLS option. Production deployments should use the server's HTTPS listener. See Connectivity and security and Auth & security.

Getting Started

Enable the connector and run an SQS round-trip end-to-end in minutes.

Architecture

One binary, two service surfaces — SQS as a Queue channel and the virtual SNS registry.

Authentication

SigV4 accept-any vs static credentials, the ConfirmSubscription exemption, and per-channel authorization.

Capabilities

Supported SQS/SNS actions, the limitations list, and the out-of-scope features.

Was this page helpful?

Architecture

Inside the KubeMQ AWS connector — one binary with two service surfaces, SQS as a KubeMQ Queue channel, the virtual SNS registry, and cross-protocol interop.

Cross-Protocol Interop

Share an sqs.* channel between an AWS SDK app and a native KubeMQ gRPC/REST client — produce with boto3, consume with kubemq-go, and migrate one side at a time.

On this page

Enable the connectorCredentials: accept-any vs staticAccept-any mode (default — no credentials configured)Static credentials (CONNECTORS_AWS_CREDENTIALS_DATA)Related