RDS cluster snapshots are snapshots created from Amazon RDS Aurora clusters. RDS snapshots created from MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server instances are different. Those are considered “DB snapshots” and are handled differently.
Aurora cluster snapshots are created from an Aurora cluster. All Aurora instances share the same underlying cluster data. So when you create a snapshot for Aurora, you are creating it from the cluster, not the instances.
The Aurora cluster snapshots can be copied for longer data retention beyond the standard RDS cluster snapshot lifetime, which maxes-out at 35 days. Also, the automated RDS snapshots are deleted when the RDS cluster is deleted. So if you need to preserve your data after the cluster is deleted, then you’ll need to make a copy of it yourself.
In this example, we’ll copy our RDS Aurora snapshot within the same region.
RDS DB snapshots are snapshots created from Amazon RDS DB instances. Those being MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server. Amazon Aurora also has snapshots, however, those are considered “cluster snapshots” and are handled differently.
The DB snapshots can be copied for longer data retention beyond the standard RDS instance snapshot lifetime, which maxes-out at 35 days. Also, the automated RDS snapshots are deleted when the RDS instance is deleted. So if you need to preserve your data after the instance is deleted, then you’ll need to make a copy of it yourself.
In this example, we’ll copy our RDS DB snapshot within the same region.
As companies, big or small, move into the cloud, it’s becoming more and more important to ensure that data is protected. There are numerous options for data resilience, including (but not limited to), Amazon EBS and Amazon S3. What you choose to use depends on your business requirements.
Amazon EBS volumes are supposed to be redundant within an availability zone, however they have been known to fail, both due to technical issues, and by human error.
When storing important data in your EC2 instances, a sound backup strategy is vital.
AWS provides an EBS-native backup option in the form of EBS snapshots. AMI images take that one step further in that an AMI image includes EBS snapshots for each attached EBS volume in addition to metadata about the EC2 instance itself. With an AMI image, you can replace a “broken” EC2 instance very quickly.
So, if your EC2 instances contain data that cannot be lost, creating daily AMI images can be key to ensuring your business stays in business.
Most likely you have heard about Spectre and Meltdown by now. It’s all over the news. As an IT or DevOps engineer, it’s now your job to patch your EC2 instance operating systems.
This task can be “fun” if you need to SSH/RDP into every EC2 instance and apply patches. Or, it can be truly fun if you decide to use AWS Systems Manager to apply patches to your OS.
Modern cloud-based data services have revolutionized the way companies manage their data. Tools such as Amazon Athena and Amazon Redshift have changed data warehouse technology, catering for a move towards interactive, real-time, analytical solutions.
Both Amazon Athena and Redshift offer their own unique benefits and use cases. Athena provides a cheaper and more portable way to query data while Redshift offers unrivalled performance and scalability.
The following article provides a brief comparison of the Amazon Athena and Redshift data services. By understanding the main uses of each and comparing them under key headings, you can come to a more informed decision in choosing the right tools for your company’s data needs.
Amazon EBS snapshots are an AWS-native backup mechanism for your EBS volumes.
If you are coming from a traditional backup history, they can be considered a mix of full and incremental backups:
However, unlike traditional backups, if you delete the first EBS snapshot (the “full one”), the rest of the EBS snapshots are still fully recoverable. It is 100% safe to delete any EBS snapshot; all remaining EBS snapshots are fully recoverable.
EBS snapshots are an important tool in any disaster recovery strategy. For many, creating daily EBS snapshots, automatically, is an important event.
Since EBS snapshots are incremental, pre-calculating the cost of EBS snapshots is difficult. The reason is that there are many factors that can affect the actual cost of an EBS snapshot:
We have created an EBS Snapshot Pricing Calculator to help estimate the cost of creating daily EBS snapshots.
At AWS re:Invent, Amazon announced support for DynamoDB backup and restore. We’ve previously discussed the current restrictions and limits with DynamoDB backups.
We’re happy to announce that we’ve added support for scheduling of creating and deleting DynamoDB backups. Today, we are adding two new actions:
Last week at AWS re:Invent, Amazon announced support for DynamoDB backup and restore. We’re already finishing the final touches on our support for creating DynamoDB backups.
During development, we came across some caveats about the new DynamoDB backup feature that we’d like to share. Here are our observations.
This week is AWS re:Invent 2017. For the 6th time, it’s bigger than ever, spanning 5 hotels: The Venetian, The Mirage, Encore, Aria, and MGM Grand. So plan your transitions well, make sure you have some good walking shoes, and take the AWS shuttles between hotels.
Like previous years, you’ll notice different coloured lanyards holding everyone’s badges. Here’s an updated list.
Amazon DynamoDB is a flexible NoSQL database solution. It provides a serverless database for non-relational data.
Unlike Amazon RDS, there is no built-in way to backup or export the data stored in a DynamoDB table. There are many reasons you may want to export your DynamoDB table items to S3:
Amazon has provided a solution using AWS Data Pipeline to export DynamoDB items to S3, but that requires using additional AWS services and cannot be applied to multiple tables across multiple regions easily.
Today, we’re happy to announce the addition of a new action to Skeddly: Export DynamoDB Tables.