Question: How do I create a VPN connection with my own PSK values and inside tunnel IP addresses?

I want to create a virtual private network (VPN) connection with my own pre-shared key (PSK) value and inside tunnel IP addresses. How can I do this?

Answer: "I want to create a virtual private network (VPN) connection with my own pre-shared key (PSK) value and inside tunnel IP addresses. How can I do this?ResolutionBefore you begin, consider the following:You can modify tunnel options after you create a Site-to-Site VPN connection.You can't configure tunnel options for an AWS Classic VPN connection. For more information, see Migrating from AWS Classic VPN to AWS VPN.To create a VPN connection with your own PSK value and inside tunnel IP addresses, do the following steps:1.    Open the Amazon Virtual Private Cloud (Amazon VPC) console.2.    Choose Site-to-Site VPN connections from the navigation pane.3.    Choose Create VPN Connection.4.    Under Tunnel Options, populate the following with your custom PSK value and inside tunnel IP addresses:Note: Inside tunnel IPv4 CIDR refers to the range of inside (internal) IPv4 addresses for the VPN tunnel. You can specify a size /30 CIDR block from the 169.254.0.0/16 range. The CIDR block must be unique across all Site-to-Site VPN connections that use the same virtual private gateway. The CIDR block doesn't need to be unique across all connections on a transit gateway. However, CIDR blocks aren't unique can create a conflict on your customer gateway. Proceed carefully when re-using the same CIDR block on multiple Site-to-Site VPN connections on a transit gateway.The following CIDR blocks are reserved and cannot be used:169.254.0.0/30169.254.1.0/30169.254.2.0/30169.254.3.0/30169.254.4.0/30169.254.5.0/30169.254.169.252/30Note: Inside tunnel IPv6 CIDR refers to the range of inside (internal) IPv6 addresses for the VPN tunnel. You can specify a size /126 CIDR block from the local fd00::/8 range. The CIDR block must be unique across all Site-to-Site VPN connections that use the same transit gateway.Inside IP CIDR for Tunnel 1Inside IP CIDR for Tunnel 2Note: The PSK must be between 8 and 64 characters in length and cannot start with zero (0). Allowed characters are alphanumeric characters, periods (.), and underscores (_).Pre-Shared Key for Tunnel 1Pre-Shared Key for Tunnel 25.    Choose Create VPN Connection.Related informationTunnel options for your Site-to-Site VPN connectionAWS Site-to-Site VPN adds configurability of security algorithms and timer settings for VPN tunnelsFollow"


Question: How do I troubleshoot issues with hosted zones in Route 53 that have the same domain names in different AWS accounts?

How do I troubleshoot issues with hosted zones in Amazon Route 53 that have the same domain names in different AWS accounts?

Answer: "How do I troubleshoot issues with hosted zones in Amazon Route 53 that have the same domain names in different AWS accounts?ResolutionPublic hosted zones with the same name in two accountsYou can create more than one hosted zone with the same name and add different records to each hosted zone. Route 53 assigns four name servers to every hosted zone, and the name servers are different for each hosted zone. When you update your registrar's name server records, be sure to use the Route 53 name servers for the appropriate hosted zone. You must use the hosted zone that contains the records that Route 53 should use when responding to queries for your domain. Route 53 won't return values for records in other hosted zones that have the same name.For example:In Account A, there's a hosted zone with the domain "101.example.com". Route 53 automatically assigned four name servers to the hosted zone:ns-1701.awsdns-20.co.uk.ns-487.awsdns-60.com.ns-1410.awsdns-48.org.ns-867.awsdns-44.net.There's also a simple Type A record in Account A with the following details:Record nameTypeRouting policyDifferentiatorValue/Route traffic totest1.101.example.comASimple-8.8.8.8In Account B, there's a hosted zone with the same domain name ("101.example.com"). Route 53 automatically assigned four name servers to the hosted zone:ns-869.awsdns-44.net.ns-1332.awsdns-38.org.ns-61.awsdns-07.com.ns-1707.awsdns-21.co.uk.This hosted zone also contains a simple Type A record with following details:Record nameTypeRouting policyDifferentiatorValue/Route traffic totest2.101.example.comASimple-8.8.8.8If the name servers for the domain (101.example.com) present in Account A are updated in Registrar while the name servers of the same domain (101.example.com) present in Account B are not added in Registrar, you get the following dig output:Dig output for Account A: NOERROR# dig test1.101.example.com; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> test1.101.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38973;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;test1.101.example.com.    IN   A;; ANSWER SECTION:test1.101.example.com. 300    IN   A      8.8.8.8Dig output for Account B: NXDOMAINdig test2.101.example.com; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> test2.101.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34489Private hosted zones with the same name in two accountsIn Account A, consider a scenario where there's a private hosted zone ("example.com") in Account A associated with VPC-A. The private hosted zone contains a simple Type A record. In this scenario, the dig output of the resource record from an instance in VPC-A of Account A is NOERROR.Record nameTypeRouting policyDifferentiatorValue/Route traffic toexample.comNSSimple-ns-1536.awsdns-00.co.uk. ns-0.awsdns-00.com. ns-1024.awsdns-00.org. ns-512.awsdns-00.netexample.comSOASimple-ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400test1.example.comASimple-1.1.1.1Dig output for Account A: NOERROR# dig test1.example.com; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> test1.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45251;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;test1.example.com.    IN   A;; ANSWER SECTION:test1.example.com.    60   IN   A   1.1.1.1In Account B, there's another private hosted zone with the same name ("example.com") associated with VPC-B of Account B. This private hosted zone contains a simple Type A record. The dig output of the resource record from an instance in VPC-B of Account B is NOERROR.Record nameTypeRouting policyDifferentiatorValue/Route traffic toexample.comNSSimple-ns-1536.awsdns-00.co.uk. ns-0.awsdns-00.com. ns-1024.awsdns-00.org. ns-512.awsdns-00.net.example.comSOASimple-ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400test2.example.comASimple-2.2.2.2Dig output for Account B: NOERROR# dig test2.example.com; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> test2.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5377;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;test2.example.com.    IN   A;; ANSWER SECTION:test2.example.com.    60   IN   A   2.2.2.2Note: The name servers for private hosted zones in Route 53 are the same four name servers. Keep in mind that you can't associate the same VPC to two private hosted zones with the same name.Follow"


Question: How do I resolve the error "The managed termination protection setting for the capacity provider is invalid" in Amazon ECS?

"When I try to create a cluster capacity provider in Amazon Elastic Container Service (Amazon ECS), I get the following error: "The managed termination protection setting for the capacity provider is invalid. To enable managed termination protection for a capacity provider, the Auto Scaling group must have instance protection from scale in enabled."How can I resolve this error?"

Answer: "When I try to create a cluster capacity provider in Amazon Elastic Container Service (Amazon ECS), I get the following error: "The managed termination protection setting for the capacity provider is invalid. To enable managed termination protection for a capacity provider, the Auto Scaling group must have instance protection from scale in enabled."How can I resolve this error?ResolutionTo resolve the error, enable scale-in protection on your Auto Scaling group. You can enable scale-in protection using either the Amazon Elastic Compute Cloud (Amazon EC2) console or the AWS Command Line Interface (AWS CLI).Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Using the Amazon EC2 console1.    Open the Amazon EC2 console, and then choose Auto Scaling Groups from the navigation pane.2.    Select your Auto Scaling group. From the Details tab, scroll down to Advanced configurations, and then choose Edit.3.    Under Instance scale-in protection, select Enable instance scale-in protection.4.    Choose Update.Using the AWS CLITo enable scale-in protection for the Auto Scaling group using the AWS CLI, run the following command:aws autoscaling update-auto-scaling-group \    --region RegionID \    --auto-scaling-group-name yourASGName \    --new-instances-protected-from-scale-inNote: Replace RegionID with your AWS Region. Replace yourASGName with the name of your Auto Scaling group.TroubleshootingIf you still receive the error, then some of your existing instances launched by the Auto Scaling group might not have scale-in protection.To apply scale-in protection to the remaining instances using either the Amazon EC2 console or the AWS CLI, follow these steps:Using the Amazon EC2 console1.    Open the Amazon EC2 console, and then choose Auto Scaling Groups from the navigation pane.2.    Select your Auto Scaling group, and then choose the Instances tab.3.    From the Instance ID column, select the instances to apply scale-in protection to.4.    On the Instance management tab, choose Actions, Set scale-in protection.5.    Create a capacity provider in Amazon ECS.Using the AWS CLITo list instances from your Auto Scaling group that don't have scale-in protection enabled, run the following AWS CLI command using the query feature:aws autoscaling describe-auto-scaling-groups \    --region RegionID \    --auto-scaling-group-names yourASGName \    --query 'AutoScalingGroups[].Instances[?ProtectedFromScaleIn==`true`].{Id:InstanceId}' \    --output textNote: Replace RegionID with your AWS Region. Replace yourASGName with the name of your Auto Scaling group.Then, follow these steps to enable scale-in protection for the specified instances in your Auto Scaling group:1.    Run the following command:aws autoscaling set-instance-protection \    --region RegionID \    --instance-ids yourInstanceID \    --auto-scaling-group-name yourASGName \    --protected-from-scale-inNote: ReplaceRegionID with your AWS Region. ReplaceyourInstanceID with your instance ID. ReplaceyourASGName with the name of your Auto Scaling group.2.    Create a capacity provider in Amazon ECS.Related informationAmazon ECS cluster auto scalingFollow"


Question: How do I troubleshoot URI connectivity issues using a Lambda function?

I experience connectivity issues with my Amazon VPC-based AWS Lambda function that results in an error. How do I troubleshoot this?

Answer: "I experience connectivity issues with my Amazon VPC-based AWS Lambda function that results in an error. How do I troubleshoot this?Short descriptionYou receive a connection-related error when you try to run your Amazon Virtual Private Cloud (Amazon VPC) Lambda function targeting a remote endpoint or service. This might be due to a network connectivity issue that creates an error message. For example, you try to create a DynamoDB table, but the operation times out.ResolutionCreate a test function that replicates the network configuration of the target function that you want to test. This is useful when you can't edit the target function to add troubleshooting logic. See Configuring a Lambda function to access resources in a VPC for further information on how to configure your Lambda for VPC access.This is an example of a defined test function:import socketdef connect_tcp(event, context):  sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  sock.settimeout(8)  hostname = "www.amazon.com"  port = 443  server_address = (hostname, port) # Server address and port  try:    IPAddr = socket.gethostbyname(hostname)    print("Hostname: " + hostname)    print("Host IP:" + IPAddr)    print("Attempting to connect ..")    sock.connect(server_address)    sock.shutdown(socket.SHUT_RDWR)    print("connected")  except Exception as e:    print("-- Error --")    print(e)  finally:    sock.close()In this example, the socket timeout is set to 8 seconds, which requires that the connection is established within that time, or else it fails. You can adjust this value if necessary.The socket library is a runtime dependency that's not bundled by default with the Python runtime. Include it as part of the deployment package or in a layer that's associated with the function. See Deploy Python Lambda functions with .zip file archives for information on how to deploy dependencies with zip archive. See Using layers with your Lambda function for information on how to deploy dependencies as layers.Note: It's a best practice to attempt to replicate the runtime of the target function. The test function is written in Python, but it can be ported to other runtimes.With the test function in place, troubleshoot by using these steps:Set the hostname and port variables to match the ones to which the target function is attempting to establish a connection.Mirror the network configuration (subnet and security group) of the target function.Set a function timeout value to accommodate any overhead. It's a best practice to make sure that the function timeout is higher than the socket connection timeout to allow for a connection.Run the test.If the test fails, then there is likely a connectivity issue that must be investigated. If the test is successful, then there is likely a connectivity between the Lambda Amazon VPC environment (including the security group) to the endpoint. In this case, there is probably an issue with the target function and any of its dependencies.Note: It's a best practice to check that the test function is launched in a similar subnet as the failing target function where multiple subnets with different routing profiles are involved.If the failing subnet isn't known, rotate through the subnets to identify the failing subnet by following these steps:Specify the first subnet, and ignore the availability warning because you won't deploy this to a production platform.Test the function.Specify the next subnet, and test again.Repeat the previous step until all subnets are checked.Follow"


Question: How can I monitor CloudWatch memory usage metrics for Elastic Beanstalk in a Windows environment?

I want to monitor memory use with Amazon CloudWatch from my AWS Elastic Beanstalk environment in Windows.

Answer: "I want to monitor memory use with Amazon CloudWatch from my AWS Elastic Beanstalk environment in Windows.Short descriptionYou can provision Elastic Beanstalk configuration files (.ebextensions) to monitor memory utilization with CloudWatch for .NET on Windows Server with IIS by doing the following:Create the .ebextensions directory.Create and save configuration file in the .ebextensions directory.Deploy your application and view your metrics.Note: By default, the unified CloudWatch agent is installed on all Elastic Beanstalk Windows environments running platform versions 2.0.1 or later.ResolutionCreate the .ebextensions directoryIn the root of your application bundle, create a hidden directory named .ebextensions.Example: This example demonstrates an application source bundle structure with .ebextensions directory at the top level of the project directory.~/workspace/my-application/|-- Content|-- .ebextensions|  |-- archive.xml`-- systemInfo.xmlCreate and save configuration file in the .ebextensions directoryCreate a file called 01_cw-memory-metrics.config inside the .ebextensions directory that you created as part of the application source bundle.Example: This example extends the CloudWatch agent configuration file - Metrics section.files:  "C:\\Program Files\\Amazon\\AmazonCloudWatchAgent\\cw-memory-config.json":    content: |{  "metrics": {    "append_dimensions": {      "AutoScalingGroupName": "${aws:AutoScalingGroupName}",      "ImageId": "${aws:ImageId}",      "InstanceId": "${aws:InstanceId}",      "InstanceType": "${aws:InstanceType}"    },    "metrics_collected": {      "Memory": {        "measurement": [          "% Committed Bytes In Use"        ],        "metrics_collection_interval": 10      }    }  }}container_commands:  01_set_config_and_reinitialize_cw_agent:    command: powershell.exe cd 'C:\Program Files\Amazon\AmazonCloudWatchAgent'; powershell.exe -ExecutionPolicy Bypass -File ./amazon-cloudwatch-agent-ctl.ps1 -a append-config -m ec2 -c file:cw-memory-config.json -s; powershell.exe -ExecutionPolicy Bypass -File ./amazon-cloudwatch-agent-ctl.ps1 -a start; exitThe 01_cw-memory-metrics.config configuration file does the following:Defines the metrics that the CloudWatch agent collects and publishes to CloudWatch console - Metrics.Collects the metrics for percentage of memory used.The files section includes the CloudWatch agent configuration JSON content that defines which metric to publish to CloudWatch.The container_commands section runs commands after the application bundle is unpacked on the Amazon Elastic Compute Cloud (Amazon EC2) instance.Note: For a list of supported CloudWatch metrics for Amazon EC2, see CloudWatch built-in metrics.Example: This example demonstrates an application source bundle structure with 01_cw-memory-metrics.config included.~/workspace/my-application/|-- Content|-- .ebextensions|   |--01_cw-memory-metrics.config|  |-- archive.xml`-- systemInfo.xmlDeploy your application and view your metricsDeploy your updated Elastic Beanstalk application.Review the memory utilization metrics:Open the CloudWatch console, In the navigation pane, choose Metrics, and then choose All metrics.You can see your metrics in the custom namespace labeled CWAgent.Follow"


Question: How can I configure backtrack on my Amazon Aurora MySQL-Compatible DB cluster?

"I have an Amazon Aurora MySQL-Compatible Edition DB cluster, and I want to backtrack my instance to a time that I specify."

Answer: "I have an Amazon Aurora MySQL-Compatible Edition DB cluster, and I want to backtrack my instance to a time that I specify.Short descriptionYou can choose to turn on backtrack when you create your Amazon Aurora DB cluster. If you have an existing cluster and you want to turn on backtrack, first create a new cluster from a snapshot of your Amazon Aurora cluster. Then, turn on backtrack during the cluster creation process.There are some limitations when you use the backtrack feature:Backtracking is supported for select Aurora MySQL-Compatible versions. You can't use backtrack with Amazon Aurora PostgreSQL-Compatible Edition instances.Backtracking isn't available in these AWS Regions: Africa (Cape Town), China (Ningxia), Asia Pacific (Hong Kong), Europe (Milan), Europe (Stockholm), Middle Easy (Bahrain), and South America (São Paulo).You can't use backtrack with Amazon Aurora multi-master clusters.Backtracking isn't supported with binary log (binlog) replication. This means that cross-Region replication must be turned off before you can configure or use backtracking.The maximum limit for a backtrack window is 72 hours.Backtracking is applied to the cluster as a whole. So, you can't use backtracking for a single data update or for specific tables. You must update the entire cluster.ResolutionFollow these steps to turn on backtrack in your Aurora MySQL-Compatible DB cluster.1.    Create an Aurora MySQL-Compatible cluster.2.    In the Backtrack section of your cluster configuration, select the check box to Enable Backtrack.3.    For Target Backtrack window, choose the number of hours that you want to configure for your Backtrack window. This determines how far back in time you can backtrack the cluster. Enter a number in hours up to 72 hours.You can also modify the backtrack window at a later date, or turn backtrack off entirely by modifying your cluster.If you created an Aurora cluster without turning on the backtrack feature, you must first restore a snapshot of the Aurora cluster. Then, use the steps in this article to turn on backtrack during the snapshot restore/cluster creation process.Related informationAmazon Aurora backtrack - turn back timeFollow"


Question: How do I export a Lightsail instance running Linux to Amazon EC2?

I have an Amazon Lightsail instance running Linux. I want to export the instance to Amazon Elastic Compute Cloud (Amazon EC2) so I can troubleshoot it or use advanced Amazon EC2 features. How do I do that?

Answer: "I have an Amazon Lightsail instance running Linux. I want to export the instance to Amazon Elastic Compute Cloud (Amazon EC2) so I can troubleshoot it or use advanced Amazon EC2 features. How do I do that?ResolutionNote: IP addresses can't be transferred from Lightsail to Amazon EC2. Amazon EC2 instances that are created from exported Lightsail instances have a different IP address.Export a Lightsail instance to Amazon EC21.    Sign in to the Lightsail console.2.    Create a snapshot of the instance.3.    Open the Snapshots tab, and then expand the drop-down menu for your instance.4.    Open the snapshot menu, and then select Export to Amazon EC2.5.    Review the information in the dialog box, and then choose Yes, Continue.6.    Review the information in the dialog box, and then choose Acknowledged.Note: The export can be lengthy, depending on the size and configuration of the source instance or block storage disk. Use the Lightsail Task Monitor to track the status of the export.7.    After the snapshot is exported, open the Lightsail Task Monitor menu, and then select Open the Amazon EC2 console. The snapshot is stored as an Amazon Machine Image (AMI) in the Amazon EC2 console.Note: Don't select Create a new Amazon EC2 instance on the Lightsail Task Monitor menu. Open the Amazon EC2 console to create the instance as described in the Create an Amazon EC2 instance from a Lightsail snapshot section of this article. Instances created from the Lightsail console always display the Lightsail key in the Amazon EC2 console, even if the Lightsail key is removed from the instance. Create the instance manually from the Amazon EC2 console to be sure of SSH key pair consistency.Keep your Lightsail instance until your new solution on Amazon EC2 is up and running. Delete your Lightsail instance when no longer needed to avoid unnecessary charges.After exporting the Lightsail instance to Amazon EC2, you can use the exported snapshot to create a new Amazon EC2 instance, troubleshoot issues, or recover data.Create an Amazon EC2 instance from a Lightsail snapshot1.    In the Amazon EC2 console, open the AMIs pane.2.    Select the AMI associated with the Lightsail snapshot that you created.3.    Choose Launch.4.    Follow the steps in the Amazon EC2 instance creation wizard.Note: In step 5 of the wizard, create a tag for the instance so that you can easily identify it later.5.    Choose Launch.6.    Create a new key pair and download the private key file.7.    Choose Launch instances.8.    After your instance is running, connect to the instance using SSH.9.    Open the ~/.ssh/authorized_keys in a text editor, and then remove the "LightsailDefaultKeyPair" from the file.Troubleshoot or recover data from a Lightsail snapshot using an Amazon EC2 instance1.    Create a new Amazon EBS volume from your Lightsail snapshot.2.    Launch a new Amazon EC2 instance in the same availability zone as your Lightsail instance. The new instance is your rescue instance.3.    Attach the new Amazon EBS volume to the rescue instance.4.    Connect to the new instance using SSH and run the following command:sudo mount /dev/sdf1 /mntImportant: Replace sdf1 with the appropriate device name depending on your instance type and distribution. You can adjust the mount point (/mnt) if you prefer another path. Be sure that the path is not already in use. For Nitro instances, use the device name /dev/nvme1n1p1. For previous generation instances, use the device name /dev/xvdf1.5.    Use the rescue instance to troubleshoot or recover data.Related InformationAmazon EC2 Update – Additional Instance Types, Nitro System, and CPU OptionsElastic IP AddressesElastic Load BalancingRouting Traffic to an Amazon EC2 InstanceFollow"


Question: Why can't I resolve domain names over my VPC peering connection?

I can't resolve domain names over my Amazon Virtual Private Cloud (Amazon VPC) peering connection.

Answer: "I can't resolve domain names over my Amazon Virtual Private Cloud (Amazon VPC) peering connection.ResolutionNote: The following scenarios assume that the VPC is configured with AmazonProvidedDNS. If you're using custom DNS and can't resolve domain names, then do the following:Add the records in the custom DNS.-or-Configure the DNS to forward certain queries to Amazon-provided DNS. Amazon-provided DNS is the .2 IP address of the VPC CIDR.Scenario 1: Resolving to the public DNS of an Amazon EC2 instance created in the peered VPCAmazon Elastic Compute Cloud (Amazon EC2) assigns a private and public DNS name at instance creation. The following domain names are assigned to instances by default:Private DNS: ip-172-31-19-128.ec2.internal (for us-east-1 Region) or ip-172-31-12-97.us-west-2.compute.internal (for other Regions).Public DNS: ec2-54-147-16-116.compute-1.amazonaws.com or ec2-35-88-61-144.us-west-2.compute.amazonaws.com.If you configure the DHCP option set with a custom domain name, such as "example.com", then the EC2 instance uses that domain name. For example, ip-172-31-12-97.us-west-2.example.com.Resolving to a private DNS from any instance in AWS resolves to a private IP address of the VPC where you created the instance:$ dig ip-172-31-12-97.us-west-2.compute.internal +short172.31.12.97Resolving the public DNS of the instance from another instance created in the peered VPC resolves to the public IP address of the instance:$ dig ec2-35-88-61-144.us-west-2.compute.amazonaws.com +short35.88.61.144You can resolve the public domain name to the private IP address of the EC2 instance. To do this, turn on one of the following options on the VPC peering connection:Requester DNS resolution-or-Accepter DNS resolutionFor more information, see Turn on DNS resolution for a VPC peering connection.After turning on DNS resolution, you can resolve the public DNS to the private IP address of the instance. For example: $ dig ec2-35-88-61-144.us-west-2.compute.amazonaws.com +short172.31.12.97If DNS resolution doesn't work after turning on DNS resolution on VPC peering, then use the following steps to troubleshoot the issue.Troubleshooting steps1.    Verify the source VPC and the destination VPC ID.2.    Make sure that there is an active peering connection between the source and destination VPCs using VPC peering.3.    Check the DNS configuration for the peering connection. Make sure that the DNS resolution is turned on for both the requester and accepter VPCs.4.    Verify that the public domain name that you're resolving to exists. Check the destination VPC to make sure that there's an instance with the public IP mentioned in the domain name.5.    Verify whether the DNS configuration in the VPC is AmazonProvidedDNS or CustomDNS. If you're using custom DNS, then verify that the custom DNS resolves the domain name of the public instance. If the custom DNS can't resolve the domain name, then do one of the following:Add a static DNS record.-or-Redirect the query to AmazonProvidedDNS.Scenario 2: Resolving to the domain name of the services created in a peered VPCIf you create a service with a domain name, then you can resolve that domain name from an instance in any peered VPC. Domain names created for these services are public records and can be resolved from anywhere.For example, the following domain name records are publicly resolvable:testCLB-520693273.us-east-1.elb.amazonaws.comtest-87913728ca9b8a68.elb.us-east-1.amazonaws.comvpce-057d3426e21755b8a-svk1k3tm.ssm.us-east-1.vpce.amazonaws.comNote: Even if the domain name is for a private load balancer, the record is public and resolves to the private IP address.Service endpoint domain names, such as ssm.us-east-1.amazonaws.com, resolve to the public IP address. This is true even if there is an interface endpoint created in the peered VPC with the private DNS option turned on. Additionally, these names resolve to private IP addresses only if queried from within the VPC where you created the interface endpoint. In order to resolve the endpoint domain names to endpoint private IP addresses from a peered VPC, you must have the correct DNS architecture created.In the following example, the interface VPC endpoint is configured on VPC A. To resolve the service domain name to the interface VPC endpoint IP addresses in VPC A from VPC B:Create an interface endpoint for the Service with PrivateDNS turned off.Create a private hosted zone using the service domain name (for example, ssm.us-east-1.amazonaws.com) from the account where the Interface endpoint is created.Make sure that DNS hostnames and DNS resolution are turned on for both VPCs in the peering connection.Create an Alias record pointing the service domain name to the regional endpoint of the interface endpoint DNS: vpce-057d3426e21755b8a-svk1k3tm.ssm.us-east-1.vpce.amazonaws.com. Or, create a record pointing the service domain name to the private IP addresses of the interface VPC endpoint created in VPC A.Associate the private hosted zone you created to the peered VPC (VPC B). If VPC B is cross-account, see How do I associate a Route 53 private hosted zone with a VPC on a different AWS account?Troubleshooting steps1.    Verify the source VPC and the destination VPC ID.2.    Make sure that there is an active peering connection between the source and destination VPC.3.    Make sure that DNS hostnames and DNS resolution are turned on for both VPCs in the peering connection.4.    Verify whether the DNS configured in the VPC is AmazonProvidedDNS or CustomDNS. If you're using a custom DNS, then verify that the custom DNS can resolve the domain name. If the custom DNS can't resolve the domain name, then add a static DNS record or configure custom DNS to forward the query to AmazonProvidedDNS.5.    Verify that both peered VPCs are associated to same private hosted zone where the domain name record is created.6.    Make sure that the records are pointing to correct VPC endpoint region-specific domain or interface endpoint IP addresses.Scenario 3: Custom domain name created in private hosted zoneYou created a private hosted zone for a custom domain name that's used to resolve the domain to a record created in private hosted zone. VPC A is associated to a private hosted zone. VPC B has a peering connection to VPC A. You want to resolve the custom domain name from VPC B to VPC A.To resolve, associate the VPC B to the private hosted zone for the custom domain where you created the record. After you make the association, you can resolve the custom domain name in a private hosted zone from resources in both of the peered VPCs.Troubleshooting steps1.    Verify the source VPC and the destination VPC ID.2.    Verify whether the DNS configured in the VPC is AmazonProvidedDNS or CustomDNS. If you're using custom DNS, then you can't resolve to records hosted in private hosted zones. To correct this, add a static domain name record on the custom DNS. Or, configure custom DNS to forward the query to AmazonprovidedDNS.3.    If you're using Amazon-provided DNS, then verify the domain that you're trying to resolve and where it's hosted (Amazon Route 53 or on-premises). If on-premises, make sure that the outbound resolver endpoint used to forward the query to on-premises DNS is configured correctly.4.    If hosted in a Route 53 private hosted zone, verify that the source VPC is associated to the private hosted zone. The source VPC is the location from where you are trying to resolve the custom domain name.5.    Make sure the FQDN that you're trying to resolve has a record created in the private hosted zone.Follow"


Question: How can I provide my Client VPN users with access to AWS resources?

My AWS Client VPN users want to establish a secure connection from their end devices to AWS resources. How can I do this?

Answer: "My AWS Client VPN users want to establish a secure connection from their end devices to AWS resources. How can I do this?ResolutionBefore configuring VPN access to specific resources, consider the following:When a Client VPN endpoint is associated to a subnet, elastic network interfaces are created in the associated subnet. These network interfaces receive IP addresses from the subnet's CIDR.When a Client VPN connection is established, a virtual tunnel adapter (VTAP) is created on the end device. The virtual adapter receives an IP address from the Client VPN endpoint's client IPv4 CIDR.When you associate a subnet with your Client VPN endpoint, Client VPN network interfaces are created in that subnet. Traffic that is sent to the VPC from the Client VPN endpoint is sent through a Client VPN network interface. Source network address translation (SNAT) is then applied, where the source IP address from the client CIDR range is translated to the Client VPN network interface IP address.To give your Client VPN end users access to specific AWS resources:Configure routing between the Client VPN endpoint's associated subnet and the target resource's network. If the target resource is in the same virtual private cloud (VPC) that's associated to the endpoint, then you don't need to add a route. In this case, the VPC's Local Route is used to forward traffic. If the target resource isn't in the same VPC that's associated to the endpoint, then add the respective route in the Client VPN endpoint's associated subnet route table.Configure the target resource's security group to allow inbound and outbound traffic through the Client VPN endpoint's associated subnet. Or, use security groups applied on the endpoint by referencing the security group attached to the endpoint in the target resource's security group rule.Configure the target resource's network access control list (network ACL) to allow inbound and outbound traffic through the Client VPN endpoint's associated subnets.Allow end user access to the target resources in the Client VPN endpoint's authorization rule. For more information, see Authorization rules.Verify that the Client VPN route table has a route for the target resource's network range. For more information, see Routes and Target networks.Allow outbound access to the target resources in the Client VPN endpoint's associated security group.Note: If you have more than one subnet associated with your Client VPN endpoint, you must allow access from each of the Client VPN subnet CIDRs to:The target resource's security groupsThe target resource's network ACLsCreate the routes, security group rules, and authorization rules required to establish connectivity, based on the resource type that your users are accessing. Based on your use case, follow these steps to:Configure access to a VPCConfigure access to the internetNote: Depending on your use case, you can opt to establish a Client VPN connection to VPCs while continuing to route internet traffic through the local gateway. To do this, set up a split-tunnel Client VPN endpoint.Configure access to a peered VPCConfigure access to an on-premises networkRelated informationHow AWS Client VPN worksFollow"


Question: How do I resolve the "[AWS service] was unable to place a task because no container instance met all of its requirements" error in Amazon ECS?

"I want to place a task in Amazon Elastic Container Service (Amazon ECS). However, I receive the following error: "[AWS service] was unable to place a task because no container instance met all of its requirements.""

Answer: "I want to place a task in Amazon Elastic Container Service (Amazon ECS). However, I receive the following error: "[AWS service] was unable to place a task because no container instance met all of its requirements."Short descriptionYou can receive this error due to one or more of the following reasons:No container instances were found in your clusterThe port needed by the task is already in useNot enough memory for your tasksNot enough CPU units for your container instanceNot enough available elastic network interface attachment pointsA required attribute is missing for your container instanceFor more information on these issues, see Service event messages.Note: If you didn't receive the preceding error message, then choose an article based on one of the following error messages that you received:[AWS service] was unable to place a task because no container instance met all of its requirements. The closest matching container-instance container-instance-id has insufficient CPU units available.[AWS service] was unable to place a task because no container instance met all of its requirements. The closest matching container-instance container-instance-id encountered error "AGENT".ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.To resolve the error, choose a resolution based on your use case:If there are no container instances registered in your cluster, then add container instances to your cluster.If the port required by the task is in use, then add container instances to your cluster, or reduce your number of desired tasks.Note: If possible, consider using dynamic port mapping to allow your tasks to use any available port on a container instance.If the container instance doesn't have enough memory for your tasks, then reduce the amount of memory in your task definition. Or, launch more container instances in your cluster. For more information, see the Not enough memory section in Service event messages. This section is located under: service (service-name) was unable to place a task because no container instance met all of its requirements.If the container instance doesn't have enough CPU units, then adjust the CPU required by the tasks, or launch more container instances in your cluster.For more information, see the Not enough CPU section in Service event messages. This section is located under service (service-name) was unable to place a task because no container instance met all of its requirements. Or, refer to How do I resolve "the closest matching container-instance container-instance-id has insufficient CPU units available" error in Amazon ECS?If the container instance doesn't have any available elastic network interface attachment points, then add more container instances to your cluster. For more information, see the Not enough available ENI attachment points section in Service event messages. This section is located under service (service-name) was unable to place a task because no container instance met all of its requirements. If the issue persists, consider using awsvpcTrunking to increase elastic network interface density on your Amazon Elastic Compute Cloud (Amazon EC2) instances.If the container instance is missing a required attribute, then refer to the Container instance missing required attribute section in Service event messages. This section is located under service (service-name) was unable to place a task because no container instance met all of its requirements. To find the missing attributes, run the ecs-cli check-attributes command:ecs-cli check-attributes --task-def Task_Definition --container-instances Container_Instance --cluster Cluster_NameNote: For Task_Definition Name, enter the name of your task definition. For Container_Instance, enter the name of your container instance. For Cluster_Name, enter the name of your cluster.You can configure an Amazon ECS service to run on a subnet that's different from the subnet for the container instance. In this case, the output of the ecs-cli-check-attributes command shows None for missing attributes, even though the task fails with the missing attribute error. Be sure that the subnets for your service and the container instance match. To do this, recreate the Amazon ECS service in the subnet where the container instance exists. For more information, see Task definition parameters and Amazon ECS container agent configuration.For example, if you run the following command:ecs-cli check-attributes --task-def task:1 --container-instances 650cf1df296749e1bce1b9e0cebb588a --cluster test-clusterThe output looks similar to:Container Instance  Missing Attributestes-cluster         NoneFor more information, run the command:ecs-cli --helpRelated informationAmazon ECS task networkingService throttle logicFollow"


Question: How can I change the status of my nodes from NotReady or Unknown status to Ready status?

My Amazon Elastic Kubernetes Service (Amazon EKS) worker nodes are in NotReady or Unknown status. I want to get my worker nodes back in Ready status again.

Answer: "My Amazon Elastic Kubernetes Service (Amazon EKS) worker nodes are in NotReady or Unknown status. I want to get my worker nodes back in Ready status again.Short descriptionYou can't schedule pods on a node that's in NotReady or Unknown status. You can schedule pods only on a node that's in Ready status.The following resolution addresses nodes in NotReady or Unknown status.If your node is in the MemoryPressure, DiskPressure, or PIDPressure status, then you must manage your resources to allow additional pods to be scheduled on the node. If your node is in NetworkUnavailable status, then you must properly configure the network on the node. For more information, see Node status on the Kubernetes website.Note: For information on managing pod evictions and resource limits, see Node-pressure eviction on the Kubernetes website.ResolutionCheck the aws-node and kube-proxy pods to see why the nodes are in NotReady statusA node in NotReady status isn't available for pods to be scheduled on.The managed node group stopped attaching the Container Network Interface (CNI) policy to the node role's Amazon Resource Name (ARN) to improve the security posture. This causes nodes to change to NotReady status because of a missing CNI policy.1.    To see if the aws-node pod is in the error state, run the following command:$ kubectl get pods -n kube-system -o wideTo resolve this issue, follow the guidelines to set up IAM Roles for Service Accounts (IRSA) for aws-node DaemonSet.2.    To check the status of your aws-node and kube-proxy pods, run the following command:$ kubectl get pods -n kube-system -o wide3.    Check the status of the aws-node and kube-proxy pods by reviewing the output from step 1.Note: The aws-node and kube-proxy pods are managed by a DaemonSet. This means that each node in the cluster must have one aws-node and kube-proxy pod running on it. If no aws-node or kube-proxy pods are listed, skip to step 4. For more information, see DaemonSet on the Kubernetes website.If your node status is normal, then your aws-node and kube-proxy pods should be in Running status. For example:$ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODEaws-node-qvqr2                   1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internalkube-proxy-292b4                 1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internalIf either pod is in a status other than Running, run the following command:$ kubectl describe pod yourPodName -n kube-system4.    To get additional information from the aws-node and kube-proxy pod logs, run the following command:$ kubectl logs yourPodName -n kube-systemThe logs and the events from the describe output can show why the pods aren't in Running status. For a node to change to Ready status, both the aws-node and kube-proxy pods must be Running on that node.Note: The name of the pods can differ from aws-node-qvqr2 and kube-proxy-292b4, as shown in the preceding examples.5.    If the aws-node and kube-proxy pods aren't listed after running the command from step 1, then run the following commands:$ kubectl describe daemonset aws-node -n kube-system$ kubectl describe daemonset kube-proxy -n kube-system6.    Search the output of the commands in step 4 for a reason why the pods can't be started.Tip: You can search the Amazon EKS control plane logs for information on why the pods can't be scheduled.7.    Confirm that the versions of aws-node and kube-proxy are compatible with the cluster version based on AWS guidelines. For example, you can run the following commands to check the pod versions:$ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'Note: To update the aws-node version, see Managing the Amazon VPC CNI plugin for Kubernetes add-on. To update the kube-proxy version, follow step 4 in Update the Kubernetes version for your Amazon EKS cluster.In some scenarios, the node can be in Unknown status. This means that the kubelet on the node can't communicate with the control plane with the correct status of the node.To troubleshoot nodes in Unknown status, complete the steps in the following sections:Check the network configuration between nodes and the control planeCheck the status of the kubeletCheck that the Amazon EC2 API endpoint is reachableCheck the network configuration between nodes and the control plane1.    Confirm that there are no network access control list (ACL) rules on your subnets blocking traffic between the Amazon EKS control plane and your worker nodes.2.    Confirm that the security groups for your control plane and nodes comply with minimum inbound and outbound requirements.3.    (Optional) If your nodes are configured to use a proxy, confirm that the proxy is allowing traffic to the API server endpoints.4.    To verify that the node has access to the API server, run the following netcat command from inside the worker node:$ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!Important: Replace 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com with your API server endpoint.5.    Check that the route tables are configured correctly to allow communication with the API server endpoint through either an internet gateway or NAT gateway. If the cluster makes use of PrivateOnly networking, verify that the VPC endpoints are configured correctly.Check the status of the kubelet1.    Use SSH to connect to the affected worker node.2.    To check the kubelet logs, run the following command:$ journalctl -u kubelet > kubelet.logNote: The kubelet.log file contains information on kubelet operations that can help you find the root cause of the node status issue.If the logs don't provide information on the source of the issue, then run the following command to check the status of the kubelet on the worker node:$ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)  Drop-In: /etc/systemd/system/kubelet.service.d           └─10-eksclt.al2.conf   Active: inactive (dead) since Wed 2019-12-04 08:57:33 UTC; 40s agoIf the kubelet isn't in the Running status, then run the following command to restart the kubelet:$ sudo systemctl restart kubeletCheck that the Amazon EC2 API endpoint is reachable1.    Use SSH to connect to one of the worker nodes.2.    To check if the Amazon Elastic Compute Cloud (Amazon EC2) API endpoint for your AWS Region is reachable, run the following command:$ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!Important: Replace us-east-1 with the AWS Region where your worker node is located.Check the worker node instance profile and the ConfigMap1.    Confirm that the worker node instance profile has the recommended policies.2.    Confirm that the worker node instance role is in the aws-auth ConfigMap. To check the ConfigMap, run the following command:$ kubectl get cm aws-auth -n kube-system -o yamlThe ConfigMap should have an entry for the worker node instance AWS Identity and Access Management (IAM) role. For example:apiVersion: v1kind: ConfigMapmetadata:  name: aws-auth  namespace: kube-systemdata:  mapRoles: |    - rolearn: <ARN of instance role (not instance profile)>      username: system:node:{{EC2PrivateDNSName}}      groups:        - system:bootstrappers        - system:nodesFollow"


Question: How can I set up a trust relationship between two AWS Managed Microsoft AD domains?

I want to create a trust relationship between two AWS Directory Service for Microsoft Active Directory domains. How can I do that?

Answer: "I want to create a trust relationship between two AWS Directory Service for Microsoft Active Directory domains. How can I do that?ResolutionConfigure the Amazon Virtual Private Cloud (Amazon VPC) resourcesCreate two Amazon VPCs with two subnets in each VPC.Note: Make sure that Enable DNS hostnames is set to Yes on both VPCs.Create a VPC peering connection between the two VPCs.Modify the VPC peering connection to enable Accepter DNS resolution.Update your VPC route tables to support the peering connection.Configure the AWS Managed Microsoft AD resourcesDeploy an AWS Managed Microsoft AD directory in each VPC.Create an Amazon Elastic Compute Cloud (Amazon EC2) instance in each VPC to manage each corresponding AWS Managed Microsoft AD directory. Then, join each instance to its corresponding directory.Find the default security group for the AWS Managed Microsoft AD domain controllers on each directory. Then, add an Outbound rule for All traffic to 0.0.0.0/0.Install Active Directory administration tools on each management instance.Create a DNS conditional forwarder from one AWS Managed Microsoft AD directory to the otherLog in to the management instance for one AWS Managed Microsoft AD directory (Directory A).Open the DNS management console.Expand Conditional Forwarders.Open the context (right-click) menu and then select New Conditional Forwarder.Enter the FQDN and both IP addresses of the other AWS Managed Microsoft AD directory (Directory B).Choose the option to Store this conditional forwarder in Active Directory and replicate as follows. Then, select All DNS servers in this forest.Choose OK.Create the trust relationship in Directory AOpen the Directory Service console.On the list of Directories, choose the ID of Directory A. This is the directory where you created a DNS conditional forwarder in the previous steps.Follow the steps to configure the trust relationship in Directory A.After you create the trust relationship, the status is Verify Failed. Proceed with the steps to create the trust relationship on Directory B.Create the trust relationship in Directory BOpen the Directory Service console.On the list of Directories, choose the ID of Directory B. This is the directory that the DNS conditional forwarder points to.Follow the steps to configure the trust relationship in Directory B.After you create the trust relationship, the status is Verified.Verify the trust relationship in Directory AReturn to the trust relationship that you created for Directory A.Verify the trust.After you verify the trust, the status of the trust relationship for Directory A changes to Verified.Follow"


Question: How do I check which role is used by my Amazon SageMaker Studio user? How do I change this role?

"I want to know which role is being used by Amazon SageMaker Studio user. Then, I want to change this role."

Answer: "I want to know which role is being used by Amazon SageMaker Studio user. Then, I want to change this role.ResolutionWhen you create and access a SageMaker Studio domain, you use the following AWS Identity and Access Management (IAM) roles:SageMaker Studio domain execution role: You use this role to set up and provision your studio infrastructure after accessing Studio integrated development environment (IDE) through the presigned URL.SageMaker user profile role: The permission scope of this role defines the actions that a user profile can perform within the Studio environment. This is the execution role that's assumed by SageMaker to create resources on your behalf within Studio.When you create a SageMaker Studio domain, then by default SageMaker allows you to create the execution role. This role has the AmazonSageMakerFullAccess policy attached to the role. This policy gives an extended access to user profile. If your use case requires that you manage these permissions, you can restrict access to user profiles by changing the SageMaker user profile role.To check the role that's attached to the user profile, run the following on a Jupyter notebook that was created by the user profile:import sagemakersagemaker_session = sagemaker.Session()#Check which role is being usedrole = sagemaker.get_execution_role()print(role)To change the role that's attached to a user profile, run the UpdateUserProfile command.You can update the role that's attached to an existing user profile by running the following AWS Command Line Interface (AWS CLI) command:aws sagemaker update-user-profile --example-domain-id --example-user-profile-name --user-settings ExecutionRole=arn:aws:iam::1111222233334444:role/service-role/example_sagemaker_execution_roleImportant: Before changing the IAM role for a SageMaker Studio user profile, be sure that your user doesn't have any 'InService' Apps active.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Related informationSageMaker rolesFollow"


Question: How can I resolve the "Bucket name already exists" or "BucketAlreadyExists" error from Amazon S3?

"I'm trying to create a new bucket in Amazon Simple Storage Service (Amazon S3). However, I'm getting one of the following errors:"Bucket name already exists" from the Amazon S3 console"BucketAlreadyExists" from the AWS Command Line Interface (AWS CLI) or an AWS SDK"Bucket name is already owned by you" from the Amazon S3 console"BucketAlreadyOwnedByYou" from the AWS CLI or an AWS SDKHow do I resolve this?"

Answer: "I'm trying to create a new bucket in Amazon Simple Storage Service (Amazon S3). However, I'm getting one of the following errors:"Bucket name already exists" from the Amazon S3 console"BucketAlreadyExists" from the AWS Command Line Interface (AWS CLI) or an AWS SDK"Bucket name is already owned by you" from the Amazon S3 console"BucketAlreadyOwnedByYou" from the AWS CLI or an AWS SDKHow do I resolve this?ResolutionAmazon S3 bucket names must be unique globally. If you get the "Bucket name already exists" or "BucketAlreadyExists" error, then you must use a different bucket name to create the bucket. These error messages indicate that another AWS account owns a bucket with the same name.If you get the "Bucket name is already owned by you" or "BucketAlreadyOwnedByYou" error, then check your account for a bucket with the same name. These error messages indicate that your account is already using the bucket name. You can use the Amazon S3 console to review existing buckets. Or, you can run the head-bucket AWS CLI command to confirm whether you already have a bucket with that name.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Related informationHow do I create an S3 bucket?Follow"


Question: How can I use a Lambda function created in one AWS account with an AWS CloudFormation custom resource in another AWS account?

"I want to create an AWS Lambda function in one account, and then invoke that function from an AWS CloudFormation custom resource in another account."

Answer: "I want to create an AWS Lambda function in one account, and then invoke that function from an AWS CloudFormation custom resource in another account.Short descriptionYou can invoke a Lambda function from a custom resource in a different account only if the Lambda function and the custom resource are in the same AWS Region. The ServiceToken property of AWS::CloudFormation::CustomResource must be in the same Region where you created your AWS CloudFormation stack. You must use a resource-based policy to grant the accounts with your custom resources permission to invoke your Lambda function.Note: When you associate a Lambda function with a custom resource, the function is invoked whenever the custom resource is created, updated, or deleted. AWS CloudFormation calls a Lambda API to invoke the function and to pass all the request data to the function. For example, request data includes the request type and resource properties.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.To grant your Lambda function access to your custom resource from another account (Account B), run the AWS CLI command add-permission in your primary account (Account A).-or-1.    When a Lambda function is created through a stack in Account A, use the AWS::Lambda::Permission resource to grant permission to Account B.2.    In Account B, launch the AWS CloudFormation stack that contains your custom resource.Note: Be sure that the ServiceToken refers to the Lambda function's Amazon Resource Name (ARN) from Account A. Include any additional properties to send to the custom resource as input.3.    Use Amazon CloudWatch Logs to confirm that your custom resource from Account B invoked your Lambda function in Account A.Related informationPropertiesGranting function access to other accountsFollow"


Question: How do I troubleshoot HTTP 502 and HTTP 500 status code (server-side) errors from AWS Lambda?

"When I try to invoke my AWS Lambda function, the request fails with a 502 or 500 server-side error. How do I troubleshoot these errors?"

Answer: "When I try to invoke my AWS Lambda function, the request fails with a 502 or 500 server-side error. How do I troubleshoot these errors?ResolutionFirst, identify the specific Lambda Invoke API error that you receive. Then, follow the troubleshooting steps listed for that error.Note: For a list of possible errors and their descriptions, see Errors in the Lambda Invoke API reference.InvalidRuntimeExceptionThe runtime or runtime version specified isn't supported. Configure your Lambda function to use the correct Lambda runtime for your function code.InvalidSecurityGroupIDExceptionConfirm that you specified the correct Amazon VPC security group ID in your Lambda function configuration. For more information, see Configuring a Lambda function to access resources in a VPC.InvalidZipFileExceptionCheck the permissions on your Lambda deployment package. For more information, see How do I troubleshoot Lambda "permission denied" or "unable to import module" errors when uploading a deployment package?Also, confirm that you created the deployment package file correctly. For more information, see Lambda deployment packages.KMSAccessDeniedExceptionCheck your Lambda function's AWS Identity and Access Management (IAM) permissions and your AWS Key Management Service (AWS KMS) key policies.The KMSAccessDeniedException error usually occurs when a Lambda function's IAM role is deleted and then is recreated with the same name. If this is what happened, configure a new IAM role for the function. Then, deploy the function again and reconfigure the previous IAM role.For more information, see Using key policies in AWS KMS.Note: The IAM user who creates and updates the Lambda function must have permission to use the AWS KMS key.KMSDisabledExceptionVerify that the KMS key is activated. For more information, see Enabling and disabling keys.KMSInvalidStateExceptionYour AWS key isn't in a valid state for AWS KMS Decrypt API requests. Verify that the AWS key is activated.For more information, see How key state affects use of a customer managed key.KMSNotFoundExceptionThe AWS KMS key specified in your request must be in the same AWS Region and account as your Lambda function. If the Region is different, then use another AWS KMS key (or create a new AWS KMS key) in the same Region.ResourceNotReadyExceptionLambda reclaims network interfaces that aren't in use. This action can place a function in an inactive state. When a function that is inactive is invoked, the function enters a pending state while VPC network access is restored. The first invocation and all others that occur while the function is in a pending state fail and then produce a ResourceNotReadyException error.To resolve the error, wait until the VPC connection is restored. Then, invoke the Lambda function again.ServiceExceptionSometimes the Lambda service itself encounters an internal error. If you get a 500 error, check the AWS Service Health Dashboard to determine if Lambda is unavailable. For more information, see Is AWS down?If Lambda is available, retry the request to invoke your Lambda function.SubnetIPAddressLimitReachedExceptionA subnet's size is defined by its CIDR block. Be sure that the CIDR blocks that you specify in your Amazon VPC have enough free IP addresses for your Amazon VPC-activated Lambda function's requirements. For more information, see VPC and subnet sizing.You have exceeded the maximum limit for Hyperplane elastic network interfaces for your accountThe default maximum number of Hyperplane elastic network interfaces or each virtual private cloud (VPC) is 250. For information on how to request a limit increase, see Service Quotas.Follow"


Question: How can I use AWS IAM Access Analyzer to monitor my AWS resources in my AWS Organization accounts?

I want to use AWS IAM Access Analyzer to identify resources in my organization and accounts that are shared with an external entity.

Answer: "I want to use AWS IAM Access Analyzer to identify resources in my organization and accounts that are shared with an external entity.ResolutionYou can add a member account in the organization as the delegated administrator to manage Access Analyzer for your organization. The delegated administrator has permissions to create and manage analyzers with the organization as the zone of trust. Access Analyzer analyzes only policies applied to resources in the same AWS Region where it's enabled. To monitor all resources in your AWS environment, you must create an analyzer to enable Access Analyzer in each Region where you're using supported AWS resources. For more information, see Delegated administrator for Access Analyzer.Note: 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 instructions to add a delegated administrator using the AWS Management Console or AWS CLI. Then, follow the instructions to create an analyzer with the organization as the zone of trust.Note: Only the management account can add a delegated administrator.To view the status of your analyzers, see Access Analyzer status.Related informationGetting started with AWS IAM Access AnalyzerUsing AWS IAM Access AnalyzerAccess Analyzer resource typesFollow"


Question: How do I turn on CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?

I need to debug errors with an Amazon API Gateway REST API or WebSocket API that I'm developing. How do I turn on logging to troubleshoot my API?

Answer: "I need to debug errors with an Amazon API Gateway REST API or WebSocket API that I'm developing. How do I turn on logging to troubleshoot my API?Short descriptionTo troubleshoot an API Gateway REST API or WebSocket API, turn on execution logging and access logging using Amazon CloudWatch Logs.Note: HTTP APIs currently support access logging only, and logging setup is different for these APIs. For more information, see Configuring logging for an HTTP API.Execution logs contain information that you can use to identify and troubleshoot most API errors. For example:The requests that your API receivesThe integration backend responses from your APIThe response provided by AWS Lambda authorizersThe requestId for AWS integration endpointsInformation on whether a provided API key was authorizedAccess logs contain details about who accessed your API and how they accessed it. You can also use the logs for troubleshooting API errors. For more information about each type of logging, see CloudWatch log formats for API Gateway.ResolutionCreate an IAM role for logging to CloudWatch1.    In the AWS Identity and Access Management (IAM) console, in the navigation pane, choose Roles.2.    On the Roles pane, choose Create role.3.    On the Create role page, do the following:For Trusted entity type, choose AWS Service.For use case, choose API Gateway.Choose the API Gateway radio button.Choose Next.4.    Under Permissions Policies, note that the AWS managed policy AmazonAPIGatewayPushToCloudWatchLogs is selected by default. The policy has all the required permissions.5.    Choose Next.6.    Under Name, review and create, do the following:For Role name, enter a name for the role.(Optional) For Role description, edit the description to your preferences.(Optional) Add tags.Choose Create role.7.    On the Roles pane, in the search bar, enter the name of the role that you created. Then, choose the role from the search results.8.    On the Summary pane, copy the Role ARN. You need this Amazon Resource Name (ARN) in the next section.For more information, see Permissions for CloudWatch logging.Add the IAM role in the API Gateway consoleNote: If you're developing multiple APIs across different AWS Regions, complete these steps in each Region.1.    In the API Gateway console, on the APIs pane, choose the name of an API that you created. This is either a REST API or a WebSocket API (not an HTTP API).2.    In the left navigation pane, at the bottom, below the Client Certificates section, choose Settings.3.    Under Settings, for CloudWatch log role ARN, paste the IAM role ARN that you copied.4.    Choose Save.Note: The console doesn't confirm that the ARN is saved.Turn on logging for your API and stage1.    In the API Gateway console, on the APIs pane, choose the name of an API that you created.2.    In the left navigation pane, choose Stage. Then, select your desired stage name.3.    Choose the Logs/Tracing tab.4.    On the Logs/Tracing tab, under CloudWatch Settings, do the following to turn on execution logging:Choose the Enable CloudWatch Logs check box.For Log level, choose INFO to generate execution logs for all requests. Or, choose ERROR to generate execution logs only for requests to your API that result in an error.For REST APIs, choose the Log full requests/responses data check box. Or, for WebSocket APIs, choose the Log full message data check box.5.    Under Custom Access Logging, do the following to turn on access logging:Choose the Enable Access Logging check box.For Access Log Destination ARN, enter the ARN of an Amazon Kinesis Data Firehose (this is only supported in REST APIs) or a CloudWatch log group.Enter a Log Format. For guidance, choose CLF, JSON, XML, or CSV to see an example in that format.6.    Choose Save Changes.Note: The console doesn't confirm that settings are saved.For more information, see Set up CloudWatch API logging using the API Gateway console.Test your logging setup1.    Send a new request to your API using your client application or a tool such as the Postman app or wscat (for WebSocket APIs).2.    In the CloudWatch console, in the left navigation pane, under Logs, choose Log Groups.3.    In the list of Log Groups, choose the log group of the API that you're debugging.For REST APIs, the log group's name is in the following format: API-Gateway-Execution-Logs_apiId/stageName.For WebSocket APIs, the log group's name is in the following format: /aws/apigateway/apiId/stageName.Note: The access logs are located in the log group whose ARN that you specified when you turned on access logging.4.    In the list of Log Streams, choose the logs stream with the latest Last Event Time. This selection will allow you to see messages with the execution or access details of your request.For more information, see View API Gateway log events in the CloudWatch console.Related informationSetting up CloudWatch logging for a REST API in API GatewayAPI Gateway mapping template and access logging variable referenceMonitoring REST API execution with Amazon CloudWatch metricsMonitoring WebSocket API execution with CloudWatch metricsFollow"


Question: How can I monitor high memory utilization for Amazon ECS tasks on Fargate?

I want to monitor high memory utilization for Amazon Elastic Container Service (Amazon ECS) tasks running on AWS Fargate.

Answer: "I want to monitor high memory utilization for Amazon Elastic Container Service (Amazon ECS) tasks running on AWS Fargate.ResolutionTo monitor high memory utilization on your Amazon ECS tasks on Fargate, try the following options:View Amazon CloudWatch metricsView Amazon CloudWatch metrics in either the Amazon ECS console or CloudWatch console.Note: Any Amazon ECS service that uses the Fargate launch type is automatically enabled for Amazon CloudWatch memory and CPU utilization metrics.Enable CloudWatch logs for your Fargate tasks1.    Enable the awslogs log driver.2.    Add the required log configuration parameters to your task definition.3.    Give the Amazon ECS task execution for your AWS Identity and Access Management (IAM) role the permissions to send logs to Amazon CloudWatch Logs.4.    View your logs in the CloudWatch console.Note: Your tasks must enter the Running state before you can view your logs.Use Container Insights to monitor memory utilizationYou can use CloudWatch Container Insights to monitor memory utilization for each container in a Fargate task.1.    Open the CloudWatch console.2.    From the navigation pane, in the Container Insights section, choose Resources.3.    To get more information about a resource, choose the name of the resource.Note: Tasks are grouped by the task definition for each cluster.4.    Choose the name of the task definition that you want more information about.5.    In the Container Performance section, choose Actions, and then choose View performance logs. This opens CloudWatch Logs Insights for your ECS cluster.6.    In the query box, enter the following query, and then choose Run query:stats avg(MemoryUtilized) by bin (30m) as period, TaskDefinitionFamily, TaskDefinitionRevision                | filter Type = "Task" | sort period desc, TaskDefinitionFamily |  limit 10Use Container Insights to set an alarm on high memory utilization1.    Open the CloudWatch console.2.    From the navigation pane, in the Container Insights section, choose Performance Monitoring.3.    From the dropdown menu, choose ECS Tasks or ECS Services.4.    On the Memory Utilization card, choose the expander (vertical dots), and then choose View in Metrics.5.    Choose the Graphed metrics tab, and then choose the bell icon in the Actions column for the task that you want more information about.6.    On the Specify metric and conditions page, choose your desired values or leave the default values.7.    In the Conditions section, for Define the threshold value, enter 70. This sets the alarm's memory utilization threshold to 70%.8.    Choose Next.9.    On the Configure actions page, in the Select an SNS topic section, select Create new topic.10.    For Send a notification to, enter the email ID where you want the alarm notifications sent.11.    Choose Next.12.    On the Add name and description page, for Alarm name, enter a name for your alarm. 13.    (Optional) For Alarm description, enter a description for your alarm.14.    Choose Next, and then choose Create alarm.15.    Confirm your subscription by following the instructions in the confirmation email that you receive from AWS.Note: CloudWatch doesn't automatically create all possible metrics from the log data to help you manage your Container Insights costs. You can view additional metrics and additional levels of granularity by using CloudWatch Logs Insights to analyze the raw performance log events.Related informationAmazon ECS on AWS FargateIntroducing Amazon CloudWatch Container Insights for Amazon ECSHow Amazon ECS manages CPU and memory resourcesFollow"


Question: "I'm receiving "Permission denied (publickey)" or "Authentication failed, permission denied" errors when trying to access my EC2 instance. How do I resolve this?"

"I'm receiving "Permission denied (publickey)" or "Authentication failed, permission denied" errors when accessing my Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I resolve this?"

Answer: "I'm receiving "Permission denied (publickey)" or "Authentication failed, permission denied" errors when accessing my Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I resolve this?Short description"Permission denied (publickey)" and "Authentication failed, permission denied" errors occur when:You're trying to connect using the wrong user name for your AMI.The file permissions within the operating system are incorrect on the instance.The incorrect SSH public key (.pub) file is in the authorized_keys file.ResolutionVerify that you're using the correct user name for your AMIFor a list of valid user names, see Error: Server refused our key or No supported authentication methods available.Verify that the file permissions within the operating system are correct and that the correct SSH public key is in the authorized_keys fileThere are four methods for performing these tasks:Method 1: Use the EC2 Serial ConsoleIf you activated EC2 Serial Console for Linux, then you can use it to troubleshoot supported Nitro-based instance types. The serial console helps you troubleshoot boot issues, network configuration, and SSH configuration issues. The serial console connects to your instance without the need for a working network connection. You can access the serial console using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).Before using the serial console, grant access to it at the account level. Then, create AWS Identity and Access Management (IAM) policies granting access to your IAM users. Also, every instance using the serial console must include at least one password-based user. If your instance is unreachable and you haven’t configured access to the serial console, then follow the instructions in Method 2, 3, or 4. For information on configuring the EC2 Serial Console for Linux, see Configure access to the EC2 Serial Console.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Method 2: Use AWS Systems Manager Session Manager to log in to the instance and make correctionsThis method updates permissions and injects your SSH public key into the authorized_keys file.Note: Installation of the SSM Agent is required to use this method. For more information on Session Manager and a complete list of prerequisites, see Setting up Session Manager.1.    Open the AWS Systems Manager console.2.    Start a session.3.    Use the ls -ld command to make sure that the permissions of the files under the home directory are correct. The following is a list of the correct permissions:Linux home directory, /home, for example, should be (0755/drwxr-xr-x).User's home directory, /home/ec2-user/, for example, should be (0700/drwx------)..ssh directory permission, /home/ec2-user/.ssh, for example, should be  (0700/drwx------).authorized_keys file permission, /home/ec2-user/.ssh/authorized_keys, for example, should be (0600/-rw-------).The following is an example of the ls -ld command and the resulting output. In this example, ec2-user is the user name. Change the user name according to your specific AMI.$ ls -ld /home/ec2-user/drwx------ 3 ec2-user ec2-user 4096 Apr  1 08:31 /home/ec2-user/4.    On your local computer, verify the SSH public key.5.    If the signature of the SSH public key isn't present in the output, then update the authorized_keys file to allow your SSH key. In the following example, replace the example key with your SSH public key.$ echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/ec2-user/.ssh/authorized_keys6.    To correct permissions, run the following commands on your EC2 instance.$ sudo chown root:root /home$ sudo chmod 755 /home$ sudo chown ec2-user:ec2-user /home/ec2-user -R$ sudo chmod 700 /home/ec2-user /home/ec2-user/.ssh$ sudo chmod 600 /home/ec2-user/.ssh/authorized_keys7.    End the session.8.    Connect to the instance using SSH.Method 3: Run the AWSSupport-TroubleshootSSH Automation procedureAWSSupport-TroubleshootSSH installs the Amazon EC2Rescue tool. After installation, the tool checks for and corrects some issues that cause remote connection errors when connecting to a Linux machine through SSH. For more information, see How can I use the AWSSupport-TroubleshootSSH Automation workflow to troubleshoot SSH connection issues?Method 4: Use a user data script to repair SSH permissions and add the correct SSH public key to the authorized_keys fileImportantIf your instance is instance store-backed or has instance store volumes containing data, then the data is lost when the instance is stopped. For more information, see Determine the root device type of your instance.If your instance is part of an Amazon EC2 Auto Scaling group, then stopping the instance might terminate it. Instances launched with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be part of an AWS Auto Scaling group. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, temporarily remove the instance from the Auto Scaling group before starting the resolution steps.Stopping and starting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.1.    Open the Amazon EC2 console.2.    Choose Instances from the navigation pane, and then select the instance you are trying to launch.3.    Stop the instance.4.    Choose Actions, Instance settings, Edit User Data.5.    Copy the following user data script into the Edit User Data dialog box, and then choose Save.Content-Type: multipart/mixed; boundary="//"MIME-Version: 1.0--//Content-Type: text/cloud-config; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="cloud-config.txt"#cloud-configcloud_final_modules:- [scripts-user, always]--//Content-Type:    text/x-shellscript; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="userdata.txt"#!/bin/bashOS_USER=@@@@@@chown root:root /home chmod 755 /homechown $OS_USER:$OS_USER /home/$OS_USER -Rchmod 700 /home/$OS_USERchmod 700 /home/$OS_USER/.sshchmod 600 /home/$OS_USER/.ssh/authorized_keys--//Note: Replace the value for OS_USER with the user name associated with the AMI you launched your instance from. For more information, see Get the default user name for the AMI that you used to launch your instance in Common causes for connection issues.6.    On your local computer, verify the SSH public key.7.    If the signature of the SSH public key isn't present in the output, then append the correct key to the user data script that you created in step 5. If the signature matches, then you can skip this step. Append the SSH public key to the user data script as shown in the following example. Replace the example key with your SSH public key.Content-Type: multipart/mixed; boundary="//"MIME-Version: 1.0--//Content-Type: text/cloud-config; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="cloud-config.txt"#cloud-configcloud_final_modules:- [scripts-user, always]--//Content-Type:    text/x-shellscript; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitContent-Disposition: attachment; filename="userdata.txt"#!/bin/bashOS_USER=@@@@@@chown root:root /home chmod 755 /homechmod 700 /home/$OS_USERchmod 700 /home/$OS_USER/.sshchmod 600 /home/$OS_USER/.ssh/authorized_keysecho 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/$OS_USER/.ssh/authorized_keyschown $OS_USER:$OS_USER /home/$OS_USER -R--//Note: Replace the value for OS_USER with the user name associated with the AMI you launched your instance from. For more information, see Get the default user name for the AMI that you used to launch your instance in Common causes for connection issues.8.    Start your instance.Note: The preceding user data script is set to run on every reboot of the instance. After regaining access to your instance, remove the user data script.To remove user data:Complete steps 1–4 in this section.Delete the user data script in the Edit User Data dialog box.Related informationHow do I troubleshoot problems connecting to my Amazon EC2 Linux instance using SSH?I've lost my private key. How can I connect to my Linux instance?How can I connect to my Amazon EC2 instance if I lost my SSH key pair after its initial launch?Follow"


Question: How do I increase or decrease the size of my Amazon EBS volume?

I need to increase or decrease the size of my Amazon Elastic Block Store (Amazon EBS) volume. How to do this?

Answer: "I need to increase or decrease the size of my Amazon Elastic Block Store (Amazon EBS) volume. How to do this?ResolutionYou can only increase the size of your Amazon EBS volume. You can't decrease volume size. If you want to have a smaller volume size, first create a smaller volume. Then, migrate your data to it using an application-level tool.For more information, see the following Amazon EBS AWS Documentation:Requirements when modifying volumesRequest modifications to your EBS volumesTutorial: Increase the size of an Amazon EBS volume on an Amazon Elastic Compute Cloud (Amazon EC2) instanceIf you're using an AWS SDK to modify your volume, refer to the documentation that's specific to your AWS SDK.Follow"


Question: How do I set an agent's status to Offline automatically when they close the Amazon Connect CCP?

"When agents in my Amazon Connect contact center close the Contact Control Panel (CCP) window, I want their status automatically changed to Offline. How do I set that up?"

Answer: "When agents in my Amazon Connect contact center close the Contact Control Panel (CCP) window, I want their status automatically changed to Offline. How do I set that up?Short descriptionUse the Amazon Connect Streams API and the Agent API to integrate the CCP into a custom application for your contact center.For an example custom CCP setup, see How do I display caller contact attributes in an Amazon Connect screenpop?Note: When using the default Amazon Connect CCP, closing it doesn't change an agent's status from Available to Offline. Agents must change their status manually.ResolutionImportant: The following instructions provide basic examples and resources. You must determine how to implement the Streams API and develop the JavaScript client code for your own use case and contact center requirements.Set up your Amazon Connect instance's CCP in a custom web applicationFor instructions, see the Amazon Connect streams documentation on GitHub.Update your application codeIntegrate the following Streams API calls into your web application:1.    Use connect.agent() to subscribe to agent events and retrieve agent objects.let mAgent;connect.agent(function(agent) { mAgent = agent;});2.    Call agent.setState() in the onbeforeunload event handler to change the agent state.window.addEventListener("beforeunload", function(event) { if (mAgent != null) { let states = mAgent.getAgentStates(); // "states" is an array of changeable states. You can filter the desired state to change by name. let offlineState = states.filter(state => state.name === "Offline")[0]; // Change agent state mAgent.setState(offlineState, { success: function() { console.log("SetState succeeded"); }, failure: function() { console.log("SetState failed"); } }); }});Design for errorsIf an API call fails and a contact takes the error branch of your contact flow, then an agent's status might not change as expected. Make sure that you include logic in your custom code to account for this possibility.For example: You can delay the page unload while the API call is tried again. Or, you can enter a "Call failed" warning message in a modal dialog box before the page unload.Related informationAdd custom agent statusProvide access to the Contact Control PanelMonitor metrics and run reportsFollow"


Question: "What is considered a soft bounce on Amazon SES, and how can I monitor soft bounces?"

What is considered a soft bounce on Amazon Simple Email Service (Amazon SES)? What are the types of soft bounces? How can I monitor soft bounces on Amazon SES?

Answer: "What is considered a soft bounce on Amazon Simple Email Service (Amazon SES)? What are the types of soft bounces? How can I monitor soft bounces on Amazon SES?ResolutionA soft bounce or a transient bounce is a bounced email that's rejected by the recipient mail server because of a temporary failure. Temporary failures that can lead to a soft bounce include:The recipient mailbox is full.The recipient mailbox is temporarily unavailable.The server limits are exceeded.The server is overloaded.It's best practice to retry soft bounces, which are caused by temporary issues.Note: If you're using Simple Mail Transfer Protocol (SMTP) with Amazon SES, then the specific error codes related to soft bounces are 421, 450, 451, or 452. For the descriptions of these error codes, see Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry on the Internet Assigned Numbers Authority (IANA) website.Amazon SES categorizes soft bounces or transient bounces as these subtypes:General: The recipient's email provider sent a general transient bounce. This typically happens when the recipient has set up an "out of the office" automatic reply. This type of soft bounce generally fixes itself. If the bounce was a result of an "out of the office" reply, then the soft bounce resolves itself after the automatic reply is removed by the recipient.MailboxFull: The recipient mailbox is full and can't accept any more emails. You might be able to send emails to the same recipient later when their mailbox is no longer full.MessageTooLarge: The recipient mail server can't accept the email because the file size of the message is too large. You can try to resolve this type of bounce by reducing your message size.ContentRejected: The recipient mail server doesn't allow the content of the email. You can try to resolve this type of bounce by modifying the content of your email.AttachmentRejected: The email contains an unacceptable attachment. Some email providers block emails with attachments of a certain file type or large attachments. After you remove or modify your email attachments, you can try to send the email to this recipient again.For more detail on these soft bounce subtypes, see Bounce types.To monitor soft bounces on Amazon SES, you can set up notifications using Amazon Simple Notification Service (Amazon SNS). The SNS notifications are triggered whenever any type of bounce is received.To determine if the rejection is a soft bounce, review the content of the SNS notification. If bounceType is Transient, then it's a soft bounce. To determine the type of soft bounce, review the value for bounceSubType.Follow"


Question: How can I create Amazon Redshift Spectrum cross-account access to AWS Glue and Amazon S3?

I want to use Amazon Redshift Spectrum to access AWS Glue and Amazon Simple Storage Service (Amazon S3) in a different AWS account that's within the same AWS Region. How do I do that?

Answer: "I want to use Amazon Redshift Spectrum to access AWS Glue and Amazon Simple Storage Service (Amazon S3) in a different AWS account that's within the same AWS Region. How do I do that?Short descriptionTo access AWS resources that are in a different account from Amazon Redshift Spectrum, perform the following steps:1.    In Account 1, create an AWS Identity and Access Management (IAM) role with a trust relationship to Amazon Redshift. This role should be attached to the Amazon Redshift cluster.2.    In Account 2, create another role with access to both AWS Glue and Amazon S3. This role edits the trust relationship and allows the Amazon Redshift account to assume this role.3.    In Account 1, edit the permissions for the existing role so that it assumes the role created in the AWS Glue and Amazon S3 account.ResolutionAccount 1: Create an AWS Identity and Access Management (IAM) role with a trust relationship to Amazon Redshift1.    Open the IAM console.2.    Choose Roles from the navigation pane, and then choose Create role.3.    For Select type of trusted entity, choose AWS service.4.    Choose Redshift.5.    For Select your use case, choose Redshift - Customizable.6.    Choose Next: Permissions, Next: Tags, andthen Next: Review. You don't need to add policies or tags.7.    Enter a Role name, and then choose Create role. In the following examples, we'll refer to this role as redshift_role1.8.    Associate redshift_role1 with the Amazon Redshift cluster. This association allows your cluster to assume the newly created role to access Amazon S3, Amazon Athena, and AWS Glue.Account 2: Create another role with access to AWS Glue and Amazon S31.    Open the IAM console.2.    Choose Policies, and then choose Create policy.3.    Choose the JSON tab, and then enter an IAM policy similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": [        "glue:BatchCreatePartition",        "glue:UpdateDatabase",        "glue:CreateTable",        "glue:DeleteDatabase",        "glue:GetTables",        "glue:GetPartitions",        "glue:BatchDeletePartition",        "glue:UpdateTable",        "glue:BatchGetPartition",        "glue:DeleteTable",        "glue:GetDatabases",        "glue:GetTable",        "glue:GetDatabase",        "glue:GetPartition",        "glue:CreateDatabase",        "glue:BatchDeleteTable",        "glue:CreatePartition",        "glue:DeletePartition",        "glue:UpdatePartition"      ],      "Resource": "*"    },    {      "Sid": "VisualEditor1",      "Effect": "Allow",      "Action": [        "s3:GetObject",        "s3:ListBucketMultipartUploads",        "s3:ListBucket",        "s3:GetBucketLocation",        "s3:ListMultipartUploadParts"      ],      "Resource": [        "arn:aws:s3:::your_bucket",        "arn:aws:s3:::your_bucket/*"      ]    },    {      "Sid": "VisualEditor2",      "Effect": "Allow",      "Action": [        "kms:Decrypt"      ],      "Resource": [        "<KMS_KEY_ARN>"      ]    }  ]}Replace your_bucket with the name of the S3 bucket that you want to access with Amazon Redshift Spectrum. Replace KMS_KEY_ARN  with the ARN of the KMS key that encrypts your S3 bucket.Note: If the files in your S3 bucket are encrypted, be sure to grant the proper permissions to Amazon Redshift.4.    Choose Review policy.5.    Enter a Name for the policy, and then choose Create policy.6.    From the navigation pane, choose Roles, and then choose Create role.7.    For Select type of trusted entity, choose Another AWS account.8.    For Account ID, enter the ID of the account that is using Amazon Redshift. For more information, see Finding your AWS account ID.9.    Choose Next: Permissions.10.    In the list of policies, select the check box next to the name of the policy that you created.11.    Choose Next: Tags and then choose Next: Review. You don't need to add tags.12.    Enter a Role name, and then choose Create role. In the following examples, we'll refer to this as glue_s3_role2.13.    From the navigation pane, choose Roles.14.    Select the name of the role that you created, and then choose the Trust Relationships tab.15.    Choose Edit Trust Relationship.16.    Delete the existing policy and then replace it with a policy similar to the following. Replace redshift_account1 with the ID of the account that is using Amazon Redshift. Replace redshift_role1 with the name of the first role that you created.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::redshift_account1:role/redshift_role1"      },      "Action": "sts:AssumeRole"    }  ]}17.    Choose Update Trust Policy.Account 1: Edit the Permissions for the role created in Amazon Redshift1.    Open the IAM console.2.    Choose Roles from the navigation pane, and then choose the name of the first role (redshift_role1) that you created earlier.3.    From Permissions section, choose Add inline policy .4.    Choose the JSON tab. Delete the existing policy and then enter an IAM policy similar to the following. Replace glue_s3_account2 with the ID of the account that is using AWS Glue and Amazon S3. Replace glue_s3_role2 with the name of the second role that you created:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Stmt1487639602000",      "Effect": "Allow",      "Action": [        "sts:AssumeRole"      ],      "Resource": "arn:aws:iam::glue_s3_account2:role/glue_s3_role2"    }  ]}<br>5.    Choose Review policy.6.    Enter a name for the policy, and then choose Create policy.7.    Connect to the Amazon Redshift cluster.8.    Create an external schema using the roles that you created in both accounts, as shown in the following example:create external schema spectrum_schemafrom data catalogdatabase 'your_db'iam_role 'arn:aws:iam::redshift_account1:role/redshift_role1,arn:aws:iam::glue_s3_account2:role/glue_s3_role2'Replace these values:your_db: the name of your database in AWS Glue.redshift_account1: the ID of the Amazon Redshift account.redshift_role1: the name of the role that you created in the Amazon Redshift account.glue_s3_account2: the ID of the AWS Glue and Amazon S3 account.glue_s3_role2: the name of the role that you created in the AWS Glue and Amazon S3 account.You can now query AWS Glue tables in glue_s3_account2 using Amazon Redshift Spectrum from your Amazon Redshift cluster in redshift_account1, as long as all resources are in the same Region. You don't need to recreate your external tables because Redshift Spectrum can access your existing AWS Glue tables.The query in the following example returns the number of rows in an AWS Glue table created in the external schema:select count(*) from spectrum_schema.glue_table;Note: Replace spectrum_schema and glue_table with the name of your schema and AWS Glue table.Related informationChaining IAM roles in Amazon RedshiftIAM policies for Amazon Redshift SpectrumFollow"