Question: Why are my Amazon Pinpoint voice message logs not populating?

"I set up an Amazon Pinpoint voice event destination to log Amazon Pinpoint voice messages, but I'm not seeing any logs. Why are my Amazon Pinpoint voice message logs not populating, and how do I troubleshoot the issue?"

Answer: "I set up an Amazon Pinpoint voice event destination to log Amazon Pinpoint voice messages, but I'm not seeing any logs. Why are my Amazon Pinpoint voice message logs not populating, and how do I troubleshoot the issue?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.Verify that your requests to the SendVoiceMessage API operation include the name of your configuration setCheck the value for the ConfigurationSetName parameter in your requests to the SendVoiceMessage API operation. The request must contain the exact name of your configuration set.Example Python request to the SendVoiceMessage API operation that includes the ConfigurationSetName parameterresponse = client.send_voice_message(    DestinationPhoneNumber=destinationNumber,    OriginationPhoneNumber=originationNumber,    ConfigurationSetName="ConfigurationSetName",  # Pass the ConfigurationSetName here    Content={        "SSMLMessage": {            "LanguageCode": languageCode,            "VoiceId": voiceId,            "Text": ssmlMessage,        }    },)Verify that the Amazon Pinpoint voice event destination is activated1.    Run the following get-configuration-set-event-destinations AWS CLI command:Important: Replace <Pass_the_configuration_set_name> with your configuration set's name.aws pinpoint-sms-voice get-configuration-set-event-destinations --configuration-set-name <Pass_the_configuration_set_name>2.    In the command output, review the "Enabled" parameter. The event destination isn't activated if this parameter's value is false.Note: Logs don't write to an event destination if the destination isn't activated.3.    If the event destination isn't activated, then activate the event destination by running the following update-configuration-set-event-destination command:Important: Replace <Pass_the_configuration_set_name> with your configuration set's name. Replace <EventDestinationName> with your event destination's name. Replace <InputFileName> with your input request file's name. Make sure that your input request file's "Enabled" parameter is configured as true.aws pinpoint-sms-voice update-configuration-set-event-destination --configuration-set-name <Pass_the_configuration_set_name> --event-destination-name <EventDestinationName> --event-destination file://<InputFileName>.jsonExample input request file for an Amazon Kinesis Data Firehose stream event destination{    "Enabled": true,    "MatchingEventTypes": ["INITIATED_CALL","RINGING","ANSWERED","COMPLETED_CALL","BUSY","FAILED","NO_ANSWER"],    "KinesisFirehoseDestination": {        "DeliveryStreamArn": "arn:aws:firehose:<region>:<AccountID>:deliverystream/<Name_of_Kinesis_Firehose>",        "IamRoleArn": "arn:aws:iam::<AccountID>:role/service-role/<IAM_role_name>"    }}For more information about input request files, see How do I set up logging for Amazon Pinpoint voice messages?Follow"


Question: How can I troubleshoot packet loss for my Direct Connect connection?

I'm using AWS Direct Connect to transfer data. I'm experiencing packet loss transferring data to my Amazon Elastic Compute Cloud (Amazon EC2) instance. I need to isolate the packet loss.

Answer: "I'm using AWS Direct Connect to transfer data. I'm experiencing packet loss transferring data to my Amazon Elastic Compute Cloud (Amazon EC2) instance. I need to isolate the packet loss.ResolutionPacket loss occurs when transmitted data packets fail to arrive at their destination resulting in network performance issues. Packet loss is caused by low signal strength at the destination, excessive system utilization, network congestion, or network route misconfigurations.Run the following checks for your network devices and Direct Connect connection.Check the AWS Personal Health Dashboard for scheduled maintenance or eventsThe AWS Personal Health Dashboard displays relevant information regarding the resources that are under maintenance and also provides notifications for activities. For more information, see How can I get notifications for Direct Connect scheduled maintenance or events?Check metrics for the Direct Connect endpoint, customer gateway, and intermediate device (layer 1)With customer gateway and intermediate devices, the issue might be local to the on-premises network or the transit path towards AWS. Check the following on the on-premises node and intermediate devices:The customer gateway logs for Interface flapsCPU utilization for the customer gateway when the issue occurredThe light signal reading on the device that the Direct Connect connection terminatesThe device that the Direct Connect connection terminates for input errors, incrementing framing errors, cyclic redundancy (CRC) errors, runts, giants, or throttlesCheck Direct Connect connection metrics (layer 1)Check for the following Direct Connect metrics:ConnectionErrorCount: Apply the sum statistic for this metric. Note that non-zero values indicate MAC level errors in the AWS device.ConnectionLightLevelTX and ConnectionLightLevelRX: Check the light signal recorded on the Direct Connect connection when the issue occurred. The acceptable range is between -14.4 and 2.50 dBm.ConnectionBpsEgress and ConnectionBpsIngress: Check the amount of traffic on the Direct Connect connection when the packet loss occurred for congestion on the link. If you use 100% capacity of the interface, then you might experience packet loss excess traffic.For more information, see Direct Connect Connection metrics.Check for asymmetric sub optimal routing (layer 3)Asymmetric routing occurs when network traffic enters through one connection and exits through another connection. This routing might cause packet loss if the on-premises firewall performs unicast reverse path forwarding, which causes network traffic to drop.If you have a backup redundant Direct Connect connection or a backup AWS Site-to-Site VPN connection, then check for any asymmetric routing that might be happening.Suppose that you have a backup Site-to-Site VPN connection and advertised similar prefixes over both the Direct Connect and VPN connections. In this case, traffic from AWS to on-premises is routed through Direct Connect. To avoid asymmetric routing, be sure to send the traffic over only Direct Connect from on-premises to AWS.If you have a backup Direct Connect connection, asymmetric routing might happen depending on how you advertise your prefixes over both Direct Connect connections.Suboptimal routing with the on-premises network might cause packet loss.For more information, see How can I resolve asymmetric routing issues when I create a VPN as a backup to Direct Connect in a transit gateway?End-to-end bidirectional trace route between the on-premises host and the AWS host (layer 3)Running trace route between the hosts determines the network path taken in both directions. Trace results also determine if the routing is asymmetric, load balanced, and so on.1.    Run the following command to install traceroute:Linux:sudo yum install tracerouteUbuntu:sudo apt-get install traceroute2.    Run a command similar to the following for the TCP traceroute:sudo traceroute -T -p <destination Port> <IP of destination host>Windows OS:Download WinPcap and tracetcp.Extract the Tracetcp ZIP file.Copy tracetcp.exe to your C drive.Install WinPcap.Open the command prompt and root WinPcap to your C drive using the C:\Users\username>cd \ command.Run tracetcp using the following commands: tracetcp.exe hostname:port or tracetcp.exe ip:port.End-to-end bidirectional MTR test between the on-premises host and the AWS host (layer 3)MTR tests are similar to traceroute for allowing the discovery of each router in the network connection pathway between the hosts. MTR tests also provide information on each node in the path such as packet loss.Check the MTR results for packet loss and network latency. A network loss percentage at a hop can indicate an issue with the router. Some service providers limit the ICMP traffic that MTR uses. To determine if the packet loss is due to rate limits, review the subsequent hops. If the subsequent hop shows a loss of 0.0%, this can indicate ICMP rate limiting.1.    Run the following command to install MTR:Amazon Linux/REHEL:$ sudo yum install mtr -yUbuntu:sudo apt install mtr -yWindows OS:Download and install WinMTR.Note: For Windows OS, WinMTR doesn't support TCP-based MTR.2.    For the on-premises to AWS direction, run MTR on the on-premises host (ICMP and TCP based):$ mtr -n -c 100 <private IP of EC2> --report$ mtr -n -T -P <EC2 instance open TCP port> -c 100 <private IP of EC2> --report3. For the AWS to on-premises direction, run MTR on the EC2 instance (ICMP and TCP based):$ mtr -n -c 100 <private IP of the local host> --report$ mtr -n -T -P <local host open TCP port> -c 100 <private IP of the local host> --reportReview the path MTU between the on-premises host and AWS host (layer 3)The maximum transmission unit (MTU) is the size of the largest permissible packet that was passed over the network connection. Any packet that's greater than the MTU size is dropped on the interface. Therefore, packet loss can occur if the packet is too large.Path MTU Discovery (PMTUD) determines the MTU path. For more information, see Path MTU Discovery.You can check the path MTU between two hosts using tracepath.1.    For the on-premises to AWS direction, run tracepath on port 80 from the localhost:$ tracepath -n -p 80 <EC2 private instance IP>2.    For the AWS to on-premises direction, run tracepath on port 80 from the EC2 instance:$ tracepath -n -p 80 <private IP of local host>Check for possible routing issues with BGPThe Direct Connect connection uses the dynamic routing protocol Border Gateway Protocol (BGP) for routing and communication between AWS and on-premises.Check for any regular flaps in BGP that might be causing intermittent packet loss.Check for the route age of learned routes from AWS to customer network in the customer gateway device. When the routes are refreshed in the customer gateway device, the route age is updated in the BGP route table. You can review this information to check if packet loss happened briefly when the route is refreshed.To check the route age on a Cisco router, run the following command:Router#sh ip bgp 1.1.1.1       BGP routing table entry for 1.1.1.1/32, version 3Paths: (1 available, best #1, table default)  Not advertised to any peer  Refresh Epoch 1  64512, (received & used)    169.254.92.181 from 169.254.92.181 (169.254.92.181)      Origin IGP, metric 100, localpref 100, valid, external, best      rx pathid: 0, tx pathid: 0x0      Updated on Mar 31 2023 08:08:00 UTC    >> Last time that the route was updated-or-Router#sh ip route | in 1.1.1.1B    1.1.1.1 [20/100] via 169.254.92.181, 01:37:46   >> You can see the route age or when the route was last refreshedIf you use a hosted connection, check with your partner or service provider to find out if maintenance on their end is causing the packet loss.Related informationBest practices for configuring network interfacesHow can I monitor packet loss and latency from AWS to an on-premises network over an internet gateway or NAT gateway?Troubleshooting AWS Direct ConnectHow can I troubleshoot Direct Connect network performance issues?Download WinPcap and tracetcp.Follow"


Question: How can I scale up or scale out an Amazon OpenSearch Service domain?

I'm trying to scale up or scale out an Amazon OpenSearch Service domain.

Answer: "I'm trying to scale up or scale out an Amazon OpenSearch Service domain.Short descriptionBased on your workload, you can scale up (scale vertically) or scale out (scale horizontally) your cluster. To scale out your OpenSearch Service domain, add additional nodes (such as data nodes, master nodes, or UltraWarm nodes) to your cluster. To resize or scale up your domain, increase your Amazon Elastic Block Store (Amazon EBS) volume size. Or add more memory and vCPUs with bigger node types.Note: When scaling up or scaling out, it's a best practice to use at least three dedicated master nodes for production workloads.ResolutionScale out your domainWhen you scale out your domain, you're adding nodes of the same configuration type as your current cluster nodes. As a result, you're also adding more resources (like RAM, VCPU, and EBS volume) to your cluster. Note that the maximum EBS volume size depends on the node's Amazon Elastic Compute Cloud (Amazon EC2) instance type.If you reach the EBS volume size limit and can't modify the instance type, then add more nodes. When you add more nodes to your cluster, you increase the cluster's EBS volume size. If you're adding more data nodes to your cluster, then make sure to use data nodes or UltraWarm nodes. Note that UltraWarm nodes can be used to migrate less frequently accessed data, while retaining accessed indices on standard data nodes.Tip: To automate the migration of data from hot nodes to warm nodes, use an Index State Management (ISM) policy.Scale up your domainWhen you scale up your OpenSearch Service domain, no additional nodes are added to your cluster. Instead, scaling up involves increasing the available resources for each of your nodes.If you want to vertically scale or scale up your domain, switch to a larger instance type to add more memory or CPU resources.Note: When you scale up your domain, EBS volume size doesn't automatically scale up. You must specify this setting if you want the EBS volume size to automatically scale up.Update your domain configuration settingsTo scale your OpenSearch Service domain, update your domain configuration settings. To edit your domain configuration settings, perform the following steps:1.    Sign in the Amazon OpenSearch Service console.2.    From the navigation pane, under Managed clusters, choose Domains.3.    Choose the domain that you want to scale, and then choose Edit Domain.4.    Choose Actions, and then choose Edit cluster configuration.5.    Based on your use case, update your domain configuration settings:Data nodes: Configure your Availability Zones, instance type, and number of nodes.Storage configuration: Update your data node storage type, EBS volume type, and EBS storage size per node.Dedicated master nodes: Turn on or turn off the dedicated master node, update the instance type, or modify the number of master nodes.UltraWarm data nodes: Turn on or turn off UltraWarm data nodes, update the instance type, or modify the number of UltraWarm data nodes.6.    Choose Submit.Note: OpenSearch Service uses a blue/green deployment process whenever you update your domain. If a blue/green deployment process is started, the number of nodes in your cluster might temporarily increase while changes are applied. For more information, see Making configuration changes in Amazon OpenSearch Service.7.    Configure Amazon CloudWatch alarms to monitor your resource utilization. For example, you can set an alarm that notifies you when CPUUtilization is above 80%.Related informationWhy did my Amazon OpenSearch Service node crash?Troubleshooting Amazon OpenSearch ServiceSupported operations in Amazon OpenSearch ServiceFollow"


Question: How can I copy my Amazon EBS snapshot data to Amazon S3 and create EBS volumes for custom data in S3?

I want to copy an Amazon Elastic Block Store (Amazon EBS) snapshot to my Amazon Simple Storage Service (Amazon S3) bucket. I also want to create Amazon EBS volumes from data that's stored in my S3 bucket.

Answer: "I want to copy an Amazon Elastic Block Store (Amazon EBS) snapshot to my Amazon Simple Storage Service (Amazon S3) bucket. I also want to create Amazon EBS volumes from data that's stored in my S3 bucket.Short descriptionWhen you create an EBS snapshot, it's automatically stored in an Amazon S3 bucket that AWS manages. You can copy snapshots within the same AWS Region, or from one Region to another. However, you can't copy snapshots to S3 buckets that you manage.To store snapshots that you infrequently access, consider using Amazon EBS Snapshots Archive. However, if you still prefer to use Amazon S3 to store your snapshots, then you can use the following workaround.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.To copy the contents of your snapshot to your S3 bucket, create a volume from the snapshot. Mount the volume to an Amazon Elastic Compute Cloud (Amazon EC2) Linux instance. Then, use the AWS CLI or S3 APIs to copy the data to your S3 bucket.To copy the contents of your EBS snapshots to an Amazon S3 bucket, follow these steps:1.    Create an EBS volume from the snapshot.2.    Launch an EC2 Linux instance in the same Availability Zone as the volume that you created.3.    Attach the volume to the instance.4.    Connect to your Linux instance.5.    Install the AWS CLI on your Linux instance.6.    Grant Amazon EC2 instance access to your Amazon S3 bucket.7.    Run the following command to mount the volume to your instance:$ sudo mount /dev/xvdf /mntNote: The device (/dev/xvdf, in the preceding example) might be attached to the instance with a different device name. Use the lsblk command to view your available disk devices along with their mount points to determine the correct device names.8.    Install the pv package to monitor the progress during tar archive creation:Amazon Linux and Red Hat Enterprise Linux (RHEL) distributions$ sudo yum install pvNote: Before you install the pv package for Amazon Linux and RHEL distributions, you must turn on the Extra Packages for Enterprise Linux (EPEL) repository. See How do I turn on the EPEL repository for my Amazon EC2 instance running CentOS, RHEL, or Amazon Linux?Ubuntu and Debian based distributions$ sudo apt install pv9.    Run the following command to copy the EBS volume data to your S3 bucket:$ tar c /mnt | pv -s $(($(du -sk /mnt | awk '{print $1}') \* 1024)) | gzip | aws s3 cp - "s3://my-bucket/backup1.tar.gz"Note: The preceding command creates a compressed file from the /mnt directory and uploads the file to the S3 bucket named my-bucket. Replace my-bucket with your S3 bucket's name and backup1 with your file's name.10.    Use the Amazon S3 console to confirm that the compressed file is uploaded to your S3 bucket.11.    Run the following command to unmount the volume:$ sudo umount /mnt12.    Detach the EBS volume from the Linux instance.13.    Delete the volume, and terminate your instance.Related informationCopy an Amazon EBS snapshotHow can I grant my Amazon EC2 instance access to an Amazon S3 bucket?Follow"


Question: How do I associate an Elastic IP address with a WorkSpace?

I want to associate an Elastic IP address with a WorkSpace in Amazon WorkSpaces.

Answer: "I want to associate an Elastic IP address with a WorkSpace in Amazon WorkSpaces.ResolutionTo associate an Elastic IP address with a WorkSpace, follow these steps:Open the Amazon WorkSpaces console.Select the WorkSpace, and then choose the Hide or Show details arrow to expand the WorkSpace details. Note the WorkSpace IP address.Open the Amazon Elastic Compute Cloud (Amazon EC2) console, and then choose Network Interfaces from the navigation pane.In the search bar, enter the WorkSpace IP address from step 2. Note the Network interface ID for the search result.From the Amazon EC2 console navigation pane, choose Elastic IPs. If you don't have an existing Elastic IP, or if your Elastic IP is already associated with an instance or network interface, then allocate a new IP address.Select the Elastic IP address that you want to associate with the WorkSpace, and then choose Actions, Associate Elastic IP address.For Resource type, choose Network interface.For Network interface, enter the Network interface ID from step 4.Choose Associate.To confirm that the Elastic IP address is associated with the WorkSpace, choose Network Interfaces from the Amazon EC2 console navigation pane. An address appears for IPv4 Public IP.Related informationConfigure a VPC for WorkSpacesConfigure automatic public IP addressesAmazon WorkSpacesFollow"


Question: How do I reboot an instance in an Amazon EC2 Auto Scaling group?

My Amazon Elastic Compute Cloud (Amazon EC2) instance is part of an Amazon EC2 Auto Scaling group. I want to reboot the instance without Amazon EC2 Auto Scaling terminating it due to health check failure. How can I do this?

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) instance is part of an Amazon EC2 Auto Scaling group. I want to reboot the instance without Amazon EC2 Auto Scaling terminating it due to health check failure. How can I do this?Short descriptionIf you stop and start an instance in the InService state in an Amazon EC2 Auto Scaling group, then Amazon EC2 Auto Scaling terminates the instance. Amazon EC2 Auto Scaling does this because the instance fails health checks when it reaches the Stopping or Stopped states during a reboot.Use any of the following procedures to start and stop the instance without Amazon EC2 Auto Scaling marking the instance as Unhealthy and then terminating it:Put the instance into the Standby stateDetach the instance from the groupSuspend the health check processResolutionPut the instance into the Standby stateTo reboot an instance in an Amazon EC2 Auto Scaling group, first put the instance into the Standby state. You do this because Amazon EC2 Auto Scaling doesn’t perform health checks on instances in the Standby state. Choose this option if you need the Amazon EC2 Auto Scaling group to manage the instance throughout the process, as an Auto Scaling group still manages instances in a Standby state.Follow these steps to put the instance into a Standby state, reboot the instance, and then return the instance to service:Open the Amazon EC2 console.In the navigation pane, under Auto Scaling, choose Auto Scaling Groups.Select the group of the instance that you want to reboot. On the Instances view, select the instance you want to reboot.Choose Actions, then choose Set to Standby. On the Set to Standby page, choose Set to Standby.In the navigation pane, under Instances, choose Instances.Note: Optionally, you can choose Add a new instance to the Auto Scaling group to balance the load to maintain the group capacity.Select the instance you set to the Standby state. Choose Actions, choose Instance State, and then choose Reboot.Select the instance again, and then choose the Status Checks view. Confirm that your System Status Checks and Instance Status Checks are passing.In the navigation pane, under Auto Scaling, choose Auto Scaling Groups.Select the group of the instance that you set to the Standby state.Select the instance that you rebooted. Choose Actions, and then choose Set to InService. On the Set to InService page, choose Set to InService.Detach the instance from the groupYou can detach an instance from an Amazon EC2 Auto Scaling group to manage the instance independently of its Amazon EC2 Auto Scaling group. After you reboot the instance, you can attach the instance to an Amazon EC2 Auto Scaling group again or you can leave the instance unattached.Follow these steps to detach the instance from the Amazon EC2 Auto Scaling group, reboot the instance, and then attach the instance to the group again:Open the Amazon EC2 console.In the navigation pane, under Auto Scaling, choose Auto Scaling Groups.Select the group of the instance that you want to reboot. On the Instances view, select the instance.Choose Actions, then choose Detach.On the Detach Instance page, choose Detach Instance.Note: Optionally, you can choose Add a new instance to the Auto Scaling group to balance the load to replace the instance you’re detaching.In the navigation pane, under Instances, choose Instances.Select the instance that you detached. Choose Actions, choose Instance State, and then choose Reboot.Select the instance, and then choose the Status Checks view. Confirm that the System Status Checks and Instance Status Checks are passing.Select the instance, choose Actions, choose Instance Settings, and then choose Attach to Auto Scaling Group.For Attach to Auto Scaling Group, under Attach an instance to, choose an existing Auto Scaling group. Select or search for the group that you detached the instance from. Then, choose Attach.Suspend the health check processYou can suspend the health check process for your Auto Scaling group to reboot instances without Amazon EC2 Auto Scaling terminating the instances.Warning: Suspending a process affects all instances in an Auto Scaling group. Until you resume the process, Amazon EC2 Auto Scaling doesn't replace any unhealthy instances. If you need Amazon EC2 Auto Scaling to perform health checks on remaining instances, choose one of the previous options.Follow these steps to suspend the health check process for your group, reboot an instance, and then resume the health check process for the group:Open the Amazon EC2 console.In the navigation pane, under Auto Scaling, choose Auto Scaling Groups.Select the group of the instance that you want to reboot.On the Details view, choose Edit.Under Suspended Processes, select HealthCheck. Then, choose  Save.In the navigation pane, under Instances, and then choose Instances.Note: Optionally, you can choose Add a new instance to the Auto Scaling group to balance the load to maintain the group capacity.Select the instance that you reboot. Choose Actions, choose  Instance State, and then choose Reboot.Select the instance, and then choose the Status Checks view. Confirm that the System Status Checks and Instance Status Checks are passing.In the navigation pane, under Auto Scaling, choose Auto Scaling Groups.Select the group of the instance that you rebooted.On the Details view, choose  Edit. Under Suspended Processes, remove HealthCheck, and then choose Save.Related informationHow do I delay Auto Scaling termination of unhealthy Amazon EC2 instances so I can troubleshoot them?Follow"


Question: Can I use more than one payment method to pay my AWS charges?

I want to pay my AWS bill with multiple payment methods.

Answer: "I want to pay my AWS bill with multiple payment methods.ResolutionYou can't divide a single AWS bill between multiple payment methods. However, you can add multiple payment methods to your AWS account, and then change the default payment method.If you receive bills from different AWS service providers or seller of records, you can set up a different payment method for each service provider bill.Example: If an AWS Organization account receives invoices from AWS Inc. and AWS EMEA (AWS Europe), each invoice can be paid using a different payment method. Also, you can set up a different payment method for your AWS Marketplace invoices.To assign more than one payment method to your AWS bills, see Managing your payment profiles.Related informationWhat payment methods does AWS accept?How do I view past or current AWS payments?How do I retry an unsuccessful payment?How do change the default payment method associated with my AWS account?Follow"


Question: How do I resolve the "error pulling image configuration: toomanyrequests" error when I use Docker images in AWS CodeBuild?

I want to resolve the "error pulling image configuration: toomanyrequests" error that I get when I use Docker images in AWS CodeBuild.

Answer: "I want to resolve the "error pulling image configuration: toomanyrequests" error that I get when I use Docker images in AWS CodeBuild.Short descriptionIf you use Docker images in CodeBuild, you can experience throttling when you pull layers from the public DockerHub repository.To resolve the error that you receive when throttling happens, you must configure CodeBuild to authenticate the layer pulls using your DockerHub account credentials.Important: To complete the following steps, you must have a DockerHub account and the user name and password for your account.ResolutionStore your DockerHub credentials with AWS Secrets Manager1.    Open the AWS Secrets Manager console.2.    Choose Store a new secret.3.    In the Select secret type section, choose Other type of secrets.4.    In the Specify the key/value pairs to be stored in this secret section, choose the Secret key/value tab.5.    In the first text box, enter username. In the second text box, enter your DockerHub user name. Then, choose Add row.6.    In the first text box of the new row, enter password. In the second text box, enter your DockerHub password. Then, choose Add row.7.    Choose Next.8.    For Secret name, enter a name for your secret. For example: dockerhub9.    Choose Next.10.    Confirm that the default setting for Disable automatic rotation is selected.11.    Choose Next.12.    Choose Store.13.    From the Secret name column, choose your secret.14.    In the Secret details section, note the Amazon Resource Name (ARN) for Secret ARN.Note: If you have created a secret configured with a customer managed encryption key, you must add permissions for the kms:Decrypt action using the configured key.Resolve throttling that happens in the PROVISIONING phase1.    Open the CodeBuild console.2.    In the navigation pane, choose Build, and then choose Build projects.3.    Choose your build project.4.    Choose Edit, and then choose Environment.5.    Choose Override image.6.    For New environment image, choose Custom image.7.    For Environment type, select your custom image.8.    For Image registry, choose Other registry.9.    For External registry URL, enter the name of your Docker image.10.    For Registry credential, enter the secret ARN that you noted earlier.11.    Choose Update environment.Resolve throttling that happens in other phasesImportant: You must grant AWS Identity and Access Management (IAM) permissions to the CodeBuild service role to access the secret.1.    Open the CodeBuild console.2.    In the navigation pane, choose Build, and then choose Build projects.3.    Choose your build project.4.    Choose the Build details tab.5.    In the Environment section, for Service role, choose the service role ARN. This opens the IAM console.6.    On the Permissions tab, choose Add inline policy.7.    Choose the JSON tab.8.    Replace the code the text editor with the following IAM policy:Note: Replace YOUR_SECRET_ARN with the secret ARN that you noted earlier.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "secretsmanager:GetSecretValue"      ],      "Resource": [        "YOUR_SECRET_ARN*"      ]    }  ]}9.    Choose Review policy.10.    For Name, enter a name for the policy. For example: dockerhub_secret_access Note: You can choose any name for the policy. The name is for your own future reference only.11.    Choose Create policy.Configure CodeBuild to retrieve the secret1.    Open the CodeBuild console.2.    In the navigation pane, choose Build, and then choose Build projects.3.    Choose your build project.4.    Choose Edit, and then choose Environment.5.    Expand the Additional configuration section.6.    To add environment variables, in the Environment variables section, for Name, enter DOCKERHUB_USERNAME.7.    For Value, enter the name of your secret, followed by :username. For example: dockerhub:username8.    For Type, choose Secrets Manager.9.    To add the next environment variable, choose Add environment variable.10.    For Name, enter DOCKERHUB_PASSWORD.11.    For Value, enter the name of your secret, followed by :password. For example: dockerhub:password12.    For Type, choose Secrets Manager.13.    Choose Update environment.14.    Modify your buildspec and add the following command before performing any other Docker actions:echo "${DOCKERHUB_PASSWORD}" | docker login -u "${DOCKERHUB_USERNAME}" --password-stdinWarning: This command can record details of your docker login username and password in build logs. After resolving the throttle error, reset your docker password.For example:version: 0.2phases:  install:    commands:      - echo "${DOCKERHUB_PASSWORD}" | docker login -u "${DOCKERHUB_USERNAME}" --password-stdin   build:    commands:      - docker pull docker:dindFollow"


Question: What are the factors that influence downtime for Amazon Aurora DB clusters?

I want to understand why my Amazon Aurora DB cluster is in downtime.

Answer: "I want to understand why my Amazon Aurora DB cluster is in downtime.Short descriptionYour Amazon Aurora DB instances might be in downtime for a number of reasons. The main factors that influence downtime include:Engine version upgradesDB cluster failoversMaintenance tasksDB cluster or instance rebootsModifying specific settings on your DB cluster or instanceResolutionNote: 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.Engine version upgradesEngine version upgrades include major and minor version upgrades. Both major and minor version upgrades cause downtime for your entire Aurora DB cluster. Before you upgrade a production DB cluster, it's important that you test the upgrade process on a test DB cluster. Verify the duration of the process, and then validate your applications before you perform the upgrade.You can also use Amazon Relational Database Service (Amazon RDS) blue/green deployments to upgrade the major or minor version of your cluster. Downtime typically lasts less than one minute for upgrades when using blue/green deployments.Automatic minor version upgradesAutomatic minor version upgrades cause downtime for your entire Aurora DB cluster. These automatic minor version upgrades are applied during the cluster maintenance window. If you don't need this feature then turn automatic minor version upgrades off on your DB instances.For more information, see Upgrading the minor version or patch level of an Aurora MySQL DB cluster.Note: Turning on the automatic minor version upgrade feature itself doesn't cause downtime during the modification. The downtime occurs only when Aurora applies the automatic upgrade.DB cluster failoverIf your Aurora DB cluster has one or more Aurora replicas, then the replica is promoted to the primary instance during failover events. A brief downtime occurs, and read and write operations fail with an exception. Service typically restores in less than 120 seconds, and often less than 60 seconds.To increase the availability of your DB cluster, create one or more Aurora replicas in two or more different Availability Zones (AZs). For more information, see Fault tolerance for an Aurora DB cluster.Maintenance tasks for your Aurora DB clusterSome maintenance tasks, like updates to the operating system (OS) or database patching, cause your DB cluster to go offline for a short period of time. For more information, see Maintaining an Amazon Aurora DB cluster.Maintenance windowDowntime doesn't inherently occur when you modify the maintenance window. But your DB cluster might have one or more pending actions that do cause downtime. If you change the maintenance window, then you apply the pending actions immediately, and downtime occurs. For more information on modifying your maintenance window, see What do I need to know about the Amazon RDS maintenance window?DB cluster or DB instance rebootsRebooting a DB cluster or DB instance causes downtime. The time required to reboot each DB instance in your cluster depends on the database activity at the time of reboot. Downtime also depends on the recovery process of your specific DB engine. For more information, see Rebooting an Amazon Aurora DB cluster or Amazon Aurora DB instance.Modifying the DB instance classWhen you modify the DB instance class of your instance, downtime occurs on the specified DB instance but not the entire cluster. For more information on instance classes, see Aurora DB instance classes.Attaching a new DB cluster or DB parameter groupWhen you modify the DB cluster or DB parameter group that's attached to your DB instance, downtime doesn't occur automatically. But, to apply changes to a DB cluster parameter group, you must reboot the primary DB instance in the cluster. For DB parameter groups, you must reboot the instance to apply changes. The reboot itself causes downtime. For more information, see Associating a DB cluster parameter group with a DB cluster and Working with parameter groups.Modifying specific settings on your DB cluster or instanceModifying parameter settings in a DB cluster or DB parameter groupDatabase parameters are either static or dynamic. When you modify a static parameter setting in a DB cluster or DB parameter group, the parameter change takes effect after you manually reboot the DB instances in each associated DB cluster. Downtime occurs during the reboot.But when you modify a dynamic parameter setting in a DB cluster or DB parameter group, the changes are applied to your DB cluster immediately. The instance isn't rebooted when you modify dynamic parameters, so there is no downtime.For more information, see Working with parameter groups.Modifying the DB instance identifierDowntime occurs when you modify the DB instance identifier because the DB instance is rebooted.Modifying the database portDowntime occurs when you modify the database port that you want to use to access your DB cluster. This happens because all of the DB instances in the DB cluster reboot immediately.Modifying the certificate authorityYou might want to modify the certificate authority (CA) for the server certificate used by your DB instance. In this use case, downtime occurs if the DB engine doesn't support rotation without restart. Use the describe-db-engine-versions AWS CLI command to check if the DB engine supports rotation without restart.For more information on which settings for Aurora influence downtime or not, see Settings for Amazon Aurora.Related informationPerforming major version upgrades for Amazon Aurora MySQL with minimum downtimeFollow"


Question: How do I share my AWS KMS keys across multiple AWS accounts?

"I want to securely grant access to my AWS KMS key to another AWS account, so that it can be used to encrypt and decrypt data on that account. What is the best way to share my KMS key?"

Answer: "I want to securely grant access to my AWS KMS key to another AWS account, so that it can be used to encrypt and decrypt data on that account. What is the best way to share my KMS key?ResolutionTo grant another account access to a KMS key, create an IAM policy on the secondary account that grants access to use the KMS key. For instructions, see Allowing users in other accounts to use a KMS key.You can also use automated monitoring tools to monitor your KMS keys.Note: It’s a best practice to grant least privilege access to your resources, especially when sharing them with accounts you don’t own.Related informationAllow a user to encrypt and decrypt with specific KMS keysShare custom encryption keys more securely between accounts by using AWS Key Management ServiceFollow"


Question: How can I connect to my Lightsail instance using PuTTY or Filezilla if I lost the SSH keypair?

I lost the SSH key pair (private key) that I configured for my Amazon Lightsail instance. How can I regain access to the instance using PuTTY or Filezilla?

Answer: "I lost the SSH key pair (private key) that I configured for my Amazon Lightsail instance. How can I regain access to the instance using PuTTY or Filezilla?ResolutionIf you created the Lightsail instance using the default SSH key pair, then download the SSH private key. To do this, navigate to the Account > Account > SSH keys section in the Amazon Lightsail console. Refer to the following Resolution steps to gain the SSH access if the instance uses a custom SSH key pair (not the default).Method 1: Use the Lightsail browser-based SSH console to configure a new key pair.Generate a new SSH Key Pair from the Amazon Lightsail console and obtain the public key:1.    Open the Amazon Lightsail console.2.    Navigate to Account, Account, SSH keys and then select Create new to create a new SSH key.3.    Retrieve the public key from the private key:On your local Linux or macOS computer, open the terminal, and then run the ssh-keygen command to retrieve the public key for your key pair:$ ssh-keygen -y -f /path_to_key_pair/my-key-pair.pemThe command returns the public key, as shown in the following example:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6Vhz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXrlsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZqaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3RbBQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLEOn your Local Windows computer:Open the puttygen program.Select File, Load private key. Then, change the File name type from PuTTy Private Key Files (*.ppk) to All Files (*.*) to see the .pem file.Select the key pair file (.pem) downloaded in step 2, and then select Open.Select the entire public key, and then right-click and select Copy.Open any text editor and paste the contents you just copied.Connect to the instance via the browser-based SSH console and add the public key to the SSH configuration file1.    Open the Amazon Lightsail console.2.    Select the name of the instance, and then select the Connect tab.3.    Select Connect using SSH.4.    After the SSH console is connected, open the ~/.ssh/authorized_keys file in a text editor.Note: To view the current public key of the keypair accepted by the instance, run the following command:$ cat ~/.ssh/authorized_keys5.    Copy and paste the public key you previously retrieved into the authorized_keys file.6.    Save the authorized_keys file.Now you can connect to your Lightsail instance with PuTTY or Filezilla using the new SSH private key you generated earlier.Note: You must convert a .pem file (private key) into a .ppk file before you connect to your instance using the Putty or Filezilla tool.Method 2: Create a new Lightsail instance from a snapshot and configure the new key pair.1.    Open the Amazon Lightsail console.2.    Create a snapshot of your Lightsail instance.3.    After the snapshot is created, create a new instance from the snapshot.4.    On the Create an instance from a snapshot page, choose an SSH key pair either by creating a new one or choosing an existing key pair that you can access. Then, choose Create instance.Note: If the previous instance had a static IP address, you can use it on the new instance. Detach the static IP address and then attach it to the new instance from the Networking tab. For more information, see Static IP addresses in Amazon Lightsail.Follow"


Question: Why did I get a "User: anonymous is not authorized" error when I tried to access my OpenSearch Service cluster?

I tried to access my Amazon OpenSearch Service domain or OpenSearch Dashboards and got a "User: anonymous is not authorized" error.

Answer: "I tried to access my Amazon OpenSearch Service domain or OpenSearch Dashboards and got a "User: anonymous is not authorized" error.Short descriptionYou get the following error when requests are unsigned and come from a source IP address that isn't allowed in the access policy:"User: anonymous is not authorized"ResolutionClient that doesn't support request signingIf you are using a client that doesn't support request signing (such as a browser), then consider the following:Use an IP-based access policy. IP-based policies allow unsigned requests to an OpenSearch Service domain.Be sure that the IP addresses specified in the access policy use CIDR notation. Access policies use CIDR notation when checking the IP address against the access policy.Verify that the IP addresses specified in the access policy are the same ones used to access your cluster. Check the public IP address of your local computer at https://checkip.amazonaws.com/.Note: If you receive an authorization error, then check to see if you're using a public or private IP address. IP-based access policies can't be applied to OpenSearch Service domains that reside within a virtual private cloud (VPC). This is because security groups already enforce IP-based access policies. If you use public access, then IP-based policies are still available. For more information, see About access policies on VPC domains.Client that supports request signingIf you're using a client that supports request signing, then check the following:Be sure that your requests are correctly signed. AWS uses the Signature Version 4 signing process to add authentication information to AWS requests. Requests from clients that aren't compatible with Signature Version 4 are rejected with a "User: anonymous is not authorized" error. For examples of correctly signed requests to OpenSearch Service, see Making and signing OpenSearch Service requests.Verify that the correct Amazon Resource Name (ARN) is specified in the access policy.If your OpenSearch Service domain resides within a VPC, then configure an open access policy with or without a proxy server. Then, use security groups to control access. For more information, see About access policies on VPC domains.OpenSearch Dashboards endpointsIf you can't access OpenSearch Dashboards, then note the following:The OpenSearch Dashboards endpoint doesn't support signed requests.If your access control policy allows AWS Identity Access Management (IAM) users or roles domain access, then configure your Amazon Cognito authentication for OpenSearch Dashboards. Otherwise, the IAM role or user receives an error when accessing the OpenSearch Dashboards domain.If you try to access the OpenSearch Service domain within a VPC from outside the VPC, then the request will time out.For more information about accessing OpenSearch Service from OpenSearch Dashboards, see Controlling access to OpenSearch Dashboards.Related informationConfiguring Amazon Cognito authentication for OpenSearch DashboardsTroubleshooting Amazon OpenSearch ServiceControlling access to OpenSearch DashboardsFollow"


Question: Why isn't CloudFront following a cache behavior that I created?

"I created a custom cache behavior for a specific URL path pattern on my distribution, but Amazon CloudFront isn't following the cache behavior. Why?"

Answer: "I created a custom cache behavior for a specific URL path pattern on my distribution, but Amazon CloudFront isn't following the cache behavior. Why?ResolutionIf your CloudFront distribution isn't following a cache behavior that you created, check the following:Review your distribution's behaviors to be sure that there's a cache behavior for your requested path pattern. If the requested path pattern isn't correctly defined in a cache behavior, CloudFront uses the default cache behavior. For example, if a cache behavior has Path Pattern set to test/, then a request to example.com/test/file1.jpg follows the default cache behavior. The request won’t follow the behavior specified for test/ because the path pattern is missing a wildcard at the end of the path (test/*).Review the path pattern specified in the cache behavior to be sure that the capitalization is correct. Path patterns specified in CloudFront are case-sensitive. References to buckets or objects in Amazon Simple Storage Service (Amazon S3) are also case-sensitive. If a path pattern has incorrect capitalization and your default cache behavior doesn't cache the requested content, users might receive a "404 Not Found" error.If you recently made changes to the cache behavior and you want to serve the updated content before the existing content expires from the cache, then consider running an invalidation.Note: CloudFront doesn't generate 404 responses. If a requested object isn't found in a CloudFront cache, the request is sent to the origin and the origin generates the 404 response.Related informationPath patternFollow"


Question: Why can't I delete my AWS Directory Service directory?

"I'm unable to delete my Simple AD, AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory, or AD Connector directory. How can I troubleshoot this?"

Answer: "I'm unable to delete my Simple AD, AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory, or AD Connector directory. How can I troubleshoot this?Short descriptionThe following are common issues that might occur when deleting a directory:You receive a message that you must deregister the service from the directory before you can delete it.You receive the error message "An Error Has Occurred. Directory can only be removed if there are no WorkSpaces assigned".ResolutionBoth errors can occur if you have AWS applications enabled for the directory. For information on disabling AWS applications that are enabled for your directory, see Delete your directory.Related informationAWS Directory Service FAQsFollow"


Question: Why is my Amazon OpenSearch Service cluster in a red or yellow status?

My Amazon OpenSearch Service cluster is in a red or yellow cluster status.

Answer: "My Amazon OpenSearch Service cluster is in a red or yellow cluster status.Short descriptionThe Monitoring tab in your OpenSearch Service console indicates the status of the least healthy index in your cluster. A cluster status that shows a red status doesn't mean that your cluster is down. This status indicates that at least one primary shard and its replicas aren't allocated to a node. If your cluster status shows a yellow status, then the primary shards for all indices are allocated to nodes in your cluster. However, one or more replica shards aren't allocated to any of the nodes.Note: Don't reconfigure your domain until you first resolve the red cluster status. If you try to reconfigure your domain when it's in a red cluster status, it could get stuck in a "Processing" state. For more information about clusters stuck in a "Processing" state, see Why is my OpenSearch Service domain stuck in the "Processing" state?Your cluster can enter a red status for the following reasons:Multiple data node failuresUsing a corrupt or red shard for an indexHigh JVM memory pressure or CPU utilizationLow disk space or disk skewNo replica shards for the unassigned shardNote: In some cases, you might be able to resolve your red cluster status by deleting and then restoring the index from an automated snapshot.Your cluster can enter a yellow health status for the following reasons:Creation of a new indexNot enough nodes to allocate to the shards or disk skewHigh JVM memory pressureSingle node failureExceeded the maximum number of shard allocation retriesThe number of replica shards is more than the number of data nodesOngoing blue or green deployment due to relocation of data shardsNote: If your yellow cluster status doesn't resolve itself, you can resolve the status by updating the index settings or by manually rerouting the unassigned shards. If your yellow cluster status doesn't self-resolve, then identify and troubleshoot the root cause. To prevent yellow cluster status, apply the Cluster health best practices.ResolutionIdentifying the reason for your unassigned shardsTo identify the unassigned shards, perform the following steps:1.    List the unassigned shard:$ curl -XGET 'domain-endpoint/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED2.    Retrieve the details for why the shard is unassigned:$ curl -XGET 'domain-endpoint/_cluster/allocation/explain?pretty' -H 'Content-Type:application/json' -d'{     "index": "<index name>",     "shard": <shardId>,     "primary": <true or false>}3.    (Optional) For a red cluster status, delete the indices of concern and identify and address the root cause:curl -XDELETE 'domain-endpoint/<index names>'Then, identify the available snapshots and restore your indices from a snapshot:curl -XGET 'domain-endpoint/_snapshot?pretty'For yellow cluster status, address the root cause so that your shards are assigned.Troubleshooting your red or yellow cluster statusNot enough nodes to allocate to the shardsA replica shard won't be assigned to the same node as its primary shard. A single node cluster with replica shards always initializes with yellow cluster status. Single node clusters are initialized this way because there are no other available nodes that OpenSearch Service can assign a replica.There is also a default limit of "1,000" for the cluster.max_shards_per_node setting for OpenSearch Service versions 7.x and later. It's a best practice to keep the cluster.max_shards_per_node setting to the default value of "1000". If you set shard allocation filters to control how OpenSearch Service allocates shards, the shard can become unassigned from not having enough filtered nodes. To prevent this node shortage, increase your node count. Make sure the number of replicas for every primary shard is less than the number of data nodes. You can also reduce the number of replica shards. For more information, see Sizing OpenSearch Service domains and Demystifying OpenSearch Service shard allocation.Low disk space or disk skewIf there isn't enough disk space, your cluster can enter a red or yellow health status. There must be enough disk space to accommodate shards before OpenSearch Service distributes the shards.To check how much storage space is available for each node in your cluster, use the following syntax:$ curl domain-endpoint/_cat/allocation?vFor more information about storage space issues, see How do I troubleshoot low storage space in my OpenSearch Service domain?Heavy disk skew can also lead to low storage space issues for some data nodes. If you decide to re-allocate any shards, the shards can become unassigned during the shard distribution. To resolve this issue, see How do I rebalance the uneven shard distribution in my OpenSearch Service cluster?The disk-based shard allocation settings can also lead to unassigned shards. For example, if the cluster.routing.allocation.disk.watermark.low metric is set to 50 GB, then the specified amount of disk space must be available for shard allocation.To check the current disk-based shard allocation settings, use the following syntax:$ curl -XGET domain-endpoint/_cluster/settings?include_defaults=true&flat_settings=trueTo resolve your disk space issues, consider the following approaches:Delete any unwanted indices for yellow and red clusters.Delete red indices for red clustersScale up the EBS volume.Add more data nodes.Note: Avoid making any configuration changes to your cluster when it's in a red health status. If you try to reconfigure your domain when it's in a red cluster status, it could get stuck in a "Processing" state.High JVM memory pressureEvery shard allocation uses CPU, heap space, and disk and network resources. Consistently high levels of JVM memory pressure might lead to a failed shard allocation. For example, if JVM memory pressure exceeds 95%, a memory parent circuit breaker is triggered. The allocation thread then gets cancelled, leaving shards unassigned.To resolve this issue, reduce the JVM memory pressure level first. After your JVM memory pressure has been reduced, consider these additional tips to bring your cluster back to a green health status:Increase the default shard retry value from "5" or higher.Deactivate and activate the replica shard.Manually retry the unassigned shards.Example API to increase the retry value:PUT <index-name>/_settings{  "index.allocation.max_retries" : <value>}For more information about reducing your JVM memory pressure, see How do I troubleshoot high JVM memory pressure on my OpenSearch Service cluster?Node failureWhen your cluster experiences a node failure, shards that are allocated to a node become unassigned. When there are no replica shards available for a given index, even a single node failure can cause red health status. Having two replica shards and a Multi-AZ deployment protects your cluster against data loss during a hardware failure.If all your indices have a replica shard, a single node failure can cause your cluster to temporarily enter a yellow health status. If your cluster temporarily enters a yellow health status, then OpenSearch Service will recover automatically as soon as the node is healthy again. Or, OpenSearch Service will recover when shards are assigned to a new node.You can confirm node failures by checking your Amazon CloudWatch metrics. For more information about identifying a node failure, see Failed cluster nodes.Note: It's also a best practice to assign one replica shard for each index or to use dedicated primary nodes and activate zone awareness. For more information, see Coping with failure on the Elasticsearch website.Exceeded the maximum number of retriesIn OpenSearch Service, your cluster must not exceed the maximum time limit (5,000 ms) or the number of retries (5) for shard allocation. If your cluster has reached the maximum thresholds, you must manually trigger a shard allocation. To manually trigger a shard allocation, deactivate and re-activate the replica shards for your indices.A configuration change on your cluster can also trigger shard allocation. For more information about shard allocation, see Every shard deserves a home on the Elasticsearch website.Note: It's not a best practice to manually trigger shard allocation if your cluster has a heavy workload. If you remove all your replicas from an index, the index must rely only on primary shards. When a node fails, your cluster then enters a red health status because the primary shards are left unassigned.To deactivate a replica shard, update the number_of_replicas value to "0":$ curl -XPUT 'domain-endpoint/<indexname>/_settings' -H 'Content-Type: application/json' -d'{     "index" : {          "number_of_replicas" : 0     }}Also, check to make sure the index.auto_expand_replicas setting is set to "false". When your cluster returns to a green status, you can set the index.number_of_replicas value back to the desired value to trigger allocation for replica shards. If the shard allocation is successful, your cluster will enter a green health status.Cluster health best practicesTo resolve your yellow or red cluster status, consider the following best practices:Set a recommended Amazon CloudWatch alarm for AutomatedSnapshotFailure. With the alarm, you can make sure you have a snapshot available to restore your indices from when your cluster enters a red status.If your cluster is under a sustained heavy workload, scale your cluster. For more information about scaling your cluster, see How can I scale up an OpenSearch Service domain?Monitor your disk usage, JVM memory pressure, and CPU usage and make sure they are not exceeding set thresholds. For more information, see Recommended CloudWatch alarms and Cluster metrics.Make sure all primary shards have replica shards to protect against node failures.For more information, see Operational best practices for Amazon OpenSearch Service.Follow"


Question: How can I use a Lambda function to create an Amazon SageMaker notebook instance?

I want to create an Amazon SageMaker notebook instance using an AWS Lambda function.

Answer: "I want to create an Amazon SageMaker notebook instance using an AWS Lambda function.Resolution1.    Create an AWS Identity and Access Management (IAM) Lambda execution role with an attached policy that allows the sagemaker:CreateNotebookInstance action. For example, you can create a role that has the AmazonSageMakerFullAccess policy attached to it.2.    Create an Amazon SageMaker execution role. For more information about the permissions required for Amazon SageMaker execution roles, see CreateNotebookInstance API: execution role permissions.3.    Open the Lambda console.4.    Choose Create function.5.    Choose Author from scratch, and then configure the following options:For Name, enter a name for your function.For Runtime, choose one of the Python options.For Role, choose Choose an existing role.For Existing role, select the IAM role that allows the sagemaker:CreateNotebookInstance action. This is the role that you created in step 1.6.    Choose Create function.7.    In the Function code section, paste code similar to the following:import osimport boto3import timeINSTANCE_TYPE = os.environ['INSTANCE_TYPE']NOTEBOOK_NAME = os.environ['NOTEBOOK_NAME']ROLE=os.environ['ROLE']sagemaker = boto3.client('sagemaker')def lambda_handler(event, context):    sagemaker_notebook = sagemaker.create_notebook_instance(        NotebookInstanceName = NOTEBOOK_NAME +'-'+str(int(time.time())),        InstanceType = INSTANCE_TYPE,        RoleArn=ROLE    )print("New Amazon SageMaker notebook instance created.")8.    Scroll down to the Environment variables section, and then choose Edit.9.    Choose Add environment variable, and then create three environment variables with the following options. Environment variables allow you to store configuration settings without changing the function code.For Key, enter ROLE.For Value, enter the Amazon Resource Name (ARN) for the Amazon SageMaker execution role. This is the role that you created in step 2.For Key, enter INSTANCE_TYPE.For Value, enter the instance type for the notebook instance. For more information, see Supported instance types and Availability Zones.For Key, enter NOTEBOOK_NAME.For Value, enter a name for your notebook.10.    Choose Save to save the environment variables.11.    In the top-right corner of the function configuration page, choose Save, and then choose Test. The test event can be empty ("{}").12.    Open the Amazon SageMaker console to confirm that a notebook instance is initializing.Note: If the Lambda function test times out, open the Lambda function again. Scroll down to the Basic settings section, and then increase the timeout value. The default is three seconds.After you confirm that the function works, you can create a trigger to automatically run the function based on an event in another AWS service. For more information, see Using AWS Lambda with other services.Follow"


Question: How do I delete or terminate my Amazon EC2 resources?

I want to find all resources associated with the Amazon Elastic Compute Cloud (Amazon EC2) service and delete them.

Answer: "I want to find all resources associated with the Amazon Elastic Compute Cloud (Amazon EC2) service and delete them.Short descriptionAmazon EC2 resources fall under a few general billing categories. To stop accruing charges:Identify your active EC2 resources in all AWS Regions.Terminate (delete) all EC2 instances and related resources in all Regions.ResolutionIdentify active resources in your AWS accountTo see your active resources and the Regions where they are provisioned, check your monthly bill in the Billing and Cost Management console.Use the AWSSupport-ListEC2Resources AWS Systems Manager Automation document to list your active EC2 resources. This automation document returns information on EC2 instances and related resources, such as Amazon Elastic Block Store (Amazon EBS) volumes, Elastic IP addresses, and Amazon EC2 Auto Scaling groups from the AWS Regions that you specify. By default, the information is gathered from all Regions and displayed in the output. To run this automation, follow the instructions in Running a simple automation.Delete or terminate EC2 resourcesTo terminate (delete) all your active resources, do the following in the respective Regions:Note: Deleted, terminated, or released resources can't be recovered.Stop or terminate all your EC2 instances and load balancers. Note: EC2 instances are visible in the console for a short time after they're terminated. You aren't billed for any instances that aren't in the running stateDelete your Auto Scaling infrastructure.Release all Dedicated Hosts.Delete all EBS volumes and EBS snapshots.Release all Elastic IP addresses.Deregister all Amazon Machine Images (AMIs).Terminate all Elastic Beanstalk environments.You can check the AWS Cost and Usage Report or AWS Cost Explorer to confirm that the resources are no longer generating charges.Note: Reserved Instances are billed as a flat fee each month. Instead, the fee is determined by the contract that you agreed to when you activated the Reserved Instance. Reserved Instances can't be canceled, but if you have a US bank account, you can list them for sale on the Reserved Instance Marketplace.The following EC2-related resources don't generate charges when used or provisioned to an account:Virtual private clouds (VPCs)Security groupsKey pairsElastic network interfacesAuto Scaling groupsNote: Amazon Lightsail and EC2 are separate services and are billed separately. For more information about Lightsail, see Lightsail docs.Related informationWhy am I charged for Amazon EC2 when all my instances were terminated?Why can't I find an Amazon EC2 instance that I launched on my account?What do I do if I'm receiving a bill from AWS, but can't find the resources related to the charges?Why am I being billed for Elastic IP addresses when all my Amazon EC2 instances are terminated?I unintentionally incurred charges while using the Free Tier. How do I make sure that I'm not billed again?Follow"


Question: How can I automate the replacement of unhealthy Amazon EC2 instances in an Elastic Beanstalk environment?

I want to automate the replacement of unhealthy Amazon Elastic Compute Cloud (Amazon EC2) instances in my AWS Elastic Beanstalk environment.

Answer: "I want to automate the replacement of unhealthy Amazon Elastic Compute Cloud (Amazon EC2) instances in my AWS Elastic Beanstalk environment.Short descriptionBy default, the health check configuration of your Auto Scaling group is set as an EC2 type that performs a status check of EC2 instances. You must use a configuration file to automate the replacement of unhealthy EC2 instances. The configuration file changes the health check type of your instance's Auto Scaling group from EC2 to ELB.Keep the following in mind:Status checks cover only an EC2 instance's health, and not the health of your application, server, or any Docker containers running on the instance.If your application crashes, the load balancer removes the unhealthy instances from its target. However, your Auto Scaling group doesn't automatically replace the unhealthy instances marked by the load balancer.By changing the health check type from EC2 to ELB, you enable the Auto Scaling group to automatically replace the unhealthy instances. The unhealthy instances are replaced when the health check fails.Note: For more information on creating and deploying .ebextensions, see How do I customize my Elastic Beanstalk environment using .ebextensions?ResolutionThe following steps apply to environments with load balancers only.Use a configuration file to change the health check type of your instance's Auto Scaling group to ELB1.    Create a folder named .ebextensions in the root directory of your source bundle.2.    Create a resource-based .ebextension called a .config file. For example:Example .ebextensions/autoscaling.config===============================================Resources:  AWSEBAutoScalingGroup:    Type: AWS::AutoScaling::AutoScalingGroup    Properties:      HealthCheckType: ELB      HealthCheckGracePeriod: 300===============================================Note: HealthCheckGracePeriod refers to the time that Amazon EC2 Auto Scaling waits before checking the health status of an EC2 instance that's come into service.3.    Create a zip file for your updated application source bundle, and then deploy your application.Note: You can also deploy your application using eb deploy.Confirm that the health check type of your Auto Scaling group is set to ELB1.    Open the Amazon EC2 console.2.    In the navigation pane, choose Auto Scaling Groups.3.    For Filter, enter the environment ID of your Auto Scaling group, and then choose your Auto Scaling group from the list of results.4.    On the Details tab of your Auto Scaling group, confirm that Health Check Type is set to ELB.Follow"


Question: How can I resolve the Amazon ECR error "CannotPullContainerError: API error" in Amazon ECS?

"If I pull images with Amazon Elastic Container Registry (Amazon ECR), I get the following error: "CannotPullContainerError: API error.""

Answer: "If I pull images with Amazon Elastic Container Registry (Amazon ECR), I get the following error: "CannotPullContainerError: API error."Short descriptionYou can receive this error due to one of the following issues:Your launch type doesn't have access to the Amazon ECR endpointYour Amazon ECR repository policy restricts access to repository imagesYour AWS Identity and Access Management (IAM) role doesn't have the right permissions to pull or push imagesThe image can't be foundAmazon Simple Storage Service (Amazon S3) access is denied by your Amazon Virtual Private Cloud (Amazon VPC) gateway endpoint policyTo pull images, Amazon ECS must communicate with the Amazon ECR endpoint.ResolutionYour launch type doesn't have access to the Amazon ECR endpoint1.    If you're running a task using an Amazon Elastic Compute Cloud (Amazon EC2) launch type and your container instance is in a private subnet, or if you're running a task using the AWS Fargate launch type in a private subnet, confirm that your subnet has a route to a NAT gateway in the route table.2.    If you're running a task using an EC2 launch type and your container instance is in a public subnet, then confirm that the instance has a public IP address.-or-If you're running a task using the Fargate launch type in a public subnet, then choose ENABLED for Auto-assign public IP when you launch the task. This allows your task to have outbound network access to pull an image.3.    Configure the NAT gateway in your VPC to route requests to the internet.Note: You can use AWS PrivateLink as an alternative to a NAT gateway.4.    If you're using AWS PrivateLink for Amazon ECR, then confirm that the security group that's associated with the interface VPC endpoints for Amazon ECR allows inbound traffic over HTTPS (port 443) from within the security group of your VPC CIDR, ECS container instance, or Fargate task or service.5.    Confirm that the security group attached to your instance and Fargate task allows outbound access for the following: HTTPS on port 443, DNS (UDP and TCP) on port 53, and your subnet's network access control list (network ACL).Your Amazon ECR repository policy restricts access to repository imagesCheck your Amazon ECR repository policy for restrictions on accessing the repository.The following repository policy example allows IAM users to push and pull images:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowPushPull",      "Effect": "Allow",      "Principal": {        "AWS": [          "arn:aws:iam::123456789012:user/push-pull-user-1",          "arn:aws:iam::123456789012:user/push-pull-user-2"        ]      },      "Action": [        "ecr:GetDownloadUrlForLayer",        "ecr:BatchGetImage",        "ecr:BatchCheckLayerAvailability",        "ecr:PutImage",        "ecr:InitiateLayerUpload",        "ecr:UploadLayerPart",        "ecr:CompleteLayerUpload"      ]    }  ]}Your IAM role doesn't have the right permissions to pull imagesIf you're running a task using an EC2 launch type, then confirm that the instance IAM role associated with the instance profile has permissions to access the Amazon ECR repository.Note: The AWS managed policy AmazonEC2ContainerRegistryReadOnly provides the minimum permissions required to pull images.If you're running a task using a Fargate launch type, then confirm that the AmazonECSTaskExecutionRolePolicy has the required permissions.The image can't be foundTo confirm the correct image name in the URI, check the image parameter in the container definitions section of your task definition.Note: To pull by tag, use the following image name format: registry/repository[:tag]. To pull by digest, use the registry/repository[@digest] format.Amazon S3 access is denied by your Amazon VPC gateway endpoint policyIf you have a route to an Amazon VPC gateway endpoint for Amazon S3 in the route table, then complete the following:1.    Verify the access policy of the Amazon VPC gateway endpoint.2.    Confirm that the Amazon VPC gateway endpoint has the correct policy to access the S3 bucket.Related informationCannotPullContainer task errorsFollow"


Question: How can I verify an Amazon S3 Lifecycle configuration rule for cleaning up incomplete multipart uploads?

I set an Amazon Simple Storage Service (Amazon S3) Lifecycle configuration rule to clean up incomplete multipart uploads. How can I confirm that the rule is working?

Answer: "I set an Amazon Simple Storage Service (Amazon S3) Lifecycle configuration rule to clean up incomplete multipart uploads. How can I confirm that the rule is working?Short descriptionYou can verify the Amazon S3 Lifecycle configuration rule in each of the following ways:Query server access logs.Test the rule by uploading some parts of a multipart upload using the AWS Command Line Interface (AWS CLI).Note: When you use the AWS CLI to set the rule, the rule is called AbortIncompleteMultipartUpload.ResolutionQuery server access logsTo query server access logs, you must have server access logging turned on in your bucket before the S3 Lifecycle rule is set to run. After the logs are available, review the logs to verify if the rule cleaned up an incomplete multipart upload. For more information, see S3 Lifecycle and logging.Test the rule by uploading some parts of a multipart upload using the AWS CLIIf you don't have server access logging turned on, then you can test the rule by running an incomplete multipart upload:Note: The following example uses the AWS CLI to perform a multipart upload. To use an AWS SDK to perform a multipart upload, see Uploading objects using multipart upload API.1.    Split the file that you want to upload into multiple parts. For example, if you're using a Linux operating system, run the split command:split /path/to/filetoupload2.    Run the create-multipart-upload command using the AWS CLI to initiate a multipart upload:aws s3api create-multipart-upload --bucket awsexamplebucket --key large_test_fileNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.The command returns an output that contains the UploadID.3.    Copy the UploadID value as a reference for later steps. The command output looks like this:{    "AbortDate": "Mon, 03 Jun 2019 00:00:00 GMT",    "AbortRuleId": "multipartcleanup",    "Bucket": "awsexamplebucket",    "Key": "objectname",    "UploadId": "exampleTUVGeKAk3Ob7qMynRKqe3ROcavPRwg92eA6JPD4ybIGRxJx9R0VbgkrnOVphZFK59KCYJAO1PXlrBSW7vcH7ANHZwTTf0ovqe6XPYHwsSp7eTRnXB1qjx40Tk"}4.    Run the upload-part command to upload the first part of the file:aws s3api upload-part --bucket awsexamplebucket --key large_test_file --part-number 1 --body large_test_file.001 --upload-id exampleTUVGeKAk3Ob7qMynRKqe3ROcavPRwg92eA6JPD4ybIGRxJx9R0VbgkrnOVphZFK59KCYJAO1PXlrBSW7vcH7ANHZwTTf0ovqe6XPYHwsSp7eTRnXB1qjx40TkNote: Replace all values with your Amazon S3 bucket, file, and multipart upload values.The command returns an output that contains an ETag value for the part of the file that you uploaded.5.    Copy the ETag value as a reference for later steps. The command output looks like the following:{    "ETag": "\"example8be9a0268ebfb8b115d4c1fd3\""}6.    Repeat steps 3 and 4 for some parts of the file. For this test, don't upload all parts to complete the file.Note: Increase the part number with each new part that you upload.7.    For this test, don't complete or abandon the multipart upload operation. Instead, note the parts that were uploaded by running the list-parts command:aws s3api list-parts --bucket awsexamplebucket --key large_test_file --upload-id exampleTUVGeKAk3Ob7qMynRKqe3ROcavPRwg92eA6JPD4ybIGRxJx9R0VbgkrnOVphZFK59KCYJAO1PXlrBSW7vcH7ANHZwTTf0ovqe6XPYHwsSp7eTRnXB1qjx40TkThe command returns a list of the parts:{    "Parts": [        {            "PartNumber": 1,            "LastModified": "2019-06-01T18:17:39.000Z",            "ETag": "\"example8be9a0268ebfb8b115d4c1fd3\"",            "Size": 162641        },        {            "PartNumber": 2,            "LastModified": "2019-06-01T18:18:19.000Z",            "ETag": "\"example246e31ab807da6f62802c1ae8\"",            "Size": 3961        }    ],    "Initiator": {        "ID": "arn:aws:iam::111122223333:user/jane",        "DisplayName": "jane"    },    "Owner": {        "DisplayName": "bucketowner",        "ID": "examplea2395fe1985ffabfe0c17d3522e5bc7fa1a2d048f8fc764d7709da80d"    },    "StorageClass": "STANDARD"}8.    Identify the multipart uploads that are in progress for your bucket by running the list-multipart-uploads command:aws s3api list-multipart-uploads --bucket awsexamplebucketThe command returns a list of in-progress multipart uploads:{    "Uploads": [        {            "UploadId": "exampleTUVGeKAk3Ob7qMynRKqe3ROcavPRwg92eA6JPD4ybIGRxJx9R0VbgkrnOVphZFK59KCYJAO1PXlrBSW7vcH7ANHZwTTf0ovqe6XPYHwsSp7eTRnXB1qjx40Tk",            "Key": "large_test_file",            "Initiated": "2019-06-01T17:08:33.000Z",            "StorageClass": "STANDARD",            "Owner": {                "DisplayName": "bucketowner",                "ID": "examplea2395fe1985ffabfe0c17d3522e5bc7fa1a2d048f8fc764d7709da80d"            },            "Initiator": {                "ID": "arn:aws:iam::111122223333:user/jane",                "DisplayName": "jane"            }        }    ]}9.    Wait the number of days that you set for your S3 Lifecycle configuration rule. (In your S3 Lifecycle configuration rule, you specified how many days after the start of a multipart upload the cleanup starts.)10.    Run the list-parts command again to see if the parts of the incomplete multipart upload were deleted. After the parts are deleted by the rule, the command returns the following response:"An error occurred (NoSuchUpload) when calling the ListParts operation: The specified upload does not exist. The upload ID may be invalid, or the upload may have been aborted or completed."11.    Run the list-multipart-uploads command again to see if the multipart operation was abandoned. After the multipart operation is abandoned by the rule, the command returns no output.Related informationUploading and copying objects using multipart uploadHow do I use the AWS CLI to perform a multipart upload of a file to Amazon S3?Follow"


Question: How do I create a new Windows WorkSpace image with a client language other than English?

"I set the source WorkSpace language settings in Amazon WorkSpaces to a language other than English. Then, I created an image from that WorkSpace. When I launch a new WorkSpace from the resulting image bundle, the language reverts to English (US). How can I set the client language for my WorkSpace to use a different language?"

Answer: "I set the source WorkSpace language settings in Amazon WorkSpaces to a language other than English. Then, I created an image from that WorkSpace. When I launch a new WorkSpace from the resulting image bundle, the language reverts to English (US). How can I set the client language for my WorkSpace to use a different language?ResolutionWorkSpaces bundles that provide the Windows 10 desktop experience support English (US), French (Canadian), Korean, and Japanese. You can also download and install language packs for Windows directly from Microsoft. WorkSpaces client applications support English (US), German, Chinese (Simplified), Japanese, French (Canadian), Korean, and Portuguese.To successfully configure a different language for a WorkSpace image, you must modify the Sysprep language parameters before you create the image.From the source WorkSpace, modify the language parameters in a specified XML file. For a WorkSpace without bring your own license (BYOL), the file path is C:\ProgramData\Amazon\EC2-Windows\Launch\Sysprep\unattend.xml. For a BYOL WorkSpace, the file path is C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml.The language parameters are:<InputLocale>en-US</InputLocale><SystemLocale>en-US</SystemLocale><UILanguage>en-US</UILanguage><UserLocale>en-US</UserLocale>Replace en-US with the language/region tag for your chosen language. (For example, enter de-DE for German). For a complete list of available languages and the associated language/region tag, see Available languages for Windows on the Microsoft website.Create a custom WorkSpace image and bundle from the source WorkSpace. When you launch a new WorkSpace from the resulting image bundle, the WorkSpace is set to your chosen language.Related informationRequirements to create Windows custom imagesAmazon WorkSpaces FAQsFollow"


Question: What should I do if I didn't receive a call from AWS to verify my new account or the PIN I entered doesn't work?

"I'm trying to open a new AWS account. When I reach the phone verification step, I don't receive an SMS message or call from AWS, or the PIN I entered was rejected. What do I do?"

Answer: "I'm trying to open a new AWS account. When I reach the phone verification step, I don't receive an SMS message or call from AWS, or the PIN I entered was rejected. What do I do?ResolutionVerify the following:You've entered your telephone number and selected your country code correctly during the sign-up process.If you're using a mobile phone, then be sure that you have a cellular signal to receive SMS messages or calls.The information that you entered for your payment method is correct. A valid payment method is required to complete the account activation.Double-check to be sure that the PIN that you entered is correct.If you entered the number into your phone's keypad, try speaking the numbers instead.Retry the phone verification.If you're still not able to complete the verification process, then AWS Support can help you to activate your account manually:Be sure that you can be reached at the telephone number that you provided for your AWS account.Open the AWS Support console, and then choose Create case.Choose Account and billing support.For Type, select Account.For Category, select Activation.In the Description section, provide a date and time when you can be reached.In the Contact options section, select Chat for Contact methods.Choose Submit.Note: You can create a case with AWS Support even if your account isn't yet activated.Related informationHow do I create and activate a new AWS account?How do I resolve the "maximum number of failed attempts" error when I try to verify my AWS account by phone?Follow"


Question: How do I troubleshoot errors with cross-account dashboard sharing in CloudWatch?

I want to share my Amazon CloudWatch dashboard with another AWS account using cross-account dashboard sharing. How can I troubleshoot and resolve errors I receive when using cross-account dashboard sharing?

Answer: "I want to share my Amazon CloudWatch dashboard with another AWS account using cross-account dashboard sharing. How can I troubleshoot and resolve errors I receive when using cross-account dashboard sharing?Short descriptionYou can create cross-account or cross-Region dashboards to share your CloudWatch data with multiple AWS accounts and across multiple AWS Regions. There are a number of reasons that you might run into issues when sharing a dashboard created in one account with another account using Account or Organization IDs. You might experience one of the following issues:The monitoring account user can't view or select the Account ID in the sharing account to view the dashboard.The monitoring user receives an error similar to the following when accessing the dashboard due to permissions issues in the sharing account:Failed to retrieve alarms errorsResource groups could not be retrieved errorsUnauthorized user errorsResolutionIn these examples, one account is sharing a dashboard with another account using Account IDs or Organization IDs. The sharing account has the ID 111111111111. The monitoring account has the account ID 999999999999.Issues viewing the Account ID to view a dashboard from a monitoringTo view and select the dashboard that's being shared, you must enable an account selector for every AWS Identity and Access Management (IAM) user in the monitoring account. Account ID selectors are only visible for IAM users who have enabled an account selector in their CloudWatch settings. For more information on enabling an account selector in CloudWatch, see Enabling cross-account functionality in CloudWatch.Errors received when accessing custom dashboards from a monitoring accountYou might encounter an errors when you attempt to access a custom dashboard from a monitoring account.When accessing the Overview page in the CloudWatch console:"Failed to retrieve alarms ; You don't have permissions to perform the following operations: CloudWatch:DescribeAlarms. Contact your administrator if you need help. If you are an administrator, you can provide permissions for your users or groups by creating IAM policies."When accessing the cross service dashboard from shared accounts::"Unable to select any Resource Group in the "Filter by resource group" dropdown. It errs out with : "Resource groups could not be retrieved"When opening a custom dashboard from a shared account:"User: "arn:aws:sts::999999999999:assumed-role/AWSServiceRoleForCloudWatchCrossAccount/CloudWatchConsole is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/CloudWatch-CrossAccountSharingRole"or"User: arn:aws:sts::999999999999:assumed-role/CloudWatch-CrossAccountSharingRole/CloudWatchConsole is not authorized to perform: cloudwatch:ListDashboards on resource: arn:aws:cloudwatch::111111111111:dashboard/* because no identity-based policy allows the cloudwatch:ListDashboards action"These errors occur because there are permissions issues in the role that was created in the sharing account. Be sure that the sharing account follows these criteria:The CloudWatch-CrossAccountSharingRole is present.The sharing account has the correct trust policies, as detailed in Enabling cross-account functionality in CloudWatch.The CloudWatch-CrossAccountSharing role has these policies attached:CloudWatchReadOnlyAccessCloudWatchAutomaticDashboardsAccess - This policy is missing if you cleared the Include CloudWatch automatic dashboards option during dashboard sharing.AWSXrayReadOnlyAccess - This policy is missing if you cleared the Include X-Ray read-only access for ServiceLens option during dashboard sharing.Limit users from a monitoring account to access specific dashboardsTo list all dashboards from cross-account dashboards, use the ListDashboards API call. However, the ListDashboards API doesn't support resource-specific permissions. But the GetDashboard API call does support resource-specific permissions, so you can limit the dashboards that can be described or opened across accounts.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": "cloudwatch:GetDashboard",      "Resource": "arn:aws:cloudwatch::111111111111:dashboard/dashboard-name"    },    {      "Sid": "VisualEditor1",      "Effect": "Allow",      "Action": [        "autoscaling:Describe*",        "cloudwatch:Describe*",        "cloudwatch:GetMetricData",        "cloudwatch:GetMetricStatistics",        "cloudwatch:GetInsightRuleReport",        "cloudwatch:GetMetricWidgetImage",        "cloudwatch:ListMetrics",        "cloudwatch:ListTagsForResource",        "cloudwatch:ListDashboards",        "logs:Get*",        "logs:List*",        "logs:StartQuery",        "logs:StopQuery",        "logs:Describe*",        "logs:TestMetricFilter",        "logs:FilterLogEvents",        "sns:Get*",        "sns:List*"      ],      "Resource": "*"    }  ]}After running this command, you can list all dashboards. But, if you try to open a dashboard that isn't mentioned in this policy, you see an error such as:User: arn:aws:sts::111111111111:assumed-role/CloudWatch-CrossAccountSharingRole/CloudWatchConsole is not authorized to perform: cloudwatch:GetDashboard on resource: arn:aws:cloudwatch::111111111111:dashboard/testIssues launching CloudFormationStack to create the required CloudWatch-CrossAccountSharingRole in the sharing accountBe sure that you have these policies associated with the IAM role in the sharing account when you use cross-account dashboard sharing:AWSCloudFormationFullAccessIAMFullAccessThese permissions allow you to launch the required CloudFormationStack API to create the IAM roles you need for cross-account dashboard sharing.Use Terraform/CloudFormation/AWS CLI to create cross-account dashboard sharing setupWhen you set up a sharing account to use cross-account functions, CloudWatch deploys an AWS CloudFormation template. Convert this CloudFormation template into a corresponding Terraform template. This allows you to enable cross-account data sharing.To allow your monitoring account to view cross-account data in CloudWatch, enable an account selector using the console. This is a per-user setting and isn't managed at account level. For more information on configuring this setting, see Enabling cross-account functionality in CloudWatch.Related informationCross-account cross-Region CloudWatch consoleFollow"


Question: Why does my EBS volume have a status of "error"?

"My Amazon Elastic Block Store (Amazon EBS) volume has a status of error. Why is this, and what can I do to fix it?"

Answer: "My Amazon Elastic Block Store (Amazon EBS) volume has a status of error. Why is this, and what can I do to fix it?Short descriptionThe error status indicates that the underlying hardware related to your EBS volume has failed. The data associated with the volume is unrecoverable and Amazon EBS processes the volume as lost. A notification appears on your account's Personal Health Dashboard when a volume enters an error state.Note: AWS doesn't bill for volumes with a status of error.ResolutionIt’s a best practice to keep backups of your EC2 resources, including EBS volumes. You can use Amazon Data Lifecycle Manager, AWS Backup, or regular EBS snapshots for maintaining regular backups of your critical volumes to avoid data loss. For more information, see Best practices for Amazon EC2.Although you can't recover a volume in an error state, you can restore the lost data from your backup:If you have an EBS snapshot of the volume, you can restore that volume from your snapshot.If you don't have an EBS snapshot of the volume, create a new EBS volume, and then restore the data to it using the manual backup solution you prefer.Note: If the volume in an error state is attached to an Amazon Elastic Compute Cloud (Amazon EC2), you might get an error when starting the instance.Related informationAmazon EBS volumesDurability and availabilityFollow"


Question: How can I review NUMA statistics for my workload running on EC2 instances?

I'm running my workload on Amazon Elastic Compute Cloud (Amazon EC2) Nitro-based instances. I want to review performance and non-uniform memory access (NUMA) statistics.

Answer: "I'm running my workload on Amazon Elastic Compute Cloud (Amazon EC2) Nitro-based instances. I want to review performance and non-uniform memory access (NUMA) statistics.Short descriptionThe following factors affect the performance of an application that's hosted on an EC2 instance:CPU over utilizationMemory useThe EBS volumeNetwork statisticsNot NUMA awareIn NUMA architecture, each CPU has access to its own assigned memory, known as local memory. Each CPU can also access memory that's allocated to other CPUs, known as foreign memory. If applications hosted on your instances aren't NUMA aware, then accessing the foreign memory incurs additional costs and might affect performance. Contact the application vendor to check if your application is NUMA aware.ResolutionReview NUMA statisticsNote: To review performance components other than NUMA statistics, see How do I troubleshoot slow connections to a website hosted on my EC2 instance?To review NUMA statistics, complete the following steps:1.    Run the following command to check if the instance type is in a single NUMA or multi-NUMA node.Note: The instance type is r5.16xlarge has 2 NUMA nodes.lscpu | grep -i numaNUMA node(s): 22.    Run the following command to install the numactl package:sudo yum install numactl 3.    Run the following command to review the NUMA topology:sudo numactl -HIn the following example output the NUMA topology is divided into two nodes, node 0 and node 1. Node 0 has 32 CPUs and 255,225 MB of memory assigned to it. Node 1 has the other half of the CPUs and 254,924 MB of assigned memory. The node distance indicates the latencies in accessing memory pages from the other node.available: 2 nodes (0-1)node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47node 0 size: 255140 MBnode 0 free: 254794 MBnode 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63node 1 size: 255225 MBnode 1 free: 254924 MBnode distances:node   0   10:  10  211:  21  104.    Run the following command to review the NUMA statistics:sudo numastatThe following is an example of the command output:node                       node0           node1numa_hit                  314825          288025numa_miss                      0               0numa_foreign                   0               0interleave_hit             37958           37620local_node                311752          248476other_node                  3073           39549For a detailed explanation of each statistic, see A.11. NUMASTAT on the Red Hat Customer Portal.Increases in the numa_foreign and numa_miss statistics might indicate that the application running on the EC2 instance isn't NUMA aware. This might affect performance. To resolve this issue, turn off NUMA at the grub level. Or, try binding the application to the specific NUMA node. For more information, see Operating system optimizations.Permanently turn off NUMA To permanently turn off NUMA on Amazon Linux 2, CentOS7, or RHEL 7, run the following commands:sudo vi /etc/default/grubGRUB_CMDLINE_LINUX_DEFAULT="numa=off"sudo grub2-mkconfig -o /etc/grub2.cfgsudo rebootFollow"