AWS Resource Name Validator

Every service has its own naming rules, and most of them are only discoverable by being rejected. One of them is not a rejection at all.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Validate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A bucket name with dots

Created without complaint, and TLS fails later

s3: my.bucket.name

An uppercase bucket name

Rejected at creation, because the name is part of a DNS name

s3: My-Bucket

A path inside an IAM role name

Path is a separate field, and the error names neither

iam: team/deployer

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Using dots in an S3 bucket name to mirror a domain

    It is legal at creation and breaks TLS on the virtual-hosted URL, so the failure appears later and in a different tool.

    Instead:Use hyphens. If the bucket serves a domain, put CloudFront in front of it.

  2. Putting a path in an IAM role name

    Path is a separate field, and the API rejects a slash in the name with an error that names neither.

    Instead:Set Path and RoleName separately.

  3. Naming a CloudFormation stack with underscores

    Stack names take letters, numbers and hyphens only, and must start with a letter.

    Instead:Replace underscores with hyphens.

A dot in an S3 bucket name is legal and breaks TLS

The wildcard certificate for *.s3.amazonaws.com covers one label, so bucket.name.s3.amazonaws.com fails validation. The bucket is created without complaint and the failure arrives later, in an SDK.

Which affects more than the SDK

Transfer Acceleration will not work with a dotted name, and static website hosting behind CloudFront needs extra care. Every SDK either falls back to the path style or errors, and which one it does depends on the SDK and its version.

S3 bucket names are global across every AWS account

A perfectly valid name can still fail with BucketAlreadyExists because somebody else has it, in an account you will never see. Including the account id in the name avoids both the collision and the guessability.

The character rules differ more than they look

Lambda allows underscores and rejects dots. DynamoDB allows both and is case sensitive. CloudFormation rejects underscores entirely and requires a leading letter. ECR follows the Docker rules, so uppercase is out and separators cannot repeat.

An IAM path is a separate field from the name

The ARN is built from both, so a slash in the name is rejected and the error mentions neither field. Set Path to /team/ and the name to the last segment.

A 64 character Lambda limit is on the name alone

Not the qualified ARN with an alias, which is longer and is not what is measured. The same applies to an IAM role, where the path does not count toward the 64.

An SQS FIFO queue name has to end in .fifo

It is the only place a dot is allowed in an SQS name, and a FIFO queue without the suffix is rejected while a standard queue with it is too.