title	AWS Developer Services: Gold-Standard Console Lab Guide
subtitle	CodeCommit • CodeArtifact • CodeBuild • CodeDeploy • CodePipeline
author	Instructor Edition \| Browser-Only Labs
date	10 November 2026
lang	en-US

Course navigation

Lab	AWS service	Practical result
1	CodeCommit	Create a browser-authored repo, branch, PR and merge
2	CodeArtifact	Configure a private npm repository and public upstream
3	CodeBuild	Resolve dependencies, test, create a deployable ZIP
4	CodeDeploy	Deploy the tested ZIP to AL2023 EC2 without SSH
5	CodePipeline	Automate commit-triggered build and deployment

Instructor’s quick start

Course outcome. Complete five connected, independently verifiable labs that take one small web application from source control through dependency acquisition, automated build and tests, manual deployment, and change-triggered continuous delivery. All user interactions take place in web browsers and the AWS Management Console. Learners never use a terminal, AWS CLI, CloudShell, Session Manager shell, or local Git client. The supplied build and deployment scripts execute automatically inside managed AWS services; they are configuration files, not manual lab commands.

Source starting point. The lab adapts the idea of the official AWS GitHub repository aws-samples/aws-codedeploy-samples, specifically applications/SampleApp_Linux, into an Amazon Linux 2023-friendly static website with a meaningful Node.js build using an npm package from CodeArtifact. Original sample: https://github.com/aws-samples/aws-codedeploy-samples/tree/master/applications/SampleApp_Linux . This manual uses a separately provided AWS_Developer_Services_Console_Lab_Source.zip, whose text files are created in CodeCommit through the browser. The GitHub repository is the provenance/reference; the ZIP is the modernized educational derivative.

Currency and verification disclosure. Research checked AWS’s publicly available CodeCommit, CodeArtifact, CodeBuild, CodeDeploy, Systems Manager and CodePipeline instructions on 10 November 2026. The source tree, JSON, YAML and shell syntax were inspected offline. AWS account-specific execution, current live console screenshots and end-to-end runtime outcomes have not been verified: no access to a training AWS account was provided, and package installation from npm could not be exercised in the authoring environment. AWS can change field labels, Region availability, defaults and wizard ordering. Follow the named AWS documentation links in the final section whenever a screen differs. No simulated screenshots are presented as real console evidence.

Important service status. AWS announced on 24 November 2025 that CodeCommit returned to general availability for new customers. Do not follow older training materials claiming it is closed to new customers. Current CodePipeline documentation uses the Build custom pipeline creation choice and a V2 pipeline experience. [AWS01][AWS02]

Architecture at a glance

GitHub sample (reference)
         |
         v  Copy modernized source files through CodeCommit browser editor
AWS CodeCommit (main)
         |
         +--> CodePipeline Source stage --> CodeBuild Build stage --> CodeDeploy Deploy stage
                                             |                      |
                    AWS CodeArtifact <-------+                      v
                     npm upstream                           Amazon EC2 (AL2023)
                    [lodash 4.17.21]                          Apache web server
                                             |
                               build release ZIP: appspec.yml,
                               index.html, scripts/*

The same release ZIP is first deployed manually from Amazon S3 during Lab 4. Later, CodePipeline passes CodeBuild’s output artifact directly to CodeDeploy in Lab 5; do not deploy the unbuilt CodeCommit source artifact, because index.html contains build-time template placeholders.

Time, cost and prerequisites

Item	Requirement or recommendation
Course duration	4–6 hours instructor-led; 6–8 hours for first-time learners, excluding provisioning delays
AWS account	Nonproduction, disposable training account preferred; access to IAM, EC2, CodeCommit, CodeArtifact, CodeBuild, CodeDeploy, CodePipeline, Systems Manager, S3 and CloudWatch
User permissions	A training-admin or an approved permission set capable of creating IAM roles/policies and passing them to AWS services; no root-user access
Region	Asia Pacific (Tokyo), ap-northeast-1, throughout; use another common Region only after adapting all Region references
Network	Default VPC with at least one public subnet and outbound internet, EC2 auto-assigned public IPv4, Systems Manager connectivity and HTTP/80 access from learner’s current public IP
Browser	Current Chrome, Edge, Firefox or Safari with downloads and clipboard enabled
Downloads	AWS_Developer_Services_Console_Lab_Source.zip and this manual; extract ZIP locally using the operating system’s file manager (no terminal)
Cost	Not free by default. EC2 compute, EBS, public IPv4, CodeBuild, CodeArtifact, CodePipeline, S3, CloudWatch and requests may incur charges; charges vary by account/Region/usage. Clean up same day.
Security	Personal training account, least privileges where practical, S3 Block Public Access ON, EC2 TCP/80 from My IP only, no SSH needed, never store credentials in Git

Start-of-class gate. Open the AWS account menu, record the 12-digit account ID, and verify the Region Asia Pacific (Tokyo) is displayed in each console. If a default VPC is absent, ask the instructor to supply a VPC with a public subnet and an internet route; do not create a public EC2 target in a private subnet by mistake. All example resource names are illustrative and should be kept consistent throughout.

Fixed naming worksheet — complete before opening Lab 1

Resource	Name/value used in this guide	Record actual value
Region	ap-northeast-1	__________________
AWS account ID	12-digit AWS account ID	__________________
CodeCommit repository	`awsdevlab-webapp`	__________________
CodeCommit branch	`main`	__________________
CodeArtifact domain	`awsdevlab`	__________________
CodeArtifact downstream repository	`web-npm`	__________________
CodeArtifact public upstream	`npm-store`	__________________
CodeBuild project	`awsdevlab-web-build`	__________________
S3 standalone artifact bucket	`awsdevlab-artifacts-ACCOUNTID-apne1` (replace ACCOUNTID)	__________________
IAM EC2 instance role	`awsdevlab-ec2-role`	__________________
IAM CodeDeploy service role	`awsdevlab-codedeploy-role`	__________________
EC2 instance Name tag	`awsdevlab-web-ec2`	__________________
EC2 security group	`awsdevlab-http-sg`	__________________
CodeDeploy application	`awsdevlab-web-app`	__________________
CodeDeploy deployment group	`awsdevlab-web-ec2`	__________________
CodePipeline pipeline	`awsdevlab-web-pipeline`	__________________
CodePipeline artifact bucket	Created by pipeline wizard; record later	__________________

Naming note. S3 bucket names are globally unique. If the proposed bucket name is unavailable, append a short suffix and update every reference to that bucket. Avoid changing the fixed CodeArtifact names unless you also edit buildspec.yml through CodeCommit’s browser editor.

Lab 1 — AWS CodeCommit: store and review the application

Objective. Create a Git repository, populate it with the modernized GitHub-derived application, browse commit history, and complete one browser-only branch and pull request workflow.

Before you begin. Sign in with the assigned training IAM Identity Center role or IAM identity; Region is ap-northeast-1. Download and extract the provided source ZIP using the graphical file manager. Have a name and contact email available for commit metadata (not credentials).

1.1 Create the repository

In the AWS Console search bar, search CodeCommit and open the service (direct link: https://console.aws.amazon.com/codecommit/ ).
Check the Region selector in the top bar: choose Asia Pacific (Tokyo).
In the left navigation choose Repositories; select Create repository.
In Repository name, enter awsdevlab-webapp.
In Description, enter Browser-only AWS developer tools training application.
Keep repository encryption at the AWS-managed/default setting offered by your account. Do not configure CodeGuru or optional integrations for this lab unless your console mandates a setting.
Choose Create. Wait for the new repository’s detail page to open.
Select its Code view. An empty-repository prompt is expected: there is no default branch until your first browser-created commit.

Checkpoint CC-1: Repositories lists awsdevlab-webapp. Copy its HTTPS clone URL only as reference; do not open a terminal or clone it.

1.2 Add the application using only the CodeCommit web editor

From the repository’s Code tab, choose Add file → Create file. Open README.md from the extracted source folder in a graphical text editor; copy all its contents into the CodeCommit editor; enter File name README.md.
Fill Author name, Email address, and Commit message (for example, Add lab README). Select Commit changes. The console creates the main branch for the first commit in a new repository.
Return to the repository’s Code tab and confirm the branch drop-down shows main. For each file below, repeat Add file → Create file, paste the file’s text, enter its exact path in File name, provide the same author/email and a meaningful commit message, then choose Commit changes:File name to create in CodeCommitPurposeindex.htmlSite HTML template and first visible release labelpackage.jsonPinned npm dependency and build/test scriptsbuildspec.ymlCodeBuild phases, CodeArtifact login and release-artifact selectionappspec.ymlCodeDeploy file mapping and lifecycle eventsscripts/install_dependenciesInstall Apache and curl on Amazon Linux 2023scripts/start_serverStart and enable Apachescripts/stop_serverGraceful stop before later deploymentsscripts/validate_serverLocal service and HTTP content verificationtests/verify-source.cjsAutomated source checkstools/build-release.cjsBuild release HTML and stage deployment package
For nested names, type the entire relative path such as scripts/start_server in the Create file dialog; AWS’s CodeCommit training tutorial documents this browser-only folder-creation method. Do not flatten paths to the root. [AWS03]
Verify the repository tree shows README.md, index.html, package.json, buildspec.yml, appspec.yml, and folders scripts/, tests/, tools/.
Open buildspec.yml in CodeCommit and verify the domain is awsdevlab, the repository is web-npm, and artifacts.base-directory is release.
Open appspec.yml and verify it is located at the repository root, includes ValidateService, and installs /index.html to /var/www/html/.
Select Commits or History in the repository navigation to confirm each browser-created file produced a commit on main.

Important: Uploading the entire ZIP as one CodeCommit repository file does not unpack it into Git. Use the Create file editor separately for the listed file paths. This is deliberately slower than Git push but honors the browser-only requirement. Never paste the ZIP’s binary data into the editor.

1.3 Practice branching, review and merge entirely in CodeCommit

Select Branches in the repository. Choose Create branch (the exact control may be under the Branches view).
Set Branch name feature/lab-banner and Branch from main; select Create branch.
Return to Code, select branch feature/lab-banner, and open index.html.
Select Edit, locate the visible sentence Five services. One end-to-end delivery workflow., and replace it with Source control review completed. Ready for CI/CD. Leave <%- releaseLabel %> and <%- builtAt %> placeholders untouched.
Enter a meaningful commit message such as Update demo banner in feature branch; choose Commit changes. Confirm that main still has the original text and feature/lab-banner has the update.
Go to Pull requests → Create pull request. Select Source feature/lab-banner and Destination main.
Review the diff. Enter title Update training website banner and a description of the change; choose Create pull request.
In the pull request, review the Changes tab, add a review comment if available, then choose Merge. Select a permitted merge strategy (for a simple, conflict-free example choose Fast forward if offered), confirm the destination is main, and complete the merge.
Return to branch main and open index.html. Confirm the updated sentence is present and the pull request is merged/closed.

Checkpoint CC-2: A named feature branch, a reviewed and merged pull request, and the modified file on main are visible in the CodeCommit console. If required by an organizational approval rule, ask another authorized learner to approve instead of bypassing governance.

Lab 1 evidence to capture

Screenshot: repository name with main branch and complete folder tree.
Screenshot: pull request diff and merged status.
Record: repository ARN, default branch, most recent commit ID.

Lab 1 troubleshooting

AccessDenied on creation or commit: check the trainee permission set and account/Region; a repository policy or organization SCP may restrict codecommit:CreateRepository, PutFile or merge permissions.
No main branch: complete the first browser-created file and refresh the page.
Missing scripts/ folder: nested file paths must be entered in the filename field on Create file, not in a flat Upload file chooser.
Pull request cannot merge: verify destination/main, source/feature, merge conflicts, branch policies and required approvals.

Lab 2 — AWS CodeArtifact: manage build dependencies

Objective. Create an AWS CodeArtifact domain and npm repository connected to the public npm registry, grant the CodeBuild role secure read access, and later verify that CodeBuild actually fetched the pinned lodash dependency through CodeArtifact.

Note on order. This lab creates the repository. The first package version will appear under Packages after the initial CodeBuild execution in Lab 3. A console-only learner does not need to authenticate npm on a local machine.

2.1 Create domain, downstream repository and npm upstream

Use AWS Console search to open CodeArtifact (direct link: https://console.aws.amazon.com/codesuite/codeartifact/start ). Check Region ap-northeast-1.
Choose Create repository from the Repositories view.
Set Repository name to web-npm and optional description Dependencies consumed by the web application CodeBuild project.
Under Public upstream repositories, select the npm-store option that connects to the public npmjs registry. The wizard will create/link an upstream repository named npm-store. Do not leave the public upstream selection empty; this is how the first lodash package is ingested.
Choose Next. For AWS account, choose This AWS account.
For Domain name, enter awsdevlab (new domain). If a domain already exists, only reuse it if your instructor confirms the domain ownership and permissions.
Under Additional configuration, choose the AWS managed key for domain encryption for this disposable lab; customer-managed KMS keys require additional permissions.
Choose Next, review the package flow web-npm → npm-store → npmjs, then Create repository.
From Repositories, verify both web-npm and npm-store exist and are associated with domain awsdevlab; from Domains, verify awsdevlab exists.
Open repository web-npm and select View connection instructions → npm. Inspect the displayed domain/repository/Region endpoint. This screen is for understanding the connection; do not execute the suggested terminal login command. Authentication will occur inside CodeBuild using buildspec.yml in Lab 3. [AWS04]

Checkpoint CA-1: CodeArtifact’s repository view shows web-npm, its upstream npm-store and the new domain awsdevlab. The package list might correctly be empty until Lab 3.

2.2 Prepare the future CodeBuild access policy in IAM

The policy below is intended for the CodeBuild service role, not the trainee identity or EC2 instance. Create it after CodeBuild creates its role in Lab 3 (the next section gives the exact console steps). Do not place CodeArtifact tokens in CodeCommit, package.json, or CodeBuild plaintext environment variables. Each build automatically acquires a short-lived token. [AWS05]

IAM policy template — replace ACCOUNT_ID with your 12-digit account ID before saving. This is policy JSON, not a terminal command.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CodeArtifactDomainToken",
      "Effect": "Allow",
      "Action": "codeartifact:GetAuthorizationToken",
      "Resource": "arn:aws:codeartifact:ap-northeast-1:ACCOUNT_ID:domain/awsdevlab"
    },
    {
      "Sid": "CodeArtifactReadRepository",
      "Effect": "Allow",
      "Action": [
        "codeartifact:GetRepositoryEndpoint",
        "codeartifact:ReadFromRepository"
      ],
      "Resource": "arn:aws:codeartifact:ap-northeast-1:ACCOUNT_ID:repository/awsdevlab/web-npm"
    },
    {
      "Sid": "AllowServiceBearerToken",
      "Effect": "Allow",
      "Action": "sts:GetServiceBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "sts:AWSServiceName": "codeartifact.amazonaws.com"
        }
      }
    }
  ]
}

Instructor checkpoint: Explain the two trust boundaries: the trainee can configure IAM, while CodeBuild assumes its own execution role. sts:GetServiceBearerToken is separate from CodeArtifact’s repository authorization. The example grants read, not publish, permissions. [AWS06]

2.3 Return after Lab 3 to prove package use

After the first successful CodeBuild run, open CodeArtifact → Repositories → web-npm → Packages.
Refresh. Search for lodash. Open the package and confirm a package version such as 4.17.21 is present.
Inspect its assets/metadata. Navigate to npm-store and examine the upstream relationship, if shown in your console.
Return to CodeBuild’s build logs. Confirm the CodeArtifact login phase and package-install phase succeeded; treat CodeArtifact package presence and build success together as evidence that the dependency path worked.

Checkpoint CA-2: lodash 4.17.21 appears in the downstream repository following a successful build. Package visibility may lag; refresh before troubleshooting.

Lab 2 troubleshooting

Public package missing after build: check upstream npm-store, public internet egress from CodeBuild, build logs, and whether the build actually installed npm dependencies. Do not assume an empty package list before first build is a fault.
Token authorization error: CodeBuild role requires CodeArtifact token + repository read actions and sts:GetServiceBearerToken; root credentials cannot request a CodeArtifact auth token.
Repository not listed in CodeBuild account: verify Region, account, domain and repository spelling. Cross-account CodeArtifact access needs additional resource policies not covered here.
Private VPC build cannot access CodeArtifact/npmjs: use the default service-managed CodeBuild networking for this course; custom VPC builds need additional routes/endpoints.

Lab 3 — AWS CodeBuild: test, build and store a release ZIP

Objective. Create a standalone CodeBuild project whose source is CodeCommit, automatically fetch npm lodash from CodeArtifact, run tests, generate an index.html with a release label, and publish a fully formed CodeDeploy revision as a ZIP in private S3.

What success looks like: CodeBuild status Succeeded, test result PASS, S3 ZIP contains appspec.yml, index.html, and scripts/* at the archive root, and the CodeArtifact package can be inspected in its console.

3.1 Create the private S3 release-artifact bucket

Open Amazon S3 → Buckets → Create bucket.
Choose General purpose bucket. Set Bucket name to awsdevlab-artifacts-ACCOUNTID-apne1 (substitute your account ID; append a suffix if already in use).
Set the AWS Region to Asia Pacific (Tokyo).
Leave Block all public access enabled. Do not make the bucket or its objects public.
For Bucket Versioning, choose Disable for this disposable lab, unless your institution requires versioning (if enabled, cleanup requires deleting versions and delete markers).
For Default encryption, leave SSE-S3 or another account-approved default. For the simplest lab, use SSE-S3 rather than customer-managed KMS.
Leave other settings at their defaults; choose Create bucket and record its exact name.
Open the bucket and confirm the Permissions panel shows Block Public Access enabled.

Checkpoint CB-1: Private, same-Region S3 bucket is available and empty.

3.2 Create the CodeBuild project

Open CodeBuild → Build → Build projects → Create build project (or Create build project from the welcome screen).
Project configuration → Project name: awsdevlab-web-build. Enter a short description such as CodeCommit → CodeArtifact npm → test → S3 deployable ZIP.
Source → Source provider: choose AWS CodeCommit. Repository: awsdevlab-webapp. Reference type: Branch. Branch: main (if requested). Leave Git depth and submodules at defaults unless your console requires an option.
Environment → Provisioning model: On-demand (managed). Environment image: Managed image. Operating system: Amazon Linux. Runtime: Standard. Image: select Amazon Linux 2023 x86_64 standard:6.0 (the exact catalog label may include aws/codebuild/amazonlinux-x86_64-standard:6.0). Choose a Linux container and the smallest general-purpose compute option appropriate for a lightweight Node build.
Environment → Service role: choose New service role; note the automatically proposed role name, such as codebuild-awsdevlab-web-build-service-role. Avoid privileged mode (not required), a custom VPC, secrets or additional environment variables for this lab.
Buildspec → Build specifications: choose Use a buildspec file in the source root. Confirm the name is buildspec.yml (do not paste terminal commands into the browser).
Artifacts → Type: Amazon S3. Select the private bucket created in 3.1.
Artifact name: web-demo-release.zip. Select ZIP packaging. Keep a blank Path, choose No namespace / None if that field appears, and leave any artifact name override/semantic versioning option off. If the option Remove artifacts encryption appears, use it only if the bucket enforces SSE-S3 and the course is not using client-side AWS KMS artifact encryption; otherwise use the default encryption and grant the deployment role appropriate KMS decrypt permissions.
Cache: No cache for the first run. Logs: enable CloudWatch Logs to capture the build phases. Accept a generated or explicitly named log group; record it for cleanup.
Choose Create build project. Note the project’s Service role ARN on the details page. [AWS07][AWS08]

Image selection note. AWS currently documents Node.js 22 on the Amazon Linux 2023 standard 6.0 CodeBuild image. Our buildspec.yml explicitly selects Node.js 22 to avoid silent runtime changes. [AWS09]

3.3 Grant CodeBuild role access through the IAM console

Open IAM → Roles in another tab.
Search for the CodeBuild service role recorded in 3.2. Select it; verify its trusted entity/service is codebuild.amazonaws.com.
On Permissions, select Add permissions → Create inline policy (or create a customer-managed policy in IAM → Policies and attach it to this role). Open the JSON editor.
Replace ACCOUNT_ID in the Lab 2 CodeArtifact policy with your actual account ID and paste the full JSON. Choose Next; enter policy name AWSDevLabCodeArtifactRead; review and Create policy. Wait until the policy appears on the CodeBuild role.
Inspect the existing CodeBuild role permissions for CodeCommit source access, CloudWatch Logs, and the chosen S3 output bucket. The console may create some scoped policies automatically; do not assume permissions are present solely because the role exists.
If the role lacks S3 write or CodeCommit pull access, create and attach this supplementary inline policy, replacing ACCOUNT_ID in the resource ARNs and the ARTIFACT_BUCKET value with the actual bucket name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadTrainingCodeCommit",
      "Effect": "Allow",
      "Action": ["codecommit:GitPull", "codecommit:GetRepository"],
      "Resource": "arn:aws:codecommit:ap-northeast-1:ACCOUNT_ID:awsdevlab-webapp"
    },
    {
      "Sid": "InspectArtifactBucket",
      "Effect": "Allow",
      "Action": ["s3:GetBucketLocation", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::ARTIFACT_BUCKET"
    },
    {
      "Sid": "WriteArtifactObjects",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::ARTIFACT_BUCKET/*"
    }
  ]
}

Review the IAM policy summary before saving; confirm the target is the CodeBuild role and there are no unresolved placeholder values. If an organization SCP or bucket policy applies an explicit deny, fixing the IAM role alone may not be sufficient.

Checkpoint CB-2: CodeBuild’s execution role has CodeArtifact read/token, service bearer token, CodeCommit pull, CloudWatch log permissions, and S3 artifact write permissions.

3.4 Inspect the build contract before running

Open CodeCommit → awsdevlab-webapp → Code → main → buildspec.yml.
Confirm install selects Node.js 22; pre_build authenticates npm to CodeArtifact and installs dependencies; the test checks source structure; build generates the release; artifacts packages release/** with release as the base directory.
Open package.json. Confirm dependency lodash is pinned to version 4.17.21 and has test and build scripts.
Open tools/build-release.cjs. Confirm it renders the template with lodash, copies appspec.yml, and includes all four CodeDeploy hooks in the release/scripts/ directory.
Explain to learners that the YAML/JavaScript/shell files are source configuration. The user never manually runs their operations. CodeBuild executes the buildspec internally using the service role; CodeDeploy executes lifecycle hooks later on the deployment host.

Production distinction: For teaching a first-time upstream cache ingest, this lab pins a single dependency and performs a fresh package resolution without a lockfile. For production, create a reviewed registry-consistent lockfile, use a reproducible installation mode, add vulnerability scanning, and remove unnecessary public dependency access.

3.5 Start and inspect the standalone build

Return to CodeBuild → Build projects → awsdevlab-web-build.
Choose Start build. For source version, choose the default/latest main revision; leave optional build overrides unchanged and choose Start build.
Open the new build ID in Build history. Watch each phase: DOWNLOAD_SOURCE, INSTALL, PRE_BUILD, BUILD, UPLOAD_ARTIFACTS, FINALIZING.
On the Build logs tab, confirm the CodeArtifact npm login step completed successfully, dependency installation completed, the automated test printed a PASS message, and build output states the release directory was created.
Confirm the build’s top-level Status is Succeeded. Record the build ID and source commit ID.
In the build detail Artifacts section, follow the Artifacts upload location link to S3, or open S3 → your artifact bucket manually.
Locate web-demo-release.zip (or the S3 object whose exact key appears in the build details). Confirm it is an S3 object, not a folder of loose individual files.
From the S3 object page, choose Download in the browser; use your operating system’s graphical archive viewer to inspect its entries. The expected ZIP hierarchy is:

appspec.yml
index.html
scripts/install_dependencies
scripts/start_server
scripts/stop_server
scripts/validate_server

Verify that appspec.yml is at the ZIP root, not inside release/, source/, a GitHub folder or another nested directory. Open the packaged index.html in a local text editor and confirm the visible Release: LAB-V1 placeholder has been rendered and the build time is a real UTC timestamp.
Return to CodeArtifact → web-npm → Packages; verify lodash version 4.17.21 appears (allow some time and refresh if initially absent).

Checkpoint CB-3: Build Succeeded, release ZIP has correct file paths, lodash is present in CodeArtifact, and build log contains the source-test PASS. Save the S3 URI of the ZIP for manual CodeDeploy deployment.

Lab 3 troubleshooting matrix

Symptom in CodeBuild	Verify in console	Recovery without terminal
Source download fails	Build log; CodeCommit repository and branch; role policy	Check same Region, correct branch, `codecommit:GitPull`, repo ARN
CodeArtifact access denied	PRE_BUILD log and CodeBuild role	Apply all 3 permissions areas from Lab 2, including `sts:GetServiceBearerToken`
npm package not found / 404	Domain, downstream upstream flow	Connect `web-npm` to `npm-store` and npmjs; retry build
`buildspec.yml` not found	CodeCommit tree	Create at repository root, correct spelling (not `buildspec.yaml`)
Node runtime unsupported	Build environment image	Use AL2023 x86_64 standard 6.0 and Node.js 22
Test failed	Detailed log; tests/ path	Restore exact sample file paths and template markers
Artifact upload failed	UPLOAD_ARTIFACTS and IAM/S3	Check S3 PutObject, actual bucket ARN, ZIP packaging and encryption
ZIP contains nested `release/` directory	Buildspec `base-directory`	Set `base-directory: release`, re-run, inspect ZIP again

Lab 4 — AWS CodeDeploy: deploy the build artifact to Amazon EC2

Objective. Launch a single Amazon Linux 2023 target, install the CodeDeploy agent entirely through the CodeDeploy/Systems Manager consoles, manually deploy the tested ZIP from Lab 3, inspect lifecycle events, and validate the live HTTP website.

Architecture note. This is intentionally a single-instance, in-place deployment with no load balancer. It teaches CodeDeploy lifecycle events. It is not a highly available production deployment. The web server is installed by lifecycle hooks included in the build artifact; the learner does not manually run installation commands.

4.1 Create the EC2 instance profile (IAM role)

Open IAM → Roles → Create role.
Under Trusted entity type, choose AWS service; Use case → EC2; choose Next.
In Permissions, attach AmazonSSMManagedInstanceCore and AmazonEC2RoleforAWSCodeDeploy. The latter grants broad S3 read permissions and is convenient for this isolated course; do not use its broad S3 resource scope unreviewed in production. For production, scope S3 reads to approved artifact paths and any required AWS-owned service buckets. [AWS10]
Choose Next; enter Role name awsdevlab-ec2-role; optionally add tag Course=AWSDevLab; choose Create role.
Open the role and verify its Trust relationships shows the EC2 service principal, and its Permissions tab contains both managed policies.

Checkpoint CD-1: An EC2-trusted instance role exists, with SSM access and the CodeDeploy agent’s artifact access.

4.2 Launch the EC2 target using the EC2 console

Open EC2 → Instances → Launch instances.
Set Name to awsdevlab-web-ec2. This creates Name=awsdevlab-web-ec2, which the deployment group will use to select the target.
Under Application and OS Images (AMI) choose Amazon Linux and explicitly select Amazon Linux 2023 (AL2023), x86_64. Do not choose an old Amazon Linux 2 image only because an older walkthrough shows it.
Under Instance type, choose a small, supported general-purpose type suitable for the course, such as t3.micro if available and permitted. Verify pricing in your account; do not assume free-tier eligibility.
Under Key pair (login) choose Proceed without a key pair if allowed. This lab uses no SSH. If your organization requires an approved key pair, choose it, but do not open TCP/22 merely for this tutorial.
Expand Network settings → Edit. Select the instructor-approved VPC and public subnet. Choose Auto-assign public IP: Enable. Ensure the subnet’s route table provides an Internet Gateway path for internet-facing test traffic.
Create a new security group awsdevlab-http-sg with Inbound HTTP TCP/80 → Source type: My IP. Remove SSH TCP/22 if the wizard adds it automatically. Leave the normal outbound rule allowing required service access. Record the IPv4 CIDR displayed for My IP; this may need to be updated if your public IP changes.
Under Configure storage, keep the default encrypted/root EBS volume size offered by the selected AMI (small is sufficient). Check Delete on termination is enabled for the root volume.
Expand Advanced details. Under IAM instance profile, select awsdevlab-ec2-role. No user data is required; do not paste bootstrapping commands.
Under Summary, verify Number of instances = 1. Choose Launch instance.
In EC2 → Instances, select the new instance and wait for Instance state: Running and Status checks: 2/2 checks passed. Record instance ID, public IPv4, public DNS and the security group.

Checkpoint CD-2: One AL2023 EC2 instance is running in a public subnet with Name tag awsdevlab-web-ec2, assigned instance role and HTTP ingress only from your IP.

4.3 Confirm SSM sees the instance; do not install agents from a shell

Open AWS Systems Manager in ap-northeast-1. Under Node Management / Fleet Manager → Managed nodes, look for the EC2 instance ID. Console navigation grouping may vary; search Managed nodes inside Systems Manager if necessary.
Confirm the node shows a healthy/online SSM agent connection. AL2023 Amazon-provided AMIs typically include SSM Agent; registration requires the EC2 IAM role and outbound connectivity.
If not online, revisit the EC2 instance profile, VPC internet route, network ACL, outbound security group and SSM prerequisites. Do not continue until the instance is manageable. [AWS11]

4.4 Create the CodeDeploy service role

Open IAM → Roles → Create role.
Choose AWS service → CodeDeploy → CodeDeploy as the use case and Next.
Confirm the console proposes or attaches AWSCodeDeployRole managed policy for EC2/On-Premises deployments.
Set role name awsdevlab-codedeploy-role; choose Create role.
Open the role and verify its trust principal is codedeploy.amazonaws.com.

Checkpoint CD-3: The CodeDeploy service role exists and is distinct from the EC2 instance role and the CodeBuild role.

4.5 Create the CodeDeploy application and deployment group

Open CodeDeploy → Deploy → Applications → Create application.
Application name: awsdevlab-web-app. Compute platform: EC2/On-premises. Choose Create application.
On the application page select Create deployment group.
Deployment group name: awsdevlab-web-ec2. Service role: choose the ARN of awsdevlab-codedeploy-role.
Under Deployment type, choose In-place.
Under Environment configuration, choose Amazon EC2 instances. Set tag selector Key = Name, Value = awsdevlab-web-ec2. If the console shows a matched-instance count, confirm one target is selected.
Under Agent configuration with AWS Systems Manager, choose Now and schedule updates. This uses Systems Manager to install/configure the CodeDeploy agent on selected instances; this field is the key to our no-terminal requirement. If this option is absent, see the alternative in Step 4.6. [AWS12]
Deployment configuration: CodeDeployDefault.OneAtATime. Load balancer: disable Enable load balancing for this one-instance course.
Review fields; choose Create deployment group.
In the deployment group’s details, verify in-place, EC2 target tag, CodeDeploy service role and agent management settings. Allow agent installation to finish before deploying.

Checkpoint CD-4: Application and deployment group exist; the correct EC2 target is registered; CodeDeploy agent installation is being managed by SSM.

4.6 Fallback: install CodeDeploy agent with Systems Manager’s visual package workflow

Use this only if the deployment group’s agent-management UI is absent or reports an install failure. It is still browser-only.

Open Systems Manager → Node Management → Distributor (or the Systems Manager package-management feature; console groupings change). Choose Third party / Amazon-owned packages or the repository of available packages.
Search for the AWS package AWSCodeDeployAgentV2, the AWS-documented package for CodeDeploy agent version 2.0 and later. Select the package and Install / Install package.
In the setup choose Installation type: Install and target the managed EC2 instance ID from 4.2. For recurring updates, choose the update schedule your instructor approves; a one-off install is enough for a disposable lab.
Choose Run / Create association as the UI offers. View the Command/Association execution status until Success. Do not enter custom shell scripts or use the terminal. [AWS13]
Return to the CodeDeploy deployment group and verify agent readiness. If the package screen differs materially, follow the AWS CodeDeploy agent installation via Systems Manager documentation cited in the References section.

4.7 Deploy the S3 build output manually

Open S3 → the standalone artifacts bucket → web-demo-release.zip. From the object detail page, choose Copy S3 URI (or copy the actual S3 object path). The value must point to the exact ZIP object, not the bucket, prefix or console webpage URL.
Return to CodeDeploy → Applications → awsdevlab-web-app → Deployments → Create deployment.
Deployment group: awsdevlab-web-ec2.
Under Repository / Revision type, select My application is stored in Amazon S3.
Revision location: paste the full S3 object URI, such as s3://awsdevlab-artifacts-ACCOUNTID-apne1/web-demo-release.zip (replace with real bucket/key).
Revision file type: .zip. Enter description Manual deployment of tested CodeBuild release.
Leave the configured deployment group strategy, deployment configuration and any optional rollback settings at their course defaults. If auto rollback on failure is available, enable it for safety, but understand a first-time deployment has no last-good revision to roll back to.
Choose Create deployment. Record its deployment ID. [AWS14]

4.8 Validate lifecycle execution and the public website

On the CodeDeploy deployment detail page, inspect Deployment status until Succeeded.
Expand Deployment lifecycle events / Instance details. Confirm the expected events were completed: BeforeInstall → Install → ApplicationStart → ValidateService. ApplicationStop is normally skipped on the first deployment because there is no previous successfully deployed revision from which to load a stop hook.
If an event is red/failed, select its error/details link or related View logs link in the deployment pane. The instance’s agent logs are not required for the normal success path; the UI’s failure details should be your first stop.
From EC2 → Instances → awsdevlab-web-ec2, copy its Public IPv4 address or Public IPv4 DNS. In a new browser tab, open the http:// URL (not https://, because the course does not configure TLS).
Confirm the page displays AWS Developer Services Lab, the merged banner from Lab 1, Release: LAB-V1, and a UTC build time. Take a screenshot showing the browser URL and page content.
If the browser times out but CodeDeploy succeeded, check the instance’s public IP, inbound HTTP/80 rule with your current My IP, public route table, and local network restrictions. If the browser returns HTTP error 403/404, inspect Apache lifecycle hooks or the ZIP’s path structure.

Checkpoint CD-5: CodeDeploy deployment status Succeeded, ValidateService succeeded and a real browser request to the instance’s public IP returns the released page.

Lab 4 troubleshooting matrix

Symptom	Likely issue	Browser-based recovery
No EC2 targets matched	Tag mismatch or wrong Region	Check EC2 Name tag, CodeDeploy group tag Key/Value and account/Region
Deployment never begins / skipped target	CodeDeploy agent not installed / not healthy	Check SSM Managed nodes and agent association; use Distributor V2 workflow
Failed BeforeInstall	Apache package install error / outbound internet	Open lifecycle failure, verify public subnet internet and EC2 outbound access; retry after network fix
Failed Install (missing AppSpec)	ZIP root structure wrong	Open standalone ZIP locally; AppSpec must be at root, rebuild from CodeBuild
AccessDenied fetching revision	IAM role / S3 object / KMS	Check EC2 instance profile `s3:GetObject`, exact S3 key and any KMS decrypt grant
Failed ApplicationStart	Web server not running	Open lifecycle error, confirm AL2023, install hook and scripts in revision
Failed ValidateService	HTTP endpoint/content verification failed	Check the rendered `index.html`, Apache service startup and root path
CodeDeploy Succeeded but public page inaccessible	HTTP/80 inbound / public IP / VPC route	Check My IP CIDR, subnet/IGW, instance public IPv4; use HTTP URL

Lab 5 — AWS CodePipeline: automate source → build → deploy

Objective. Transform the standalone CodeBuild project into a pipeline-compatible action, create a V2 CodePipeline containing CodeCommit source, CodeBuild build and CodeDeploy deployment, then demonstrate an automatic rebuild and redeployment from an in-browser CodeCommit edit.

Two essential integration rules: (1) The existing CodeBuild project must have Source provider = AWS CodePipeline and Artifacts type = AWS CodePipeline before the pipeline executes it. (2) The CodeDeploy action input artifact must be the CodeBuild output (often BuildArtifact), not the CodeCommit raw source output (SourceArtifact). Missing either rule is a common source of misleading pipelines that cannot deploy the rendered HTML. [AWS15][AWS16]

5.1 Reconfigure the existing build project for CodePipeline

Open CodeBuild → Build projects → awsdevlab-web-build.
Choose Edit → Source. Change Source provider from AWS CodeCommit to AWS CodePipeline. The pipeline will now supply source ZIPs to this project. Save Update source / Update configuration, depending on the screen.
Choose Edit → Artifacts. Change Type from Amazon S3 to AWS CodePipeline; save. This does not delete the standalone ZIP created earlier in S3.
Verify Environment still uses AL2023 x86_64 standard 6.0, Service role is the same CodeBuild role (with CodeArtifact read access), and Buildspec still uses root buildspec.yml.
On project details verify Source: AWS CodePipeline and Artifacts: AWS CodePipeline. Do not use Start build directly for another standalone test; pipeline now supplies the input source and manages artifacts.

Checkpoint CP-1: The existing, already-tested CodeBuild project is configured for CodePipeline source and artifact exchange.

5.2 Create the V2 custom pipeline in the AWS console

Open CodePipeline → Pipelines → Create pipeline.
On Choose creation option, select Build custom pipeline, then Next. Avoid a prebuilt template that changes the pipeline’s service architecture.
On Pipeline settings, set Pipeline name awsdevlab-web-pipeline.
For Pipeline type, use V2 (the current console experience). Select New service role and allow AWS to create the CodePipeline service role. Record its role ARN. Keep the default same-Region S3 pipeline artifact store unless organizational policy requires a preexisting protected artifact bucket. Choose Next. [AWS02]
Add source stage: Source provider = AWS CodeCommit. Repository name = awsdevlab-webapp. Branch name = main. For Output artifact format, choose CodePipeline default, not Full clone, because the deployment later needs buildable ZIP contents. Enable Start the pipeline on source code change / EventBridge change detection. Confirm the source output artifact name, normally SourceArtifact. Choose Next.
Add build stage: Build provider = AWS CodeBuild. Select Existing project, then choose awsdevlab-web-build. Keep build mode Single build if offered, not batch build. Confirm the build receives SourceArtifact and will produce a new output artifact, normally BuildArtifact. Choose Next.
Add test stage, if offered: choose Skip test stage, since CodeBuild already runs the automated test in its PRE_BUILD phase. For production, consider a distinct dedicated test stage.
Add deploy stage: Deploy provider = AWS CodeDeploy. Application name = awsdevlab-web-app. Deployment group = awsdevlab-web-ec2. If there is an Input artifacts selector, explicitly choose the CodeBuild output (normally BuildArtifact). Choose Next.
On the Review page check source repository and branch, build project name, deployment group, artifact wiring and V2 type. Choose Create pipeline.
The pipeline may start an initial execution immediately. In Pipeline details / Edit, inspect the Deploy action. If it selected SourceArtifact or a different input, choose Edit action, set Input artifact to the CodeBuild BuildArtifact, and Save the pipeline change. Trigger a fresh execution using Release change after correcting the input; the first run may have failed if it used an incorrect artifact.
Inspect the pipeline’s automatically created artifact bucket from Pipeline settings / Artifact store and record its name. These artifacts are managed separately from the standalone Lab 3 S3 bucket.

Checkpoint CP-2: The pipeline visually shows Source (CodeCommit) → Build (CodeBuild) → Deploy (CodeDeploy). Source output flows to Build; Build output flows to Deploy.

5.3 Observe first complete pipeline execution

On the pipeline Executions or visualization page, choose Release change if no execution is in progress; confirm the action when prompted.
Watch Source become Succeeded. Select its execution details and verify the main branch and latest CodeCommit commit ID.
Watch Build. Follow View details to CodeBuild and confirm tests, CodeArtifact npm authentication and release/ packaging all succeed.
Watch Deploy. Follow View details to CodeDeploy and confirm the correct application/deployment group and all lifecycle events succeed.
Once the full pipeline is Succeeded, refresh the browser tab pointing at the EC2 public IP. Confirm the page remains accessible and the Build time (UTC) reflects the new pipeline build.
Capture the pipeline execution ID, CodeCommit commit ID, CodeBuild build ID and CodeDeploy deployment ID. These four linked IDs form the traceable evidence chain for the release.

Checkpoint CP-3: A green three-stage pipeline deploys a built ZIP produced by CodeBuild and the HTTP page is healthy.

5.4 Demonstrate a true automatically triggered change

Open CodeCommit → awsdevlab-webapp → Code → main → index.html.
Select Edit. Change the visible headline AWS Developer Services Lab (inside the <h1> element only) to AWS Developer Services Lab — Version 2. Keep the separate <title> text, the verification marker strings, the releaseLabel template placeholder and the lab-check element untouched.
The source-test checker intentionally verifies the phrase AWS Developer Services Lab, which remains a substring of the updated heading, so the test will continue to pass.
Enter commit message Release version 2 from CodeCommit console and choose Commit changes directly on main for the automatic-trigger demonstration. (In a governed production workflow, use a pull request with approvals.)
Immediately return to CodePipeline → awsdevlab-web-pipeline. Observe a new execution created by the CodeCommit change. It can take a short time for the event to arrive.
Verify Source, Build, Deploy each become Succeeded. In Build logs, look for PASS and the generated release. In CodeDeploy, confirm ValidateService succeeded.
Refresh the public page. Confirm the new heading AWS Developer Services Lab — Version 2 and a changed UTC build time.
Optionally open CodeCommit → Commits, CodePipeline → Executions, CodeBuild → Build history, and CodeDeploy → Deployments side by side and connect the commit, pipeline, build and deployment IDs.

Checkpoint CP-4: A single CodeCommit browser edit automatically results in a tested, packaged and successfully deployed Version 2 website—without manually starting a build or deployment.

5.5 Optional: introduce a controlled failure and practice recovery

Open index.html through CodeCommit Edit and temporarily remove the HTML element with id="lab-check". Commit this change on a separate temporary branch or on main only if the class permits deliberately failing the training pipeline.
Observe the subsequent Build stage fail its source test in CodeBuild. Confirm CodePipeline does not run a new successful Deploy action for that failed source revision; the old website should remain reachable.
Restore the id="lab-check" element using the CodeCommit browser editor and commit the corrected file. Re-run (or allow the trigger to start) the pipeline.
Verify the next pipeline execution becomes Succeeded and the website is healthy. Explain why build-time tests prevent a defective revision from reaching the deployment stage.

Safety note: A pipeline source-stage rule, branch permission or manual approval may prevent an automatic trigger. If so, capture that governance behavior as part of the exercise rather than disabling organizational controls without permission.

Lab 5 troubleshooting matrix

Symptom	Inspect	Corrective action in console
CodePipeline build says wrong source type	CodeBuild Source settings	Change CodeBuild Source to AWS CodePipeline
CodeBuild artifact type mismatch	CodeBuild Artifacts settings	Change Type to AWS CodePipeline
Deploy step says missing AppSpec or raw template shown	Deploy action Input artifacts	Select BuildArtifact, not SourceArtifact
No auto-trigger after CodeCommit commit	Source stage change detection	Check `main` branch, EventBridge rule and pipeline trigger settings; release manually to isolate fault
CodePipeline cannot use CodeBuild	Pipeline service role permissions	Confirm `codebuild:StartBuild`, `codebuild:BatchGetBuilds`, build project ARN
CodeDeploy cannot read pipeline artifact	EC2 instance role / artifact bucket and KMS policy	Check managed S3 GetObject and any extra KMS decrypt rights
Only first pipeline works	Region/branch, token refresh, artifact names	Trace each stage’s current input/output and cloud log references
Old website after green run	Browser cache, wrong public IP, artifact input	Hard-refresh browser, inspect build timestamp, deploy action artifact and EC2 target tag

Instructor verification and assessment

Deliverable checklist

Gate	Must-have evidence	Pass condition
CC-1/2	CodeCommit repo tree; PR diff; merged status	Correct root/nested paths, main branch, completed review
CA-1/2	CodeArtifact domain, npm upstream, cached lodash	`web-npm` and `npm-store`; `lodash` 4.17.21 after successful build
CB-1/3	Private artifact bucket; CodeBuild status/log; release ZIP	Succeeded, tests PASS, AppSpec at ZIP root, readable release content
CD-1/5	EC2 role/instance/SSM; deployment detail; web page	Managed EC2 target, CodeDeploy Succeeded, ValidateService passed, HTTP page loads
CP-1/4	Pipeline wiring; second execution; Version 2 page	V2 pipeline, BuildArtifact to Deploy, automatic trigger, page changes
Clean-up	Empty artifact buckets; deleted EC2 and lab resources	No running instances/pipelines or remaining paid lab artifacts

Suggested assessment (100 points): CodeCommit 15; CodeArtifact 15; CodeBuild 20; CodeDeploy 25; CodePipeline 20; safe clean-up 5. Award points only for screenshots/IDs or in-console evidence; do not award on the basis of claimed success alone.

Security and production-hardening discussion

IAM: The provided CodeBuild CodeArtifact policy is scoped to one repository/domain. The beginner-friendly EC2 AmazonEC2RoleforAWSCodeDeploy managed policy is broad (s3:* read-related actions on all resources); consider a custom scope for production, including service-specific buckets, and any required customer-managed KMS permissions.
Package supply chain: CodeArtifact is an upstream/cache boundary, not malware scanning by itself. Pin versions, adopt lockfiles, scan dependency vulnerabilities, govern upstream repositories and consider repository package-origin controls.
Deployment: A single EC2 instance and HTTP from My IP are instructional. For production use private instances, an ALB, TLS, launch templates or images with the CodeDeploy agent, Auto Scaling or blue/green, alarms and rollback.
Build security: Keep CodeBuild privileged mode OFF when not needed; avoid plaintext secrets and broad service roles; log and monitor builds, consider VPC endpoints and private package access.
Release governance: Prefer PR reviews, protected main branch, manual approval for production stages, deployment windows, change records and automated failure alarms.

No-terminal cleanup runbook — perform in this order

Why the order matters: Pipelines may retrigger from new source commits, deployments may create Systems Manager associations, and S3 buckets may contain automatically generated artifacts. Removing high-level orchestration first reduces orphaned resources.

CodePipeline: Open Pipelines → awsdevlab-web-pipeline. Stop/disable active executions or transitions if possible; then select Delete pipeline and confirm. Record the CodePipeline-managed S3 artifact bucket from pipeline settings before deleting if you have not already recorded it.
CodeDeploy: Open Applications → awsdevlab-web-app; inspect deployment group and any active deployments. Delete the deployment group and application through their Delete controls. Review Systems Manager → State Manager/Associations for any CodeDeploy agent installation/update associations created for the target and remove lab-only associations if they remain.
EC2: Open EC2 → Instances; select awsdevlab-web-ec2 and choose Instance state → Terminate instance. Confirm termination. Inspect Volumes, Snapshots and Elastic IPs for any lab-only resources left behind; delete only those created by this lab. Delete awsdevlab-http-sg after the instance releases the security group.
CodeBuild: Open Build projects → awsdevlab-web-build → Delete. Check its optional CloudWatch Logs group; delete the lab-specific log group after saving any instructional evidence.
CodeCommit: Open Repositories → awsdevlab-webapp → Delete repository. Confirm that there is no source data you still need.
CodeArtifact: Under Repositories delete web-npm and npm-store (including package contents per prompts), then go to Domains and delete awsdevlab. You cannot delete a domain until its repositories have been removed.
Amazon S3: Empty the standalone awsdevlab-artifacts-ACCOUNTID-apne1 bucket, then Delete bucket. Identify the separate CodePipeline-generated artifact bucket/folder; remove the pipeline’s lab objects, and delete the bucket only if you confirm no other pipeline shares it. Versioned buckets require removal of all object versions and delete markers.
IAM: Delete the lab-specific IAM roles awsdevlab-ec2-role, awsdevlab-codedeploy-role, the generated CodeBuild service role, and the generated CodePipeline role only after confirming nothing else uses them. Delete any custom AWSDevLabCodeArtifactRead policy if not reused. Detach policies before deleting roles when the console requests it.
CloudWatch/EventBridge: Inspect for lab-only log groups, alarms and EventBridge rules still present; delete orphaned lab-only resources. Some change detection rules are removed automatically when the pipeline is deleted.
Cost review: Open Billing and Cost Management → Cost Explorer after billing data posts. Look for EC2, CodeBuild, CodeArtifact, CodePipeline, S3, public IPv4 and CloudWatch charges. Cost data is not necessarily real time.

Final cleanup gate: EC2 Instances shows no running training EC2, CodePipeline and CodeBuild no longer list training resources, CodeArtifact domain is deleted, the standalone S3 bucket is gone, and training IAM roles are removed or explicitly retained by policy.

Reference guide: verified documentation and sample provenance

Key	Current authoritative/reference material	URL
AWS01	AWS announcement: CodeCommit returned to general availability (24 November 2025)	https://aws.amazon.com/blogs/devops/aws-codecommit-returns-to-general-availability/
AWS02	AWS CodePipeline: create a custom pipeline (console), V1/V2, stages and change detection	https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html
AWS03	AWS CodePipeline tutorial: CodeCommit browser files and nested paths	https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-codecommit.html
AWS04	AWS CodeArtifact: getting started using the console	https://docs.aws.amazon.com/codeartifact/latest/ug/getting-started-console.html
AWS05	CodeArtifact authentication/token behavior	https://docs.aws.amazon.com/codeartifact/latest/ug/tokens-authentication.html
AWS06	CodeArtifact: using npm packages in CodeBuild and IAM permissions	https://docs.aws.amazon.com/codeartifact/latest/ug/using-npm-packages-in-codebuild.html
AWS07	CodeBuild: create build project through console	https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html
AWS08	CodeBuild: buildspec syntax and artifact base-directory	https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html
AWS09	CodeBuild: currently available runtimes and images	https://docs.aws.amazon.com/codebuild/latest/userguide/available-runtimes.html
AWS10	Managed EC2 CodeDeploy role scope (AWS managed policy)	https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2RoleforAWSCodeDeploy.html
AWS11	Systems Manager: managing EC2 as managed nodes	https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-nodes.html
AWS12	CodeDeploy/CodePipeline tutorial: configure agent using SSM in deployment group	https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-codecommit.html
AWS13	CodeDeploy: install CodeDeploy agent through Systems Manager Distributor	https://docs.aws.amazon.com/codedeploy/latest/userguide/codedeploy-agent-operations-install-ssm.html
AWS14	CodeDeploy: create EC2/on-prem deployment with S3 revision	https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-create-console.html
AWS15	CodeBuild: change project source and artifacts in the console	https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html
AWS16	CodePipeline: CodeDeploy deploy action and artifact requirements	https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-CodeDeploy.html
AWS17	GitHub sample: AWS CodeDeploy `SampleApp_Linux` (architecture and origin)	https://github.com/aws-samples/aws-codedeploy-samples/tree/master/applications/SampleApp_Linux
AWS18	lodash package source and current npm package information	https://www.npmjs.com/package/lodash

Source integrity reminder: This guide is an original training adaptation, not a claim that the GitHub sample was written for CodeArtifact or AL2023. For exact upstream source and license, review the AWS GitHub repository. The downloadable training ZIP contains the files participants should transfer through the CodeCommit browser editor. No AWS or GitHub credentials are bundled.

title	AWS Developer Services: Gold-Standard Console Lab Guide
subtitle	CodeCommit • CodeArtifact • CodeBuild • CodeDeploy • CodePipeline
author	Instructor Edition \| Browser-Only Labs
date	10 November 2026
lang	en-US