New answers tagged

0

No, a backup strategy for off service is required regardless of the service in question. Aside from the potential for service side corruption, account issues can cause unrecoverable issues.


5

Versioning is a great feature, and it should absolutely be used if possible. Having versioning enabled (and using appropriately-provisioned access keys) can save you from all manner of issues. But. Versioning won't protect you from; Loss of control of your AWS account, S3 downtime or widespread corruption, Other similar act-of-god type issues. You ...


0

A helpful forum poster over on AWS helped me to figure it out. It is indeed not a DNS-related issue, but rather a webserver one. In this case, the webserver effectively being AWS S3. It was incorrectly set up with a redirect to (not surprisingly) route requests from the actual domain to the S3 bucket address. Actually I think that the user documentation was ...


0

Set the bucket policy on the s3 bucket that you want to use, either create a role or use your existing ec2 role to add to the policy. { "Version": "2008-10-17", "Statement": [ { "Sid": "", "Effect": ...


1

To communicate to s3 you need to have 2 things IAM user credentials who has read-write access to s3 bucket. A client like aws-cli for bash, boto library for python etc. once you have both, you can transfer any file from your machine to s3 and from s3 to your machine. Below is the example for aws-cli. to sync all files in a folder aws s3 sync ...


2

There are so many ways to simulate something going down. You've already said one which is to use iptables block rules. Another really simple way - unplug the network router so that your monitoring software can still see the host, but the host can't talk to S3 (or anything else for that matter). To me, this is the simplest but may in some cases not be ...


1

I cannot block write access if the bucket is meant to be read from and written to by the root user, and is monitored by the root user. This story starts and ends with the fact that this bucket needs to be accessed via IAM. Your root account on AWS exists only to setup the IAM roles. Once you've got that setup, you can alter the IAM privileges to test.


1

Why not just check for the existence of a specific file in the S3 bucket. If it's not there, throw your SNMP trap. Creating/deleting this file will make it very simple to verify that your script is working properly.


2

There is no way to avoid the cost entirely, because any form of "outbound" data transfer comes with a cost. Import/Export "disk" services are not yet available in your region, otherwise you could use a physical external hard drive, ship it to Amazon, they load your data from S3 to the disk, send it to you, you send it back to them at a different location, ...


0

seems like what you want to do is generate a signed URL with an expiration time. See Share an Object with Others


0

Consider temporarily setting the proxy_pass backend service to either a local service or an HTTP echo service so you can review the full HTTP request being sent to Amazon. (If you use an HTTP echo web service, remove your sensitive bits from the request first!). Then you debug what's wrong with the Amazon request directly. Once you figure that out, you ...


1

Questions What is the principal and what do I put there? ---The principal is the ARN of the IAM user, role or account that you want to grant or deny access in this policy. What is the keyname? Where do I find it? ---What S3 calls "Keys" you may call a "folder", it is the sub folders you create within the bucket. If do not wish to add that level of ...


2

Unfortunately you'll need access to the actual DNS records to point the domains to the S3 bucket. You can use Route53 for all of your domains. Just create Hosted Zones for each, then check your NS entry in your newly created zones, then go to your registrar and update your domains to use these NS servers - you can then use Route53 to manage all of your DNS ...



Top 50 recent answers are included