Question: How do I prepare for maintenance on my Direct Connect connection?

"I received a notification that my AWS Direct Connect connection will be down temporarily for maintenance, and I want to prepare for this downtime."

Answer: "I received a notification that my AWS Direct Connect connection will be down temporarily for maintenance, and I want to prepare for this downtime.Short descriptionWhen a Direct Connect connection is down for maintenance, that connection can be down from a few minutes to a few hours. To prepare for this downtime, take one of the following actions:Request a redundant Direct Connect connection.Configure a virtual private network (VPN) connection as a backup.It's a best practice to shift your traffic to another circuit during Direct Connect maintenance. To prevent any production traffic disruption, use one of the preceding options before the scheduled maintenance period. You can also use the AWS Direct Connect Resiliency Toolkit to perform scheduled failover tests and verify the resiliency of your connections.ResolutionRequest a redundant Direct Connect connectionIf you request multiple connections to the same co-location site from the same AWS account, then AWS configures them on separate routers. Direct Connect performs maintenance on a single router at a time, so one connection stays up.If you request a redundant connection at a different co-location site, then you have a secondary connection when the first is down for maintenance. If an infrastructure event affects the entire co-location site, then you can use this second connection.For information on requesting a new Direct Connect connection, see Request an AWS Direct Connect dedicated connection.Configure a VPN connection as a backupFor a shorter-term or lower-cost solution, configure an AWS Site-to-Site VPN as a failover option for a Direct Connect connection. Because VPN connections generally offer less bandwidth than Direct Connect connections, be sure that your use case or application can tolerate a lower bandwidth.Related informationVPN connection as a backup to AWS DX connection exampleWhat is AWS Direct Connect?Connect your VPC to remote networks using AWS Virtual Private NetworkFollow"


Question: How do I migrate my Amazon Redshift cluster to an RA3 node type?

I want to migrate my Amazon Redshift cluster from an existing node to an RA3 node type. How can I upgrade my cluster configuration to the RA3 node type?

Answer: "I want to migrate my Amazon Redshift cluster from an existing node to an RA3 node type. How can I upgrade my cluster configuration to the RA3 node type?Short descriptionRA3 nodes allow you to optimize your data by scaling and paying for compute and managed storage. Based on your use case, you can migrate your existing Amazon Redshift cluster to the ra3.4xlarge or ra3.8xlarge node types. If you create an RA3 cluster, note that the minimum number for RA3 clusters is two nodes. For more information about RA3 node types, see Upgrading to RA3 node types.To migrate your cluster from an existing node type to RA3, use one of the following methods:Elastic resize: This is the most efficient way to change the instance type and update the nodes in your Amazon Redshift cluster. The cluster endpoint doesn't change and the downtime during resize is minimal.Snapshot and restore method: Choose the snapshot and restore method if elastic resize is unavailable (from a mismatch between slice and node count). Or, use this method to minimize the amount of time that it takes to write to your production database.Note: Data written to the source cluster after the snapshot is taken must be copied over manually to the target cluster afterwards.Classic resize: Choose the classic resize method if it's the only option available. For single node clusters, only a classic resize can be performed to convert the cluster into a multi-node cluster.Note: When you resize your Amazon Redshift cluster, you can schedule the resize. Use the create-scheduled-action command or CreateScheduledAction API to automate cluster resizing in Amazon Redshift.ResolutionElastic resizeWith Amazon Redshift elastic resize, you slice your cluster in half or double the node count. Amazon Redshift presents slice mapping options that are applicable to your configuration. Amazon Redshift does not consider data size during a resize.To check the available node migration options, choose the Nodes dropdown list in the AWS Management Console. If your current configuration supports elastic resize, then use elastic resize to upgrade your cluster with the RA3 node type. The minimum node count required to perform an elastic resize is two.Note: Some configuration changes don't allow an elastic resize. If elastic resize is unavailable as an option in your AWS Management Console, use the snapshot restore method.Before you perform an elastic resize, determine the possible node configurations for different node types using the following:The DescribeNodeConfigurationOptions API, which returns properties of possible node configurations such as node type, number of nodes, and disk usage for the specified action type.-or-The describe-node-configuration-options AWS Command Line Interface (AWS CLI) command, which returns possible node configurations. Node configuration settings include node type, number of nodes, and disk usage for the specified action type.Note: The AWS CLI doesn't offer node configuration options for slice mapping.For example:aws redshift describe-node-configuration-options --action-type resize-cluster --cluster-identifier your-redshift-clusteridentifierTo use elastic resize to change your cluster configuration in Amazon Redshift, perform the following steps:1.    Sign in to your AWS Management Console.2.    Open the Amazon Redshift console.3.    Choose Clusters.4.    Select your Amazon Redshift cluster.5.    Choose Actions.6.    Choose Resize.7.    Select Elastic Resize as your resize type.8.    Select the node that you want to migrate to for New cluster configuration.9.    Select the number of nodes based on node type.10.    Choose Resize cluster now to trigger the resize. When the resize completes, the status of your cluster changes from Available  to Modifying.Snapshot and restoreIf elastic resize is unavailable to you in your Amazon Redshift console, use the snapshot and restore method. You can use the DescribeNodeConfigurationOptions API or describe-node-configuration-options AWS CLI command to obtain the possible node configurations for different node types. Then, restore your cluster to the original configuration.For example:aws redshift describe-node-configuration-options --action-type restore-cluster --snapshot-identifier your-snapshot-identifierNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.To use the snapshot and restore method to change your cluster configuration, perform the following steps:1.    Sign in to your AWS Management Console.2.    Open the Amazon Redshift console.3.    Choose Clusters.4.    Choose Snapshots.5.    Select the most recent snapshot of the source cluster.6.    Choose Restore from Snapshot.7.    Select the node type.8.    Select the number of nodes.9.    (Optional) Under Additional Configuration, modify the database configurations and default configurations (such as your VPC, parameter group, monitoring, and backup).10.    Choose Restore cluster from snapshot.To retain the same endpoint as your source cluster, perform the following steps:Important: Before you begin, you must create an Amazon Redshift cluster.1.    Delete the old Amazon Redshift cluster.2.    Select the new cluster.3.    Choose the Actions dropdown menu.4.    Choose Modify.5.    Specify the same Cluster Identifier as your deleted cluster.6.    Choose Modify Cluster.You can also use the ModifyCluster API or modify-cluster AWS CLI command to rename your Amazon Redshift cluster. For more information, see Renaming clusters.Classic resizeIf elastic resize is unavailable to you in your Amazon Redshift console, use the classic resize method to update your node configurations. A classic resize depends on the amount of data and node count in your cluster. The resize can take anywhere from several hours to several days. It's a best practice to perform a classic resize if it is your only option for upgrading your node configuration.Note: In some cases (such as single node clusters), the classic resize is your only option to update your node configuration.To use a classic resize to change your node configuration, perform the following steps:1.    Sign in to your AWS Management Console.2.    Open the Amazon Redshift console.3.    Select the cluster that you want to modify.4.    Choose the Actions dropdown menu.5.    Choose Resize.6.    Choose Classic Resize.7.    Under New cluster configuration, select your preferred node type and nodes for migration.8.    Choose Resize cluster now to begin the classic resize. Your Amazon Redshift cluster remains in the read-only mode until the resize operation completes.Follow"


Question: How do I create and copy an Amazon Machine Image (AMI) from one AWS Region to another?

I want to launch a copy of my Amazon Elastic Cloud Compute (Amazon EC2) instance to serve clients in other geographical regions and to create redundancy in my application. How do I create an Amazon Machine Image (AMI) of my Amazon EC2 instance and then copy the AMI to another AWS Region?

Answer: "I want to launch a copy of my Amazon Elastic Cloud Compute (Amazon EC2) instance to serve clients in other geographical regions and to create redundancy in my application. How do I create an Amazon Machine Image (AMI) of my Amazon EC2 instance and then copy the AMI to another AWS Region?ResolutionTo create a copy of your AMI in another AWS Region, follow these steps:Create an AMI of your EC2 instance:To create a Linux AMI, see Create your own AMI.To create a Windows AMI, see Create a custom Windows AMI.Copy the AMI of your EC2 instance to another AWS Region:To copy a Linux AMI, see Copy an AMI.To copy a Windows AMI, see Copy an AMI.After the copy operation completes, launch a new EC2 instance from your AMI in the new AWS Region.Copying an encrypted AMIFor more information, see the following:Copy an AMI - Encryption and copying.Share encrypted AMIs across accounts to launch instances in a single step.How to share encrypted AMIs across accounts to launch encrypted EC2 instances.Linux error message "This AMI was copied from an AMI with a kernel that is unavailable in the destination region: {Image ID}"Linux paravirtual (PV) AMIs aren't supported in all AWS Regions. If you receive this message, you can create a new HVM instance, and then attach new EBS volumes to the HVM instance. Then, copy over data from the EBS volumes attached to the old PV instance. For more information, see Linux AMI virtualization types.Related informationBest practices for Amazon EC2How can I share an encrypted Amazon EBS volume with another AWS account?Amazon PV-GRUB Kernel Image IDsFollow"


Question: How do I automate the creation of AMIs based on my EBS-backed EC2 instance using Systems Manager Automation?

I want to automate the creation of Amazon Machine Images (AMIs) of Amazon Elastic Compute Cloud (Amazon EC2) instances that are backed by Amazon Elastic Block Store (EBS). How can I do this?

Answer: "I want to automate the creation of Amazon Machine Images (AMIs) of Amazon Elastic Compute Cloud (Amazon EC2) instances that are backed by Amazon Elastic Block Store (EBS). How can I do this?Short descriptionYou can use AWS Systems Manager to create a maintenance window, and then register an Automation task to automate the creation of the AMIs. This process is applicable for both Windows and Linux instances.The instance that you want to create an AMI for must be listed as a managed instance in Systems Manager. First, verify that the instance meets all prerequisites for using Systems Manager. If the instance uses a private subnet, you can create VPC endpoints for Systems Manager.Note: (Windows only) Sysprep isn't run on Windows instances before creating an AMI when you use the following automation process.ResolutionTo automate the creation of AMIs, follow these steps:Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent version of the AWS CLI.Create an AWS Identity and Access Management (IAM) role with permissions to create an AMI for the maintenance window. You can use the IAM console, AWS CLI, or Tools for Windows PowerShell.Create a maintenance window.On the Schedule section, for Specify with, choose Cron schedule builder.Assign targets to the maintenance window.Register an Automation task to create an AMI.For Actions, choose Register Automation task.For Automation document, choose AWS-CreateImage.For IAM service role, choose Use a custom service role, and then choose the IAM role that you created in step 1 of this article.On the Input parameters section, for InstanceId, enter the pseudo parameter placeholder {{TARGET_ID}} or {{RESOURCE_ID}}.Note: When entering the pseudo parameter placeholder, keep the following in mind:If the target type is RESOURCE_GROUP, the {{TARGET_ID}} parameter returns the full ARN of the resource. The {{RESOURCE_ID}} parameter returns a shorter name or ID of the resource.Examples{{TARGET_ID}} format: arn:aws:ec2:us-east-1:123456789012:instance/i-02573cafcfEXAMPLE{{RESOURCE_ID}} format: i-02573cafcfEXAMPLEIf the target type is INSTANCE, both the {{TARGET_ID}} and {{RESOURCE_ID}} parameters return the instance ID only.For more information on pseudo parameters, see About pseudo parameters.For a list of supported pseudo parameters, see Supported pseudo parameters.Related informationWorking with maintenance windows (console)Systems Manager maintenance windows tutorials (AWS CLI)Create a standardized Amazon Machine Image (AMI) using SysprepHow can I restrict access to launch Amazon EC2 instances from only tagged AMIs?Controlling access during AWS requestsFollow"


Question: How do I resolve "Net::OpenTimeout" errors in CodeDeploy?

"I want to launch a Windows Amazon Machine Image (AMI) instance in AWS CodeDeploy. However, I receive the following error in my AWS CodeDeploy agent log file: "CodeDeploy Instance Agent Service: error during start or run: Net::OpenTimeout - execution expired - C:/Windows/TEMP/ocrFxxx.tmp/lib/ruby/2.3.0/net/http.rb:880:in 'initialize'.""

Answer: "I want to launch a Windows Amazon Machine Image (AMI) instance in AWS CodeDeploy. However, I receive the following error in my AWS CodeDeploy agent log file: "CodeDeploy Instance Agent Service: error during start or run: Net::OpenTimeout - execution expired - C:/Windows/TEMP/ocrFxxx.tmp/lib/ruby/2.3.0/net/http.rb:880:in 'initialize'."Short descriptionFor AWS provided Windows Server 2016 AMI instances, EC2Launch statistically sets the metadata or AWS Key Management Service (AWS KMS) routes on the first boot. If you create a custom AMI from these instances, then the routes are captured as part of the OS configuration. Any new instances that you launch from the AMI retain the same routes, regardless of subnet placement.When launching from a custom AMI, these static routes don't update unless one of the following configurations is true:You use Sysprep for your custom AMI.You schedule the Amazon Elastic Compute Cloud (Amazon EC2) launch initialization tasks before you create the AMI.When launching from a custom AMI into a different Amazon Virtual Private Cloud (Amazon VPC), subnet, or CIDR block, the following issues occur:Configured routes are no longer valid.The instance can't reach the metadata service or the AWS KMS servers that are required for instance activation.Resolution1.    Create a custom AMI in Windows.2.    Use the custom AMI that you created in step 1 to launch a new instance.Important: If you're using Sysprep, then use Sysprep after launching your new instance.3.    Connect to your launched Windows instance.4.    Log in to Windows PowerShell as an administrator.5.    In PowerShell, navigate to C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts. Then, enter the following command:.\InitializeInstance.ps1 -Schedule6.    Press Enter.7.    Terminate the instance that you created in step 3. Then, create a new AMI from the instance that you terminated.8.    Use the new AMI to launch the instance in CodeDeploy.Follow"


Question: How do I troubleshoot “DeviceTokenNotForTopic” errors when publishing APNs push notifications through Amazon SNS or Amazon Pinpoint?

"My Apple Push Notification Service (APNs) mobile push notifications are failing to send through Amazon Simple Notification Service (Amazon SNS) or Amazon Pinpoint. When the push notifications fail, APNs returns a 400/410 status code with a "DeviceTokenNotForTopic" error message. Why am I receiving this error, and how do I resolve the issue?"

Answer: "My Apple Push Notification Service (APNs) mobile push notifications are failing to send through Amazon Simple Notification Service (Amazon SNS) or Amazon Pinpoint. When the push notifications fail, APNs returns a 400/410 status code with a "DeviceTokenNotForTopic" error message. Why am I receiving this error, and how do I resolve the issue?Short descriptionWhen creating an Amazon SNS platform application or configuring an Amazon Pinpoint APNs channel, a certificate/token linked to a specific bundle ID is required. Your application generates a device token with that bundle ID. When sending a message to a device endpoint, the APNs expects the same bundle ID for this device token.If the APNs picks up a device token with a different bundle ID, it returns a 400/410 status code and the following error: "DeviceTokenNotForTopic". When this error occurs, APNs deactivates the associated platform endpoint and displays a “disabled” status for this endpoint on SNS.For more information, see User notification process overview and Apple authentication methods in the Amazon SNS Developer Guide. Also, see Handling notification responses from APNs on the Apple Developer website.Note: You can set up mobile app event notifications when certain application events occur so you can take programmatic action on that event. For example, you can set up an event notification when a platform endpoint is deactivated.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 resolve the error when using Amazon SNS or Amazon Pinpoint to send push notifications to APNs1.    First check the bundle ID that's registered with APNs for your application.2.    Update the application's bundle ID to match the bundle ID that's registered with APNs and generate a new device token.3.    Then, update the platform endpoint with the newly generated device token.Check the bundle ID that's registered with APNs for your applicationCertificate-based authentication1.    Sign in to your Apple Developer account.2.    In the left navigation bar, choose Certificates, IDs & Profiles.3.    In the left navigation bar, choose Identifiers.4.    Choose your application.Note: To verify that your application is linked to a certificate, navigate to Certificates, and then view the bundle ID under Name.5.    Copy the bundle ID that's in the Name field. This is the bundle ID that's registered with APNs for your application.Token-based authenticationFor token-based authentication, you can map multiple bundle ID’s (applications) with a single token. To verify that you're using the correct bundle ID, confirm them on either your Apple Developer account or on your SNS console.1.    Sign in to your Apple Developer account.2.    In the left navigation bar, choose Certificates, IDs & Profiles.3.    In the left navigation bar, choose Identifiers. Then, App IDs.4.    Choose your application.5.    Copy the bundle ID that's in the Name field. This is the bundle ID that's registered with APNs for your application.6.    Sign in to your SNS Console.7.    Navigate to Push Notification under Mobile.8.    Choose your platform application.9.    Verify that the Apple Bundle ID is the correct bundle ID.To update the application's bundle ID to match the bundle ID that's registered with APNs1.    Download Xcode, if you haven't already.2.    Open Xcode.3.    Choose your application's root project folder.4.    Choose Signing & Capabilities.5.    In the Bundle Identifier text field, enter the bundle ID that's registered with APNs for your application. The new bundle ID is saved automatically.6.    Run your application to generate a new device token with the correct bundle ID.Update the platform endpointFor Amazon SNS1.    Run the set-endpoint-attributes AWS CLI command.2.    Change the Enabled attribute to true. Then, for Token, specify the newly-generated device token.For Amazon Pinpoint1.    Run the update-endpoint AWS CLI command.2.    For the Address attribute, specify the newly-generated device token.For more information, see Creating a platform endpoint in the Amazon SNS Developer Guide and Adding endpoints to Amazon Pinpoint.Related informationMobile push API errorsFollow"


Question: "How can I perform a failover in my Aurora global database, and why did my failover fail?"

I want to know how to perform failover in my Amazon Aurora PostgreSQL-Compatible Edition global database and the reasons why a failover failed.

Answer: "I want to know how to perform failover in my Amazon Aurora PostgreSQL-Compatible Edition global database and the reasons why a failover failed.ResolutionFor an Aurora global database, there are two different options for performing a failover:Manual unplanned failover ("detach and promote") - Use this option to recover from an unplanned outage or to do disaster recovery testing.Managed planned failover - Use this option for operational maintenance or other planned operational procedures.Manual unplanned failoverTo fail over to a secondary cluster after an unplanned outage in the primary AWS Region, first do the following:Stop issuing DML statements and other write operations to the primary Aurora DB cluster in the AWS Region with the outage.Identify an Aurora DB cluster from a secondary AWS Region to use as a new primary DB cluster. If you have two or more secondary AWS Regions in your Aurora global database, then choose the secondary cluster that has the least lag time.Remove your chosen secondary DB cluster from the Aurora global database.Then, to complete the manual unplanned failover, do the following:Reconfigure your application to send all write operations to the now standalone Aurora DB cluster using its new endpoint. If you accepted the provided names when creating the Aurora global database, then change the endpoint by removing the -ro from the cluster's endpoint string.For example, the secondary cluster's endpoint my-global.cluster-ro-aabb.us-west-1.rds.amazonaws.com becomes my-global.cluster-aabb.us-west-1.rds.amazonaws.com when that cluster is detached from the Aurora global database.The secondary Aurora DB cluster becomes the primary cluster of a new Aurora global database when you start adding Regions to it.Add an AWS Region to the DB cluster to start the replication process from primary to secondary cluster.Add more AWS Regions as needed to recreate the topology needed to support your application.For more information, see Recovering an Amazon Aurora global database from an unplanned outage.Managed planned failoverTo start a managed planned failover for your Aurora global database, do the following:Open the Amazon RDS console.Choose Databases, and find the Aurora global database you want to fail over.From the Actions menu, choose Fail over global database. The failover is now pending, and the process doesn't begin until after you choose the failover target.Choose the secondary Aurora DB cluster that you want to promote to primary. The secondary DB cluster must be available.Note: If you have more than one secondary DB cluster, then compare the lag amount for all secondaries. Then, choose the one with the smallest amount of lag.Choose Fail over global database to confirm your choice of secondary DB cluster, and begin the failover process.The Status column of the Databases list shows the state of each Aurora DB instance and Aurora DB cluster during the failover process.The status bar at the top of the console displays progress and provides a Cancel failover option.If you choose Cancel failover, then you're given the option to proceed with the failover or to cancel the failover process.Choose Close to continue failing over, and dismiss the prompt.After the failover completes, you can see the Aurora DB clusters and their current state in the Databases list. For more information, see Performing managed planned failovers for Amazon Aurora global databases.You can also use the AWS Command Line Interface (AWS CLI) to initiate a managed planned failover by running the failover-global-cluster command.Reasons for a failed failoverA failover might fail due to one of the following reasons:Replication lag between the source and targetAvailability Zone failuresCompute node failuresNetworking issues between DB instancesStorage issuesLarge Scale EventsRelated informationUsing failover in an Amazon Aurora global databaseFollow"


Question: How do I troubleshoot "Execution failed due to configuration error: Invalid endpoint address" errors from API Gateway?

"I'm seeing "Execution failed due to configuration error: Invalid endpoint address" errors in my Amazon CloudWatch execution logs for Amazon API Gateway. What's causing the error, and how do I fix it?"

Answer: "I'm seeing "Execution failed due to configuration error: Invalid endpoint address" errors in my Amazon CloudWatch execution logs for Amazon API Gateway. What's causing the error, and how do I fix it?Short descriptionWhen communicating with backend HTTP or HTTPS endpoints, API Gateway uses the domain configured in the Endpoint URL value of the method request. Before sending a request to the endpoint URL, API Gateway resolves the domain by performing a Domain Name Server (DNS) resolution. If API Gateway can't resolve the domain in the endpoint URL, then the following error appears in the CloudWatch execution logs:Execution failed due to configuration error: Invalid endpoint addressResolutionTo troubleshoot the error, do the following:1.    To confirm successful DNS resolution, run a name resolution command, such as dig or nslookup. If the DNS is resolved successfully, then the command response returns a valid, public IP address.Note: Use dig for Linux operating systems and nslookup for Windows operating systems, through the system's default command prompt.Example dig command:$ dig www.amazon.com; <<>> DiG 9.10.6 <<>> amazon.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13150;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;www.amazon.com.    IN    A;; ANSWER SECTION:www.amazon.com.        41    IN    A    54.239.17.6;; Query time: 1 msec;; SERVER: 10.3.9.10#53(10.3.9.10);; MSG SIZE rcvd: 48Example nslookup command:$ nslookup amazon.comServer: 10.3.9.10Address: 10.3.9.10#53Name: amazon.comAddress: 54.239.25.1922.    If the command returns a private IP address within your Amazon Virtual Private Cloud (Amazon VPC), then set up an API private integration.  Note: API Gateway private integrations allow clients outside of your Amazon VPC to access your HTTP and HTTPs resources.-or-If the command doesn't return a valid, public IP address, then contact your DNS provider. Ask them to confirm that the DNS mappings for the domain are set up correctly.Follow"


Question: How do I troubleshoot high latency on my ELB Classic Load Balancer?

I am experiencing high latency when connecting to web applications running on Amazon Elastic Compute Cloud (Amazon EC2) instances registered to a Classic Load Balancer. How do I troubleshoot the Elastic Load Balancing latency?

Answer: "I am experiencing high latency when connecting to web applications running on Amazon Elastic Compute Cloud (Amazon EC2) instances registered to a Classic Load Balancer. How do I troubleshoot the Elastic Load Balancing latency?Short descriptionHigh latency on a Classic Load Balancer occurs due to the following:Network connectivity issuesImproper configuration of the Classic Load BalancerHigh memory (RAM) utilization on backend instancesHigh CPU utilization on backend instancesImproper web server configuration on backend instancesProblems with web application dependencies running on backend instances, such as external databases or Amazon Simple Storage Service (Amazon S3) bucketsResolution1.    Troubleshoot network connectivity issues for your Classic Load Balancer.2.    Configure the Classic Load Balancer for your use case.3.    Determine which backend instances are experiencing high latency by checking the access logs for your Classic Load Balancer. Review backend_processing_time to find backend instances with latency issues.To verify that a backend instance's web application server is experiencing high latency, use curl to measure the first byte response. For example:[ec2-user@ip-192.0.2.0 ~]$ for X in `seq 6`; do curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" http://www.example.com/ -so /dev/null; doneHigh Latency sample output:HTTPCode=200 TotalTime=2.452HTTPCode=200 TotalTime=1.035Low latency sample output:HTTPCode=200 TotalTime=0.515HTTPCode=200 TotalTime=0.0134.    Check the Average statistic of the CloudWatch Latency metric for your Classic Load Balancer. If the value is high, there is a problem with backend instances or application dependency servers.5.    Check the Maximum statistic of the Latency metric. If the value meets or exceeds the idle timeout value, requests are timing out which results in HTTP 504 errors.6.    Check for patterns in the Latency metric. Metric spikes at regular intervals indicate performance problems with backend instances due to overhead from scheduled tasks.7.    Check the CloudWatch SurgeQueueLength metric for Elastic Load Balancing. If requests to the Classic Load Balancer exceed the maximum value (1024), requests are rejected and an HTTP 503 error is generated by the load balancer. The sum statistic of the SpilloverCount metric measures the total number of rejected requests. For more information, see How do I troubleshoot Classic Load Balancer capacity issues in Elastic Load Balancing?8.    Check for memory issues by checking the Apache processes on your backend instances.Example command:watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"Example output:Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no-headers | wc -1 && free –mApache Processes: 27          total     used     free     shared     buffers     cachedMem:      8204      7445     758      0          385         4567-/+ buffers/cache:  2402     5801Swap:     16383     189      161949.    Check the CloudWatch CPUUtilization metric of your backend instances. Look for high CPU utilization or spikes in CPU utilization. For high CPU utilization, consider upgrading your instances to a larger instance type.10.    Check the MaxClient setting for the web servers on your backend instances, which defines how many simultaneous requests the instance can serve. For instances with appropriate memory and CPU utilization experiencing high latency, consider increasing the MaxClient value.Compare the number of processes generated by Apache (httpd) with the MaxClient setting. If the number of Apache processes frequently reaches the MaxClient value, consider increasing the value.Example command:[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15Example output:<IfModule prefork.c>StartServers         10MinSpareServers      5MaxSpareServers      10ServerLimit          15MaxClients           15MaxRequestsPerChild  4000</IfModule>11.    Check for dependencies that cause latency issues on your backend instances. These include, but aren’t limited to: shared databases, external resources (such as S3 buckets), external resource connections such as network address translation (NAT) instances, remote web services, and proxy servers.Related informationMonitor your Classic Load BalancerFollow"


Question: How can I generate a log bundle for my Amazon EKS instances?

I'm troubleshooting an Amazon Elastic Kubernetes Service (Amazon EKS) instance. I need to collect all the relevant Amazon EKS logs associated with that instance.

Answer: "I'm troubleshooting an Amazon Elastic Kubernetes Service (Amazon EKS) instance. I need to collect all the relevant Amazon EKS logs associated with that instance.Short descriptionUse the AWSSupport-CollectEKSInstanceLogs automation document to collect your Amazon EKS logs.Important: For the automation to work, you must install and run the SSM Agent on your Amazon EKS instance.ResolutionNote: The following resolution works only for worker nodes in Amazon EKS for Linux.1.    Open the AWS Systems Manager console.2.    In the navigation pane, choose Automation.3.    Choose Execute automation.4.    On the Owned by Amazon tab, in the Automation document search box, enter EKSInstanceLogs. Then, select the AWSSupport-CollectEKSInstanceLogs document.5.    Choose Next.6.    On the Automation Inputs page, for EKSInstanceId, enter your target Amazon EKS instance ID.7.    Set the LogDestination and AutomationAssumeRole parameters.Note: The log bundle is uploaded to the Amazon Simple Storage Service (Amazon S3) bucket that's specified in the LogDestination field. If you didn't specify a bucket, then you can retrieve the log bundle from the instance. The log bundle is saved locally in the /var/log/ path.8.    Choose Execute automation.When you run the above automation document, note the following best practices and requirements:It's a best practice to attach the Amazon managed AmazonSSMManagedInstanceCore policy to the relevant AWS Identity and Access Management (IAM) role. This IAM role is for the Amazon Elastic Compute Cloud (Amazon EC2) instance that's targeted for automation.If you provide the S3 bucket name in the LogDestination field before the automation runs, then the instance profile can write to the bucket.To run the automation and send the command to the instance, you must have at least the ssm:ExecuteAutomation and ssm:SendCommand permissions.To read the automation output, you must have the ssm:GetAutomationExecution permission.Related informationConfigure instance permissions for Systems ManagerEKS Logs Collector (GitHub)Follow"


Question: I'm getting an error while using the password reset option in my Lightsail WordPress website's login page. How can I fix this?

"When using the Lost Password option on the login page of my Amazon Lightsail WordPress website, I receive the error: "The email could not be sent. Your site may not be correctly configured to send email". I also can't send emails from my WordPress website using PHP mailer. How do I fix these issues?"

Answer: "When using the Lost Password option on the login page of my Amazon Lightsail WordPress website, I receive the error: "The email could not be sent. Your site may not be correctly configured to send email". I also can't send emails from my WordPress website using PHP mailer. How do I fix these issues?Short descriptionThe PHP mail function uses the sendmail application to send emails. PHP mailer and the Forgot Password option, which depends on PHP mailer, won't work in the following scenarios:The sendmail application isn't installed in the instance.The sendmail binary location isn't correctly configured in the PHP configuration file.Resolution1.    Verify that sendmail is installed by running the following command. If you receive the error command not found after running the command, then sendmail isn't installed.sudo /usr/sbin/sendmail -q2.    If sendmail isn't installed, then install it by running the following command:OS distributions such as Debian and Ubuntusudo apt-get install sendmailOS distributions such as Amazon Linux 2 and CentOSsudo yum install sendmail3.    Run the following command to configure PHP to use sendmail. This command modifies the PHP configuration file /opt/bitnami/php/etc/php.ini.sudo sed -i.$(date +%F_%R) '/sendmail_path/c\sendmail_path = "env -i /usr/sbin/sendmail -t -i"' /opt/bitnami/php/etc/php.ini4.    Run the following command to restart PHP-FPM:sudo /opt/bitnami/ctlscript.sh restart php-fpm5.    Use the password reset option on the log in page to verify that it now works.Follow"


Question: How do I troubleshoot my Amazon EKS worker node that's going into NotReady status due to PLEG issues?

My Amazon Elastic Kubernetes Service (Amazon EKS) worker nodes go into NotReady or Unknown Status because the Pod Lifecycle Event Generator (PLEG) isn't healthy.

Answer: "My Amazon Elastic Kubernetes Service (Amazon EKS) worker nodes go into NotReady or Unknown Status because the Pod Lifecycle Event Generator (PLEG) isn't healthy.ResolutionWhen the worker nodes in your Amazon EKS cluster go into the NotReady or Unknown status, then workloads that are scheduled on that node are disrupted. To troubleshoot this issue, do the following:Get information on the worker node by running the following command:$ kubectl describe node node-nameIn the output, check the Conditions section to find the cause for the issue.Example:KubeletNotReady  PLEG is not healthy: pleg was last seen active xxThe most common reasons for PLEG being unhealthy are the following:Kubelet can't communicate with Docker daemon because the daemon is busy or dead. For example, the Docker daemon on your EKS worker node might be broken.An out of memory (OOM) or CPU utilization issue at instance level caused PLEG to become unhealthy.If the worker node has a large number of pods, the kubelet and Docker daemon might experience higher workloads, causing PLEG related errors. Higher workloads might also result if the liveness or readiness probes frequently.Check the kubelet logsYou can check the kubelet logs on the instance to identify why PLEG is unhealthy.1.    Use SSH to connect to the instance and run the following command:$ journalctl -u kubelet > kubelet.logIf you're using the Amazon EKS-optimized AMI and SSH isn't enabled, then you can connect using SSM. For more information, see Connect to your Linux instance using Session Manager.2.    Check for PLEG related events posted by kubelet in these logs:Example:28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"3.    Check the kubelet logs to see if there are any pods that are failing readiness and liveness probes. These log messages look similar to the following:"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"Use these logs to identify the pods that are failing. For the pods that are identified, check and make sure that the health probes are configured correctly.Monitor the worker node resource usageCheck if there is any instance level issue, such as a resource crunch due to OOM issues or high CPU utilization.Monitor the CPU Utilization metric for the underlying Amazon Elastic Compute Cloud (Amazon EC2) worker node. Check this metric to see if there are any sudden spikes or if the CPU utilization reaches 100%.Kubelet reports that the node is under pressure when the node meets hard or soft eviction thresholds irrespective of configured grace periods. You can check the node condition by running the following command:$ kubectl describe node <node_name>Check whether node condition is indicated as MemoryPressure in the output. In these cases, the instance might stall due to resource unavailability. This might result in the process becoming unresponsive.To mitigate issues due to resource crunch, it's a best practice to set CPU and memory utilization limits for your pods.When you specify a resource limit for your container, kubelet enforces these limits. The usage of the running container isn't allowed to exceed these limits. This prevents the pod from taking up more memory than needed, thereby preventing OOM issues. For more information, see Resource Management for pods and containers on the Kubernetes website.Also, consider using Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. For more information, see Amazon EKS and Kubernetes Container Insights metrics. You can use node_cpu_utilization and node_memory_utilization to monitor resource utilization at node level. You can also set alarms to get notified when a certain threshold is reached.Monitor the root Amazon EBS volume performancePLEG might be unhealthy due to disk issues in your Amazon Elastic Block Store (Amazon EBS) volume. In this case, the kubelet logs look similar to the following:fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2sThis happens when your applications that are using the pods on the instance perform intensive I/O operations against the disk.You can monitor the IOPS utilization and throughput of your Amazon EBS volume using the Amazon CloudWatch metrics for Amazon EBS.Use the following CloudWatch metrics to monitor the throughput and IOPS of an Amazon EBS volume:VolumeReadOpsVolumeWriteOpsVolumeReadBytesFor example, you can calculate the average IOPS in ops/s using the following formula:((VolumeReadOps) + (VolumeWriteOps)) / (Period)You can calculate the average throughput in bytes/s using the following formula:((VolumeReadBytes) + (VolumeWriteBytes)) / (Period)For more information, see How can I use CloudWatch metrics to calculate the average throughput and average number of IOPS my EBS volume is providing?To resolve this issue, consider increasing the disk size or changing the EBS volume type for achieving a better I/O throughput.Follow"


Question: How can I set up a custom domain name for my API Gateway API?

I want to use a custom domain name for my Amazon API Gateway API instead of the default base URL. How do I set that up?

Answer: "I want to use a custom domain name for my Amazon API Gateway API instead of the default base URL. How do I set that up?Short descriptionThere are two types of custom domain names that you can create for API Gateway APIs: Regional or (for REST APIs only) edge-optimized.Note: Custom domain names aren't supported for private APIs.To set up a custom domain name for your API Gateway API, do the following:Request or import an SSL/TLS certificate.Create the custom domain name for your REST API, HTTP API, or WebSocket API.Test the setup by calling your API using the new custom domain name.The following are some key differences between Regional and edge-optimized custom domain names.Target endpoint differencesRegional custom domain names use a Regional API endpoint.Edge-optimized custom domain names use an Amazon CloudFront distribution.SSL/TLS certificate differencesRegional custom domain names must use an SSL/TLS certificate that's in the same AWS Region as your API.Edge-optimized custom domain names must use a certificate that's in the following Region: US East (N. Virginia) (us-east-1).Custom domain name differencesRegional custom domain names can be shared by other Regional custom domain names that are in different AWS Regions.Edge-optimized custom domain names are unique and can't be associated with more than one CloudFront distribution.Domain name mapping differencesA Regional custom domain name for a WebSocket API can't be mapped to a REST API or HTTP API. However, a Regional custom domain can be associated with REST APIs and HTTP APIs.For REST APIs, both edge-optimized and Regional custom domain names can have mappings for edge-optimized API endpoints, Regional API endpoints, or both.For WebSocket APIs and HTTP APIs, TLS 1.2 is the only supported TLS version.ResolutionRequest or import an SSL/TLS certificateBefore creating a custom domain name for your API, you must do one of the following:Request an SSL/TLS certificate from AWS Certificate Manager (ACM).-or-Import an SSL/TLS certificate into ACM.Note: For more information, see Getting certificates ready in AWS Certificate Manager.When requesting or importing the certificate, keep in mind the following requirements:To pass domain validation checks, the certificate must include the custom domain name as an alternate domain name.Note: For more information about validation checks with CloudFront distributions (for edge-optimized custom domain names), see Continually Enhancing Domain Security on Amazon CloudFront. There are similar validation checks for Regional custom domain names.For an edge-optimized custom domain name, the ACM certificate must be in the following Region: US East (N. Virginia) (us-east-1).For a Regional custom domain name, the ACM certificate must be in the same Region as your API.Create the custom domain name for your REST API, HTTP API, or WebSocket APIFor REST APIs, follow the instructions in Setting up custom domain names for REST APIs.For HTTP APIs, follow the instructions in Setting up custom domain names for HTTP APIs.For WebSocket APIs, follow the instructions in Setting up custom domain names for WebSocket APIs.Route traffic to your API Gateway APIUse Amazon Route 53 to route traffic to your custom domain. This gives you more control over the resources that users can access when they visit your domain.Follow the instructions in Configuring Route 53 to route traffic to an API Gateway endpoint.When configuring Route 53, you must create either a public hosted zone or a private hosted zone. For internet-facing applications with resources that you want to make available to users, choose a public hosted zone. For more information, see Working with hosted zones.Route 53 uses records to determine where traffic is routed for your domain. Alias records provide easier DNS queries to AWS resources, while CNAME (non-alias) records can redirect DNS queries outside of AWS resources. For more information, see Choosing between alias and non-alias records.Test the setup by calling your API using the new custom domain name1.    Run a curl command on the domain name using the base path mapping that you specified when you created the custom domain name.Note: For more information about curl, see the curl project website.2.    Verify that the response to the custom domain name is the same response that you receive when you invoke the API stage URL.Related informationMigrating a custom domain name to a different API endpointRequesting a public certificateFollow"


Question: Why can't I generate an Amazon S3 Inventory Report?

"I configured the Amazon Simple Storage Service (Amazon S3) Inventory Report, but it's not being delivered and I'm getting an Access Denied error."

Answer: "I configured the Amazon Simple Storage Service (Amazon S3) Inventory Report, but it's not being delivered and I'm getting an Access Denied error.Short descriptionIf you created the Amazon S3 Inventory configuration, then you must have the correct bucket policies and permissions in place to avoid getting this error:Access denied Inventory export for 2021-02-19 failed because S3 doesn't have access to the destination bucket or KMS key. Ask the owner of the destination bucket or KMS key to grant the necessary access and then try again.To generate an Amazon S3 Inventory Report, the following requirements must be met:Your destination bucket must allow the source bucket to upload the Amazon S3 Inventory Report to the destination bucket.Your destination bucket must be in the same AWS Region as the source bucket (where you've set up the Amazon S3 Inventory).Your destination bucket policy must grant access to the AWS KMS key that's been used to encrypt the inventory report file.Note: It can take up to 48 hours to deliver the first inventory report.ResolutionAllow the source bucket to upload the Amazon S3 Inventory Report to the destination bucketTo generate and upload the inventory report to the destination bucket, your bucket policy must allow the source bucket to upload to the destination bucket.For example:{  "Version": "2012-10-17",  "Id": "S3PolicyId",  "Statement": [    {      "Sid":"InventoryAndAnalyticsExamplePolicy",      "Effect":"Allow",      "Principal": {"Service": "s3.amazonaws.com"},      "Action":"s3:PutObject",      "Resource":["arn:aws:s3:::destinationbucket/*"],      "Condition": {          "ArnLike": {              "aws:SourceArn": "arn:aws:s3:::sourcebucket"           },         "StringEquals": {             "aws:SourceAccount": "123456789012",             "s3:x-amz-acl": "bucket-owner-full-control"          }       }    }  ]}Review your destination bucket policy for any Deny statements. The bucket can't include any Deny statements that prevent Amazon S3 (s3.amazonaws.com) from performing a PutObject in the destination bucket. An explicit deny takes precedence over any Allow statements. Exclude the Amazon S3 service (s3.amazonaws.com) from every Deny statement that might affect a PutObject action.Here's an example of a bucket policy that denies access to Amazon S3 (s3.amazonaws.com) and only allows access to a specified IP range:{  "Version": "2012-10-17",  "Id": "S3PolicyId",  "Statement": [    {      "Sid": "IPAllow",      "Effect": "Deny",      "Principal": "*",      "Action": "s3:*",      "Resource": [       "arn:aws:s3:::destinationbucket",               "arn:aws:s3:::destinationbucket/*"      ],      "Condition": { "NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}      }    }  ]}To correct the previous bucket policy, update your policy like this:{"Version": "2012-10-17",  "Id": "S3PolicyId", "Statement": [    {      "Sid": "IPAllow",      "Action": "s3:*",      "Effect": "Deny",      "Resource": [        "arn:aws:s3:::destinationbucket",        "arn:aws:s3:::destinationbucket/*"      ],      "Condition": {        "NotIpAddress": {          "aws:SourceIp": "54.240.143.0/24"        },        "ArnNotLike": {          "aws:SourceArn": "arn:aws:s3:::sourcebucket"        }      },      "Principal": "*"    },    {      "Sid": "InventoryAndAnalyticsExamplePolicy",      "Action": [        "s3:PutObject"      ],      "Effect": "Allow",      "Resource": [        "arn:aws:s3:::destinationbucket/*"      ],      "Condition": {        "ArnLike": {          "aws:SourceArn": "arn:aws:s3:::sourcebucket"        },        "StringEquals": {          "aws:SourceAccount": "123456789012",          "s3:x-amz-acl": "bucket-owner-full-control"        }      },      "Principal": {        "AWS": [          "s3.amazonaws.com"        ]      }    }  ]}Confirm that your destination bucket is in the same AWS Region as the source bucket.To verify that your destination bucket is in the same AWS Region as your source bucket, do the following:1.    Sign in to the AWS Management Console.2.    Open the Amazon S3 console.3.    Review the AWS Region column in your bucket list to confirm that your destination bucket is in the same AWS Region as the source bucket. (The source bucket is where you set up the Amazon S3 Inventory.)4.    (Optional) If your source and destination bucket are in different Regions, then create or choose a new bucket. This is because the source bucket and destination bucket must be in the same AWS Region.Note: Amazon S3 creates buckets in specific Regions. After a bucket is created in a specific Region, any objects that belong to the bucket never leave that Region (unless they're explicitly transferred). For more information about using Amazon S3 buckets and AWS Regions, see Buckets overview.Grant access to the AWS KMS key that was used to encrypt the inventory report fileIf you encrypted your Amazon S3 bucket with an AWS KMS key, then make sure to give Amazon S3 access to your AWS KMS key.To grant permissions for encryption using your AWS KMS key, do the following:1.    Sign in to the AWS Management Console.Note: Make sure to sign in using the AWS account that owns the AWS KMS key.2.    Open the AWS KMS console.3.    In the left navigation pane, choose Customer managed keys.4.    Under Customer managed keys, select the AWS KMS key that you want to use to encrypt the inventory report file.5.    Under Key policy, choose Switch to policy view.6     To update the key policy, choose Edit.7.    Under Edit key policy, add the following key policy to the existing key policy.{    "Sid": "Allow Amazon S3 use of the KMS key",    "Effect": "Allow",    "Principal": {        "Service": "s3.amazonaws.com"    },    "Action": [        "kms:GenerateDataKey"    ],    "Resource": "*",    "Condition":{      "StringEquals":{         "aws:SourceAccount":"source-account-id"     },      "ArnLike":{        "aws:SourceARN": "arn:aws:s3:::source-bucket-name"     }   }}8.    Choose Save changes.Note: Check the Last export column under Inventory configurations in the Amazon S3 console. If this column is empty, then Amazon S3 received a 403 AccessDenied response from querying the inventory status of the destination bucket. An empty Last export column doesn't always indicate that the report wasn't delivered. It's possible that the inventory report was successfully delivered. In this case, you can find the inventory report in the specified path within the destination bucket.Review your server access logs and CloudTrail HistoryReview your server access logs. Check if any changes were made to your bucket policies when that your inventory report stopped being delivered. The Amazon S3 server access log format looks like the following:79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be awsexamplebucket1 [06/Feb/2019:00:00:38 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be 891CE47D2EXAMPLE REST.PUT.BUCKETPOLICY - "GET /awsexamplebucket1?logging HTTP/1.1" 200 - 242 - 11 - "-" "S3Console/0.4" - 9vKBE6vMhrNiWHZmb2L0mXOcqPGzQOI5XLnCtZNPxev+Hf+7tpT6sxDwDty4LHBUOZJG96N1234= SigV2 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader awsexamplebucket1.s3.us-west-1.amazonaws.com TLSV1.1Look for any of the following entries that indicate that changes were made to your bucket policy:REST.PUT.BUCKETPOLICYYou can also search for the PutBucketPolicy action in your AWS CloudTrail Event history to confirm if any recent changes were made. Note that CloudTrail Event history provides only a 90-day window. If the PutBucketPolicy action was performed more than 90 days ago, then you must query the CloudTrail logs directly in Amazon S3. For information about the Amazon S3 API calls that are captured by CloudTrail, see Amazon S3 information in CloudTrail on the AWS Docs GitHub website.Related informationEnabling CloudTrail event logging for S3 buckets and objectsGranting permissions for Amazon S3 Inventory and Amazon S3 analyticsHow can I copy all objects from one Amazon S3 bucket to another bucket?Follow"


Question: How do I create and troubleshoot topology aware volume provisioning that uses an EBS CSI driver in Amazon EKS?

I want to provision topology aware volumes in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that uses Amazon Elastic Block Store (Amazon EBS) components.

Answer: "I want to provision topology aware volumes in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that uses Amazon Elastic Block Store (Amazon EBS) components.Short descriptionTo configure and troubleshoot a cloud infrastructure topology in Amazon EKS that uses Amazon EBS components, complete the following steps:Check that the EBS CSI add-on is configured correctly.Configure the storage class with topology aware implementation.Create a pod and workload, and then test a topology aware scenario.Troubleshoot EBS CSI controller errors.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.Check that the EBS CSI add-on is configured correctlyNote: It's a best practice to use the EBS CSI provisioner ebs.csi.aws.com for EBS volume provisioning. Also, use the EBS CSI provisioner when implementing topology aware volumes instead of the in-tree Kubernetes provisioner kubernetes.io/aws-ebs.To check that the EBS CSI add-on is configured correctly, complete the following steps:1.    Check if the CSI driver is installed. If it isn't installed, then see Amazon EBS CSI driver to install the CSI driver.2.    Check that the AWS Identity and Access Management (IAM) role on the service account has the minimum EBS volume action permissions.Note: You must annotate the service account with the IAM roles for service accounts (IRSA). If you don't annotate the service account with IRSA, then the Amazon EBS CSI driver assumes the IAM role on the worker node by default. If the CSI driver defaults to the IAM role on the worker node, then configure the required IAM role permissions in the AWS Management Console.Configure the storage class with topology aware implementation1.    Run the following command to deploy the storage class. Edit the manifest as needed to your specific deployment requirements.kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yamlExample manifest:Note: Replace the attributes in the manifest with ones that are specific to your use case.apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: ebs-scprovisioner: ebs.csi.aws.comvolumeBindingMode: WaitForFirstConsumerparameters:  csi.storage.k8s.io/fstype: xfs  type: io1  iopsPerGB: "50"  encrypted: "true"allowedTopologies:- matchLabelExpressions:  - key: topology.ebs.csi.aws.com/zone    values:    - us-east-2cNote: For topology aware implementation, make sure that you configure the allowedTopologies option. Deleting this option causes the correct Availability Zone to be inferred and the Amazon EBS CSI controller to create a volume where the pod is scheduled.2.    Use one of the following options to create a pv-claim:(Option 1) Create a pv-claim that requests a volume with the profile type specified in the deployed storage class manifest:kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml(Option 2) Create a pv-claim that uses an available EBS volume specified in the persistent volume manifest. Make sure to modify the option storageClassname: to an empty string**, "",** and modify the nodeAffinity block as required.kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifestsNote: For option 1 or option 2, if nodes aren't available in the volume's Availability Zone, then the deployment fails. This is because the scheduler can't dynamically adjust to the topology restriction.Create a pod and workload and test a topology aware scenarioCreate a pod1.    Create a test pod that uses the previous pv-claim:kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yamlNote: When you use topology.ebs.csi.aws.com/zone in allowedTopologies within a storage class or persistent volume, the pod is placed in the Availability Zone that's specified in the configuration manifests. If there's no node available in that Availability Zone, then the pod gets stuck in the Pending state.2.    Run the following get and describe pod commands to check the status of the deployment:kubectl get pod,pvc,pvkubectl describe pod <EXAMPLE_POD_NAME>Note: Replace EXAMPLE_POD_NAME with your pod's name.Create a workload1.     Run the following command to create a statefulSet workload that uses the previous pv-claim:kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml2.    Run the following get and describe command to check the status of the statefulSet workload:kubectl get statefulset,pod,pvc,pvkubectl describe pod <EXAMPLE_POD_NAME>Note: The statefulSet controller creates some pv-claims to cater to the pods' volume request for volumes in AWS Regions us-east-2b and us-east-2c. StatefulSets on termination isn't guaranteed to clean up persistent volumes, which could cause volumes to not be re-provisioned for statefulSet pods that are rescheduled to another Availability Zone.Test a topology aware scenario(Optional) To test how node replacement in another Availability Zone is handled, simulate node reshuffling by scaling down the nodes in the specified AZ. Then, scale up new nodes in another AZ. When completed, see the Create a pod and Create a workload sections.Example output on simulated deployment issue:from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.To correct the stuck pod, scale up a node in the specified Availability Zone again to resolve the volume node affinity conflict error.Note: When scaling up a new node in the expected Availability Zone, the deployment can fail due to failed reconciler runs. For troubleshooting steps, see the following section, Troubleshoot EBS CSI controller errors.Troubleshoot EBS CSI controller errorsExample of an EBS CSI error where pod churn and node recycle were simulated:from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate1.    To isolate the issue, describe the pod, and review the error log entries in the event. In the preceding example error, the message shows that four of five nodes can't be scheduled due to node taints and topology or affinity configuration. Also, the last node running in the correct Availability Zone didn't find an available persistent volume to bind.2.    To isolate this issue, check the status of the pv-claim bind:kubectl describe persistentvolumeclaim <PVC_NAME>Note: The pv-claim statuses are waiting, bound, invalid, or not found. In the following example, the pv-claim is waiting for the driver to create a volume. As it waits, the pv-claim doesn't bind to a target node.`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  `waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`3.    Check the csi-provisioner container logs in the ebs-csi-controller pod:kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-systemThe following output is an example error event:Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not foundNote: If error events similar to the preceding message occur, then the pv-claim reconciler failed to find a selected target node annotation. Remove this annotation so that the pv-claim can successfully sync.4.    To remove the selected target node annotation, run the following command. Make sure to copy and save the output into the pv-claim manifest to remove the selected-node annotation.kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"If the proceeding troubleshooting steps don't resolve your issue, then gather the logs from the isolated container workload and contact AWS Support. You can also search for related issues on the GitHub repository.Follow"


Question: Why am I being charged for Amazon EC2 when all my instances were terminated?

"I terminated all my Amazon Elastic Compute Cloud (Amazon EC2) instances, but the Billing and Cost Management console still shows charges for EC2."

Answer: "I terminated all my Amazon Elastic Compute Cloud (Amazon EC2) instances, but the Billing and Cost Management console still shows charges for EC2.ResolutionCheck the following common causes:You incurred the charges earlier in the billing cycleIf you run an EC2 instance at the beginning of the month but you stop or terminate it later, then your bill includes charges for the time that the instance ran.You terminated your instances, but you still have EC2 resources provisioned to your accountThe Elastic Compute Cloud line item in your bill includes resources other than instances. EC2 instances are often used along with other EC2 resources, such as the following:Elastic IP addressesAmazon Elastic Block Store (Amazon EBS) volumesExpand the Elastic Compute Cloud line item in the Bills page to see your EC2 usage by resource. Then, open the Amazon EC2 console and terminate or delete any resources that you don't need.Stopped instances don't incur charges, but Elastic IP addresses or EBS volumes attached to those instances do.To disassociate an Elastic IP address from an instance, see Disassociate an Elastic IP address.For information on releasing an unattached Elastic IP address, see Release an Elastic IP address.To detach an EBS volume from an instance, see Detach an Amazon EBS volume from a Linux instance.To delete an EBS volume that you no longer need, see Delete an Amazon EBS volume.To delete an EBS snapshot that you no longer need, see Delete an Amazon EBS snapshot.You terminated your instances in one AWS Region, but you have instances running in another RegionTo check whether you have active EC2 instances in other Regions, do the following:1.    Open the Billing and Cost Management console.2.    Choose Bills in the navigation pane.3.    In the Bill details by service section, expand the Elastic Compute Cloud line item.4.    Check if you have active EC2 instances in other Regions.After you confirm the Regions where EC2 resources incur charges, do the following:1.    Open the Amazon EC2 console.2.    In the navigation bar, select the respective Region from the Region Selector.3.    Terminate or delete EC2 resources that you don't need.New instances have launched on your accountServices such as Amazon EC2 Auto Scaling and AWS Elastic Beanstalk can launch instances automatically based on how you configured them. If you created Spot Instance requests or Spot Fleet requests, then Spot Instances launch when a certain Spot bid price is met.Check the relevant service's documentation for more information on terminating these resources. If you're not sure which service or resource is launching instances on your account, then contact AWS Support for help.You purchased a Reserved InstanceReserved Instances are billed each month for each hour in a given month until the end of the Reserved Instance contract.If you no longer use an instance type, then modify any applicable Reserved Instances to sizes that suit your current use case. You can also sell your instance on the Amazon EC2 Reserved Instance Marketplace.If none of these scenarios apply to you, or you're not sure why you're being billed, then contact AWS Support.Related informationAmazon EC2 pricingViewing your billFollow"


Question: How can I resolve the "DBInstance xxxxxx failed to stabilize" error when I create an RDS DB instance from snapshots using AWS CloudFormation?

"When I try to create an AWS::RDS::DBInstance resource with AWS CloudFormation, I get the following error: "DBInstance xxxxxx failed to stabilize.""

Answer: "When I try to create an AWS::RDS::DBInstance resource with AWS CloudFormation, I get the following error: "DBInstance xxxxxx failed to stabilize."Short descriptionIf you create an Amazon Relational Database Service (Amazon RDS) DB instance (AWS::RDS::DBInstance) from an existing RDS DB snapshot using AWS CloudFormation, then you can receive an error due to the following reasons:The storage type in the DB snapshot doesn't match the storage type in the DB instance.Your DB snapshots contain invalid objects.Note: There are other possible causes of RDS DB instance stabilization issues. The steps in the following resolution apply only to issues where the RDS DB instance is created from snapshots in AWS CloudFormation.ResolutionMatch the storage types between your DB snapshot and DB instanceNote: 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.1.    Verify the storage type of the DB snapshot by using the Amazon RDS console or the describe-db-snapshots AWS CLI commands. For example:aws rds describe-db-snapshots --db-snapshot-identifier MyRDSSnapShot --region us-east-1{    "DBSnapshots": [        {            .......            "AllocatedStorage": 20,             "Status": "available",             "PercentProgress": 100,             "DBSnapshotArn": "arn:aws:rds:us-east-1:1234567890:snapshot:MyRDSSnapShot",             "EngineVersion": "12.1.0.2.v7",             "ProcessorFeatures": [],             "OptionGroupName": "default:oracle-ee-12-1",             "SnapshotCreateTime": "2019-03-16T17:43:41Z",             "AvailabilityZone": "us-east-1f",             "StorageType": "gp2",            .......        }    ]}Note: The StorageType value gp2 from the AWS CLI command maps to the value General Purpose (SSD) in the Amazon RDS console.2.    In the AWS::RDS::DBInstance resource definition of your AWS CloudFormation JSON or YAML template, set the value of StorageType to match the storage type of the snapshot. In this case, the storage type is set to gp2.JSON:{    "MySampleDB": {        "Type": "AWS::RDS::DBInstance",        "Properties": {            "DBInstanceClass": "db.t2.small",            "StorageType": "gp2",            "Engine": "postgres",            "EngineVersion": "9.5.12",            ........        }    }}YAML:MySampleDB:  Type: 'AWS::RDS::DBInstance'  Properties:    DBInstanceClass: db.t2.small    StorageType: gp2    Engine: postgres    EngineVersion: 9.5.12    ......Note: If the storage type isn't set, then AWS CloudFormation sets StorageType to standard by default, which might not match the storage type of the referenced snapshot. If the storage types don't match, then RDS could take longer to create the database because of the extra storage conversion process. Also, this mismatch could lead to timeout errors for larger databases. It's a best practice to explicitly define the storage type in the AWS::RDS::DBInstance resource. Also, consider setting the storage type to match the storage type of the snapshot.3.    Launch your AWS CloudFormation stack to create the DB instance.Verify that your DB snapshots don't have invalid objectsIf the DB snapshot that's used to create your DB instance has invalid objects, complete the following steps:1.    Identify and fix the invalid objects in your existing databases.For example, the following Oracle database query returns a list of invalid objects:select owner,object_name,object_type,status from dba_objects where status='INVALID'2.    Retake snapshots from your existing databases.Important: Retake the DB snapshots only after you fixed or removed all the invalid objects from your databases.3.    Launch your AWS CloudFormation stack to create the DB instance using the existing DB snapshot.Follow"


Question: I tried to delete my ACM certificate but received an error that it's in use with other AWS resources

"I want to delete an AWS Certificate Manager (ACM) certificate. However, I receive an error similar to "The certificate is in use (associated with other AWS resources) and cannot be deleted. Disassociate the certificate from each resource in the list and try again.""

Answer: "I want to delete an AWS Certificate Manager (ACM) certificate. However, I receive an error similar to "The certificate is in use (associated with other AWS resources) and cannot be deleted. Disassociate the certificate from each resource in the list and try again."Short descriptionDeploying an edge-optimized API endpoint creates an Amazon CloudFront distribution by Amazon API Gateway. Deploying a Regional API endpoint creates an Application Load Balancer by API Gateway. The CloudFront distribution or Application Load Balancer is owned by API Gateway, not your account. The ACM certificate provided to deploy API Gateway is associated with the CloudFront distribution or Application Load Balancer.Similarly, adding a custom domain to your Amazon Cognito user pool creates a CloudFront distribution. The CloudFront distribution is owned by the Amazon Cognito service, not by your account. The ACM certificate that's provided when you create the custom domain is associated with the CloudFront distribution.Defining a custom endpoint for your domain in Amazon OpenSearch Service creates an Application Load Balancer. The Application Load Balancer is owned by the OpenSearch Service, not by your account. The ACM certificate that's provided when you create the custom endpoint is associated with the Application Load Balancer.Note: You can check the resource that the ACM certificate is associated with by running the describe-certificate command with AWS Command Line Interface (AWS CLI).ResolutionRemove the association of the ACM certificate with the CloudFront distribution or Application Load Balancer. To do this, you must replace the ACM certificate associated with the custom domain, or delete the custom domain.Important:Before you begin, be sure that you have installed and configured the AWS CLI.If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.To remove the association of the ACM certificate, do one of the following:To replace the ACM certificate for API Gateway, see Rotate a certificate imported into ACM.To replace the ACM certificate for Amazon Cognito, see Changing the SSL certificate for your custom domain.To delete the custom domain name for API Gateway, run the AWS command delete-domain-name.To delete the custom domain name for Amazon Cognito, run the AWS command delete-user-pool-domain.To update the ACM certificate for Amazon ES, see Creating a custom endpoint for Amazon OpenSearch Service.Then, delete the ACM certificate.Related informationAPI Gateway problemsFollow"


Question: How can I configure my IPv6 subnet as a private subnet?

I want to set up my Amazon Virtual Private Cloud (Amazon VPC) and configure my IPv6 subnet to be a private subnet.

Answer: "I want to set up my Amazon Virtual Private Cloud (Amazon VPC) and configure my IPv6 subnet to be a private subnet.Short descriptionIPv4-only VPCs can use private subnets if there is no route to the internet gateway in the associated route table. IPv4-only private subnets can also use NAT gateways to allow access from private AWS resources to the internet.In an Amazon VPC where IPv6 is activated, all the addresses associated with the instance are global unicast addresses. Therefore, they don't require a NAT gateway.Note: Amazon VPCs don't support Elastic IP addresses for IPv6.ResolutionUse an egress-only internet gateway to allow your IPv6 address to access the internet, without internet resources initiating communication with your instance.1.    Create an egress-only internet gateway in your Amazon VPC.2.    Add a route to your route table that points all IPv6 traffic (::/0) or a specific range of IPv6 addresses to the egress-only internet gateway.After completing these steps, IPv6 traffic in the subnet that is associated with the route table is routed to the egress-only internet gateway.Related informationDNS64 and NAT64VPC that supports IPv6 addressingCreate a dual-stack VPC and subnets using the AWS CLIVPC with public and private subnets (NAT)Follow"


Question: How do I migrate my transit VPC to a transit gateway?

How do I migrate my Amazon Virtual Private Cloud (Amazon VPC) from a Transit VPC to a Transit Gateway.

Answer: "How do I migrate my Amazon Virtual Private Cloud (Amazon VPC) from a Transit VPC to a Transit Gateway.ResolutionCreate a transit gateway.Create the Amazon VPC attachments for the spoke VPCs. If the spoke VPCs:Are in different accounts, share the transit gateway to the second account. Then, create attachments in the second account.Are in different Regions, create a new transit gateway in the second Region. Then, create a peering attachment between the two transit gateways.Create transit gateway virtual private network (VPN) connections to the on-premises networks, if applicable.Note: After the VPN tunnels are UP, you can change the on-premises gateway to prefer the transit gateway VPN tunnels over the virtual gateway tunnels.Configure the transit gateway route tables.In the spoke VPC route tables, change the target from the virtual private gateway to the transit gateway. Be sure to modify the spoke VPC route tables only during a schedule maintenance window.After communication is established on the transit gateway, remove each of the spoke VPC tags individually. Then, delete any VPNs connected to on-premises networks, if applicable. These actions remove the VPN connection between the spoke VPC and the transit network VPC.Note: The default tag for the spoke VPCs is configured with key: transitvpc:spoke and  value: true.After all spokes are migrated to the transit gateway, delete the transit network VPC AWS CloudFormation stack.Follow"


Question: How do I resolve "HIVE_CURSOR_ERROR: Row is not a valid JSON Object - JSONException: Duplicate key" when reading files from AWS Config in Athena?

"When I use Amazon Athena to query AWS Config files, I get the following error: "Error: HIVE_CURSOR_ERROR: Row is not a valid JSON Object - JSONException: Duplicate key.""

Answer: "When I use Amazon Athena to query AWS Config files, I get the following error: "Error: HIVE_CURSOR_ERROR: Row is not a valid JSON Object - JSONException: Duplicate key."Short descriptionThis error commonly occurs during the following situations:AWS Config resources have multiple tags with the same name.Some of the tags are in uppercase and some are in lowercase.For example, the following record uses tc:Name and tc:name JSON keys:{  "fileVersion": "1.0",  "configSnapshotId": "35eced35-a13a-45b7-81e4-446e35616e70",  "configurationItems": [  {    "tags": { "tc:Name": "6", "tc:name": "abc6-38" }  },  {    "tags": { "tc:Name": "6", "tc:name": "abc6-38" }  },  {    "tags": { "tc:Name": "6" }  },   {    "tags": { "tc:name": "6" }  }  ]}ResolutionRun a CREATE TABLE statement similar to the below example. This statement creates an Athena table, sets case.insensitive to false, and maps column names to JSON keys that aren't identical to the column names. Before running this statement, note the following:In the LOCATION field, replace s3://awsexamplebucket/AWSLogs/ with the name of your Amazon Simple Storage Service (Amazon S3) bucket.Replace all mapping properties with your column names and JSON keys (for example, mapping.fileversion'='fileVersion').CREATE EXTERNAL TABLE aws_config_configuration_snapshot ( fileversion STRING, configsnapshotid STRING, configurationitems ARRAY < STRUCT <    configurationItemVersion : STRING,    configurationItemCaptureTime : STRING,    configurationStateId : BIGINT,    awsAccountId : STRING,    configurationItemStatus : STRING,    resourceType : STRING,    resourceId : STRING,    resourceName : STRING,    ARN : STRING,    awsRegion : STRING,    availabilityZone : STRING,    configurationStateMd5Hash : STRING,    configuration : STRING,    supplementaryConfiguration : MAP < STRING, STRING >,    tags: MAP < STRING, STRING >,    resourceCreationTime : STRING > >) PARTITIONED BY ( dt STRING , region STRING )ROW FORMAT SERDE  'org.openx.data.jsonserde.JsonSerDe' WITH SERDEPROPERTIES (   'case.insensitive'='false,  'mapping.fileversion'='fileVersion',  'mapping.configsnapshotid'='configSnapshotId',  'mapping.configurationitems'='configurationItems',  'mapping.configurationitemversion'='configurationItemVersion',  'mapping.configurationitemcapturetime'='configurationItemCaptureTime',  'mapping.configurationstateid'='configurationStateId',  'mapping.awsaccountid'='awsAccountId',  'mapping.configurationitemstatus'='configurationItemStatus',  'mapping.resourcetype'='resourceType',  'mapping.resourceid'='resourceId',  'mapping.resourcename'='resourceName',  'mapping.arn'='ARN',  'mapping.awsregion'='awsRegion',  'mapping.availabilityzone'='availabilityZone',  'mapping.configurationstatemd5hash'='configurationStateMd5Hash',  'mapping.supplementaryconfiguration'='supplementaryConfiguration',  'mapping.configurationstateid'='configurationStateId'  )  LOCATION 's3://awsexamplebucket/AWSLogs/';If you already have a table with partitions loaded, then you can add the new SerDe properties to the table. Use a statement similar to the following:ALTER TABLE aws_config_configuration_snapshot SET TBLPROPERTIES (  'case.insensitive'='false','mapping.fileversion'='fileVersion','mapping.configsnapshotid'='configSnapshotId','mapping.configurationitems'='configurationItems','mapping.configurationitemversion'='configurationItemVersion','mapping.configurationitemcapturetime'='configurationItemCaptureTime','mapping.configurationstateid'='configurationStateId','mapping.awsaccountid'='awsAccountId','mapping.configurationitemstatus'='configurationItemStatus','mapping.resourcetype'='resourceType','mapping.resourceid'='resourceId','mapping.resourcename'='resourceName','mapping.arn'='ARN','mapping.awsregion'='awsRegion','mapping.availabilityzone'='availabilityZone','mapping.configurationstatemd5hash'='configurationStateMd5Hash','mapping.supplementaryconfiguration'='supplementaryConfiguration','mapping.configurationstateid'='configurationStateId')When the table is ready, access the tags using configurationItem.tags['TAGNAME']. For example, to access the tc:Name tag, run the following query:SELECT configurationItem.tags['tc:Name']FROM your_tableCROSS JOIN unnest(configurationItems) AS t(configurationItem)WHERE configurationItem.tags['tc:Name'] IS NOT NULLRelated informationCreate tables in Amazon Athena from nested JSON and mappings using JSONSerDeWhy do I get errors when I try to read JSON data in Amazon Athena?Hive-JSON-Serde (Github)Follow"


Question: How do I troubleshoot WorkSpaces image creation issues?

"I tried to create an Amazon WorkSpaces image, but the task failed."

Answer: "I tried to create an Amazon WorkSpaces image, but the task failed.ResolutionNote:As of January, 14, 2020, images can't be created from public Windows 7 bundles.Image creation isn't supported on Windows 10 systems that are upgraded from one version of Windows 10 to a newer version of Windows 10. This includes the Windows 10 feature and version upgrades.Verify that the image checker was turned on without any failure before proceeding with image creation. See Run the Image Checker. If Image Checker fails, see the Tips for resolving issues detected by the Image Checker section.Review the following common causes and steps to troubleshoot WorkSpaces image creation issues.Limit reached for WorkSpace images in a RegionThere's a default limit of 40 WorkSpace images in each AWS Region. If you reached this limit, then new attempts to create an image fail. For information about how to request a limit increase, see Amazon WorkSpaces quotas.Encrypted WorkSpaceThe WorkSpace must not be encrypted. Image creation from an encrypted WorkSpace isn't supported.Windows WorkSpaces image validation failsFollow these troubleshooting steps, as applicable, to resolve the validation error:1.    Deactivate or uninstall any antivirus software or security agents that might prevent successful image creation.2.    If a WorkSpaces service (services.msc) uses a domain account, change the service account to one of the following according to the service requirements:Local SystemLocal ServiceNetwork Service3.    Keep your user profile size under 10 GB. Verify that only the user profile data that's required as part of the image is present on the WorkSpace.4.    Verify that C:\ has free space equal to at least the user profile size plus 2 GB. For example, if the user profile size is 10 GB, then C:\ must have at least 12 GB of free space.5.    The PowerShell execution policy in a WorkSpace must be set to allow RemoteSigned scripts. To verify the value, run the Get-ExecutionPolicy PowerShell command. If it's not set to Unrestricted or RemoteSigned, then run the Set-ExecutionPolicy –ExecutionPolicy RemoteSigned command to change the value of the execution policy. This setting lets you run scripts on WorkSpaces. Running scripts is required to create an image.6.    Verify that WorkSpaces is updated with the latest patches to prevent interruptions in the image creation process due to Windows updates. WorkSpaces image creation can fail if Windows updates are missing or if the WorkSpace isn't updated with the latest patches.7.    The WorkSpace that you're testing image creation with must not be assigned to a user within a Domain Guests group. To verify if there are any domain accounts, run the following command:Get-WmiObject -Class Win32_Service | Where-Object { $_.StartName -like "*$env:USERDOMAIN*" }8.    Determine if there's a pending reboot for Windows Update. The image creation process fails when a reboot is pending.9.    The following components are required in an image. Without these components, the WorkSpaces that you launch from the image won't function correctly:Windows PowerShell version 3.0 or laterRemote Desktop ServicesAWS PV driversWindows Remote Management (WinRM)Teradici PCoIP agents and driversSTXHD agents and driversAWS and WorkSpaces certificatesSkylight AgentLinux WorkSpaces image validation failsFollow these troubleshooting steps, as applicable, to resolve the validation error:1.    The status of the WorkSpace must be Available and its modification state must be None.2.    All applications to be included in the image must be installed outside of the user volume (the /home directory).3.    The root volume (/) must be less than 97% full.4.    The following components are required in an image. Without these components, the WorkSpaces that you launch from the image won't function correctly:Cloud-initTeradici PCoIP agents and driversSkylight AgentSmart card on Linux WorkSpacesTo use smart cards on Linux WorkSpaces with WorkSpaces Streaming Protocol (WSP) activated, see Use smart cards for authentication. This page provides information about the customizations that you must make to your Linux WorkSpace before creating your image.Copy profile failsFor Windows 10 WorkSpaces, any files from the user profile that are intended for the image must be manually copied to C:\users\default. This method can fail if:The profile path for any of the folders within the user profile is longer than 261 characters.Appropriate permissions aren't present on the profile folder. Make sure that full privileges are assigned on the profile folder for the system and all application packages.Some group policy objects (GPOs) restrict access to the RDP certificate thumbprint when requested by EC2Config or EC2Launch. In this case, move the WorkSpace to a new organizational unit (OU) with blocked inheritance and no policies applied. Then, create an image.A WorkSpace is newly createdA newly created WorkSpace takes approximately 20 minutes for that WorkSpace to move from the Pending state to the Available state. While the WorkSpace is pending, you can't create images. For a recently created WorkSpace, wait until it becomes available before attempting to create a custom image. If your WorkSpace is stuck in Pending, then see Why can't I create a new WorkSpace?Other troubleshooting stepsIf you still can't create an Amazon WorkSpaces image, then follow these troubleshooting steps:1.    If your WorkSpace has a firewall turned on, then verify that the firewall isn't blocking any necessary ports. Certain ports are required for downloading scripts that are used for image creation.2.    Reboot the WorkSpace to be sure that all AWS components are running updated versions.3.    Run the Test-WSMan command to verify that the WSMan service is started and configured for automatic startup.4.    Verify that the applications installed are Sysprep compatible.For more information and prerequisites for custom image creation, see Create a custom WorkSpaces image and bundle.Related informationHow do I create a WorkSpaces image?Administer your WorkSpacesFollow"


Question: How do I import DNS zone files to Route 53 and troubleshoot errors received while importing them?

I'm migrating my Domain Name System (DNS) from another service provider. I need to move all the records in an Amazon Route 53 hosted zone by importing a DNS zone file. How can I do this?

Answer: "I'm migrating my Domain Name System (DNS) from another service provider. I need to move all the records in an Amazon Route 53 hosted zone by importing a DNS zone file. How can I do this?Short descriptionBefore starting the import process, confirm the following in your DNS zone file to avoid errors during import:The zone file must be in an RFC-compliant format.The domain name of the records in the zone file must match the name of the hosted zone.Route 53 supports the $ORIGIN and $TTL keywords. If the zone file includes $GENERATE or $INCLUDE keywords, the import fails and Route 53 returns an error.When you import the zone file, Route 53 ignores the statement of authority (SOA) record. Any name server (NS) records in the zone file that have the same name as the hosted zone are also ignored.You can import a maximum of 1,000 records.If the hosted zone already contains records that appear in the zone file, the import process fails, and no records are created.Review the contents of the zone file to confirm that record names include or exclude a trailing dot, as appropriate.When the name of a record in the zone file includes a trailing dot (example.com.), the import process interprets the name as a fully qualified domain name (FQDN). In this case, a Route 53 record with that name is created.When the name of a record in the zone file doesn't include a trailing dot (www), the import process concatenates that name with the domain name in the zone file (example.com). In this case, a Route 53 record with the concatenated name (www.example.com) is created.Note: For canonical name (CNAME), mail exchanger (MX), pointer (PTR), and service (SRV) records, the trailing dot behavior also applies to the domain name that's included in the RDATA value. If you're using a zone file for example.com, and a CNAME record in the zone file (without a trailing dot) has an RDATA value of www.example.com (without a trailing dot), then the import process creates a Route 53 record with the name: support.example.com. This record routes traffic to www.example.com.example.com. Before you import your zone file, review RDATA values and update the values as applicable.ResolutionImport a DNS zone fileTo create records by importing a zone file:Open the Route 53 console.In the navigation pane, choose Hosted zones.On the Hosted zones page, choose Create hosted zone.Enter the name of your domain. (Optional) You can also enter a comment.Choose Create.Choose Import zone file.In the Import zone file pane, paste the contents of your zone file into the Zone file text box.Choose Import.Note: Depending on the amount of records in your zone file, it might take a few minutes for the records to be created.After the DNS records are created in the Route 53 hosted zone, you can proceed with the migration process. To complete the migration process, follow the steps in Making Amazon Route 53 the DNS service for an existing domain.Troubleshoot errors received while importing a DNS zone fileThe following examples provide troubleshooting steps for resolving common error messages that you might receive while importing DNS zone files."Expected exactly one of [AliasTarget, all of [TTL, and ResourceRecords], or TrafficPolicyInstanceId], but found none in Change with {DNS_Record}"Cause: There's no time to live (TTL) value specified in a DNS record of the zone file.Example zone file:$ORIGIN testdomain.com@ A 1.1.1.1www CNAME example.comExample error message:Invalid request: Expected exactly one of [AliasTarget, all of [TTL, and ResourceRecords], or TrafficPolicyInstanceId], but found none in Change with [Action=CREATE, Name=testdomain.com, Type=A, SetIdentifier=null]Solution: Either use the $TTL keyword to assign TTL to all the DNS records or specify a TTL value to individual records, as appropriate for your use case.$ORIGIN testdomain.com$TTL 60@ A 1.1.1.1www CNAME example.com-or-$ORIGIN testdomain.com@ 60 A 1.1.1.1www 60 CNAME example.com"The zone file contains too many values for a record with a type of {Record_Type}. 1 values were expected, but {n} values are specified. On line {m}."Cause: Multiple values were specified for a particular DNS record in line "m."Example 1 zone file:$ORIGIN testdomain.com$TTL 60@ TXT  "abc" "xyz"Example 1 error message:The zone file contains too many values for a record with a type of TXT. 1 values were expected, but 2 values are specified. On line 3. '@ TXT  "abc" "xyz"'Solution: Specify multiple TXT record values on separate lines. Be sure to use double quotes ("example value") around each value.$ORIGIN testdomain.com$TTL 60@ TXT "abc" @ TXT "xyz"Example 2 zone file:$ORIGIN testdomain.com$TTL 60@ A 1.1.1.1 2.2.2.2 3.3.3.3Example 2 error message:The zone file contains too many values for a record with a type of A. 1 values were expected, but 3 values are specified. On line 3. '@ A 1.1.1.1 2.2.2.2 3.3.3.3'Solution:$ORIGIN testdomain.com$TTL 60@ A 1.1.1.1 @ A 2.2.2.2@ A 3.3.3.3"CharacterStringTooLong (Value is too long) encountered with {Value}"Cause: The TXT value string contains more than 255 characters.Example zone file:$ORIGIN testdomain.com$TTL 60www TXT "spf1 +a +mx ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 ip4:4.4.4.4 ip4:5.5.5.5.5 ip4:6.6.6.6 ip4:7.7.7.7 ip4:8.8.8.8 ip4:9.9.9.9 ip4:10.10.10.10 ipv4:11.11.11.11 ip4:12.12.12.12 ip4:13.13.13.13 ip4:14.14.14.14 ip4:15.15.15.15.15 include:spf.abc.com include:_spf.xyz.com ~all"Example error message:[Invalid Resource Record: 'FATAL problem: CharacterStringTooLong (Value is too long) encountered with '"spf1 +a +mx ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 ip4:4.4.4.4 ip4:5.5.5.5.5 ip4:6.6.6.6 ip4:7.7.7.7 ip4:8.8.8.8 ip4:9.9.9.9 ip4:10.10.10.10 ipv4:11.11.11.11 ip4:12.12.12.12 ip4:13.13.13.13 ip4:14.14.14.14 ip4:15.15.15.15.15 include:spf.abc.com include:_spf.xyz.com ~all"'']Solution: Split TXT record strings with over 255 characters into multiple text strings within the same record. Be sure to use double quotes ("example value") around each value.$ORIGIN testdomain.com$TTL 60www TXT "spf1 +a +mx ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 ip4:4.4.4.4 ip4:5.5.5.5.5 ip4:6.6.6.6 ip4:7.7.7.7 ip4:8.8.8.8 ip4:9.9.9.9 ip4:10.10.10.10 ipv4:11.11.11.11""ip4:12.12.12.12 ip4:13.13.13.13 ip4:14.14.14.14 ip4:15.15.15.15.15 include:spf.abc.com include:_spf.xyz.com ~all"Note: The maximum length of a value in a TXT record is 4,000 characters."RRSet of type CNAME with DNS name example.com does not contain exactly one resource record"Cause: Multiple CNAME records were created for the same domain name.Note: Records imported to a hosted zone using this method are created with the Simple Routing policy. As a result, multiple CNAME records can't be specified in a single DNS record.Example zone file:$ORIGIN testdomain.com$TTL 60www CNAME abc.comwww CNAME xyz.comExample error message:Error occurred [RRSet of type CNAME with DNS name www.testdomain.com. is not permitted as it conflicts with other records with the same DNS name in zone testdomain.com., RRSet of type CNAME with DNS name www.testdomain.com. does not contain exactly one resource record.]Solution: Instead of using the Import option, create records separately with Weighted, Latency, Failover, or Geolocation routing policies, as appropriate for your use case.Follow"