0

We have a couple huge AWS accounts and I've been tasked with implementing guidelines for monitoring resources and ensuring that monitoring is set up for all existing and future resources.

Is there any way to prevent resource creation/modification by invoking rules based on resource options and/or custom conditions? For example, don't allow an RDS instance to be created unless it has enhanced monitoring enabled, or don't allow any EC2 instance to be created without some specific CloudWatch alarms.

I have looked into Policies / Guardrails but it doesn't seem to be robust enough. What are other people using in this scenario?

EDIT I have been looking at AWS Config as a potential solution but there seems to be a lot of limitations there. For example, I have the ability to audit RDS clusters to see if they have alarms created for certain metrics, but I cannot do the same for RDS instances.

blizz
  • 1,134
  • 1
  • 26
  • 47
  • Your question is a little vague. What do you want to monitor? CPU / memory usage, system failures, or something else? When you say "secure resource creation", do you mean "prevent resource creation" or something else? I've done a lot of this and can give you some advice, but need to know more about the problem and what you're trying to achieve. Please edit your question rather than putting information in comments. – Tim Jan 14 '20 at 18:57
  • Hi @Tim thanks for your comments....I edited the description to make it a little more clear. Let me know if you still have a question. – blizz Jan 15 '20 at 13:09
  • Have you looked into cloud custodian? it is pretty similar as AWS config, but it has even more actions, filters and supports more AWS resources – Diego Velez Jan 15 '20 at 16:48

1 Answers1

0

Prevent Resource Creation with SCP

In some cases you can use Service Control Policies for this type of requirement, but only relating to properties of the resource being created - AFAIK it won't work to say "you can't create an EC2 instance if a CloudWatch alarm hasn't been created".

AWS has some example Service Control Policies on this page, I'll copy one below. I've used this technique to do things like prevent EC2 instance creation if it isn't encrypted, if the EBS volume isn't encrypted, and prevent RDS creation if the storage isn't encrypted.

Example SCP from Amazon: With this SCP, any instance launches not using the t2.micro instance type are denied.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals":{                 
          "ec2:InstanceType":"t2.micro"
        }
      }
    }
  ]
}

Automatic Remediation

You could consider automatic remediation after resources are created. Something like AWS Config can get notified every time a resource is created, run a Lambda script, which you can then run custom code to detect state and set up related resources. Again, this is custom, but we've done this in the past. For example, when an S3 bucket is created we've turned on logging and versioning unless a specific tag was in place.

In the same way, you could delete resources that are non-compliant rather than automatically remedating.

Preventing Resource Creation with IAM Permissions

Instead of removing resources that aren't compliant you could look at reducing permissions for users so they can't directly create resources, and putting in place some kind of a self service system that sets up resources for them, with all required related resources set up. I haven't done this myself, so I can't say exactly how to do it.

This could be as simple as allowing CloudFormation templates you supply to run under a service role, but not allowing users permissions to create the resources directly.

Tim
  • 31,888
  • 7
  • 52
  • 78