How do I execute a policy on creation, in addition to the criteria of the mode parameter?

Goal: I have an AWS account with a large number of ‘lost and forgotten’ resources which are accruing unnecessary costs. I’m looking to deploy a policy that will enforce some configuration options to better monitor our resources. Ideally, we can deploy a policy that will:

1. Evaluate the compliance status of all existing resources
2. Evaluate the compliance status of all new/modified resources

Step 2 is handled by the example policy below with the config-rule mode. But I’m unsure how to achieve step 1.

policies:
  - name: my-first-policy
    mode:
        type: config-rule
        role: arn:aws:iam::123456789012:role/some-role
    resource: ec2
    filters:
      - "tag:Custodian": present
    actions:
      - stop

AWS config rules have an action option to re-evaluate, which will evaluate all existing resources (of the specified type). Is there a way to have new policies do an initial full evaluation upon deployment, and then run in accordance to the specified mode?

[kapilt]

generally speaking provisioning or updating a config rule through any provisioning mechanism doesn’t trigger whole extant set evaluation, thats an after deploy manual step that can be achieved through the api or console. ie using custodian here is no different then using terraform or cloudformation, etc for a config-rule provisioning. ie you can do it, but then you have to do the work as a post deployment step. ie per your example c7n-org commands.

what i’m trying to raise re simple answer is that the particular issue your raising is specific to aws config rule mode, if you use a default poll mode on your policy, you’ll have whole fleet evaluation of a resource type during execution. so its partly a question of start with the why… why is using config important? but perhaps thats not material if you’ve got a work around re using config.

[Richard-Hansen]

the simple answer is not using mode: config-rule 😉 this isn’t an issue in our default modes… either using describe apis, or using config as a data source like source: config which avoids the issues of having to trigger config to re-evaluate. ie. this issue is in party by using a mode not appropriate to use case.

wrt to config rule mode, the issue with re-evaluate option is that its hard to know when to do it, atm we can re-upload/change on policy change or code change, but thats technically to the underlying lambda, not the event source, we either should do it by default or not at all afaics / ala document user responsibility. ie. the problem with adding an option on config-rule mode here is how a user supposed to know if they need to do it, and in which circumstances.

@kapilt I’m not sure I understand the alternatives you’ve presented. I’m working off the list of modes from https://cloudcustodian.io/docs/aws/aws-modes.html. Are you suggesting to trigger config off of specific API calls (such as using mode: cloudtrail?

If you’d be able to point me to the relevant documentation, that’d be fantastic.