I have Enabled enhance monitoring for RDS instance using cloudformation template.
Now When i am trying to disable enhance monitoring its not working.
As per documentation i have set Monitoring Interval to 0 and same i have verified cloudformation latest parameters. But still enhance monitoring is not disabled.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html
Cloudformation is not throwing any error and its getting updated.
You can do it with CLI first to verify (and apply to your CloudFormation template afterwards).
To disable Enhanced Monitoring using the AWS CLI, set the --monitoring-interval option to 0 in the these commands.
For Linux, macOS, or Unix:
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--monitoring-interval 30 \
--monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
For Windows:
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--monitoring-interval 30 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
For further info, you can take a look at this documentation.
Related
I have been trying to stop multiple instances of RDS using a single command line but it does not seem to work.
Currently I can only make it work with one instance at a time with a command like this:
aws rds stop-db-instance --db-instance-identifier test-instance1 --region ap-southeast-1 --profile dev
However I would like to stop multiple RDS and this does not seem to work:
aws rds stop-db-instance --db-instance-identifier test-instance1 test-instance2 testinstance3 --region ap-southeast-1 --profile dev
Any idea or suggestion on how I can make this work?
If it is not possible I will probably create a CRON job instead using Lambda.
Sadly you can't do this. But you can write a simple bash for loop:
ids=(test-instance1 test-instance2 test-instance3)
for id in ${ids[#]};
do
echo "Stopping: ${id}"
aws rds stop-db-instance --db-instance-identifier ${id} --region ap-southeast-1 --profile dev
done
If writing a shell script that calls aws rds stop-db-instance multiple times, once per RDS instance, is problematic for you somehow, then consider doing this via a scheduled Lambda (think of it like crontab).
See Schedule Amazon RDS stop and start using AWS Lambda, which:
presents a solution using AWS Lambda and Amazon EventBridge that allows you to schedule a Lambda function to stop and start the idle databases with specific tags to save on compute costs.
I recently enabled flow logs for global accelerator to troubleshoot an issue. below is the AWS CLI command i ran to enable flowlogs for global accelerator as per aws article.
aws globalaccelerator update-accelerator-attributes
--accelerator-arn arn:aws:globalaccelerator::012345678901:accelerator/1234abcd-abcd-1234-abcd-1234abcdefgh
--region us-west-2
--flow-logs-enabled
--flow-logs-s3-bucket s3-bucket-name
--flow-logs-s3-prefix s3-bucket-prefix
My S3 bucket is getting huge with the GA flow logs and I no longer need these logs, I would like to disable the flow logs for global accelerator and I don't find a working aws cli command to disable the flow logs for global accelerator. --flow-logs-disabled doesnt exist.
The option you are looking for is:
--no-flow-logs-enabled
So your commandline would become:
aws globalaccelerator update-accelerator-attributes
--accelerator-arn arn:aws:globalaccelerator::012345678901:accelerator/1234abcd-abcd-1234-abcd-1234abcdefgh
--region us-west-2
--no-flow-logs-enabled
See the documentation for details: https://docs.aws.amazon.com/cli/latest/reference/globalaccelerator/update-accelerator-attributes.html
I wanted to add validation to my script before starting the Pod build in AWS.
One of the validation step is to check the # of VPCs in the asked region and the max limit set on the account.
I didn't find any CLI or SDK API to get it.
However there are similar APIs, example to get the max elastic IP per VPC, I can query:
aws ec2 describe-account-attributes
And look for "AttributeName": "default-vpc"
There is a brand new service which is able to do what you want: AWS Service Quotas.
It is currently available in most of the regions.
You can query the VPC service limit using the GetServiceQuota action.
The quota code for the quota VPCs per Region is L-F678F1CE (ARN: arn:aws:servicequotas:<REGION>::vpc/L-F678F1CE).
The service code for the service Amazon Virtual Private Cloud (Amazon VPC) is vpc.
Documentation: https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html
GetServiceQuota-Command Documentation for the CLI: https://docs.aws.amazon.com/cli/latest/reference/service-quotas/get-service-quota.html
You can use the latest version of the aws cli as follows:
aws service-quotas get-service-quota --service-code 'vpc' --quota-code 'L-F678F1CE'
On Windows cli:
aws service-quotas get-service-quota --service-code vpc --quota-code L-F678F1CE
As long as Trusted Advisor access to the Service Limits category remains free, you can do this:
CHECK_ID=$(aws --region us-east-1 support describe-trusted-advisor-checks --language en --query 'checks[?name==Service Limits].{id:id}[0].id' --output text)
aws support describe-trusted-advisor-check-result --check-id $CHECK_ID --query 'result.sort_by(flaggedResources[?status!="ok"],&metadata[2])[].metadata' --output table --region us-east-1
CHECK_ID is currently eW7HH0l7J9
I am creating the RDS via AWS CLI using
create-db-instance
RDS is getting created but I want to wait until the RDS comes to "available" state so that I can execute the remaining part of the script. I am not sure how can I achieve that.
Use the waiters as provided by the AWS SDK in its CLI. Specifically, you want to wait until RDS DB instance becomes available. Look at db-instance-available.
aws rds wait \
db-instance-available \
--db-instance-identifier "your-rds-instnace-id"
Never tried this. But the following CLI is what you need:
aws rds wait db-instance-available --db-instance-identifier <value>
Wait until JMESPath query DBInstances[].DBInstanceStatus returns
available for all elements when polling with describe-db-instances. It
will poll every 30 seconds until a successful state has been reached.
This will exit with a return code of 255 after 60 failed checks.
These days, you should use the AWS Command-Line Interface (CLI) to call AWS.
The command would be:
aws rds create-db-instance ...
Then, you could call a waiter:
aws rds wait db-instance-available ...
See:
create-db-instance
db-instance-available
It's pretty easy via the console but I need to do the same from CLI.
First I created a db snapshot:
aws rds create-db-cluster-snapshot \
--db-cluster-snapshot-identifier $SNAPSHOT_ID \
--db-cluster-identifier $CLUSTER \
CLUSTER contains only one writer instance
I did not use create-db-snapshot method because it throwned an error
A client error (InvalidParameterValue) occurred when calling the CreateDBSnapshot operation: The specified instance is a member of a cluster and a snapshot cannot be created directly. Please use the CreateDBClusterSnapshot API instead.
It works:
aws rds create-db-cluster-snapshot \
--db-cluster-snapshot-identifier $SNAPSHOT_ID \
--db-cluster-identifier $CLUSTER \
{
"DBClusterSnapshot": {
"Engine": "aurora",
"SnapshotCreateTime": "2016-12-08T11:48:07.534Z",
....
}
So, I wanted to restore a new Aurora cluster from the snapshot, then I tried:
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier from-snap2 \
--db-snapshot-identifier snap2 \
A client error (DBSnapshotNotFound) occurred when calling the RestoreDBInstanceFromDBSnapshot operation: DBSnapshot not found: snap2
So I tried to restore with:
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier from-snap2 \
--snapshot-identifier snap2 \
--engine aurora \
--vpc-security-group-ids $PREPROD_SG \
--db-subnet-group-name my-db-subnet-group \
It works...
{
"DBCluster": {
...
"EngineVersion": "5.6.10a",
"DBClusterIdentifier": "from-snap2",
...
"DBClusterMembers": [],
...
}
But why the cluster does not contain any Aurora instance?
Where is the mistake?
This is very counterintuitive. If you restore a cluster from a snapshot, but there are no member instances in the cluster, what operation has actually succeeded? It seems as if all this does is create some kind of logical entity, maybe the backing store, but no instances.
Strange. But, the API documentation does show the cluster members as an empty set in the example response.
<DBClusterMembers/>
So it seems you create a cluster, as you did, then you apparently create instances in the cluster, as explained in an AWS Forum post:
aws rds create-db-instance --db-instance-identifier my-instance --db-instance-class db.r3.large --engine aurora --db-subnet-group-name default-vpc-xxxxxx --db-cluster-identifier my-instance-cluster
https://forums.aws.amazon.com/thread.jspa?messageID=688727
Apparently the console encapsulates multiple API requests behind the same action.
Response from AWS Support:
This is a known issue when using the API calls and our engineers are working on it. Even if the cluster is visible on AWS Console after the creation via CLI it will not create any instance automatically in your Aurora Cluster. In this case, you will need to create a db-instance and associate it to your newly restored cluster. When performing this Action on the AWS Console a new instance is automatically created for the cluster, but the action from the CLI uses separated API calls.
The following documentation provides detailed information on how to create a DB instance:
http://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html
You can describe your clusters using the AWS Console or using the CLI:
http://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html
Here is a command line example that creates the instance and associate it to a fictional cluster:
aws rds create-db-instance --engine aurora --db-cluster-identifier yourauroraclusteridentifier --db-instance-class db.t2.medium --db-instance-identifier yourinstanceidentifier
In my case, --db-cluster-identifier is the cluster created from the cluster snapshot.
If you create with aws rds create-db-cluster-snapshot then you can't restore with aws rds restore-db-instance-from-db-snapshot. The first creates a DB snapshot and the second restores a Cluster snapshot, different types.
From your question it looks like your restore is correct, maybe you need --database-name specified. Also you could try the restore with only the required parameters, i.e no vpc sg or DB subnet.