Follow AWS naming rules and adopt consistent, descriptive naming conventions for S3 buckets and objects to ensure global uniqueness, DNS compliance, compatibility, and efficient data management.
Naming your S3 buckets and files (objects) correctly is a foundational step for building scalable, maintainable, and high-performance applications on AWS. AWS provides specific technical rules you must follow, and industry best practices recommend organizational conventions to make your data easy to manage and secure. Bucket names are globally unique across all AWS accounts, while object keys are unique within a bucket.
Bucket names must be between 3 and 63 characters long.
Names can consist only of lowercase letters, numbers, dots (.), and hyphens (-).
Names must begin and end with a letter or number.
Names must not contain two adjacent periods (..).
Names must not be formatted as an IP address (e.g., 192.168.5.4).
Names must not start with the prefix 'xn--'.
Names must not end with the suffix '-s3alias' or '--ol-s3' or '.mrap'.
Bucket names are globally unique across all AWS accounts within the same partition .
Avoid dots (.) in bucket names for general-purpose buckets unless you have a specific need, such as static website hosting. Dots can cause issues with SSL certificate validation for virtual-hosted-style access and prevent you from using S3 Transfer Acceleration .
Use hyphens (-) instead of dots to separate words and maintain DNS compatibility (e.g., my-application-data instead of my.application.data) .
Choose a consistent and descriptive naming convention that includes information like company name, environment, data sensitivity, region, account ID, and purpose. For example, exampleco-raw-useast1-12345-dev for a raw data layer bucket .
Consider using the new account regional namespace to create predictable bucket names that are guaranteed to be available only to your account within a specific region. The name format includes your account suffix, e.g., mybucket-123456789012-us-east-1-an .
Remember that bucket names are immutable – you cannot rename them after creation. If you need a different name, you must create a new bucket and move your data .
If you delete a bucket and want to reuse its name, be aware it can take 48–72 hours for the name to become globally available again .
Keep object key names descriptive and use a logical hierarchical structure with prefixes (like folders) and the forward slash (/) delimiter. For example, Development/Projects.xls .
Use safe characters to avoid application issues. The recommended set includes alphanumeric characters (0-9, a-z, A-Z) and special characters like !, -, _, ., *, ', (, and ) .
Be aware of object key length limits. The total UTF-8 encoded name must be 1,024 bytes or less, which includes all prefixes and delimiters .
Avoid characters that require special handling or URL encoding. Be cautious with & $ @ = ; : + , ? and spaces .
Do not use characters that cause significant handling issues, including \ { ^ } % ] " > [ ~ < # |`. Avoid non-printable ASCII characters (128-255 decimal) .
Be careful with trailing periods (.) in key names. The S3 console may strip them when downloading objects; use the AWS CLI or SDKs to preserve them .
Avoid object keys with period-only path segments such as ./, ../, or keys that contain /. /. These can cause path normalization issues and unexpected behavior with various applications and tools .
Adopting a consistent naming convention across your organization not only helps with data governance but also simplifies lifecycle management and cost allocation. For data lakes, it's recommended to use separate buckets for different data layers (e.g., raw, stage, analytics) with clear naming . Always consider your long-term data strategy when naming buckets, as they are foundational and immutable once created .
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
