An Architect's vision

As of 12:00 AM PDT April 30, 2015, AWS will discontinue support of SSLv3 for securing connections to S3 buckets. Security research published late last year demonstrated that SSLv3 contained weaknesses that weakened its ability to protect and secure communications.  These weaknesses have been addressed in the replacement for SSL, TLS. Since then, major browser software vendors have been disabling support for SSLv3 and their work is largely complete. Consistent with our top priority to protect AWS customers, AWS will only support versions of the more modern Transport Layer Security (TLS) rather than SSLv3. For further reading on SSLv3 security concerns and why it is important to disable support for this nearly 18 year old protocol, we suggest the following articles: https://www.us-cert.gov/ncas/alerts/TA14-290A https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ http://disablessl3.com/#why

Amazon RDS generates a significant number of events in categories that you can subscribe to using the Amazon RDS Console, CLI, or the API. Each category applies to a source type, which can be a DB instance, DB snapshot, DB security group, or DB parameter group. Event categories for a DB instance source type include: Availability, Backup, Configuration Change, Creation, Deletion, Failover, Failure, Low Storage, Maintenance, Notification, Read Replica, Recovery, and Restoration. Event categories for a DB snapshot source type include: Creation, Deletion, and Restoration. Event categories for a DB security group source type include: Configuration Change and Failure. The event category for a DB parameter group source type is Configuration Change. The following table shows the event category and a list of events when a DB instance is the source type.

Retrieving Archived Redo Logs If you are using Oracle Database 11.2.0.2.v7 or later, you can retain archived redo logs and use log miner (DBMS_LOGMNR) to retrieve log information. For example, the following command retains redo logs for 24 hours: exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);                                              Because these logs are retained on your DB instance, you need to ensure that you have enough storage available on your instance to accommodate the log files. To see how much space you have used in the last "X" hours, use the following query, replacing "X" with the number of hours. select sum(blocks * block_size) bytes from v$archived_log where next_time>=sysdate-X/24 and dest_id=1;                                                Once you have retained the redo logs, you can use log miner as described in the Oracle documentation . Previous Methods for Accessing Alert Logs

Monitoring Database activity from transaction log is not possible in AWS RDS instances  Installation of database activity monitoring software on Amazon RDS instances is not possible because users don’t have access to underlying EC2 instances.  Database Activity Monitoring consists of auditing, analyzing and monitoring database access and activities to prevent unauthorized access or loss of data integrity.  Database activity monitoring is independent of the actual database and doesn’t rely on the database for auditing or logs. 

You can access following  SQL Server error logs,  Agent logs, and  Trace files by using the Amazon RDS console or APIs.  Log files are rotated each day and when a database reboot occurs; a maximum of seven files are retained for each error log, agent log, and trace file. Log files are deleted after seven days. We can not monitor Transaction Logs as it requires file system level access. Which AWS RDS will not provide.