How to handle AWS Amplify Web App Security?

Replying to the below response. Question still completely unanswered. Seems like you haven't used Amplify if you can't understand how Amplify is configured on a client.

You create an amplify config and then you instantiate Amplify in your client, even if you use .env or any other client side secrets management, your process.env will still be exposed.

Which means any rogue developer could grab your User Pool ID, Identity Pool ID, and region and recreate your Amplify instance.

This is an actual concern.

This is quite a broad question (I'm on the fence about whether it's too broad for Stack Overflow). But here goes:

Protecting your (private) resources will require your website to have authentication (authN), and possibly also authorization (authZ). Check out this explanation of these concepts:

In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

I say you might need authZ because in the case where all users are allowed to do everything, then you might do both in the authN step.

The most common pattern of achieving this using Amplify is to use Cognito. Cognito has two main parts:

Cognito User Pools: handle authN. They are a repository of user identities, and Amplify uses them to get authentication tokens. They can outsource their real work of authentication to a 3rd-party Identity Provider, such as Google or Facebook.

Cognito Identity Pools: handle authZ. They are a mapping from user identities (bundled together in a user pool) to IAM credentials.

Cognito ID pools are not needed if you use API Gateway which can provide authZ directly from authentication tokens.

The primary vulnerability would seem to be that my Amplify config is exposed in the Angular code

This is a fundamental part of web development. Your front-end must always know which endpoints to use to authenticate and authorize. The trick here is that the endpoints are only useful if the user has credentials to authenticate. This is exactly the behavior of every login page on the web: anyone can try to log in to any public login page. But if you the user don't have credentials, the endpoint refuses to authenticate you.

In terms of other configuration, if you really want to you can wait until after authN/authZ to provide the front-end with information about where to find its resources such as Dynamo. But this might well be overkill; you should weigh carefully how paranoid you are, to determine whether it's worth hiding the identity of back-end resources which unauthorized users won't be able to access, anyway.

Edit in response to comments:

Can't a developer create an account through my app, use my Amplify config in their own app, authenticate with the account they created through my app, then have free range to my Amplify resources given they're authenticated?

Yup! A simpler way to do this is to authenticate to your app, take the resulting credentials, and use them directly via the console to manually execute operations. But again, this is a fundamental limitation of the client-server interaction: anything you give the front-end (including credentials) can be used in any way the front-end wants, because you can't control the front-end. The way around this is to limit the permissions you grant the user on the back-end: by strictly limiting the operations which credentials authorize the user to perform.

Another way of thinking about this is that even if you could prevent the user from using the credentials outside of your specific front-end page, they could script a bot to manually click buttons or input garbage. Because you can't control what actions the user will attempt, the only thing you can do is make sure they only succeed doing the things you want them to, by setting permissions accordingly.