Individual Amazon web services are actually quite amazing all on their own but they are really neat when you start to use them together.
There probably isn’t anyone who in their life hasn’t had a sdcard or hard disk fill up who just needed a small bit of extra space to complete their action. Of course in that situation in the real world you have to stop what you are doing and free up (ie delete something) so you can continue.
Amazon S3 doesn’t have that problem. If you have the budget, you can keep adding data to it until you are satisfied you are finished. Sure you have to keep on eye on the costs but that is a completely separate issue.
However, it isn’t any one service that makes AWS so cool as much as how they all seem work together. One such example of that is the ability to send notifications based on some event that has occurred. This might be an event you setup to monitor your costs or it might be used as a trigger to an application.
In my case, I am going to demonstrate an email notification going out if a file ends up in a S3 bucket. If you were some sort of picture site, this might instead be triggering a lambda function to create thumbnails or perhaps this information might be put into a queue for some other processing (or both).
In my previous article, AWS – Simple Notification Service, I discussed everything that needs to be done in order to setup a Simple Notification Service topic but in this blog entry I will actually use put the AWS SNS to use.
In addition to sending out messages, I will also add replication to a s3 bucket. This will provide a cool way to put data into one bucket and watch it being replicated to the second bucket. This replication is pretty much as the name says. If you add data to the source bucket, it will be added to the destination bucket but if you delete it from the source bucket it will also be deleted from the destination bucket.
The replication is actually quite simple. The setup is essentially from where do you want to copy what, and where should it be placed. Replication setup is available from the management tab on the bucket.
It is also possible, actually recommended that you check the checkbox to encrypt the objects that are replicated.
The replicated box must be in another region. It is also possible to change the storage class in the destination. By selecting a class with a different type it may be possible to reduce the cost of the storage in this additional location.
I did not create this IAM rule, nor name myself – I had it created for me. This is necessary in order to allow the proper read and writing for these two S3 buckets.
Once the replication setup has been saved then new data that is saved or deleted from the source bucket will be replicated a short while later in the destination bucket.
The actual notifications on the S3 bucket are trivial to setup. Simply go to the properties of the bucket and setup an “event”.
It is possible to be notified depending on which type of action occurred, ranging from simple create or even just simple HTTP commands.
However, it might not be quite that simple as it appears on first look.
You might get an error if the permissions are not properly setup in the simple notification service.
Once you setup the proper permissions in the simple notification setup you can then create and save other rules as long as they do not overlap in functionality (ie two different types of create)