Bedrock Model Customization Job Has Active Security Group

Using Console

Here’s how to remediate this using the AWS Console by locking down (or removing) the security group associated with the Bedrock model customization job.

1. Identify the Security Group Used by the Customization Job

Sign in to the AWS Management Console and go to Amazon Bedrock.
In the left navigation pane, choose Model customization (or Custom models → Customization jobs, depending on your console version).
Click the specific Customization job that triggered the finding.
In the Networking / VPC configuration section, note the Security group ID(s) associated with the job. Copy those IDs.

Important: You cannot change the VPC/security group on an already-running or completed customization job. You will secure the SG itself and adjust settings for future jobs.

2. Tighten the Security Group Rules

In the console, go to EC2.
In the left pane, choose Security Groups.
Search for the Security group ID you copied, then select it.

2.1 Restrict Inbound Rules

Go to the Inbound rules tab, then choose Edit inbound rules.
Remove any rules that:
- Allow inbound from 0.0.0.0/0 or ::/0 (especially for SSH, RDP, or any non-required port).
- Are broader than needed (e.g., wide CIDR like /0, /8, /16 when not required).
Only keep rules that are:
- Required for your job (for most Bedrock customization jobs, you often do not need broad inbound access at all).
- Restricted to specific internal CIDR ranges, VPCs, or security groups.
Choose Save rules.

2.2 Restrict Outbound Rules (if needed)

Go to the Outbound rules tab → Edit outbound rules.
Remove or narrow any 0.0.0.0/0 or ::/0 rules unless egress to the public internet is strictly required.
Prefer:
- VPC-only or specific CIDR ranges.
- Specific service endpoints (via VPC endpoints, if applicable).
Choose Save rules.

3. (Optional) Create a Locked-Down Security Group for Future Jobs

If the existing SG is used by multiple workloads, it’s cleaner to create a dedicated one for Bedrock:

In EC2 → Security Groups, choose Create security group.
Name it something like bedrock-customization-sg-restricted.
Attach it to the correct VPC.
Set:
- Inbound rules: None or only the minimal, tightly scoped rules required.
- Outbound rules: Restricted to what is necessary (VPC-only or specific CIDRs/endpoints).
Save the security group.

Then:

Go back to Amazon Bedrock → Model customization.
When you create the next customization job, in the Networking / VPC configuration step, choose this new restricted Security group instead of the older one.

4. (Optional) If You Intended to Delete the Security Group

If you’re getting errors deleting a security group because it is “in use” by a Bedrock customization job:

Confirm the customization job has fully completed or failed (not running).
Verify the SG isn’t referenced by:
- Other EC2 instances, ENIs, load balancers, Lambda functions, etc.
Once it’s no longer referenced:
- Go to EC2 → Security Groups, select the SG, and choose Delete security group.

If you tell me the exact security check/source of the finding (e.g., Security Hub / control ID), I can tailor the remediation more precisely to that control’s requirement.

Using CLI

Below are CLI-focused steps to remediate a Bedrock model customization job that uses an insecure/overly-permissive active security group.Assumptions:

You already know (or can identify) the Security Group ID(s) used in the Bedrock customization job’s VPC config.
The typical misconfiguration is that the SG allows broad access (e.g., 0.0.0.0/0 or ::/0) or unnecessary ports/protocols.

1. Identify the Security Group(s) Used

If you already know the Security Group ID (sg-xxxxxxxx), skip to step 2.If not, list security groups and filter by tag/name you used for Bedrock:

aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=*bedrock*" \
  --region <REGION>

Look for the GroupId fields like sg-0123456789abcdef0.

2. Review Current Inbound and Outbound Rules

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --region <REGION>

Inspect IpPermissions (inbound) and IpPermissionsEgress (outbound) for:

0.0.0.0/0 or ::/0
Unnecessary ports (e.g., all ports 0–65535, or IpProtocol: -1)

3. Remove Insecure Inbound Rules

Example: Remove all inbound rules:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://ingress.json

First generate ingress.json from current rules:

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query "SecurityGroups[0].IpPermissions" \
  --output json > ingress.json

Run revoke-security-group-ingress with that file to clear them.If you only want to remove broad rules (e.g., all traffic from 0.0.0.0/0):

Create a minimal JSON file, e.g. revoke-0-all.json:

[
  {
    "IpProtocol": "-1",
    "IpRanges": [
      {
        "CidrIp": "0.0.0.0/0"
      }
    ]
  }
]

Revoke just that:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://revoke-0-all.json \
  --region <REGION>

Repeat similarly for IPv6 (CidrIpv6: "::/0").

4. Restrict Outbound Rules (If Required)

If your policy requires restricted egress (not 0.0.0.0/0):

Export current egress:

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query "SecurityGroups[0].IpPermissionsEgress" \
  --output json > egress.json

Revoke overly broad egress, e.g.:

revoke-egress-0-all.json:

[
  {
    "IpProtocol": "-1",
    "IpRanges": [
      {
        "CidrIp": "0.0.0.0/0"
      }
    ]
  }
]

Command:

aws ec2 revoke-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://revoke-egress-0-all.json \
  --region <REGION>

5. Add Least-Privilege Rules Needed by Bedrock Job

Typically:

No inbound rules are required for many VPC workloads if they only initiate outbound connections.
Outbound rules should only allow required destinations (e.g., VPC endpoints, specific CIDR ranges or ports).

Example: allow outbound HTTPS only within your VPC CIDR:

aws ec2 authorize-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "IpRanges": [
        {
          "CidrIp": "10.0.0.0/16"
        }
      ]
    }
  ]' \
  --region <REGION>

If Bedrock customization uses VPC endpoints, scope egress to those endpoints’ private IP ranges or associated subnets.

6. (Optional) Create a New Hardened Security Group and Use It for Future Jobs

Instead of fixing an old SG, you can create a dedicated locked-down one:

aws ec2 create-security-group \
  --group-name bedrock-customization-sg \
  --description "SG for Bedrock model customization with restricted egress" \
  --vpc-id vpc-0123456789abcdef0 \
  --region <REGION>

Then configure:

No inbound rules (default).
Minimal egress as in step 5.

Use that SG’s ID in the vpcConfig.securityGroupIds when starting future Bedrock customization jobs.

7. (Optional) Delete Unused Security Groups

After confirming the SG is no longer attached to any ENIs and not referenced in other resources:

aws ec2 delete-security-group \
  --group-id sg-0123456789abcdef0 \
  --region <REGION>

If you share:

The current SG rules (JSON from describe-security-groups), and
Any Bedrock/VPC endpoint patterns you must support,

I can give exact CLI JSON payloads for your specific environment.

Using Python

For AWS Bedrock, the “Model Customization Job Has Active Security Group” finding usually means the security group associated with the job allows unnecessary inbound access (e.g., 0.0.0.0/0). You can’t update an existing Bedrock customization job, but you can remediate the underlying security group (for running jobs) and fix your configuration for all new jobs.Below are step‑by‑step instructions and Python (boto3) code to lock down the security group(s).

1. Identify the Security Group(s) used by the Bedrock customization job

If you know the security group ID(s) already, you can skip to step 2.Otherwise, when you create a customization job you pass a vpcConfig with security group IDs. For reference, a creation call looks like:

import boto3

client = boto3.client("bedrock")

response = client.create_model_customization_job(
    jobName="my-custom-job",
    # ...
    outputDataConfig={
        "s3Uri": "s3://my-bucket/output/"
    },
    roleArn="arn:aws:iam::123456789012:role/BedrockCustomizationRole",
    vpcConfig={
        "securityGroupIds": ["sg-0123456789abcdef0"],   # <- HERE
        "subnetIds": ["subnet-0123456789abcdef0"]
    },
    # ...
)

Use the security groups referenced there.

2. Remove overly permissive inbound rules from the security group

Typical misconfiguration: inbound rules like:

CIDR: 0.0.0.0/0 or ::/0
Protocol: tcp or -1 (all)
Ports: wide ranges or all

You want:

No inbound rules at all, or
Only strictly required internal access (e.g., from specific subnets or security groups).

Python: strip all inbound rules from the SG

import boto3

ec2 = boto3.client("ec2", region_name="us-east-1")  # set your region
security_group_id = "sg-0123456789abcdef0"          # your SG ID

def remove_all_ingress_rules(sg_id: str):
    # Get current ingress rules
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    ip_permissions = sg.get("IpPermissions", [])

    if not ip_permissions:
        print(f"No ingress rules to remove for {sg_id}")
        return

    # Revoke all ingress rules
    ec2.revoke_security_group_ingress(
        GroupId=sg_id,
        IpPermissions=ip_permissions
    )
    print(f"Removed all ingress rules from {sg_id}")

remove_all_ingress_rules(security_group_id)

If you only want to remove 0.0.0.0/0 or ::/0 rules and keep internal rules, filter them:

def remove_public_ingress_rules(sg_id: str):
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    to_remove = []

    for perm in sg.get("IpPermissions", []):
        ip4s = [ip for ip in perm.get("IpRanges", []) if ip.get("CidrIp") == "0.0.0.0/0"]
        ip6s = [ip for ip in perm.get("Ipv6Ranges", []) if ip.get("CidrIpv6") == "::/0"]
        if ip4s or ip6s:
            new_perm = {
                "IpProtocol": perm["IpProtocol"],
                "FromPort": perm.get("FromPort"),
                "ToPort": perm.get("ToPort"),
                "IpRanges": ip4s,
                "Ipv6Ranges": ip6s,
            }
            to_remove.append(new_perm)

    if not to_remove:
        print(f"No public ingress rules found for {sg_id}")
        return

    ec2.revoke_security_group_ingress(
        GroupId=sg_id,
        IpPermissions=to_remove
    )
    print(f"Removed public ingress rules from {sg_id}")

remove_public_ingress_rules(security_group_id)

3. Lock down outbound rules if required by your policy

Some security baselines also require outbound to be restricted (not 0.0.0.0/0 / all protocols).To remove all outbound rules:

def remove_all_egress_rules(sg_id: str):
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    ip_permissions_egress = sg.get("IpPermissionsEgress", [])

    if not ip_permissions_egress:
        print(f"No egress rules to remove for {sg_id}")
        return

    ec2.revoke_security_group_egress(
        GroupId=sg_id,
        IpPermissions=ip_permissions_egress
    )
    print(f"Removed all egress rules from {sg_id}")

remove_all_egress_rules(security_group_id)

If Bedrock customization needs outbound access (for example to S3 via a VPC endpoint), add only those explicit rules (e.g., to VPC endpoint security groups or CIDRs).

4. Use a hardened SG for all future Bedrock customization jobs

Create a dedicated, locked‑down SG once, and reuse it:

def create_locked_down_sg(vpc_id: str, name: str, description: str):
    resp = ec2.create_security_group(
        GroupName=name,
        Description=description,
        VpcId=vpc_id
    )
    sg_id = resp["GroupId"]
    print(f"Created SG {sg_id} in VPC {vpc_id}")

    # By default, SG has no ingress and one broad egress rule.
    # Optionally remove default egress:
    remove_all_egress_rules(sg_id)

    return sg_id

vpc_id = "vpc-0123456789abcdef0"
locked_sg_id = create_locked_down_sg(vpc_id, "bedrock-customization-sg", "SG for Bedrock Model Customization")

Then, when creating new customization jobs, always reference locked_sg_id:

client = boto3.client("bedrock", region_name="us-east-1")

client.create_model_customization_job(
    jobName="my-secure-custom-job",
    # ...
    vpcConfig={
        "securityGroupIds": [locked_sg_id],
        "subnetIds": ["subnet-0123456789abcdef0"]
    },
    # ...
)

If you share the exact policy/finding text (e.g., from Security Hub/Config), I can tailor the Python to match that control precisely (e.g., specific ports or CIDRs to remove).

AWS Introduction

AWS Pricing

AWS Threats

AWS Misconfigurations

Bedrock Model Customization Job Has Active Security Group

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Identify the Security Group Used by the Customization Job

2. Tighten the Security Group Rules

2.1 Restrict Inbound Rules

2.2 Restrict Outbound Rules (if needed)

3. (Optional) Create a Locked-Down Security Group for Future Jobs

4. (Optional) If You Intended to Delete the Security Group

1. Identify the Security Group(s) Used

2. Review Current Inbound and Outbound Rules

3. Remove Insecure Inbound Rules

4. Restrict Outbound Rules (If Required)

5. Add Least-Privilege Rules Needed by Bedrock Job

6. (Optional) Create a New Hardened Security Group and Use It for Future Jobs

7. (Optional) Delete Unused Security Groups

1. Identify the Security Group(s) used by the Bedrock customization job

2. Remove overly permissive inbound rules from the security group

Python: strip all inbound rules from the SG

3. Lock down outbound rules if required by your policy

4. Use a hardened SG for all future Bedrock customization jobs

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​1. Identify the Security Group Used by the Customization Job

​2. Tighten the Security Group Rules

​2.1 Restrict Inbound Rules

​2.2 Restrict Outbound Rules (if needed)

​3. (Optional) Create a Locked-Down Security Group for Future Jobs

​4. (Optional) If You Intended to Delete the Security Group

​1. Identify the Security Group(s) Used

​2. Review Current Inbound and Outbound Rules

​3. Remove Insecure Inbound Rules

​4. Restrict Outbound Rules (If Required)

​5. Add Least-Privilege Rules Needed by Bedrock Job

​6. (Optional) Create a New Hardened Security Group and Use It for Future Jobs

​7. (Optional) Delete Unused Security Groups

​1. Identify the Security Group(s) used by the Bedrock customization job

​2. Remove overly permissive inbound rules from the security group

​Python: strip all inbound rules from the SG

​3. Lock down outbound rules if required by your policy

​4. Use a hardened SG for all future Bedrock customization jobs

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Identify the Security Group Used by the Customization Job

2. Tighten the Security Group Rules

2.1 Restrict Inbound Rules

2.2 Restrict Outbound Rules (if needed)

3. (Optional) Create a Locked-Down Security Group for Future Jobs

4. (Optional) If You Intended to Delete the Security Group

1. Identify the Security Group(s) Used

2. Review Current Inbound and Outbound Rules

3. Remove Insecure Inbound Rules

4. Restrict Outbound Rules (If Required)

5. Add Least-Privilege Rules Needed by Bedrock Job

6. (Optional) Create a New Hardened Security Group and Use It for Future Jobs

7. (Optional) Delete Unused Security Groups

1. Identify the Security Group(s) used by the Bedrock customization job

2. Remove overly permissive inbound rules from the security group

Python: strip all inbound rules from the SG

3. Lock down outbound rules if required by your policy

4. Use a hardened SG for all future Bedrock customization jobs