Skip to main content

Bedrock Model Customization Jobs Should Use VPC

More Info:​

Bedrock Model Customization Jobs should use VPC

Risk Level​

Medium

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • ISO/IEC 27018
  • ISO/IEC 27701
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • StateRAMP
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Using Console

To ensure Bedrock model customization jobs run inside a VPC using the AWS Console, you must (a) have a suitable VPC setup, and (b) explicitly select it when creating the customization job.

1. Prepare the VPC networking (one-time setup, if not already done)​

  1. Create or choose a VPC

    • Go to VPC Console → Your VPCs.
    • Either:
      • Use an existing VPC, or
      • Click Create VPC (VPC only), give it a CIDR (e.g., 10.0.0.0/16) and create it.

  2. Create private subnets

    • In the VPC console, go to Subnets → Create subnet.
    • Select your VPC.
    • Create at least 2 subnets in different Availability Zones (for high availability).
    • Mark them as “private” by not associating a route to an Internet Gateway (i.e., no 0.0.0.0/0 to IGW).

  3. Create or choose a security group

    • Go to Security groups → Create security group.
    • Attach it to your VPC.
    • In Inbound rules, only allow the traffic you actually need (often no inbound is required for Bedrock customization jobs if they don’t accept external connections).
    • In Outbound rules, you may allow outbound to required services (for example via VPC endpoints or NAT).

  4. (Recommended) Create VPC endpoints for private access

    • Go to Endpoints → Create endpoint.
    • For fully private operation, create:
      • S3 Gateway endpoint for your VPC (service type: Gateway, com.amazonaws.<region>.s3).
      • Interface endpoints as needed (e.g., for CloudWatch Logs, STS, etc., depending on what your jobs use).
    • Attach these endpoints to the private subnets and security group you created.

2. Configure Bedrock model customization to use the VPC​

  1. Go to the Amazon Bedrock Console.

  2. In the left navigation pane, choose Custom models (or Model customization depending on the UI).

  3. Click Create customization job (or Customize model).

  4. Fill in:

    • Base model
    • Training data location (S3 bucket)
    • Output model location, etc.

  5. In the Network or VPC configuration section:

    • Turn on the option like “Enable VPC” / “Run this job in a VPC”.
    • Select your VPC.
    • Select the private subnets you prepared.
    • Select the security group you prepared.
    • Confirm there is no requirement for public IPs (leave public IP assignment disabled if there’s an option).

  6. Review all settings and click Create / Start job.

3. Enforce VPC usage going forward​

  • Update any internal runbooks or templates so that:
    • All Bedrock customization jobs are created with the VPC networking section enabled.
  • For jobs already running without a VPC:
    • You cannot change the network of an existing job.
    • Stop/let them complete, and recreate future jobs with the VPC configuration as above.

This ensures all new Amazon Bedrock model customization jobs run within a VPC, satisfying the “Bedrock Model Customization Jobs Should Use VPC” requirement.

Using CLI

To ensure Amazon Bedrock model customization jobs use a VPC, you must:

  1. Have a VPC and private subnets.
  2. Create VPC endpoints for Bedrock, S3, and (optionally) CloudWatch Logs.
  3. Run start-model-customization-job with vpcConfig specified.

Below are the minimal step‑by‑step AWS CLI commands.

1. Identify / create VPC and private subnets​

If you already have a VPC and isolated/private subnets, you can reuse them and skip to step 2.

# Create a VPC
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=bedrock-vpc}]'

# Capture the VPC ID (replace in later commands)
VPC_ID=<your-vpc-id>

# Create two private subnets in different AZs (example)
aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=bedrock-private-a}]'

aws ec2 create-subnet \
  --vpc-id $VPC_ID \
  --cidr-block 10.0.2.0/24 \
  --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=bedrock-private-b}]'

Record the SubnetId values; you’ll pass them to Bedrock.

2. Create a security group for Bedrock jobs​

aws ec2 create-security-group \
  --group-name bedrock-customization-sg \
  --description "SG for Bedrock model customization jobs" \
  --vpc-id $VPC_ID

Optionally add inbound rules if your jobs need to talk to internal services:

SG_ID=<sg-id>

# Allow all traffic from within the VPC CIDR (example)
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --ip-permissions IpProtocol=-1,IpRanges='[{CidrIp=10.0.0.0/16,Description="VPC internal"}]'

3. Create required VPC endpoints​

3.1. Interface endpoint for Bedrock​

List the Bedrock endpoint service name for your region:

aws ec2 describe-vpc-endpoint-services \
  --query 'ServiceDetails[?contains(ServiceName, `bedrock`)].ServiceName'

Use the correct ServiceName (example below for com.amazonaws.us-east-1.bedrock):

BEDROCK_SERVICE_NAME=com.amazonaws.us-east-1.bedrock

aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --vpc-endpoint-type Interface \
  --service-name $BEDROCK_SERVICE_NAME \
  --subnet-ids <subnet-id-1> <subnet-id-2> \
  --security-group-ids $SG_ID

If you use Bedrock Agent or other specialized endpoints, also create those corresponding interface endpoints.

3.2. Gateway endpoint for S3 (required for training data / output in S3)​

aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids <route-table-id-for-private-subnets>

3.3. (Optional) Interface endpoint for CloudWatch Logs / Events​

aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.logs \
  --subnet-ids <subnet-id-1> <subnet-id-2> \
  --security-group-ids $SG_ID

Repeat similarly for com.amazonaws.us-east-1.events if needed.

4. Start a Bedrock model customization job with VPC config​

The key is to pass vpcConfig in the --cli-input-json.

Example:

aws bedrock start-model-customization-job \
  --region us-east-1 \
  --cli-input-json '{
    "jobName": "my-bedrock-custom-job",
    "customizationType": "FINE_TUNING",
    "baseModelIdentifier": "anthropic.claude-3-haiku-20240307-v1:0",
    "customModelName": "my-custom-haiku-vpc",
    "roleArn": "arn:aws:iam::<account-id>:role/BedrockCustomizationRole",
    "trainingDataConfig": {
      "s3Uri": "s3://my-bucket/training-data/"
    },
    "outputDataConfig": {
      "s3Uri": "s3://my-bucket/custom-output/"
    },
    "vpcConfig": {
      "subnets": [
        "<subnet-id-1>",
        "<subnet-id-2>"
      ],
      "securityGroupIds": [
        "'$SG_ID'"
      ]
    }
  }'

Replace:

  • baseModelIdentifier with the specific model you’re customizing.
  • IAM role ARN, bucket names, subnet IDs, and security group ID.

5. Enforce VPC usage going forward​

To systematically remediate the finding:

  • Update all automation (scripts, CI/CD, IaC) to always include vpcConfig on start-model-customization-job.
  • Optionally add an SCP or Config rule (e.g., custom Config rule or EventBridge rule + Lambda) that detects jobs started without vpcConfig and alerts or remediates.

This ensures all Bedrock model customization jobs are launched inside your VPC and satisfies the “Bedrock Model Customization Jobs Should Use VPC” requirement.

Using Python

To fix this, you must ensure every model customization job is created with a VPC attached. Bedrock does not let you “update” an existing job’s VPC settings; remediation is:

  1. Stop / let non‑compliant jobs finish.
  2. Re‑create future jobs with vpcConfig.

Below is a concise, end‑to‑end Python (boto3) example.

1. Prerequisites​

pip install boto3
aws configure  # set credentials & region

Make sure you already have:

  • A VPC ID
  • Private subnet IDs in that VPC
  • Security group IDs allowing required egress (e.g. to S3, KMS via NAT)

2. Python: Create a Bedrock Model Customization Job with VPC​

import boto3
import uuid
from datetime import datetime

bedrock = boto3.client("bedrock")

# --- REQUIRED VALUES (replace with your own) ---
region = "us-east-1"

custom_model_name = f"my-custom-model-{datetime.utcnow().strftime('%Y%m%d%H%M%S')}"
base_model_identifier = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"

s3_data_location = "s3://my-bedrock-training-bucket/training-data/"
s3_output_location = "s3://my-bedrock-output-bucket/custom-model-output/"

role_arn = "arn:aws:iam::123456789012:role/BedrockCustomizationRole"

vpc_id = "vpc-0123456789abcdef0"
subnet_ids = ["subnet-0123456789abcdef0", "subnet-0fedcba9876543210"]
security_group_ids = ["sg-0123456789abcdef0"]

# --- BUILD REQUEST BODY ---
job_name = f"bedrock-customization-job-{uuid.uuid4()}"

request = {
    "jobName": job_name,
    "customModelName": custom_model_name,
    "baseModelIdentifier": base_model_identifier,
    "roleArn": role_arn,
    "outputDataConfig": {
        "s3Uri": s3_output_location
    },
    "trainingDataConfig": {
        "s3Uri": s3_data_location
    },
    "vpcConfig": {                       # <<< ENSURES COMPLIANCE
        "subnetIds": subnet_ids,
        "securityGroupIds": security_group_ids
    },
    # Example hyperparameters – adjust for your model type
    "hyperParameters": {
        "epochCount": "3",
        "batchSize": "4",
        "learningRate": "0.0001"
    }
}

response = bedrock.create_model_customization_job(**request)

print("Started customization job with VPC:")
print(f"Job Name: {job_name}")
print(f"Job ARN:  {response['jobArn']}")

Key remediation point: the vpcConfig block must be present in create_model_customization_job.

3. (Optional) Stop Non‑Compliant Jobs​

You can’t retrofit a VPC onto a running job; you can only stop it and recreate it with vpcConfig.

def stop_job(job_identifier: str):
    """job_identifier can be the jobName or jobArn."""
    bedrock.stop_model_customization_job(jobIdentifier=job_identifier)

# Example:
# stop_job("bedrock-customization-job-1234-abcd-...")

4. Validation​

Programmatically verify new jobs are compliant:

def is_job_in_vpc(job_name: str) -> bool:
    resp = bedrock.get_model_customization_job(jobIdentifier=job_name)
    return "vpcConfig" in resp and bool(resp["vpcConfig"].get("subnetIds"))

print(is_job_in_vpc(job_name))  # should be True

Use this pattern in your pipelines so every Bedrock model customization job is launched with vpcConfig, satisfying the “Bedrock Model Customization Jobs Should Use VPC” requirement.

Using Terraform

Terraform cannot currently create or manage Amazon Bedrock model customization jobs; the AWS provider exposes no aws_bedrock_* or similar resource for this API surface, so the VPC configuration cannot be set or corrected via Terraform.

You must remediate this finding outside Terraform using the AWS CLI or Console, following the same steps as the verified remediation:

  1. Check the job, 2) stop the non‑compliant job (irreversible), and 3) create a new model customization job with the required VPC configuration (subnetIds and securityGroupIds) using --vpc-config or the equivalent fields in the Console.