{"id":200,"date":"2026-04-13T04:29:00","date_gmt":"2026-04-13T04:29:00","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-codepipeline-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools\/"},"modified":"2026-04-13T04:29:00","modified_gmt":"2026-04-13T04:29:00","slug":"aws-codepipeline-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-codepipeline-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools\/","title":{"rendered":"AWS CodePipeline Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Developer tools"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Developer tools<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS CodePipeline is a managed continuous integration and continuous delivery (CI\/CD) orchestration service in AWS. It helps you model, automate, and monitor the steps required to release software\u2014starting from a source code change and ending with a deployed application or updated infrastructure.<\/p>\n\n\n\n<p>In simple terms: <strong>AWS CodePipeline watches for changes (like a Git push), then automatically runs a series of actions (build, test, approve, deploy) in the order you define<\/strong>. You get a visual workflow, execution history, and tight integration with many AWS services used for builds and deployments.<\/p>\n\n\n\n<p>Technically, AWS CodePipeline is a <strong>pipeline orchestrator<\/strong>. It does not compile code by itself and it does not deploy by itself. Instead, it coordinates <strong>actions<\/strong> that are performed by other services (for example, AWS CodeBuild for builds, AWS CloudFormation for infrastructure deployments, Amazon ECS for container deployments, AWS Lambda for invoking automation, and third-party providers through supported integrations). It stores and moves artifacts between steps, manages stage transitions, and emits events\/telemetry for operations and governance.<\/p>\n\n\n\n<p>The core problem AWS CodePipeline solves is <strong>repeatable, auditable, automated releases<\/strong>. Without a pipeline orchestrator, teams often rely on manual steps or ad-hoc scripts, which leads to inconsistent deployments, longer lead times, higher change-failure rates, and weaker auditability. CodePipeline standardizes releases so that deployments are predictable and can be traced end-to-end.<\/p>\n\n\n\n<blockquote>\n<p>Service name note: The primary service name remains <strong>AWS CodePipeline<\/strong>. Some related integrations have evolved over time (for example, the AWS-managed connection service for GitHub\/GitLab has been branded as <strong>AWS CodeConnections<\/strong> in recent AWS materials; you may also see older references to \u201cAWS CodeStar Connections\u201d). <strong>Verify in official AWS docs<\/strong> for the naming used in your account\/region and console.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS CodePipeline?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>AWS CodePipeline is an AWS <strong>continuous delivery service<\/strong> that helps you <strong>automate release pipelines<\/strong> for fast and reliable application and infrastructure updates.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>AWS CodePipeline enables you to:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define a <strong>pipeline<\/strong> made of ordered <strong>stages<\/strong> (for example: Source \u2192 Test \u2192 Approve \u2192 Deploy)<\/li>\n<li>Configure <strong>actions<\/strong> within each stage (build, test, approval, deploy, invoke)<\/li>\n<li>Automatically trigger pipeline executions from <strong>source changes<\/strong> (depending on the source provider)<\/li>\n<li>Pass <strong>artifacts<\/strong> (build outputs, templates, packages) between stages<\/li>\n<li>Monitor runs, troubleshoot failures, and integrate notifications and operations tooling<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pipeline<\/strong>: The top-level workflow definition.<\/li>\n<li><strong>Stage<\/strong>: A logical group of actions, typically aligned to lifecycle phases (source\/build\/test\/deploy).<\/li>\n<li><strong>Action<\/strong>: A task performed by an AWS service or partner integration (for example, deploy to S3, invoke Lambda, run CodeBuild).<\/li>\n<li><strong>Artifact<\/strong>: Files produced and consumed by actions (for example, a ZIP of your source or build output), typically stored in Amazon S3.<\/li>\n<li><strong>Execution<\/strong>: A single run of the pipeline.<\/li>\n<li><strong>Transition<\/strong>: The movement from one stage to the next; can be disabled to \u201cpause\u201d a pipeline.<\/li>\n<li><strong>Service role \/ action roles<\/strong>: IAM roles that allow CodePipeline and action providers to access resources securely.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed CI\/CD pipeline orchestration service<\/strong> (control plane).<\/li>\n<li>Relies on other services for compute and deployment work.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional vs global<\/h3>\n\n\n\n<p>AWS CodePipeline is generally treated as a <strong>regional service<\/strong>: you create pipelines in a specific AWS Region, and that pipeline\u2019s resources (like the artifact bucket and many actions) are typically region-scoped. Cross-region and cross-account patterns are supported for certain use cases, but require explicit configuration (for example, additional artifact stores\/keys and IAM roles). <strong>Verify regional behavior and cross-region action requirements in the official docs<\/strong> for your chosen action types.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>AWS CodePipeline sits in the AWS Developer Tools family and commonly integrates with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Source<\/strong>: GitHub via AWS-managed connections (AWS CodeConnections), AWS CodeCommit (if used in your organization), Amazon S3, and other supported providers<\/li>\n<li><strong>Build\/Test<\/strong>: AWS CodeBuild, AWS Lambda (custom testing), partner tools<\/li>\n<li><strong>Deploy<\/strong>: AWS CodeDeploy, Amazon ECS, AWS CloudFormation, AWS Elastic Beanstalk, Amazon S3 (static content), and custom actions<\/li>\n<li><strong>Security\/Governance<\/strong>: AWS IAM, AWS KMS, AWS CloudTrail, Amazon EventBridge, Amazon CloudWatch, AWS Config, AWS Organizations (multi-account patterns)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS CodePipeline?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster delivery<\/strong>: Reduces time from commit to production.<\/li>\n<li><strong>Lower change risk<\/strong>: Standardized pipelines reduce manual error.<\/li>\n<li><strong>Auditability<\/strong>: Execution history helps with compliance and post-incident review.<\/li>\n<li><strong>Team scalability<\/strong>: A shared delivery mechanism across many repos\/services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Repeatable releases<\/strong>: Same steps every time, reducing \u201cworks on my machine\u201d variability.<\/li>\n<li><strong>Integrated artifact flow<\/strong>: Manages passing outputs between steps.<\/li>\n<li><strong>Composable actions<\/strong>: Mix AWS-native actions with custom automation (for example, Lambda).<\/li>\n<li><strong>Environment promotion<\/strong>: Model dev \u2192 staging \u2192 prod progression with approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central visibility<\/strong>: Console view of the release flow and which stage failed.<\/li>\n<li><strong>Event-driven operations<\/strong>: Emit events you can route to ChatOps, tickets, or incident tooling.<\/li>\n<li><strong>Controlled rollouts<\/strong>: Add manual approvals, gated transitions, and environment-specific deploy steps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based access<\/strong>: Fine-grained permissions on who can edit pipelines, approve steps, or access artifacts.<\/li>\n<li><strong>Encryption<\/strong>: Artifact storage can be encrypted with AWS KMS.<\/li>\n<li><strong>Logging<\/strong>: CloudTrail can record API activity; EventBridge can forward execution state changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed control plane<\/strong>: No pipeline servers to maintain.<\/li>\n<li><strong>Parallel actions<\/strong>: Actions in a stage can be configured to run concurrently where supported.<\/li>\n<li><strong>Scales with usage<\/strong>: Suitable for small teams and large portfolios (with governance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose AWS CodePipeline<\/h3>\n\n\n\n<p>Choose AWS CodePipeline when:\n&#8211; You run workloads on AWS and want <strong>AWS-native CI\/CD orchestration<\/strong>\n&#8211; You need <strong>multi-stage promotion<\/strong> with approvals and audit trails\n&#8211; You want <strong>tight integration<\/strong> with AWS deployment targets (CloudFormation\/ECS\/Lambda\/S3\/CodeDeploy)\n&#8211; You need a managed service rather than self-hosting CI\/CD infrastructure<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose AWS CodePipeline<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; Your primary runtime is not AWS and you want a cloud-agnostic CI\/CD platform\n&#8211; You need very advanced workflow modeling beyond what CodePipeline provides natively (complex DAGs, dynamic fan-out\/fan-in across hundreds of microservices) and you prefer specialized workflow engines\n&#8211; You already standardized on another CI\/CD platform (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) and CodePipeline adds little value\n&#8211; You need fully offline\/on-prem pipeline control planes (CodePipeline is a managed AWS service)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS CodePipeline used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>AWS CodePipeline is used broadly anywhere software delivery needs automation and auditability, including:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software companies<\/li>\n<li>Financial services and fintech (with strong change control)<\/li>\n<li>Healthcare and life sciences (compliance-driven delivery)<\/li>\n<li>Retail and e-commerce (frequent updates, seasonal scaling)<\/li>\n<li>Media and gaming (rapid iteration, content deployments)<\/li>\n<li>Manufacturing and IoT (edge + cloud deployment workflows)<\/li>\n<li>Public sector (approval-heavy release processes)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building standardized delivery \u201cpaved roads\u201d<\/li>\n<li>DevOps\/SRE teams operating deployments, rollback strategies, and observability hooks<\/li>\n<li>Application teams delivering services and infrastructure as code<\/li>\n<li>Security teams embedding scanning and policy gates into releases<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Static websites and documentation sites<\/li>\n<li>Serverless applications (Lambda + API Gateway)<\/li>\n<li>Containers (ECS\/EKS with supporting actions\/tools)<\/li>\n<li>Infrastructure-as-code deployments (CloudFormation, CDK pipelines with CodePipeline, Terraform via custom build\/deploy actions)<\/li>\n<li>Data\/analytics workflows where pipeline runs trigger deployment of ETL jobs or scheduled tasks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single-account deployments (dev\/test\/prod in one account)<\/li>\n<li>Multi-account landing zone deployments (separate accounts per environment)<\/li>\n<li>Multi-region releases (regional stacks with global routing)<\/li>\n<li>Hybrid workflows (AWS-hosted pipeline coordinating on-prem steps via custom actions)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: Feature branch validation, ephemeral environments, preview deployments, integration test pipelines<\/li>\n<li><strong>Production<\/strong>: Controlled promotion, manual approvals, change windows, audit logging, rollback\/blue-green strategies (using downstream deploy services)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS CodePipeline is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Commit-to-deploy for a static website (S3\/CloudFront)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Manual uploads to a website bucket are error-prone and not auditable.<\/li>\n<li><strong>Why AWS CodePipeline fits<\/strong>: Automates source \u2192 deploy and records deployment history.<\/li>\n<li><strong>Example<\/strong>: Marketing site updates published automatically after a merge to <code>main<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Serverless deployment pipeline (Lambda + IaC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Coordinating packaging, infrastructure updates, and function publishing is complex.<\/li>\n<li><strong>Why it fits<\/strong>: Orchestrates build\/test plus infrastructure deploy actions.<\/li>\n<li><strong>Example<\/strong>: Pipeline runs tests, then updates a CloudFormation stack for Lambda\/API Gateway.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Multi-environment promotion with approvals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need dev \u2192 staging \u2192 prod promotion with sign-off.<\/li>\n<li><strong>Why it fits<\/strong>: Manual approval actions and stage transitions support controlled releases.<\/li>\n<li><strong>Example<\/strong>: Security approves production deployment after staging tests pass.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Infrastructure-as-code release governance (CloudFormation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: IaC changes must be reviewed, tested, and rolled out safely.<\/li>\n<li><strong>Why it fits<\/strong>: Combines source triggers, change set creation\/execution, and approvals.<\/li>\n<li><strong>Example<\/strong>: Pipeline creates CloudFormation change sets, requires approval, then executes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Container deployment orchestration (ECS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Updating container images and task definitions across environments is repetitive.<\/li>\n<li><strong>Why it fits<\/strong>: Orchestrates build\/push image steps and ECS deployment actions (often via CodeBuild + deploy).<\/li>\n<li><strong>Example<\/strong>: Push to <code>main<\/code> triggers image build and deploy to ECS service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Cross-account production deployment (AWS Organizations)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Production is isolated in a separate AWS account; deployments must be controlled.<\/li>\n<li><strong>Why it fits<\/strong>: Supports cross-account role assumption patterns for actions.<\/li>\n<li><strong>Example<\/strong>: Pipeline in a tooling account deploys to prod account using an IAM role.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Release pipeline for monorepos<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple components in a single repo need consistent deployment steps.<\/li>\n<li><strong>Why it fits<\/strong>: Pipeline stages can run parallel actions per component (with careful artifact handling).<\/li>\n<li><strong>Example<\/strong>: A monorepo containing frontend + backend triggers coordinated releases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Scheduled \u201ccompliance rebuild\u201d pipeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Periodic rebuilds and redeploys are required (for patched base images\/dependencies).<\/li>\n<li><strong>Why it fits<\/strong>: Pipelines can be triggered by events (for example, scheduled triggers via EventBridge + API calls).<\/li>\n<li><strong>Example<\/strong>: Weekly rebuild of AMIs\/containers and redeploy to staging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Automated documentation publishing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Docs should be updated when markdown changes, without manual steps.<\/li>\n<li><strong>Why it fits<\/strong>: Source trigger + deploy to S3 (or downstream docs hosting) is straightforward.<\/li>\n<li><strong>Example<\/strong>: Engineering handbook updated on merge to main.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Partner tool integration with an AWS-centered release process<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Company uses third-party scanners\/tests but deploys on AWS.<\/li>\n<li><strong>Why it fits<\/strong>: CodePipeline supports partner actions and custom actions to integrate external tooling.<\/li>\n<li><strong>Example<\/strong>: Run a security scan action, then deploy only if the scan passes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Blue\/green deployment orchestration (via deploy service)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need safer production rollouts with traffic shifting and rollback.<\/li>\n<li><strong>Why it fits<\/strong>: Pipeline coordinates build\/test and then triggers a blue\/green deployment in the deploy target service.<\/li>\n<li><strong>Example<\/strong>: Pipeline triggers CodeDeploy blue\/green for ECS or EC2 workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Release train management for regulated environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Releases must occur in a controlled window with auditable approvals.<\/li>\n<li><strong>Why it fits<\/strong>: Manual approvals, logs, and consistent stages support release-train processes.<\/li>\n<li><strong>Example<\/strong>: Monthly production release with formal approvals and documented artifacts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pipelines, stages, and actions (visual workflow)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you model release steps as stages with actions.<\/li>\n<li><strong>Why it matters<\/strong>: Creates a repeatable, shareable release process.<\/li>\n<li><strong>Practical benefit<\/strong>: A new engineer can understand the delivery workflow by viewing the pipeline diagram.<\/li>\n<li><strong>Caveats<\/strong>: The pipeline is an orchestrator\u2014build\/test\/deploy work happens in action providers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Automated triggering from source changes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Starts pipeline executions when the source changes (provider-dependent).<\/li>\n<li><strong>Why it matters<\/strong>: Removes manual \u201ckick off a release\u201d steps.<\/li>\n<li><strong>Practical benefit<\/strong>: Every merge to <code>main<\/code> becomes a traceable deployment.<\/li>\n<li><strong>Caveats<\/strong>: Trigger behavior depends on source provider and integration method. <strong>Verify current trigger mechanics<\/strong> for GitHub connections and your branching strategy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Artifact management (S3-backed artifact store)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Stores and transfers artifacts between actions\/stages.<\/li>\n<li><strong>Why it matters<\/strong>: Enables separation of responsibilities (source produces artifact; deploy consumes artifact).<\/li>\n<li><strong>Practical benefit<\/strong>: You can promote the same tested artifact to multiple environments.<\/li>\n<li><strong>Caveats<\/strong>: Artifacts incur S3 storage and request costs; artifact encryption and bucket policies must be managed carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Manual approvals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Inserts a manual gate requiring a human to approve before proceeding.<\/li>\n<li><strong>Why it matters<\/strong>: Supports change control, release windows, and compliance.<\/li>\n<li><strong>Practical benefit<\/strong>: Production deploys can require on-call or CAB approval.<\/li>\n<li><strong>Caveats<\/strong>: Manual approvals can become bottlenecks if overused; define SLAs and ownership for approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Parallel actions within a stage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Runs multiple actions concurrently within a stage (where supported).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces end-to-end pipeline runtime.<\/li>\n<li><strong>Practical benefit<\/strong>: Run unit tests and linting at the same time.<\/li>\n<li><strong>Caveats<\/strong>: Parallelism increases concurrency against downstream services; ensure quotas and costs are understood.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cross-account support (with IAM roles)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables deployments into other AWS accounts via assumed roles.<\/li>\n<li><strong>Why it matters<\/strong>: Supports strong environment isolation and least privilege.<\/li>\n<li><strong>Practical benefit<\/strong>: Tooling account hosts pipelines; prod account stays locked down.<\/li>\n<li><strong>Caveats<\/strong>: Requires careful IAM trust policies and permission boundaries; misconfiguration can cause hard-to-debug access failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cross-region support (for certain actions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports deploying to resources in other regions, typically by using additional artifact stores.<\/li>\n<li><strong>Why it matters<\/strong>: Enables multi-region resilience and regionalized deployments.<\/li>\n<li><strong>Practical benefit<\/strong>: Deploy the same release to <code>us-east-1<\/code> and <code>eu-west-1<\/code>.<\/li>\n<li><strong>Caveats<\/strong>: Cross-region pipelines can increase complexity and data transfer; verify which action types support cross-region patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Execution history and rollback assistance (operational visibility)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a record of pipeline executions and where failures occurred.<\/li>\n<li><strong>Why it matters<\/strong>: Helps diagnose release failures and supports audit requirements.<\/li>\n<li><strong>Practical benefit<\/strong>: You can quickly identify which commit\/artifact caused a failed deploy.<\/li>\n<li><strong>Caveats<\/strong>: Rollback is not automatic by default; rollback strategy depends on your deploy target (for example, blue\/green in CodeDeploy or traffic shifting in other services).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Event and notification integrations (EventBridge\/SNS patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Emits pipeline state changes that can be routed to notifications or automation.<\/li>\n<li><strong>Why it matters<\/strong>: Improves operational response and visibility.<\/li>\n<li><strong>Practical benefit<\/strong>: Notify a Slack channel (via a webhook bridge) when production deploy completes.<\/li>\n<li><strong>Caveats<\/strong>: Event routing and notification endpoints introduce additional services and IAM permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with AWS security and audit services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with IAM, KMS, CloudTrail, and service-linked roles where applicable.<\/li>\n<li><strong>Why it matters<\/strong>: Enables enterprise governance and compliance.<\/li>\n<li><strong>Practical benefit<\/strong>: Security teams can audit who changed pipeline definitions and when.<\/li>\n<li><strong>Caveats<\/strong>: Strong governance requires additional setup (CloudTrail organization trails, KMS key policies, tagging standards).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>AWS CodePipeline acts as a control plane that:\n1. Detects or receives a trigger indicating a source change (provider-dependent).\n2. Pulls source and packages it as an artifact.\n3. Stores artifacts in an S3 artifact store (optionally encrypted with KMS).\n4. Invokes configured actions in sequence (and in parallel within a stage).\n5. Tracks status, retries (where supported), and transitions.\n6. Publishes execution state changes to AWS eventing\/monitoring systems (for example, EventBridge).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow<\/strong>: CodePipeline coordinates which action runs next and with what inputs.<\/li>\n<li><strong>Data flow<\/strong>: Artifacts (ZIPs, templates, packages) flow between actions via the artifact store (S3).<\/li>\n<li><strong>Identity flow<\/strong>: CodePipeline uses IAM roles to call AWS APIs on your behalf; some actions use their own service roles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon S3<\/strong>: Artifact store and simple deploy target for static content\n&#8211; <strong>AWS CodeBuild<\/strong>: Build\/test steps (compilation, unit tests, packaging)\n&#8211; <strong>AWS CodeDeploy<\/strong>: Deployment orchestration (EC2, ECS, Lambda deployments)\n&#8211; <strong>AWS CloudFormation<\/strong>: Infrastructure deployment and change sets\n&#8211; <strong>Amazon ECS \/ AWS Lambda<\/strong>: Deployment targets (often via deploy actions or CloudFormation)\n&#8211; <strong>Amazon EventBridge<\/strong>: Pipeline execution events to drive automation\/notifications\n&#8211; <strong>AWS CloudTrail<\/strong>: Audit logs of API actions<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>A typical pipeline requires:\n&#8211; One or more source providers (GitHub via AWS-managed connection, S3, etc.)\n&#8211; An artifact store in S3\n&#8211; IAM roles for CodePipeline and any action providers\n&#8211; Optional: KMS keys for encryption, EventBridge rules for notifications, CloudWatch alarms for monitoring<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> governs:<\/li>\n<li>Who can create\/update\/delete pipelines<\/li>\n<li>Who can start executions or approve manual steps<\/li>\n<li>What the pipeline is allowed to access (S3 buckets, deploy targets)<\/li>\n<li><strong>KMS<\/strong> can encrypt pipeline artifacts in S3.<\/li>\n<li><strong>Cross-account access<\/strong> is typically done using IAM roles with trust relationships.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>AWS CodePipeline itself is a managed AWS service. Networking considerations mainly apply to:\n&#8211; The services running builds\/tests\/deployments (for example, CodeBuild in a VPC)\n&#8211; Access from those services to private endpoints (for example, VPC endpoints for S3, STS)\n&#8211; Secure access to external source providers (for example, GitHub connectivity via AWS-managed integration)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CodePipeline execution history<\/strong> for quick pipeline-level troubleshooting.<\/li>\n<li>Use <strong>CloudTrail<\/strong> to audit pipeline changes and sensitive actions like approvals.<\/li>\n<li>Use <strong>EventBridge<\/strong> to capture state changes for notifications and automation.<\/li>\n<li>Use <strong>CloudWatch<\/strong> primarily for downstream logs (for example, CodeBuild logs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (lab-scale)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer pushes to GitHub] --&gt; Conn[AWS-managed Git connection]\n  Conn --&gt; CP[AWS CodePipeline]\n  CP --&gt; S3a[(S3 Artifact Store)]\n  CP --&gt; S3d[(S3 Deploy Bucket)]\n  S3d --&gt; User[User downloads\/opens deployed content]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (multi-stage, multi-account)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph ToolingAccount[Tooling Account]\n    Repo[Source Repo (GitHub\/Enterprise)] --&gt; Conn[AWS CodeConnections]\n    Conn --&gt; CP[AWS CodePipeline]\n    CP --&gt; Art[(S3 Artifact Store + KMS)]\n    CP --&gt; Evt[EventBridge Rules]\n    Evt --&gt; Notif[SNS\/ChatOps\/Ticketing]\n  end\n\n  subgraph SharedServices[Shared Services]\n    Sec[Security Scans (CodeBuild\/Partner)]:::svc\n    Tests[Integration Tests (CodeBuild)]:::svc\n  end\n\n  subgraph DevAccount[Dev Account]\n    DevDeploy[Deploy via CloudFormation\/ECS\/CodeDeploy]:::svc\n  end\n\n  subgraph ProdAccount[Prod Account]\n    Approval[Manual Approval]:::gate\n    ProdDeploy[Deploy via CloudFormation\/ECS\/CodeDeploy]:::svc\n    Obs[CloudWatch\/Logs\/X-Ray]:::svc\n  end\n\n  CP --&gt; Sec --&gt; Tests --&gt; DevDeploy --&gt; Approval --&gt; ProdDeploy --&gt; Obs\n\n  classDef svc fill:#eef,stroke:#336,stroke-width:1px;\n  classDef gate fill:#ffe,stroke:#aa6,stroke-width:1px;\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>Ability to create IAM roles, S3 buckets, and CodePipeline pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions\/IAM<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Create and manage <strong>AWS CodePipeline<\/strong> pipelines\n&#8211; Create and manage <strong>Amazon S3<\/strong> buckets and policies (for artifact store and deploy target)\n&#8211; Create and pass <strong>IAM roles<\/strong> used by CodePipeline actions (the console wizard can create roles for you if permitted)\n&#8211; Create <strong>AWS CodeConnections<\/strong> connection (if using GitHub as source)<\/p>\n\n\n\n<p>A practical approach for a lab:\n&#8211; Use an admin-capable role in a sandbox account.\n&#8211; For production, apply least privilege and segregation of duties.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>For the hands-on tutorial, install:\n&#8211; <strong>AWS CLI v2<\/strong>: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html\n&#8211; <strong>Git<\/strong> (if using GitHub): https:\/\/git-scm.com\/downloads<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure AWS CodePipeline is available in your chosen AWS Region.<\/li>\n<li>If your deploy target or source integration has regional constraints, <strong>verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>AWS CodePipeline and integrated services have quotas (for example, limits on pipelines, stages\/actions per pipeline, concurrent executions, artifact sizes). Review:\n&#8211; AWS CodePipeline quotas: https:\/\/docs.aws.amazon.com\/codepipeline\/latest\/userguide\/limits.html (verify current URL\/section in docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the lab in this guide:\n&#8211; Amazon S3 (artifact store + deploy bucket)\n&#8211; GitHub account (or GitHub organization access) if using GitHub source\n&#8211; AWS CodeConnections connection to GitHub (created in the AWS console during pipeline setup)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how charges work)<\/h3>\n\n\n\n<p>AWS CodePipeline pricing is <strong>usage-based<\/strong>, and the exact dimensions can evolve over time. In general, your costs typically include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CodePipeline charges<\/strong> (commonly based on the number of active pipelines and\/or execution activity\u2014<strong>verify the current pricing dimensions and rates<\/strong>)<\/li>\n<li><strong>Amazon S3<\/strong> costs for artifact storage and requests (PUT\/GET\/LIST)<\/li>\n<li><strong>KMS<\/strong> costs if you use customer-managed keys for artifact encryption<\/li>\n<li>Costs for any integrated services:<\/li>\n<li><strong>CodeBuild<\/strong> build minutes and compute type<\/li>\n<li><strong>CodeDeploy<\/strong> (pricing depends on compute platform and configuration\u2014verify)<\/li>\n<li><strong>CloudFormation<\/strong> is generally not charged directly, but it provisions billable resources<\/li>\n<li><strong>EventBridge<\/strong>, <strong>SNS<\/strong>, <strong>CloudWatch<\/strong>, and any third-party tools used<\/li>\n<\/ul>\n\n\n\n<p>Official pricing:\n&#8211; AWS CodePipeline pricing: https:\/\/aws.amazon.com\/codepipeline\/pricing\/\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<blockquote>\n<p>Important: Do not rely on blog posts or old examples for exact figures. <strong>Always confirm current pricing on the official pricing page<\/strong> and validate in the AWS Billing console.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>AWS offerings sometimes include free tiers or limited free usage. For AWS CodePipeline, free usage (if any) and its scope can change. <strong>Verify free tier eligibility and scope<\/strong> on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<p>Direct and indirect drivers include:\n&#8211; Number of <strong>pipelines<\/strong> you keep active\n&#8211; Frequency of <strong>pipeline executions<\/strong> (commits, merges, reruns)\n&#8211; Size and number of <strong>artifacts<\/strong> (S3 storage + requests)\n&#8211; Use of <strong>customer-managed KMS keys<\/strong>\n&#8211; Build\/test workloads (CodeBuild minutes; bigger instances cost more)\n&#8211; Multi-account\/multi-region patterns (more pipelines, more artifacts, more data transfer)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data transfer<\/strong>: Cross-region artifact replication or downloads can add costs.<\/li>\n<li><strong>Log ingestion and retention<\/strong>: CloudWatch logs from build\/test tools.<\/li>\n<li><strong>Downstream resources<\/strong>: The pipeline may create\/modify resources that are the main cost center (ECS services, databases, load balancers).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Consolidate pipelines where it makes sense (but don\u2019t sacrifice isolation\/governance).<\/li>\n<li>Reduce unnecessary executions (avoid triggering on docs-only changes if not needed).<\/li>\n<li>Keep artifacts small; clean up large artifacts and old versions where appropriate.<\/li>\n<li>Use S3 lifecycle policies for artifact buckets (retention aligned with audit needs).<\/li>\n<li>Use the smallest practical build compute in CodeBuild, and cache dependencies where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal learning setup often includes:\n&#8211; 1 pipeline\n&#8211; 1 artifact bucket (small artifacts, low traffic)\n&#8211; No build service (source \u2192 deploy only)\n&#8211; Minimal logging\/notifications<\/p>\n\n\n\n<p>Your cost will be dominated by:\n&#8211; CodePipeline baseline charges (if applicable)\n&#8211; S3 storage\/requests (usually small for a simple lab)<\/p>\n\n\n\n<p>Use the AWS Pricing Calculator with:\n&#8211; Your region\n&#8211; Estimated executions per day\/week\n&#8211; Artifact sizes and retention<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs usually come from:\n&#8211; Many pipelines (microservices)\n&#8211; Frequent executions (CI at scale)\n&#8211; Heavy build\/test workloads\n&#8211; Multi-account and multi-region deployment patterns\n&#8211; Logging\/monitoring at enterprise retention<\/p>\n\n\n\n<p>A practical approach:\n&#8211; Create a cost model per application\/team (pipelines + build minutes + artifacts + deploy infrastructure).\n&#8211; Enforce tags on artifact buckets and build projects to allocate cost by owner\/team.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Build a real, low-cost AWS CodePipeline that:\n&#8211; Pulls source from a GitHub repository using an AWS-managed connection\n&#8211; Deploys the repository contents to a private Amazon S3 bucket\n&#8211; Verifies the deployment by generating a pre-signed URL to view the deployed <code>index.html<\/code>\n&#8211; Includes a manual approval gate to demonstrate controlled promotion<\/p>\n\n\n\n<p>This lab avoids build tools (like CodeBuild) so you don\u2019t need build specifications, and it keeps the S3 bucket private to reduce exposure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:\n&#8211; A GitHub repository with a simple static web page (<code>index.html<\/code>)\n&#8211; An S3 bucket to receive the deployed files (private)\n&#8211; An AWS CodePipeline with stages:\n  1. <strong>Source<\/strong> (GitHub via AWS connection)\n  2. <strong>Approve<\/strong> (manual approval)\n  3. <strong>Deploy<\/strong> (Amazon S3 deploy action, extract files)<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; When you push a change to GitHub, the pipeline runs.\n&#8211; After you approve, the updated content is deployed to S3.\n&#8211; You can open the deployed page via a pre-signed URL.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a region and set up AWS CLI credentials<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Pick an AWS Region (example: <code>us-east-1<\/code>) where you will build the pipeline.<\/li>\n<li>Configure AWS CLI:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws configure\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Confirm identity:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see your AWS account and principal ARN.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a GitHub repository with a simple web page<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In GitHub, create a new repository (example name: <code>codepipeline-s3-lab<\/code>).<\/li>\n<li>Clone it locally:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">git clone https:\/\/github.com\/&lt;YOUR_GITHUB_USER_OR_ORG&gt;\/codepipeline-s3-lab.git\ncd codepipeline-s3-lab\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Create <code>index.html<\/code>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; index.html &lt;&lt; 'EOF'\n&lt;!doctype html&gt;\n&lt;html&gt;\n  &lt;head&gt;\n    &lt;meta charset=\"utf-8\"&gt;\n    &lt;title&gt;AWS CodePipeline Lab&lt;\/title&gt;\n  &lt;\/head&gt;\n  &lt;body&gt;\n    &lt;h1&gt;Deployed by AWS CodePipeline&lt;\/h1&gt;\n    &lt;p&gt;If you can read this, the S3 deploy action worked.&lt;\/p&gt;\n  &lt;\/body&gt;\n&lt;\/html&gt;\nEOF\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li>Commit and push:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">git add index.html\ngit commit -m \"Add initial index.html\"\ngit push origin main\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The repository has a <code>main<\/code> branch with <code>index.html<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create the S3 deploy bucket (private)<\/h3>\n\n\n\n<p>Create a globally unique bucket name. Replace placeholders:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"\nexport DEPLOY_BUCKET=\"cp-s3-deploy-$(aws sts get-caller-identity --query Account --output text)-$AWS_REGION\"\naws s3api create-bucket --bucket \"$DEPLOY_BUCKET\" --region \"$AWS_REGION\" \\\n  $( [ \"$AWS_REGION\" = \"us-east-1\" ] &amp;&amp; echo \"\" || echo \"--create-bucket-configuration LocationConstraint=$AWS_REGION\" )\n<\/code><\/pre>\n\n\n\n<p>Enable bucket versioning (recommended for rollback and audit):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-bucket-versioning --bucket \"$DEPLOY_BUCKET\" \\\n  --versioning-configuration Status=Enabled\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A private S3 bucket exists and has versioning enabled.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an AWS CodeConnections connection to GitHub (console)<\/h3>\n\n\n\n<p>This step is easiest in the AWS console because it requires an OAuth-based authorization flow.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the AWS console for your chosen region.<\/li>\n<li>Go to <strong>Developer Tools<\/strong> \u2192 <strong>Connections<\/strong> (you may see it referenced as AWS CodeConnections).<\/li>\n<li>Create a new connection:\n   &#8211; Provider: <strong>GitHub<\/strong>\n   &#8211; Connection name: <code>github-connection-codepipeline-lab<\/code><\/li>\n<li>Follow the prompts to authorize AWS with GitHub and select the repository\/org access.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Connection status shows as <strong>Available<\/strong> (or similar).<\/p>\n\n\n\n<p>If the connection does not become available, see the <strong>Troubleshooting<\/strong> section.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create the pipeline (console)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <strong>AWS CodePipeline<\/strong> in the AWS console (same region).<\/li>\n<li>Choose <strong>Create pipeline<\/strong>.<\/li>\n<li>\n<p>Pipeline settings:\n   &#8211; <strong>Pipeline name<\/strong>: <code>codepipeline-s3-deploy-lab<\/code>\n   &#8211; <strong>Service role<\/strong>: Choose the option to let CodePipeline create a new service role (good for labs).\n   &#8211; <strong>Artifact store<\/strong>: Choose default (CodePipeline will use an S3 bucket it manages\/creates) or select a dedicated bucket if your org requires it.<\/p>\n<\/li>\n<li>\n<p><strong>Source stage<\/strong>:\n   &#8211; Source provider: <strong>GitHub (via connection)<\/strong> (wording may vary)\n   &#8211; Connection: select <code>github-connection-codepipeline-lab<\/code>\n   &#8211; Repository name: select your repo\n   &#8211; Branch name: <code>main<\/code>\n   &#8211; Change detection: keep the default offered by the console for your provider<\/p>\n<\/li>\n<li>\n<p>Add an <strong>Approval stage<\/strong>:\n   &#8211; Choose <strong>Add stage<\/strong>\n   &#8211; Stage name: <code>Approve<\/code>\n   &#8211; Action provider: <strong>Manual approval<\/strong>\n   &#8211; (Optional) Configure notification if offered<\/p>\n<\/li>\n<li>\n<p><strong>Deploy stage<\/strong>:\n   &#8211; Deploy provider: <strong>Amazon S3<\/strong>\n   &#8211; Bucket: select your deploy bucket (<code>$DEPLOY_BUCKET<\/code>)\n   &#8211; Extract file before deploy: <strong>Yes<\/strong>\n   &#8211; Input artifact: should be the output from the source stage (auto-selected)<\/p>\n<\/li>\n<li>\n<p>Create the pipeline.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: The pipeline is created and may immediately start its first execution.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Approve and observe the deployment<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the pipeline execution view, wait for the Source stage to succeed.<\/li>\n<li>The pipeline will pause at the manual approval action.<\/li>\n<li>Choose <strong>Review<\/strong> \u2192 <strong>Approve<\/strong>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>:\n&#8211; Approval stage becomes <strong>Succeeded<\/strong>\n&#8211; Deploy stage runs and then becomes <strong>Succeeded<\/strong>\n&#8211; Objects appear in the S3 bucket, including <code>index.html<\/code><\/p>\n\n\n\n<p>Verify objects were deployed:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3 ls \"s3:\/\/$DEPLOY_BUCKET\" --recursive\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Validate the deployed content with a pre-signed URL<\/h3>\n\n\n\n<p>Generate a temporary URL for the deployed <code>index.html<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3 presign \"s3:\/\/$DEPLOY_BUCKET\/index.html\" --expires-in 3600\n<\/code><\/pre>\n\n\n\n<p>Copy the URL into a browser.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see the page title \u201cAWS CodePipeline Lab\u201d and the heading \u201cDeployed by AWS CodePipeline\u201d.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Make a change and watch the pipeline run again<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Update the page locally:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">sed -i.bak 's\/If you can read this, the S3 deploy action worked.\/Update successful: deployed a new version via AWS CodePipeline.\/' index.html\nrm -f index.html.bak\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Commit and push:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">git add index.html\ngit commit -m \"Update index text\"\ngit push origin main\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Return to the CodePipeline console and watch a new execution start.<\/li>\n<li>Approve again when it pauses.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: After deploy, generating a new pre-signed URL shows the updated text.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pipeline shows <strong>Succeeded<\/strong> for Source \u2192 Approve \u2192 Deploy stages.<\/li>\n<li>S3 bucket contains <code>index.html<\/code>.<\/li>\n<li>A pre-signed URL for <code>index.html<\/code> loads successfully in your browser.<\/li>\n<li>A new commit triggers a new pipeline execution.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Connection to GitHub is not \u201cAvailable\u201d<\/h4>\n\n\n\n<p>Common fixes:\n&#8211; Ensure you completed the OAuth authorization in GitHub.\n&#8211; Confirm the GitHub account\/organization allows the AWS app\/connection.\n&#8211; If using a GitHub organization with restrictions, an org admin may need to approve the app.\n&#8211; Recreate the connection if it is stuck in a pending state.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Deploy action fails with AccessDenied to S3<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm the deploy bucket name is correct.<\/li>\n<li>If you used an existing bucket with restrictive policies, the auto-created CodePipeline role might not have access.<\/li>\n<li>In a lab, the fastest fix is to:<\/li>\n<li>Use a new bucket created specifically for this pipeline, and<\/li>\n<li>Let the console create the pipeline role<\/li>\n<li>For production, implement a least-privilege bucket policy and IAM role permissions (review in your security process).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Pipeline doesn\u2019t trigger on push<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm the pipeline source branch matches (<code>main<\/code> vs <code>master<\/code>).<\/li>\n<li>Confirm change detection settings in the source action.<\/li>\n<li>Some providers require webhook configuration behind the scenes; ensure the connection is healthy.<\/li>\n<li>As a quick test, use <strong>Release change<\/strong> (or equivalent) in the console to manually start an execution.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Pre-signed URL returns AccessDenied<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure the object exists at <code>s3:\/\/bucket\/index.html<\/code>.<\/li>\n<li>Generate a new pre-signed URL (they expire).<\/li>\n<li>Confirm your AWS principal has <code>s3:GetObject<\/code> permission for that bucket\/object.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs and clutter:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Delete the pipeline:\n   &#8211; CodePipeline console \u2192 select pipeline \u2192 <strong>Delete<\/strong><\/p>\n<\/li>\n<li>\n<p>Empty and delete the S3 deploy bucket:<\/p>\n<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws s3 rm \"s3:\/\/$DEPLOY_BUCKET\" --recursive\naws s3api delete-bucket --bucket \"$DEPLOY_BUCKET\" --region \"$AWS_REGION\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>\n<p>Delete the AWS CodeConnections connection:\n   &#8211; Developer Tools \u2192 Connections \u2192 select connection \u2192 delete<\/p>\n<\/li>\n<li>\n<p>(Optional) Delete the GitHub repository if it was created only for this lab.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate orchestration from execution<\/strong>: Use CodePipeline to orchestrate, and specialized services (CodeBuild\/CloudFormation\/CodeDeploy) to do the work.<\/li>\n<li><strong>Promote the same artifact<\/strong>: Build once, then deploy the same immutable artifact to dev\/staging\/prod to reduce drift.<\/li>\n<li><strong>Use multi-account deployments<\/strong> for strong isolation (tooling account + environment accounts).<\/li>\n<li><strong>Design for rollback<\/strong>:<\/li>\n<li>Keep previous artifacts available (S3 versioning \/ artifact retention).<\/li>\n<li>Use deployment strategies that support rollback (blue\/green, traffic shifting) where applicable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>least privilege<\/strong> roles for pipelines and actions.<\/li>\n<li>Use <strong>separate roles per environment<\/strong> (dev vs prod) and limit who can approve prod.<\/li>\n<li>Restrict who can <strong>edit pipeline definitions<\/strong> vs who can <strong>start runs<\/strong> vs who can <strong>approve<\/strong>.<\/li>\n<li>Use <strong>permission boundaries<\/strong> or SCPs (AWS Organizations) in larger orgs.<\/li>\n<li>Encrypt artifacts with <strong>KMS<\/strong> (customer-managed keys when required by policy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce unnecessary executions (filter changes where possible; avoid redundant pipelines).<\/li>\n<li>Use S3 lifecycle policies for artifact buckets (aligned with audit requirements).<\/li>\n<li>Keep build\/test steps efficient (if using CodeBuild): caching, smaller compute, parallelism where meaningful.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Parallelize independent tests\/actions.<\/li>\n<li>Keep artifacts small and focused (don\u2019t package large unnecessary files).<\/li>\n<li>Avoid over-serializing deployments when they can be safely parallelized (with guardrails).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add clear stage boundaries and fast feedback (lint\/unit tests early).<\/li>\n<li>Use manual approvals only for meaningful gates (prod or risky changes).<\/li>\n<li>Emit pipeline events to your incident\/notification tooling for fast awareness.<\/li>\n<li>Regularly test failure modes: failed deploy, rollback, permissions changes, missing artifacts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize naming:<\/li>\n<li><code>app-env-pipeline<\/code> (example: <code>payments-prod-pipeline<\/code>)<\/li>\n<li>Stage names consistent across teams (Source\/Build\/Test\/Deploy)<\/li>\n<li>Tag resources (where supported): application, environment, owner, cost center.<\/li>\n<li>Establish runbooks for:<\/li>\n<li>Approvals<\/li>\n<li>Failed deployments<\/li>\n<li>Pipeline permission issues<\/li>\n<li>Artifact encryption\/key rotation impacts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent tags across:<\/li>\n<li>S3 artifact buckets<\/li>\n<li>KMS keys<\/li>\n<li>Build projects and deploy resources<\/li>\n<li>Store pipeline definitions and IaC templates in version control when possible.<\/li>\n<li>Apply org-wide policies for:<\/li>\n<li>Mandatory encryption<\/li>\n<li>Restricted public access<\/li>\n<li>Approved source providers<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM principals (users\/roles)<\/strong> control who can:<\/li>\n<li>Create\/update\/delete pipelines<\/li>\n<li>Start pipeline executions<\/li>\n<li>Approve manual approval actions<\/li>\n<li>View artifacts\/logs<\/li>\n<li><strong>Pipeline service roles<\/strong> determine what the pipeline can do to AWS resources.<\/li>\n<\/ul>\n\n\n\n<p>Recommendations:\n&#8211; Separate duties:\n  &#8211; Developers can trigger dev deployments\n  &#8211; Release managers\/ops approve prod\n&#8211; Use AWS Organizations SCPs to prevent pipelines from deploying to unauthorized accounts\/regions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>S3 artifact stores<\/strong> should be encrypted.<\/li>\n<li>Use <strong>SSE-KMS<\/strong> with a customer-managed KMS key when compliance requires it.<\/li>\n<li>Ensure KMS key policies allow:<\/li>\n<li>CodePipeline role usage<\/li>\n<li>Any cross-account roles (if applicable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS CodePipeline is managed; your main exposure risk is in:<\/li>\n<li>Publicly accessible artifact\/deploy buckets<\/li>\n<li>Build services running in public subnets<\/li>\n<li>Prefer private buckets and controlled access patterns (pre-signed URLs for validation; CloudFront with private origin access for production hosting).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store secrets in source repos or plaintext artifacts.<\/li>\n<li>Use dedicated secret stores (for example, AWS Secrets Manager or SSM Parameter Store) and fetch secrets at runtime in build\/deploy steps.<\/li>\n<li>Ensure pipeline logs do not print secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudTrail (and ideally organization trails) to log:<\/li>\n<li>Pipeline creation\/modification<\/li>\n<li>Approval actions<\/li>\n<li>IAM role changes that could affect deployments<\/li>\n<li>Route events to centralized monitoring using EventBridge.<\/li>\n<li>Retain logs based on compliance requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>AWS CodePipeline can support compliance objectives by:\n&#8211; Providing standardized release processes\n&#8211; Capturing execution history\n&#8211; Integrating approvals<\/p>\n\n\n\n<p>However, compliance depends on how you configure the full delivery system:\n&#8211; Who can approve?\n&#8211; Are artifacts immutable?\n&#8211; Are environments isolated?\n&#8211; Are logs retained and protected?<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overly permissive pipeline IAM roles (wildcard admin access)<\/li>\n<li>Public artifact buckets<\/li>\n<li>Not encrypting artifacts with KMS where required<\/li>\n<li>No separation between dev and prod accounts<\/li>\n<li>No audit trail for approvals and pipeline edits<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use multi-account environments with strong role boundaries.<\/li>\n<li>Encrypt artifacts and enforce bucket policies that deny unencrypted uploads (where appropriate).<\/li>\n<li>Require approvals for production, and restrict approvers by IAM conditions\/groups.<\/li>\n<li>Continuously review IAM access for pipeline editing and role passing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Limits and behavior can change; always confirm with the latest AWS documentation and quotas for your region and account.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maximum numbers for pipelines, stages, actions, and concurrent executions (service quotas apply).<\/li>\n<li>Artifact size and action-specific constraints (for example, what an action provider can consume\/produce).<\/li>\n<li>Some advanced workflow patterns (dynamic graphs) are not native; you may need custom orchestration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pipelines are created in a region; cross-region deployments require careful setup.<\/li>\n<li>Some integrations or action providers may have region-specific availability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Costs are often driven more by:<\/li>\n<li>Build minutes (if using CodeBuild)<\/li>\n<li>Artifact storage and request rates (S3)<\/li>\n<li>Logging and retention (CloudWatch)<\/li>\n<li>Multi-region and high-frequency pipelines can increase S3 requests\/data transfer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source provider integration behavior differs (GitHub vs S3 vs other providers).<\/li>\n<li>Branch naming (<code>main<\/code> vs <code>master<\/code>) mismatches frequently cause \u201cno trigger\u201d confusion.<\/li>\n<li>Cross-account IAM trust\/policies are a common failure point.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you disable a stage transition, executions will pause and queue behind it.<\/li>\n<li>Manual approvals can stall deployments; assign clear on-call ownership.<\/li>\n<li>Artifact encryption with KMS can fail if key policies or grants are misconfigured.<\/li>\n<li>Reusing artifact buckets across many pipelines can complicate permissions and cost allocation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from Jenkins\/GitHub Actions to CodePipeline may require:<\/li>\n<li>Rewriting deployment logic into AWS-native actions or CodeBuild projects<\/li>\n<li>Redesigning secrets and IAM boundaries<\/li>\n<li>Adjusting governance and audit workflows<\/li>\n<li>Moving across accounts\/regions requires careful recreation of roles, KMS keys, and bucket policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CodePipeline is optimized for AWS-centric delivery. If most targets are outside AWS, consider whether a different CI\/CD orchestrator is a better fit.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS-native alternatives and adjacent services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CodeBuild<\/strong>: Build\/test execution service; not a pipeline orchestrator.<\/li>\n<li><strong>AWS CodeDeploy<\/strong>: Deployment orchestrator; not a full CI\/CD pipeline.<\/li>\n<li><strong>AWS CodeCatalyst<\/strong>: An integrated DevOps service (space\/project-centric). Fit depends on your org\u2019s workflow and service availability. <strong>Verify current capabilities and regional availability<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure DevOps Pipelines<\/strong>: Strong end-to-end CI\/CD and work item integration for Azure and multi-cloud.<\/li>\n<li><strong>Google Cloud Build \/ Cloud Deploy<\/strong>: CI build execution plus deployment orchestration in GCP.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Jenkins<\/strong> (self-managed): Very flexible; higher ops overhead.<\/li>\n<li><strong>GitHub Actions<\/strong>: Great if GitHub-centric; can deploy to AWS with OIDC and actions.<\/li>\n<li><strong>GitLab CI\/CD<\/strong>: Strong integrated SCM+CI\/CD platform; self-managed or SaaS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>AWS CodePipeline<\/td>\n<td>AWS-centric CI\/CD orchestration<\/td>\n<td>Managed pipelines, AWS integrations, auditability<\/td>\n<td>Orchestration only; advanced workflow modeling may need workarounds<\/td>\n<td>You deploy primarily to AWS and want managed orchestration<\/td>\n<\/tr>\n<tr>\n<td>AWS CodeBuild<\/td>\n<td>Builds\/tests<\/td>\n<td>Managed build runners, scalable<\/td>\n<td>Not orchestration; needs pipeline\/orchestrator<\/td>\n<td>You need build execution as a component in CI\/CD<\/td>\n<\/tr>\n<tr>\n<td>AWS CodeDeploy<\/td>\n<td>Deployments<\/td>\n<td>Deployment strategies, rollback patterns (platform-dependent)<\/td>\n<td>Not full CI\/CD; requires upstream orchestration<\/td>\n<td>You need controlled deployments to compute targets<\/td>\n<\/tr>\n<tr>\n<td>AWS CodeCatalyst<\/td>\n<td>Integrated DevOps experience<\/td>\n<td>Project-centric tooling, integrated workflows<\/td>\n<td>Fit\/availability varies; may not match existing enterprise patterns<\/td>\n<td>New teams wanting an integrated AWS DevOps suite (verify current scope)<\/td>\n<\/tr>\n<tr>\n<td>GitHub Actions<\/td>\n<td>GitHub-native CI\/CD<\/td>\n<td>Close to code, huge marketplace, flexible<\/td>\n<td>Governance at scale can be complex; runners and secrets management need design<\/td>\n<td>You are standardized on GitHub and want CI\/CD near repos<\/td>\n<\/tr>\n<tr>\n<td>Jenkins (self-managed)<\/td>\n<td>Maximum customization<\/td>\n<td>Extremely flexible, plugin ecosystem<\/td>\n<td>High ops\/security burden, upgrades, plugin risk<\/td>\n<td>You need deep customization and accept ops overhead<\/td>\n<\/tr>\n<tr>\n<td>Azure DevOps Pipelines<\/td>\n<td>Microsoft ecosystem and enterprise CI\/CD<\/td>\n<td>Strong enterprise features, boards\/test plans<\/td>\n<td>Heavier platform; best fit often with Azure<\/td>\n<td>You are in Microsoft\/Azure ecosystem or need its suite<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated, multi-account)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A financial services company must deploy a customer-facing API with strict separation between environments, approvals, and audit trails.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Tooling account hosts AWS CodePipeline and artifact store (S3 + KMS).<\/li>\n<li>Source from enterprise Git provider via AWS-managed connection.<\/li>\n<li>Build and test actions run in isolated build projects (for example, CodeBuild) with no public internet, using VPC endpoints.<\/li>\n<li>Deploy to dev and staging accounts automatically.<\/li>\n<li>Manual approval required for production.<\/li>\n<li>Production deploy uses infrastructure-as-code and a deployment strategy supporting rollback.<\/li>\n<li>CloudTrail organization trail + EventBridge notifications to SOC tooling.<\/li>\n<li><strong>Why AWS CodePipeline was chosen<\/strong>:<\/li>\n<li>AWS-native orchestration with strong IAM and audit integration.<\/li>\n<li>Cross-account patterns support environment isolation.<\/li>\n<li>Clear execution history for audit.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced deployment lead time with consistent controls.<\/li>\n<li>Improved auditability (who approved what, and when).<\/li>\n<li>Lower change failure rate due to standardized, test-gated promotions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (fast iteration, minimal ops)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small SaaS team needs automated deployments for a static landing page and a simple backend, without managing CI servers.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>AWS CodePipeline with GitHub source.<\/li>\n<li>Simple deployments: static content to S3; backend deployed via infrastructure templates or lightweight automation.<\/li>\n<li>Notifications routed to email\/chat for failures.<\/li>\n<li><strong>Why AWS CodePipeline was chosen<\/strong>:<\/li>\n<li>Managed service; minimal operational overhead.<\/li>\n<li>Quick to implement using console wizards.<\/li>\n<li>Clear release visibility for a small team.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster releases with fewer manual steps.<\/li>\n<li>Easier onboarding (pipeline shows the delivery process).<\/li>\n<li>Predictable deployments and quick troubleshooting.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is AWS CodePipeline a CI tool or a CD tool?<\/strong><br\/>\nAWS CodePipeline is primarily a <strong>CI\/CD orchestration<\/strong> tool. It coordinates steps. CI work (build\/test) is usually done by services like AWS CodeBuild or other tools, and CD work (deployments) is done by services like AWS CodeDeploy, CloudFormation, ECS, or custom automation.<\/p>\n\n\n\n<p>2) <strong>Where are CodePipeline artifacts stored?<\/strong><br\/>\nTypically in <strong>Amazon S3<\/strong> in an artifact store bucket. You can usually configure encryption (including KMS) and retention using S3 features.<\/p>\n\n\n\n<p>3) <strong>Can CodePipeline deploy to multiple AWS accounts?<\/strong><br\/>\nYes, using <strong>cross-account IAM roles<\/strong> and trusted relationships. This is a common enterprise pattern for dev\/staging\/prod isolation.<\/p>\n\n\n\n<p>4) <strong>Can CodePipeline deploy to multiple regions?<\/strong><br\/>\nOften yes, but cross-region deployments require careful configuration (for example, additional artifact stores and encryption considerations). <strong>Verify cross-region support for your action types<\/strong>.<\/p>\n\n\n\n<p>5) <strong>Does CodePipeline support manual approvals?<\/strong><br\/>\nYes. Manual approval actions can pause the pipeline until an authorized user approves.<\/p>\n\n\n\n<p>6) <strong>Can I run security scans in CodePipeline?<\/strong><br\/>\nYes, by integrating scanning tools via build actions, partner actions, or custom automation. The pipeline can gate deployments based on scan results.<\/p>\n\n\n\n<p>7) <strong>How do I get notifications when a pipeline fails?<\/strong><br\/>\nUse <strong>EventBridge<\/strong> pipeline state change events and route them to SNS, chat integrations, ticketing, or incident systems.<\/p>\n\n\n\n<p>8) <strong>How does CodePipeline authenticate to GitHub?<\/strong><br\/>\nTypically via an AWS-managed connection service (commonly referred to as AWS CodeConnections in newer AWS materials). The connection is authorized through a GitHub OAuth or app authorization flow.<\/p>\n\n\n\n<p>9) <strong>Can CodePipeline run on a schedule?<\/strong><br\/>\nCodePipeline is usually event-driven. For scheduled runs, a common pattern is an <strong>EventBridge schedule<\/strong> that triggers an action (for example, calling the StartPipelineExecution API). <strong>Verify the latest recommended approach<\/strong> in AWS docs.<\/p>\n\n\n\n<p>10) <strong>What\u2019s the difference between CodePipeline and CodeDeploy?<\/strong><br\/>\nCodePipeline orchestrates the whole workflow. CodeDeploy focuses specifically on deployment strategies and lifecycle hooks for certain compute platforms.<\/p>\n\n\n\n<p>11) <strong>How do I implement \u201cbuild once, deploy many\u201d?<\/strong><br\/>\nProduce a versioned artifact in a build stage (for example with CodeBuild), store it, then deploy the same artifact to dev\/staging\/prod stages. Ensure your pipeline passes the same artifact forward rather than rebuilding.<\/p>\n\n\n\n<p>12) <strong>Can I use CodePipeline with Infrastructure as Code?<\/strong><br\/>\nYes. Common patterns include deploying CloudFormation stacks, generating and reviewing change sets, and gating execution with approvals.<\/p>\n\n\n\n<p>13) <strong>Does CodePipeline support environment variables or parameters?<\/strong><br\/>\nCodePipeline has mechanisms for passing information between actions (often via action configuration and variables). Exact capabilities can vary by pipeline type and action provider. <strong>Verify current variable support in the official docs<\/strong>.<\/p>\n\n\n\n<p>14) <strong>How do I restrict who can approve production?<\/strong><br\/>\nUse IAM to restrict access to the approval action and separate roles\/groups for production approvers. Consider AWS Organizations SCPs for additional guardrails.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the most common cause of pipeline failures?<\/strong><br\/>\nIAM permission issues, misconfigured artifact buckets\/KMS keys, source connection problems, and downstream deployment failures are common. Start troubleshooting by identifying which stage\/action failed and reviewing associated logs\/events.<\/p>\n\n\n\n<p>16) <strong>Should I use one pipeline per microservice?<\/strong><br\/>\nOften yes for independence, but it depends on governance and cost. Some teams use one pipeline per service; others use consolidated pipelines for closely coupled components.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS CodePipeline<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS CodePipeline User Guide \u2014 https:\/\/docs.aws.amazon.com\/codepipeline\/<\/td>\n<td>Authoritative reference for concepts, action providers, security, and configuration<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>AWS CodePipeline Pricing \u2014 https:\/\/aws.amazon.com\/codepipeline\/pricing\/<\/td>\n<td>Current pricing dimensions and rates (verify by region)<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>AWS Pricing Calculator \u2014 https:\/\/calculator.aws\/#\/<\/td>\n<td>Build estimates for pipelines plus downstream services (S3, KMS, CodeBuild, etc.)<\/td>\n<\/tr>\n<tr>\n<td>Official getting started<\/td>\n<td>AWS CodePipeline Getting Started (in docs) \u2014 https:\/\/docs.aws.amazon.com\/codepipeline\/latest\/userguide\/getting-started-codepipeline.html<\/td>\n<td>Step-by-step onboarding paths and foundational patterns<\/td>\n<\/tr>\n<tr>\n<td>Official limits\/quotas<\/td>\n<td>CodePipeline Limits \u2014 https:\/\/docs.aws.amazon.com\/codepipeline\/latest\/userguide\/limits.html<\/td>\n<td>Understand quotas and design around them<\/td>\n<\/tr>\n<tr>\n<td>Official security<\/td>\n<td>Security in AWS CodePipeline \u2014 https:\/\/docs.aws.amazon.com\/codepipeline\/latest\/userguide\/security.html<\/td>\n<td>IAM, encryption, and audit guidance<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Architecture Center \u2014 https:\/\/aws.amazon.com\/architecture\/<\/td>\n<td>Patterns for multi-account, CI\/CD, and governance<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>AWS YouTube Channel \u2014 https:\/\/www.youtube.com\/@amazonwebservices<\/td>\n<td>Many CI\/CD and DevOps sessions and demos (search for \u201cCodePipeline\u201d)<\/td>\n<\/tr>\n<tr>\n<td>Samples (AWS)<\/td>\n<td>AWS Samples on GitHub \u2014 https:\/\/github.com\/aws-samples<\/td>\n<td>Practical examples; search for \u201ccodepipeline\u201d repositories<\/td>\n<\/tr>\n<tr>\n<td>Trusted learning<\/td>\n<td>AWS Workshops \u2014 https:\/\/workshops.aws\/<\/td>\n<td>Hands-on labs for AWS services; look for CI\/CD workshops<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to working DevOps engineers<\/td>\n<td>CI\/CD pipelines, AWS Developer Tools, DevOps practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Developers, build\/release engineers<\/td>\n<td>Source control, CI\/CD fundamentals, tooling practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers, operations teams<\/td>\n<td>Cloud operations, automation, AWS operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform teams, reliability engineers<\/td>\n<td>SRE practices, automation, release reliability<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring automation<\/td>\n<td>AIOps concepts, monitoring\/automation workflows<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/Cloud training content (verify specific offerings)<\/td>\n<td>Students to professionals<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify scope)<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training (verify services)<\/td>\n<td>Teams needing practical guidance<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and learning resources (verify scope)<\/td>\n<td>Engineers needing hands-on support<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify offerings)<\/td>\n<td>CI\/CD implementation, cloud automation, operational practices<\/td>\n<td>Standardizing pipelines across teams; improving deployment reliability<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement (verify offerings)<\/td>\n<td>DevOps transformation, tooling adoption, training + implementation<\/td>\n<td>Setting up AWS CodePipeline reference architectures; platform enablement<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify offerings)<\/td>\n<td>CI\/CD, automation, release governance<\/td>\n<td>Building multi-account deployment pipelines; governance and approvals<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS CodePipeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Git fundamentals: branching, pull requests, tags, releases<\/li>\n<li>CI\/CD basics: build vs deploy, artifacts, environments, promotion<\/li>\n<li>AWS IAM essentials: roles, policies, trust relationships, least privilege<\/li>\n<li>Amazon S3 basics: buckets, objects, encryption, versioning<\/li>\n<li>Basic AWS networking concepts (VPC, endpoints) for production pipelines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS CodePipeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS CodeBuild for builds\/tests (and how to secure builds in VPCs)<\/li>\n<li>AWS CodeDeploy or deployment strategies for your runtime (ECS\/Lambda\/EC2)<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>AWS CloudFormation and\/or AWS CDK<\/li>\n<li>Observability and operations:<\/li>\n<li>EventBridge event routing<\/li>\n<li>CloudTrail auditing strategies<\/li>\n<li>CloudWatch alarms and centralized logging<\/li>\n<li>Multi-account governance:<\/li>\n<li>AWS Organizations, SCPs, centralized security accounts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Cloud Engineer<\/li>\n<li>Release\/Build Engineer<\/li>\n<li>Solutions Architect (implementation-focused)<\/li>\n<li>Security Engineer (DevSecOps pipelines and governance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications don\u2019t certify a single service, but CodePipeline is commonly relevant to:\n&#8211; AWS Certified DevOps Engineer \u2013 Professional (covers CI\/CD and operations patterns)\n&#8211; AWS Certified Developer \u2013 Associate (development and deployment basics)\n&#8211; AWS Certified Solutions Architect \u2013 Associate\/Professional (architecture and governance patterns)<\/p>\n\n\n\n<p>Always confirm the current exam guides and domains:\n&#8211; https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add a test stage (using a build service) and fail the pipeline on test failures.<\/li>\n<li>Implement multi-environment promotion (dev \u2192 staging \u2192 prod) with approvals.<\/li>\n<li>Add security scanning and enforce \u201cno critical findings\u201d gates.<\/li>\n<li>Create a multi-account pipeline deploying to isolated accounts.<\/li>\n<li>Send pipeline events to a notification channel and create an ops runbook.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Action<\/strong>: A single task in a pipeline stage (build, deploy, approve, invoke).<\/li>\n<li><strong>Artifact<\/strong>: A file bundle passed between actions (source ZIP, build output, templates).<\/li>\n<li><strong>Artifact store<\/strong>: The storage location (typically S3) where pipeline artifacts are kept.<\/li>\n<li><strong>CI\/CD<\/strong>: Continuous Integration \/ Continuous Delivery (or Deployment).<\/li>\n<li><strong>Connection (AWS-managed)<\/strong>: A managed integration that lets AWS services access third-party repos like GitHub (often referred to as AWS CodeConnections in newer AWS materials).<\/li>\n<li><strong>Cross-account<\/strong>: Deploying or operating resources across multiple AWS accounts using IAM role assumption.<\/li>\n<li><strong>Execution<\/strong>: A single run of the pipeline.<\/li>\n<li><strong>IAM role<\/strong>: An AWS identity that grants permissions; pipelines use roles to call AWS APIs.<\/li>\n<li><strong>KMS<\/strong>: AWS Key Management Service, used for encryption keys (for example, S3 SSE-KMS).<\/li>\n<li><strong>Manual approval<\/strong>: A pipeline action that pauses execution until a human approves.<\/li>\n<li><strong>Pipeline<\/strong>: The overall release workflow definition.<\/li>\n<li><strong>Stage<\/strong>: A logical grouping of actions (Source\/Build\/Test\/Deploy).<\/li>\n<li><strong>Transition<\/strong>: The movement from one stage to the next; can be disabled to pause flow.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS CodePipeline is AWS\u2019s managed CI\/CD orchestration service in the <strong>Developer tools<\/strong> category. It helps teams automate and govern releases by defining pipelines made of stages and actions, moving artifacts through the workflow, and providing execution visibility and audit-friendly history.<\/p>\n\n\n\n<p>It matters because it reduces manual deployment work, improves consistency, and supports controlled promotion through environments\u2014especially when you combine it with IAM boundaries, encrypted artifact storage, and event-driven operations.<\/p>\n\n\n\n<p>Cost-wise, plan for CodePipeline usage charges (per AWS\u2019s current pricing model) plus the downstream costs that usually dominate in real systems: builds, artifact storage, encryption, logging, and the deployed infrastructure itself. Security-wise, focus on least-privilege IAM roles, artifact encryption (KMS when required), private buckets, and strong audit trails with CloudTrail.<\/p>\n\n\n\n<p>Use AWS CodePipeline when you want AWS-native CI\/CD orchestration with clear governance and integration into AWS deployment targets. Next, deepen your skills by adding build\/test stages, multi-account deployments, and event-driven notifications\u2014then validate your design against the latest AWS documentation and quotas.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Developer tools<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,18],"tags":[],"class_list":["post-200","post","type-post","status-publish","format-standard","hentry","category-aws","category-developer-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/200","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=200"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/200\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}