New in AWS Amplify: Expanded Fullstack Deployment Capabilities for Teams of All Sizes

Today, we’re excited to announce new team environment workflows as a part of AWS Amplify Gen 2. We’ve improved team collaboration in three ways: 1/ making the development lifecycle faster and more powerful, 2/ improving the core functionality of our own platform, and 3/ offering greater flexibility for customers to integrate Amplify within their existing deployment setup. This allows you to use Amplify to easily deploy fullstack apps whether you’re an early stage startup, or an enterprise team.

In this blog, we will walkthrough different team workflows and development environment improvements that the new version of Amplify offers. If you’d like learn more about the all-new second generation of Amplify featuring a fullstack TypeScript DX or if you want to follow along while reading, check out our launch blog first, then come back and read this post about the development lifecycle improvements!

Development

Amplify has three new features that enhance its development experience: per-developer cloud sandboxes for faster iteration during the app creation process, secrets management, and AWS Cloud Development Kit (AWS CDK) integration for greater customization capabilities.

Per-developer Cloud Sandboxes

All teams using Amplify will benefit from its new per-developer sandbox environments. These cloud sandboxes, meant for local development only, deploy high-fidelity AWS backends to use while you build. They allow you to iterate on your backend logic quickly — every time you save your code, your sandbox will redeploy cloud resources based on what you need. For example, if you update your Amplify data schema, the sandbox will make changes to your database automatically so you can test out your logic in your app. Each developer works in their own sandbox, so quick iteration in development won’t lead to developers working over each other. In the diagram below, four developers are able to work on fullstack features independently without disrupting each other’s environments:

All you need to do to run a sandbox is open an Amplify Gen 2 app and run the following command in your terminal:

cd my-app
npx ampx sandbox

Cloud sandboxes are meant to be ephemeral, once you’re done developing, tear down the sandbox and create a new one the next time you need one!

AWS CDK integration

As business requirements evolve, developers may need to add use cases beyond those natively supported by Amplify. Amplify is now built on top of the AWS CDK which makes adding custom resources and overriding the resources Amplify utilizes seamless. A developer could, for example, use the AWS CDK to hook up a Redis cache, implement custom security rules, deploy containers on AWS Fargate, or connect to Amazon Bedrock for AI/ML. The infrastructure defined through the AWS CDK code is deployed along with the Amplify app backend with every git push. This means you can build with Amplify’s ease of use and simplicity, but you don’t have to worry about outgrowing it as your business requirements evolve.

If you wanted to set a custom removal policy on your Amplify-provisioned authentication instance, for example, you could add the following to your backend.ts file:

import { defineBackend } from '@aws-amplify/backend';
import { auth } from './auth/resource';
import { UserPool } from 'aws-cdk-lib/aws-cognito';
import { RemovalPolicy } from 'aws-cdk-lib';

const backend = defineBackend({
  auth
});

const userPool = backend.auth.resources.userPool as UserPool;
userPool.applyRemovalPolicy(RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE);

Secrets

Amplify Gen 2 offers centralized management of secrets and environment variables. Secrets allow you to securely configure environment-specific values like social sign-in keys, function environment variables, function secrets, and other sensitive data needed by your application across environments. These secrets can be scoped to all deployed branches, or just specific ones. You can have secrets set up both in your local sandbox, for example:

npx ampx sandbox secret set fb-client-id 
? Enter secret value: ### Done! > 
npx ampx sandbox secret set fb-client-secret 
? Enter secret value: ### Done!

Or in production through the console:

You can then access your secrets in your code!

import { defineAuth, secret } from "@aws-amplify/backend";
export const auth = defineAuth({
  loginWith: {
    email: true,
    externalProviders: {
      facebook: {
        clientId: secret("fb-client-id"),
        clientSecret: secret("fb-client-secret"),
      },
    },
  },
});

Deployment

Amplify also has new capabilities for shipping apps with your whole team no matter what development workflow you follow. Let’s walk through what your Amplify workflow for three different deployment strategies: Git flow, GitHub/pull request flow, and trunk-based deployments. We’ll then talk about new features for repository and secrets management.

Git Flow

Git flow is a branching model that utilizes two main branches: a main branch for production releases and a develop branch for integration of features. Developers create feature branches from the develop branch, merge them back into develop after completion, and periodically merge develop into main for releases. It also introduces separate branches for hotfixes and releases, providing a structured way to manage parallel development streams.

Amplify’s CI/CD system is designed to work really well with this workflow. All of your Amplify code, and therefore your backend and cloud logic, will exist in your codebase in TypeScript code, so your Git branches will contain all the source code needed to deploy your frontend and backend. You can then have a deployment environment for your main and dev branches.

Auto-deploy fullstack feature branches

In the Amplify Console, you can define branch patterns such as * or feature/* and auto-deploy any branches matching that pattern in your repo to Amplify. Moving changes from dev to prod is as simple as merging changes from your dev to prod branch.

Checking the ‘Automatically disconnect branches’ checkbox in the right will auto-disconnect branches from Amplify when you delete Git branches from your repository.

Automatic custom sub-domains

Once you set up a custom domain, you might want your auto-deployed feature branches or PR previews to have a memorable sub-domain. You can configure Amplify to create those subdomains based on a pattern you specify.

GitHub/Pull request Flow

Another common approach teams use is to have a single main branch for production, and then each developer would create pull requests to that main branch from forks they created in order to merge features to production. In this scenario, we see customers deploy a single main branch to Amplify, and then enable pull request previews to create ephemeral pull request deployment instances.

Now, when a pull request is opened, Amplify will automatically deploy a fullstack pull-request branch to Amplify as an ephemeral environment that will be accessible at https://pr-#.mydomain.com

Once the pull request is merged, the entire fullstack pull request preview branch is torn down.

Trunk-based developments

Trunk-based development is a another software development strategy where all developers work off a single shared trunk (or main branch) and frequently integrate their changes into the trunk. It emphasizes continuous integration and collaboration, reducing the risk of merge conflicts and enabling faster feedback cycles. In trunk-based development, developers create short-lived feature branches, merge them into the trunk as soon as possible, and rely on automated testing with pipeline stages to ensure the stability of the codebase.

Multi-account AWS deployments

While Amplify does not directly offer a pipeline/stage-based workflow, customers can now use their own their own CI/CD pipeline such as AWS CodePipeline or Amazon CodeCatalystto deploy their fullstack application in a pipeline-based workflow. You can follow this tutorial for using Amplify with Amazon CodeCatalyst to follow this trunk-based strategy.

Monorepos and Multirepos

Amplify accommodates various repository configurations. It integrates with monorepo tooling like Nx or yarn workspaces, enabling teams to manage multiple applications within a single repository. If you have separate frontend and backend teams, Amplify also supports using separate repositories for frontend and backend codebases.

Next Steps

This blog post explores how teams can leverage Amplify to develop and deploy full-stack applications no matter their scale. Get started with Amplify by following our Quickstart tutorials!