Detecting Orphaned Resources Using AWS Config Rules

1. Introduction

Managing cloud environments efficiently involves more than just provisioning resources — it also requires ensuring that unused, unattached, or forgotten resources do not accumulate over time. In AWS, these so-called orphaned resources can quietly drive up costs, pose security risks, and increase operational complexity if left unchecked.

This blog explores how to identify and manage orphaned resources using AWS Config, a service designed to continuously assess, audit, and evaluate AWS resource configurations. We'll start by understanding what orphaned resources are, why they matter, and how AWS Config plays a critical role in detecting them. From there, we'll move step-by-step through configuring AWS Config, leveraging managed and custom rules, setting up automations, handling challenges, and learning from real-world examples.

By the end, you'll have a structured approach to monitor, detect, and remediate orphaned resources in any AWS environment, whether managing a single account or a large-scale multi-account organization.

1.1 What Are Orphaned Resources in AWS?

In AWS, orphaned resources refer to infrastructure components that are no longer attached, referenced, or actively used by any application, workload, or other resource. They remain provisioned in the account even though they serve no meaningful purpose.

Common examples include:

These resources can accumulate gradually due to:

• Application decommissioning without proper cleanup.
• Infrastructure migrations.
• Testing and temporary resource provisioning.

Orphaned resources are not always obvious because AWS environments can be dynamic and complex, particularly when multiple teams manage resources.

1.2 Why Detecting Orphaned Resources Matters

Leaving orphaned resources unattended can lead to multiple operational and financial issues:

Moreover, orphaned resources can cause confusion for new team members, cluttering dashboards, inventories, and reporting systems.

1.3 Overview of AWS Config

Source - AWS

AWS Config is a fully managed service that provides a detailed view of the configuration of AWS resources in your account. It enables:

• Resource Discovery: Catalogs all supported AWS resources and their relationships.
• Configuration History: Records the configuration of resources over time.
• Compliance Evaluation: Automatically assesses resources against compliance rules and best practices.
• Operational Visibility: Detects changes and unauthorized modifications to critical infrastructure components.

Main Components of AWS Config:

AWS Config can operate across multiple regions and accounts, making it effective for large-scale cloud environments where maintaining visibility is a challenge.

2. Understanding AWS Config Rules

2.1 What Are AWS Config Rules?

AWS Config Rules are evaluation checks that assess whether your AWS resources comply with defined standards. A rule represents a specific desired configuration or compliance condition.

Each rule has:

• A scope (which resources it applies to),
• Trigger type (periodic or configuration change),
• Evaluation logic (criteria to assess compliance).

For example, a rule might enforce that all EBS volumes must be attached to EC2 instances, or that IAM roles must rotate access keys within a specific timeframe.

Rules provide structured, repeatable checks that remove manual evaluation processes and support ongoing compliance.

2.2 Types of Config Rules: Managed vs Custom

AWS Config provides two categories of rules:

Comparison Overview:

Managed rules are suitable for standard security, operational, and compliance needs. Custom rules are essential when your organization’s resource management policies go beyond what AWS provides natively.

2.3 How Config Rules Work Behind the Scenes

Understanding the internal working of AWS Config Rules helps in setting up efficient compliance checks:

1. Resource Recording: The configuration recorder continuously monitors resources in the selected region and records their configurations.
2. Rule Triggering: Rules can be triggered:
   • Periodically (e.g., every 24 hours).
   • On Configuration Changes (when a resource is created, modified, or deleted).
3. Evaluation: Upon triggering, each rule executes its logic against the recorded configuration.
4. Compliance Determination: The rule reports the resource as compliant or non-compliant based on evaluation.
5. Result Storage: The compliance status and evaluation details are stored and can be queried or exported for reporting.

Optional remediation actions can be configured to automatically correct non-compliant resources using Systems Manager Automation documents or Lambda functions.

3. Detecting Orphaned Resources: Concepts and Approach

3.1 What Constitutes an Orphaned Resource in AWS?

An orphaned resource is defined by one or more of the following conditions:

• Unattached: No longer linked to any active resource (e.g., an EBS volume without an EC2 instance).
• Unreferenced: Not cited by any service dependencies or workloads (e.g., security groups not attached to network interfaces).
• Idle: Deployed but not currently handling any traffic or performing useful operations (e.g., load balancers with zero registered targets).

Importantly, not all idle resources are orphaned — for example, a load balancer waiting for auto-scaling activities might appear idle but is still needed. Hence, detection must be cautious and context-aware.

3.2 Key AWS Services Where Orphaned Resources Are Common

Certain AWS services are more prone to accumulating orphaned resources. The following table highlights common sources:

Regularly monitoring these services can prevent unnecessary costs and operational risks.

3.3 General Strategies for Orphan Detection Using Config

Several strategies can be employed when using AWS Config to detect orphaned resources:

Effective orphaned resource detection often requires combining static checks (Config rules) with dynamic behavior analysis (metrics, logs).

4. Setting Up AWS Config for Resource Monitoring

4.1 Enabling AWS Config in Your Account

AWS Config must be properly set up before you can monitor and detect orphaned resources.
The setup process involves a few essential steps:

1. Access AWS Config: Open the AWS Management Console, navigate to AWS Config, and select Set Up.
2. Configuration Recorder: Define the recorder to track changes in resource configurations automatically.
3. Select Resource Recording Options:
   • All Resources (recommended): Tracks all supported resource types for complete visibility.
   • Specific Resources Only: Useful when focusing on critical resource types to reduce costs.
4. Configure a Delivery Channel: Specify where Config will deliver configuration snapshots and compliance data (an S3 bucket and optionally an SNS topic).
5. Finalize and Activate: Review settings and enable the configuration recorder.

Important: AWS Config must be enabled region-by-region. If your infrastructure spans multiple AWS regions, you’ll need to configure Config separately in each or use AWS Config Aggregators for centralized management.

4.2 Selecting Resources to Record

Choosing which resources AWS Config records is crucial, especially when targeting orphan detection.

For orphan detection, you should prioritize recording:

• EC2 Instances and EBS Volumes
• Elastic IPs (EIP)
• Elastic Load Balancers (ELB/ALB)
• Network Interfaces (ENIs)
• Security Groups
• RDS Snapshots and Databases

Not recording certain resources might leave hidden orphans undetected.

4.3 Configuring Delivery Channels and Storage

A delivery channel in AWS Config defines how and where your configuration snapshots and compliance results are stored.

Steps to configure delivery and storage:

• Create an S3 Bucket: Assign proper access policies to allow AWS Config to write data securely.
• Optional SNS Topic: For critical resource changes, configure SNS topics to alert admins immediately.
• Data Retention Strategy: Plan how long you need to retain configuration history based on compliance or audit requirements.

Choosing the right storage setup ensures your data is available when needed without unnecessary costs.

5. Using Managed AWS Config Rules for Orphaned Resources

5.1 Relevant Managed Rules for Orphan Detection

AWS provides prebuilt ("managed") Config rules that help you quickly detect common types of orphaned resources without writing custom code.

These rules can help enforce basic cleanup practices automatically.

5.2 Configuring and Deploying Managed Rules

Deploying managed rules is straightforward:

1. Open AWS Config → Rules → Add Rule.
2. Search and Select Managed Rules: Example: Select ec2-volume-inuse-check.
3. Customize Parameters:
   • Some rules allow fine-tuning parameters (e.g., allowed states or tags).
4. Define Evaluation Triggers:
   • Configuration Changes (real-time)
   • Periodic Checks (every 24 hours or as configured)
5. Activate and Monitor Compliance:
   • AWS Config will continuously monitor the selected resources based on these rules.

Using managed rules allows quick wins, especially during initial setup phases.

5.3 Limitations of Managed Rules in Detecting Orphans

While helpful, managed rules have notable boundaries:

For environments with more complex needs, managed rules must be supplemented by custom Config rules.

6. Creating Custom Config Rules for Advanced Orphan Detection

6.1 When to Use Custom Rules

Custom Config rules become necessary when:

• No managed rule covers your orphaned resource scenario.
• You require complex, context-driven evaluation (like checking for last activity timestamps).
• Exceptions or special logic (e.g., ignore volumes with a Backup=true tag) are necessary.
• You want continuous tuning without waiting for AWS to release new managed rules.

Custom rules allow fine-grained control tailored to your environment.

6.2 Writing Custom Lambda Functions for Resource Validation

Custom Config rules rely on AWS Lambda functions to process evaluations dynamically.

Typical Lambda Function Workflow:

1. Receive Event: AWS Config triggers the Lambda with resource details.
2. Evaluate Resource: Check if it meets compliance (e.g., volume is unattached for more than 7 days).
3. Return Result: Return COMPLIANT or NON_COMPLIANT to AWS Config.

Simplified Lambda structure example:

Design your functions to be efficient and minimize runtime costs.

6.3 Permissions and IAM Roles Required

AWS Config rules and their backing Lambda functions need permissions to operate correctly.

Tip: Always apply the least privilege principle to avoid overexposing services.

6.4 Examples of Custom Rules for Orphaned EC2 Volumes, ENIs, and Snapshots

Writing clear, targeted custom rules can save significant costs and keep your environment tidy without manual cleanup.

7. Automating Remediation for Orphaned Resources

7.1 Introduction to Automatic Remediation with AWS Config

Detecting orphaned resources is only part of the solution. To keep your AWS environment clean and cost-effective, automating the remediation process is just as important.
AWS Config supports automatic remediation actions, allowing you to fix issues the moment they are detected without manual intervention. This approach reduces response time, minimizes human error, and improves overall operational efficiency.

7.2 Setting Up Remediation Actions

To set up automatic remediation:

• First, identify the Config rule you want to enforce, such as detecting unattached EBS volumes.
• Next, attach a remediation action, which is typically an AWS Systems Manager Automation document. AWS provides several ready-to-use documents like deleting a resource or stopping an instance.
• Specify the parameters the automation action needs, such as the resource ID.
• Define whether the action should execute automatically or wait for manual approval.
• Ensure the IAM role linked to the remediation has sufficient permissions to modify or delete the targeted resources.

By combining Config rules with Systems Manager, you create a continuous cycle of detection and correction.

7.3 Common Remediation Scenarios

Some common examples where automated remediation is effective include:

• Unattached EBS volumes: Automatically delete after a set grace period.
• Unused Elastic IPs: Release them to avoid ongoing charges.
• Detached ENIs: Remove unused network interfaces to tidy up VPC configurations.
• Orphaned snapshots: Review and delete snapshots that are no longer needed.

It’s important to exercise caution, especially when automating actions like snapshot deletions, to avoid accidental data loss.

8. Monitoring, Notifications, and Reporting

8.1 Integrating with Amazon SNS for Alerts

Monitoring the environment in real-time helps catch issues early.
AWS Config integrates with Amazon SNS to send notifications whenever a resource becomes non-compliant or when a remediation action succeeds or fails.
Setting this up involves:

• Creating an SNS topic.
• Subscribing endpoints like email addresses, Slack webhooks, or ticketing systems.
• Configuring AWS Config rules to publish compliance changes to the SNS topic.

This setup ensures that operational teams are promptly informed about violations and can act if necessary.

8.2 Dashboarding Orphaned Resource Violations

While notifications are helpful for immediate events, dashboards offer a broader view of system health over time.
AWS Config’s dashboard allows you to see:

• The number of non-compliant resources.
• The trend of compliance over weeks or months.
• Specific details about which rules are violated most often.

You can also integrate AWS Config data with AWS CloudWatch or external monitoring platforms to build custom dashboards for deeper insights.

Dashboards make it easier to spot recurring issues and prioritize efforts where they matter most.

8.3 Scheduled Compliance Reports and Metrics

For longer-term tracking and audits, scheduled reports are essential.
AWS Config enables:

• Automatic compliance reports sent to S3 buckets.
• Aggregation of compliance status across multiple accounts and regions.
• Exporting data to analytics tools for more detailed investigation.

Setting up scheduled reports ensures that compliance records are preserved for audits and allows teams to identify trends that may not be obvious from day-to-day monitoring.

9. Best Practices for Detecting and Handling Orphaned Resources

9.1 Designing Effective Resource Recording Strategies

Accurate orphan detection begins with careful configuration of what AWS Config records.
Some best practices include:

• Enable broad recording initially to capture all resources unless there is a strong reason to limit it.
• Review and update recorded resource types periodically as your AWS environment evolves.
• Focus recording efforts on high-cost or high-risk resources, such as storage volumes, IP addresses, and network interfaces, when necessary.

Having complete and up-to-date resource records ensures Config rules work as intended.

9.2 Balancing Detection Sensitivity vs Noise

Overly aggressive detection settings can create unnecessary alerts, leading to alert fatigue, while overly lax settings may miss important problems.
To find the right balance:

• Use resource tags to differentiate between production, development, and test resources.
• Apply grace periods before marking a resource as orphaned to avoid false positives for temporary detachment.
• Customize Config rules and remediation actions based on environment-specific needs.

The goal is to surface real problems while minimizing noise, allowing your teams to focus their efforts effectively.

9.3 Security and Cost Optimization Considerations

Detecting and handling orphaned resources ties directly into both security and financial optimization goals.

• From a cost perspective, orphaned resources like unattached EBS volumes or idle Elastic IPs contribute to unnecessary charges.
• From a security perspective, unused network interfaces or open security groups can introduce vulnerabilities if they are forgotten but still accessible.

A mature orphan detection and remediation process improves both your cloud security posture and your operational efficiency.
It should be a foundational part of any organization's cloud governance strategy.

10. Common Challenges and Troubleshooting

10.1 False Positives in Orphan Detection

False positives occur when resources are mistakenly flagged as orphaned, despite being actively in use.
Common causes of false positives in orphan detection include:

• Temporary detachment: EBS volumes might be detached during instance replacement but are still scheduled for re-attachment.
• Incorrectly tagged resources: If resources are tagged improperly, AWS Config might not identify them correctly as being in use.
• Untracked state changes: Resources might change states unexpectedly, like auto-scaling operations, leading them to appear unattached briefly.

How to Minimize False Positives

• Set Grace Periods: Before automatically triggering any action, add a grace period (e.g., 24 hours) to account for temporary detachment.
• Use AWS Lambda Functions for Validation: Incorporate custom Lambda functions that cross-check the status of flagged resources in real-time to ensure they're truly orphaned.
• Regularly Review Config Rules: As your environment changes, periodically review and adjust the thresholds for orphan detection to reflect operational nuances.

10.2 Scaling Config Rules in Multi-Account AWS Organizations

When managing AWS resources at scale across multiple accounts, especially in large organizations, scaling AWS Config can become challenging. Common challenges include:

• Rule Inconsistencies Across Accounts: Ensuring the same Config rules are applied consistently across multiple accounts.
• Cross-Region Monitoring: Config is region-specific by default, meaning you need extra configurations for monitoring resources across AWS regions.
• Permissions Management: Properly managing IAM roles and permissions to ensure all accounts can access the needed configuration data.

Best Practices for Scaling Config Rules

• Use AWS Organizations: With AWS Organizations, you can apply AWS Config rules across multiple accounts at once, maintaining consistency across your environment.
• Centralized Aggregation: Use AWS Config Aggregators to pull in data from all accounts and regions into a single dashboard for easier management and oversight.
• Automation Frameworks: Tools like AWS Control Tower and AWS CloudFormation StackSets can automate the deployment of Config rules across multiple accounts.

10.3 Dealing with Intermittent Resource States

AWS resources can sometimes be in an “intermittent” state — where they temporarily appear orphaned but are actually active. For example:

• Auto-Scaling Events: An EC2 instance might temporarily detach an EBS volume during scaling operations, creating an orphaned state, only to reattach it later.
• Elastic IPs (EIP): When you disassociate an EIP from an instance, it might be temporarily flagged as an orphan, though it’s still reserved for future use.

Strategies for Managing Intermittent States

• Use CloudWatch Events: Trigger event-based checks using CloudWatch to automatically flag resources as orphaned only if they’ve been in an unattached state for an extended period (e.g., 72 hours).
• Cross-validate with AWS Systems Manager: Systems Manager’s Inventory feature can cross-check the status of resources to ensure they are not truly orphaned before triggering any actions.
• Dynamic Thresholds: Implement dynamic thresholds for detecting orphans. For example, set a threshold that ignores short-term detachment but flags longer periods of inactivity.

11. Advanced Topics

11.1 Cross-Region Orphaned Resource Detection

AWS Config operates regionally, which can present challenges when trying to detect orphaned resources across multiple AWS regions.
Some common examples include:

• Unattached Volumes in one region might not be visible from another region.
• Cross-region compliance tracking might leave certain resources undetected if you don’t aggregate data properly.

Solution: Cross-Region Monitoring with AWS Config Aggregators

To ensure complete visibility, AWS Config Aggregators are essential for organizations with multi-region deployments. Here’s how you can set up an aggregator:

1. Create an Aggregator: From the AWS Config console, create an aggregator in a central account.
2. Choose Accounts and Regions: Specify which AWS accounts and regions to aggregate.
3. Aggregate Compliance Data: The aggregator will pull in data from all regions into a single view.

This enables you to centrally monitor orphaned resources across regions, making it easier to manage multi-region AWS environments.

11.2 Leveraging AWS Config Aggregators for Enterprise Monitoring

AWS Config Aggregators are ideal for monitoring compliance across a large-scale enterprise environment. By using an aggregator, you can:

• Consolidate Compliance Data: Aggregate compliance data from multiple accounts and regions into a single, consolidated dashboard.
• Ensure Comprehensive Coverage: Without aggregators, orphan detection might miss resources in regions or accounts you’ve overlooked.
• Streamline Reporting: With all data in one place, you can generate reports for internal audits or external regulatory compliance requirements. 

Setting Up an Aggregator

This example creates an aggregator that pulls configuration data from multiple AWS accounts and all AWS regions, ensuring comprehensive monitoring.

11.3 Integrating with AWS Security Hub and Trusted Advisor

AWS Config can be enhanced by integrating with AWS Security Hub and Trusted Advisor, providing a broader view of your cloud health.

• AWS Security Hub: Offers centralized security findings and can be used to detect unsecured or orphaned resources (e.g., untagged security groups or unused IAM roles).
• AWS Trusted Advisor: Helps with cost optimization by detecting unused resources like unattached EBS volumes or idle RDS instances.

By integrating these services, you can automate detection and remediation of orphaned resources, improving both security and cost efficiency.

12. Case Studies and Examples

12.1 Real-World Example: Orphaned Resource Cleanup in a Production Account

Consider an organization with a complex AWS environment consisting of several EC2 instances, EBS volumes, and Elastic IPs. Over time, the resources grew unmanaged, leading to significant operational costs.

Problem:

• Unattached EBS volumes were not deleted, leading to unnecessary storage costs.
• Elastic IPs were allocated but not in use, wasting resources.
• The environment had no centralized monitoring for orphaned resources.

Solution:

1. Deployed AWS Config with managed rules specifically designed for EBS volumes and Elastic IPs.
2. Set up SNS notifications to alert teams about potentially orphaned resources.
3. Implemented remediation actions using Systems Manager to delete orphaned volumes automatically after 14 days.

Result:

• Reduced monthly storage costs by 18%.
• Improved resource visibility and automated cleanup saved time and effort.

12.2 Lessons Learned from Large-Scale Implementations

From deploying AWS Config and automating orphaned resource detection in large-scale environments, several key lessons were learned:

• Gradual Rollout: Start with visibility before implementing remediation actions. It's essential to first validate orphan detection before automating deletions.
• Incorporate Stakeholder Feedback: Make sure application owners understand orphan detection policies to avoid accidental deletion of necessary resources.
• Tagging is Critical: A well-defined tagging strategy is necessary for AWS Config to detect resources accurately. Inconsistent tags can result in missed orphan detection.
• Automation Testing: Test remediation actions thoroughly in a staging environment to avoid unintended disruptions in production.

By applying these lessons, organizations can avoid common pitfalls and streamline the implementation of resource detection and management.

Note - Solutions like CloudOptimo’s CostSaver can assist by effectively identifying idle, unused, or misconfigured cloud resources, providing insights that help target these assets for optimization and improved performance.