RFC: Importing Existing AWS Resources to Amplify Project using the Amplify CLI

[kaustavghosh06]

Currently, the CLI provisions new AWS resources based on the categories that you add to your Amplify project.
This RFC is to gauge community interest and hear more thoughts around the CLI being able to import existing resources into an Amplify project.

As an MVP, we’re planning to support importing of resources in the following categories:

• Auth
• Storage (S3 & DynamoDB)
• API - REST and GraphQL (to use existing data sources and auth resources)

We’ll be relying heavily on the new CloudFormation import functionality - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-existing-stack.html for this feature

Auth

• Ability to add an existing Cognito user pool to an Amplify backend environment as a part of the amplify add auth flow
• Ability to specify a new or use the same Cognito user pool used in an existing environment when creating a new Amplify backend environment
• Ability to update and manage the imported Cognito user pool via the CLI as a part of the amplify update auth flow to add features like Lambda triggers to your existing Cognito user pool

Storage

• Ability to add an existing S3 bucket as a part of the amplify add storage flow
• Ability to add an existing DynamoDB table as a part of the amplify add storage flow
• Ability to update and manage the imported and S3 and DynamoDB tables as a part of the amplify update storage flow
• Ability to specify a new or use the same S3 & DynamoDB tables used in an existing environment when creating a new Amplify backend environment

API

GraphQL API

• Ability to use existing DynamoDB tables as a part of @model directive as a part of the GraphQL transformer annotated schema
• Ability to use an existing Cognito user pool for authorization as a part of the amplify add/update flow
• Ability to modify or use the same Cognito user pool for authorization between different Amplify backend environments

REST API

• Ability to add an existing API Gateway resource using the amplify add api flow
• Ability to use an existing Lambda resource with an API Gateway resource as a part of the amplify add/update api flow
• Ability to update or manage the imported API Gateway resource as a part of the amplify update api flow
• Ability to specify a new or use the same API Gateway resource used in an existing environment when creating a new Amplify backend environment

Please comment on this thread if you have some thoughts or suggestions on this feature or if you think we’re missing any story points which you would love to see as a part of this feature.

[andrewbtp]

How would this play out across environments? If I add a bucket im-a-bucket to env test, if I create a new env prod, does it hit the same bucket or create a new bucket?

Though I hopefully won't need it, I'm a big fan of this RFC.

[hisham]

Will you be able to add resources in other regions or will it be limited as same data center as the amplify env?

[jagadishallakanti]

It would be amazing if we can use same cognito user pool for two different application like for example one app for back office management and other app for front office users. In this way security is not compromised or accidental release happen

[TLaue]

We are currently already using AWS Amplify with existing resources (e.g. Cognito User Pool) by adding manually created config files which are included by our CI/CD pipeline depending on the relevant stage. It works but I would really prefer a way which is natively supported by AWS Amplify CLI.

Furthermore I would really love to include existing AppSync apis with support for Amplify DataStore even though this might be a bigger task.

[RossWilliams]

I’m not in favour of this feature, and I’d rather see this supported through solid documentation and exposing users to a bit of plumbing.

Main reasons:

• The documentation will help users who don’t need this specific feature to better understand the cli and how it interacts with cloud formation
• Documentation around internal plumbing can help more community members contribute to the project
• This won’t be a highly used feature on its own
• The cli should not have to do everything for users, instead it should look to support users who want to edit cloud formation with as little resistance as possible
• You can’t cover all cases, users will also want to pull custom resources into their stack

[cesiztel]

I am really happy that you guys are considering this feature 🔥. In short, my opinion is that this feature can increase the number of projects and developers which adopt AWS Amplify. My reasons are:

• In frontend teams of specially big corps (where the AWS services are heavily used), they are more reluctant to use Amplify because they can not integrate easily (natively) the existing services from the CLI. Frontend teams do not want to end up with configuration files or be forced to have a deep understanding of AWS Services, so for them will be really helpful in adoption point of view.
• It will be possible draw a real independency line between frontend development circle and serverless-backend development circle. AWS Amplify will be the glue which can adapt to new and existing services. This will give full ownership to the frontend teams.
• The barriers of usage will be minimum. From the documentation you will guide through the process to create a new whole fresh project or adapt with the existing infrastructure. I do not think is a really considerable-to-use tool if the documentation just mentioned how you can do this integration manually somehow.

The CLI will be probably more complex. Also, the CLI will need to manage existing and new services at the same time. But it is a "downside" that it worth to assume.

[asmajlovicmars]

This would be perfect, as long as it's robust enough to never delete the existing Auth if there's a reference to it from another project. We're planning to add several applications around a single Cognito User Pool, which serves as SSO, and being able to attach the existing Auth is exactly what we need. I second the question how would this work across different envs?

[Johnniexson]

Yea, this will be very useful for me, and will ease the stress of manually setting the config file to use existing resources. 👍

[BeaveArony]

Wonderful news!

It took me quite some time in January to include an existing UserPool in a project in my company. The cloud is managed by terraform and setup manually. Every environment is in a different account and I do not have permissions to use amplify push. The people in charge are very skeptical about this kind of automation and are afraid, that Amplify would delete or change something, that other parts of the software rely on.

I started with creating the UserPool Client for web and the identity pool in terraform, but soon realized that this was too much work to transform all the cloudformation templates to another format. With every Amplify update, I would also have to check if something changed, that would be a nightmare!

Note:

Before I could do anything with the Amplify CLI, I had to configure the CLI with an external AWS-Account where I had all permissions to. It turned out to be a good testing ground for experiments without committing the changes to git. This gave me the /amplify folder I needed to check into version control.

My solution so far:

1. Create a GraphQL API and have it also create the UserPool, the UserPool Client, the IdentityPool, and so on...
2. Create a custom resource as described in the docs and copy the automatically created cloudformation template over and adjust the parameters.json to include the existing UserPool ARN (this is automated in the build pipelines to get the proper ARN)
3. Go through the template and delete the UserPool creation part, and update all the mentions of the UserPool ARN with the configured input parameter, which is quite tedious and error prone
4. Remove the Auth category before pushing or committing the source code
5. Change the GraphQL API in cloudformation so it points to the new custom resource
6. Repeat these steps for other categories that depend on the Auth category, ie. Storage

In build pipelines:

1. Get the UserPoolArn with the TerraForm CLI and write it to some config file so it can also be used by the frontend build during a later build step
2. Write the extracted value in the auth parameters.json file
3. Create a custom aws_config.js file with a modified pushAmplify.sh script

The Resulting Project

There are probably several steps I did not mention, but I ended up with Amplify CLI managing everything except the UserPool, including a new UserPoolClientForWeb and IdentityPool.
Every environment is in a different account, so in the team-provider-info.json every ENV is in a different AmplifyAppId and if the CI/CD pipeline adds or changes something in this file, it needs to be committed back to the repo or otherwise there will be a new Amplify App created with every build!

Working with this kind of setup

Every change to the auth part is a huge pain! If I want to add IAM autentication to the AppSync API for example, I would need to try it out in another project and compare the CFN templates to see what changed. Amplify is under heavy development and is adding features and fixing bugs all the time. The generated templates change quite heavily sometimes, which is a good thing, they are auto generated, but for me I just want to use Amplify because I do not want to write CloudFormation or TerraForm!
So this RFC would lift a lot of weight off my shoulders!

Create the initial Amplify App with CFN?

I think if I would start over, I would explore to create the Amplify App with either a CloudFormation template, the aws-cli (not amplify-cli) or some other InfrastructureAsCode tool and see how to progress from there...

Protect existing resources

I'm concerned about having the CLI modify or accidentally delete the existing UserPool. Even changing the triggers might overwrite some existing trigger and cause some grieve for the developer responsible for the change. So maybe start with only adding resources like the UserPoolClient and IdentityPool and wire them to the other Amplify categories, but leave the UserPool alone? I think the people in charge wouldn't mind seeing UserPoolClients created for every new Amplify project as long as the existing parts are protected. Managing triggers by Amplify is a very good feature though!

Export resources

There is also some additional complexity when Amplify also needs to export created resources. One scenario I'm facing is to give the AppSync API URL some pretty company sub-domain name. There is an existing TerraForm module that makes it easy, but I would need to figure out how to best fetch the URL and create a new TerraForm plan that is run after the Amplify deploy process. (The first plan only imports existing resources)

TAGS

Also, please add the option to specify tags for the root stack, so that every resource created by the Amplify CLI gets them automatically applied! Please!
My current workaround for this is to redeploy the root stack with the aws-cli adding the --tags parameter. This is done after every amplify push during CI/CD.

Parting words

Anyways, I got into quite some details, so you could hopefully understand one developers needs when it comes to integrating an Amplify App into an existing AWS infrastructure. So every progress in that area is highly anticipated by me!

[vdumouchel]

Hello guys!

Had a mid size project on amplify pushing to dynamo DB tables. Had to play in my graphql schema to change connections between types and this introduced a secondary index error on a table upon doing amplify push... tried reverting back by pushing the schema I had prior to my connections modifications instead and now I have big rollback errors many tables in dynamo db. Hard to know what is the problem and impossible to debug.
So I feel I'm left with either starting from scratch (losing everything in the appsync endpoint).... but I would very much like to possibly start a new amplify project and just connect my previous auth pool + previous appsync endpoint and I guess start a new dynamo DB to get by to the previous state of my project so the appsync endpoint pushes stuff back in the new DB to seed it as if nothing ever happened!

If you guys have other ways right now to revert changes made to my dynamo db to get past the errors on Amplify push I'm all ears!

[RossWilliams]

@vdumouchel

Hard to know what is the problem and impossible to debug.

You likely have a GSIs created on dynamo tables from the first push failure. When a GSI change fails in DynamoDB, CloudFormation will not roll it back for you, it must be done manually. You need to use the API or console to remove the created GSIs so that you tables match your last-known good schema. Then be careful and make sure each push only changes 1 GSI per table going forward. This feature being discussed is not likely to be a good long-term solution to your situation.

[BeaveArony]

@vdumouchel
@RossWilliams is spot on. Do NOT push changes where you change more than one @connection or @key.

I would suggest to always only experiment in a different environment, but make sure to only incrementally merge the changes to the main branch.

Renaming trick

One 'trick' I use when I get into this situation and don't want to create a new environment is to simply rename all those @model types! This will delete the old Dynamo tables and create the new ones with all those changes you want. If the data is important you can make a backup, ie. in the Management Console.
Once you merge this schema with the renamed @model types to every other branch/env you can rename them back and push them to every branch/env again. Then restore the backup or repopulate the data somehow.

I haven't tried the backup part yet, so I cannot help you with that.

[Johnniexson]

@vdumouchel
@RossWilliams is spot on. Do NOT push changes where you change more than one @connection or @key.

I would suggest to always only experiment in a different environment, but make sure to only incrementally merge the changes to the main branch.

Renaming trick

One 'trick' I use when I get into this situation and don't want to create a new environment is to simply rename all those @model types! This will delete the old Dynamo tables and create the new ones with all those changes you want. If the data is important you can make a backup, ie. in the Management Console.
Once you merge this schema with the renamed @model types to every other branch/env you can rename them back and push them to every branch/env again. Then restore the backup or repopulate the data somehow.

I haven't tried the backup part yet, so I cannot help you with that.

Hmmm... This is a dope idea, i will give it a try also

[danrivett]

I love this RFC, I'm sure I'll have additional thoughts, but the first two things that spring to mind are:

1. When specifying existing names for things like DynamoDB tables, it would be good to support an env placeholder so that it can vary dynamically per environment if desired
   1. e.g. I could specify notes-${env} and it would resolve to notes-dev, notes-prod or I could specify just notes and it would be used across all environments
2. Just an initial thought but I would think it is safest to have a hard lock on deleting any existing resources referenced.
   1. e.g. it should be able to distinguish between resources created, and existing resources referenced, per environment, and removing an environment would only remove the automatically created resources and leave the existing resources behind.

[apoorvmote]

I want to collect emails with Hugo static website.
Then manage email list with react app and send bulk email with SES and lambda.
I have created another issue #4175 with more details.

[cyrfer]

Maybe there is a comment above that elaborates, but based on the heading I am worried "support for USING existing resources" (created by whatever process, including another Cloudformation stack) might get mixed in with "import existing resources" which implies leveraging Cloudformation's recent support for importing resources that were not created by a CF stack.

If a resource was created by another CF stack, I don't want to modify that resource. Instead I think the CF templates and CLI interview should allow users to provide existing resources to be USED (not only IMPORTED).

I made a feature request for "support for existing resources" over here. I think it's notable that for some cases (mine) it is currently supported! And I don't want it be be broken. :)
#4197

[sw33tr0ll]

Please add this please! Thank you, great idea

[diegorey]

This would be amazing for working with multiple apps within the same company. It would be great to add functions directed to an existing table and/or AppSync API.
Thanks for the great work!
PS: Are there examples in the documentation of accessing existing AppSync APIs through Lambda?

[arckdash]

I believe I managed to solve as I described it in this thread:
aws-amplify/amplify-js#4704 (comment)

[Alk3m1st]

Also adding my support for this feature. Similar to @cyrfer my use case is around being able to use / link Amplify to existing resources for easy and seamless integration rather than importing them for control by the Amplify App. I'm most interested in Auth, allowing a Cognito instance to be used by multiple apps but only one in control of it (or perhaps not at all where managed externally).
Use of existing DynamoDB tables by API (AppSync) or S3 buckets by storage would also find many uses.
I love that Amplify still allows delving into the CloudFormation templates for customisation and @RossWilliams makes a good point about stronger documentation here but I enjoy the power of the Amplify CLI to perform most tasks without needing to do so. For example the Lambda triggers were really useful to me recently for easily using DynamoDB streams to an existing table (outside Amplifys control).

[JamieSlome]

Apologies if I am duplicating advice written above. I have not had the chance to read through all of it.

It would appear that creating an entirely new resource (Lambda function, for example) through the CLI alongside an already existing reference (i.e. an AppSync API) and executing amplify push will force the backend environment to now reference your already existing API resource.

Of course, you can go ahead and delete the Lambda or temporary resource after.

Cheers 🍰

[frankoid]

We have a largish (9000 lines of cloudformation for the appsync not including the lambdas that it calls) AppSync API that we'd like to be able to develop/debug locally. At the moment we have to deploy all changes to AWS before we can test them which means we have a slow feedback loop (especially since we do the deployments via a pipeline we've built, so it requires a git commit and a minute or two's wait plus the ~5 minutes for the AppSync CloudFormation to deploy).

We'd love to be able to develop locally so if Amplify could import existing cloudformation templates for AppSync and Lambdas that would be great.

A bit more info about our stack: we have a React web app and an AppSync API backed by lambdas and also some direct AppSync->DynamoDB access. The VTL in our AppSync API is quite complex (possibly too complex, but simplifying it would involve compromises/downsides).

[renebrandel]

So far I have ran into no problems! Although I do have a question. From my understanding of the documentation, the app client without the secret key is for storing data of the todo list. I just have one Cognito user pool for AWS Amplify Authentication. Whenever I tried adding the Cognito user pool to the Cognito Identity Pool and running the command "Amplify import auth" from the Amplify CLI in the root of my project, it gave me an error saying I needed to have an app client without a secret key. Why is it required to have two app clients: one with a client secret and one without?

Various CLI components currently take dependency on this "shape" of the Cognito resource format. This might be a requirement that we'll drop in the future. Good call out. For now, you'll just need to add a second app client in order to conform to the Amplify requirements.

[cyrfer]

@renebrandel Is the "imported" resource specific to each environment? I use a different Cognito User Pool for each of my environments.

[amirmishani]

@renebrandel something I didn't see in the original RFC was extending Auth, API and Storage to use existing Lambdas. I really like AWS CDK and I want to create my Lambdas using CDK and Typescript. I want to be able to use these Lambdas (some are step functions, another feature amplify cli doesn't currently have) as resolvers for mutations or Auth Lambda triggers or DynamoDB triggers.

[warrenmcquinn]

I'm interested in making some modifications to an existing Amplify-managed Cognito User Pool (for example, enabling username case-insensitivity).
I'm unclear about how amplify import auth might help.

Would it be possible for us to create a new self-managed Cognito User Pool, import users from current Amplify-managed Cognito, and then amplify import that new self-managed Cognito into our prod environment?

Edit: I'm aware of this solution to import using a user migration lambda trigger. Would that be the best solution?

[renebrandel]

@renebrandel Is the "imported" resource specific to each environment? I use a different Cognito User Pool for each of my environments.

You’ll be asked to either import a different Cognito resource or maintain the same Cognito resource for your app’s auth category.

If you want to have Amplify manage your auth resources in a new environment, run amplify remove auth to unlink the imported Cognito resource and amplify add auth to create new Amplify-managed auth resources in the new environment.

https://docs.amplify.aws/cli/auth/import#multi-environment-support

[renebrandel]

@renebrandel something I didn't see in the original RFC was extending Auth, API and Storage to use existing Lambdas. I really like AWS CDK and I want to create my Lambdas using CDK and Typescript. I want to be able to use these Lambdas (some are step functions, another feature amplify cli doesn't currently have) as resolvers for mutations or Auth Lambda triggers or DynamoDB triggers.

That's a good call out. I think we should look into that for next year.

[renebrandel]

I'm interested in making some modifications to an existing Amplify-managed Cognito User Pool (for example, enabling username case-insensitivity).
I'm unclear about how amplify import auth might help.

Would it be possible for us to create a new self-managed Cognito User Pool, import users from current Amplify-managed Cognito, and then amplify import that new self-managed Cognito into our prod environment?

Edit: I'm aware of this solution to import using a user migration lambda trigger. Would that be the best solution?

I haven't tried it myself but if you are able to transfer the users out and want to fully manage the Cognito instance yourself, you could rereference that new Cognito instance through amplify import auth.

[renebrandel]

Also, just to provide an update, we've now enabled the ability to import S3 and DynamoDB tables to your Amplify project:

Read the blog post on how to import S3 buckets here: https://aws.amazon.com/blogs/mobile/use-an-existing-s3-bucket-for-your-amplify-project/
Docs on how to import existing S3 buckets and DynamoDB tables: https://docs.amplify.aws/cli/storage/import#import-an-existing-cognito-user-pool

[Simon323]

Hello everyone,
I created with my team serverless app on AWS. Currently our app is full control by AWS console. We have in plan create in back office to manage our app. For this purpose we want use Amplify, React and GraphQL. In my opinion amplify looks good because offer a lot of things out of the box.
Currently the main problem is that Amplify don't want work with existing component our app.
When I try create new GraphQL API which I want use in our new back office by command amplify add api I don't have option re-use existing tables in DynamoDB.
Amplify allow only for create new GraphQL API in AppSync with new tables in DynamoDB.
@renebrandel I saw your post a few days ago about import DynamoDB but info from this articles not resolve my issue.
I think that functionality which I need is that Ability to use existing DynamoDB tables as a part of @model directive as a part of the GraphQL transformer annotated schema
I understand that feature described above is not ready yet ?

[thiskevinwang]

What are they pre-requisites/criteria needed to be able to import Cognito User Pool and Identity Pool ?

• This is not documented
• How to debug the following error below is not documented either

With amplify import auth, I'm consistently getting getting:

(select my pre-existing UserPool)

❯ There are no Identity Pools found which has the selected Cognito User Pool configured as identity provider.

But, looking at my Identity Pool:

... anyone else in the same boat 🛶?

---

❌ amplify import auth, Cognito User Pool and Identity Pool + my UserPool doesn't work
✅ amplify import auth, Cognito User Pool only + my UserPool works

ultimately, I'm trying to amplify add storage but this auth part is blocking me!

[my-name-is-nheo]

Also, just to provide an update, we've now enabled the ability to import S3 and DynamoDB tables to your Amplify project:

Read the blog post on how to import S3 buckets here: https://aws.amazon.com/blogs/mobile/use-an-existing-s3-bucket-for-your-amplify-project/
Docs on how to import existing S3 buckets and DynamoDB tables: https://docs.amplify.aws/cli/storage/import#import-an-existing-cognito-user-pool

@renebrandel Worked like a charm ! thank you and to your team. in the mean time, are there any way of adding existing APIs from API gateway to Amplify? Manually? Been stuck at this for days.

[alionthego]

having same issue when trying to import Cognito User Pool and Identity Pool:
There are no Identity Pools found which has the selected Cognito User Pool configured as identity provider.
Did you find any solution for this @thiskevinwang ?

[beld2107]

I was able to solve this problem by adding the "Web App Client" and the "Native app Client" to the Identity Pool as shown in this page: https://aws.amazon.com/blogs/mobile/use-existing-cognito-resources-for-your-amplify-api-storage-and-more/

[nshyam97]

Ability to update and manage the imported Cognito user pool via the CLI as a part of the amplify update auth flow to add features like Lambda triggers to your existing Cognito user pool

How soon are we looking for this? I'm looking to add Admin Queries to an existing auth I've set up. Or if anyone has a resource to a workaround so I can pull in a list of users in the current group that would be ideal. I assume a lambda function is the way to go for this

[BeaveArony]

Ability to update and manage the imported Cognito user pool via the CLI as a part of the amplify update auth flow to add features like Lambda triggers to your existing Cognito user pool

How soon are we looking for this? I'm looking to add Admin Queries to an existing auth I've set up. Or if anyone has a resource to a workaround so I can pull in a list of users in the current group that would be ideal. I assume a lambda function is the way to go for this

Well, it's quite easy:

amplify auth update

You can add Admin Queries or Triggers there.

[RubberChickenParadise]

Ability to update and manage the imported Cognito user pool via the CLI as a part of the amplify update auth flow to add features like Lambda triggers to your existing Cognito user pool

How soon are we looking for this? I'm looking to add Admin Queries to an existing auth I've set up. Or if anyone has a resource to a workaround so I can pull in a list of users in the current group that would be ideal. I assume a lambda function is the way to go for this

Well, it's quite easy:

amplify auth update

You can add Admin Queries or Triggers there.

@BeaveArony you cant use the amplify update auth to add the admin queries on an imported cognito user pool. That is the issue I am also trying to solve.

[davidjaldred]

With API imports (hopefully) on the distant horizon, what is the current recommended way to add an existing AWS REST API to amplifyconfiguration.json (referring to this guide) so that everyone else in the team automatically has this config too? amplify push doesn't save it to the backend, so it can't be pulled down and has to be manually added by everyone. I asked in the discord, but just wanted to check here too.

My current solution is splitting the amplifyconfig string after "awsAPIPlugin": { and inserting the API config string. The result is passed to Amplify.configure(), and all of this is of course kept in Git so everyone automatically has the API config.

[rickwargo]

There is a lot of confusion in conflicting information for a person newly introduced to Cognito and Amplify. I'd like to bring in Auth to my existing React application, however, it is challenging to determine which is the correct path to follow. I believe most beneficial would be good documentation that outlines not only what needs to be done, but where and why. I'd love to see a schema for the auth section - it still confuses me. I think I understand what to call, but sometimes things appear in my sign up/sign in dialogs that I don't know how they got there (e.g. Sign in with AWS). There are multitudes of times where I cannot get the federated signin working. And the libraries are so exacting, but the documentation leaves some things up to interpretation and a bit of hope. I spent days trying to understand why something wasn't working and it turns out that I needed a trailing slash at the end of the URL, associated with the redirect query param. I was surprised to see my formatted signup dialog appear when I added that slash. A reference implementation would go hand-in-hand with the documentation. If you could deliver those two things, it would be a huge win for this library!

Things change so often. It took me a while to realize aws-amplify-react was the old library, even though there was plenty of information about if during the past few years. I'm not sure how you factor in ensuring newer projects are started with the latest and greatest, but that would also be helpful.

I don't want to use the amplify push/pull/update cli framework. I want to use my own, but leverage the great content in the associated libraries.

[rabi-palmtree]

Any progress on using Amplify CLI to import existing REST API ECS endpoints?
My workaround is to manually add the configuration to amplifyconfiguration.json (referring to this guide). Similar to @davidjaldred
I want to take advantage of Amplify Environments to pull this configuration for Dev/Staging/Production envs.
Still can't do that with amplify api command.
Help!

[rabi-palmtree]

Is there a way to increase the visibility/priority of this Amplify CLI issue.
It should not be hidden within a RFC. It seems more of a higher priority bug to me.
Will not most real world/"non hello world" usages of REST API with amplify run into this issue?

[Hovard]

With API imports (hopefully) on the distant horizon, what is the current recommended way to add an existing AWS REST API to amplifyconfiguration.json (referring to this guide) so that everyone else in the team automatically has this config too? amplify push doesn't save it to the backend, so it can't be pulled down and has to be manually added by everyone. I asked in the discord, but just wanted to check here too.

My current solution is splitting the amplifyconfig string after "awsAPIPlugin": { and inserting the API config string. The result is passed to Amplify.configure(), and all of this is of course kept in Git so everyone automatically has the API config.

I tried your way, add awsAPIPlugin (called ie. 'peopleAPI') but, i have no idea how configure react to recognize that API? amplify api push/update doesnt work.
When im using:
Amplify.API.post('peopleAPI', '/people', {
body: request,
headers: {
'Content-Type': 'application/json'
}
}).then(result => {
..
}).catch(error => {
..
});
I still get error: error: API peopleAPI does not exist. Can you be more specific how you workaround the problem with adding existing API?

[billygerhard]

We have some existing lambdas built using CDK, and we would love to import them into our amplify project, and then have amplify build an API Gateway around them so we can use the amplify authentication to call those lambdas built with CDK.

[cypherpower]

Would love to see this added. Also would like to see the amplify CLI support creation of python 3.10 lambdas instead of just python 3.8

[AliSMAmin]

Have an existing Lambda I manually build and would love to import it directly into Amplify.

[Jimgitsit]

Want this.