If you’re a front-end developer working with AWS, I really think you should start with Amplify, and later refactor to CodePipeline. Seeing a concerning trend of Developers diving into various CICD pipelines AWS provides that are too low-level, and too slow out of the box for reasons that aren’t readily apparent unless building pipelines is your specialty.

Using Amplify first prevents big batch development, gets you moving quickly leveraging the powers of serverless, but gives you an escape hatch. The only justification for going to CodePipeline first is if you have the chops to already generate a pipeline from existing reference architecture, and you know how to make it fast while having the resources & bandwidth to maintain it. Slow pipelines that developers cannot fix are bad for projects whereas fast ones that developers can maintain are good.

The first escape hatch is as your Ops chops improve, and your automated tests increase in scope, you can migrate to CodePipeline/CodeBuild, yet still have those utilize Amplify as a deployment target; the build & automated tests can be run in CodeBuild instead.

If serving costs become a concern (e.g. S3 + CloudFront cheaper than Amplify for serving files), you can then move to individual S3 + CloudFront vs. having Amplify manage those for you at which point you can probably afford a dedicated Cloud Engineer to manage the automation around building that infrastructure. The same value proposition of Serverless vs. ECS/EKS/K8.

Amplify has all the things a UI developer (NOT Full Stack) needs for both hosting AND a build server:

1. “Give me a URL to give my users now, and later make it a nice looking URL”; hosting, CloudFront cache invalidation, and Route53 URL SSL integration all abstracted away nicely
2. “deployment pipeline that builds my code, tests it, and if the tests pass invalidates the cache and deploys it”; single YAML CodeBuild setup with 3 phases of build, test, and deploy, all visual, all linked to individual builds with real-time updates in the UI
3. “Built in Cypress Tests“, built in Cypress container that AWS manages so you aren’t on the hook for managing container updates, with Cypress, all integrated into the UI so you can see which tests pass and fail, and when they fail, you can download the images and videos.
4. If you do not practice trunk based development, then you can have Amplify automatically spin up differently URL’s/environments for each of your source control branches; this is an automatic optional feature Amplify provides.

When starting a project, at least for the UI, consider using Amplify first. This empowers UI developers who may not have a lot of experience with building their own CICD pipelines the ability to quickly deliver code to users, improve the pipeline with automated quality checks (e.g. ESLint, unit tests, acceptance/Cypress tests), and quickly debug their code when the UI fails. By default, she’s 3 to 5 minutes from code check-in to being live on a URL your clients/users can see. The YAML to build the pipeline is something any UI dev, even juniors, can put together and debug when it fails.

When you’re team/department is ready, then you can move to CodePipeline, or some other mature Continuous Deployment pipeline such as Gitlab Pipeline, while still using Amplify for the deployment step until it’s worth the cost to manage S3/CloudFront/Route53 yourself.

Amplify CLI and back-end should be avoided, though; just the AWS service using UI.