Standardized aws: [ERROR]: format for all CLI error messages

[AndrewAsseily]

Issue #, if available: CLI-7288

Description of changes: Standardizes all AWS CLI error messages to use the format aws: [ERROR]: <error-message>.

Behavior:

Before:

Unknown options: --invalid-option

After:

aws: [ERROR]: Unknown options: --invalid-option

Backward Compatibility

Error message content is preserved exactly. Only the prefix changes from error: to [ERROR]:. Scripts parsing error content should continue to work with minimal modifications.

Description of tests:

• Unit and functional tests pass locally.

Note: Marked as enhancement rather than feature since this will be released alongside the Structured Error PR (#9890) which triggers the minor version bump.

[ashovlin]

Changes look good! Is there any way with ruff to protect against new sys.stderr.write calls moving forward? Don't go too far out of the way, but curious if there's a quick win.

[AndrewAsseily]

Thanks! I've thought about this a bit. Unfortunately Ruff doesn't have a built-in way to ban specific method calls like sys.stderr.write(). The banned-api rule only works for imports, not function calls.

There are already several existing sys.stderr.write() calls in the codebase (cloudtrail/validation.py, s3uploader.py, etc.), I think the most practical approach is to rely on code review to catch new instances. We could add a grep-based CI check, but that feels brittle and would have to maintain an allowlist of existing violations.

[ashovlin]

Thanks! I've thought about this a bit. Unfortunately Ruff doesn't have a built-in way to ban specific method calls like sys.stderr.write(). The banned-api rule only works for imports, not function calls.

There are already several existing sys.stderr.write() calls in the codebase (cloudtrail/validation.py, s3uploader.py, etc.), I think the most practical approach is to rely on code review to catch new instances. We could add a grep-based CI check, but that feels brittle and would have to maintain an allowlist of existing violations.

Sounds good for now. I don't think the risk is too high of a new exception slipping through, since these are intended for humans, not automation. Can possibly revisit if ruff adds plugins/custom rules.