Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
For this finding, there’s nothing to “flip” in a single setting. The AWS managed control CodePipeline deployment limit should be reviewed (Config rule:
In summary, the remediation is to review how often your CodePipeline+CodeBuild combination can deploy and add gates (approvals, restricted triggers, IAM) so that deployments are intentionally controlled rather than unconstrained.
codepipeline-deployment-limit-check) is manual: you must review how often your pipelines (and underlying CodeBuild projects) deploy and put proper controls in place.Below is how to do that for CodeBuild-based pipelines using the AWS Console.1. Identify the affected pipeline(s) and CodeBuild project(s)
- In the AWS Console, go to Security Hub.
- In the left menu, choose Findings.
- Filter:
- Product name:
Security Hub - Resource type:
AWS::CodePipeline::Pipeline - Title / Rule ID contains:
CodePipeline deployment limit should be reviewedorcodepipeline-deployment-limit-check.
- Product name:
- Open a finding and note:
- The pipeline name.
- The region.
- Go to CodePipeline (same region) → find and open the pipeline.
- For each Build action, note the CodeBuild project name.
2. Review and control deployment frequency using approvals
If the issue is that deployments are happening too frequently (e.g., straight to a shared/test/prod environment):- In CodePipeline, open the pipeline.
- Click Edit (top right).
- Between the build stage and the “risky” stage (e.g., deploy-to-shared, deploy-to-prod), add an approval:
- Click + Add stage (or + Add action group in an existing stage).
- Name it something like
Manual-ApprovalorChange-Review. - Choose Action provider:
Manual approval. - Configure:
- SNS topic: an existing topic that notifies approvers, or create one.
- Comments / URL: link to your change ticketing system (optional).
- Save the action.
- Click Save at the top, then Release change if required to re-run.
3. Use CodeBuild project settings to avoid excessive or uncontrolled builds
- Go to CodeBuild → Build projects → open the affected project.
- Click Edit:
- Confirm that Environment settings (privileged mode, IAM role) are appropriate and not allowing overly broad actions in downstream stages that increase deployment risk.
- Under Buildspec / build commands, ensure you are not:
- Triggering additional nested pipelines.
- Manually invoking deployments to multiple environments from one build in an uncontrolled way.
- If necessary, split the build into:
- One build project for build and test.
- Another separate, more controlled pipeline for deployment, with approvals.
4. Control triggers so deployments don’t happen too often
- In CodePipeline → your pipeline → Edit.
- At the Source stage:
- If using CloudWatch Events / EventBridge or Git webhooks, consider:
- Enabling filtering (branch, directory).
- Configuring your repo (GitHub/CodeCommit) to only trigger on specific events.
- If using CloudWatch Events / EventBridge or Git webhooks, consider:
- Or, switch some pipelines to manual trigger (click Release change on demand instead of on every commit) for non-critical or noisy branches.
5. (Optional) Restrict who can start/approve deployments
- Go to IAM → Roles / Users.
- Find the role or user groups that:
- Run the pipeline (
codepipelineservice role). - Have StartPipelineExecution or PutApprovalResult permissions.
- Run the pipeline (
- Tighten policies so only appropriate users/groups can:
- Manually start the pipeline.
- Approve the manual approval steps.
6. Mark the finding as addressed (if using Security Hub)
- Once you’ve implemented the controls above and are satisfied with the deployment behavior:
- In Security Hub → Findings, open the finding.
- Set the Workflow status to Resolved, or add a note indicating:
- What controls you added (manual approval, trigger changes, IAM restrictions).
- That deployment frequency and limits have been reviewed.
In summary, the remediation is to review how often your CodePipeline+CodeBuild combination can deploy and add gates (approvals, restricted triggers, IAM) so that deployments are intentionally controlled rather than unconstrained.
Using CLI
Using CLI
For the “CodePipeline Deployment Limit Check Should Be Reviewed” finding, the remediation is not a change on a specific CodeBuild project; it’s about making sure you’re not too close to (or exceeding) AWS service quotas for CodePipeline/CodeBuild and cleaning up or increasing those limits.Below are step‑by‑step AWS CLI actions you can take to remediate from the CodeBuild side.
Common CodeBuild-related quotas include:Locate the quota whose
Get details to identify unused projects:Repeat for all obsolete projects.
(Use the current project config as a template:
Note the You can then track the request:
1. Identify which limit you are close to
This Trusted Advisor check generally warns when you’re close to CodePipeline/CodeBuild quotas (e.g., number of pipelines, actions, concurrent builds, etc.).List relevant CodeBuild quotas via Service Quotas:CODEBUILD_CONCURRENT_BUILDSCODEBUILD_PROJECTS_PER_ACCOUNT
UsageMetric or description matches what you’re nearing (e.g., concurrent builds, number of projects, etc.).2. Reduce current usage (clean up unused CodeBuild resources)
2.1. List all CodeBuild projects
2.2. Delete unused projects
3. Adjust how many builds run concurrently
If the issue is around concurrent builds or load on CodeBuild:3.1. Reduce parallel builds via batch builds or scheduling
You can reduce parallelism by controlling how many builds are triggered at once (e.g., from CodePipeline or CI system), but directly on a project you can changetimeoutInMinutes, environment, etc., not the hard limit. From CLI, update project configuration for better queue handling:aws codebuild batch-get-projects → edit → update-project.)The actual quota of concurrent builds itself is an account‑level limit, not per project.4. Request a quota increase (if needed)
If cleanup/optimization isn’t enough, request a higher limit with Service Quotas.- Find the specific quota code:
QuotaCode for the quota you need to raise (e.g., L-XXXXXXX).- Request an increase:
5. Re-run/check the finding
Once you’ve:- Deleted unused projects,
- Reduced parallelism where practical,
- And/or increased the service quota,
Using Python
Using Python
“CodePipeline Deployment Limit Check Should Be Reviewed” is an AWS Config managed rule (
It flags CodePipelines whose Deploy stage has no safe deployment limit (for example, a CodeDeploy action pushing to too many instances at once).Below is how to remediate this specifically for pipelines that use CodeBuild + CodeDeploy, using Python (
This gives you the pipeline names/IDs that the rule is flagging.
In the Deploy action configuration you should see keys similar to:
Notes:
If you can paste one of the actual noncompliant pipeline definitions (or the AWS Config rule message), I can tailor the Python exactly to your case (e.g., ECS, CloudFormation, Lambda deployments instead of CodeDeploy).
CODEPIPELINE_DEPLOYMENT_LIMIT_CHECK).It flags CodePipelines whose Deploy stage has no safe deployment limit (for example, a CodeDeploy action pushing to too many instances at once).Below is how to remediate this specifically for pipelines that use CodeBuild + CodeDeploy, using Python (
boto3).1. Understand what you must change
For pipelines that deploy via CodeDeploy, the “deployment limit” is effectively controlled by the deployment configuration on the CodeDeploy deployment group:CodeDeployDefault.OneAtATime– safest (deploy to one instance at a time).CodeDeployDefault.HalfAtATime– deploy to 50% at a time.CodeDeployDefault.AllAtOnce– deploy to all at once (usually what the Config rule flags as risky).
- Identify the CodeDeploy deployment groups your pipeline’s Deploy stage uses.
- Change those deployment groups to use a safer
deploymentConfigName(typicallyCodeDeployDefault.OneAtATimeor a custom config with suitably low percentages).
2. Find noncompliant CodePipelines from AWS Config (Python)
3. For each pipeline, locate the Deploy action and its CodeDeploy deployment group
ApplicationNameDeploymentGroupName
4. Update the CodeDeploy deployment group to a safer deployment config (Python)
Example: changedeploymentConfigName to CodeDeployDefault.OneAtATime.- In practice,
update_deployment_groupmay require additional parameters if you want to modify other aspects; the minimal example above focuses ondeploymentConfigName. - If you need a more tailored rollout (e.g., 10% at a time), create a custom deployment configuration first (
create_deployment_config) and then reference it here.
5. Optional: End‑to‑end automation for all noncompliant pipelines
Sketch:If you can paste one of the actual noncompliant pipeline definitions (or the AWS Config rule message), I can tailor the Python exactly to your case (e.g., ECS, CloudFormation, Lambda deployments instead of CodeDeploy).
Using Terraform
Using Terraform
aws_codedeploy_deployment_group or CodeBuild project, so the remediation is to reduce the number of Deploy actions per stage in aws_codepipeline, especially in the first deployment stage, to be at or below your chosen deploymentLimit.This change normally does not force replacement of the pipeline resource itself, but it will update stages and actions in place; expect terraform plan to show modifications to the stage blocks (removal or reduction of extra Deploy actions) and no changes to unrelated resources.
