Question: How can I share an encrypted Amazon Aurora snapshot with another account?

I have an Amazon Aurora DB cluster encrypted snapshot that's using the default AWS Key Management Service (AWS KMS) key. How can I share the encrypted snapshot with another AWS account?

Answer: "I have an Amazon Aurora DB cluster encrypted snapshot that's using the default AWS Key Management Service (AWS KMS) key. How can I share the encrypted snapshot with another AWS account?Short descriptionYou can't share a snapshot that's encrypted with the default AWS KMS key. You must create a custom AWS KMS key instead. To share an encrypted Aurora DB cluster snapshot:Create a custom AWS KMS key.Add the target account to the custom AWS KMS key.Create a copy of the DB cluster snapshot using the custom AWS KMS key. Then, share the newly copied snapshot with the target account.Copy the shared DB cluster snapshot from the target account.ResolutionCreate a custom AWS KMS keyLog in to the source account, and then go to the AWS KMS console in the same region as the DB cluster snapshot.Select Customer-managed keys from the navigation pane on the side.Choose Create key.Create a symmetric encryption AWS KMS key.In Key usage, select Encrypt and decrypt. For information about creating AWS KMS keys that generate and then verify MAC codes, see Creating HMAC AWS KMS keys.In Advanced options, select AWS KMS as the key material origin.Select Single-region key, and then select Next.Give your key an alias. It is a best practice also to give your key a description and a tag. Then, select Next.Choose the IAM users and roles that will be allowed to administer the AWS KMS key, and then select Next.Note: To prevent the IAM users and roles from deleting the AWS KMS key, in the Key deletion section, uncheck the Allow key administrators to delete this key check box.Select the IAM users and role that can use the AWS KMS key in cryptographic operations, and select Next.Note: You also can allow other AWS accounts to use the key for cryptographic operations. For more information, see Cryptographic operations.Select Finish to create the AWS KMS key.Give target account access to the custom AWS KMS key within the source accountLog in to the source account, and go to the AWS KMS console in the same Region as the DB cluster snapshot.Select Customer-managed keys from the navigation pane.Select your custom AWS KMS key.From the Other AWS accounts section, select Add another AWS account, and then enter the AWS account number of your target account. For more information see, Allowing users in other accounts to use an AWS KMS key.Copy and share the DB cluster snapshotOpen the Amazon RDS console  in the source account, and then select Snapshots from the navigation pane.Select the DB cluster snapshot you want to share. Select Actions, and then select Copy snapshot.Select the same AWS Region that your custom AWS KMS key is in, and then enter a name for the New DB Snapshot Identifier.In the Encryption section, select the custom AWS KMS key that you created.Select Copy Snapshot.Select the newly copied DB cluster snapshot, select Actions, and then select Share snapshot.In AWS account ID, enter the AWS account number of your target account, and then select Add.Select Save.Copy the shared DB cluster snapshotLog in to the target account, and then open the Amazon RDS console.Choose Snapshots from the navigation pane.From the Snapshots pane, select the Shared with Me tab.Select the DB cluster snapshot that was shared.Select Actions. Then, select Copy Snapshot to copy the DB cluster snapshot into the same AWS Region.The DB snapshot now has an AWS KMS key from the target account and can be used to launch the instance.Related informationSharing a DB cluster snapshotCreating asymmetric AWS KMS keysMulti-Region keys in AWS KMSCopying a DB cluster snapshotSharing a snapshotFollow"


Question: How do I use a software license that I own on AWS hardware?

"I own a software license, and I want to use it on AWS hardware."

Answer: "I own a software license, and I want to use it on AWS hardware.ResolutionAlthough AWS can’t provide licensing advice, we offer tools to help you use your licensed software on AWS infrastructure.Because some software licenses specify the types of hardware, lengths of time, or number of machines they can be run on, you might consider running your software on instances in a Dedicated Host.Dedicated Hosts are a way to provision an entire physical server for your own use, which can help you meet the requirements of some software licenses. Dedicated Hosts also support host recording using AWS Config, which can help with license reporting. For more information, see Bring your own license.If your software is a Microsoft product, see License Mobility for more information on how to use Microsoft software on AWS infrastructure.Your software might also be listed in the AWS Marketplace, and some software providers offer a "Bring Your Own License" (BYOL) version of their software, ready to launch on AWS infrastructure. For more information, see AWS Marketplace Buyers Guide.Related informationAmazon EC2 Dedicated HostsFollow"


Question: How can I capture information about a deadlock on my Amazon RDS DB instance running SQL Server?

I have an Amazon Relational Database Service (Amazon RDS) DB instance that runs Microsoft SQL Server. I want to get more details about a deadlock on my RDS DB instance.

Answer: "I have an Amazon Relational Database Service (Amazon RDS) DB instance that runs Microsoft SQL Server. I want to get more details about a deadlock on my RDS DB instance.ResolutionA deadlock is encountered when two or more sessions, each with a resource locked, attempt to access the other session’s locked resource. The result is a "circular chain". When this happens, none of the sessions will continue to run until:One of the sessions releases its locks.Which allows the other session to access the locked resource.SQL Server's deadlock detector resolves this situation by ending one of the sessions using a resource-based or cost-based mechanism. Then, the detector rolls back any modifications related to this session. After one of the sessions is ended, the locks held by the session are released, and the other session is allowed to continue. For more information, see Microsoft documentation for Deadlocks.You can capture information about a deadlock event on your DB instance using one of the following ways.Activate trace flagsYou can activate the deadlock trace flags (1204,1222). Trace flags are used to customize SQL Server behaviors, such as additional monitoring by capturing deadlock information in the SQL Server error logs.Trace flag 1204 provides deadlock information about each of the nodes involved in the deadlock.Trace flag 1222 provides more detailed deadlock information than trace flag 1204 in XML format.You can activate both trace flags to get two different representations for each deadlock event. To set this up, see How can I receive a notification when a deadlock event occurs on my Amazon RDS SQL Server DB instance? After the trace flags are activated, you can review the SQL Server error logs for more information on the deadlock event.Use the system_health sessionExtended events is a lightweight performance monitoring system that helps you to collect data to monitor and troubleshoot problems in SQL Server. The system_health extended events session is included in SQL Server and activated by default. The session starts automatically when your SQL Server database engine starts and collects basic server health information. You can use this information to troubleshoot performance issues and monitor deadlocks within your database engine.The system_health extended event session uses two targets, event file and ring buffer, to store the data.By default, the size of each individual file is 5 MB and the number of maximum rollover files is four. This adds up to 20 MB of system_health extended event data. For SQL Server 2016, 2017, and 2019, the size of individual files is 100 MB and the maximum number of files is increased to 10. This adds up to 1 GB of data.The ring buffer is a special data structure in the memory that stores data on a first-in-first-out (FIFO) basis. The target memory of the ring buffer can’t exceed 4 MB in Amazon RDS for SQL Server. Therefore, on a busy instance, the system_health session might rotate events.Use the system_health session to retrieve information about a deadlock on your DB instance with either Microsoft SQL Server Management Studio (SSMS) or Transact-SQL (T-SQL).Do the following to retrieve deadlock information using SSMS:Open SSMS.On Object Explorer, choose Management, and then choose Extended Events.Choose Sessions.Find system_health session, and then choose (double-click) package0.event_file to open the extended event file.After the file contents have loaded, on the SSMS menu, choose Extended Events.Choose Filters.In the Filter window, do the following:For Field, select name.For Operator, select Contains.For Value, select deadlock.Choose OK. You can view the events with deadlocks.Choose the event that you want to view, and then choose the Deadlock tab to view the graph.-or-Do the following to retrieve deadlock information using T-SQL:1.    Run a query similar to the following to view the list of deadlocks:SELECT XEvent.query('(event/data/value/deadlock)[1]') AS DeadlockGraphFROM (    SELECT XEvent.query('.') AS XEvent    FROM (        SELECT CAST(target_data AS XML) AS TargetData        FROM sys.dm_xe_session_targets st        INNER JOIN sys.dm_xe_sessions s         ON s.address = st.event_session_address        WHERE s.NAME = 'system_health'        AND st.target_name = 'ring_buffer'        ) AS DataCROSS APPLY TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(XEvent)) AS source;2.    Choose the deadlock XML output to open the XML file in a new window.3.    Save the XML using the .xdl file extension. This converts the XML into a graphical format.4.    Navigate to the file location, and then open the .xdl file in SSMS to view the deadlock graph.You can run the T-SQL query to retrieve deadlock information from ring_buffer. The ring_buffer target holds event data in memory. This information is available only as long as the instance isn't rebooted. When you reboot, this information is purged.Use an xml_deadlock_report extended events sessionYou can create an extended event session by selecting the xml_deadlock_report event to capture deadlocks. Selecting an event file as the target saves the events to the file. This file can be analyzed in the future. To create an extended event session, you can use either SSMS or T-SQL. After the session is created, you can retrieve information about a deadlock on your DB instance. You can do this using either SSMS or T-SQL.Do the following to create an extended event session using SSMS:Open SSMS.On Object Explorer, Choose Management, and then choose Extended Events.Choose (right-click) Sessions, and then choose New Session Wizard.For Session name, enter the name of your session, and then choose Next.On the Choose Template page, select Do not use a template.Choose Next to open the New Session Wizard page.From Event library, select xml_deadlock_report, and then choose Next.In the Capture Global Fields page, select values that are common to all events.Note: Select sql_text field to see the query that caused the deadlock.Choose Next.In the Set Session Event Filters page, create event filters to limit the data that you want to capture.Choose Next.In the Specify Session Data Storage page, select Save data to a file for later analysis and Work with only the most recent data.Choose Finish.You can now see your new session in the Sessions folder in SSMS. Choose (right-click) the session, and then choose Start session.-or-Run a query similar to the following to create an extended event session using T-SQL:CREATE EVENT SESSION [Deadlock_detection] ON SERVER ADD EVENT sqlserver.xml_deadlock_reportADD TARGET package0.event_file(SET filename=N'D:\rdsdbdata\Log\Deadlock',max_file_size=(100))WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)GO     -- Start the event session  ALTER EVENT SESSION Deadlock_detection ON SERVER  STATE = start;  GODo the following to retrieve the deadlock information using SSMS:Open SSMS.On Object Explorer, Choose Management, and then choose Extended Events.Choose Sessions.Find the extended event session that you created earlier, and then choose (double-click) package0.event_file to open the extended event file.After the file contents have loaded, choose the event that you want to view, and then choose the Deadlock tab to view the graph.-or-Run a query similar to the following in T-SQL to view the list of deadlocks:SELECT * FROM sys.fn_xe_file_target_read_file('d:\rdsdbdata\log\deadlock*.xel', null, null, null)Related informationMicrosoft documentation for Deadlock information toolsFollow"


Question: Why can’t clients connect to my ELB load balancer?

"Clients can’t connect to my Application Load Balancer, Classic Load Balancer, or Network Load Balancer. How do I troubleshoot why clients can't connect to my Elastic Load Balancing (ELB) load balancer?"

Answer: "Clients can’t connect to my Application Load Balancer, Classic Load Balancer, or Network Load Balancer. How do I troubleshoot why clients can't connect to my Elastic Load Balancing (ELB) load balancer?Short descriptionCommon causes of load balancer connectivity issues include:No listener is configured for the load balancer port where clients are trying to connect.The load balancer security group doesn’t allow traffic for the listener.The target security group doesn’t allow traffic for the target port and load balancer health check port.The network access control list (network ACL) for a load balancer in an Amazon Virtual Private Cloud (Amazon VPC) doesn’t allow the necessary traffic.Route table rules are blocking or improperly routed requests.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 your port listenerVerify that you've configured the appropriate listeners for your load balancer port:Listeners for your Application Load BalancersListeners for your Classic Load BalancerListeners for your Network Load BalancersCheck the security group for your target instancesCheck the settings of the security group for the instances behind your load balancer. For each subnet that is attached to your load balancer, confirm that traffic is allowed in both directions for the listener and health check ports:Security groups for your Application Load BalancerConfigure security groups for your Classic Load BalancerRegister targets with your target group (Network Load Balancer)Check your network ACLs (for load balancers in a VPC)Confirm that the network ACLs for your VPC allow traffic in both directions on the listener port and health check port for each subnet attached to your VPC:Custom network ACLsNetwork ACLs for load balancers in a VPC (Classic Load Balancers)Check your route tablesConfirm that the route tables for the attached subnets of your load balancer allow load balancer connections using a default route that points to an internet gateway.To verify connectivity to your load balancer from an Amazon Elastic Compute Cloud (Amazon EC2) instance:1.    Connect to your Amazon EC2 instance (see steps for Linux instances or Windows instances).2.    Verify that either netcat (nc) or telnet is installed on your instance.3.    If you have a public load balancer, verify that your instance has internet connectivity. To confirm internet connectivity, use an internet gateway or network address translation (NAT) gateway.4.    Verify that your Amazon EC2 instance security group allows outbound connections to the internet. Then, confirm that the network ACL attached to the subnet where your instance is running allows inbound and outbound traffic.5.    Run one of the following commands, based on your configuration:nc –v elb.ip.address porttelnet elb.ip.address port6.    Review the output. Verify that the route table rules designate an internet gateway to the subnet for your load balancer.Note: If connectivity testing returns an HTTP 503 or HTTP 504 error, see:The load balancer generates an HTTP error (Application Load Balancers)Troubleshoot a Classic Load Balancer: HTTP errors7.    From an external client, run the traceroute (Linux clients) or tracert (Windows clients) utility to your load balancer listener's IP address.8.    Review the output.Note: If you receive other error codes from a Classic Load Balancer or Application Load Balancer, see:Troubleshoot your Application Load BalancersTroubleshoot your Classic Load BalancerCheck for load or capacity issuesSporadic connectivity issues might indicate load- or capacity-related issues. For troubleshooting steps, see How do I troubleshoot Classic Load Balancer capacity issues in ELB?Related informationHow Elastic Load Balancing worksFollow"


Question: How do I use AWS WAF to block specific file extension uploads?

I want to restrict file uploads (HTTP POST requests) with specific extensions to my web server.

Answer: "I want to restrict file uploads (HTTP POST requests) with specific extensions to my web server.Short descriptionWhen you analyze the POST data of an HTTP request, uploaded content can be one of two types:Form dataBinaryNote: AWS WAF inspects the first 8 KB (8,192 bytes) of the request body. This is a hard service limit that you can't change.To restrict file uploads that use a specific file extension, such as .pdf, .docx, or .exe, complete the following steps:1.    Create a custom web access control list (web ACL) rule to inspect the request BODY.2.    Create a regex match condition within the rule. Use this regex pattern to configure the rule to restrict multiple file extensions.3.    Set the rule action to BLOCK.4.    Define the rule priority so that this custom rule has a higher priority than any web ACL rule that can block this rule.5.    Validate that the rule successfully blocks the specific file extension.ResolutionIdentify the type of content that the POST data usesThe POST data inside HTTP requests typically uses either form data or binary.Form data includes any data that a user enters on a web page (or “HTML form”) that HTTP sends (or “posts”) to a web server.A binary payload is anything other than a text payload. For example, a binary payload can be a .jpeg file, a .gzip file, or an .xml file. This includes generic binary data such as from a .pdf application, .jpeg image, or .zip application. For all file extension types, see Media types on the Internet Assigned Numbers Authority (IANA) website.To identify the type of POST request, see the Content-Type value of the HTTP POST header. The following example contains a Content-Type of multipart/form-data:Content-Type: multipart/form-dataIf the header "Content-Type" has a value of "multipart/form-data" then complete the following steps to create a rule:1.    Open the AWS WAF console.2.    In the navigation pane, under AWS WAF, choose Web ACLs.3.    For Region, choose the AWS Region where you created your web ACL.Note: If you set up your web ACL for Amazon CloudFront, then select Global.4.    Select your Web ACL. Then, choose the Rules tab.5.    Choose the Add Rules dropdown list, and then choose Add my own rules and rule groups.6.    For the Rule type, choose Rule Builder.7.    For Name, enter a name to identify this rule.8.    For Type, choose Regular rule.9.    For If a request, choose matches the statement. Then, complete the following fields for the Statement:For Inspect, choose Body.For Content type, choose JSON.For JSON match scope, choose Values.For How AWS WAF should handle the request if the JSON in the request body is invalid, choose the relevant option for your use case.For Content to inspect, choose Full JSON content.For Match type, choose Matches regular expression.For Regular expression, enter a regex-pattern to match. See the following example:(?:.pdf|.doc|.docx|.ppt)10.    (Optional) For Text transformation, you can add a text transformation, or keep these fields as None.11.    For Oversize Handling, choose the relevant option for your use case.12.    For Action, choose Block.13.    Choose Add Rule.14.    (Optional) For Set Rule Priority, select your rule and move its priority. AWS WAF processes the rules in the order that they appear. For more information, see Processing order of rules and rule groups in a web ACL.15.    Choose Save.Validate that the rule works as expected.If the header "Content-Type" has a binary value such as "application/pdf" or "application/ppt" then complete the following steps to create a rule:1.    Open the AWS WAF console.2.    In the navigation pane, under AWS WAF, choose Web ACLs.3.    For Region, choose the AWS Region where you created your web ACL.Note: If you set up your web ACL for Amazon CloudFront, then select Global.4.    Select your Web ACL. Then, choose the Rules tab.5.    Choose the Add Rules dropdown list, and then choose Add my own rules and rule groups.6.    For the Rule type, choose Rule Builder.7.    For Name, enter a name to identify this rule.8.    For Type, choose Regular rule.9.    For If a request, choose matches the statement. Then, complete the following fields for the Statement:For Inspect, choose Single header.For Header field name, enter Content-Type.For Match type, choose Matches regular expression.For Regular expression, enter a regex-pattern to match. See the following example for .pdf and .jpeg files:(?:pdf|jpeg)   10.    (Optional) For Text transformation, you can add a text transformation, or keep these fields as None.11.    For Action, choose Block.12.    Choose Add Rule.13.    (Optional) For Set Rule Priority, select your rule and move its priority. AWS WAF processes the rules in the order that they appear. For more information, see Processing order of rules and rule groups in a web ACL.14.    Choose Save.Validate that the rule works as expected.Note: To restrict the rule for a specific upload URI path, use an AND statement inside the web ACL rule that inspects the path.Follow"


Question: How do I troubleshoot an upgrade fail with my Amazon EKS cluster?

My Amazon Elastic Kubernetes Service (Amazon EKS) cluster fails to update. How do I resolve this?

Answer: "My Amazon Elastic Kubernetes Service (Amazon EKS) cluster fails to update. How do I resolve this?Short descriptionTo resolve a failed Amazon EKS cluster update, try the following:For an IpNotAvailable error, verify that the subnet that's associated with your cluster has enough available IP addresses.For a SubnetNotFound error, verify that the subnets exist and are correctly tagged.For a SecurityGroupNotFound error, verify that the security groups that are associated with the cluster exist.For an EniLimitReached error, increase the elastic network interface quota for the AWS account.For an AccessDenied error, verify that you have the correct permissions.For an OperationNotPermitted error, verify that the Amazon EKS service role has the correct permissions.For a VpcIdNotFound error, verify that the VPC that's associated with the cluster exists.Verify that the resources that you used to create the cluster were deleted.For clusters created with eksctl, verify that the AWS CloudFormation stack failed to roll back.For a ResourceInUseException error, wait for some time before you retry the update.For transient backend workflow issues, update the cluster again.ResolutionVerify that the subnets have available IP addresses (IpNotAvailable)To update an Amazon EKS cluster, you must have five available IP addresses from each of the subnets. If you don't have enough available IP addresses, then you can delete unused network interfaces within the cluster subnets. Deleting a network interface releases the IP address. For more information, see Delete a network interface.To check for available IP addresses in the Amazon EKS cluster subnets:1.    Open the Amazon EKS console in the Region where you created your cluster.2.    Select Clusters from the sidebar. Then, select your Amazon EKS cluster.3.    Choose the Configuration tab.4.    Choose the Networking tab.5.    Under Subnets, select a subnet to open the Subnets page.6.    Select a subnet and choose the Details tab.7.    Locate the Available IPv4 addresses to see how many available IP addresses the subnet has.From the AWS Command Line Interface, run the following commands:1.    Get the subnets that are associated with the cluster:$ aws eks describe-cluster --name cluster-name --region your-regionNote: Replace cluster-name with your cluster's name and your-region with your AWS Region.Output:...   "subnetIds": [                "subnet-6782e71e",                "subnet-e7e761ac"            ],   ...2.    Describe the subnets from the preceding output:aws ec2 describe-subnets --subnet-ids subet-id --region your-regionNote: Replace subnet-id with your subnet's ID and your-region with your Region.Output:..."AvailableIpAddressCount": 4089,...If you don't have enough available IP addresses, then you can set the environment variable in the aws-node daemonset to WARM_IP_TARGET. This defines how many secondary IP addresses that the Container Network Interface (CNI) must reserve for pods:$ kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=numberNote: Replace number with the number of IP addresses that you want to reserve from the subnets.You can also use the variable MINIMUM_IP_TARGET to control the minimum number of IP addresses per node.It's a best practice to use these configuration variables to control how many network interfaces and IP addresses are maintained.Verify that the subnets exist and are correctly tagged (SubnetNotFound)To verify that your subnets exist, run the following command:aws ec2 describe-subnets --subnet-ids subet-id --region regionNote: Replace subnet-id with your subnet's ID and region with the Region where the subnets are located.If the subnets don't exist, then you receive the following error:An error occurred (InvalidSubnetID.NotFound) when calling the DescribeSubnets operation: The subnet ID 'subnet-id' does not existTo verify that the subnets are correctly tagged:1.    Identify the subnets that are associated with the cluster using the steps in the Check if you have enough available IP addresses (IpNotAvailable) section.2.    Open the VPC console.3.    Select Subnets from the sidebar.4.    Select the subnets that should be associated with the cluster and choose the Tags tab in the Details pane.5.    Verify that each subnet has the correct tags:Key - kubernetes.io/cluster/cluster-nameNote: The preceding tag is added to only Amazon EKS cluster versions 1.18 or earlier. For clusters created with Kubernetes version 1.19 and later, the tag is not mandatory. Replace cluster-name with your cluster's name.The value of the tag can be either shared or owned.If you have a Support plan, then contact the Support team to update your Amazon EKS subnets.Verify that the security groups that are associated with the cluster exist (SecurityGroupNotFound)To identify the security groups that are associated with the cluster:1.    Open the Amazon EKS console in the Region where you created your cluster.2.    Select the cluster.3.    Choose the Configuration tab.4.    Choose the Networking tab.5.    Select the security groups that are listed under Cluster security group and Additional security groups.If the security group exists, then the console opens and displays the security group details.From the AWS CLI:1.    Get the security groups associated with the cluster:$ aws eks describe-cluster --name cluster-name --region your-regionNote: Replace cluster-name with your cluster's name and your-region with your Region.Output:..."securityGroupIds": [    "sg-xxxxxxxx"]...2.    Describe the security group from the preceding output:$ aws ec2 describe-security-groups --group-ids security-group-id --region your-regionNote: Replace security-group-id with your security group's ID and your-region with your Region.Increase the elastic network interface quota for the AWS account (EniLimitReached)If you reached your network interface quota, then you can remove unused network interfaces or request a limit increase .If your network interfaces are attached to a cluster, then delete the cluster to remove the network interface. If your network interfaces are attached to unused worker nodes, then delete the Auto Scaling group for self-managed node groups. For managed node groups, delete the node group from the Amazon EKS console. To move workloads from one node group to another node group, see Migrating to a new node group.Verify that you have the correct permissions (AccessDenied)1.    Open the IAM console.2.    On the navigation pane, choose Roles or Users.3.    Select the role or user.4.    Verify that the IAM role or user has the correct permissions.Verify that the service role has the correct permissions (OperationNotPermitted)1.    Open the IAM console.2.    On the navigation pane, choose Roles.3.    Filter for AWSServiceRoleForAmazonEKS and select the role.4.    Verify that the role has the AmazonEKSServiceRolePolicy policy attached.If the policy isn't attached, see Adding IAM identity permissions.Verify that the VPC associated with the cluster exists (VpcNotFound)1.    Open the Amazon EKS console in the Region where you created your cluster.2.    Select the cluster.3.    Choose the Configuration tab.4.    Choose the Networking tab.5.    Select the VPC ID link to see if the VPC exists.If the VPC doesn't exist, you must create a new cluster.Verify that resources associated with the cluster were deletedIf you created the cluster on the Amazon EKS console and the subnets used to create the cluster were deleted, then the cluster can't update. You must recreate the cluster and move the workloads from the old cluster to the new one. If you have a support plan, then contact the support team to update your Amazon EKS subnets.Verify that the AWS CloudFormation stack failed to roll back (eksctl)If the CloudFormation stack failed to roll back, then see How can I get my CloudFormation stack to update if it's stuck in the UPDATE_ROLLBACK_FAILED state?Wait for some time before you initiate the control plane update again (ResourceInUseException)This error occurs if an automated Amazon EKS control plane action, such as a platform version update, is in progress when you initiate an update. Amazon EKS automatically detects and replaces unhealthy control plane instances, and it provides automated version upgrades and patching for them. Wait some time for the automated action to finish before you initiate the control plane update again.Note: Your wait time depends on when the automated update started. If you're not sure when the automated action will resolve, then wait an hour before you retry the control plane update.Update the cluster againTransient issues can cause the backend workflows to be unstable. If the preceding troubleshooting steps don't relate to your issue, then try to update the cluster again.Follow"


Question: How do I use my own security group for my load balancer when I deploy an AWS Elastic Beanstalk application?

"I want to create a load-balanced, auto-scaling environment type for my AWS Elastic Beanstalk application. I also want to specify my own security group for my load balancer."

Answer: "I want to create a load-balanced, auto-scaling environment type for my AWS Elastic Beanstalk application. I also want to specify my own security group for my load balancer.Short descriptionElastic Beanstalk creates a default security group for your load balancer. You can override this default behavior if you have an existing security group (also called a ManagedSecurityGroup) that you want to attach to your load balancer. To prevent Elastic Beanstalk from creating a default security group, you must add one or more configuration files to a .ebextensions directory. The directory is in your application deployment package.Important: The following steps apply only to Application Load Balancers and Classic Load Balancers. Network Load Balancers don't have an associated security group.ResolutionUse .ebextensions to instruct the Elastic Beanstalk service to attach an existing security group to your load balancer. Then, remove the default security group that Elastic Beanstalk creates for you.1.    Confirm that you have an existing security group for Elastic Beanstalk to use. Or, create a new security group for the load balancer in your Elastic Beanstalk environment.2.    Note the ID of your security group. For example: sg-1234563.    Create a .ebextensions/ directory in your local application code directory.Note: For more information, see Advanced environment customization with configuration files (.ebextensions).4.    In the .ebextensions/ directory, create a file named elbsg.config. For example:~/workspace/my-app/├── .ebextensions│   ├── elbsg.config├── helloworldNote: For more information, see Advanced environment customization with configuration files (.ebextensions).5.    Update the elbsg.config file based on the load balancer type of your Elastic Beanstalk environment.To create a new environment or update an existing environment with a Classic Load Balancer, use the SecurityGroups setting to override the default security group. For example:option_settings: aws:elb:loadbalancer:  ManagedSecurityGroup: "sg-123456"  SecurityGroups: "sg-123456"To create a new environment or update an existing environment with an Application Load Balancer, use the SecurityGroups setting to override the default security group. For example:option_settings: aws:elbv2:loadbalancer:  ManagedSecurityGroup: "sg-123456"  SecurityGroups: "sg-123456"Note: In the preceding examples, replace sg-123456 with your security group and managed security group. The preceding .ebextensions are in YAML format. Be sure to validate the YAML formatting.6.    Deploy your code and the new .ebextensions/ directory together as a new application version in your Elastic Beanstalk environment.After deployment, your security group is attached to the load balancer. Your environment and load balancer are now using your existing security group instead of the default load balancer security group.Related informationConfiguring Elastic Beanstalk environmentsaws:elb:loadbalanceraws:elbv2:loadbalancerFollow"


Question: How can I upgrade my standard Amazon Linux 2 kernel version 4.14.x to Amazon Linux Extras kernel versions?

"I want to upgrade my standard Amazon Linux 2 kernel version 4.14.x to the Amazon Linux Extra version 5.4.x. Or, I want to upgrade my Amazon Linux Extra kernel version 5.4.x to version 5.10.x."

Answer: "I want to upgrade my standard Amazon Linux 2 kernel version 4.14.x to the Amazon Linux Extra version 5.4.x. Or, I want to upgrade my Amazon Linux Extra kernel version 5.4.x to version 5.10.x.Short descriptionThe default kernel installed on Amazon Linux 2 instances is 4.14.x. You can upgrade the default kernel to an Amazon Linux Extras kernel version 5.4.x. Or, if you have kernel version 5.4.x installed, you can upgrade to version 5.10.x.Note: You can upgrade directly from Amazon Linux 2 kernel version 4.14.x to 5.10.x without having to upgrade to 5.4.x first.ResolutionUpgrade the Amazon Linux 2 default kernel from 4.14.x to Amazon Linux Extras kernel 5.4.x1.    Review the current active kernel version. In the following example, the current kernel version running on the system is 4.14.268-205.500.[ec2-user@kernel-upgrade ~]$ uname -r4.14.268-205.500.amzn2.x86_642.    Verify what kernel versions are offered by the amazon-linux-extras repository:[ec2-user@kernel-upgrade ~]$ sudo amazon-linux-extras |grep kernel35 kernel-ng available [ =stable ]49 kernel-5.4 available [ =stable ]55 kernel-5.10 available [ =stable ]This output lists the three kernel options available from the Amazon Linux Extra repository:kernel-ngkernel-5.4kernel-5.103.    Use the amazon-linux-extras tool to install the kernel 5.4:sudo amazon-linux-extras install kernel-5.4 -y4.    After the installation completes, verify that the state has changed in amazon-linux-extras:[ec2-user@kernel-upgrade ~]$ sudo amazon-linux-extras |grep kernel35 kernel-ng available [ =stable ]49 kernel-5.4=latest enabled [ =stable ]_ kernel-5.10 available [ =stable]Note the line that shows that the state has changed from available to enabled:49 kernel-5.4=latest enabled [ =stable ]5.    Verify the installed kernels from the RPM database:[ec2-user@kernel-upgrade ~]$ rpm -qa |grep kernelkernel-tools-4.14.268-205.500.amzn2.x86_64kernel-4.14.268-205.500.amzn2.x86_64kernel-5.4.181-99.354.amzn2.x86_64There are now two different kernel versions available: kernel-4.14.268-205.500 and kernel-5.4.181-99.354.The following example shows that the old kernel is still active:[ec2-user@kernel-upgrade ~]$ uname -r4.14.268-205.500.amzn2.x86_647.    To activate the latest kernel version, reboot the instance:[ec2-user@kernel-upgrade ~]$ sudo reboot8.    Log in to the instance again, and then verify that the new kernel is active:[ec2-user@kernel-upgrade ~]$ uname -r5.4.181-99.354.amzn2.x86_64Upgrade the Amazon Linux 2 (Amazon Linux Extras) kernel from 5.4.x to 5.10.x1.    Review the kernel active:[ec2-user@kernel-upgrade ~]$ uname -r5.4.181-99.354.amzn2.x86_642.    Use the amazon-linux-extras tool to verify the available kernel versions:[ec2-user@kernel-upgrade ~]$ sudo amazon-linux-extras |grep kernel35 kernel-ng available [ =stable ]49 kernel-5.4=latest enabled [ =stable ]_ kernel-5.10 available [ =stable ]In this example, kernel-5.4 is enabled.3.    Use the amazon-linux-extras tool to deactivate kernel 5.4:[ec2-user@kernel-upgrade ~]$ sudo amazon-linux-extras disable kernel-5.4Note: If you don't deactivate kernel 5.4, then you receive the following error when trying to install kernel 5.10:"Refusing because kernel-5.10 could cause an invalid combination."4.    Use the amazon-linux-extras tool to install kernel 5.10:[ec2-user@kernel-upgrade ~]$ sudo amazon-linux-extras install kernel-5.10 -y5.    Verify the installed kernels from the RPM database:[ec2-user@kernel-upgrade ~]$ rpm -qa |grep kernelkernel-tools-4.14.268-205.500.amzn2.x86_64kernel-4.14.268-205.500.amzn2.x86_64kernel-5.4.181-99.354.amzn2.x86_64kernel-5.10.102-99.473.amzn2.x86_64 <- kernel 5.10.x has been installed6.    After verifying that the correct kernel is installed, reboot the instance to activate the latest kernel:[ec2-user@kernel-upgrade ~]$ uname -r5.4.181-99.354.amzn2.x86_64 [ec2-user@kernel-upgrade ~]$ sudo reboot7.    Log in and then confirm that the kernel is activated:[ec2-user@kernel-upgrade ~]$ uname -r5.10.102-99.473.amzn2.x86_64Note: Upgrading the Amazon Linux 2 kernel from 5.10.x to Amazon Linux Extras 5.15.x follows the same steps that are detailed earlier.Follow"


Question: How do I change the time zone for an Amazon Aurora DB cluster?

"I have an Amazon Aurora DB cluster, and I want to change the time zone. How can I do this?"

Answer: "I have an Amazon Aurora DB cluster, and I want to change the time zone. How can I do this?Short descriptionIn Amazon Aurora, the time_zone parameter is a cluster level parameter. The parameter group provides a default time zone for the cluster. This is the default for all databases. The default value of time_zone is UTC, and after you change the value of time_zone, your change is applied to all the nodes in the cluster.Note: The default_time_zone parameter refers to server time zone. You can't modify this parameter.Important: There is a difference between DB cluster parameter groups and DB instance parameter groups.A DB parameter group acts as a container for engine configuration values that are applied to one or more DB instances. DB parameter groups apply to DB instances in both Amazon Relational Database Service (Amazon RDS) and Amazon Aurora. These configuration settings apply to properties that can vary between the DB instances in an Aurora DB cluster, such as the sizes for memory buffers.A DB cluster parameter group acts as a container for engine configuration values that are applied to every DB instance in an Aurora DB cluster. For example, the Aurora shared storage model requires that every DB instance in an Aurora cluster use the same setting for parameters, such as innodb_file_per_table. So parameters that affect the physical storage layout are part of the DB cluster parameter group. The DB cluster parameter group also includes default values for all the DB instance-level parameters.ResolutionThis example changes the time_zone parameter to ASIA/CALCUTTA using Amazon Aurora MySQL-Compatible Edition 5.7.1.    Create a custom DB cluster parameter group. For more information, see Working with parameter groups.2.    Modify the dynamic parameter time_zone="ASIA/CALCUTTA".3.    Attach the new DB cluster parameter group that you created to the cluster, and then manually reboot the DB cluster to apply the changes.4.    Check the timestamp of your DB instance by running the select @@time_zone command:mysql> select @@time_zone;+---------------+| @@time_zone   |+---------------+| Asia/Calcutta |+---------------+1 row in set (0.00 sec)Note: When you set the time zone at session level, this overrides both the database and parameter time zone. But, this is maintained only for the session. When you run the SET time_zone = 'Europe/Helsinki'; command, this sets the time zone for all the databases to Europe/Helsinki. The new time zone takes precedence over the parameter group time zone. A time zone set at database level overrides the parameter group time zone. A session time zone overrides both the parameter group time zone and a time zone set at database level.Follow"


Question: My Spot Instance was terminated. Can I recover it?

"I had an Amazon Elastic Compute Cloud (Amazon EC2) Spot Instance running, but the instance was terminated, and I'm concerned I might have lost data."

Answer: "I had an Amazon Elastic Compute Cloud (Amazon EC2) Spot Instance running, but the instance was terminated, and I'm concerned I might have lost data.Short descriptionWith Amazon EC2 Spot Instance, you can request unused Amazon EC2 instances to reduce your compute costs.The Spot Instance can be terminated if:The Spot price increases above the maximum price that you're willing to pay per hour per instanceCapacity is no longer availableThe Spot request has constraints that can't be metFor details about the reasons a Spot Instance can be interrupted, see How Spot Instances work. Data that isn't backed up can be lost when instances are terminated, so it's important to be aware of that for this use case. See Product features for a list of best-suited use cases and workload types.ResolutionIf you have a Spot Instance that was recently terminated or interrupted, you might have a concern that your data has been lost. Here are some places to check for your data:Did you configure your Spot Instances to leave Amazon EBS volumes behind if the instance is terminated? You can configure the Spot Instance to leave Amazon EBS volumes behind if the instance is terminated. Then, you can attach the volume to another instance and attempt to recover data stored on the volume. When creating Spot Instance requests, clear the Delete check box for Amazon EBS volumes that you want to be kept if the instance is terminated. If you attached a volume to your Spot Instance, then the data you're looking for might be stored on the volume. Open the Amazon EC2 console, and then select Volumes. Look for any unattached volumes that have a State of available. These volumes can be attached to another instance. For instructions on attaching a volume to a new instance, see Attach an Amazon EBS volume to an instance.Did you take regular snapshots of any volumes attached to your Spot Instance? Snapshots that are normally used as backups for Amazon EBS volumes might contain the data you're looking for. Open the Amazon EC2 console, and then select Snapshots. Look for any snapshots of volumes that were attached to your Spot Instance. For more information, see Replace a volume using a previous snapshot.Was the data added or backed up to another source? Common output sources for workflows that run through Spot Instances include Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, and Amazon Relational Database Service (Amazon RDS). If you set your Spot Instance to send output to one of these services, check those services for the data you're looking for.For future planning, it's a best practice to prepare for a Spot Instance's termination ahead of time. For example, you can specify Amazon EC2 to stop or hibernate your Spot Instances rather than terminate them when they are interrupted. For more information about how to effectively prepare for a Spot Instance's eventual termination, see Spot Instance interruptions.Related informationAmazon EC2 Spot InstancesAmazon EC2 FAQFollow"


Question: How can I troubleshoot certificate chain and self-signed certificate issues for Amazon API Gateway with custom domains and mutual TLS enabled?

I am using mutual Transport Layer Security (TLS) authentication with Amazon API Gateway with a custom domain name. I am getting certificate chain or self-signed certificate errors. How can I troubleshoot this?

Answer: "I am using mutual Transport Layer Security (TLS) authentication with Amazon API Gateway with a custom domain name. I am getting certificate chain or self-signed certificate errors. How can I troubleshoot this?Short descriptionBefore you begin, make sure that you have:Set up a custom domain name for Amazon API Gateway.Created the certificate chain and self-signed certificate.Imported the certificate chain and self-signed certificate into AWS Certificate Manager (ACM).Configured your truststore and upload it to an Amazon Simple Storage Service (Amazon S3).ResolutionFor a list of specific error messages when invoking your Amazon API Gateway API, run a curl command similar to the following:$ curl -v https://mtls.example.info/test-apigw-mtls --key self-signed.key --cert self-signed.pem:"example"Client errors"curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory, (no key found, wrong pass phrase, or wrong file format?"This error means that the PEM file has the wrong name, location, or file format. For example, the certificate file format stored locally is .crt , but the .pem file was used instead in the API request. To resolve this, make sure that the local client certificate has the correct format and name."curl: (6) Could not resolve host: mtls.example.info"The client wasn't able to resolve the domain name. Make sure that the domain name and configuration are correct."url: (58) schannel: Failed to import cert file self-signed.pem, last error is 0x80092002"This error means that there is an issue with the local client .pem file. Make sure that the .pem file includes the correct name and format."curl: (58) unable to set private key file: 'self-signed.key' type PEM"This error means that there is an issue with the local client file. Make sure that the private key provided in the HTTP request is not missing and correct.Server errors"Access denied. Reason: self-signed certificate."Verify that the self-signed client certificate in the API request isn't altered or corrupted.The following must match exactly:The modulus of the private key (private.key ) used to sign the self-signed certificate within the truststore in Amazon S3 (bundle.crt or bundle.pem ).The modulus from the client's certificate passed in the API request (client.crt ).To compare the two modulus, run the following OpenSSL commands:$ openssl rsa -noout -modulus -in private.key$ openssl x509 -noout -modulus -in bundle.crt$ openssl x509 -noout -modulus -in client.crtNote: To produce a shorter hash value for easier comparison, you can use PIPE to send the output modulus into a cryptographic hash function. For example: openssl sha1 .$ openssl [operation] -noout -modulus -in [data] | openssl sha1Valid command output examples:2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcb2143831a73a8bb28467860df18550c696c03fbcbTo confirm data integrity, verify that there wasn't any data modification at the content level by running the following diff command:$ diff client.crt bundle.crtRelated informationIntroducing mutual TLS authentication for Amazon API GatewayHow do I troubleshoot HTTP 403 Forbidden errors from an API Gateway custom domain name that requires mutual TLS?Follow"


Question: How do I delete a NAT Gateway in Amazon VPC?

I want to delete a NAT gateway in Amazon Virtual Private Cloud (Amazon VPC) using the console.

Answer: "I want to delete a NAT gateway in Amazon Virtual Private Cloud (Amazon VPC) using the console.ResolutionDeleting a NAT gateway disassociates its Elastic IP address, but that action doesn't release the address from your account. If you delete a NAT gateway, then the NAT gateway routes remain in a blackhole status until you update or delete the routes. If you no longer need the Elastic IP address that was associated with a public NAT gateway, see Release an Elastic IP address.To delete a NAT gateway in Amazon VPC, do the following:Access the Amazon VPC console.Select the AWS Region for your Amazon VPC.In the navigation pane, choose NAT Gateways.Select the option button for the NAT gateway, and then choose Actions, Delete NAT gateway.When prompted, enter delete and then choose Delete.Note: The NAT gateway entry might remain visible in the Amazon VPC console for an hour after removal.To delete a NAT gateway with the AWS Command Line Interface (AWS CLI), seedelete-nat-gateway.Related informationWhy can't I delete my requester-managed VPC endpoint?Follow"


Question: How do I resolve the "One or more of your origins or origin groups do not exist" error in AWS CloudFormation?

"When I try to create or update an AWS CloudFormation stack that contains an Amazon CloudFront distribution, I get the following error:"One or more of your origins or origin groups do not exist.""

Answer: "When I try to create or update an AWS CloudFormation stack that contains an Amazon CloudFront distribution, I get the following error:"One or more of your origins or origin groups do not exist."Short descriptionThis error occurs when the TargetOriginId property of CacheBehavior or DefaultCacheBehavior doesn't match a CloudFront origin or origin group ID. This ID is a user-defined string that uniquely identifies an origin or origin group. You must define the origin group in the template, and manage your resources through CloudFormation.Tip: It's a best practice to avoid making changes to stack resources outside of CloudFormation. This can create a mismatch between your stack's template and the current state of your stack resources. When you update or delete the stack, the mismatch can cause errors.Resolution1.    Confirm that the TargetOriginId matches the ID of one of the defined origins or origin groups. Enter the correct origin ID as a parameter for DefaultCacheBehavior or CacheBehavior.In the following example JSON and YAML template snippets, DefaultCacheBehavior defines and consumes a CloudFront distribution with a single origin. Also, the origin uses an origin access identity (OAI) for authentication. In the examples, the origin ID is set to my-s3-origin.JSON:{  "AWSTemplateFormatVersion": "2010-09-09T00:00:00.000Z",  "Resources": {    "cloudfrontdistribution": {      "Type": "AWS::CloudFront::Distribution",      "Properties": {        "DistributionConfig": {          "DefaultCacheBehavior": {            "ViewerProtocolPolicy": "https-only",            "DefaultTTL": 3600,            "ForwardedValues": {              "Cookies": {                "Forward": "none"              },              "QueryString": true            },            "TargetOriginId": "my-s3-origin"          },          "Enabled": true,          "Origins": [            {              "DomainName": "my-s3-bucket.s3.amazonaws.com",              "Id": "my-s3-origin",              "S3OriginConfig": {                "OriginAccessIdentity": {                  "Fn::Sub": "origin-access-identity/cloudfront/${CloudFrontOriginAccessIdentity}"                }              },              "OriginPath": "/my-content"            }          ]        }      }    },    "CloudFrontOriginAccessIdentity": {      "Type": "AWS::CloudFront::CloudFrontOriginAccessIdentity",      "Properties": {        "CloudFrontOriginAccessIdentityConfig": {          "Comment": {            "Ref": "AWS::StackName"          }        }      }    }  }}Note: Replace my-s3-origin with your origin ID, my-s3-bucket.s3.amazonaws.com with your domain name, and /my-content with your origin path.YAML:AWSTemplateFormatVersion: 2010-09-09Resources:  cloudfrontdistribution:    Type: AWS::CloudFront::Distribution    Properties:      DistributionConfig:        DefaultCacheBehavior:          ViewerProtocolPolicy: https-only          DefaultTTL: 3600          ForwardedValues:            Cookies:              Forward: none            QueryString: true          TargetOriginId: my-s3-origin        Enabled: true        Origins:          - DomainName: 'my-s3-bucket.s3.amazonaws.com'            Id: my-s3-origin            S3OriginConfig:              OriginAccessIdentity: !Sub origin-access-identity/cloudfront/${CloudFrontOriginAccessIdentity}            OriginPath: /my-content            CloudFrontOriginAccessIdentity:    Type: AWS::CloudFront::CloudFrontOriginAccessIdentity    Properties:      CloudFrontOriginAccessIdentityConfig:        Comment: !Sub ${AWS::StackName}2.    Test your CloudFront distribution to verify that your CloudFormation stack is created or updated.Related informationUsing various origins with CloudFront distributionsCreating a stack on the AWS CloudFormation consoleAWS CloudFormation best practicesFollow"


Question: Why is my Amazon RDS for MySQL DB instance stuck in "Rebooting"?

"I'm trying to restart my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. However, my DB instance is stuck in the "Rebooting" state, or the reboot is taking longer than expected. Why is this happening, and how do I resolve this?"

Answer: "I'm trying to restart my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. However, my DB instance is stuck in the "Rebooting" state, or the reboot is taking longer than expected. Why is this happening, and how do I resolve this?Short descriptionBefore performing a reboot, make sure to stop any incoming or ongoing transactions in your DB instance. Ongoing transactions will be stopped and any uncommitted transactions will be rolled back.Note: The rollback of uncommitted transactions can be an expensive operation. Uncommitted transactions can also take a long time to complete before your Amazon RDS for MySQL instance becomes available again.After a reboot has begun, the process can't be cancelled and the reboot will continue until it completes. If your reboot is taking longer than expected, investigate the root cause, and consider the following troubleshooting approaches:Check for ongoing queries.Check whether there are any unpurged transactions.Review the MySQL error log file.ResolutionCheck for ongoing queriesUse the SHOW FULL PROCESSLIST command to check whether there are any active queries on your Amazon RDS for MySQL instance:mysql> SHOW FULL PROCESSLIST;Here's an example output that indicates that an UPDATE query is still in progress:+-----+---------------+---------------------+------+---------+------+----------+-----------------------+| Id  | User          | Host                | db   | Command | Time | State    | Info                  |+-----+---------------+---------------------+------+---------+------+----------+-----------------------+|   2 | rdsadmin      | localhost:30662     | NULL | Sleep   |    4 |          | NULL                  || 101 | admin         | 172.31.28.252:58288 | NULL | Query   |  111 | updating |UPDATE tutorials SET tu|+-----+---------------+---------------------+------+---------+------+----------+-----------------------+The output provides information about your MySQL threads running on your database. If there are queries that are still running, then allow the queries to complete before performing a reboot.Note: Run the SHOW FULL PROCESSLIST query as the master user. If you're not the master user, then you must have MySQL server administration privileges to view all active threads on the MySQL instance. Otherwise, the output shows only active thread IDs in the user's MySQL account. For more information, see SHOW PROCESSLIST statement and MySQL server administration on the MySQL website.Check whether there are any unpurged transactionsThe MySQL InnoDB engine uses multiversion concurrency control (MVCC) that maintains a list of old versions of changed rows during a transaction. If a transaction must be rolled back, then InnoDB can perform any undo operations during this process. Old versions of rows are captured inside the undo space. These old versions are purged when they are no longer called during a transaction. If captured changes aren't purged because a transaction still references them, then the history list length can grow larger. For more information, see InnoDB multi-versioning on the MySQL website.Unpurged transactions are represented as the history list length value. This value can be found under "TRANSACTIONS" in the SHOW ENGINE INNODB STATUS command output. Note that the history list length is typically a low value, although a write-heavy workload or long-running transactions can cause the value to increase. For more information about the history list length value, see Purge configuration on the MySQL website.To check for any unpurged transactions inside the history list length, use the SHOW ENGINE INNODB STATUS command. The output from this command also allows you to view size of the history list length and for any ongoing transactions listed under the "TRANSACTIONS" section. For more information about reviewing the listed transactions, see InnoDB standard monitor and lock monitor output on the MySQL website.For example:------------TRANSACTIONS------------Trx id counter 105746959Purge done for trx's n:o < 105746958 undo n:o < 0 state: running but idleHistory list length 32LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 328605240396520, not started0 lock struct(s), heap size 1136, 0 row lock(s)---TRANSACTION 328605240395600, not started0 lock struct(s), heap size 1136, 0 row lock(s)Note: If the history list length is a high value and there are active transactions, then it's not a best practice to reboot.For more information, see SHOW ENGINE INNODB STATUS on the MySQL website.Review the MySQL error log fileIn Amazon RDS, the MySQL error log file is enabled by default. If you suspect that your RDS instance is taking too long to become available again, then review the content of your MySQL error log file. MySQL writes to the error log file when it starts up, shuts down, or when it encounters any errors.For example, InnoDB might have to roll back any uncommitted transactions as part of the InnoDB crash recovery process. If any uncommitted transactions are rolled back, then the MySQL error log document this event. For more information, see InnoDB crash recovery on the MySQL website.Additional troubleshootingNote: If you choose to perform a point-in-time recovery (PITR) or restore from a snapshot, then your new Amazon RDS instance might not be immediately available. For more information, see the following articles:Why is it taking a long time to perform a point-in-time recovery of my Amazon RDS for MySQL instance?Why is it taking so long to restore a snapshot of my Amazon RDS for MySQL DB instance?If your Amazon RDS for MySQL DB instance is rebooting for a while, then try these additional troubleshooting tips:If your DB instance has automated backups enabled, then perform a PITR to restore to a new Amazon RDS instance from a specified time. You can restore to any point in time within your backup retention period.Note: By default, restored DB instances are associated with the default DB parameter and option groups. However, you can use a custom parameter group and option group by specifying them during a restore.Restore your DB instance from the most recent DB snapshot by creating a new DB instance. You can use the restored DB instance as soon as its status is available.If your DB instance has a read replica, then promote the read replica to become a standalone DB instance. When you promote a read replica, the DB instance is automatically rebooted before it becomes available.It's also a best practice to regularly monitor your database activity. You can monitor your Amazon RDS for MySQL DB instance using the following tools:Amazon CloudWatch: With Amazon CloudWatch, you can monitor any ongoing database workload. If you're observing high values in DB connections, CPU utilization, or write/read IOPS, then there might be ongoing activity in your DB instance.Enhanced Monitoring: Enhanced Monitoring requires permission to send OS metric information to CloudWatch Logs. You can grant Enhanced Monitoring permissions using an AWS Identity and Access Management (IAM) role. Before enabling Enhanced Monitoring, you must first create an IAM role.Performance Insights: Performance Schema is an optional performance tool used by Amazon RDS for MySQL (or MariaDB). If you enable or disable Performance Insights, then you won't need to reboot your DB instance. You also won't experience any downtime or a failover.Follow"


Question: How do I mount an encrypted Amazon EFS file system to a pod in Amazon EKS?

I want to mount an encrypted Amazon Elastic File System (Amazon EFS) file system to a pod in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to mount an encrypted Amazon Elastic File System (Amazon EFS) file system to a pod in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionYou can encrypt data in your Amazon EFS file system using one of the following methods:Encrypting data in transit with TLSEncrypting data at restIn the "Resolution" section, choose an encryption method based on your needs.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.ResolutionEncrypt data in transit with TLS1.    Deploy the Amazon EFS Container Storage Interface (CSI) driver for your Amazon EKS cluster.2.    Create an Amazon EFS file system without encryption for your cluster.3.    Clone the GitHub repository to your local system:git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git4.    Go to the encryption_in_transit example directory:cd aws-efs-csi-driver/examples/kubernetes/encryption_in_transit/5.    Retrieve your Amazon EFS file system ID:aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text6.    Go to the pv.yaml file in the /examples/kubernetes/encryption_in_transit/specs/ directory. Then, replace the value of VolumeHandle with the FileSystemId of the Amazon EFS file system that needs to be mounted. For example:apiVersion: v1kind: PersistentVolumemetadata:  name: efs-pvspec:  capacity:    storage: 5Gi  volumeMode: Filesystem  accessModes:    - ReadWriteOnce  persistentVolumeReclaimPolicy: Retain  storageClassName: efs-sc  csi:    driver: efs.csi.aws.com    volumeHandle: [FileSystemId]    volumeAttributes:      encryptInTransit: "true"Note: The volumeAttributes: encryptInTransit mount option activates encryption in transit.7.    Deploy the storage class, persistent volume claim, persistent volume, and pod from the /examples/kubernetes/encryption_in_transit/specs/ directory:kubectl apply -f specs/storageclass.yamlkubectl apply -f specs/pv.yamlkubectl apply -f specs/claim.yamlkubectl apply -f specs/pod.yaml8.    After the objects are created, verify that your pod is running:kubectl get pods9.    List the persistent volumes in the default namespace:kubectl get pv10.    Describe the persistent volume:kubectl describe pv efs-pvNote: The Amazon EFS file system ID is listed as the VolumeHandle.11.    Verify that the data is written onto the Amazon EFS file system:kubectl exec -ti efs-app -- tail -f /data/out.txtEncrypt data at rest1.    Deploy the Amazon EFS CSI driver for your Amazon EKS cluster.2.    Create an Amazon EFS file system by enabling encryption at rest for your Amazon EKS cluster.3.    Clone the following GitHub repository to your local system:git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git4.    Go to the multiple_pods example directory:cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/5.    Retrieve your Amazon EFS file system ID:aws efs describe-file-systemsExample output:{ "FileSystems": [ { "SizeInBytes": { "Timestamp": , "Value": }, "ThroughputMode": "", "CreationToken": “”, "Encrypted": true, "CreationTime": , "PerformanceMode": "", "FileSystemId": "[FileSystemId]", "NumberOfMountTargets": , "LifeCycleState": "available", "KmsKeyId": "arn:aws:kms:ap-southeast-1:<account_id>:key/854df848-fdd1-46e3-ab97-b4875c4190e6", "OwnerId": "" }, ]}6.    Go to the pv.yaml file in the /examples/kubernetes/multiple_pods/specs/ directory. Then, replace the value of volumeHandle with the FileSystemId of the Amazon EFS file system that needs to be mounted. For example:apiVersion: v1kind: PersistentVolumemetadata:  name: efs-pvspec:  capacity:    storage: 5Gi  volumeMode: Filesystem  accessModes:    - ReadWriteMany  persistentVolumeReclaimPolicy: Retain  storageClassName: efs-sc  csi:    driver: efs.csi.aws.com    volumeHandle: [FileSystemId]7.    Deploy the storage class, persistent volume claim, persistent volume, and pod from the /examples/kubernetes/multiple_pods/specs/ directory:kubectl apply -f specs/storageclass.yaml kubectl apply -f specs/pv.yaml kubectl apply -f specs/claim.yaml kubectl apply -f specs/pod1.yaml kubectl apply -f specs/pod2.yaml8.    After the objects are created, verify that your pod is running:kubectl get pods9.    List the persistent volumes in the default namespace:kubectl get pv10.    Describe the persistent volume:kubectl describe pv efs-pv11.    Verify that the data is written onto the Amazon EFS file system:kubectl exec -ti app1 -- tail /data/out1.txtkubectl exec -ti app2 -- tail /data/out1.txtFollow"


Question: Why did my EC2 instance reboot or restart itself?

Why did my Amazon Elastic Compute Cloud (Amazon EC2) instance reboot or restart unexpectedly?

Answer: "Why did my Amazon Elastic Compute Cloud (Amazon EC2) instance reboot or restart unexpectedly?Short descriptionAlthough unexpected reboots or restarts are rare, there are several reasons they might occur. The following are the most common reasons:The instance failed one or both of its status checks.The underlying hardware hosting your instance was faulty and Amazon EC2 restarted the instance to move it to new, healthy hardware.Scheduled maintenance occurred on your instance that required a reboot.A user or application inside your server rebooted the instance.A kernel bug. If you encounter a kernel bug, be sure that your kernel is fully updated.To update the kernel, run one of the following commands or similar, depending on your Linux Operating system and version:sudo yum update kernelsudo zypper up kernel-defaultsudo apt upgrade linux-image-awsResolutionThere are several actions that you can take to determine why your instance rebooted:View status checksView the instance's status checks from the console or using the AWS Command Line Interface (AWS CLI). If a status check failure is indicated, see Why is my EC2 Linux instance unreachable and failing one or both of its status checks?Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.View system logsIf the instance didn't fail a status check, then the instance might have rebooted due to operating system-level issues. Review the system logs to determine what error occurred. The system logs are located at /var/log/messages or /var/log/syslog depending on your OS distribution.If the instance fails a status check, you can reboot the instance to retrieve the system logs by using the console output. Review the console output logs to troubleshoot your issue. For more information, see Retrieve the system logs.View reboot historyUse the following commands to determine if a user or an application inside the server initiated the reboot:# grep reboot /home/*/.bash_history# grep reboot /root/.bash_history# history | grep -i reboot# history | grep -i init# last rebootView AWS CloudTrail Events historyInstance reboots initiated from the Amazon EC2 console or through the AWS CLI appear in CloudTrail Events history. To view these events:Open the AWS CloudTrail console.Choose Event history.Select Event name from the filter dropdown list, and then enter RebootInstances.Note: You can create an Amazon CloudWatch alarm that automatically recovers instances experiencing underlying hardware issues resulting in reboot. For information on how to set up the CloudWatch alarm, see Recover your instance.Related informationTroubleshoot instances with failed status checksTypes of status checksFollow"


Question: How do I capture a screenshot of an unreachable Amazon EC2 Windows instance for troubleshooting?

"I want to capture a screenshot of the Amazon EC2 instance to check its status. But, I can't use Remote Desktop Protocol (RDP) to connect to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance."

Answer: "I want to capture a screenshot of the Amazon EC2 instance to check its status. But, I can't use Remote Desktop Protocol (RDP) to connect to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.Short descriptionAn EC2 Windows instance might be unreachable for various reasons, such as network configuration, permissions, or high CPU use. The status of an instance might be unreachable even if the instance is running and otherwise appears healthy. To help identify why the connection attempt fails or times out, use the Get Instance Screenshot feature.ResolutionNote: 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.You can use the Amazon EC2 console or AWS CLI to get a screenshot of an unreachable instance. The Get Instance Screenshot feature returns an image of the Windows desktop. This image looks similar to the view when you directly connect to the instance with a display monitor.For screenshot examples and troubleshooting steps for the issues that are featured in those examples, see Common screenshots.Related informationTroubleshoot EC2 Windows instancesDetach an Amazon Elastic Block Store (Amazon EBS) volume from a Windows instanceTroubleshoot Remote Desktop disconnected errors (Microsoft)Follow"


Question: How do I replace a lost key pair for my EC2 Windows instance when using EC2Config or EC2Launch to reset the administrator password?

"I'm trying to reset a lost password using EC2Config or EC2Launch, but I lost the private key file for the key pair that I use to launch my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. How can I replace or change the key pair on an EC2 Windows instance?"

Answer: "I'm trying to reset a lost password using EC2Config or EC2Launch, but I lost the private key file for the key pair that I use to launch my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. How can I replace or change the key pair on an EC2 Windows instance?Short descriptionTo replace a lost key pair, you can use the AWS Systems Manager AWSSupport-ResetAccess Automation document**.** Or, you can create an Amazon Machine Image (AMI) of the existing instance, launch a new instance, and then select a new key pair.ResolutionUse the AWSSupport-ResetAccess Automation documentYou can use the Systems Manager AWSSupport-ResetAccess Automation document to replace a lost key pair, or to replace a lost local Administrator password. For instructions, see Reset passwords and SSH keys on EC2 instances.Create an AMI and launch a new instanceWhen you use EC2Config or EC2Launch to reset a lost password, you must use its key pair to retrieve the administrator password. If you've lost the key pair, you can create an AMI of the existing instance, and then launch a new instance. You can then select a new key pair by following the instance launch wizard. 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 AWS CLI version.Create a new key pair, and then save the private key file in a safe place. You can create a key pair using the console, the AWS CLI, or AWS Tools for Windows PowerShell.Note: To give the new key pair the same name as the lost key pair, you must first delete the lost key pair.From the Amazon EC2 console, choose Instances from the navigation pane.Select your instance. From the Description tab, note the Instance type, VPC ID, Subnet ID, Security groups, and IAM role for the instance.Stop your instance. Warning: If this instance has an instance store volume, any data on it is lost when the instance is stopped. If the instance shutdown behavior is set to Terminate, the instance terminates when it is stopped.Select your instance. For Actions, choose Image, Create Image.For Image name, enter a name.(Optional) For Image description, enter a description.Choose Create Image, and then choose Close.Choose AMIs from the navigation pane. If the Status is pending, the AMI is still being created. When the Status is available, continue to the next step.Select the AMI, and then choose Launch.Complete the wizard. Be sure to select the same Instance type, VPC ID, Subnet ID, Security groups, and IAM role as the instance that you are replacing.For Select a key pair, choose the new key pair.(Optional) If the original instance has an associated Elastic IP address, reassociate the Elastic IP address to the new instance.(Optional) If any Amazon Elastic Block Store (Amazon EBS) volumes aren't captured during the AMI creation, detach the volume. Then, attach the volume to the new instance.Note: When you detach the volume, you can skip the step to unmount the volume, because the original instance is already in stopped state.Now that the private key file is replaced, you can reset the administrator password. Use EC2Config for Windows Server 2012 R2 and earlier. Use EC2Launch for Windows Server 2016 and later.(Optional) To clean up, you can terminate the stopped instance for which the key pair is lost. You can also delete the AMI after successfully launching the new instance.Note: Storing AMIs can incur costs. If you no longer need the AMI, delete the AMI.Related informationAmazon EC2 key pairs and Windows instancesTutorial: Get started with Amazon EC2 Windows instancesFollow"


Question: Why don't I see any of my AWS resources after signing in to my AWS account?

"I signed in to my AWS account, but none of my resources are visible in the console. I know that these resources are still provisioned to my account. Why can’t I see them?"

Answer: "I signed in to my AWS account, but none of my resources are visible in the console. I know that these resources are still provisioned to my account. Why can’t I see them?ResolutionHere are a few common reasons that you might not see all your resources in the console:You accidentally signed in to a different accountIf you have more than one AWS account, sign in to the other account, and then check for your resources.The resources are in a different AWS RegionMost AWS resources are located in a specific geographical region, and the console displays only one Region at a time for those services. Be sure that you’re viewing the AWS Region that your resources are in.You don't have permissions to view those resourcesUpdate your IAM policy to allow access to view those resources, or ask your account administrator to update your IAM policy for you.Related informationManaging your accountFollow"


Question: I created or updated an IAM policy and received the error "Has prohibited field Principal". How can I resolve this?

How can I resolve the error "Has prohibited field Principal" with my AWS Identity and Access Management (IAM) policy?

Answer: "How can I resolve the error "Has prohibited field Principal" with my AWS Identity and Access Management (IAM) policy?Short descriptionThe Principal element can be used in resource-based policies to control the IAM user or roles that are allowed to access the resource. For example, Amazon Simple Storage Service (Amazon S3) buckets use the resource-based policy named bucket policy to control access to a bucket. Bucket policies use the Principal element. IAM policies attached directly to IAM identities (users, groups, and roles) grant permissions to make API calls that don't have a Principal element. For more information, see Identity-based policies and resource-based policies.IAM roles have a resource-based policy that controls who's allowed to assume the role and receive temporary credentials. IAM roles also have an identity-based policy that controls what API calls that the temporary security credentials are allowed to make.Resource-based policies are different from resource-level permissions. Resource-level permissions can be used in both resource-based policies and identity-based policies. Resource-level permissions use the Resource element to restrict permissions to AWS resources.ResolutionMake sure policies using the Principal element are created with the AWS service associated with the AWS resource, not within IAM. Check for AWS services that work with IAM to confirm if an AWS service uses resource-based policies. For example, Amazon S3 bucket policies are configured within the S3 service, not within IAM. For instructions, see Adding a bucket policy using the Amazon S3 console.The only resource-based policy that exists within the IAM service itself is the trust policy for IAM roles. To add a trust policy to an IAM role, make sure that you are editing the trust policy and not the permissions policy. For instructions, see modifying a role trust policy and permissions policy.Related informationEditing the trust relationship for an existing roleGranting a user permissions to switch rolesFollow"


Question: "How can I request, view, and manage service quota increase requests using AWS CLI commands?"

I want to use AWS Command Line Interface (AWS CLI) commands to request service quota increases and then view and manage those requests.

Answer: "I want to use AWS Command Line Interface (AWS CLI) commands to request service quota increases and then view and manage those requests.Short descriptionYou can request, view, and manage quotas, formerly known as limits, for AWS services from the Service Quotas console or using AWS CLI commands.For a list of service quota AWS CLI commands, see AWS CLI Command Reference and the Service Quotas API Reference.Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.When using the AWS CLI to manage your service quotas, review the following points:Unless otherwise noted, quotas are specific to each AWS Region. Make sure that you replace the --region parameter in your commands with the Region where you're requesting a quota increase.There's a maximum number of active service quota requests that you can have at a particular time. Also, you can't adjust quota values. For more information, see Service quotas for Service Quotas.The output for the API commands displays in a table format. For information on changing the output to appear in text or JSON format, see Controlling command output from the AWS CLI.ResolutionNote: Each AWS service that's available in Service Quotas has an associated service code. Within each service, the available quota type has a quota code. You must include these codes in your service quota increase requests.Run the list-services command to see the list of service codes for your Region. Replace eu-west-1 with your Region:# aws service-quotas list-services --region eu-west-1 --output tableRun the list-service-quotas command to see available quota codes for a particular service and Region. In the following example, replace --service-code and --region with your specific service and Region. The following example requests service quotas for Amazon Elastic Compute Cloud (Amazon EC2) in the eu-west-1 Region.# aws service-quotas list-service-quotas --service-code ec2 --region eu-west-1 --query "Quotas[*].{ServiceName:ServiceName,QuotaName:QuotaName,QuotaCode:QuotaCode,Value:Value}" --output tableRequest a service quota increaseWhen requesting a service quota increase, check the current limit, and then increase the service quota in a particular Region.1.    Run the get-service-quota command to check the applied quota value for the service you want to increase. The following example requests the service quota for the number of Elastic IP addresses in Amazon EC2 in the eu-west-1 Region. Replace the --service-code, --quota-code, and --region with the values for your request.# aws service-quotas get-service-quota --service-code ec2 --quota-code L-0263D0A3 --region eu-west-1{    "Quota": {        "ServiceCode": "ec2",        "ServiceName": "Amazon Elastic Compute Cloud (Amazon EC2)",        "QuotaArn": "arn:aws:servicequotas:eu-west-1:111122223333:ec2/L-0263D0A3",        "QuotaCode": "L-0263D0A3",        "QuotaName": "EC2-VPC Elastic IPs",        "Value": 5.0,        "Unit": "None",        "Adjustable": true,        "GlobalQuota": false    }}2.    Use the request-service-quota-increase command to request a quota increase. The following example requests a quota increase for Number of Elastic IP addresses in Amazon EC2 in the eu-west-1 Region. Replace the --service-code, --quota-code, and --region with the values for your request.# aws service-quotas request-service-quota-increase --service-code ec2 --quota-code L-0263D0A3 --region eu-west-1 --desired-value 10{    "RequestedQuota": {        "Id": "d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20",        "ServiceCode": "ec2",        "ServiceName": "Amazon Elastic Compute Cloud (Amazon EC2)",        "QuotaCode": "L-0263D0A3",        "QuotaName": "EC2-VPC Elastic IPs",        "DesiredValue": 10.0,        "Status": "PENDING",        "Created": 1576431516.421,        "Requester": "{\"accountId\":\"111122223333\",\"callerArn\":\"arn:aws:iam::111122223333:user/testeksuser\"}",        "QuotaArn": "arn:aws:servicequotas:eu-west-1:111122223333:ec2/L-0263D0A3",        "GlobalQuota": false,        "Unit": "None"    }After creating the request, you can use the Service Quotas console to track the new case. Or, you can use the AWS CLI to check the request status.Check the status of a service quota increase requestRun the get-requested-service-quota-change command to check the status of a pending request. In the following example, replace the --request-id and --region with the values of your request. The output shows the Case ID and the Status of the request.# aws service-quotas get-requested-service-quota-change --request-id "d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20" --region eu-west-1{    "RequestedQuota": {        "Id": "d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20",        "CaseId": "6672648091",        "ServiceCode": "ec2",        "ServiceName": "Amazon Elastic Compute Cloud (Amazon EC2)",        "QuotaCode": "L-0263D0A3",        "QuotaName": "EC2-VPC Elastic IPs",        "DesiredValue": 10.0,        "Status": "CASE_OPENED",        "Created": 1576431516.421,        "LastUpdated": 1576431520.527,        "Requester": "{\"accountId\":\"111122223333\",\"callerArn\":\"arn:aws:iam::111122223333:user/testeksuser\"}",        "QuotaArn": "arn:aws:servicequotas:eu-west-1:111122223333:ec2/L-0263D0A3",        "GlobalQuota": false,        "Unit": "None"    }}After a quota increase request reaches CASE_CLOSED, APPROVED, or DENIED status, you can check the details of the request. Service quota increase request history is kept for 90 days. For more information, see ListRequestedServiceQuotaChangeHistoryByQuota.# aws service-quotas get-requested-service-quota-change --request-id "d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20" --region eu-west-1{    "RequestedQuota": {        "Id": "d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20",                                           "CaseId": "6672648091",        "ServiceCode": "ec2",        "ServiceName": "Amazon Elastic Compute Cloud (Amazon EC2)",                                           "QuotaCode": "L-0263D0A3",        "QuotaName": "EC2-VPC Elastic IPs",        "DesiredValue": 10.0,        "Status": "CASE_CLOSED",                                           "Created": 1576431516.421,        "LastUpdated": 1576432913.04,        "Requester": "{\"accountId\":\"111122223333\",\"callerArn\":\"arn:aws:iam::111122223333:user/testeksuser\"}",                                           "QuotaArn": "arn:aws:servicequotas:eu-west-1:111122223333:ec2/L-0263D0A3",        "GlobalQuota": false,        "Unit": "None"    }}Track multiple service quota increase requestsUsing the following APIs, you can check all requests that were made in a particular Region, including all services and their quotas codes. You can also check all requests that were made for a Region that's specific to a quota code.Example 1Run the following command to check the status of all requests that were made in a specific Region, including all services and their quota codes:# aws service-quotas list-requested-service-quota-change-history --region eu-west-1 --query "RequestedQuotas[*].{CaseId:CaseId,Id:Id,QuotaCode:QuotaCode,QuotaName:QuotaName,DesiredValue:DesiredValue,Status:Status}" --output table-------------------------------------------------------------------------------------------------------------------------------------------------|                                                    ListRequestedServiceQuotaChangeHistory                                                     |+------------+---------------+--------------------------------------------+-------------+----------------------------------------+--------------+|   CaseId   | DesiredValue  |                    Id                      |  QuotaCode  |               QuotaName                |   Status     |+------------+---------------+--------------------------------------------+-------------+----------------------------------------+--------------+|  None      |  50.0         |  2f919bc7e8b942e4a4d9e48b70e714547VLCFkjY  |  L-3D9CCA6E |  Tasks per Maintenance Window          |  APPROVED    ||  6673136551|  10.0         |  cc07103300c74653911cebbd78739dacEToPmn3Z  |  L-DE82EABA |  Running Dedicated g3 Hosts            |  CASE_OPENED ||  6673112701|  10.0         |  fb78996c9c364915825bab46f2b6a313J8FAIAFm  |  L-8CCBD91B |  Running On-Demand m5d hosts           |  CASE_OPENED ||  6673109881|  10.0         |  06db5543f3a74dcda55346ca4812a6a0H4jikbty  |  L-24D7D4AD |  Running On-Demand m5n hosts           |  CASE_OPENED ||  6673043811|  10.0         |  0cf070a56ae742acaf5143f5685d9cc8pGWjHH9l  |  L-0263D0A3 |  EC2-VPC Elastic IPs                   |  CASE_OPENED ||  6672648091|  10.0         |  d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20  |  L-0263D0A3 |  EC2-VPC Elastic IPs                   |  CASE_CLOSED |+------------+---------------+--------------------------------------------+-------------+----------------------------------------+--------------+Example 2Run the following command to check the status of all your requests that were made for a specific quota code:# aws service-quotas list-requested-service-quota-change-history-by-quota --service-code ec2 --quota-code L-0263D0A3 --region eu-west-1 --query "RequestedQuotas[*].{CaseId:CaseId,Id:Id,QuotaCode:QuotaCode,QuotaName:QuotaName,DesiredValue:DesiredValue,Status:Status}" --output table--------------------------------------------------------------------------------------------------------------------------------------|                                            ListRequestedServiceQuotaChangeHistoryByQuota                                           |+------------+---------------+--------------------------------------------+-------------+----------------------------+---------------+|   CaseId   | DesiredValue  |                    Id                      |  QuotaCode  |         QuotaName          |    Status     |+------------+---------------+--------------------------------------------+-------------+----------------------------+---------------+|  6673043811|  10.0         |  0cf070a56ae742acaf5143f5685d9cc8pGWjHH9l  |  L-0263D0A3 |  EC2-VPC Elastic IPs       |  CASE_OPENED  ||  6672648091|  10.0         |  d323c5f4eb8d400e96fbf34743b373a7YRHQ2y20  |  L-0263D0A3 |  EC2-VPC Elastic IPs       |  CASE_CLOSED  |+------------+---------------+--------------------------------------------+-------------+----------------------------+---------------+Related informationHow can I troubleshoot errors using the AWS CLI to manage my Service Quota requests? What is Service Quotas?Introducing Service Quotas: View and manage your quotas for AWS services from one central locationFollow"


Question: How do I remove a lost or broken MFA device from my AWS account?

"I'm using a multi-factor authentication (MFA) device, but now I can't find the device, the device is broken, or the device is out-of-sync. How do I remove it?"

Answer: "I'm using a multi-factor authentication (MFA) device, but now I can't find the device, the device is broken, or the device is out-of-sync. How do I remove it?ResolutionIf the lost, broken, or out-of-sync MFA device is preventing you from signing in to the account, see What If an MFA device is lost or stops working?If you're still unable to gain access to the account, you can request assistance from AWS Support by filling out the Lost or unusable Multi-Factor Authentication (MFA) device form.If you can sign in to the account, and you want to remove an MFA device from an AWS account root user or deactivate an MFA device for an AWS Identity and Access Management (IAM) user, see Deactivating MFA devices.Related informationWhat do I do if I receive an error when entering the CAPTCHA to sign in to my AWS account?Using multi-factor authentication (MFA) in AWSResynchronizing virtual and hardware MFA devicesFollow"


Question: Why can't I associate a transit gateway to my Direct Connect gateway?

I want to troubleshoot why I can't associate a transit gateway with my AWS Direct Connect gateway.

Answer: "I want to troubleshoot why I can't associate a transit gateway with my AWS Direct Connect gateway.ResolutionTo troubleshoot this issue, do the following:Confirm that your Direct Connect gateway isn't associated with a virtual private gateway or private virtual interface. A Direct Connect gateway can be associated with either a virtual private gateway or a transit gateway, but not both. If your Direct Connect gateway is associated with a virtual private gateway or a private virtual interface, then create a new Direct Connect gateway.Confirm that your Direct Connect gateway and transit gateway don't have the same Autonomous System Number (ASN). If they have the same ASN, then modify the ASN of your transit gateway. Or, create a new Direct Connect gateway with a different ASN. If you connect to multiple transit gateways that are in different Regions, use unique ASNs for each transit gateway.Confirm that you have the required AWS Identity and Access Management (IAM) permissions to associate a transit gateway to your Direct Connect gateway. For more information, see Identity and Access Management for Direct Connect.You can attach up only up to three transit gateways to a Direct Connect gateway. Make sure that you aren't exceeding this limit. For more information, see AWS Direct Connect quotas.Related informationTransit gateway associationsFollow"


Question: How do I run a command on an existing EC2 Windows instance when I reboot or start the instance?

I want to run a custom script on my existing Amazon Elastic Compute Cloud (Amazon EC2) Windows instance when I reboot or start the instance. How can I do this?

Answer: "I want to run a custom script on my existing Amazon Elastic Compute Cloud (Amazon EC2) Windows instance when I reboot or start the instance. How can I do this?Short descriptionYou can run a script that runs after the instance reboots or starts by adding it to user data. User data is processed by EC2Config (Windows Server 2012 R2 and earlier) or EC2Launch (Windows Server 2016 and later).ResolutionWhen you add the script to user data, you must enclose it within a special tag. This tag determines whether the commands run in a Command Prompt window or run in Windows PowerShell. For more information, see Run commands on your Windows instance at launch.You can't add or change user data when the instance is running, but you can view it. To add or change user data, the instance must be in the stopped state. User data scripts don't run automatically when you reboot or start the instance. You can enable the user data to run the next time, or every time, that you reboot or start the instance.Warning: Before you stop an instance, be aware of the following:If you're not using an Elastic IP Address, then the public IP address is released when you stop the instance.If this instance has an instance store volume, then any data on it is lost when the instance is stopped.If the instance shutdown behavior is set to Terminate, then the instance terminates when it is stopped.If the instance is part of an Auto Scaling group, first detach the instance from the Auto Scaling Group. Then, after you stop and start the instance, attach the instance back to the Auto Scaling group.For more information, see Stop and start your instance.1.    Connect to your EC2 Windows instance.2.    For Windows Server 2016 or later, open a Windows PowerShell command window, and then run the following command:C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –ScheduleFor Windows Server 2012 R2 or earlier, open C:\Program Files\Amazon\Ec2ConfigService\Ec2ConfigServiceSetting.exe.Then, for User Data, select Enable UserData execution for next service start.Note: The preceding command changes the local administrator password of the instance at every restart. If you're using an AMI with the No Key Pair option selected, you might lose access to your instance on restart.3.    From the Amazon EC2 console, stop the instance.4.    Select the instance. Then choose, Actions, Instance Settings, Edit User Data.5.    Add or update the user data, and then choose Save.Note: To run user data scripts every time you reboot or restart the instance, add the following:<persist>true</persist>6.    Start the instance. The user data scripts run as part of the instance start process.For additional troubleshooting, EC2Launch and EC2Config log files contain the output from the standard output and standard error streams. Log files are located as follows:EC2Launch: C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.logEC2Config: C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2Config.logRelated informationHow do I run a command on a new EC2 Windows instance at launch?Follow"


Question: How do I confirm a user account in Amazon Cognito?

I want to confirm a user account in Amazon Cognito.

Answer: "I want to confirm a user account in Amazon Cognito.ResolutionThere are two ways to confirm a user account in Amazon Cognito:Through email or phone number verificationThrough the administratorBoth of these options set the user status to CONFIRMED.Email or phone number verificationConfigure your Amazon Cognito user pool to require that users provide an email address or phone number when they sign up. Amazon Cognito then sends a verification code to that email address or phone number to confirm the user account.By providing the verification code, the user proves that they have access to the mailbox or phone that received the code. After the user provides the code, Amazon Cognito does the following:Sets the user status to CONFIRMED.Updates the user attributes to indicate that the email address or phone number is verified.For information on how to choose the user contact attribute that Amazon Cognito sends a verification message to, see Verifying contact information at sign-up.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.AWS CLI commands:Signupaws cognito-idp sign-up --client-id 3n4b5urk1ft4fl3mg5e62d9ado --username testuser --password PASSWORD --user-attributes Name="email",Value="jane@example.com" Name="name",Value="Jane"Output{  "UserConfirmed": false,  "UserSub": "e04d60a6-45dc-441c-a40b-e25a787d4862"}Confirm signupaws cognito-idp confirm-sign-up --client-id 3n4b5urk1ft4fl3mg5e62d9ado --username testuser --confirmation-code CONF_CODENote: You must pass --secret-hash in the CLI command if you meet both of the following requirements:Your AWS CLI commands have --client-id as a parameter.The app client is configured with a secret.To calculate the secret hash of an app client, see [How do I troubleshoot "Unable to verify secret hash for client" errors from my Amazon Cognito user pools API?](https://repost.aws/knowledge-center/cognito-unable-to-verify-secret-hash)Administrator verificationTo confirm a user account through administrator verification, use the Amazon Cognito console, or use the AWS CLI API command.Use the Amazon Cognito console:Open the Amazon Cognito console.From the navigation pane, choose User Pools, and then select your user pool.Choose the Users tab, and then select the user that you want to confirm.In the user information page, choose Actions, and then select Confirm Account.Use the AWS CLI command:aws cognito-idp admin-confirm-sign-up --user-pool-id us-west-2_aaaaaaaaa --username testuserFollow"