Amazon Simple Storage Service (S3) has many configuration options that control who can access content in your S3 buckets, whether your bucket acts as a statically served website, and if objects in your bucket are replicated to another S3 bucket for extra durability. Blue Matador detects changes and issues with these configuration options and creates anomalies to help your correlate these changes with other issues such as an increase in 4xx’s from CloudFront, increased response times, or issues accessing items in your bucket.
The Bucket Policy controls access to your S3 bucket. Changes in the bucket policy should be infrequent and can have unintended consequences. The bucket policy may control cross-account bucket access, or public access to an S3 bucket.
A CORS configuration is required if you are hosting fonts or static assets in an S3 bucket that need to be accessed from another origin (domain). A change in CORS configuration should be rare and can affect the ability of any web browser to request content from the bucket.
Static website hosting in S3 allows the contents of an S3 bucket to act as a statically-served website without any web server. The configuration specifies an index page, error pages, and redirect rules. Changes to this configuration can inadvertently make pages unavailable and cause redirects.
S3 buckets can be set up to replicate their data to S3 buckets in other regions or AWS accounts. Blue Matador detects when a bucket is configured to replicate to a bucket that does not exist. This can easily happen if somebody deletes or renames a bucket, not knowing that it is the target of replication, especially if the target bucket is in another AWS account.
When this happens, replication will need to be reconfigured with a bucket that does exist. Make sure permissions to that bucket are correctly set and enable replication. Enabling replication does not copy over existing data, so data that should have been replicated will have to be copied using the S3 API.