# Configuration (/connectors/aws/concepts/configuration)



The AWS connector is configured server-side under the `Connectors.Aws` block of the KubeMQ
server config, exposed as **ten `CONNECTORS_AWS_*` environment variables**. Unlike the other
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](../reference/configuration) for the full field table and the
TOML/Env/Docker equivalents.

<Callout type="info">
  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.
</Callout>

## Enable the connector [#enable-the-connector]

The connector is &#x2A;*off until you enable it.** Set its enable variable to `true`:

<RunKubeMQ ports="[4566, 50000]" env="{ CONNECTORS_AWS_ENABLE: 'true' }" />

<Callout type="warn">
  **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 all six wire-protocol connectors, it does not bind
  a listener until explicitly enabled. 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).
</Callout>

## Credentials: accept-any vs static [#credentials-accept-any-vs-static]

The connector supports two credential postures. See
[Authentication](/connectors/aws/how-to/authentication) for the full treatment.

### Accept-any mode (default — no credentials configured) [#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.

<Callout type="warn">
  **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).
</Callout>

### Static credentials (`CONNECTORS_AWS_CREDENTIALS_DATA`) [#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`):

```json
[
  {
    "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.

<Callout type="info">
  SigV4 over plain HTTP is &#x2A;*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](/connectors/aws/how-to/connectivity-and-security) and
  [Auth & security](/connectors/reference/auth-and-security).
</Callout>

## Related [#related]

<Cards>
  <Card title="Getting Started" href="/connectors/aws/tutorials/getting-started" description="Enable the connector and run an SQS round-trip end-to-end in minutes." />

  <Card title="Architecture" href="/connectors/aws/concepts/architecture" description="One binary, two service surfaces — SQS as a Queue channel and the virtual SNS registry." />

  <Card title="Authentication" href="/connectors/aws/how-to/authentication" description="SigV4 accept-any vs static credentials, the ConfirmSubscription exemption, and per-channel authorization." />

  <Card title="Capabilities" href="/connectors/aws/reference/capabilities" description="Supported SQS/SNS actions, the limitations list, and the out-of-scope features." />
</Cards>