The --role-session-name value passed to aws sts assume-role (or the equivalent SDK parameter) looks like free text, but AWS enforces a specific length and character-set rule on it - and a value that violates that rule fails the API call with an error that names the parameter but does not always make it obvious which character was the problem, especially in an automated pipeline where the value was constructed dynamically. Role Session Name Validator checks a proposed session name against AWS's documented rule locally and, on failure, states the specific reason: too short, too long, or which exact character(s) are not allowed.
AWS documents RoleSessionName as 2 to 64 characters, restricted to the pattern [\w+=,.@-]+ - word characters (letters, digits, underscore) plus six specific special characters: +, =, ,, ., @, and -. Anything else - spaces, slashes, most punctuation, unicode letters or symbols - is outside the allowed set. This tool implements exactly that documented pattern and, rather than a single pass/fail bit, reports which specific rule was violated and, for a character-set failure, the exact distinct offending characters found in the string, so the fix is obvious instead of requiring a manual re-scan of a 40-character generated string.
Because this check is a local regex against AWS's published documentation rather than a live call to the STS API, this tool says so plainly instead of implying perfect certainty: if AWS's real server-side enforcement ever differs subtly from its own documented pattern, this tool's verdict could in principle disagree with what a real aws sts assume-role call does. Treat it as a fast, honest local sanity check to catch an obviously invalid session name before it reaches AWS - not as a formal guarantee that a "valid" result will always be accepted, or that an "invalid" result would always be rejected.
A handful of sample session names - some valid, some deliberately invalid in different ways (too short, contains a space, contains a slash, too long) - are provided as one-click examples, so you can see each failure mode reported with its specific reason without having to construct bad input yourself.