Core Actions
Relevant source files
The following files were used as context for generating this wiki page:
Core Actions represent the operations Cloud Custodian executes on cloud resources that match a policy's filters. They define the remediation, notification, or management steps applied to cloud infrastructure. Every policy consists of a resource type, optional filters, a execution mode, and a set of actions.
Actions execute against resource sets provided by the resource manager. Common actions include tagging, deletion, and state modification, while specialized actions like webhooks or notifications facilitate external integrations.
Sources: README.md:95-99, c7n/commands.py:236-258
Action Architecture and Registration
Actions are implemented as Python classes that inherit from a base Action or BaseAction class. These classes are registered within a resource-specific action_registry, allowing policies to reference them by a simple type string in YAML configurations.
Action Components
The documentation generator identifies action components through the following attributes:
- Type: The identifier used in policy YAML (e.g.,
tag,delete). - Permissions: The IAM or cloud provider permissions required to execute the action.
- Schema: A JSON schema used to validate action parameters in policy files.
Sources: tools/c7n_sphinxext/c7n_sphinxext/docgen.py:16-118, c7n/resources/airflow.py:46-50
Execution Logic
The Policy execution engine processes actions sequentially for all resources that pass through the filter chain.
This diagram illustrates the flow where actions are only triggered if resources successfully pass all defined filters.
Sources: c7n/commands.py:236-258, README.md:143-156
Standard Resource Actions
Most cloud resources support a common set of actions for lifecycle management and compliance enforcement.
Tagging Actions
Tagging actions manage metadata on resources. They are critical for cost allocation, ownership tracking, and automated governance.
| Action Type | Description | Key Parameters |
|---|---|---|
tag | Creates or updates tags on the resource. | key, value |
remove-tag | Removes specific tags from the resource. | tags (list) |
mark-for-op | Tags a resource to be acted upon after a delay (e.g., stop in 4 days). | op, days |
Sources: c7n/resources/airflow.py:53-100, c7n/resources/appflow.py:32-68, README.md:135-141
Lifecycle and State Actions
These actions modify the operational state of a resource, typically for cost optimization or security remediation.
- Delete: Permanently removes the resource from the cloud provider.
- Update: Modifies resource-specific configurations, such as access modes or encryption settings.
Sources: c7n/resources/airflow.py:108-150, c7n/resources/appflow.py:76-108
Implementation Examples
Resource-Specific Action Implementation
The following example shows how a delete action is implemented for an AWS AppFlow resource, including permission requirements and parameter handling.
@AppFlow.action_registry.register('delete')
class DeleteAppFlowResource(BaseAction):
permissions = ('appflow:DeleteFlow',)
schema = type_schema('delete', force={'type': 'boolean'})
def process(self, resources):
client = local_session(self.manager.session_factory).client('appflow')
force_delete = self.data.get('force', False)
for r in resources:
client.delete_flow(flowName=r['flowName'], forceDelete=force_delete)
Sources: c7n/resources/appflow.py:76-108
Tagging Implementation
Resources like Apache Airflow implement tagging by mapping YAML input to the specific cloud provider API calls.
@ApacheAirflow.action_registry.register('tag')
class TagApacheAirflow(Tag):
permissions = ('airflow:TagResource',)
def process_resource_set(self, client, airflow, new_tags):
for r in airflow:
client.tag_resource(
ResourceArn=r['Arn'],
Tags={t['Key']: t['Value'] for t in new_tags})
Sources: c7n/resources/airflow.py:53-76
Action Execution and Error Handling
When a policy runs, the custodian run command iterates through the matched policies. Each policy invokes its actions against the filtered resource list.
- Initialization: The provider initializes the policy and its actions, ensuring credentials and session factories are available.
- Processing: The
process()method of the action is called. For many resource actions, this involves batching resources to minimize API calls. - Error Handling: If an action fails, Cloud Custodian logs the exception and continues with the next policy unless the
--debugflag is active.
Sources: c7n/commands.py:236-258, c7n/resources/airflow.py:133-150
Infrastructure as Code (IaC) Actions
In "Shift Left" scenarios (e.g., using c7n-left), actions typically do not modify live resources. Instead, the engine evaluates policies against source assets (Terraform files) and results in compliance findings rather than direct cloud mutations. In these contexts, the "action" is the reporting of a failure or warning to the developer or CI/CD pipeline.
Sources: tools/c7n_left/README.md:1-25, tools/c7n_left/c7n_left/output.py:270-285
Summary of Action Functionality
Core Actions provide the mechanism for Cloud Custodian to interact with cloud environments. By abstracting cloud-specific API calls into reusable classes, the system allows users to define complex remediation logic in simple YAML. Whether performing a simple tag update or a complex environment deletion, actions ensure that policy matches result in tangible infrastructure changes.
Sources: README.md:1-50, c7n/commands.py:130-150