Question: How can I manage my Lightsail instance using AWS CLI commands?

How can I manage my Amazon Lightsail instances using AWS Command Line Interface (AWS CLI) version 1 commands?

Answer: "How can I manage my Amazon Lightsail instances using AWS Command Line Interface (AWS CLI) version 1 commands?Short descriptionFor a list of Amazon Lightsail AWS CLI commands, see AWS CLI Command reference and the Amazon Lightsail API reference.The following are common scenarios for using AWS CLI commands on your Lightsail instances:Listing all the Lightsail plans (bundles) and blueprints available in a Region.Creating a Lightsail instance using a specific bundle and blueprint.Listing all the Lightsail Instances in a particular Region.Allocating a static IP address and then attaching it to the instance and verifying it.Note: Keep in mind the following when using AWS CLI commands:If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.JSON is the default AWS CLI output. You can use the default, or append --output json to the commands to receive output as shown in the following examples. For more information, see Controlling command output from the AWS CLI.For general information on solving AWS CLI errors, see Why am I receiving errors when running AWS CLI commands?The AWS CLI command output displays timestamps in Unix Epoch time. Use one of the following methods to convert the timestamp into UTC:macOS:Remove the decimal point from the timestamp and any digits to the right of the decimal point, and then run the following command:# date -r 1602175741 -uThu Oct  8 16:49:01 UTC 2020Linux:Run the following command:# date -d @1602175741.603 -uThu Oct  8 16:49:01 UTC 2020Windows:Convert the timestamp using a converter, such as epochconverter.com.ResolutionListing all the Lightsail bundles and blueprints available in a RegionRun the get-bundles command to see the list of all bundles that are available for purchase in your Region. In the following command, replace eu-west-1 with your Region:# aws lightsail get-bundles --region eu-west-1 --query 'bundles[].{price:price,cpuCount:cpuCount,ramSizeInGb:ramSizeInGb,diskSizeInGb:diskSizeInGb,bundleId:bundleId,instanceType:instanceType,supportedPlatforms:supportedPlatforms[0]}' --output table---------------------------------------------------------------------------------------------------------------|                                                 GetBundles                                                  |+-----------------+-----------+---------------+---------------+--------+---------------+----------------------+|    bundleId     | cpuCount  | diskSizeInGb  | instanceType  | price  |  ramSizeInGb  | supportedPlatforms   |+-----------------+-----------+---------------+---------------+--------+---------------+----------------------+|  nano_2_0       |  1        |  20           |  nano         |  3.5   |  0.5          |  LINUX_UNIX          ||  micro_2_0      |  1        |  40           |  micro        |  5.0   |  1.0          |  LINUX_UNIX          ||  small_2_0      |  1        |  60           |  small        |  10.0  |  2.0          |  LINUX_UNIX          ||  medium_2_0     |  2        |  80           |  medium       |  20.0  |  4.0          |  LINUX_UNIX          ||  large_2_0      |  2        |  160          |  large        |  40.0  |  8.0          |  LINUX_UNIX          ||  xlarge_2_0     |  4        |  320          |  xlarge       |  80.0  |  16.0         |  LINUX_UNIX          ||  2xlarge_2_0    |  8        |  640          |  2xlarge      |  160.0 |  32.0         |  LINUX_UNIX          ||  nano_win_2_0   |  1        |  30           |  nano         |  8.0   |  0.5          |  WINDOWS             ||  micro_win_2_0  |  1        |  40           |  micro        |  12.0  |  1.0          |  WINDOWS             ||  small_win_2_0  |  1        |  60           |  small        |  20.0  |  2.0          |  WINDOWS             ||  medium_win_2_0 |  2        |  80           |  medium       |  40.0  |  4.0          |  WINDOWS             ||  large_win_2_0  |  2        |  160          |  large        |  70.0  |  8.0          |  WINDOWS             ||  xlarge_win_2_0 |  4        |  320          |  xlarge       |  120.0 |  16.0         |  WINDOWS             ||  2xlarge_win_2_0|  8        |  640          |  2xlarge      |  240.0 |  32.0         |  WINDOWS             |+-----------------+-----------+---------------+---------------+--------+---------------+----------------------+Run the get-blueprints command to see the list of all images or blueprints in your Region. You can then choose to create a new instance using the available images. In the following command, replace eu-west-1 with your Region:# aws lightsail get-blueprints --region eu-west-1 --query 'blueprints[].{blueprintId:blueprintId,name:name,group:group,productUrl:productUrl,platform:platform}' --output table---------------------------------------------------------------------------------------------------------------------------------------------------------------------|                                                                           GetBlueprints                                                                           |+--------------------------------------+-----------------------+--------------------------------+-------------+-----------------------------------------------------+|              blueprintId             |         group         |             name               |  platform   |                     productUrl                      |+--------------------------------------+-----------------------+--------------------------------+-------------+-----------------------------------------------------+|  windows_server_2019                 |  windows_2019         |  Windows Server 2019           |  WINDOWS    |  https://aws.amazon.com/marketplace/pp/B07QZ4XZ8F   ||  windows_server_2016                 |  windows_2016         |  Windows Server 2016           |  WINDOWS    |  https://aws.amazon.com/marketplace/pp/B01M7SJEU7   ||  windows_server_2012                 |  windows_2012         |  Windows Server 2012 R2        |  WINDOWS    |  https://aws.amazon.com/marketplace/pp/B00KQOWCAQ   ||  windows_server_2016_sql_2016_express|  windows_2016_sql_exp |  SQL Server 2016 Express       |  WINDOWS    |  https://aws.amazon.com/marketplace/pp/B01MAZHH98   ||  amazon_linux_2                      |  amazon_linux_2       |  Amazon Linux 2                |  LINUX_UNIX |  https://aws.amazon.com/amazon-linux-2/             ||  amazon_linux                        |  amazon-linux         |  Amazon Linux                  |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00CIYTQTC   ||  ubuntu_20_04                        |  ubuntu_20            |  Ubuntu                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B087QQNGF1   ||  ubuntu_18_04                        |  ubuntu_18            |  Ubuntu                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B07CQ33QKV   ||  ubuntu_16_04_2                      |  ubuntu               |  Ubuntu                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B01JBL2M0O   ||  debian_10                           |  debian_10            |  Debian                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B0859NK4HC   ||  debian_9_5                          |  debian_9             |  Debian                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B073HW9SP3   ||  debian_8_7                          |  debian               |  Debian                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00WUNJIEE   ||  freebsd_12                          |  freebsd              |  FreeBSD                       |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B07L6QV354   ||  opensuse_15_1                       |  opensuse             |  openSUSE                      |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B01N4R3GJI   ||  centos_7_1901_01                    |  centos               |  CentOS                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00O7WM7QW   ||  wordpress                           |  wordpress            |  WordPress                     |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NN8Y43U   ||  wordpress_multisite                 |  wordpress_multisite  |  WordPress Multisite           |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NN8XE6S   ||  lamp_7                              |  lamp_7               |  LAMP (PHP 7)                  |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B072JNJZ5C   ||  nodejs                              |  node                 |  Node.js                       |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZUAKO   ||  joomla                              |  joomla               |  Joomla                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZUP54   ||  magento                             |  magento              |  Magento                       |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZTA6Y   ||  mean                                |  mean                 |  MEAN                          |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NO1HJ56   ||  drupal                              |  drupal               |  Drupal                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZSUMO   ||  gitlab                              |  gitlab               |  GitLab CE                     |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZU5PO   ||  redmine                             |  redmine              |  Redmine                       |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZUVHQ   ||  nginx                               |  nginx                |  Nginx                         |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NPHKI3Y   ||  ghost_bitnami                       |  ghost_bitnami        |  Ghost                         |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NPHLY8W   ||  django_bitnami                      |  django_bitnami       |  Django                        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NNZTDNO   ||  plesk_ubuntu_18_0_28                |  plesk_ubuntu         |  Plesk Hosting Stack on Ubuntu |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B077MJL7Z2   ||  cpanel_whm_linux                    |  cpanel_whm_linux     |  cPanel & WHM for Linux        |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B07RRX2TVV   |+--------------------------------------+-----------------------+--------------------------------+-------------+-----------------------------------------------------+Example:The following command filters for blueprints with the Linux/Unix Platform OS:# aws lightsail get-blueprints --query 'blueprints[?type==`os`&&platform==`LINUX_UNIX`].{name:name,version:version}' --output table--------------------------------------------|               GetBlueprints              |+-----------------+------------------------+|      name       |        version         |+-----------------+------------------------+|  Amazon Linux 2 |  2.0.20200917.0        ||  Amazon Linux   |  2018.03.0.20200918.0  ||  Ubuntu         |  20.04 LTS             ||  Ubuntu         |  18.04 LTS             ||  Ubuntu         |  16.04 LTS             ||  Debian         |  10.5                  ||  Debian         |  9.5                   ||  Debian         |  8.7                   ||  FreeBSD        |  12.1                  ||  openSUSE       |  15.1                  ||  CentOS         |  7 1901-01             |+-----------------+------------------------+Creating a Lightsail instance using a specific bundle and blueprint1.    Run the following command to get a blueprint. The following example command gets a WordPress blueprint. Replace eu-west-1 with your Region and the WordPress information with the blueprint information of your choice.# aws lightsail get-blueprints --region eu-west-1 --query 'blueprints[].{blueprintId:blueprintId,name:name,group:group,productUrl:productUrl,platform:platform}' --output table |grep -i wordpress|  wordpress                           |  wordpress            |  WordPress                     |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NN8Y43U   ||  wordpress_multisite                 |  wordpress_multisite  |  WordPress Multisite           |  LINUX_UNIX |  https://aws.amazon.com/marketplace/pp/B00NN8XE6S   |2.    Run the create-instances command to create Amazon Lightsail Instances. The following example creates an Amazon Lightsail instance in the eu-west-1 Region using a WordPress blueprint and the micro_2_0 bundle. Replace --instance-names, blueprint-id, bundle-id, and --region with the appropriate values for your request.# aws lightsail create-instances --region eu-west-1 --instance-names MyNewInstance --availability-zone eu-west-1a --blueprint-id wordpress --bundle-id micro_2_0{    "operations": [        {            "id": "003757e7-0880-4162-9912-211d4756081e",            "resourceName": "MyNewInstance",            "resourceType": "Instance",            "createdAt": 1602175452.334,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationType": "CreateInstance",            "status": "Started",            "statusChangedAt": 1602175452.334        }    ]}To create multiple instances using a single API call, specify parameters with --instance-names {"LightsailInstance1","LightsailInstance2"}. The following example creates two Lightsail instances in the eu-west-1 Region using a WordPress blueprint and the micro_2_0 bundle.# aws lightsail create-instances --region eu-west-1 --instance-names {"TestLightsailInstance1","TestLightsailInstance2"} --availability-zone eu-west-1a --blueprint-id wordpress --bundle-id micro_2_0{    "operations": [        {            "id": "8a15b195-9a20-4d79-ad1d-6e85557ae94d",            "resourceName": "TestLightsailInstance1",            "resourceType": "Instance",            "createdAt": 1602175741.602,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationType": "CreateInstance",            "status": "Started",            "statusChangedAt": 1602175741.602        },        {            "id": "a006513b-0e25-4802-ab33-671a40bf5a92",            "resourceName": "TestLightsailInstance2",            "resourceType": "Instance",            "createdAt": 1602175741.603,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationType": "CreateInstance",            "status": "Started",            "statusChangedAt": 1602175741.603        }    ]}Listing all Lightsail instances in a RegionRun the get-instances command to display Lightsail instances in a specific Region. The following example shows all Lightsail instances in the eu-west-1 Region Replace --region with the appropriate values for your request.# aws lightsail get-instances --region eu-west-1 --query 'instances[].{name:name,createdAt:createdAt,blueprintId:blueprintId,blueprintName:blueprintName,publicIpAddress:publicIpAddress}' --output table---------------------------------------------------------------------------------------------------------------------|                                                   GetInstances                                                    |+-----------------+----------------+-----------------+------------------------------------------+-------------------+|   blueprintId   | blueprintName  |    createdAt    |                  name                    |  publicIpAddress  |+-----------------+----------------+-----------------+------------------------------------------+-------------------+|  wordpress_4_9_8|  WordPress     |  1545700733.77  | WordPress-512MB-Ireland-1  |  63.33.xx.xx ||  wordpress      |  WordPress     |  1602175741.603 |  TestLightsailInstance2    |  63.33.xx.xx ||  wordpress      |  WordPress     |  1602175741.602 |  TestLightsailInstance1    |  54.7.xx.xx  ||  wordpress      |  WordPress     |  1588098501.555 |  WordPress-1               |  3.250.xx.xx ||  wordpress      |  WordPress     |  1602175452.334 |  MyNewInstance             |  54.195.xx.xx +-----------------+----------------+-----------------+------------------------------------------+-------------------+Allocating a Static IP and then attaching it to the Lightsail instance created and verifying it.Note: The create-instances command creates a Lightsail instance with a public IP address assigned to it. Unlike public IP address that you can assign and reassign to an instance or other resource, static IP addresses are fixed. If you haven't created a static IP address for your instance, then Lightsail assigns a new public IP address each time you stop or restart the instance.1.    Run the allocate-static-ip command to allocate a fixed public address. The following example shows allocation of a static IP named StaticIpForTestLightsailInstance1 in the eu-west-1 Region. Replace the --static-ip-name and --region with the appropriate values for your request.# aws lightsail allocate-static-ip --static-ip-name StaticIpForTestLightsailInstance1 --region eu-west-1{    "operations": [        {            "id": "6471cedc-97f5-42d1-b35f-4f77c5f93242",            "resourceName": "StaticIpForTestLightsailInstance1",            "resourceType": "StaticIp",            "createdAt": 1602180341.746,            "location": {                "availabilityZone": "all",                "regionName": "eu-west-1"            },            "isTerminal": true,            "operationType": "AllocateStaticIp",            "status": "Succeeded",            "statusChangedAt": 1602180342.011        }    ]}2.    Run the get-static-ipcommand to display the value for allocated static IP addresses. The following example shows allocation of a static IP 52.210.xx.xx named StaticIpForTestLightsailInstance1 in the eu-west-1 Region. Replace the --static-ip-name and --region with the appropriate values for your request.# aws lightsail get-static-ip --static-ip-name StaticIpForTestLightsailInstance1 --region eu-west-1{    "staticIp": {        "name": "StaticIpForTestLightsailInstance1",        "arn": "arn:aws:lightsail:eu-west-1:920893848407:StaticIp/16a97579-c51e-404c-96cc-5946528d12aa",        "supportCode": "11178xxxxxxx/52.210.xx.xx",        "createdAt": 1602180341.746,        "location": {            "availabilityZone": "all",            "regionName": "eu-west-1"        },        "resourceType": "StaticIp",        "ipAddress": "52.210.xx.xx",        "isAttached": false    }}3.    Run the attach-static-ip command to attach a static ip address to your Lightsail instance. The following example shows allocation of a static IP 52.210.xx.xx named StaticIpForTestLightsailInstance1 to the instance named TestLightsailInstance1 in the eu-west-1 Region. Replace the --static-ip-name, --instance-name and --region with the appropriate values for your request.# aws lightsail attach-static-ip --static-ip-name StaticIpForTestLightsailInstance1 --instance-name TestLightsailInstance1  --region eu-west-1{    "operations": [        {            "id": "d9d2372f-b4b7-4838-99ae-c15f8ffb8332",            "resourceName": "StaticIpForTestLightsailInstance1",            "resourceType": "StaticIp",            "createdAt": 1602180562.026,            "location": {                "availabilityZone": "all",                "regionName": "eu-west-1"            },            "isTerminal": true,            "operationDetails": "TestLightsailInstance1",            "operationType": "AttachStaticIp",            "status": "Succeeded",            "statusChangedAt": 1602180562.026        },        {            "id": "131994d8-bd25-4b47-8d81-851224b168d1",            "resourceName": "TestLightsailInstance1",            "resourceType": "Instance",            "createdAt": 1602180562.026,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": true,            "operationDetails": "StaticIpForTestLightsailInstance1",            "operationType": "AttachStaticIp",            "status": "Succeeded",            "statusChangedAt": 1602180562.026        }    ]}4.    Run the get-instances command to verify if the static IP address associated correctly with your Lightsail instance.# aws lightsail get-instances --region eu-west-1 --query 'instances[].{name:name,createdAt:createdAt,blueprintId:blueprintId,blueprintName:blueprintName,publicIpAddress:publicIpAddress,InstanceID:supportCode}' --output table---------------------------------------------------------------------------------------------------------------------------------------------------------|                                                                     GetInstances                                                                      |+----------------------------------+------------------+----------------+-----------------+------------------------------------------+-------------------+|            InstanceID            |   blueprintId    | blueprintName  |    createdAt    |                  name                    |  publicIpAddress  |+----------------------------------+------------------+----------------+-----------------+------------------------------------------+-------------------+|  11178xxxxxxx/i-09f6xxxx|  wordpress       |  WordPress     |  1602175741.602 |  TestLightsailInstance1                  |  52.210.xx.xx    |+----------------------------------+------------------+----------------+-----------------+------------------------------------------+-------------------+Related informationHow can I manage my snapshots and create backups for my Lightsail instances using AWS CLI commands?How can I manage static IP addresses on my Lightsail instances using AWS CLI commands?AWS CLI command referenceAmazon Lightsail API referenceEnabling or disabling automatic snapshots for instances or disks in Amazon LightsailFollow"


Question: How can I troubleshoot issues with using a custom SSL certificate for my CloudFront distribution?

I have an SSL certificate on AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) that I want to use for my Amazon CloudFront distribution. I want to troubleshoot the issues that I'm having.

Answer: "I have an SSL certificate on AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) that I want to use for my Amazon CloudFront distribution. I want to troubleshoot the issues that I'm having.Short descriptionThe following are the most common issues when using a custom SSL certificate for your CloudFront distribution:When setting up the distribution, you don't have the option to choose your custom SSL certificate.You can't choose the SSL certificate even though you might be able to use the same certificate with your load balancer.ResolutionTo troubleshoot issues when using a custom SSL certificate with your CloudFront distribution, check the following:If you're using a certificate requested from or imported to ACM, then confirm that your certificate meets the requirementsTo assign an ACM certificate to a CloudFront distribution, request or import the certificate in the US East (N. Virginia) Region. If you're using the ACM console, then check the Region selector in the navigation bar. Confirm that US East (N. Virginia) is selected before you request or import the certificate.Note: After you assign an ACM certificate to a CloudFront distribution, the certificate is distributed to all edge locations for the CloudFront distribution's price class.After you validate your ACM certificate using either DNS validation or email validation, be sure that the status of the certificate is Issued. The status must be Issued before you can assign the certificate to a CloudFront distribution.The certificate must be a 2048-bit RSA certificate or smaller. Though ACM supports 1024 bit through 4096-bit RSA certificates, services such as CloudFront that are integrated with ACM support a maximum of 2048-bit RSA certificates.For imported certificates, be sure that the certificate meets the prerequisites for importing a certificate.If you're using a certificate imported to IAM, then verify the CloudFront pathWhen you import your SSL certificate to IAM, provide the correct path so that CloudFront can use the certificate. Run the following AWS Command Line Interface (AWS CLI) command to upload your certificate with a specified CloudFront path:Note: Before you run this command, be sure to replace all values with the details for your certificate and CloudFront distribution.aws iam upload-server-certificate --server-certificate-name CertificateName--certificate-body file://public_key_certificate_file --private-key file://privatekey.pem --certificate-chain file://certificate_chain_file --path /cloudfront/DistributionName/**Note:**If you receive errors when running AWS CLI commands,make sure that you’re using the most recent version of the AWS CLI.If you didn't upload your certificate with the CloudFront path, then run this command to update your certificate with the path:aws iam update-server-certificate --server-certificate-name CertificateName --new-path /cloudfront/DistributionName/Note: After you add a certificate to a CloudFront distribution, the distribution's status changes from Deployed to In Progress. The distribution's status changes back to Deployed when the change is deployed to all CloudFront edge locations. The typical deployment time is 5 minutes.Confirm that you have the required permissions when assigning a certificate from ACM or IAM to the CloudFront distributionThe IAM user or role that you use to assign the certificate must have the following permissions at minimum:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": "acm:ListCertificates",            "Resource": "*"        },        {            "Effect": "Allow",            "Action": [                "cloudfront:ListDistributions",                "cloudfront:ListStreamingDistributions"            ],            "Resource": "*"        },        {            "Effect": "Allow",            "Action": [                "cloudfront:List*",                "cloudfront:Get*",                "cloudfront:Update*"            ],            "Resource": "arn:aws:cloudfront::account-id:distribution/distribution-id"        },        {            "Effect": "Allow",            "Action": "iam:ListServerCertificates",            "Resource": "*"        },        {            "Effect": "Allow",            "Action": [                "iam:GetServerCertificate",                "iam:UpdateServerCertificate"            ],            "Resource": "arn:aws:iam::account-id:server-certificate/certificate-name-with-path"        }    ]}Related informationHow do I resolve the "InvalidViewerCertificate" error exception while creating or updating a CloudFront distribution?Requirements for using SSL/TLS certificates with CloudFrontFollow"


Question: Why does my Amazon EMR cluster fail to launch and return the error "bootstrap action returned a non-zero return code"?

"I created a custom bootstrap action for my Amazon EMR cluster. The cluster fails to launch, and the bootstrap action returns an error similar to the following: "bootstrap action 1 returned a non-zero return code"."

Answer: "I created a custom bootstrap action for my Amazon EMR cluster. The cluster fails to launch, and the bootstrap action returns an error similar to the following: "bootstrap action 1 returned a non-zero return code".Short descriptionBootstrap actions run after Amazon EMR provisions the Amazon Elastic Compute Cloud (Amazon EC2) instances in the cluster. When a bootstrap action fails, Amazon EMR terminates the instance. For more information, see Understanding the cluster lifecycle.If a bootstrap action fails because of an error in the bootstrap script, then the cluster can't launch. For more information, see Bootstrap action basics.ResolutionTo determine why a bootstrap action failed, review the stderr logs for your bootstrap action. These logs are located in the Amazon Simple Storage Service (Amazon S3) path or LogUri that you configured earlier when you created the Amazon EMR cluster.Example: s3://example-log-location/example-cluster-id/node/example-instance-id/bootstrap-actions/If you can't determine why the script failed after reviewing the stderr logs, modify your script to provide additional debug information. For example, set the -ex parameters in the bash script. This allows you to view the bash script flow in the bootstrap action log files.#!/bin/bashset -x -eNote: If the failed bootstrap action isn't a bootstrap action that you created—for example, if you created six bootstrap actions and you see the error message is "bootstrap action 7 failed with non-zero exit code")—that error message indicates that Amazon EMR couldn't install applications or start services.To troubleshoot this issue, check the Amazon EMR provisioning logs. Amazon EMR uses Puppet to install and configure applications on a cluster. The logs might provide information on errors caused during the provisioning of the cluster.You can access these logs on the cluster or S3 if you configured the logs to be pushed to S3. The logs are stored in /var/log/provision-node/apps-phase/0/example-UUID}/puppet.log on the disk and s3://example-log-location/example-cluster-id/node/example-instance-id/provision-node/apps-phase/0/{UUID}/puppet.log.gz.Related informationUse custom bootstrap actionsFollow"


Question: How can I configure my Amazon VPC to privately connect to my S3 bucket without using authentication?

"I want to create a private connection from my Amazon Virtual Private Cloud (Amazon VPC) to an Amazon Simple Storage Service (Amazon S3) bucket. However, I don't want to use authentication, such as AWS Identity and Access Management (IAM) credentials. How do I create this type of private connection?"

Answer: "I want to create a private connection from my Amazon Virtual Private Cloud (Amazon VPC) to an Amazon Simple Storage Service (Amazon S3) bucket. However, I don't want to use authentication, such as AWS Identity and Access Management (IAM) credentials. How do I create this type of private connection?Short descriptionYou can access an S3 bucket privately without authentication when you access the bucket from an Amazon Virtual Private Cloud (Amazon VPC). However, make sure that the VPC endpoint used points to Amazon S3.Follow these steps to set up VPC endpoint access to the S3 bucket:1.    Create a VPC endpoint for Amazon S3.2.    Add a bucket policy that allows access from the VPC endpoint.ResolutionBefore you begin, you must create a VPC that you'll access the bucket from.Create a VPC endpoint for Amazon S31.    Open the Amazon VPC console.2.    Using the Region selector in the navigation bar, set the AWS Region to the same Region as your S3 bucket.3.    From the navigation pane, choose Endpoints.4.    Choose Create Endpoint.5.    For Service category, verify that "AWS services" is selected.6.    For Service Name, select the "s3" service name and "Gateway" type. For example, the service name in the US East (N. Virginia) Region is com.amazonaws.us-east-1.s3.7.    For VPC, select your VPC.8.    For Configure route tables, select the route tables based on the associated subnets that you want to be able to access the endpoint from.9.    For Policy, verify that Full Access is selected.10.    Choose Create endpoint.11.    Note the VPC Endpoint ID. You'll need this endpoint ID for a later step.Add a bucket policy that allows access from the VPC endpointUpdate your bucket policy with a condition that allows users to access the S3 bucket when the request is from the VPC endpoint that you created.To allow those users to download objects ( s3:GetObject), use a bucket policy like this one:{   "Version": "2012-10-17",   "Id": "Policy1415115909152",   "Statement": [     {       "Sid": "Access-to-specific-VPCE-only",       "Principal": "*",       "Action": "s3:GetObject",       "Effect": "Allow",       "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"],       "Condition": {         "StringEquals": {           "aws:sourceVpce": "vpce-1a2b3c4d"         }       }     }   ]}For the value of aws:sourceVpce, make sure to enter the VPC endpoint ID of the endpoint that you previously created.Important: This policy allows access from the VPC endpoint, but it doesn't deny all access from outside the endpoint. If a user from the same account is authenticated, this policy still allows the user to access the bucket from outside the VPC endpoint. For a more restrictive bucket policy, use a policy that explicitly denies access to any requests from outside the endpoint.Related informationGateway endpoints for Amazon S3Follow"


Question: How do I use the VPC Reachability Analyzer to troubleshoot connectivity issues with an Amazon VPC resource?

I'm unable to connect to my destination server using an Amazon Virtual Private Cloud (Amazon VPC) resource as the source. How do I troubleshoot this issue using VPC Reachability Analyzer?

Answer: "I'm unable to connect to my destination server using an Amazon Virtual Private Cloud (Amazon VPC) resource as the source. How do I troubleshoot this issue using VPC Reachability Analyzer?Short descriptionTo troubleshoot Amazon VPC connectivity issues, use Reachability Analyzer to check for common issues with:Security group configurationsNetwork access control list (network ACL) configurationsRoute table configurationsResolutionImportant: VPC Reachability Analyzer relies on data from other AWS services. If the tool fails to run, then confirm the following:You have the required API permissions.The source, destination, and intermediate components are supported by Reachability Analyzer.Using Reachability Analyzer from the AWS Management Console1.    Open the Amazon VPC console.2.    In the navigation pane, choose Reachability Analyzer.3.    Select the Region where your resources are located.4.    For Source type, choose Instances. Then, select your source resource.5.    For Destination type, choose Internet Gateways. Then, select your destination resource.6.    For Protocol, choose TCP or UDP, depending on your use case.7.    Choose Create and analyze path.8.    After the path analysis completes, view the results.If the Reachability status is Not reachable, then there's an issue in the path.You can analyze an existing path by specifying an intermediate component. Find an alternative reachable path that traverses the intermediate component by doing the following:1.    Select the path, and then choose Analyze path.2.    Determine the Amazon Resource Name (ARN) for the intermediate component.For example, the ARN for a Network Address Translation (NAT) gateway is:arn:aws:ec2:us-east-1:123456789012:nat-gateway/nat-012345678901234ab3.    Enter the ARN for the intermediate component, and then choose Confirm.4.    Refresh the page, and then view the new analysis ID that displays with the intermediate hop path.Using Reachability Analyzer from the AWS CLINote: 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.Follow the steps in Getting started with VPC Reachability Analyzer using the AWS CLI.For example, let's say that you're diagnosing connectivity issues between the following points:Source = Amazon Elastic Compute Cloud (Amazon EC2) instance i-ab001122334455667Destination = Internet gateway igw-00aabb11223344556 on port 22 in an Amazon VPC1.    Create a path using the following example command:aws ec2 create-network-insights-path --source i-ab001122334455667 --destination igw-00aabb11223344556 --destination-port 22 --protocol TCPExample output:{    "NetworkInsightsPath": {        "NetworkInsightsPathId": "nip-01a23b456c789101d1",        "NetworkInsightsPathArn": "arn:aws:ec2:us-east-1:123456789012:network-insights-path/nip-01a23b456c789101d1",        "CreatedDate": "2021-06-01T01:00:00.000000+00:00",        "Source": "i-ab001122334455667",        "Destination": "igw-00aabb11223344556",        "Protocol": "tcp",        "DestinationPort": 22    }}2.    Analyze the path by adding the network insights path ID as a parameter in the following example command:aws ec2 start-network-insights-analysis --network-insights-path-id nip-01a23b456c789101d1Example output:{    "NetworkInsightsAnalysis": {        "NetworkInsightsAnalysisId": "nia-0fb371a9ea7ce9712",        "NetworkInsightsAnalysisArn": "arn:aws:ec2:us-east-1:123456789012:network-insights-analysis/nia-0fb371a9ea7ce9712",        "NetworkInsightsPathId": "nip-01a23b456c789101d1",        "StartDate": "2021-06-01T01:00:00.000000+00:00",        "Status": "running"    }}3.    Get the results of the path analysis by adding the NetworkInsightsAnalysisIds parameter obtained in the previous step to the following example command:aws ec2 describe-network-insights-analyses --network-insights-analysis-ids nia-0fb371a9ea7ce9712When a path is unreachable, NetworkPathFound is false and ExplanationCode contains an explanation code. For more information about each of the explanation codes, see VPC Reachability Analyzer explanation codes.Related informationNew – VPC Reachability AnalyzerFollow"


Question: How do I troubleshoot issues with Voicemail for Amazon Connect?

I want to troubleshoot issues with the Voicemail for Amazon Connect solution.

Answer: "I want to troubleshoot issues with the Voicemail for Amazon Connect solution.ResolutionThe Voicemail for Amazon Connect solution provides automated voicemail capabilities for Amazon Connect. This solution uses multiple Amazon Web Services (AWS) services, such as:Amazon ConnectAmazon DynamoDBAmazon Kinesis Video StreamsAmazon Kinesis Data StreamsAWS LambdaAmazon TranscribeThe following are common issues that might occur when configuring or using the Voicemail for Amazon Connect solution:Agents aren’t receiving emails for their voicemails and transcriptsWhen launching the AWS CloudFormation stack, you must enter a parameter for Delivery Email. To receive emails for voicemails and transcripts, the Delivery Email must be verified. For more information, see Verifying an email address identity.Also, when configuring the CloudFormation stack, be sure the RecordingsURLExpirationTime parameter is set to less than, or equal to, seven days. If the RecordingsURLExpirationTime parameter is greater than seven, then the AWS Lambda function responsible for sending the email will fail. The Lambda function responsible for sending the email will fail because presigned URLs don't support an expiry time greater than seven days. For more information, see Authenticating Requests (AWS Signature Version 4).Agents have suddenly stopped receiving text messages for their voicemails and transcriptsBe sure that you’re using the correct SMS destination number. If the SMS destination number is correct, then the SMS delivery might be limited by your spending limit. By default, your AWS account’s text messaging spending limit is set to $1.00 per month. To increase this limit, you can request an increase for the SMS Message Spending in USD quota. For more information, see Requesting a quota increase.The stack fails at the step to customize the Amazon Cognito user pool user interfaceIf your domain for the Amazon Cognito user pool isn’t globally unique, then the domain and user interface creation fail. To correct this, redeploy the CloudFormation stack with a unique domain name in the User Pool Domain Prefix parameter. Be sure to use all lowercase when entering the parameter.You can also check the CloudFormation stack events for error messages. The following is an example error message that you might see: CREATE_FAILED, ROLLBACK_COMPLETE.For more information, see Viewing AWS CloudFormation stack data and resources on the AWS Management Console.The contact flow fails to downloadThe contact flow creation requires a queue named BasicQueue. If this queue name is missing, then the contact flow fails. To correct this, first create a new queue, and then name it BasicQueue. Then, you can export the contact flow.The administrator can’t download the flow and sync agentsIf you get access denied exceptions when trying to sync agents and download contact flows, then verify that you entered your Amazon Connect instance ID. You must enter the Amazon Connect instance ID in the Amazon Connect instance ID parameter. The instance ID is separate from the instance ARN. For more information, see Find your Amazon Connect instance ID/ARN.Unable to set up administrator or manger accounts in the voicemail portalThis issue occurs when using the same email address for the Admin Email and Manager Email parameters. The manager email and administrator email address can’t be the same when deploying the CloudFormation stack. If these email addresses are the same, then you can’t download the contact flows. To correct this, redeploy the CloudFormation stack with different Admin Email and Manager Email addresses.Follow"


Question: Why aren't my inbound emails on Amazon SES arriving or saving to my Amazon S3 bucket?

"I set up an Amazon Simple Email Service (Amazon SES) receipt rule that sends inbound emails to an Amazon Simple Storage Service (Amazon S3) bucket. However, the inbound emails aren't arriving or saving to the S3 bucket."

Answer: "I set up an Amazon Simple Email Service (Amazon SES) receipt rule that sends inbound emails to an Amazon Simple Storage Service (Amazon S3) bucket. However, the inbound emails aren't arriving or saving to the S3 bucket.ResolutionTo identify and resolve what's preventing your inbound emails from saving to the S3 bucket, check the following:Amazon SES domain verificationTo receive inbound emails on Amazon SES, you must complete the verification process for your email domain.Mail exchanger record (MX record)To receive inbound emails on Amazon SES, you must set up one of the following:MX record on your domain's DNS settings.Your receiving mail server to forward emails to the Amazon SES inbound mail sever.The MX record refers to the endpoint for the AWS Region where you use Amazon SES. To check if the record exists using macOS or a Linux operating system, run the digcommand:**Note:**Replace example.comwith your domain.dig MX example.com +shortIf the MX record exists, then the command returns the MX record:example.com. 60 IN MX 10 inbound-smtp.eu-west-1.amazonaws.comTo check if the record exists using a Windows operating system, run the nslookupcommand:At the command prompt, type NSLOOKUP. Then, press Enter.At the **>**prompt, type set type=MX. Then, press Enter.At the next **>**prompt, type your domain. For example, type example.com. Then, press Enter.If the MX record exists, the command returns the MX record:Non-authoritative answer: example.com MX preference = 10, mail exchanger = inbound-smtp.eu-west-1.amazonaws.comNote: If there are more than one MX records for your domain, then make sure that the MX record for inbound emails (SES) has the highest preference. The number before the MX record indicates preference. The lower the number, the higher the preference. For example:10inbound-smtp.us-east-1.amazonaws.com<br>20mail-host1.example.comReceipt rule settingsConfirm that the receipt rule that you're using to send inbound emails to Amazon S3 is in an active rule set. The rule must be in an active rule set to apply to your emails.Additionally, view the receipt rule in the Amazon SES console, and review the following settings:**Enabled:**Confirm that this option is selected. The receipt rule must be turned on for it to apply to your emails.**Require TLS:**If this option is selected, then Amazon SES rejects inbound emails if they aren't encrypted by TLS.**Recipient:**You can enter a single email identity or an email domain. Or, you can leave the field blank so that the rule applies to all your verified domains. If you set a single email identity as the recipient, then confirm that the identity receives the emails that you want to store on Amazon S3. Emails received by any other identity aren't sent to Amazon S3. Additionally, if you set the recipient as an email domain or all of your verified domains, then review your other active receipt rules to confirm that your rules don't overlap.**Note:**Amazon SES runs receipt rules based on the order that you configured on the rule set.**Object key prefix:**If you set an object key prefix, then make sure to check this prefix within your S3 bucket to find the inbound emails.S3 bucket permissionsTo send inbound emails to the S3 bucket, you must grant Amazon SES the necessary permissions on the bucket policy.Review the bucket policy to confirm that Amazon SES has permissions for s3:PutObject. Additionally, modify any **"Effect": "Deny"**statements in the bucket policy that deny Amazon SES permissions for s3:PutObjectexplicitly.EncryptionTo encrypt your inbound emails with AWS Key Management Service (AWS KMS), select your encryption key in the steps to create the Amazon SES receipt rule. You must grant Amazon SES the necessary permissions on the key policy.IP address filter for Amazon SES email receivingIf you set an IP address filter for inbound emails to Amazon SES, then confirm that your inbound emails are from IP addresses that are allowed by your filter.Email file sizeTo store an inbound email in an S3 bucket, the file size of the email (including headers) must be 40 MB or smaller.Related informationSetting up Amazon SES email receivingGiving permissions to Amazon SES for email receivingCreating receipt rules console walkthroughRecipient-based control using receipt rulesFollow"


Question: "How can I determine why I was charged for EventBridge usage, and then how can I reduce future charges?"

"I'm seeing high Amazon EventBridge charges in my AWS bill. How can I see why I was charged for EventBridge usage, and then how can I reduce future charges?"

Answer: "I'm seeing high Amazon EventBridge charges in my AWS bill. How can I see why I was charged for EventBridge usage, and then how can I reduce future charges?Short descriptionReview your AWS Cost and Usage Reports to understand your EventBridge charges. Look for charges for the following service:CloudWatch Events: AWSEvents PutEvents region-Event(-64K-Chunks)|RequestNote: Items in bold are similar to what you might see in your reports. In your reports, region represents the  abbreviation for your AWS Regions.ResolutionCharges are based on the number of events published to EventBridge event buses. Events originated from other AWS services are free. Custom events, events originating from third parties (SaaS), and events from another event bus incur a fee. Events sent from one AWS account to another are billed to the sender account as custom events.To reduce costs:Minimize PutEvents calls.Reduce the number of events that are sent to an event bus. These are also charged as custom events.Keep in mind that events ingested by Scheme discovery and Event replay incur charges.There are similar rules for API destination targets that forward events to web-based applications. In this scenario, charges are based on the number of target invocations.Related informationAmazon EventBridge pricingFollow"


Question: How can I resolve the IAM Identity Center error message "This permission set is currently provisioned in xx AWS accounts"?

I tried to delete the AWS IAM Identity Center (successor to AWS Single Sign-On) permission set and received an error similar to the following:"This permission set is currently provisioned in xx AWS accounts".

Answer: "I tried to delete the AWS IAM Identity Center (successor to AWS Single Sign-On) permission set and received an error similar to the following:"This permission set is currently provisioned in xx AWS accounts".ResolutionTo delete the permission set, you must first remove it from the AWS account that it's provisioned for.Open the IAM Identity Center console, and then in the navigation pane choose AWS accounts.In AWS Accounts, choose the AWS organization tab.Choose the AWS account that is associated with the permission set that you want to delete.Expand Permission sets, and then choose the permission set that you want to remove.In the Remove permission set dialog box, choose Remove access.If you have multiple AWS accounts associated with the permission set, repeat steps 3-5.Choose AWS Accounts in the navigation pane.Choose the Permissions sets tab, choose the permission set, and then choose Delete.The permission set is now deleted. For more information, see Delete permission sets.Related informationHow do I use IAM Identity Center permission sets?How do I get started with using IAM Identity Center and access the AWS access portal?Follow"


Question: How do I create Amazon EC2 instances through CloudFormation when the IAM policy for RunInstances has tag-based restrictions?

I want to create Amazon Elastic Compute Cloud (Amazon EC2) instances through AWS CloudFormation. But my AWS Identity and Access Management (IAM) policy for RunInstances has tag-based restrictions.

Answer: "I want to create Amazon Elastic Compute Cloud (Amazon EC2) instances through AWS CloudFormation. But my AWS Identity and Access Management (IAM) policy for RunInstances has tag-based restrictions.Short descriptionYou can use a launch template to create Amazon EC2 instances through CloudFormation.The Tags property of the AWS::EC2::Instance resource doesn't extend to the volumes that are created through CloudFormation. If the IAM policy that's associated with the user or role has restrictions on volume tags, then you receive the following error:"You are not authorized to perform this operation."To pass the tags through CloudFormation to ec2:CreateVolume, you must define your tags in the AWS::EC2::LaunchTemplate resource in your CloudFormation template.Resolution1.    Define a launch template in the stack with the tags that the IAM policy requires. For example:RequiredTagsLaunchTemplate:    Type: 'AWS::EC2::LaunchTemplate'    Properties:      LaunchTemplateData:        TagSpecifications:          - ResourceType: volume            Tags:              - Key: Env                 Value: Dev2.    Attach your launch template to your EC2 instance resource. For example:Instance:    Type: 'AWS::EC2::Instance'    Properties:      LaunchTemplate:        LaunchTemplateId: !Ref RequiredTagsLaunchTemplate        Version: 1      InstanceType: r4.xlarge      .      .  RequiredTagsLaunchTemplate:    Type: 'AWS::EC2::LaunchTemplate'    Properties:      LaunchTemplateData:        TagSpecifications:          - ResourceType: volume            Tags:              - Key: Env                Value: Dev3.    Confirm that your launch template has all the necessary tags.Important: You must confirm that the role or user that creates the stack has the permissions to create and use a launch template without tagging restrictions. You can use the aws:CalledVia condition key to create a new statement that exempts CloudFormation API calls from tagging requirements.Follow"


Question: How can I allow outgoing traffic from the IP address in my Elastic Beanstalk environment?

I'm required to have a static IP address for the outgoing traffic of the instance in my AWS Elastic Beanstalk environment. I'm also required to integrate that IP address with an external partner application or API. How can I meet these requirements in Elastic Beanstalk?

Answer: "I'm required to have a static IP address for the outgoing traffic of the instance in my AWS Elastic Beanstalk environment. I'm also required to integrate that IP address with an external partner application or API. How can I meet these requirements in Elastic Beanstalk?Short DescriptionA single-instance environment in Elastic Beanstalk comes with a static IP address that's known as an Elastic IP address. You use a single-instance environment in Elastic Beanstalk to allow traffic from the IP address to access an external partner application, API, or other entity.If you want to assign a static IP address in a load-balanced Elastic Beanstalk environment, then complete the steps in How do I assign a static source IP address for all instances in a load balanced Elastic Beanstalk environment?Note: Single-instance environments are generally better suited for applications with low-volume traffic.ResolutionIf you're using a custom VPC instead of the default VPC when you launch your Elastic Beanstalk environment, then verify that your instance is in a public subnet and has an internet gateway with a route to the internet (0.0.0.0/0).After launching your environment, use the Elastic IP address attached to the Amazon Elastic Compute Cloud (Amazon EC2) instance to allow traffic from that IP address to access the external application, API, or other entity.Related InformationConfigurationChanging Environment TypeFollow"


Question: How can I make sure that I receive Amazon SNS notifications from AWS Config?

"I set up an Amazon Simple Notification Service (Amazon SNS) notification for AWS Config, but I don't receive any notifications."

Answer: "I set up an Amazon Simple Notification Service (Amazon SNS) notification for AWS Config, but I don't receive any notifications.Short descriptionTry the following troubleshooting resolutions:Verify the status of your Amazon SNS topic subscriptionGrant your AWS account permission to publish your SNS topicGrant your AWS cross-account permission to publish your Amazon SNS topicConfirm that AWS Config can access encrypted Amazon SNS topicsFix your Amazon CloudWatch Events and SNS permission configurationsResolutionVerify the status of your Amazon SNS topic subscription1.    Open the Amazon SNS console.2.    On the navigation pane, choose Subscriptions.3.    From the list of subscriptions, confirm that the Status of your subscription is set to Confirmed. If Status is set to PendingConfirmation, then follow the instructions to confirm the subscription.Grant your AWS account permission to publish your SNS topicYou must choose either a service-linked role or a custom role as your recorder role. The recorder role is an AWS Identity and Access Management (IAM) role that allows you to record configuration information.Important: As a security best practice, use the custom configuration service role as a recorder role. Avoid using the service-linked role as the recorder role for your cross-account topic policy. This is because the service-linked role requires you to set “config.amazonaws.com” as the Service property in your Amazon SNS topic policy.To replace the Amazon Resource Name (ARN) of the service-linked role with a custom service role ARN, add the following permission to the role permissions policy:{    "Effect": "Allow",    "Action": "sns:Publish",    "Resource": "arn:aws:sns:Region:AccountId:Topic-Name"}For more information on custom roles, see Permissions for the IAM Role Assigned to AWS Config.Grant your AWS cross-account permission to publish your Amazon SNS topicIf you chose an SNS topic from another account, then set up the following configurations to get cross-account access:1.    Add the following statement to the access policy attached to your SNS topic:{    "Sid": "__console_pub_0",    "Effect": "Allow",    "Principal": {        "AWS": "arn:aws:iam::config-AccountId:root" OR "arn:aws:iam::config-AccountId:role/Custom_Service_role_name"    },    "Action": "sns:Publish",    "Resource": "arn:aws:sns:Region:SNS-topic-AccountId:Topic-Name"}2.    Attach the following statement to the IAM role assumed by AWS Config:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "PublishToSNSTargetAccount",            "Effect": "Allow",            "Action": "sns:Publish",            "Resource": "arn:aws:sns:Region:config-AccountId:Topic-Name"        }    ]}Confirm that AWS Config can access encrypted Amazon SNS topicsIf your SNS topic is encrypted with an AWS Key Management Service (AWS KMS) key, complete the following steps:1.    Confirm that the IAM role assumed by AWS Config can access the key required for decrypting the SNS topic. For example:{    "Effect": "Allow",    "Principal": {        "AWS": "arn:aws:iam::config-AccountId:role/ConfigRoleName"    },    "Action": [        "kms:GenerateDataKey*",        "kms:Decrypt",        "kms:Encrypt"    ],    "Resource": "*"}2.    Add AWS KMS permissions in your role's access policy:{    "Effect": "Allow",    "Action": [        "kms:GenerateDataKey*",        "kms:Decrypt",             ],    "Resource": "*"}Fix your Amazon CloudWatch Events and SNS permission configurations1.    Confirm that you chose the correct SNS topic as the target for your CloudWatch Events rule.2.    If you're using Amazon CloudWatch to monitor AWS Config APIs and send notifications using Amazon SNS, confirm that CloudWatch has publishing permissions for your SNS topic. For example, include the following statement in your topic's resource policy:{    "Sid": "Allow_Publish_Events",    "Effect": "Allow",    "Principal": {        "Service": "events.amazonaws.com"    },    "Action": "sns:Publish",    "Resource": "arn:aws:sns:Region:AccountId:Topic-Name"}3.    Troubleshoot your CloudWatch Events rule.Related informationPermissions for the Amazon SNS TopicHow can I be notified when an AWS resource is non-compliant using AWS Config?How can I receive custom email notifications when a resource is deleted in my AWS account using AWS Config service?How can I receive custom email notifications when a resource is created in my AWS account using AWS Config service?Creating IAM Role PoliciesFollow"


Question: How can I troubleshoot latency issues for my edge-optimized API endpoint in API Gateway?

I'm seeing higher latency when clients send requests to my edge-optimized API in Amazon API Gateway. How do I find the source of the latency for troubleshooting?

Answer: "I'm seeing higher latency when clients send requests to my edge-optimized API in Amazon API Gateway. How do I find the source of the latency for troubleshooting?Short descriptionTo find the source of latency for an edge-optimized API endpoint, determine how long each of the following parts of the connection path takes:Important: These connection path steps apply only to edge-optimized API endpoints, and not to Regional API endpoints. Edge-optimized APIs are accessed through an Amazon CloudFront distribution. Regional API endpoints aren't accessed through CloudFront.Start of connection to the DNS name resolutionStart of connection to the Transmission Control Protocol (TCP) handshake to connect to CloudFrontStart of connection to the Secure Sockets Layer (SSL) handshake to connect to CloudFrontStart of connection to sending the client HTTP request to CloudFrontStart of connection to the first byte transferred from CloudFrontTotal time for the request and response to the APITime for API Gateway to process the request and respond to the CloudFront edge locationTime for the integration endpoint to respond to the HTTP request from API GatewayTime for API Gateway to respond to the CloudFront edge location, and for CloudFront to respond to the clientThe parts of the connection path that take the longest are the source of the latency.Note: You can use AWS X-Ray to trace and analyze user requests as they travel through your Amazon API Gateway REST APIs to underlying services. API Gateway supports X-Ray tracing for all API Gateway REST API endpoint types in the AWS Regions where X-Ray is available. To see all the Regions where X-Ray is available, see the AWS Region table.ResolutionRun the curl_for_latency Bash scriptTo determine the duration of steps 1-6 in your API's connection path process, run the curl_for_latency Bash script on GitHub.Important: Make sure that you replace the URL, HTTP method, and parameters values to match the information for your API.The script returns the time period that it takes for your API to complete the following connection path steps:Start of connection to the DNS name resolution ("time_namelookup")Start of connection to the TCP handshake to connect to CloudFront ("time_connect")Start of connection to the SSL handshake to connect to CloudFront ("time_appconnect")Start of connection to sending the client HTTP request to CloudFront ("time_pretransfer")Start of connection to the first byte transferred from CloudFront ("time_starttransfer")Total time for the request and response to the API ("time_total")After you identify the events that are contributing to the latency, see How do I troubleshoot and reduce increased latency from CloudFront?Verify how long it takes API Gateway to process the request and respond to the CloudFront edge locationReview the Latency metric for your API in the CloudWatch console. Then, configure the Latency metrics graph settings for 1-minute interval and Maximum to see the longest processing time within a one-minute time period.For instructions, see View API Gateway metrics in the CloudWatch console.Verify how long it takes for the integration endpoint to respond to the HTTP request from API GatewayReview the IntegrationLatency metric in the CloudWatch console. Then, configure the IntegrationLatency graph settings for 1-minute interval and Maximum to see the longest processing time within a one-minute time period.-or-If you have CloudWatch logging activated for your API, then review the logs for a line item that's similar to the following:Received response. Integration latency: 325 msYou can also add $context variables with access logging for additional latency troubleshooting.For instructions, see How do I turn on CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?API Gateway requests integrated with LambdaIf you're using AWS Lambda with API Gateway and you see a high IntegrationLatency metric, review your Lambda function's CloudWatch Logs. High latency must be addressed when an API endpoint that’s integrated with a Lambda function takes too long to send responses to a client. Cold starts in Lambda functions aren't recorded in the function's duration metric, so your API's integration latency might be longer than the function's duration. To see the duration of your function with a cold start, use AWS X-Ray.For more information, see How do I troubleshoot high latency in my API Gateway requests that are integrated with Lambda?Verify how long it takes API Gateway to respond to the CloudFront edge location, and for CloudFront to respond to the clientTake the total time for the request and response to the API ("time_total"), and then subtract the following:Start of connection to sending the client HTTP request to CloudFront ("time_pretransfer")Time for API Gateway to process the request and respond to the CloudFront edge location (the Latency metric for your API)The result is how long it takes API Gateway to respond to the CloudFront edge location, and for CloudFront to respond to the client.Related informationWorking with metrics for HTTP APIsAmazon API Gateway dimensions and metricsMonitoring WebSocket API execution with CloudWatch metricsHow can I use Amazon API Gateway logs for troubleshooting?Follow"


Question: Why does my AWS Glue test connection fail?

I want to troubleshoot a failed test connection in AWS Glue.

Answer: "I want to troubleshoot a failed test connection in AWS Glue.ResolutionCheck for the following common problems.Networking issuesCheck connectivity to JDBC data stores: AWS Glue creates elastic network interfaces with private IP addresses in the connection's subnet. This means that AWS Glue can't use the public internet to connect to the data store.If the data store is outside the Amazon Virtual Private Cloud (Amazon VPC), then the subnet's route table must have a route to a NAT gateway in a public subnet. Otherwise, the connection times out.Note: The data store outside the Amazon VPC might be an on-premises data store or an Amazon Relational Database Service (Amazon RDS) resource with a public hostname.If the data store is in the Amazon VPC, then confirm that the connection's security groups and network access control list (network ACL) allow traffic to the data store.Check the connection's security groups: One of the security groups associated with the connection must have a self-referencing inbound rule that's open to all TCP ports. Similarly, one of the security groups must also be open to all outbound traffic. You can use a self-referencing rule to restrict outbound traffic to the Amazon VPC. For more information, see Setting up a VPC to connect to JDBC Data Stores.Check the number of free IP addresses: The number of free IP addresses in the subnet must be greater than the number of data processing units (DPUs) specified for the job. This allows AWS Glue to create elastic network interfaces in the specified subnet.Confirm that the subnet can access Amazon Simple Storage Service (Amazon S3): Provide an Amazon S3 endpoint or provide a route to a NAT gateway in your subnet's route table. For more information, see Error: Could not find S3 endpoint or NAT Gateway for subnetId in VPC.Check if you have an AWS KMS VPC endpoint: If your AWS Glue Data Catalog is encrypting connections, be sure that you have a route to AWS KMS. For example, this route can be an AWS KMS VPC interface endpoint. For more information, see Connecting to AWS KMS through a VPC endpoint.Check if the AWS Glue connection and the database use different VPCs: Your test connection fails with a timeout error when the following conditions are true:The database is not publicly accessible.The AWS Glue job is attached to a connection that uses a different VPC without VPC peering.This issue can be resolved by creating a dedicated AWS Glue VPC and setting up the corresponding VPC peerings with your other VPCs as needed. For more information, see Connect to and run ETL jobs across multiple VPCs using a dedicated AWS Glue VPC.Check the connectivity to the on-premises data store: If you are testing the AWS Glue connection to an on-premises database, then it's a best practice to connect to an Amazon Elastic Compute Cloud (Amazon EC2) instance in the same VPC, subnet, and security group used for the connection. Then, run the following tests from the Amazon EC2 instance. If you have issues running the commands, check your VPN and the configurations of VPC, subnet, security group, and network access control lists (ACLs). Be sure that these configurations do not block the connectivity from VPC to your on-premises database or create firewall issues from the on-premises database. For more information, see How to access and analyze on-premises data stores using AWS Glue.$ telnet hostname port$ nc -zv hostname port$ dig hostname$ traceroute -AnT -p IP portAuthentication issuesChoose the correct IAM role: The AWS Identity and Access Management (IAM) role that you select for the test connection must have a trust relationship with AWS Glue. An easy way to do this is to choose a service-linked role that has the AWSGlueServiceRole policy attached to it.Check the connection's IAM role: If the connection password is encrypted with AWS Key Management Service (AWS KMS), then confirm that the connection's IAM role allows the kms:Decrypt action for the key. For more information, see Setting up encryption in AWS Glue.Check the connection logs: Logs from test connections are located in Amazon CloudWatch Logs under /aws-glue/testconnection/output. Check the logs for error messages.Check the SSL settings: If the data store requires SSL connectivity for the specified user, be sure to select Require SSL connection when you create the connection on the console. Don't select this option if the data store doesn't support SSL.Check the JDBC username and password: The user who is accessing the JDBC data store must have sufficient access permissions. For example, AWS Glue crawlers require SELECT permissions. A job that writes to a data store requires INSERT, UPDATE, and DELETE permissions.Check the JDBC URL syntax: Syntax requirements vary by database engine. For more information, see Adding an AWS Glue connection and review the examples under JDBC URL.Additional troubleshootingCheck the connection type:Be sure to choose the correct connection type. When you choose Amazon RDS or Amazon Redshift for Connection type, AWS Glue auto populates the VPC, subnet, and security group.If you need to connect to MySQL, then be aware that the test connection feature works only for MySQL 5.x versions. MySQL version 8 is not supported with the built-in AWS Glue JDBC driver. If you test the connection against a MySQL version newer than version 5.x, then you might get a connection timeout error. However, you can still use your AWS Glue connection to connect to MySQL version 8 with a workaround. Use the connection on an extract, load, and transform (ETL) job by manually providing the compatible driver JAR for MySQL version 8 and later. Then, load this JAR file into your job similar to how you load any JDBC driver on a Spark job. For more information, see Connection types and options for ETL in AWS Glue.Rule out DNS problems: To rule out DNS issues, use the data store's public or private IP address as the JDBC URL for the AWS Glue connection. When you do this, you must uncheck Require SSL connection because you're no longer using a domain name.Check if the driver is incompatible: If the connection fails because of an incompatible driver, provide the correct driver as an extra JAR file in the job properties, along with the failed connection name. (When you specify the connection name as a job property, AWS Glue uses the connection's networking settings, such as the VPC and subnets.) Then, override the default AWS Glue data store drivers by manually creating the Apache Spark dataframe using the JAR file that you provided in the job properties. After creating the dataframe, you can optionally convert it into an AWS Glue DynamicFrame. For more information, see fromDF.Check if the JDBC data store is publicly accessible: Connect to the data store using MySQL Workbench and the JDBC URL. Or, launch an Amazon EC2 instance that has SSH access to the same subnet and security groups used for the connection. Then, connect to the instance using SSH and run the following commands to test connectivity.$ dig hostname$ nc -zv hostname portRelated informationDefining connections in the AWS Glue Data CatalogTroubleshooting errors in AWS GlueFollow"


Question: How do I integrate a multi-Region and multi-account Amazon Cognito user pool with an Amazon Cognito identity pool?

I need to integrate an Amazon Cognito user pool with an Amazon Cognito identity pool when they're located in different accounts.

Answer: "I need to integrate an Amazon Cognito user pool with an Amazon Cognito identity pool when they're located in different accounts.Short descriptionWhen a user signs in to your application, Amazon Cognito verifies the sign-in information. After successfully signing in, an Amazon Cognito user pool creates a session and returns ID, access, and refresh tokens to the authenticated user.An Amazon Cognito identity pool provides temporary AWS credentials for unauthenticated guest users and authenticated users who receive tokens from supported identity providers (IdPs). With these AWS credentials, your application can securely access AWS services.You can integrate an Amazon Cognito user pool with an Amazon Cognito identity pool that's located in a different AWS account. With this configuration, your users authenticate from a user pool in one account. Then, to access AWS services, your users use temporary AWS credentials that they obtain from an identity pool in another account.ResolutionThe following cross-account scenario is an example configuration.An Amazon Cognito user pool is in Account-A in the US East (N. Virginia) AWS Region. The Amazon Cognito identity pool is in Account-B in the Asia Pacific (Mumbai) Region.In this scenario, you must get temporary credentials from the Account-B identity pool for a user who uses the Account-A user pool to authenticate. You must add the Account-A user pool as an authentication provider to the Account-B identity pool.To add the user pool as an authentication provider, follow these steps:1.    Open the new Amazon Cognito console in Account-A.2.    Choose User Pools, and then choose the appropriate user pool from the list.3.    Copy and externally save the values for the User pool ID and the App client id.Example user pool as an authentication provider:Account-A user poolUser pool ID: us-east-1_xxxxxxxxxApp client ID: 79i7hhxxxxxxxx1d5iciiu74.    Open the new Amazon Cognito console in Account-B, and then choose Federated identities.5.    From the list of identity pools, choose the appropriate identity pool.6.    Choose Edit identity pool. The Edit identity pool page appears.7.    Scroll down and choose Authentication providers to show the authentication provider options.8.    For the User pool ID, paste the user pool ID that you copied earlier.9.    For the App client id, paste the app client ID that you copied earlier.10.    Save your changes.Invoke UpdateIdentityPool API to add the user pool as an authentication provider.Example update-identity-pool command:aws cognito-identity update-identity-pool --identity-pool-id example_identity_pool_id --identity-pool-name example_identity_pool_name --no-allow-unauthenticated-identities --cognito-identity-providers ProviderName=cognito-idp.example_region.amazonaws.com/example_user_pool_id,ClientId=example_app_client_id,ServerSideTokenCheck=false --region example_regionDescriptions for the update-identity-pool command:example_identity_pool_id corresponds to the identity pool ID in Account-B. Example: ap-south-1:12345678-abcd-abcd-abcd-1234567890ab.example_app_client_id represents the client ID from Account-A. Example: 79i7hhxxxxxxxx1d5iciiu7.example_region represents the Region of the identity pool. Example: ap-south-1.example_identity_pool_name corresponds to the identity pool name. Example: test-pool.example_user_pool_id represents the user pool from Account-A. Example: us-east-1_xxxxxxxxx.Important: Because the UpdateIdentityPool API resets the identity pool's existing configuration, invoke the DescribeIdentityPool API first. Then, send all the existing identity pool parameters to the UpdateIdentityPool API.Follow"


Question: How can I troubleshoot connect errors when connecting an Amazon OpenSearch Service domain to QuickSight?

"I'm trying to connect my Amazon OpenSearch Service domain to Amazon QuickSight. However, I received an error. How can I resolve this?"

Answer: "I'm trying to connect my Amazon OpenSearch Service domain to Amazon QuickSight. However, I received an error. How can I resolve this?Short descriptionTo connect QuickSight to your Amazon OpenSearch domain, make sure that:Your domain is version 7.7 or higher.Your OpenSearch version is 1.0 or higher.Your OpenSearch Service domain is in the same AWS Region and account as QuickSight.Note: Amazon OpenSearch Service supports OpenSearch and legacy Elasticsearch OSS up to 7.10.ResolutionFollow these troubleshooting steps for your use case.Unsupported engine version errorWhen connecting to an OpenSearch Service domain, you might receive the following error:"Your database uses an unsupported engine version. Please review supported versions."This error occurs when the compatibility mode is not enabled on the OpenSearch Service domain. OpenSearch version 1.0 introduces a domain setting named Enable compatibility mode. Some OpenSearch Service clients and plugins check the cluster version before connecting. Compatibility mode sets OpenSearch Service to report its version as 7.10 so that these clients continue to work. When compatible mode is enabled, QuickSight identifies the correct version and the connection is established successfully.To enable compatibility mode, run the following command:PUT /_cluster/settings{     "persistent": {          "compatibility.override_main_response_version": true     }}Cursor not enabled or unable to prepare this table errorWhen importing the OpenSearch Service domain data into SPICE, you might receive one of the following errors:Can't perform this Action. The domain X has not enabled cursor.-or-Unable to prepare this tableTo enable SQL cursor in your OpenSearch Service domain, run the following command:PUT _opendistro/_sql/settings{     "transient": {          "opendistro.sql.cursor.enabled": "true"     },     "persistent": {          "opendistro.sql.cursor.enabled": "true"     }}Connection error forbiddenIf you have fine-grained access control enabled on OpenSearch Dashboards in your OpenSearch Service domain, you might receive the following error:GENERAL_SQL_EXCEPTION. Connection error forbiddenThis error occurs because the QuickSight service role isn't mapped to an OpenSearch Service role.To resolve this error, follow the instructions to add permissions to a domain to allow access from QuickSight.Related informationUsing Amazon OpenSearch Service with Amazon QuickSightSupported data sourcesConnecting to a VPC with Amazon QuickSightOperational best practices for Amazon OpenSearch ServiceFollow"


Question: How do I use Fargate Spot capacity providers for Amazon ECS?

I want to use AWS Fargate Spot capacity providers for Amazon Elastic Container Service (Amazon ECS).

Answer: "I want to use AWS Fargate Spot capacity providers for Amazon Elastic Container Service (Amazon ECS).Short descriptionBefore you get started, keep the following in mind:Fargate and Fargate Spot capacity providers don't need to be created. They are available to all accounts and only need to be associated with a cluster to be available for use.Fargate Spot capacity provider can be associated with an existing cluster using ECS PutClusterCapacityProviders API and ECS put-cluster-capacity-providers CLI command reference. Adding Fargate Spot capacity provider to an existing cluster is not supported using the AWS Management Console.Fargate and Fargate Spot capacity providers are reserved and can't be deleted. You can disassociate them from a cluster using the PutClusterCapacityProviders API.Fargate Spot requires that your task use platform version 1.3.0 or later (for Linux) and Fargate Spot capacity provider is not supported for Windows containers on Fargate.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Create, associate, and disassociate Fargate Spot capacity provider with your clusterFargate Spot capacity providers are automatically associated with the cluster when they are created from the Amazon ECS console using the Networking only cluster template. For more information, see Creating a cluster for the Fargate launch type using the new console.Associate Fargate Spot capacity provider with your clusterIf the Fargate Spot capacity provider isn't already associated, you can associate the capacity provider with your cluster using the PutClusterCapacityProviders API, or the following AWS CLI command:aws ecs put-cluster-capacity-providers \        --cluster <Cluster_name> \        --capacity-providers FARGATE FARGATE_SPOT \        --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1 \        --region <Region>Important: To avoid overwriting your capacity providers, include all your existing capacity providers and the capacity provider strategy in the preceding command. Capacity providers that aren't included in the command are disassociated from the cluster.Dissociate Fargate Spot capacity provider with your clusterAny existing capacity providers that are associated with the cluster, and that are omitted from a PutClusterCapacityProviders API call, will be disassociated with the cluster. To disassociate the Fargate Spot capacity provider from your Amazon ECS cluster, run the following AWS CLI command:aws ecs put-cluster-capacity-providers \        --cluster <Cluster_name> \        --capacity-providers FARGATE \        --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1 \        --region <Region>Verify that your Fargate Spot capacity provider is associated with your Amazon ECS clusterTo verify that the Fargate Spot capacity provider is associated with your Amazon ECS cluster, run the following command:aws ecs describe-clusters \        --cluster <Cluster_name> \        --region <Region>The output looks similar to the following:Output:      "capacityProviders": [           "FARGATE",           "FARGATE_SPOT"      ]Note: The output of the preceding command includes the capacityProviders section that contains the capacity providers that are associated with your Amazon ECS cluster.Run a task or create a service using Fargate Spot capacity providerTo run a task using a Fargate Spot capacity provider, run the following command:aws ecs run-task \        --cluster <Cluster_name> \        --capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=1 \        --task-definition <Task_definition_family>:<revision> \        --network-configuration "awsvpcConfiguration={subnets=[string,string],securityGroups=[string,string],assignPublicIp=string}" \        --count <Number_of_Tasks> \        --region <Region>To create an Amazon ECS service that uses Fargate Spot capacity providers, run the following command:aws ecs create-service \         --cluster <Cluster_name> \        --service-name <Service_name> \        --capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1 \        --task-definition <Task_defintition_family>:<revision> \        --network-configuration "awsvpcConfiguration={subnets=[string,string],securityGroups=[string,string],assignPublicIp=string}" \        --desired-count <Number_of_tasks> \        --region <Region>Verify if your tasks are running on the Fargate Spot capacity providerTo confirm that your tasks are using Fargate capacity providers, run the following command:aws ecs describe-tasks         --cluster <Cluster_name> \        --tasks <TaskID> \        --region <Region>Tracking Fargate OnDemand and Fargate Spot usage per service from Amazon CloudWatch is not currently supported. However, you can see the metric for total Fargate OnDemand and Spot usage using CloudWatch. For more information, see AWS Fargate usage metrics.Frequently asked questionsWhat are some Fargate Spot best practices?Fargate Spot is great for stateless, fault-tolerant workloads, but don’t rely solely on Spot Tasks for critical workloads. Instead, configure a mix of regular Fargate Tasks.Handle interruptions gracefully by catching SIGTERM signals. When receiving a SIGTERM signal, it's a best practice to set StopTimeout to 120 seconds. For more information, see Graceful shutdowns with ECS.Applications running on Fargate Spot must be fault-tolerant.What happens to the tasks when the FARGATE_SPOT capacity is not available?When the ECS scheduler is unable to launch a task due to capacity not being available, the SERVICE_TASK_PLACEMENT_FAILURE event is emitted. The Task will not get to the first stage PROVISIONING and a notice will not be displayed in the ECS Events. ECS scheduler will continue to try to launch the task. If capacity becomes available, then the SERVICE_STEADY_STATE event will emit.Is there a failover to Fargate when no Fargate Spot capacity is available?It's not possible to have a fail back mechanism to FARGATE when there is no FARGATE_SPOT capacity available.What is an example of how the tasks are placed when using the capacity providers in an ECS service?For this example, there is a capacity provider strategy that contains the following two capacity providers:Provider 1: FARGATE      |  Base:2   Weight:1Provider 2: FARGATE_SPOT |  Base:0   Weight:3According to this strategy, after the base value is satisfied, for every one task that runs using FARGATE, three tasks use FARGATE_SPOT. When the ECS service is created with the desired count of 5, then the following happens:2 tasks are launched using FARGATE to satisfy the base value and the remaining 3 are split between FARGATE and FARGATE_SPOT in a 1:3 ratio.3 tasks are run using FARGATE and 2 tasks in FARGATE_SPOT.Using this same strategy, with a scale-out event that happened and the desired count is increased to 9. The ECS scheduler will see that 3 tasks have already run using FARGATE that has the base satisfied. Also, it will see that the new 4 tasks that are in PROVISIONING state are split between FARGATE and FARGATE_SPOT in a 1:3 ratio. The final 4 tasks are run using FARGATE and 5 tasks in FARGATE_SPOT.Follow"


Question: How can I prevent my Amazon EBS volumes from being deleted when I terminate Amazon EC2 instances?

"When I terminate an Amazon Elastic Compute Cloud (Amazon EC2) instance, the Amazon Elastic Block Store (Amazon EBS) volume is deleted."

Answer: "When I terminate an Amazon Elastic Compute Cloud (Amazon EC2) instance, the Amazon Elastic Block Store (Amazon EBS) volume is deleted.ResolutionWhen an instance terminates, the value of the DeleteOnTermination attribute for each attached EBS volume determines whether to preserve or delete the volume. By default, the DeleteOnTermination attribute is set to True for the root volume. It is set to False for all other volume types.To preserve the root volume when an instance terminates, change the DeleteOnTermination attribute for the root volume to False.Note: You don't incur billing costs for changing these values. However, charges are still incurred for the resources on EBS volumes that you choose to preserve, according to EBS pricing.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.New instancesYou can set the DeleteOnTermination attribute to False when you launch a new instance.For instructions using the Amazon EC2 console, see Change the root volume to persist at launch using the console.To use the AWS CLI or AWS Tools for Windows PowerShell, see Change the root volume to persist at launch using the command line.Running instancesIf the instance is already running, you can set DeleteOnTermination to False using the command line.Related informationAmazon EBS volumesWhat happens when you terminate an instanceFollow"


Question: How do I troubleshoot HTTP 403 Forbidden errors from an API Gateway custom domain name that requires mutual TLS?

My Amazon API Gateway custom domain name that has mutual Transport Layer Security (TLS) authentication activated returns HTTP 403 Forbidden errors. I don't know why this is happening.

Answer: "My Amazon API Gateway custom domain name that has mutual Transport Layer Security (TLS) authentication activated returns HTTP 403 Forbidden errors. I don't know why this is happening.Short descriptionNote: API Gateway can return 403 Forbidden errors for a variety of reasons. This article addresses 403 Forbidden errors related only to mutual TLS. For information on troubleshooting other types of 403 Forbidden errors, see How do I troubleshoot HTTP 403 Forbidden errors from API Gateway?To invoke an API Gateway API using a custom domain name that requires mutual TLS, clients must present a trusted certificate in the API request. When a client attempts to invoke the API, API Gateway looks for the client certificate's issuer in your truststore.The following conditions cause API Gateway to fail the TLS connection, and return a 403 status code:API Gateway can't find the issuer of the client certificate in your truststore.The client certificate is using an insecure signature algorithm.The client certificate is self signed.If Amazon CloudWatch logging is activated for your API, then an error message that indicates the cause of the error appears in your execution logs.Important: If the API request doesn't produce any CloudWatch Logs after logging is activated, then the 403 Forbidden error isn't related to mutual TLS.For REST APIsIf you set up Amazon CloudWatch logging for your REST API, then one of the following error messages also appears in your execution logs:Access denied. Reason: Could not find issuer for certificateAccess denied. Reason: Client cert using an insecure Signature AlgorithmAccess denied. Reason: self signed certificateFor HTTP API operationsHTTP APIs don't support execution logging. To troubleshoot 403 Forbidden errors returned by a custom domain name that requires mutual TLS and invokes an HTTP API, you must do the following:1.    Create a new API mapping for your custom domain name that invokes a REST API for testing only.Note: If you don't have a REST API available for testing, then use the example PetStore REST API. Then, deploy the example API to a new stage, and create a new API mapping that uses your custom domain name.2.    Follow the instructions in the Resolution section of this article using the new API mapping that you created to your REST API.3.    After the error is identified and resolved, reroute the API mapping for your custom domain name back to your HTTP API.ResolutionConfirm the cause of the error1.   Turn on CloudWatch logging for your REST API. Then, configure execution and access logging.When configuring access logging for this use case, it's a best practice to use the following $context variables. These variables do two things:They tell API Gateway to generate CloudWatch Logs when your custom domain name that requires mutual TLS returns a 403 Forbidden error.They make it easier to identify the caller that tried to invoke your API operation when you review your CloudWatch Logs.Recommended $context variables for CloudWatch access logging that will allow API Gateway to generate execution and access logs{ "accountId":"$context.accountId", "apiId":"$context.apiId", "domainName":"$context.domainName", "domainPrefix":"$context.domainPrefix", "error.message":"$context.error.message", "error.responseType":"$context.error.responseType", "extendedRequestId":"$context.extendedRequestId", "httpMethod":"$context.httpMethod", "identity.sourceIp":"$context.identity.sourceIp", "identity.clientCert.clientCertPem":"$context.identity.clientCert.clientCertPem", "identity.clientCert.subjectDN":"$context.identity.clientCert.subjectDN", "identity.clientCert.issuerDN":"$context.identity.clientCert.issuerDN", "identity.clientCert.serialNumber":"$context.identity.clientCert.serialNumber", "identity.clientCert.validity.notBefore":"$context.identity.clientCert.validity.notBefore", "identity.clientCert.validity.notAfter":"$context.identity.clientCert.validity.notAfter", "identity.userAgent":"$context.identity.userAgent", "path":"$context.path", "protocol":"$context.protocol", "requestId":"$context.requestId", "requestTime":"$context.requestTime", "requestTimeEpoch":"$context.requestTimeEpoch", "resourceId":"$context.resourceId", "resourcePath":"$context.resourcePath", "stage":"$context.stage", "responseLatency":"$context.responseLatency", "responseLength":"$context.responseLength", "status":"$context.status" }2.    Identify what's causing the 403 Forbidden errors by viewing your REST API's execution logs in CloudWatch. If a 403 Forbidden error related to mutual TLS is logged, then you receive an error message similar to the following one:Example CloudWatch Logs error message for when a custom domain name that requires mutual TLS returns a 403 Forbidden errorExtended Request Id: {extendedRequestId} Access denied. Reason: {reason} ForbiddenException Forbidden: {requestId}To resolve "Access denied. Reason: Could not find issuer for certificate" errorsVerify that the issuer of the client certificate in the API request is included in the custom domain name's truststoreThe issuer of the client certificate (client.pem) in the API request must be included in your custom domain name's truststore. The issuer must also be included as part of the certificate bundle (bundle.pem) in Amazon Simple Storage Service (Amazon S3).To verify if the issuer of the client certificate is included in the required truststore, run the following OpenSSL command:$ openssl verify -CAfile bundle.pem client.pem-or-If the certificate bundle contains intermediate certificate authorities, then run the following OpenSSL command:$ openssl verify -CAfile rootCA.pem -untrusted intCA.pem client.pemIf the issuer of the client certificate in the API request is included in the required truststore, then the command returns an OK response.If the issuer of the client certificate isn't included in the required truststore, then the command returns the following error: "error X at Y depth lookup: unable to get local issuer certificate"Verify that all of the client certificates in your custom domain name's truststore are validIf one of the client certificate's in your custom domain name's truststore isn't valid, then some clients might not be able to access your API.To verify whether all of the client certificates in your truststore are valid, do the following:1.    Open the API Gateway console.2.    In the left navigation pane, choose Custom domain names. Then, choose your custom domain name that requires mutual TLS.3.    In the Details section, check for the the following error message: There is an invalid certificate in your truststore bundle.4.    If you see the error message, then you must decode the certificates in your truststore to identify which certificate produced the warning.Note: The following OpenSSL command displays the contents of a certificate, including its subject:$ openssl x509 -in certificate.crt -text -noout5.    Update or remove the certificates that produced the warning. Then, upload a new truststore to Amazon S3.For more information, see Troubleshooting certificate warnings.Note: If their certificate chain is preserved, then API Gateway accepts client certificates signed directly by the root certificate authority or any other intermediate certificate authority. To validate client certificates signed by only the last intermediate certificate authority, use a request parameter-based AWS Lambda authorizer. You can use your custom validation algorithm at the Lambda function level by accepting the client certificate as input from the API request.To resolve "Access denied. Reason: Client cert using an insecure Signature Algorithm" errorsVerify that your truststore text file uses a supported hashing algorithmAPI Gateway supports the following hashing algorithms in the truststore:SHA-256 or strongerRSA-2048 or strongerECDSA-256 or strongerTo verify if your truststore text file uses a supported hashing algorithm, run the following OpenSSL command:$ openssl x509 -in client.crt -text -noout | grep 'Signature Algorithm'The command response returns your truststore's signature algorithm.For more information, see Configuring your truststore.To resolve "Access denied. Reason: self signed certificate" errorsVerify that the self-signed client certificate in the API request isn't altered or corruptedThe following must match exactly:The modulus of the private key (private.key) that's used to sign the self-signed certificate within the truststore in S3 (bundle.crt or bundle.pem).The modulus from the client's certificate that's passed in the API request (client.crt).To compare the two moduli, run the following OpenSSL commands:$ openssl rsa -noout -modulus -in private.key$ openssl x509 -noout -modulus -in bundle.crt$ openssl x509 -noout -modulus -in client.crtNote: To produce a shorter hash value for easier comparison, you can PIPE-ing the output modulus into a cryptographic hash function. See the following openssl sha1 example:$ openssl [operation] -noout -modulus -in [data] | openssl sha1Valid command output examples2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcbTo confirm data integrity, verify that there isn't any data modification at the content level by running the following diff command:$ diff client.crt bundle.crtFor more information, see Configuring your truststore.Follow"


Question: How do I troubleshoot custom launch template issues with managed node groups in Amazon EKS?

I want to troubleshoot errors when using custom launch template with managed node groups in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I want to troubleshoot errors when using custom launch template with managed node groups in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.Short descriptionYou might get one of the following errors when using a custom launch template with managed node groups in your Amazon EKS cluster:"Client.InternalError: Client error on launch""SourceEc2LaunchTemplateNotFound or The Amazon EC2 Launch Template lt-xxxxxxxxxxxxxxxxx version x was not found""Node group entered a DEGRADED status"ResolutionClient.InternalError: Client error on launchThis error occurs when using encrypted Amazon Elastic Block Store (Amazon EBS) volumes in the custom launch template with incorrect permissions. To check the encryption status and AWS Identity and Access Management (IAM) permissions or policies, verify the following:The AWS Key Management Service (AWS KMS) key used to encrypt the volume is activated.The AWS KMS key has the correct key policies. To allow more IAM roles to work with encrypted Amazon EBS volumes, you can modify the key policies. For more information, see Allows key users to use the KMS key.SourceEc2LaunchTemplateNotFound or The Amazon EC2 Launch Template lt-xxxxxxxxxxxxxxxxx version x was not foundThis error occurs when you manually change the custom launch template version through the Auto Scaling group of the node instead of Amazon EKS. To resolve this issue, you must update the launch template version using Amazon EKS.To update your EC2 launch template from the managed node group, complete the following steps:Open the Amazon EKS console.In the navigation pane, choose Clusters.In Cluster name, choose the cluster that contains the node group to update.Choose the Compute tab.For Node groups, choose your node and then choose Change version.Select the version to apply to your node group. Make sure that the update strategy is set to Rolling Update.Choose Update.For more information, see Updating a managed node group.Node group entered a DEGRADED status after creating a new launch templateNode group can enter a DEGRADED status with an error similar to the following:"The Amazon EC2 Launch Template : lt-xxxxxxxxxxxxxxxxx has a new version associated with your Autoscaling group, which is not managed by Amazon EKS. Expected Launch Template version : x".This issue happens when the Amazon EC2 launch template version for your managed node group doesn't match the version that Amazon EKS created. Existing node groups that don't use a custom launch template can't be updated directly. To resolve this, create a launch template and version with your preferred settings, and then create the node group using that launch template. If the new node group is launched from your custom template, then you can create new versions of the template. You can use this template without putting the node group in a DEGRADED status.Related informationLaunch template supportLaunch template configuration basicsFollow"