Open the Amplify console. If you are in the process of deploying a new app, choose refresh, and then choose the role you just created. It should look like AmplifyConsoleServiceRole-AmplifyRole.
If you already have an existing app, you can find the service role setting in App settings > General and then choose Edit from the top right corner of the box. Pick the service role you just created from the dropdown and choose Save.
Confused deputy prevention
The Amplify console now has permissions to deploy backend resources.
Confused deputy prevention
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. For more information, see Cross-service confused deputy prevention (p. 140).
Currently, the default trust policy for the Amplify-Backend Deployment service role enforces the aws:SourceArn and aws:SourceAccount global context condition keys to prevent against confused deputy. However, if you previously created an Amplify-Backend Deployment role in your account, you can update the role's trust policy to add these conditions to protect against confused deputy.
Use the following example to restrict access to apps in your account. Replace the red italicized text in the example with your own information.
"Condition": { "ArnLike": {
"aws:SourceArn": "arn:aws:amplify:us-east-1:123456789012:apps/*"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
} }
For instructions on editing the trust policy for a role using the AWS Management Console, see Modifying a role (console) in the IAM User Guide.
Instant cache invalidation with instant deploys
Managing app performance
Amplify Console's default hosting architecture optimizes the balance between hosting performance and deployment availability. For more information, see the section called “Instant cache invalidation with instant deploys” (p. 107).
For advanced users that require finer control over an app's performance, Amplify Console supports performance mode. Performance mode optimizes for faster hosting performance by keeping content cached at the content delivery network (CDN) edge for a longer interval. For more information, see the section called “Performance mode” (p. 107).
Instant cache invalidation with instant deploys
Amplify Console supports instant cache invalidation of the CDN on every code commit. This enables you to deploy updates to your single page or static app instantly, without giving up the performance benefits of CDN caching.
For more information about how the Amplify Console handles cache invalidations, see the blog post AWS Amplify Console supports instant cache invalidation and delta deployments on every code commit.
Performance mode
Amplify Console performance mode optimizes for faster hosting performance by keeping content cached at the edge of the CDN for a longer interval. When performance mode is enabled, hosting configuration or code changes can take up to 10 minutes to be deployed and available.
Using headers to control cache duration
Performance mode is intended for advanced customers that require finer control over an app's performance. To optimize the balance between hosting performance and deployment availability, the default the section called “Instant cache invalidation with instant deploys” (p. 107) hosting architecture is recommended.
To enable performance mode for an app
1. Sign in to the AWS Management Console and open the Amplify Console.
2. Choose the app to enable performance mode for.
3. In the navigation pane, choose App settings, General.
4. In the General pane, scroll down to the Branches section. Select the branch that you want to to enable performance mode for.
5. Choose Action, Enable performance mode.
6. In the Enable performance mode dialog box, choose Enable performance mode.
Using headers to control cache duration
HTTP Cache-Control header max-age and s-maxage directives affect the content caching duration for your app. The max-age directive tells the browser how long (in seconds) that you want content to remain in the cache before it is refreshed from the origin server. The s-maxage directive overrides max-age and lets you specify how long (in seconds) that you want content to remain at the CDN edge before it is refreshed from the origin server. Note that apps hosted with Amplify Console honor and reuse the Cache-Control request headers sent by clients, unless they are overridden by a custom header that you define. Continue reading for a description of how to configure a custom header.
You can manually adjust the s-maxage directive to have more control over the performance and deployment availability of your app. For example, to increase the length of time that your content stays cached at the edge, you can manually increase the time to live (TTL) by updating s-maxage to a value longer than the default 600 seconds (10 minutes).
NoteWhen performance mode is enabled for an app, Amplify increases the maximum TTL, that you can set for the app using a custom header, from 10 minutes (600 seconds) to one day (86,400 seconds). Amplify caps the s-maxage that you can set using a custom header at one day. For example, if you set s-maxage to one week (604,800 seconds), Amplify uses the maximum TTL of one day.
You can define custom headers for an app in the Custom headers section of the Amplify Console. For more information, see Setting custom headers (p. 92). To specify a custom value for s-maxage, use the following YAML format. This example keeps the associated content cached at the edge for 3600 seconds (one hour).
Amplify information in CloudTrail
Logging Amplify API calls using AWS CloudTrail
AWS Amplify is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amplify. CloudTrail captures all API calls for Amplify as events. The calls captured include calls from the Amplify console and code calls to the Amplify API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amplify. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in Event history. Using the information that CloudTrail collects, you can determine the request that was made to Amplify, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the AWS CloudTrail User Guide.
Amplify information in CloudTrail
CloudTrail is enabled on your AWS account by default. When activity occurs in Amplify, that activity is recorded in a CloudTrail event along with other AWS service events in Event history. You can view, search, and download recent events in your AWS account. For more information, see Viewing events with CloudTrail Event history in the AWS CloudTrail User Guide.
For an ongoing record of events in your AWS account, including events for Amplify, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following in the AWS CloudTrail User Guide:
• Creating a trail for your AWS account
• CloudTrail supported services and integrations
• Configuring Amazon SNS notifications for CloudTrail
• Receiving CloudTrail log files from multiple regions and Receiving CloudTrail log files from multiple accounts
All Amplify operations are logged by CloudTrail and are documented in the AWS Amplify Console API Reference, the AWS Amplify Admin UI API Reference, and the Amplify UI Builder API Reference. For example, calls to the CreateApp, DeleteApp and DeleteBackendEnvironment operations generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
• Was the request made with root or AWS Identity and Access Management (IAM) user credentials.
• Was the request made with temporary security credentials for a role or federated user.
• Was the request made by another AWS service.
For more information, see the CloudTrail userIdentity element in the AWS CloudTrail User Guide.
Understanding Amplify log file entries
Understanding Amplify log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the Amplify Console API Reference DeleteBackendEnvironment operation.
{ "eventVersion": "1.08", "userIdentity": { "type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Mary_Major", "accountId": "444455556666",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": {
"invokedBy": "apigateway.amazonaws.com"
},
"eventTime": "2021-01-12T00:31:08Z", "eventSource": "amplify.amazonaws.com", "eventName": "DeleteBackendEnvironment", "awsRegion": "us-west-2",
"sourceIPAddress": "apigateway.amazonaws.com", "userAgent": "apigateway.amazonaws.com", "requestParameters": {
"environmentName": "staging", "appId": "d3lap6vexample"
},
"responseElements": { "backendEnvironment": {
"backendEnvironmentArn": "arn:aws:amplify:us-west-2:444455556666:apps/
d3lap6vexample/backendenvironments/staging", "createTime": 1610086829.109,
"deploymentArtifacts": "amplify-amplify9b7cd3example-staging-62027-deployment", "environmentName": "staging",
"stackName": "amplify-amplify9b7cd3example-staging-62027", "updateTime": 1610086829.109
} },
"requestID": "1135382e-f832-45ba-ae53-f7ffbexample", "eventID": "cebab152-deb6-42e1-bd1f-d05b6example", "readOnly": false,
"eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "444455556666"
Understanding Amplify log file entries
}
The following example shows a CloudTrail log entry that demonstrates the AWS Amplify Console API Reference ListApps operation.
{ "eventVersion": "1.08", "userIdentity": { "type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Mary_Major", "accountId": "444455556666",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "Mary_Major",
"eventTime": "2021-01-12T06:47:29Z", "eventSource": "amplify.amazonaws.com", "eventName": "ListApps",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "aws-internal/3 aws-sdk-java/1.11.898
Linux/4.9.230-0.1.ac.223.84.332.metal1.x86_64 OpenJDK_64-Bit_Server_VM/25.275-b01 java/1.8.0_275 vendor/Oracle_Corporation",
"requestParameters": { "maxResults": "100"
},
"responseElements": null,
"requestID": "1c026d0b-3397-405a-95aa-aa43aexample", "eventID": "c5fca3fb-d148-4fa1-ba22-5fa63example", "readOnly": true,
"eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "444455556666"
}
The following example shows a CloudTrail log entry that demonstrates the AWS Amplify Admin UI API Reference ListBackendJobs operation.
{
"eventVersion": "1.08", "userIdentity": { "type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Mary_Major", "accountId": "444455556666",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "Mary_Major",
Understanding Amplify log file entries
} },
"eventTime": "2021-01-13T01:15:43Z",
"eventSource": "amplifybackend.amazonaws.com", "eventName": "ListBackendJobs",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "aws-internal/3 aws-sdk-java/1.11.898
Linux/4.9.230-0.1.ac.223.84.332.metal1.x86_64 OpenJDK_64-Bit_Server_VM/25.275-b01 java/1.8.0_275 vendor/Oracle_Corporation",
"requestParameters": {
"appId": "d23mv2oexample",
"backendEnvironmentName": "staging"
},
"responseElements": { "jobs": [
"backendEnvironmentName": "staging"
},
"requestID": "7adfabd6-98d5-4b11-bd39-c7deaexample", "eventID": "68769310-c96c-4789-a6bb-68b52example", "readOnly": false,
"eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "444455556666"
}
Identity and Access Management
Security in Amplify
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from data centers and network architectures that are built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The shared responsibility model describes this as security of the cloud and security in the cloud:
• Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs.
To learn about the compliance programs that apply to AWS Amplify, see AWS Services in Scope by Compliance Program.
• Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using Amplify. The following topics show you how to configure Amplify to meet your security and compliance objectives. You also learn how to use other AWS services that help you monitor and secure your Amplify resources.
Topics
• Identity and Access Management for Amplify (p. 113)
• Cross-service confused deputy prevention (p. 140)
• Security event logging and monitoring in Amplify (p. 142)
• Data Protection in Amplify (p. 142)
• Compliance Validation for AWS Amplify (p. 143)
• Infrastructure Security in AWS Amplify (p. 144)
Identity and Access Management for Amplify
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be authenticated (signed in) and authorized (have permissions) to use Amplify resources. IAM is an AWS service that you can use with no additional charge.
Topics
• Audience (p. 114)
• Authenticating with identities (p. 114)
• Managing access using policies (p. 116)
• How Amplify works with IAM (p. 117)
• Identity-based policy examples for Amplify (p. 122)
• AWS managed policies for AWS Amplify (p. 124)
• Troubleshooting Amplify identity and access (p. 132)
• Amplify permissions reference (p. 134)
Audience
Audience
How you use AWS Identity and Access Management (IAM) differs, depending on the work that you do in Amplify.
Service user – If you use the Amplify service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Amplify features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in Amplify, see Troubleshooting Amplify identity and access (p. 132).
Service administrator – If you're in charge of Amplify resources at your company, you probably have full access to Amplify. It's your job to determine which Amplify features and resources your employees should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Amplify, see How Amplify works with IAM (p. 117).
IAM administrator – If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to Amplify. To view example Amplify identity-based policies that you can use in IAM, see Identity-based policy examples for Amplify (p. 122).
Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. For more information about signing in using the AWS Management Console, see Signing in to the AWS Management Console as an IAM user or root user in the IAM User Guide.
You must be authenticated (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role. You can also use your company's single sign-on authentication or even sign in using Google or Facebook. In these cases, your administrator previously set up identity federation using IAM roles.
When you access AWS using credentials from another company, you are assuming a role indirectly.
To sign in directly to the AWS Management Console, use your password with your root user email address or your IAM user name. You can access AWS programmatically using your root user or IAM users access keys. AWS provides SDK and command line tools to cryptographically sign your request using your credentials. If you don't use AWS tools, you must sign the request yourself. Do this using Signature Version 4, a protocol for authenticating inbound API requests. For more information about authenticating requests, see Signature Version 4 signing process in the AWS General Reference.
Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.
AWS account root user
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
IAM users and groups
An IAM user is an identity within your AWS account that has specific permissions for a single person or application. An IAM user can have long-term credentials such as a user name and password or a set of
Authenticating with identities
access keys. To learn how to generate access keys, see Managing access keys for IAM users in the IAM User Guide. When you generate access keys for an IAM user, make sure you view and securely save the key pair. You cannot recover the secret access key in the future. Instead, you must generate a new access key pair.
An IAM group is an identity that specifies a collection of IAM users. You can't sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named IAMAdmins and give that group permissions to administer IAM resources.
Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see When to create an IAM user (instead of a role) in the IAM User Guide.
IAM roles
An IAM role is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by switching roles. You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see Using IAM roles in the IAM User Guide.
IAM roles with temporary credentials are useful in the following situations:
• Temporary IAM user permissions – An IAM user can assume an IAM role to temporarily take on different permissions for a specific task.
• Federated user access – Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider. For more information about federated users, see Federated users and roles in the IAM User Guide.
• Cross-account access – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access.
However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access,
However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access,