A bucket name with dots
Created without complaint, and TLS fails later
s3: my.bucket.name
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
Created without complaint, and TLS fails later
s3: my.bucket.name
Rejected at creation, because the name is part of a DNS name
s3: My-Bucket
Path is a separate field, and the error names neither
iam: team/deployer
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
Stack names take letters, numbers and hyphens only, and must start with a letter.
Instead:Replace underscores with hyphens.
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.
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.
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.
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.
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.
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.
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.