InvalidGroup.NotFound - Security Group Not Found (InvalidGroup.NotFound)
Amazon EC2 returns `InvalidGroup.NotFound` when the referenced security group ID or name cannot be found in the target VPC scope.
Last reviewed: May 5, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Security Group Not Found (InvalidGroup.NotFound) Mean?
EC2 could not resolve one or more security group references in current VPC/account/region scope, so launches and network mutations fail until valid SG IDs are supplied.
Common Causes
- -Security group ID/name is incorrect, stale, or references another VPC/account.
- -Group was deleted/replaced and launch templates still point to old identifier.
- -A recently created security group has not fully propagated across EC2 control-plane reads yet.
- -Request runs in wrong region where group ID does not exist.
- -Automation uses group name where group ID is required in VPC-scoped APIs.
How to Fix Security Group Not Found (InvalidGroup.NotFound)
- 1Resolve security group IDs from current VPC inventory in target region.
- 2Verify caller account and VPC context match expected security group ownership.
- 3Update launch templates/ASGs with active SG IDs instead of stale names/IDs.
- 4If the group was just created, wait briefly and retry after propagation checks complete.
- 5Re-run operation only after SG existence and VPC scope checks pass.
Step-by-Step Diagnosis for Security Group Not Found (InvalidGroup.NotFound)
- 1Capture SG reference, VPC ID, account, region, and request ID from failure logs.
- 2Correlate SG create/delete/replace operations with failure window in CloudTrail.
- 3Diff launch/runtime SG references against
DescribeSecurityGroupsoutput. - 4Check API usage for group-name vs group-id requirements in VPC-scoped calls.
Security Group Scope and Existence Checks
- -Validate SG IDs exist in the same VPC/account/region as the target resource (example: SG from old VPC used after network migration).
- -Inspect cross-account role assumptions that may point to different SG inventory (example: deploy role resolves to shared account without target SG).
Template Drift and Network Refactor Alignment
- -Audit launch templates for stale SG references after VPC refactors (example: template version still pins deleted SG ID).
- -Add pre-launch SG validation gates in CI/CD (example: block rollout when SG reference is missing from target VPC).
Decision Shortcut: Wrong VPC vs Deleted Group vs Name/ID Mismatch
- -If the group exists in another VPC, update the launch template or service config to the security group ID from the target VPC.
- -If CloudTrail shows the group was deleted or replaced, refresh network manifests before rerunning launches.
- -If the API uses VPC-scoped parameters, prefer security group IDs over names to avoid ambiguous or classic-EC2-era assumptions.
Wrong Fix to Avoid
- -Do not recreate a security group with a similar name without restoring the intended rules, tags, ownership, and launch references.
- -Do not add default security groups just to get instances launching; that can silently change network exposure.
- -Do not assume eventual consistency when the group was deleted or belongs to another VPC/account.
Implementation Examples
VPC_ID=vpc-0123456789abcdef0
REGION=us-east-1
aws ec2 describe-security-groups \
--region "$REGION" \
--filters Name=vpc-id,Values="$VPC_ID" \
--query 'SecurityGroups[].{id:GroupId,name:GroupName,vpc:VpcId}' \
--output tableaws ec2 describe-launch-template-versions \
--launch-template-name prod-web \
--versions '$Latest' \
--query 'LaunchTemplateVersions[].LaunchTemplateData.{sgIds:SecurityGroupIds,interfaces:NetworkInterfaces}'Incident Timeline
10:15 UTC
Network refactor publishes new security groups
Signal: IaC creates replacement security groups and may retire old IDs used by launch templates or autoscaling groups.
Why it matters: Launch artifacts must be republished atomically with network IDs, otherwise compute workflows keep stale references.
10:22 UTC
EC2 launch cannot resolve the referenced group
Signal: RunInstances, ASG scale-out, or ENI mutation returns InvalidGroup.NotFound with the stale security group ID or name.
Why it matters: The failing SG reference, VPC ID, account, and region define the diagnosis boundary.
10:30 UTC
Live VPC inventory differs from launch config
Signal: DescribeSecurityGroups shows current groups while the launch template still points to a removed or wrong-VPC group.
Why it matters: Repair the launch artifact or service config; IAM and retry tuning will not make a missing group resolvable.
10:45 UTC
Launch uses current manifest-backed SG IDs
Signal: The same scale-out or launch step succeeds after the security group reference is refreshed.
Why it matters: Keep SG manifests and preflight checks in CI to prevent stale network references after refactors.
Seen in Production
Network migration deletes legacy SGs while templates still reference them
Frequency: common
Example: Post-migration deployments fail because launch configs contain SG IDs from the retired VPC.
Fix: Regenerate SG mappings from current VPC inventory and republish launch configuration artifacts.
VPC replacement rotates security groups but launch config keeps old IDs
Frequency: rare
Example: Provisioning workflow references deleted SG IDs after network refactor.
Fix: Refresh SG mappings from live VPC inventory before launch operations.
Wrong Fix vs Better Fix
Default group fallback vs intended SG mapping
Wrong fix: Swap in the VPC default security group to unblock instance launches quickly.
Better fix: Resolve and apply the intended security group IDs from the environment network manifest.
Why this is better: The workload keeps the expected ingress/egress rules instead of inheriting broad or incorrect network access.
Manual console repair vs launch-template versioning
Wrong fix: Patch one autoscaling group in the console while launch templates and IaC still contain stale SG IDs.
Better fix: Publish a corrected launch template version and roll every dependent ASG or service to that version.
Why this is better: The fix survives the next deployment and applies consistently across scaling paths.
Debugging Tools
- -EC2 DescribeSecurityGroups
- -CloudTrail VPC/security-group events
- -Launch template network diff
- -VPC inventory reconciliation reports
How to Verify the Fix
- -Run
DescribeSecurityGroups --group-idsand confirm every referenced SG exists in the intended VPC. - -Replay the failing launch or network operation and verify InvalidGroup.NotFound is resolved.
- -Confirm deployment logs no longer include removed security-group identifiers.
How to Prevent Recurrence
- -Resolve SG IDs from live VPC inventories rather than hard-coded launch defaults.
- -Add CI checks enforcing SG-to-VPC/account alignment for every deployment target.
- -Coordinate VPC refactors with atomic launch-template SG updates.
Pro Tip
- -maintain environment-scoped SG manifests and require launch configs to reference manifest entries instead of raw hard-coded IDs.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.