How to Add Manual Approval Before Production Deployment in AWS CodePipeline

An automated pipeline can build, test, and deploy an AI application within minutes. That speed is valuable, but production releases may still require a person to confirm that the correct change, model configuration, permissions, and infrastructure are being promoted.

This guide adds a manual approval gate to an existing AWS CodePipeline workflow for a synthetic application named claims-ai-summary. The pipeline already deploys to staging. After staging succeeds, CodePipeline pauses at ApproveProduction. An authorized reviewer examines the release evidence and either approves the production deployment or rejects the execution.

The goal is not to add a ceremonial button. The approval must have a named owner, a defined review checklist, limited IAM permissions, useful evidence, and an auditable decision.

What You Will Build

The final release flow is:

Source
  ↓
Build and automated tests
  ↓
Deploy to staging
  ↓
Verify staging
  ↓
MANUAL APPROVAL
  ↓ approved
Deploy to production

If the reviewer rejects the request, or the approval reaches its configured timeout, the production action does not run.

This implementation uses:

• AWS CodePipeline for pipeline orchestration and the approval action.

  
  

• AWS IAM for a narrowly scoped release-approver role.

  
  

• Amazon SNS for optional approval notifications.

  
  

• AWS CloudTrail for control-plane audit events.

  
  

• Amazon CloudWatch for build, staging, and production evidence.

  
  

• AWS Lambda or Amazon ECS as the application deployment target. The example names use Lambda, but the approval pattern is independent of the deployment service.

  
  

Why Manual Approval Matters for Enterprise AI

Automated tests should block known bad changes, but some release decisions require context that is not yet fully represented in a test suite. For an enterprise AI application, a reviewer may need to confirm changes to:

• System prompts or prompt templates.

  
  

• Model identifiers, versions, regions, or inference parameters.

  
  

• Retrieval indexes, knowledge sources, and grounding configuration.

  
  

• Tool access, IAM permissions, and business-action limits.

  
  

• Safety filters, evaluation thresholds, or human-review rules.

  
  

• Infrastructure, networking, secrets, and production configuration.

  
  

A manual approval does not make a release secure or compliant by itself. It creates a controlled pause where an authorized person can assess defined evidence before production changes begin.

Target Architecture

The approval stage sits after staging verification and immediately before production. This placement matters: the reviewer examines a working staging release, and an approval cannot be bypassed by a later unreviewed build. Production must consume the same build artifact that passed the automated tests and staging checks.

AWS CodePipeline approval actions cannot be added to the Source stage. The AWS procedure for adding an approval action places it in a new or existing stage at the point where the pipeline should pause.

Prerequisites

Before adding the approval gate, confirm that you have:

• An existing pipeline named claims-ai-summary-pipeline.

  
  

• Working Source, Build/Test, Staging, and Production actions.

  
  

• A staging environment that can be reviewed safely before release.

  
  

• A production action that consumes the same packaged artifact used for staging.

  
  

• Permission to edit the pipeline and its service role.

  
  

• An AWS IAM Identity Center permission set or federated IAM role for release approvers.

  
  

• A synthetic test change for verifying approval and rejection without affecting customer data.

  
  

• Optional: an SNS topic in the same AWS Region as the pipeline and a confirmed subscription.

  
  

Use a sandbox or non-customer account for this tutorial. Do not experiment with rejection, timeout, or IAM permissions in a shared production pipeline without an approved change plan.

Step 1: Confirm the Pipeline Is Ready for an Approval Gate

Open the pipeline and verify its current order. Staging must finish before production begins:

Source → Build/Test → DeployStaging → VerifyStaging → DeployProduction

Confirm these conditions before editing:

Check	Required condition
Build artifact	Staging and production reference the same packaged artifact
Automated tests	A failed test prevents staging deployment
Staging verification	A failed smoke or integration test prevents approval
Production action	Production starts only after preceding stages succeed
Rollback	The team knows how to restore the last approved release
Audit evidence	Source revision, build ID, test result, and stack/deployment ID can be correlated

If the pipeline rebuilds the application after staging, correct that first. Approval should authorize a specific tested artifact, not permission to create a different production artifact later.

No screenshot is needed for this step. Record the current pipeline version and artifact names in the implementation notes.

Step 2: Define What the Approver Must Review

Write the approval policy before configuring the action. A useful approval request tells the reviewer what changed, what evidence exists, and what decision they are making.

For claims-ai-summary, use this release checklist:

Review area	Evidence
Source	Reviewed pull request and exact commit identifier
Automated validation	Successful unit, integration, AI behavior, and security tests applicable to the release
Staging	Successful deployment and smoke-test result
AI configuration	Prompt, model, retrieval, tool, and safety-control changes summarized
Permissions	IAM and application authorization changes reviewed
Operations	Monitoring, rollback owner, and observation window confirmed
Business authorization	Change ticket or release record approved when required

Define the reviewer role independently from the developer who initiated the release. AWS CodePipeline can pause and record a decision, but separation of duties depends on how your organization assigns IAM access and operates its release process.

No screenshot is needed. Save the checklist in the repository or release-management system so it is versioned and reviewable.

Step 3: Grant a Dedicated Approver the Minimum Required Access

Create or update an IAM Identity Center permission set or federated role named claims-ai-summary-release-approver. Prefer temporary federated access over long-lived IAM users.

The reviewer needs read access to the named pipeline and permission to submit a decision only for the intended approval action. The important permission is codepipeline:PutApprovalResult on the action ARN.

A narrowly scoped policy follows this pattern:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReleasePipeline",
      "Effect": "Allow",
      "Action": [
        "codepipeline:GetPipeline",
        "codepipeline:GetPipelineState",
        "codepipeline:GetPipelineExecution"
      ],
      "Resource": "arn:aws:codepipeline:<AWS_REGION>:<ACCOUNT_ID>:claims-ai-summary-pipeline"
    },
    {
      "Sid": "DecideProductionApproval",
      "Effect": "Allow",
      "Action": "codepipeline:PutApprovalResult",
      "Resource": "arn:aws:codepipeline:<AWS_REGION>:<ACCOUNT_ID>:claims-ai-summary-pipeline/ApproveProduction/ReviewRelease"
    }
  ]
}

Replace the placeholders during implementation and do not publish the resulting account-specific ARN. If reviewers need to browse the pipeline list in the console, grant the additional list permission documented by AWS. Do not attach full CodePipeline administration access merely to make the approval button visible.

AWS provides a managed approver policy, but AWS also recommends narrowing managed permissions for specific use cases. The approval IAM documentation includes a resource-scoped pattern for a particular pipeline, stage, and action.

No screenshot is needed. Retain the reviewed policy document or IaC change as evidence.

Step 4: Configure Optional Approval Notifications

An approval gate is ineffective if the responsible person does not know it is waiting. For a small tutorial, the reviewer can monitor CodePipeline directly. For an operational workflow, create an SNS topic such as claims-ai-summary-production-approvals in the same Region as the pipeline.

Configure an approved subscriber endpoint and confirm the subscription. Then allow the CodePipeline service role to publish only to that topic. Avoid exposing confidential release notes in an email or broadly subscribed channel.

The notification should direct the reviewer to the pipeline, but the decision must still be submitted by an authenticated identity with PutApprovalResult. Receiving a notification is not approval authority.

No screenshot is needed. Record the topic ARN in the deployment configuration, redact the account ID from publication material, and test delivery with non-sensitive content.

Step 5: Insert the Manual Approval Stage

Open claims-ai-summary-pipeline in the CodePipeline console and edit the pipeline. Add a stage between VerifyStaging and DeployProduction with these values:

Setting	Value
Stage name	ApproveProduction
Action name	ReviewRelease
Action provider	Manual approval
SNS topic ARN	The optional approval topic
URL for review	A stable staging release, test report, or internal change-record URL
Comments	A concise release-review instruction

Example comments:

Confirm the source revision, automated test report, staging verification,
AI configuration changes, permission changes, and rollback owner before deciding.

Save the action and pipeline. Reopen the pipeline definition and confirm the order is now:

Source
→ Build/Test
→ DeployStaging
→ VerifyStaging
→ ApproveProduction
→ DeployProduction

The review URL must point to evidence for the current release. Do not use a generic home page that forces the approver to search for the relevant build. CodePipeline variables can be included in approval information when upstream actions expose them; see the AWS guidance on using variables in manual approvals.

Step 6: Trigger a Release and Review the Evidence

Merge a small, reviewed synthetic change to the configured source branch. Follow the execution until staging deployment and verification succeed.

At ApproveProduction, CodePipeline should pause. The production action must remain unstarted. If SNS is configured, the approver should receive one non-sensitive notification for the waiting action.

Before deciding, the reviewer should compare:

1. The source revision in CodePipeline with the reviewed pull request.

   
   

2. The CodeBuild result and applicable AI test report.

   
   

3. The staging deployment identifier and smoke-test evidence.

   
   

4. The declared prompt, model, permission, and infrastructure changes.

   
   

5. The rollback plan and operational owner.

   
   

According to the current AWS documentation, the account-level default timeout for a manual approval is seven days. CodePipeline quotas also document a configurable action timeout from five minutes up to 60 days. Choose a timeout that matches the release process instead of allowing requests to wait indefinitely.

Step 7: Approve and Verify Production Deployment

After the evidence satisfies the release checklist, enter a decision comment that explains what was reviewed and choose Approve. CodePipeline should resume and run DeployProduction.

Verify the release at two levels:

• Pipeline: the production action uses the same build artifact and source revision reviewed at the approval stage.

  
  

• Application: the production Lambda version, ECS task definition, or deployment identifier changes as expected, and the approved synthetic smoke test succeeds.

  
  

For the claims-ai-summary example, invoke the production application with non-sensitive synthetic input and confirm the expected response contract. Check CloudWatch for errors without publishing raw request data.

Do not describe the release as successful until the production action and application check have actually completed.

Verify the Approval and Rejection Paths

Test both decisions in a disposable environment. One approved execution proves only half of the control.

Test	Expected result	Required evidence
Approval pending	Production remains unstarted	Screenshot 2 plus pipeline execution ID
Authorized approval	Production begins only after the decision	Screenshot 4 plus production deployment ID
Unauthorized identity	Identity cannot submit PutApprovalResult	Redacted authorization error or CloudTrail event; no screenshot required
Rejection	Pipeline execution fails and production remains unchanged	Execution event, rejection comment, and unchanged production version; no screenshot required
Notification	Intended subscriber receives the correct review link	Redacted delivery record; no screenshot required
Traceability	Decision maps to source revision and staging evidence	Correlated revision, execution, build, and deployment IDs

AWS documents that approval resumes the pipeline, while rejection prevents it from continuing. Reviewers can submit the decision and an explanatory comment in the console; see approving or rejecting an action.

The tests prove that this pipeline requires an authorized decision at this point in the workflow. They do not prove that the reviewer assessed the evidence correctly, that two-person separation is enforced outside IAM, or that the application meets all production requirements.

Production Considerations

Security and Separation of Duties

Separate these responsibilities wherever practical:

• Developers create and review application changes.

  
  

• The pipeline service role orchestrates actions

  
  

• Staging and production deployment roles modify only their environments.

  
  

• Release approvers can inspect evidence and submit only the named approval decision.

  
  

• Security or risk owners review sensitive model, data, and permission changes when policy requires it.

  
  

Use IAM Identity Center, temporary sessions, multifactor authentication, and resource-scoped customer-managed policies. Avoid giving approvers the ability to edit the pipeline they approve or to deploy directly around it.

Release Evidence Quality

Approval quality depends on the evidence presented. Give the reviewer a release-specific URL, source revision, test summary, staging version, AI behavior changes, security changes, and rollback details. A vague message such as “Please approve” provides weak control even when the IAM configuration is correct.

Never include credentials, confidential prompts, customer inputs, raw model conversations, or internal secrets in approval comments or SNS notifications.

Preventing Artifact Substitution

Production must consume the exact artifact tested in staging. Keep immutable artifact identifiers, restrict write access to the artifact bucket, use appropriate S3 and KMS policies, and avoid rebuilding between approval and production.

If an execution is superseded by a newer release, reject the stale approval rather than approving it for convenience. Review the source revision every time.

Reliability and Timeout Handling

Define what happens when the approver is unavailable, the request expires, or the production window closes. Use an escalation rotation rather than sharing credentials. If approval times out, start a new release execution and review its current evidence instead of trying to bypass the gate.

Maintain and test rollback independently. Manual approval reduces unreviewed deployments; it does not prevent runtime failures after an approved release.

Monitoring and Auditability

Retain enough evidence to reconstruct:

Source revision
→ Pipeline execution
→ Automated test result
→ Staging deployment and verification
→ Approver identity, decision, and timestamp
→ Production deployment identifier

Use CloudTrail for CodePipeline control-plane activity and the organization’s approved retention destination. Use EventBridge, SNS, or the notification system selected by the operations team for pending, rejected, timed-out, and failed releases.

Cost

The approval action itself does not run compute, but the surrounding pipeline, CodeBuild jobs, artifact storage, notifications, logs, KMS requests, Lambda/ECS resources, and AI inference can incur charges. CodePipeline V1 and V2 use different pricing models; check the current AWS CodePipeline pricing before publication and deployment.

Keep staging resources running only as long as the organization needs them, set log retention intentionally, and ensure a waiting approval does not leave expensive test endpoints or provisioned model capacity idle.

Multi-Account Production

For an enterprise deployment, keep production in a separate AWS account. The approval should authorize a cross-account production action that assumes a narrowly scoped deployment role. The approver does not need general production administration access merely to approve the pipeline action.

Use service control policies, artifact encryption, cross-account KMS key policies, and centralized audit logging according to the organization’s governance model.

Clean Up the Tutorial Resources

If the approval stage was added only for a disposable tutorial:

1. Preserve the four screenshots and required execution records before cleanup.

   
   

2. Stop or reject any execution still waiting for approval.

   
   

3. Edit or delete the tutorial pipeline so it cannot start more releases.

   
   

4. Remove the dedicated approver permission set, role, and customer-managed policy if nothing else uses them.

   
   

5. Delete the dedicated SNS topic and subscriptions if created only for the tutorial.

   
   

6. Delete staging and production resources through their deployment stacks or approved infrastructure process.

   
   

7. Review artifact buckets, logs, notification resources, and KMS keys separately; pipeline deletion may not remove them.

   
   

Do not delete audit evidence that must be retained. Follow the organization’s change, evidence-retention, and KMS-key deletion policies.

Reference Implementation

This article can reuse the aws-ai-cicd-pipeline repository from the broader CI/CD tutorial. Add the approval stage to its pipeline infrastructure definition and include:

infrastructure/
├── pipeline.yml
└── approver-policy.json
docs/
└── production-approval-checklist.md

How Codersarts Can Help

Codersarts can add controlled production promotion to an existing AWS delivery workflow, including CodePipeline approval gates, multi-account deployment roles, AI-specific release evidence, least-privilege approver access, notifications, audit correlation, and rollback planning.

Learn more about Codersarts AI development services or discuss how to strengthen production releases for an AWS AI application.

Conclusion

A useful manual approval gate connects human judgment to a specific tested artifact. Placing it after staging verification and before production allows an authorized reviewer to inspect the source revision, automated results, AI behavior changes, permissions, and rollback readiness before the production action can begin.

The control becomes meaningful when it also has scoped IAM access, clear evidence, an accountable decision, a tested rejection path, and an audit trail. Automation still performs the deployment; human approval determines whether that exact release is allowed to proceed.

References

• Add a manual approval action to a CodePipeline pipeline

• Manual approval workflow and notification options

• Approve or reject an approval action

• Grant approval permissions to a specific pipeline action

• Use CodePipeline variables in manual approvals

• AWS CodePipeline quotas and approval timeout

• Identity and access management for CodePipeline

• AWS CodePipeline pricing