Developer and End-User Tools

What is it?

Besides core infrastructure, AWS offers tools for developers who build and ship software, and services that deliver desktops and applications to end users. Availability note: AWS sometimes stops accepting new customers for a service or retires it (for example Cloud9 and parts of the Code* suite have been closed to new customers). Always check current availability before choosing a service, but know them for the exam.

Developer tools

• AWS CloudShell: a browser-based shell with the AWS CLI preinstalled, signed in with your console credentials.
• AWS Cloud9: a browser-based IDE for writing and debugging code.
• AWS CodeCommit (Git repositories), CodeBuild (compile and test), CodeDeploy (deploy to EC2, Lambda, on-premises), CodePipeline (automate the release stages), CodeArtifact (store packages) and CodeStar (project templates) form a CI/CD suite.
• AWS X-Ray: traces requests through a distributed application to find slow or failing components.
• AWS AppConfig (part of Systems Manager): deploy application configuration and feature flags safely, with validation and gradual rollout.
• AWS Amplify: build, host and connect web and mobile front ends to backends such as authentication and storage.
• AWS AppSync: managed GraphQL (and pub/sub) APIs that connect to data sources.
• AWS Device Farm: test web and mobile apps on real phones and browsers.

End-user computing

• Amazon WorkSpaces Family: managed virtual desktops (Windows or Linux) for staff, billed monthly or hourly; WorkSpaces Secure Browser (formerly WorkSpaces Web) gives a secure, isolated browser for internal web apps.
• Amazon AppStream 2.0: streams a desktop application to a browser instead of a whole desktop.

Internet of Things

• AWS IoT Core: connects devices securely and routes their messages. AWS IoT Greengrass extends AWS to the device edge so it can run code and make decisions locally, even offline.

Explain like I'm 10

Building software is like running a factory. CloudShell and Cloud9 are the workbench, the Code* services are the assembly line from source to shipping dock, X-Ray is the tracking label that shows where a parcel got stuck, AppConfig is the switchboard for turning features on gradually, and WorkSpaces/AppStream deliver a ready workstation or a single tool to any employee's door.

Examples

A buildspec for CodeBuild

version: 0.2
phases:
  install:
    commands:
      - npm ci
  build:
    commands:
      - npm test
      - npm run build
artifacts:
  files:
    - "dist/**/*"

CodeBuild reads this file, runs each phase in a fresh container, and saves the dist files as the build output for CodePipeline to deploy.

CloudShell: no setup required

# Open CloudShell from the console toolbar, then:
aws sts get-caller-identity
aws s3 ls
# Your home folder (1 GB) persists between sessions in that Region

CloudShell removes the need to install and configure the CLI locally for quick tasks.

How it works

CI/CD: a commit triggers CodePipeline, which pulls source, calls CodeBuild to build and test, then CodeDeploy to roll the new version out (in place, rolling or blue/green). X-Ray adds a trace ID to a request and collects segments from every service it touches, producing a service map.

WorkSpaces runs a desktop in AWS and streams pixels to a client, so data stays in the cloud rather than on a laptop. IoT Core uses MQTT messages and a rules engine to route device data to other AWS services.

  Source -> Build -> Test -> Deploy        (CodePipeline orchestrates)
  [Git]    [CodeBuild]      [CodeDeploy] -> EC2 / Lambda / on-prem
  Running app --> X-Ray traces --> service map of slow calls
  Staff laptop <== pixels == WorkSpaces desktop in AWS

Why does it exist?

Teams want to ship quickly and safely without running their own build servers, and organisations want to give staff secure desktops without managing physical PCs. Managed tools remove that undifferentiated work.

When to use it

Use the CI/CD tools to automate releases, X-Ray to debug microservices, AppConfig for gradual feature rollouts, Amplify for quick front-end hosting, Device Farm for device testing, WorkSpaces for remote staff desktops, AppStream 2.0 for delivering one application, and IoT Core for connected devices.

When not to use it

Do not build new work on a service that is closed to new customers; pick the current alternative (the AWS docs name it). Do not use WorkSpaces when you only need one application (AppStream 2.0), and do not use X-Ray for metrics and alarms (CloudWatch).

Common mistakes

• Assuming every service is still open to new customers.

• Confusing CodeDeploy (deployment) with CodePipeline (orchestration) or CodeBuild (build/test).

• Mixing up X-Ray (tracing requests) with CloudTrail (API audit) and CloudWatch (metrics/logs).

• Choosing WorkSpaces when AppStream 2.0 would stream just one app.

Practice exercises

1. Easy:

   List which Code* service builds, which deploys and which orchestrates.

2. Medium:

   A slow API call crosses five microservices. Explain how X-Ray would help find the bottleneck.

3. Medium:

   Pick WorkSpaces, WorkSpaces Secure Browser or AppStream 2.0 for three different scenarios.

4. Hard:

   Design a release pipeline with a manual approval step and blue/green deployment, naming each AWS service.

Interview questions

Exam-style: Which service traces requests across a distributed application?

AWS X-Ray.

Exam-style: Which service automates the release process from source to deployment?

AWS CodePipeline.

Exam-style: Which service provides virtual desktops in the cloud?

Amazon WorkSpaces.

Exam-style: Which service streams a single desktop application to a web browser?

Amazon AppStream 2.0.

Exam-style: Which service tests mobile apps on real devices?

AWS Device Farm.

Exam-style: Which service lets you run code on devices locally and connect them to AWS?

AWS IoT Greengrass (with IoT Core for cloud connectivity).

Exam-style: Which service provides a browser-based CLI?

AWS CloudShell.