Request for a new topic: Expand remote storage authorization example

## Description

Migrated from original Issue in DevDocs: https://github.com/magento/devdocs/issues/8823

Possibly expand topic or create a new sub-topic with a generic example for including the Nginx `ngx_aws_auth` module for use with secret keys.

## Content checklist

- [ ] The topic provides an explanation of how ____ works.
- [ ] The topic provides steps for ____.
- [ ] The topic contains code samples that shows ____.

## Additional information

per Slack: i think we need to show a sample scenario for IAM and for the secret keys, separately, and in more depth.

### Suggestions

The following suggestions were provided in the original Issue.

- [ ] If you use EC2 IAM profiles you don't need the Access keys or secret keys in the Magento config.

- [ ] If you don't use the Nginx ngx_aws_auth module, you need to allow public access to the S3 bucket so that nginx can proxy images without getting a 403 forbidden. You can set a bucket policy like this (make sure you uncheck block all public access first:

```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPublicGetObjectOnly",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::BUCKET/*"
}
]
}
```

This will ensure nginx can still proxy but nobody can just browse to the bucket to see the assets. I've not tried the ngx_aws_auth module but I believe if that module is used and it's configured with the keys, you don't need to set public access above.

Alternatively, there's methods of locking down access to the S3 bucket via VPC. So if you're using EC2 to host Magento, you could add an additional layer of security by just allowing resources in that VPC access to the bucket. Again, it depends on what security you need.

- [ ] The Nginx code snippet for proxying should be rewritten as follows to use new virtual hosted style access instead of path style access (which is [being deprecated](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/), see more information [here](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#virtual-hosted-style-access))

```
location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ {
# Proxying to AWS S3 storage.
resolver 8.8.8.8;
set $bucket "";
set $region "";
proxy_pass https://$bucket.s3.$region.amazonaws.com$uri;
proxy_pass_request_body off;
proxy_pass_request_headers off;
proxy_intercept_errors on;
proxy_hide_header "x-amz-id-2";
proxy_hide_header "x-amz-request-id";
proxy_hide_header "x-amz-storage-class";
proxy_hide_header "Set-Cookie";
proxy_ignore_headers "Set-Cookie";
}
```

> One thing I did notice is.. the new media gallery doesn't work when S3 is used as remote media. I've run the media.gallery.synchronization and media.content.synchronization commands but there's no change. The old media gallery still works though.

Start by locating the existing remote-storage documentation topic referenced by the migrated DevDocs issue and review its current Nginx and S3 guidance. Compare it with the requested IAM-profile, secret-key, ngx_aws_auth, bucket-policy, VPC, and virtual-hosted-style examples. Done means the topic or sub-topic explains each scenario with steps and code samples, while the media gallery concern is separately verified or documented.

Written by the indexing model from the issue text.