AWS snapshots created without policy - amazon-web-services

in my AWS snapshots, I see, that there are snapshots created without policy, and I don't know, hot to disable them.
In my "Lifecycle Manager" I see only one policy, and it creates snapshot every day, and keep them for 2 weeks.
Those snapshots have description added "Created for policy: policy-0fd537dfc2b885c39 schedule: Daily".
And kept only for 2 weeks, then deleted automatically.
But there are also some snapshots without description, which aren't deleted and kept forever. Their creation date is about 11:45PM (East Europe time).
Snapshot list, with unknown snapshots in red border.
The only policy defined:
Are they created by some automatic volume backup, or how?
I didn't have any cron jobs on the server.
What can I do to disable them? Where to find their configuration?
I appreciate any help :)
Kind regards,
Wojtek

You can use AWS CloudTrail to look for the API events that created the Snapshots. A user identity (eg IAM Role or IAM User) will be associated with those events.
That should help you figure out how/what is creating those snapshots each night at 12:45am.

Related

I have a lot of AWS resources in the tag editor

I created my AWS account and got 12 months free plan. Then I went to the teg editor to check all my running services and there were 165 unnecessary running services. Maybe someone had the same problem? Is this ok and I don't have to pay for it?)
Screenshot
Just because they exist, does not mean they are running.
Those look like to be the default VPCs that are created by AWS in every region by default for every AWS account.
If you didn't create them, don't worry - you aren't being charged for them.
AWS does not provide any default resources that charge you money.

Where does AWS Lifecycle manager save the snapshot it takes as backup

I configured a set of Lifecycle manager Policies to back-up my EC2 instances last week, but I cannot find any relevant snapshots in the EBS snapshots section. Can someone please advise if I should look for the snapshots somewhere else, or if I should review any specific parameters that regard the policy, or if even I should use another method?
Thank you.
Schedule details
Lifecycle manager will create the backup as a regular EBS snapshot, EBS snapshots are stored in S3 however you do not have access to the snapshot other than through the console/API.
Based on your configuration it will only apply to a tag of Name with the value of Graylog v3.3.2. This will happen once a week at 12:30PM UTC on a Monday.
If the snapshots are not being generated check the following:
Do the target instances have this name and value assigned to them?
Does the execution IAM role have permissions to perform this action? If it has the default permissions then it will be fine to run.
Thank you for the answer and apologies for this issue I'm kind of new to AWS and I managed to solve it.
The issue was simply in the filter applied to the snapshots tab I wasn't seeing the full name. bottom line the policy was working fine after all.

AWS RDS disaster recovery using cross-account

We are running AWS RDS PostgreSQL, with daily automatic snapshots, encrypted by AWS managed KMS key. My objective is to minimize risks and data loss, in case when main AWS account (running RDS) got compromised or RDS deleted/damaged in some way.
What we've implemented so far: RDS snapshots are shared with different (backup) account, periodically copied to backup account and re-encrypted with the KMS key from the backup account, to make copies local, and independent from the main AWS account.
I'm wondering if there are better ways to minimize recovery time objective and recovery point objective in case of a disaster event?
This AWS blog post seems to weigh the options well.
Automated backups are limited to a single AWS Region while manual snapshots and Read Replicas are supported across multiple Regions.
Having cross region Read replica would give you the best RPO and RTO as you can promote replica to be an independent instance which should improve your RPO / RTO
Alternatively, if you choose to use Amazon Aurora Backtrack it seems to offer a similar option to having a read replica but I do not have a personal experience with this feature so can't say how effective it is in improving RTO and RPO.
I wrote two scripts implementing flow at the diagram drawn above ^^^, the idea is to run them daily:
src_acc_take_share_rds_snapshot.py in src account:
list available RDS snapshots according to provided regexp
recrypt them with KMS key, shared from dst account
share recrypted RDS snapshots with the dst account
remove old decrypted snapshots
dst_acc_copy_shared_rds_snapshot_to_local.py in dst account
list RDS snapshots, shared in src account with dst account
copy RDS snapshots from src account to dst account
remove old decrypted snapshots
fire an SNS message if desired snapshot count != actual
and put them at GitHub https://github.com/mvasilenko/dr-rds-share-snapshot

Regarding Retrieve AWS EC2 Instance as a snapshot

We had an instance where MongoDB hosted. now MongoDB someone deleted data by mistaken and we don't have any snapshots policy to retrieve backup for that account...
In this case, Can AWS provide backup as a snapshot from their data center backup mechanism??
Please let me know as its very important for us to work out this.
Unfortunately if you do not see an EBS snapshot in the account, then it does not exist. AWS does not keep extra backups of snapshots separate from it's customer accounts.
Under the AWS Shared Responsibility Model, customer data, including backups of that data, are the sole responsibility of the customer.
See https://aws.amazon.com/compliance/shared-responsibility-model/

How to find how Amazon AMI created date

Is there a way to find out Amazon EC2 AMI creation date/time from AWS Console or command line?
Note: I am not looking for instance creation, rather when was a particular AMI created?
Querying the creation date of an AMI has been a requested feature since 2006.
Back when I was creating community AMIs in 2007-2009 I started a trend of including the creation date in the AMI name/description (e.g., 20121210). This practice has been picked up by a number of popular AMI series, so you may want to check out the name and description of the AMI for a date looking string.
From AWS's 'What's New' :
AMI Creation Date is now available on the AWS Management Console. You can find this attribute by going to the EC2 console and choosing AMIs on the left navigation menu. You should see a new column on the AMIs page called "Creation Date"
You can also see this 'CreationDate' attribute with AWS EC2 CLI using:
ec2 describe-images --image-ids ami-a3e0thy0
Two alternatives:
1) You can view info about the associated snapshot from the EC2 snapshot panel, specifically the "Started" field which will tell you the time the snapshot started. I think this is very close, and worked well for AMIs my coworkers and I created - not so well for private AMIs. Simply find the snapshot ID (snapshot-1234abcd) in the AMI view in the "Block devices" field, then look up that snapshot in the Snapshots view.
2) If you are in a region which offers AWS CloudTrail, you can probably find that info in the CloudTrail logs.
This is not currently possible. The ability to better track versions of AMIs is a often requested feature though. Expect AWS to be releasing some enhancements in this area relatively soon.
If you want to use the CLI, but only want the image ID and the creation date, you can run this:
aws ec2 describe-images --image-ids ami-XXXXXXXX --query 'Images[*].[ImageId,CreationDate]'