Question: How do I troubleshoot invalid SAML response errors users might receive when they federate into Amazon Cognito?

I need to troubleshoot errors users might encounter when they federate into Amazon Cognito with Security Assertion Markup Language 2.0 (SAML 2.0).

Answer: "I need to troubleshoot errors users might encounter when they federate into Amazon Cognito with Security Assertion Markup Language 2.0 (SAML 2.0).ResolutionAmazon Cognito supports authentication with identity providers (IdPs) and SAML 2.0. There are common errors that users might encounter when federating into Amazon Cognito using SAML.Note: Throughout, replace <attribute_name> with the user attribute from your error scenario.View SAML responsesTo resolve common SAML federation errors, look at the SAML response sent from the IdP to the Amazon Cognito user pool. For instructions on how to capture and decode the SAML response, see viewing a SAML response in your browser.Note: The SAMLResponse element contains the base64-encoded request. A payload that has % characters indicates that the payload is URL-encoded in addition to base64. Perform URL decoding on the SAMLResponse value before sending it for base64 decoding.Resolve invalid SAML response errors"Invalid SAML response received: Invalid user attributes: <attribute_name>: The attribute is required."This error occurs when a user pool is configured with required attributes but the IdP isn't passing claims for required attributes. This error also occurs when attribute mapping isn't available for required attributes.Follow these steps to resolve the error:1.    Open the Amazon Cognito console.2.    Select your user pool.3.    Review the information about the user pool. Note the required attributes configured under Sign-up experience.4.    Retrieve and review the SAML response in your browser.5.    Check whether the IdP is passing all the required attribute claims in the response's AttributeStatement field. If the IdP isn't sending all required attributes in the SAML response, review your IdP's attribute mapping configuration. Make sure that your IdP is configured to send the correct mappings for required attributes.Note: Your IdP might offer sample SAML assertions for reference. You can check the assertions to obtain more details about the IdP's mapped attributes. Some IdPs use simple names for attribute mappings, such as an email address, while others use URL-formatted attribute names similar to this example:http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress6.    When the SAML response includes required attributes but you're still getting the same error, check the Amazon Cognito attribute mappings. When a mapping is missing for a required attribute, add a mapping to the attribute claim. For instructions on how to add attribute mappings, see Specifying identity provider attribute mappings for your user pool."Invalid SAML response received: Invalid user attributes: <attribute_name>: Required attribute cannot be deleted."This error occurs when a required attribute is changed in the IdP so that the required attribute is null or deleted. This error also occurs when a mapping is removed after a user is created.Follow these steps to resolve the error:1.    Open the Amazon Cognito console.2.    Select your Amazon Cognito user pool.3.    Review the information about the user pool. Note the configured required attributes.4.    Retrieve and review the SAML response in your browser.5.    Check whether the IdP is passing all required attribute claims in the response's AttributeStatement field. If the IdP isn't sending all required attributes in the SAML response, then review the IdP's attribute mapping configuration. Make sure that your IdP is set up to send required attributes with the correct mappings.6.    If all required attributes are passed with valid values in the SAML response, then check the IdP attribute mappings. Make sure that there are mappings for all required attributes.Note: You might encounter the following error during federation requests after an IdP's required attribute is deleted or changed to null: "Invalid SAML response received: Invalid user attributes: <attribute_name>: Required attribute cannot be deleted." This error also occurs when the mapping is removed after a user is created. To resolve this error, follow the previous steps to make sure that the mapping exists for required attributes. Then a correct value is passed for your required attributes from your IdP."Invalid SAML response received: Invalid user attributes: <attribute_name>: Attribute cannot be updated."This error occurs when an attribute is passed from the IdP but the mapped Amazon Cognito attribute is set to be immutable ("mutable" : "false"). You can't change an attribute's mutability settings after a user pool is created. To resolve this error, you need to remove the attribute mappings rule that maps the SAML attribute to an immutable attribute.Follow these steps to resolve the error:1.    Run the following AWS Command Line Interface (AWS CLI) command and note the attributes returned in the output. All the attributes returned in the output are immutable.Note: Replace <userpool_id> with your user pool ID.aws cognito-idp describe-user-pool --user-pool-id <userpool_id> --query 'UserPool.SchemaAttributes[?Mutable==`false`].Name'Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.2.    Open the Amazon Cognito console.3.    Review the SAML attribute mappings for your provider.4.    Check whether any of the SAML attributes are mapped to Amazon Cognito attributes returned in the command output. If there's a mapping to an immutable attribute, delete that mapping. If you're required to have that SAML attribute mapped, map it to any existing mutable attribute. You can also create a custom mutable attribute and map the SAML attribute to the custom mutable attribute.There's no workaround that you can perform on an existing user pool to delete a mapping because a mapped attribute is required. You must create a new user pool with the required mutability settings and migrate your users to the new user pool."Invalid SAML response received: SAML Response signature is invalid."This error occurs when the IdP changes the SAML signing certificate. To troubleshoot this issue, review the SAML response you receive when you federate into Amazon Cognito. Note the value given in the X509Certificate field. Compare this X509Certificate value in the SAML response with the X509Certificate value in the metadata XML file uploaded to Amazon Cognito for the IdP configuration. If the values are different, then it means the SAML signing certificate used by the IdP is updated.Follow these steps to resolve the error:1.    Navigate to your IdP's application configuration page and then fetch the updated metadata file.2.    Open the Amazon Cognito console.3.    Navigate to the configuration for your SAML IdP.4.    Replace the existing metadata file with the updated metadata file.-or-If your IdP offers SAML metadata through a public URL, then copy the metadata document URL. Paste that public URL instead of uploading a metadata file."Invalid SAML response received: Audience restriction in SAML Assertion does not allow it for urn:amazon:cognito:sp:xxxxxxxx."-or-"Invalid SAML response received: Application with identifier 'urn:amazon:cognito:sp:xxxxxxxx' was not found."Note: The error message differs based on the IdP.This error occurs when you incorrectly configure your entity ID on your IdP. This error also occurs when you use another user pool's URN as the entity ID.Follow these steps to resolve the error:1.    Open the Amazon Cognito console.2.    Choose User pools and then note your user pool ID.3.    Go to the IdP's SAML application settings and then configure the entity ID in the following format:Note: Replace <user_pool_id> with your Amazon Cognito user pool ID.urn:amazon:cognito:sp:<user_pool_id>"An error was encountered with the requested page."This error occurs on the Amazon Cognito Hosted UI page. When this error message isn't accompanied by any other error statements, it indicates that your application's Assertion Consumer Service (ACS) URL is configured incorrectly. Your IdP uses the ACS URL to send a SAML response to Amazon Cognito. The ACS URL follows this format:Note: Replace <your_user_pool_domain> with your user pool domain.https://<your_user_pool_domain>/saml2/idpresponseAmazon Cognito only supports POST binding for the endpoint. Your IdP must send SAML responses in the POST request to the endpoint. If you incorrectly configure this URL on your IdP's application, then your IdP sends the SAML response to an incorrect endpoint. This results in a 400 error and a federation failure.Follow these steps to resolve the error:1.    Go to your IdP's application configuration and set the ACS URL by using one of the following formats:Cognito domain:https://<your_user_pool_domain>.auth.<region>.amazoncognito.com/saml2/idpresponseCustom domain:https://<your_user_pool_domain>/saml2/idpresponse"An error was encountered with the requested page: Invalid relayState from identity provider."-or-"An error was encountered with the requested page: Invalid samlResponse or relayState from identity provider."This error occurs for the following reasons:The RelayState parameter is set to null by the IdP when a SAML response is sent to Amazon Cognito.The ACS URL in the SAML request isn't the same as the ACS URL configured in your IdP's application.Amazon Cognito generates a RelayState parameter when forwarding an authentication request to your IdP. This RelayState parameter must be returned by the IdP to Amazon Cognito after successfully authenticating.During SAML federation, a user pool acts as a service provider on behalf of your application. As a service provider, Amazon Cognito only supports service provider-initiated single-sign-on (SSO) flows. IdP-initiated flows aren't supported. When a federation request is initiated from your IdP, the IdP's required attribute is deleted or changed to null. A federation failure is the result that includes the error message previously mentioned.To resolve this error, initiate the federation request from Amazon Cognito instead of the IdP. To initiate federation from Amazon Cognito, take either of the following steps to start your authentication flow:Redirect users to the /login endpoint for signing in. The /login endpoint loads the login page and presents the client authentication options to users. Connect to the /login endpoint when users need to check different options to sign in to your applications and get redirected to the IdP.Send requests to the /oauth2/authorize endpoint for Amazon Cognito. The /oauth2/authorize endpoint is a redirection endpoint that supports two redirect destinations. When you include an identity_provider or idp_identifier parameter in the URL, your user is seamlessly redirected to the sign-in page for the IdP. You might use this option to skip the default layout of the hosted UI and to get directly redirected to the IdP page.The error also occurs when the ACS URL is different when a federation request for the same IdP application is from a different user pool. Follow these steps to investigate and resolve the error:1.    When you federate into Amazon Cognito, capture the HTTP Archive (HAR) file.2.    In your browser, on the Network tab, look for the request with a saml?SamlRequest entry and then open the request.3.    Copy the SAMLRequest provided in the request parameters.4.    Use your preferred SAML decoding tool to decode the SAMLRequest. Then, check whether the ACS URL sent in the SAMLRequest is the same as the one that's set on your IdP's application.The error is confirmed when the SAMLRequest values are different.5.    To resolve the error, check your IdP configuration. Make sure that the ACS URL set on your application is the same as the ACS URL sent in the SAMLRequest.The ACS URL is different when a federation request is generated for the same IdP application from a different user pool. Make sure that you start your federation request from the appropriate user pool.Follow"


Question: What do I need to know about CPU allocation in Amazon ECS?

I'm looking for information related to allocating CPU to tasks in Amazon Elastic Container Service (Amazon ECS).

Answer: "I'm looking for information related to allocating CPU to tasks in Amazon Elastic Container Service (Amazon ECS).Short descriptionWhen creating a task definition, you can define limits for CPU resources. These limits can be defined at the task-level and the container level.The overall performance of your Amazon ECS cluster is affected based on these limits. Depending on the Amazon ECS behaviors and your use case, you must adjust the CPU allocation values at the task level and the container level. Use the following information to determine the CPU allocation that meets your workload and application requirements.ResolutionAmazon ECS uses a standard unit of measure for CPU resources called CPU units. 1024 CPU units is the equivalent of 1 vCPU.For example, 2048 CPU units is equal to 2 vCPU.Note: When defining task definitions, you can also use 1 vCPU instead of 1024. When the task definition is registered, ECS translates the value into units.Task-level CPU allocationAmazon ECS tasks can be run on AWS Fargate or Amazon Elastic Compute Cloud (Amazon EC2) instances.When you set the cpu parameter on the task-level, you'll also be setting the maximum amount of CPU resources that your containers in a task are allowed.AWS FargateAWS Fargate requires a cpu parameter on the task level to allocate requested resources to the task. You can select the memory and cpu from predefined task sizes available for AWS Fargate. You can learn more about the different combinations under the Task CPU and memory section of the AWS Fargate Developer Guide.Amazon EC2When running tasks on Amazon EC2, the cpu parameter is optional.If you define the cpu parameter, consider the following:Your containers will have limited access based on the amount of cpu defined.The amount defined in your cpu parameter becomes the CPU reservation for the task to be scheduled on a container instance.Note: This is also true for the container-level definition.For example, a defined cpu parameter on Amazon EC2 with the following configuration will have 1024 CPU units left in its pool:An m5.large EC2 instance registered in an ECS cluster as a container instance for a total of 2048 CPU units.One task with cpu: 1024 at task-level defined is running on the instance.Current instance EC2 CPUUtilization is at 68%.The current CPUUtilization doesn't affect how many CPU Units are available in the container instance for task scheduling. Even if the instance exceeds 50% of its utilization, you will still have half of the units in its pool available for new tasks to start. This is because the parameter acts only as a CPU reservation and limit and doesn't translate directly to CPU usage itself.With this example, there are several results that can happen when taking only CPU into account:You can schedule two more tasks with cpu: 512 defined in either task-level or container-level definitions.You can schedule one task, with two containers, with cpu: 1024 defined at the task level and cpu: 512 defined at the container level in each container.If the cpu isn't defined, then you can schedule as many tasks as ECS supports for the network mode that you selected. The CPU units available in your ECS container instance for scheduling aren't affected.Container-level CPU allocationContainer-level cpu definitions are considered in the following scenarios:At Scheduling time:When the task-level cpu definition isn't set, then the total amount of CPU units defined in your containers becomes the CPU reservation.The total number of CPU units in your cpu container-level definition can't be larger than the CPU units defined at your task-level allocation.At Runtime, and there is no CPU contention:If Task-level cpu definition is set, then your containers have access only to cpu resources up to the task-level cpu defined value.If Task-level cpu definition isn't set, then the containers in your task have access to all the CPU resources available in your instance, regardless of the cpu definition set at the container level.If you're using Windows tasks and the cpu at task level isn't supported, then the containers are always capped to the definition of cpu at the container level.CPU contention happens when multiple processes are requesting cpu time. When CPU contention occurs, your containers are throttled to the amount of resources defined on your cpu at the container-level definition.**Important:**Be sure to verify if the application you are running on ECS is container aware. Some applications, such as Java 10, are container aware, and use only the limits defined in the container-level cpu definition, regardless of whether there is CPU contention.Container-level cpu definitions are mapped directly to the CpuShares parameters of the Create a Container remote docker API.Related informationHow can I allocate memory to tasks in Amazon ECS?Follow"


Question: How can I find the IP address ranges that Amazon S3 uses?

I don't know how to find the IP address ranges that Amazon Simple Storage Service (Amazon S3) uses.

Answer: "I don't know how to find the IP address ranges that Amazon Simple Storage Service (Amazon S3) uses.ResolutionFirst, download the JSON file that contains all AWS IP address ranges. Then, search the file for the string "service": "S3".On Linux or macOS machines, you can use a tool, such as the jq tool (on the GitHub website), to parse the JSON response. For example, the following command parses the JSON file for all IPv4 addresses that Amazon S3 uses:curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.service=="S3") | .ip_prefix'52.95.154.0/2352.219.64.0/2252.92.72.0/2252.92.64.0/2252.95.156.0/24....As another example, the following command parses the JSON response for all IPv4 addresses that Amazon S3 uses in a specific AWS Region (us-east-1):curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.region=="us-east-1") | select(.service=="S3") | .ip_prefix'54.231.0.0/1752.92.16.0/2052.216.0.0/15On Windows operating systems, you can use AWS Tools for PowerShell. The following Get-AWSPublicIpAddressRange command filters for all IPv4 and IPv6 addresses that Amazon S3 uses:Get-AWSPublicIpAddressRange -ServiceKey S3 | select IpPrefixIpPrefix--------52.47.73.72/2913.55.255.216/2952.15.247.208/29......2a05:d07c:2000::/402a05:d000:8000::/402406:dafe:2000::/40...For more examples, see Filtering the JSON file.Related informationAWS IP address rangesFollow"


Question: How can I use AWS Budgets to track my spending and usage?

I want to monitor and track my AWS cost and usage. How can I set a custom budget?

Answer: "I want to monitor and track my AWS cost and usage. How can I set a custom budget?ResolutionWith AWS Budgets, you can set custom budgets that proactively alert you when your costs exceed your budgeted amount.Consider the following when creating a budget:You can create two free budgets per account. For more information, see Quotas and restrictions.For a description of the different budget types available, see Managing your costs with AWS Budgets.For best practices using AWS Budgets, see Best practices for AWS Budgets.Create a cost budgetTo create a recurring fixed monthly cost budget, do the following:Open the AWS Billing and Cost Management console.On the navigation pane, choose Budgets.Choose Create budget.Select Cost budget. Then, choose Next.Under Details, enter a Budget name.Under Set budget amount, select Monthly from the list.Choose Recurring budget for Budget renewal type.Select a Start month.Select Fixed for Budgeting method.Enter a dollar amount for your budget in Enter your budgeted amount ($). For example, 50.00.Under Budget scope, select All AWS services.Note: For Advanced options, choose the options that are best for your use case, or leave the default settings.Choose Next.Choose Add an alert threshold.Under Set alert threshold, for Threshold, enter the amount that must be reached for you to be notified. This can be either an absolute value or a percentage.Under Set alert threshold, for Trigger, choose Actual to create an alert for your actual spend. Or, choose Forecasted to create an alert for your forecasted spend. You can set up multiple alert thresholds within the same Budget by choosing Add alert threshold.For example, suppose you have a budget of $50 and want to be notified when you are forecasted to exceed 80% of this amount. Enter 80, choose % of the budgeted amount, and then choose Forecasted as the Trigger.Under Notification preferences – Optional, select a notification method by Email recipients, Amazon SNS Alerts, or Amazon Chatbot Alerts. Your threshold must have at least one notification method or action configured.Choose Next.For Attach actions - Optional, you can configure an action that AWS Budgets performs on your behalf when the alert threshold is exceeded. For more information and instructions, see To configure a budget action.Choose Next.Review your budget settings, and then choose Create budget.View your budgetsTo view your budgets, do the following:Open the AWS Billing and Cost Management console.On the navigation pane, choose Budgets.To see the filters and cost variances for your budgets, choose the budget's name in your list of budgets.Note: For more information, see Reading your budgets.To view the budget history, choose **View in AWS Cost Explorer.**Note: After you create a budget, it might take up to 24 hours for the Cost Explorer graph to appear.AWS Budgets information is updated up to three times a day. Updates typically occur eight to twelve hours after the previous update.Delete a budgetImportant: You can't recover a budget after you delete it. If you delete a budget, all email notifications and notification subscribers that are associated with the budget are also deleted.To delete a budget, do the following:Open the AWS Billing and Cost Management console.On the navigation pane, choose Budgets.From your list of budgets, select one or more budgets that you want to delete.At the top of the page, choose Actions, and then choose Delete.Choose Confirm.Related informationReporting your budget metrics with budget reportsHow can I use Cost Explorer to analyze my spending and usage?Follow"


Question: How do I configure my Application Load Balancer TLS/SSL listeners to use ECDSA ciphers?

"My Application Load Balancer’s security policy lists RSA and ECDSA ciphers. But when I connect to my load balancer, I see only RSA ciphers selected."

Answer: "My Application Load Balancer’s security policy lists RSA and ECDSA ciphers. But when I connect to my load balancer, I see only RSA ciphers selected.Short descriptionYou can configure an Application Load Balancer HTTPS listener with multiple certificates. However, it requires a security policy. Each security policy contains ciphers for both RSA and ECDSA cryptographic algorithms. During the TLS handshake, the Application Load Balancer uses selection process logic to determine which Application Load Balancer certificate to use for the HTTPS connection. If the chosen certificate is created with RSA or ECDSA (elliptic curve) keys, then the Application Load Balancer uses RSA or ECDSA ciphers for encryption.ResolutionTo use ECDSA ciphers with your Application Load Balancer, complete the following steps:Create or import a new ECDSA certificate to ACM and bind it to an HTTPS listenerCreate a new ECDSA certificateFirst, determine your certificate requirements. Then, request an ECDSA certificate from AWS Certificate Manager (ACM).Import the ECDSA certificate to ACMAfter you work with your certificate authority to get the ECDSA certificate for your domain in .pem format, import your new ECDSA certificate to ACM.After you create or import your ECDSA certificate to ACM, associate your certificate with your Application Load Balancer.(Optional) Test your load balancer’s TLS listener for supported ciphersTo test which protocols and ciphers are used, use an open source command line tool, such as sslscan.Note: Using sslscan lets you get complete information for all ciphers without using an additional third-party utility. For example, if you use curl, then you must specify individual cipher suites. These require separate curl requests that specify TLS protocols and cipher suites.You can install and run the sslscan command on any Amazon Elastic Compute Cloud (Amazon EC2) Linux instance or from your local system. Make sure that the load balancer that you want to test accepts TLS connections from your source IP address.To use sslscan on an Amazon Linux EC2 instance, complete the following steps:1.    Activate the Extra Packages for Enterprise Linux (EPEL) repository.2.    Install sslscan on your Amazon EC2 Linux instance:sudo yum install sslscan3.    To scan your Application Load Balancer for supported ciphers, run the following command. Replace example.com with your domain name:[ec2-user@ ~]$ sslscan --show-ciphers example.com | grep AcceptedHere's an example output that shows the results of running a vulnerability scan on your Application Load Balancer. In this example, the load balancer uses a P-256 ECDSA certificate and default security policy:    Accepted  TLSv1  256 bits  ECDHE-ECDSA-AES256-SHA    Accepted  TLSv1  128 bits  ECDHE-ECDSA-AES128-SHA    Accepted  TLS11  256 bits  ECDHE-ECDSA-AES256-SHA    Accepted  TLS11  128 bits  ECDHE-ECDSA-AES128-SHA    Accepted  TLS12  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384    Accepted  TLS12  256 bits  ECDHE-ECDSA-AES256-SHA384    Accepted  TLS12  256 bits  ECDHE-ECDSA-AES256-SHA    Accepted  TLS12  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256    Accepted  TLS12  128 bits  ECDHE-ECDSA-AES128-SHA256    Accepted  TLS12  128 bits  ECDHE-ECDSA-AES128-SHAThe following example output features a load balancer with an RSA 2048 certificate and default security policy:    Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA    Accepted  TLSv1  256 bits  AES256-SHA    Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA    Accepted  TLSv1  128 bits  AES128-SHA    Accepted  TLS11  256 bits  ECDHE-RSA-AES256-SHA    Accepted  TLS11  256 bits  AES256-SHA    Accepted  TLS11  128 bits  ECDHE-RSA-AES128-SHA    Accepted  TLS11  128 bits  AES128-SHA    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-GCM-SHA384    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA384    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA    Accepted  TLS12  256 bits  AES256-GCM-SHA384    Accepted  TLS12  256 bits  AES256-SHA256    Accepted  TLS12  256 bits  AES256-SHA    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA256    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA    Accepted  TLS12  128 bits  AES128-GCM-SHA256    Accepted  TLS12  128 bits  AES128-SHA256    Accepted  TLS12  128 bits  AES128-SHAIf you correctly configured your ECDSA certificate on your Application Load Balancer, then your output shows the negotiated ECDHE-ECDSA-* cipher suites. If your output shows other cipher suites, then review and update your Application Load Balancer security policy.Follow"


Question: Why is my Aurora MySQL-Compatible DB cluster snapshot taking so long to restore?

"I want to restore an Amazon Aurora MySQL-Compatible Edition DB cluster snapshot, but it's taking a long time."

Answer: "I want to restore an Amazon Aurora MySQL-Compatible Edition DB cluster snapshot, but it's taking a long time.Short descriptionThe snapshot restore process for Amazon Aurora MySQL-Compatible Edition DB clusters involves a number of important tasks. For example, during this process an Aurora cluster is created, as is the highly available cluster volume. Process like status checks, storage and hardware allocation, and writing data volumes all contribute to the time it takes for a snapshot to be restored.Snapshot restore time is influenced by a number of factors:For Aurora clusters, a single is distributed across three Availability Zones (AZs) to provide high availability. When the Aurora cluster restores from the snapshot, it provisions storage in these three AZs. After the cluster becomes available, It then creates a further six copies within the cluster volume for storing data. Storage volume is striped across hundreds of storage nodes, and distributed over three different AZs.After the Aurora cluster is created, the cluster downloads data from Amazon Simple Storage Solution S3 (Amazon S3) to the storage nodes. The cluster does this before the data becomes available. Unlike the restore process for Amazon Relational Database Service (Amazon RDS) for MySQL instances, lazy loading doesn't occur after the restore.Aurora restores are non-linear. So, for example, you might restore two separate clusters, one with 1 GB of data and another with 10 GB of data. Instead of taking ten times as long, the larger data set takes only a little longer than the smaller data set to restore.Other processes within the restore include status checks, storage and hardware allocation, and writing data volumes. All of these processes are time consuming, but have to be performed precisely for best performance.ResolutionYou can use the Aurora cluster clone feature or the backtrack feature when you make changes to your Aurora databases, depending on your use case.Aurora cluster cloneUsing the Aurora cluster clone feature is the fastest way to create an identical copy of your current cluster. After the cloned cluster is created, you can test your changes against the cloned cluster without affecting the original cluster. If the test passes, you can apply changes to the original cluster.Note: It's still a best practice to take a snapshot of your cluster before you make any changes in a database.Here are some common use cases for cloning an existing Aurora cluster:You want to experiment with and assess the impact of changes like schema changes or parameter group changes.You want to perform workload-intensive operations like exporting data or running analytical queries.You want to create a copy of a production DB cluster in a non-production environment for development or testing.Aurora backtracking featureYou can also use the backtracking functionality for your Aurora clusters. Backtracking gives you the ability to rapidly undo errors by doing an in-place rewind of your data. Backtracking a DB cluster doesn't require the creation of a new DB cluster, so takes only a few minutes to complete.But, there are limitations of this feature. First, it's available only on clusters that were created with the feature turned on. So if your cluster doesn't have this feature turned on, then you need to perform a snapshot restore to turn on backtracking. Also, backtracking doesn't support binary log replication, and cross-Region replication must be tuned off before you can configure or use backtracking. The limit for a backtrack window is 72 hours.ConsiderationsThe Aurora cluster clone and backtrack features were introduced to improve Aurora restore time in certain use cases. But, taking regular snapshot is still a best practice, and it's a best practice that you take this approach before conducting any planned changes to a database.Also, make sure that no long-running write operations are running on the source database at the time of the snapshot, point-in-time, or clone. Any long-running DCL, DDL, or DML (open write transactions) can increase the time it takes for the restored database to become available.Related informationCloning a volume for an Amazon Aurora DB clusterBacktracking an Aurora DB clusterFollow"


Question: How do I resolve the "putClassificationExportConfiguration" error in Amazon Macie?

"I enabled Amazon Macie and tried to configure an Amazon Simple Storage Service (Amazon S3) repository for sensitive data discovery results. However, I received an error similar to the following:"putClassificationExportConfiguration: The operation can't be performed because you're not authorized to access the S3 bucket, the KMS key, or both.""

Answer: "I enabled Amazon Macie and tried to configure an Amazon Simple Storage Service (Amazon S3) repository for sensitive data discovery results. However, I received an error similar to the following:"putClassificationExportConfiguration: The operation can't be performed because you're not authorized to access the S3 bucket, the KMS key, or both."Short descriptionThis error message means that there are permission configuration issues with Macie.ResolutionCheck the permissions for the Amazon S3 bucket, AWS Key Management Service (AWS KMS) key, and AWS Identity and Access Management (IAM) policy.IAM permissions1.    Open the IAM console, and then choose Users.2.    Choose the User name, and then choose the Permissions tab.3.    Verify that the user is allowed to perform the following API actions:macie2:PutClassificationExportConfiguration s3:CreateBucket s3:GetBucketLocation s3:ListAllMyBuckets s3:PutBucketAcl s3:PutBucketPolicy s3:PutBucketPublicAccessBlock s3:PutObject kms:ListAliasesFor more information, see Verify your permissions.Amazon S3 permissionsMake sure that the Amazon S3 bucket policy has permissions similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Deny non-HTTPS access",      "Effect": "Deny",      "Principal": "*",      "Action": "s3:*",      "Resource": "arn:aws:s3:::<BUCKET>/*",      "Condition": {        "Bool": {          "aws:SecureTransport": "false"        }      }    },    {      "Sid": "Deny incorrect encryption header. This is optional",      "Effect": "Deny",      "Principal": {        "Service": "macie.amazonaws.com"      },      "Action": "s3:PutObject",      "Resource": "arn:aws:s3:::<BUCKET>/*",      "Condition": {        "StringNotEquals": {          "s3:x-amz-server-side-encryption-aws-kms-key-id": "<ARN OF KMS KEY>"        }      }    },    {      "Sid": "Deny unencrypted object uploads. This is optional",      "Effect": "Deny",      "Principal": {        "Service": "macie.amazonaws.com"      },      "Action": "s3:PutObject",      "Resource": "arn:aws:s3:::<BUCKET>/*",      "Condition": {        "StringNotEquals": {          "s3:x-amz-server-side-encryption": "aws:kms"        }      }    },    {      "Sid": "Allow Macie to upload objects to the bucket",      "Effect": "Allow",      "Principal": {        "Service": "macie.amazonaws.com"      },      "Action": "s3:PutObject",      "Resource": "arn:aws:s3:::<BUCKET>/*"    },    {      "Sid": "Allow Macie to use the getBucketLocation operation",      "Effect": "Allow",      "Principal": {        "Service": "macie.amazonaws.com"      },      "Action": "s3:GetBucketLocation",      "Resource": "arn:aws:s3:::<BUCKET>"    }  ]}AWS KMS permissionsMake sure that the AWS KMS key policy has permissions similar to the following:{  "Sid": "Allow Macie to use the key",  "Effect": "Allow",  "Principal": {    "Service": "macie.amazonaws.com"  },  "Action": [    "kms:GenerateDataKey",    "kms:Encrypt"  ],  "Resource": "*",  "Condition": {    "StringEquals": {      "aws:SourceAccount": "111122223333"    },    "ArnLike": {      "aws:SourceArn": [        "arn:aws:macie2:Region:111122223333:export-configuration:*",        "arn:aws:macie2:Region:111122223333:classification-job/*"      ]    }  }}For more information, see Troubleshooting errors.Note: It's a best practice to grant least privileges for only the permissions required to perform a task. For more information, see Grant least privilege.Related informationGetting started with Amazon MacieFollow"


Question: How do I set up an Application Load Balancer using the AWS Load Balancer Controller on an Amazon EC2 node group in Amazon EKS?

I want to set up an Application Load Balancer using the AWS Load Balancer Controller on an Amazon Elastic Compute Cloud (Amazon EC2) node group in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to set up an Application Load Balancer using the AWS Load Balancer Controller on an Amazon Elastic Compute Cloud (Amazon EC2) node group in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionThe following steps show you how to deploy the Application Load Balancer using the AWS Load Balancer Controller on an Amazon EC2 node group with Amazon EKS. To create a Network Load Balancer, see AWS Load Balancer Controller.The AWS Load Balancer Controller must be connected to an AWS service endpoint, such as AWS Identity and Access Management (IAM), EC2, AWS Certificate Manager (ACM), Elastic Load Balancing, Amazon Cognito, AWS WAF, or AWS Shield. This means that you must have an outbound internet connection for AWS Load Balancer Controller to work. For more information, see How do I configure my subnets for an Amazon EKS cluster?To deploy the AWS Load Balancer Controller on AWS Fargate, see How do I set up the AWS Load Balancer Controller on an Amazon EKS cluster for Fargate and deploy the 2048 game?ResolutionTag your subnets to allow auto discoveryTag the Amazon VPC subnets in your Amazon EKS cluster to allow your AWS Load Balancer Controller to autodiscover subnets when the Application Load Balancer resource is created.For public Application Load Balancers, you must have at least two public subnets in your cluster's VPC with the following tags:kubernetes.io/role/elbFor internal Application Load Balancers, you must have at least two private subnets in your cluster's VPC with the following tags:kubernetes.io/role/internal-elbNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, be sure that you’re using the most recent version of the AWS CLI.Create an OIDC identity provider for your clusterTo create an OpenID Connect (OIDC) identity provider for your cluster to use with AWS Identity and Access Management (IAM) roles for service accounts, use either eksctl or the AWS Management Console.You can also use the AWSL CLI to create an OIDC identity provider for your cluster. For example:ISSUER_URL=$(aws eks describe-cluster --name cluster-name \  --query "cluster.identity.oidc.issuer" --region region-name --output text)aws iam create-open-id-connect-provider \  --url ${ISSUER_URL} \  --thumbprint-list ca-thumbprint \  --client-id-list sts.amazonaws.com \  --region region-nameNote: Replace cluster-name with your cluster name, region-name with your AWS Region, and ca-thumbprint with the thumbprint of your root CA certificate. You can get the thumbprint of the root CA certificate that your cluster uses with oidc.eks.region-name.amazonaws.com.Create an IAM policy for the AWS Load Balancer ControllerThe Amazon EKS policy that you create allows the AWS Load Balancer Controller to make calls to AWS APIs on your behalf. It's a best practice to use AWS IAM roles for service accounts when you grant access to AWS APIs.1.    To download an IAM policy document for the AWS Load Balancer Controller from AWS GitHub, run one of the following commands based on your Region.All Regions other than China Regions:curl -o iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json-or-Beijing and Ningxia China Regions:curl -o iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy_cn.json2.    To create an IAM policy named AWSLoadBalancerControllerIAMPolicy for your worker node instance profile, run the following command:aws iam create-policy \    --policy-name AWSLoadBalancerControllerIAMPolicy \    --policy-document file://iam-policy.json3.    Note the Amazon Resource Name (ARN) of the policy that's returned in the output from step 2.4.    Use the existing IAM role or create a new IAM role for the AWS Load Balancer Controller.Tip: To create an IAM role with eksctl, use the --attach-policy-arn parameter with the ARN of the IAM policy AWSLoadBalancerControllerIAMPolicy.5.    To attach AWSLoadBalancerControllerIAMPolicy to IAM roles that you identified earlier, run the following command:aws iam attach-role-policy \--policy-arn arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \--role-name role-nameNote: Replace 111122223333 with your AWS account ID and role-name with your IAM role name.Deploy the AWS Load Balancer Controller1.    Verify that you have the required tags for the load balancer associated with your subnets.2.    Install cert-manager so that you can inject the certificate configuration into the webhooks.For Kubernetes 1.16 or later:kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/$VERSION/cert-manager.yamlFor Kubernetes 1.15 or earlier:kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/$VERSION/cert-manager-legacy.yamlNote: Replace $VERSION with the version (from the Jetstack GitHub site, for example 'v1.6.0') of the cert-manager that you want to deploy.3.    In the downloaded manifest file for the AWS Load Balancer Controller from AWS GitHub, run the following command:curl -Lo ingress-controller.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/$VERSION/v2_4_1_full.yamlNote: Replace $VERSION with the version (from the Kubernetes SIGs GitHub site for example 'v2.4.1') of the AWS Load Balancer Controller that you want to deploy.4.    Edit the cluster-name for your cluster. For example:spec:    containers:    - args:        - --cluster-name=your-cluster-name # edit the cluster name        - --ingress-class=alb5.    Update only the ServiceAccount section of the file only. For example:apiVersion: v1kind: ServiceAccountmetadata:  labels:    app.kubernetes.io/component: controller    app.kubernetes.io/name: aws-load-balancer-controller  annotations:                                                                        # Add the annotations line    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/role-name              # Add the IAM role  name: aws-load-balancer-controller  namespace: kube-systemNote: Replace 111122223333 with your AWS account ID and role-name with your IAM role name.6.    To deploy the AWS Load Balancer Controller, run the following command:kubectl apply -f ingress-controller.yamlDeploy a sample application to test the AWS Load Balancer ControllerDeploy a sample application to verify that the AWS Load Balancer Controller creates a public Application Load Balancer because of the Ingress object.1.    To deploy a game called 2048 as a sample application, run the following command:kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/$VERSION/docs/examples/2048/2048_full.yamlNote: Replace $VERSION with the version (from the Kubernetes SIGs GitHub site for example 'v2.3.0') of the AWS Load Balancer Controller that you want to deploy.2.    To verify that the Ingress resource was created, wait a few minutes, and then run the following command:kubectl get ingress/ingress-2048 -n game-2048You receive output similar to the following:NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGEingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.us-west-2.elb.amazonaws.com   80      2m32sIf your Ingress isn't created after several minutes, then run the following command to view the AWS Load Balancer Controller logs:kubectl logs -n kube-system   deployment.apps/aws-load-balancer-controllerNote: AWS Load Balancer Controller logs can show error messages to help you troubleshoot issues with your deployment.3.    To see the sample application, open a web browser, and then go to the URL address from the output in step 2.4.    To clean up the sample application, run the following command:kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/$VERSION/docs/examples/2048/2048_full.yamlNote: Replace $VERSION with the version (from the Kubernetes SIGs GitHub site for example 'v2.3.0') of the AWS Load Balancer Controller that you want to deploy.Follow"


Question: How do I troubleshoot the error "InvalidIdentityToken - OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint" when I'm using the Amazon EKS IAM role to access the service account?

"The thumbprint for my Amazon Elastic Kubernetes Service (Amazon EKS) cluster has changed, causing the Application Load Balancer controller to fail updates.-or-My Amazon EKS pods are in failed state with the following error: "WebIdentityErr: failed to retrieve credentials\r\ncaused by: InvalidIdentityToken: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint\r\n"."


Question: How do I CC another email address on account-related correspondence from AWS?

"I'd like a copy of my account-related emails to be sent to another email address, as well as the root email address associated with my account."

Answer: "I'd like a copy of my account-related emails to be sent to another email address, as well as the root email address associated with my account.ResolutionYou can designate a specific email address to receive account-related correspondence by adding that email address as an alternate contact in your AWS account. For instructions, see Adding, changing, or removing alternate contacts.The available alternate contact types are Billing, Operations, and Security. Each email address added to the account receives correspondence only related to their contact type. For example, a Billing alternate contact receives notifications of finalized AWS bills.Related informationWhat is AWS Billing and Cost Management?Consolidated billing for AWS OrganizationsFollow"


Question: Why is it taking so long to restore a snapshot of my Amazon RDS for MySQL DB instance?

I'm trying to restore a snapshot of my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. Why is it taking so long?

Answer: "I'm trying to restore a snapshot of my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. Why is it taking so long?Short descriptionLong snapshot restore times are typically caused by long database recoveries. The recovery time depends on workload on your instance when snapshot was taken. If your source DB instance has binary logging enabled, then recovery might take longer. As a result, your snapshot restore duration can also be impacted.ResolutionWhen you restore a snapshot, Amazon RDS performs a recovery process and the MySQL DB engine is started on a new DB instance. The new DB instance start can take up to a few minutes, depending on the length of the recovery session during an instance startup. For more information, see InnoDB crash recovery on the MySQL website.Note: You'll experience some latency (or lazy loading) until the volume is fully hydrated from Amazon Simple Storage Service (Amazon S3). For more information about lazy loading, see Restoring from a snapshot.To reduce the snapshot restore completion time in Amazon RDS, consider the following approaches:Schedule a backup window or take a manual snapshot of your DB instance during off-peak hours. Activities performed on the source DB instance while taking a snapshot affects the database recovery time and any snapshot restore times.If a source instance is using the magnetic storage type during a snapshot, then the newly restored instance will be in a modifying state. For example, when you restore a DB snapshot as a General Purpose SSD (GP2) or Provisioned IOPS (PIOPS) storage type, the underlying volume change occurs. As a result, your new instance indicates a "modifying" state. During this time, you can still connect to an Amazon RDS instance, although you might experience some performance degradation.Temporarily restore your instance to a higher DB instance class (such as an instance class that has more memory or RAM). By upgrading the DB instance class, crash recovery times can be improved. You temporarily gain more resources, which can help speed up the overall crash recovery time. After the snapshot restore completes, you can scale down the instance class.To reduce the snapshot restore completion time for snapshots with binary logging enabled in Amazon RDS, consider the following:When binary logging is enabled (such as when the source instance has automated backups enabled), binary logs directly affect the snapshot restore time. During crash recovery, the snapshot restore process also performs a binary log recovery.To decrease binlog recovery times, avoid large transactions and large binlog files. The more data that is logged in the binary logs, the more data that the restore process must process during a binlog recovery. As a result, recovery time is increased, which also increases snapshot restore times.Use the correct transaction size whenever possible. Large transactions are written to the binary log file at one time, and are not split up amongst different files. As a result, the binary log file ends up being large, increasing the crash recovery time.The type of binary logging format used can also impact the size and efficiency of recovery. Some formats (such as row-based logging) log more information than others in the binary logs. Statements that modify a large number of rows in a table causes the DB engine to generate binlog entries for every modified row. As a result, you'll get a large binlog file. For more information about the row-based logging format, see Usage of row-based logging and replication on the MySQL website. For more information about the different types of binary logging formats, see Advantages and disadvantages of statement-based and row-based replication on the MySQL website.Follow"


Question: How do I set up Auth0 as a SAML identity provider with an Amazon Cognito user pool?

I want to use Auth0 as Security Assertion Markup Language 2.0 (SAML 2.0) identity provider (IdP) with an Amazon Cognito user pool. How do I set that up?

Answer: "I want to use Auth0 as Security Assertion Markup Language 2.0 (SAML 2.0) identity provider (IdP) with an Amazon Cognito user pool. How do I set that up?Short descriptionAmazon Cognito user pools allow signing in through a third party (federation), including through a SAML IdP such as Auth0. For more information, see Adding user pool sign-in through a third party and Adding SAML identity providers to a user pool.A user pool integrated with Auth0 allows users in your Auth0 application to get user pool tokens from Amazon Cognito. For more information, see Using tokens with user pools.To set up Auth0 as SAML IdP, you need an Amazon Cognito user pool with an app client and domain name and an Auth0 account with an Auth0 application on it.ResolutionCreate an Amazon Cognito user pool with an app client and domain nameFor more information, see the following articles:Tutorial: Creating a user poolNote: When creating a user pool, the standard attribute email is selected by default. For more information about user pool attributes, see User pool attributes.Setting up the hosted UI with the Amazon Cognito consoleNote: When adding an app client, you can clear the Generate client secret check box. An app client secret isn't required and using an app client secret prevents the Amazon Cognito JavaScript (browser) SDK from authenticating users.Adding a domain name for your user poolSign up for an Auth0 accountEnter your email address and a password on the Auth0 Sign Up page to get started. If you already have an account, then log in.Create an Auth0 applicationOn the Auth0 website dashboard, choose Applications, and then choose Create Application.In the Create Application dialog box, enter a name for your application. For example, My App.Under Choose an application type, choose Single Page Web Applications.Choose Create.Create a test user for your Auth0 applicationOn the left navigation bar, choose User Management, and then choose Users.Choose Create Your First User. Or, if this isn't your first user, choose Create User.In the Create user dialog box, enter an email and password for the user.Choose Save.Configure SAML settings for your applicationOn the left navigation bar, choose Applications.Choose the name of the application you created.On the Addons tab, turn on SAML2 Web App.In the Addon: SAML2 Web App dialog box, on the Settings tab, for Application Callback URL enter: https://yourDomainPrefix.auth.region.amazoncognito.com/saml2/idpresponse.Note: Replace yourDomainPrefix and region with the values for your user pool. Find them in the Amazon Cognito console on the Domain name tab of the management page for your user pool.-or-Enter a custom domain callback URL similar to the following: https//yourCustomDomain/saml2/idpresponse. For more information, see Adding a custom domain to a user pool.Under Settings, do the following:For audience, delete the comment delimiter (//) and replace the default value (urn:foo) with urn:amazon:cognito:sp:yourUserPoolId.Note: Replace yourUserPoolId with your Amazon Cognito user pool ID. Find the ID in the Amazon Cognito console on the General settings tab of the management page for your user pool.For mappings and email, delete the comment delimiters (//). Do the same for any other attributes required by your Amazon Cognito user pool. For more information, see User pool attributes.For nameIdentifierFormat, delete the comment delimiters ( //). Replace the default value (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified) with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.(Optional) Choose Debug, then log in as the test user you created to confirm that the configuration works.Choose Enable, and then choose Save.Get the IdP metadata for your Auth0 applicationIn the Addon: SAML2 Web App dialog box, on the Usage tab, find Identity Provider Metadata. Then, do either of the following:Right-click download, and then copy the URL.Choose download to download the .xml metadata file.Configure Auth0 as SAML IdP in Amazon CognitoFor more information, see Creating and managing a SAML identity provider for a user pool. Follow the instructions under To configure a SAML 2.0 identity provider in your user pool.When creating the SAML IdP, for Metadata document, either paste the Identity Provider Metadata URL or upload the .xml metadata file.Map email address from IdP attribute to user pool attributeFor more information, see Specifying identity provider attribute mappings for your user pool and follow the instructions under To specify a SAML provider attribute mapping.When adding a SAML attribute, for SAML Attribute, enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. For User pool attribute, choose Email from the list.Change app client settings in Amazon CognitoIn the Amazon Cognito console management page for your user pool, under App integration, choose App client settings. Then do the following:Under Enabled identity providers, select the Auth0 and Cognito User Pool check boxes.For Callback URL(s), enter a URL where you want your users to be redirected after logging in. For testing, you can enter any valid URL, such as https://www.amazon.com.For Sign out URL(s), enter a URL where you want your users to be redirected after logging out. For testing, you can enter any valid URL, such as https://www.amazon.com.Under Allowed OAuth Flows, be sure to select at least the Implicit grant check box.Under Allowed OAuth Scopes, be sure to select at least the email and openid check boxes.Choose Save changes.For more information, see App client settings terminology.Test the login endpointEnter this URL in your web browser: https://<yourDomainPrefix>.auth.<region>.amazoncognito.com/login?response_type=token&client_id=<yourClientId>&redirect_uri=<redirectUrl>Note: Replace yourDomainPrefix and region with the values for your user pool. Find them in the Amazon Cognito console on the Domain name tab of the management page for your user pool.Replace yourClientId with your app client's ID, and replace redirectUrl with your app client's callback URL. Find them in the Amazon Cognito console on the App client settings tab of the management page for your user pool.For more information, see How do I configure the hosted web UI for Amazon Cognito? and Login endpoint.Choose Auth0.Note: If you're redirected to your app client's callback URL, you're already logged in to your Auth0 account in your browser. The user pool tokens appear in the URL in your web browser's address bar.On the login page for your Auth0 application, enter the email and password for the test user you created.Choose Log in.After you log in, you're redirected to your app client's callback URL. The user pool tokens appear in the URL in your web browser's address bar.Related informationIntegrating third-party SAML identity providers with Amazon Cognito user poolsSAML user pool IdP authentication flowHow do I set up a third-party SAML identity provider with an Amazon Cognito user pool?Follow"


Question: What do I do if I receive a bill from AWS but can't find the resources related to the charges?

"I’m receiving a monthly bill from AWS, but I can’t find the resources that are generating the charges."

Answer: "I’m receiving a monthly bill from AWS, but I can’t find the resources that are generating the charges.Short descriptionThe resources that generate charges might not be visible to you due to the following reasons:You have active resources in your account that you are not aware of.The charges are being generated by resources on another account.You might not have permissions to view the resources that are generating charges.The resources generated charges earlier in the month but have since been terminated or deleted.ResolutionYou have active resources in your account that you are not aware ofTo check the resources that are generating charges in your account, do the following:Open the AWS Billing and Cost Management console.In the navigation pane, on the left side of the screen, choose Bills.The Details section shows all the charges that are being incurred by various AWS services on your account. If you see charges for a service, then that service is generating charges.If you use the consolidated billing feature in AWS Organizations, then the Bills page lists totals for all accounts on the Consolidated Bill Details tab. Choose the Bill Details by Account tab to see the activity for each account in the organization.Note: It’s a best practice to check the Details section for the previous month to identify all services that are generating charges.Under Details, expand each service to identify the Regions where the services have incurred charges.Note: The Billing and Cost Management console takes about 24 hours to update usage and charge information for active resources.You can use the AWSSupport-ListEC2Resources AWS Systems Manager Automation document to list your active Amazon Elastic Compute Cloud (Amazon EC2) resources. This automation document returns information on Amazon EC2 instances and related resources, such as Amazon Elastic Block Store (Amazon EBS) volumes, Elastic IP addresses, and Amazon EC2 Auto Scaling groups from the AWS Regions that you specify. By default, the information is gathered from all Regions and displayed in the output. To run this automation, follow the instructions in Running a simple automation.In addition, you can use the AWS Cost and Usage Report or the AWS Cost Explorer to check your usage of resources.After identifying your active resources in different Regions, terminate resources that you no longer need by opening the respective service console. For more information, see Why was I charged by Amazon Web Services when I don't have an AWS account?The charges are being generated by resources on another accountCheck any other AWS accounts that you might have. You can run the AWSSupport-ListEC2Resources automation on your other AWS accounts to check if there are active EC2 resources in these accounts.For information on how to find an account associated with AWS charges, see Why was I charged by Amazon Web Services when I don't have an AWS account?You might not have permissions to view the resources that are generating chargesIf you sign in to an AWS account as an AWS Identity and Access Management (IAM) user, you might not have permission to view the resources that are generating charges. Ask your account administrator to grant you permissions to view those resources. For a general explanation of IAM permissions and policies, see Overview of access management: Permissions and policies.If you're signed in to a member account in an organization, then the charges might be related to resources on another account in the organization's consolidated bill. Ask the owner of that account for more information about the resources on the account.The resources generated charges earlier in the month, but have since been terminated or deletedThe charges in the Billing and Cost Management console represent your total usage for a given month. If the resources generated charges earlier in the month, but are later stopped or terminated, they are no longer visible in the AWS Management Console for that service.You can check the AWS Cost and Usage report or AWS Cost Explorer to be sure that the resources are no longer generating charges.Related informationViewing your monthly chargesWhat are AWS Cost and Usage Reports?Analyzing your costs with Cost ExplorerHow do I use the AWS Cost and Usage Report?AWS pricingFollow"


Question: How can I run the CodeDeploy agent with a user profile that's not the root profile?

I want to run the AWS CodeDeploy agent with a user profile that's not the root profile.

Answer: "I want to run the AWS CodeDeploy agent with a user profile that's not the root profile.Short descriptionTo run the CodeDeploy agent with a user profile that's not the root profile, do the following:1.    (Prerequisite) Verify that the CodeDeploy agent is installed on your Amazon Elastic Compute Cloud (Amazon EC2) instance.2.    Change the user in your CodeDeploy agent configuration file and grant the user the required permissions.3.    Create an Amazon EC2 launch configuration template and Auto Scaling group to automate the user change process.4.    Test the setup by verifying that the CodeDeploy agent is installed and running with the correct user on your Amazon EC2 instance.Note: These steps apply to instances that use the Amazon Linux 1 or Amazon Linux 2 Amazon Machine Image (AMI). However, the Amazon Linux 1 AMI is in maintenance support status. In this status, the AMI receives only receive critical and important security updates for a reduced set of packages. The AMI is also no longer guaranteed to support new EC2 platform capabilities or new AWS features.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent AWS CLI version.(Prerequisite) Verify that the CodeDeploy agent is installed on your Amazon EC2 instanceFollow the instructions in Verify the CodeDeploy agent is running in the CodeDeploy User Guide.For instructions on how to install the CodeDeploy agent, see Install the CodeDeploy agent.Change the user in your CodeDeploy agent configuration file and grant the user the required permissions1.    Connect to your Amazon EC2 instance using SSH.2.    Stop the CodeDeploy host agent that's installed on the instance by running the following command:sudo service codedeploy-agent stop3.    Change the user in the CodeDeploy agent configuration file by running the following sed stream editor command:Important: Replace ec2-user with the user name that you want the CodeDeploy host agent to run on.sudo sed -i 's/""/"ec2-user"/g' /etc/init.d/codedeploy-agentImportant: For Amazon Linux 2 AMIs, you must also run the following two commands:sudo sed -i 's/#User=codedeploy/User=ec2-user/g' /usr/lib/systemd/system/codedeploy-agent.servicesudo systemctl daemon-reload4.    Grant the new user permissions to the required directories by running the following two commands:Important: Replace ec2-user with the user name that you want the CodeDeploy host agent to run on.sudo chown ec2-user:ec2-user -R /opt/codedeploy-agent/sudo chown ec2-user:ec2-user -R /var/log/aws/5.    Restart the CodeDeploy agent and confirm that your updates to the configuration file were successful by running the following two commands:sudo service codedeploy-agent startsudo service codedeploy-agent statusSuccessful command output exampleThe AWS CodeDeploy agent is running as PID ####6.    Verify what processes are running and which user is running these processes by running the following command:ps aux | grep codedeploy-agentCreate an Amazon EC2 launch configuration template and Auto Scaling group to automate the user change processTo confirm that the CodeDeploy agent is installed and running with the correct user when new instances are launched, do the following:1.    Open the Amazon EC2 console.2.    On the navigation pane, choose Launch Configurations.3.    Choose Create launch configuration.4.    Select the Amazon Linux AMI.5.    Choose Next: Configure details.6.    For IAM role, choose a preconfigured AWS Identity and Access Management (IAM) role. The role must grant your EC2 instance permission to access Amazon Simple Storage Service (Amazon S3) resources.7.    Choose Advanced Details.8.    In the User data section of the agent configuration file, enter the commands to install the CodeDeploy agent. Then, update the file to use a specific user.Agent configuration file exampleImportant: Replace ec2-user with the user name that you want the CodeDeploy host agent to run on. The following example code runs automatically when a new instance is launched that's using the defined launch configuration.#!/bin/bashREGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')yum -y updateyum install ruby wget -ycd /home/ec2-userwget https://aws-codedeploy-$REGION.s3.amazonaws.com/latest/installchmod +x ./install./install autoservice codedeploy-agent stop#adduser username <--- this is only required if you use a username that does not already existsed -i 's/""/"ec2-user"/g' /etc/init.d/codedeploy-agent#sed -i 's/#User=codedeploy/User=ec2-user/g' /usr/lib/systemd/system/codedeploy-agent.service  <--- Uncomment this line for Amazon Linux 2systemctl daemon-reloadchown ec2-user:ec2-user -R /opt/codedeploy-agent/chown ec2-user:ec2-user -R /var/log/aws/service codedeploy-agent start9.    Complete the remaining steps in the AWS Launch Wizard as needed. Then, choose Create launch configuration.10.    Choose Create an Auto Scaling group using this launch configuration.11.    For Group name, enter a name for your Auto Scaling group.12.    For Subnet, enter a subnet that allows your instance to access the internet.13.    Choose Next: Configure scaling policies. Then, choose a policy based on your needs.14.    Complete the rest of the steps in the Launch Wizard. Then, choose Create Auto Scaling Group.Test the setup by verifying that the CodeDeploy agent is installed and running with the correct user on a new Amazon EC2 instanceConfirm that your Amazon EC2 instance is running. Then, do the following:1.    Connect to your Amazon EC2 instance using SSH.2.    Verify that the CodeDeploy agent is running on the Amazon EC2 instance by running the following command:sudo service codedeploy-agent status3.    Verify that the CodeDeploy agent is running on the correct user name by running the following command:ps aux | grep codedeploy-agentSuccessful command output exampleThe AWS CodeDeploy agent is running as PID ####Follow"


Question: How do I resolve the AWS CloudFormation error "Cannot update a stack when a custom-named resource requires replacing"?

"When I try to update an AWS CloudFormation stack, I get an error message similar to the following: "CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename 'MYResourceXXX' and update the stack again." How can I resolve this error?"

Answer: "When I try to update an AWS CloudFormation stack, I get an error message similar to the following: "CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename 'MYResourceXXX' and update the stack again." How can I resolve this error?Short descriptionThis error typically occurs when a stack update tries to replace resources that have properties with custom names. AWS CloudFormation doesn't replace a resource that has a custom name unless that custom name is changed to a different name. To prevent a stack failure and avoid the error message, change any resources with custom names to use different names before you update a stack.The resolution for this error assumes the following:You're updating an existing stack and not creating a new stack.You're changing the names of existing custom-named resources and not creating new custom-named resources.Resolution1.    In a code editor, open the AWS CloudFormation template for the stack that you want to update.2.    Replace the names, or values, of any resource properties that have custom names with different names.Note: In the following example, the DBInstanceIdentifier property of the MyRDS resource is set to the custom name PRODdb. The AWS CloudFormation stack can't be successfully updated until the name PRODdb is changed to a different name, such as PRODdb1. Or, you can omit the DBInstanceIdentifier property from your template. That way, AWS CloudFormation generates a unique physical ID to use for the DB instance."MyRDS": {    "Type": "AWS::RDS::DBInstance",    "Properties": {        "DBInstanceClass": "db.m3.medium",        "Engine": "MySQL",        "DBInstanceIdentifier": "PRODdb",        "AllocatedStorage": "10",        "AutoMinorVersionUpgrade": "true",        "BackupRetentionPeriod": "0",    …    …    }}Important: When you rename a custom-named resource, AWS CloudFormation replaces that resource. For more information, see Name type. Replacement of certain resources can cause data loss without proper backup. For more information, see Replacement.3.    Save the changes to your AWS CloudFormation template, and then use the template to update your stack.Related informationAWS CloudFormation stacks updatesUpdate behaviors of stack resourcesAWS resource and property types referenceFollow"


Question: How do I turn on Multi-AZ with automatic failover in my ElastiCache for Redis cluster?

I want to improve fault tolerance for my ElastiCache for Redis cluster. What are the benefits of Multi-AZ and automatic failover and how do I turn them on?

Answer: "I want to improve fault tolerance for my ElastiCache for Redis cluster. What are the benefits of Multi-AZ and automatic failover and how do I turn them on?ResolutionBenefits of Multi-AZ with automatic failoverThe main benefits of using Multi-AZ set up with automatic failover are the minimization of administrative needs and enhancing the availability of your cluster. When Multi-AZ and automatic failover are turned on, Amazon ElastiCache automatically detects failure. ElastiCache then promotes one of the replica nodes as a new primary without your involvement.Having both the primary and replica nodes in the same Availability Zone doesn't make your Redis replication group resilient to Availability Zone disruption. Redis clusters with Multi-AZ turned on can have nodes in different Availability Zones. In the event of Availability Zone failure, your primary node fails over to another Availability Zone if automatic failover is turned on.You're covered by the Amazon ElastiCache Service Level Agreement that's provided to clusters with the Multi-AZ feature turned on.Turn on Multi-AZ with automatic failoverYou can turn on Multi-AZ when creating a cluster. Or, you can modify an existing cluster with an existing replication group. For instructions, see Minimizing down time in ElastiCache for Redis with Multi-AZ.Note: You can create your Redis cluster without turning on Multi-AZ, but this reduces fault tolerance. And, in the unlikely event of an Availability Zone failure or loss of network connectivity, the node becomes unavailable. Using ElastiCache for Redis replication together with Multi-AZ and automatic failover provides increased availability and fault tolerance. If automatic failover is turned off, you can manually failover from one Availability Zone to another. For more information, see Testing automatic failover.Related informationMulti-AZ support/Auto failover for Amazon ElastiCache for RedisFollow"


Question: How do I transfer ownership of Amazon RDS resources to a different AWS account?

I want to transfer ownership of Amazon Relational Database Service (Amazon RDS) resources from one Amazon Web Services (AWS) account to a different AWS account. How can I do this?

Answer: "I want to transfer ownership of Amazon Relational Database Service (Amazon RDS) resources from one Amazon Web Services (AWS) account to a different AWS account. How can I do this?Short descriptionYou can't transfer resources between accounts. However, you can migrate Amazon RDS resources to another account.By sharing cross-account snapshots, you can share snapshots of an unencrypted DB instance with a specific account, or you can make snapshots public. There are some limitations for sharing snapshots of an encrypted DB instance. For more information, see Sharing a DB snapshot.Note: AWS Support doesn't have access to copy Amazon RDS resources or modify any configurations in AWS accounts.ResolutionTo migrate Amazon RDS resources to another account, follow these instructions:Create a DB snapshot.Share the snapshot with the target account.In the target account, create a new DB instance by restoring the DB snapshot.To share only one database (not a whole DB instance), or to share an encrypted snapshot with a persistent option, such as Transparent Data Encryption (TDE), you must export all the data from the source database instance. Then, you must import the data into the target database instance. For more information, see How do I import data into my Amazon RDS DB instance?Related informationCopying a snapshotHow do I encrypt Amazon RDS snapshots?How do I share manual Amazon RDS DB snapshots or DB cluster snapshots with another AWS account?How can I share an encrypted Amazon RDS DB snapshot with another account?Follow"


Question: How do I fix the "Unable to validate the following destination configurations" error in AWS CloudFormation?

"I subscribe an Amazon Simple Notification Service (Amazon SNS) topic or an AWS Lambda function to Amazon Simple Storage Service (Amazon S3) event notifications. I receive the following error: "Unable to validate the following destination configurations." When I try to set a dependency on the SNS topic policy from the S3 bucket in my template, I receive a circular dependency validation error."

Answer: "I subscribe an Amazon Simple Notification Service (Amazon SNS) topic or an AWS Lambda function to Amazon Simple Storage Service (Amazon S3) event notifications. I receive the following error: "Unable to validate the following destination configurations." When I try to set a dependency on the SNS topic policy from the S3 bucket in my template, I receive a circular dependency validation error.Short descriptionBecause of the way that AWS CloudFormation handles dependency ordering, Amazon S3 event notifications are defined as an attribute of the S3 bucket. These notifications are established when the S3 bucket resource is created.To avoid an error, you must create resources in the following order:Create the SNS topic, because the S3 bucket references the SNS topic.Create the S3 bucket, because the SNS topic policy references both the S3 bucket and the SNS topic.Before subscribing an SNS topic to S3 event notifications, you must specify a topic policy (AWS::SNS::TopicPolicy) with the appropriate permissions. That topic policy must exist before you create the subscription.Try one of the following strategies to avoid the "Unable to validate the following destination configurations" error:Specify a value for BucketName in your AWS CloudFormation templateCreate a stack, and then perform a stack updateResolutionSpecify a value for BucketName in your AWS CloudFormation templateUse a static name for your S3 bucket by specifying a value for the BucketName property in the S3Bucket resource of your AWS CloudFormation template. Doing this removes the need to include {"Ref": "paramBucketName"} in the SNS topic policy. Doing this removes the intrinsic dependency between the SNS topic policy and Amazon S3.The following example AWS CloudFormation template specifies a hardcoded value (-Bucket-Name-) for the BucketName property. In your template, replace all instances of -Bucket-Name- with your bucket name.{  "Resources": {    "SNSTopic": {      "Type": "AWS::SNS::Topic"    },    "SNSTopicPolicy": {      "Type": "AWS::SNS::TopicPolicy",      "Properties": {        "PolicyDocument": {          "Id": "MyTopicPolicy",          "Version": "2012-10-17",          "Statement": [            {              "Sid": "Statement-id",              "Effect": "Allow",              "Principal": {                "Service": "s3.amazonaws.com"              },              "Action": "sns:Publish",              "Resource": {                "Ref": "SNSTopic"              },              "Condition": {                "ArnLike": {                  "aws:SourceArn": {                    "Fn::Join": [                      "",                      [                        "arn:aws:s3:::",                        "-Bucket-Name-"                      ]                    ]                  }                }              }            }          ]        },        "Topics": [          {            "Ref": "SNSTopic"          }        ]      }    },    "S3Bucket": {      "Type": "AWS::S3::Bucket",      "DependsOn": [        "SNSTopicPolicy"      ],      "Properties": {        "AccessControl": "BucketOwnerFullControl",        "BucketName": "-Bucket-Name-",        "NotificationConfiguration": {          "TopicConfigurations": [            {              "Topic": {                "Ref": "SNSTopic"              },              "Event": "s3:ObjectCreated:Put"            }          ]        }      }    }  }}Note: The S3Bucket resource has an explicit DependsOn value that's set to SNSTopicPolicy. This attribute specifies that the template creates the SNSTopicPolicy resource before the S3Bucket resource.To use the same AWS CloudFormation template for S3 buckets with different names, define a parameter for the bucket name. The parameter allows you to use the same template for different bucket names by passing the bucket name as a parameter during stack creation.To use the following example template, you must pass the bucket name as the paramBucketName parameter during stack creation.{  "Parameters": {    "paramBucketName": {      "Type": "String",      "Description": "Bucket Name"    }  },  "Resources": {    "SNSTopic": {      "Type": "AWS::SNS::Topic"    },    "SNSTopicPolicy": {      "Type": "AWS::SNS::TopicPolicy",      "Properties": {        "PolicyDocument": {          "Id": "MyTopicPolicy",          "Version": "2012-10-17",          "Statement": [            {              "Sid": "Statement-id",              "Effect": "Allow",              "Principal": {                "Service": "s3.amazonaws.com"              },              "Action": "sns:Publish",              "Resource": {                "Ref": "SNSTopic"              },              "Condition": {                "ArnLike": {                  "aws:SourceArn": {                    "Fn::Join": [                      "",                      [                        "arn:aws:s3:::",                        {                          "Ref": "paramBucketName"                        }                      ]                    ]                  }                }              }            }          ]        },        "Topics": [          {            "Ref": "SNSTopic"          }        ]      }    },    "S3Bucket": {      "Type": "AWS::S3::Bucket",      "DependsOn": [        "SNSTopicPolicy"      ],      "Properties": {        "AccessControl": "BucketOwnerFullControl",        "BucketName": {          "Ref": "paramBucketName"        },        "NotificationConfiguration": {          "TopicConfigurations": [            {              "Topic": {                "Ref": "SNSTopic"              },              "Event": "s3:ObjectCreated:Put"            }          ]        }      }    }  }}Create a stack, and then perform a stack updateDivide the stack creation into two stages. First, create the stack, but don't specify the NotificationConfiguration property in the S3Bucket resource. Then, perform a stack update to add the S3 event notification. Doing this avoids setting the S3 event notification before the SNS topic policy is created.1.    Create all the resources, including the SNS topic policy. For example:{  "Resources": {    "SNSTopic": {      "Type": "AWS::SNS::Topic"    },    "SNSTopicPolicy": {      "Type": "AWS::SNS::TopicPolicy",      "Properties": {        "PolicyDocument": {          "Id": "MyTopicPolicy",          "Version": "2012-10-17",          "Statement": [            {              "Sid": "Statement-id",              "Effect": "Allow",              "Principal": {                "Service": "s3.amazonaws.com"              },              "Action": "sns:Publish",              "Resource": {                "Ref": "SNSTopic"              },              "Condition": {                "ArnLike": {                  "aws:SourceArn": {                    "Fn::Join": [                      "",                      [                        "arn:aws:s3:::",                        {                          "Ref": "S3Bucket"                        }                      ]                    ]                  }                }              }            }          ]        },        "Topics": [          {            "Ref": "SNSTopic"          }        ]      }    },    "S3Bucket": {      "Type": "AWS::S3::Bucket",      "Properties": {        "AccessControl": "BucketOwnerFullControl"      }    }  }}2.    Update the stack to add the S3 event notification. For example:{  "Resources": {    "SNSTopic": {      "Type": "AWS::SNS::Topic"    },    "SNSTopicPolicy": {      "Type": "AWS::SNS::TopicPolicy",      "Properties": {        "PolicyDocument": {          "Id": "MyTopicPolicy",          "Version": "2012-10-17",          "Statement": [            {              "Sid": "Statement-id",              "Effect": "Allow",              "Principal": {                "Service": "s3.amazonaws.com"              },              "Action": "sns:Publish",              "Resource": {                "Ref": "SNSTopic"              },              "Condition": {                "ArnLike": {                  "aws:SourceArn": {                    "Fn::Join": [                      "",                      [                        "arn:aws:s3:::",                        {                          "Ref": "S3Bucket"                        }                      ]                    ]                  }                }              }            }          ]        },        "Topics": [          {            "Ref": "SNSTopic"          }        ]      }    },    "S3Bucket": {      "Type": "AWS::S3::Bucket",      "Properties": {        "AccessControl": "BucketOwnerFullControl",        "NotificationConfiguration": {          "TopicConfigurations": [            {              "Topic": {                "Ref": "SNSTopic"              },              "Event": "s3:ObjectCreated:Put"            }          ]        }      }    }  }}Note: You can use AWS CloudFormation Template Flip to convert your AWS CloudFormation templates between JSON and YAML formats.Related informationHow do I avoid the "Unable to validate the following destination configurations" error with Lambda event notifications in AWS CloudFormation?AWS CloudFormation stack updatesSetting up Amazon SNS notificationsFollow"


Question: What should I consider before choosing Amazon Lightsail over Amazon EC2?

"I want to set up my website environment using Amazon Lightsail. What factors should I consider before choosing Lightsail over other AWS Services, such as Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), and so on?"

Answer: "I want to set up my website environment using Amazon Lightsail. What factors should I consider before choosing Lightsail over other AWS Services, such as Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), and so on?Short descriptionLightsail provides an easy, lightweight way for you to build your website quickly. Lightsail provides pre-configured applications such as WordPress, Magento, MEAN, Prestashop, and so on. Lightsail is a good place to start your website in AWS and further familiarize yourself with the services that AWS offers. It's important to know what features Lightsail does and doesn't offer compared with other AWS services.For a summary of the differences between a Lightsail instance and an EC2 instance, see What are the differences between Amazon EC2 and Lightsail?ResolutionBefore choosing Lightsail over Amazon EC2, consider the following:Lightsail instances1.    Modifying the disk space quota: In Lightsail, It's not possible to increase the size of the disk without upgrading the instance bundle. Upgrading the bundle increases other parameters, such as RAM, CPU, bandwidth, and so on along with the disk space. In Amazon EC2, it's possible to increase the size of the Amazon Elastic Block Store (Amazon EBS) volume without upgrading the instance.2.    Upgrading the instance: In Lightsail, it's not possible to upgrade the instance directly. You must take a snapshot of the instance and then launch a new instance with the bigger bundle using that snapshot. In Amazon EC2, you can easily upgrade an instance without taking a snapshot and launching a new instance.3.    Limited resources for an instance: The biggest Instance plan in Lightsail provides 32 GB RAM, 8 vCPUs, and 640 GB disk space. If you need additional disk space, you must attach secondary disks to the instance.4.    Attaching multiple IP addresses: You can attach only one IP address to a Lightsail instance. You can attach multiple IP addresses to a single EC2 instance.5.    Instance console output: This is a tool in Amazon EC2 that helps you troubleshoot unresponsive instances by yourself. This tool isn't available in Lightsail.6.    Private instances: Resources in Lightsail are in a public subnet. You can't make a Lightsail instance private, although you can restrict access to the instance using Lightsail firewalls.7.    Instance launch script: You can use an instance launch script to execute a script when you launch the Lightsail instance. In Amazon EC2, you can add the script after launching the instance so that the script executes when the instance stops and starts. In Lightsail, you can't add a script after launching the instance. The workaround is to take a snapshot of the Lightsail instance and then launch a new instance from that snapshot. You can add the launch script while launching the new instance from the snapshot.8.    Replacing the root disk: In Lightsail, it's not possible to replace the root disk of an instance. Using the AWS Command Line Interface (AWS CLI), you can create a disk snapshot of the root disk, create a disk from that snapshot, and then attach it to another Lightsail instance. However, you can't attach this disk to the original instance as root disk.9.    Instance termination protection: EC2 instances provide a feature to enable termination protection. Termination protection prevents your instance from being accidentally terminated. This feature is not available in Lightsail.10.    Instance purchasing options: Amazon EC2 provides different instance purchasing options, such as On Demand, Spot Instances, Reserved Instances, capacity reservations, and so on. Lightsail's only purchasing option is to launch a Lightsail bundle on demand.11.    Auto Scaling group: In Amazon EC2, you have the option to set up Amazon EC2 Auto Scaling to make sure that you have the optimal number of EC2 instances to handle your workload. Lightsail doesn't support Auto Scaling.12.    Instance hibernate: EC2 instances support hibernation. You can use hibernation instead of stopping the instance. Hibernation saves the contents from RAM to the EBS volume. Lightsail doesn't support hibernation.13.    Number of Lightsail firewall rules: You can add up to 60 firewall rules for a Lightsail instance. Each source IP address is considered a different rule. IPv6 rules are counted towards this quota of 60. The maximum number of source IP addresses that can be added in a rule using the Lightsail console is 30. To add more, you can use the AWS CLI.14.    Copying Lightsail firewall rules: In security groups, you can use the console to copy the rules from one security group to another. However, the Lightsail console doesn't support copying rules from one firewall to another. You can use the AWS CLI to copying rules in Lightsail.15.    Denying IP addresses in a Lightsail firewall: In a Lightsail firewall, you can allow port access to a set of IP addresses. However, you can't explicitly deny a set of IP addresses in Lightsail. In Amazon EC2, you can use network ACLs to deny particular IP addresses.Common solution - Use EC2 instances instead of Lightsail instances. If you already have a Lightsail instance launched, you can export it to EC2. Exporting a cPanel Lightsail instance to EC2 isn't supported.Lightsail load balancer1.    Health check settings: In Application Load Balancer health check settings, you have various customization options available, such as HealthCheckPort, HealthCheckProtocol, Matcher, and so on. In Lightsail load balancer, you can modify only the HealthCheckPath settings.2.    Security Policies: In Application Load Balancer, you can choose a security policy from the available options. Using this option, you can disable the TLS versions that aren't needed for your Load Balancer. The Lightsail load balancer doesn't provide this feature.3.    Listener rules: You can use listener rules to define how your load balancer routes traffic to target instances. One of the common use cases of this option is to add HTTP to HTTPS redirection. Listener rules are available in Application Load Balancer but aren't supported in Lightsail load balancer.4.    Firewall services: You can use AWS firewall services, such as AWS WAF and AWS Shield, with Application Load Balancer. These services aren't supported in Lightsail load balancer.5.    TLS certificates: In Application Load Balancer, you can attach a total of 26 ACM SSL certificates. In Lightsail load balancer, you can attach one at a time. Also, you must request separate certificates for each load balancer that you create.6.    Target port: In Lightsail load balancer, target instances are registered on port 80 by default. You can't modify this using the Lightsail console. However, you can use the AWS CLI to define a different port when creating the load balancer.7.    Access Logs: Application Load Balancer provides access logs that capture detailed information about requests sent to your load balancer. Lightsail load balancer doesn't support logging.Common solution: Use an Application Load Balancer instead of a Lightsail load balancer for your Lightsail instance. For more details, see How can I associate an Application Load Balancer with my Lightsail instance?Lightsail DNS1.    Number of DNS zones: You can have a maximum of three DNS zones in Lightsail. In Amazon Route 53, you can have up to 500 hosted zones. You can also request more DNS zones.2.    Routing policies: Unlike Route 53, routing policies aren't supported in Lightsail.3.    Record types: Currently, Lightsail DNS doesn't support the record types CAA, DS, NAPTR, PTR, SOA, and SPF. These record types are supported in Route 53.4.    Health checks: Route 53 supportshealth checks. Health checks can be used to monitor the health and performance of your web applications, web servers, and other resources. Lightsail DNS doesn't support health checks.5.    Private DNS zone: You can use private DNS zones to make a domain or sub domain resolve to the records of your choice within the VPC. Lightsail DNS doesn't support private DNS zones.6.    Importing a zone file: In Route 53, you can import DNS zone file to create records in a hosted zone. This is helpful when you want to migrate DNS records from a third-party DNS provider to AWS. Importing zone files isn't supported in Lightsail DNS.Common solution: Use Route 53 instead of Lightsail DNS for your Lightsail resources. For more information, see  Map your domain at Route 53 to your Lightsail resources.Lightsail SSL/TLS certificates1.    Number of certificates: In Lightsail, you can have up to 20 SSL/TLS certificates per Region (including expired certificates). Amazon Certificate Manager (ACM) offers a quota of 2500 certificates.2.     Wildcard domains: It isn't possible to add a wildcard domain (for example, *.example.com) in your Lightsail SSL/TLS certificate. You have to define each subdomain separately in your certificate. ACM supports wildcard domains.3.    Importing certificates: In ACM, you can import a third-party SSL certificate and then attach it with resources such as Application Load Balancer, Amazon CloudFront distribution and so on. It's not possible to import third-party certificates to Lightsail SSL/TLS.4.    Certificate validation: To validate the certificate, you can use both DNS validation and email validation in ACM. Lightsail SSL/TLS supports only DNS validation.Common solution: Use ACM certificates in Lightsail instead of Lightsail SSL/TLS certificates. This means you have to use Application Load Balancer or Amazon CloudFront instead of Lightsail load balancer or Lightsail distribution.Follow"


Question: How do I access the Apache Airflow UI using the private network access mode in my Amazon MWAA environment?

"When I try to open the Apache Airflow UI in my Amazon Managed Workflows for Apache Airflow (Amazon MWAA) environment, I get the "Connection timed out" error."

Answer: "When I try to open the Apache Airflow UI in my Amazon Managed Workflows for Apache Airflow (Amazon MWAA) environment, I get the "Connection timed out" error.Short descriptionThe Amazon MWAA environment provides public and private access modes for Apache Airflow UI. With the public access mode, the Apache Airflow Web server is open to the internet and can be accessed without any additional setup. However, you can't control the network access of the Apache Airflow Web server using a security group. Therefore, this option is considered less secure compared to the private access mode. With the private access mode, the Apache Airflow Web server is exposed only within the Amazon Virtual Private cloud (Amazon VPC) in the environment. Amazon MWAA creates a VPC endpoint in your VPC for each environment. Therefore, access to the VPC is necessary to access the Apache Airflow UI. The private network access mode requires additional networking setup.ResolutionYou can access the Apache Airflow Web server in private network access mode using one of the following approaches.AWS Direct Connect or VPNIf you have an AWS Direct Connect or VPN connection to connect your on-premises network to Amazon VPC, consult with your networking team to configure access to the Amazon MWAA Web server address. After the network path is established, review the security groups associated with the environment to be sure that the Amazon MWAA Web server allows HTTPS (TCP 443) traffic from the source IP or subnet. You can also use an AWS Client VPN to configure the private network access.If you are still facing issues, try the following:Verify the DNS resolution with a tool, such as nslookup or dig (dig <airflow-web-server-address>).Verify port level connectivity using a tool, such as telnet (telnet <airflow-web-server-address-443>).If the issue still persists, check whether the browser has a web proxy configured. In that case, try disabling the proxy for testing or fix the issue in the proxy configuration.Linux bastion hostA bastion host can be used as an intermediary between the internet and private subnet. The host is usually a Linux machine with SSH server running. You can establish an SSH tunnel to the bastion host to access resources within your Amazon VPC. Then, you can use a browser proxy, such as FoxyProxy, to open the Apache Airflow UI through the SSH Tunnel. To set up a Linux bastion host, see Tutorial: Configuring private network access using a Linux bastion host.If you have an Amazon Elastic Compute Cloud (Amazon EC2) instance with a graphical user interface (GUI), such as a Windows machine, you can use this instance to access the Apache Airflow UI.Load balancerYou can also use a load balancer as an intermediary between the internet and private subnet. Unlike with the bastion host, you can directly access the load balancer's address without any additional setup.To configure the load balancer, do the following:Identify the private IP addresses of the MWAA Web server. To get these IP addresses, do a DNS lookup on the Apache Airflow UI address (dig +short <airflow-web-server-address>).Create a target group for the private IP addresses of the Amazon MWAA Web server.Configure the health check settings for the target group to include 200 and 302 for Matcher.Note: Without this setting, the targets might be flagged as unhealthy when the Apache Airflow Web server responds with a 302 Redirect.Create an Application Load Balancer with an HTTPS listener and the target group created.Note: You must have an SSL certificate before creating an HTTPS listener. You can create an SSL certificate with AWS Certificate Manager (ACM) by signing in to the domain or subdomain of your choice.Test access to the Apache Airflow UI using the address of the Application Load Balancer that you created.Note: Amazon MWAA requires a web login token to access the Apache Airflow UI. Therefore, you need to create the web login token and pass this token as a query string when accessing the Apache Airflow UI through the Application Load Balancer. To automate the creation of this token, see Accessing a private Amazon MWAA environment using federated identities.Related informationApache Airflow access modesAccessing the Apache Airflow UIFollow"