Amazon S3 Technical FAQs

If you are a developer:

1. Technical Documentation
2. Code Samples
3. Developer Forums (after you finish reading this page :)

If you have no development experience and just want a storage solution:

• Check out our solutions catalog.

The bucket namespace is global - just like domain names. You can't create a bucket with a name that is already used by another Amazon S3 user. In most cases, the common names, such as "images" or "users" will not be available.

If you try to create a bucket with a name that already exists, you will get a 409 Conflict.

When you list the content of a bucket the results come back in blocks (currently 1000 keys or less). If the IsTruncated node is true in the response from Amazon S3, you'll need to make another request to get the rest of your keys. Your code must be prepared to handle this scenario.

If the IsTruncated flag is set, request the next page of results by setting Marker to the value of the NextMarker node from the last Amazon S3 response.

Check the system clock and time zone settings on the offending machine. Amazon S3 requires all machines making requests be within 15 minutes of an Amazon S3 webserver's clock. Setting up your machines to sync their times with an NTP server in addition to making sure they are patched for the recent Day Light Savings changes should resolve this issue.

This is a common error when a developer decides to deploy their application to another machine.

The response from Amazon S3 will contain the following:

• HTTP Status Code: 403 Forbidden
• Error Code: RequestTimeToo-Skewed
• Description: The difference between the request time and the server's time is too large.

There is not currently a way to perform any of these operations on an existing bucket. Data in the existing bucket will need to be downloaded and then re-uploaded into a newly created bucket.

This is the same approach you will need to take if you want to move a bucket to a different locale.

Yes, you can make your bucket publicly readable or even writable. Keep in mind, however, that you are responsible for the data that is both downloaded and uploaded to your buckets. Take care when giving someone 'write' access, as this user will have access to delete any object in the bucket.

You'll find more information about this topic in our technical documentation under the "Authentication and Access Control" section.

A key is a sequence of Unicode characters whose UTF-8 encoding is at most 1024 bytes long.

Please make sure to review the "Bucket Restrictions and Limitations" section of the technical documentation.

You can mimic a file system hierarchy by using the Prefix and Delimiter parameters when you list a bucket. When you store your objects, create key names that correspond to a typical file system path.

For Example: the bucket "my-application" could include the following keys:

• john/settings/conf.txt
• jane/settings/conf.txt

While parameters do exist that will allow you to mimic a typical file system hierarchy, you should not think of Amazon S3 like you would a typical file system. Amazon S3 is a distributed system that will exhibit some behavior you may not be used to seeing.

For Example: it may take a few seconds for an object update to propagate to all parts of the system.

The bucket limit is something new users need to take in to account when architeching their applications. In most cases, users find they only require a small number of buckets after they have taken a look at how mimic a standard file system (see above).

You have to use a DIME attachment when putting large objects via SOAP.

Microsoft .NET Framework users that want to use SOAP will need to install the WSE 2.0 package. It should be noted that WSE 3.0 (MTOM) is not yet supported by Amazon S3.

The Amazon network blocks the packet types (ICMP) used by trace route utilities (so destination unreachable is expected behavior).

Providing the results of a trace route are still useful when troubleshooting network related issues.

Speaking generally, the route between any end-user endpoint and the Amazon network normally traverses many routers, most of which are not controlled by either Amazon or end users. Providing the results of a trace helps to determine if a user is experiencing issues related to one of these many routers.

As our intent is to charge equitably for system resources used, we will be charging the owner of the bucket for 403s and 404s, since they consume system resources (as do all requests). Note that we will not be charging for requests which fail due to an Amazon S3 internal system error (all other requests will be billed).

If you suspect fraudulent or malicious access to your buckets, please contact us immediately and we'll work with you to resolve the issue.

You should not be getting charged when a request terminates with a 50x.

We do not currently provide the ability to cap your usage of Amazon S3.

If you would like to track your usage via bucket and object logging, please review the "Server Access Logging" feature in the Amazon S3 Developer Guide.

https://docs.amazonwebservices.com/AmazonS3/2006-03-01/ServerLogs.html

This service provides a best effort attempt to log all access of objects within a bucket. Please note that it is possible that the actual usage report at the end of a month will slightly vary.

Your other option is to develop your own service that sits between users and Amazon S3, that monitors all requests to your buckets/objects.

Transfer-Encoding: chunked is not supported. The PUT operation must include a Content-Length header.

When debugging Amazon S3 error responses, be sure to look at the XML error document located in the body of the HTTP reply message. It contains extra information about the error not included in the HTTP headers. Some HTTP user agents don't show the HTTP message body by default, but this extra information is essential for understanding the problem with your request.

In order to effectively troubleshoot issues related to Amazon S3, we typically need the following information:

• Request details: method, Request-URI, all HTTP headers, and the request body (if making a SOAP request)
• Response details: status code, all HTTP headers, and response body (which includes error details).

A user can obtain all of this information by logging the bits of a request on the wire before they leave their system, and by logging the bits from the Amazon server response on the wire before they reach their application.

Here are some example utilities available on the Internet for download that can be used to capture this data:

1. tcpmon
2. wireshark
3. ethereal
4. tcpdump