Question: How can I configure access to the EC2 Serial Console of an unreachable or inaccessible Linux instance?

My Amazon Elastic Compute Cloud (Amazon EC2) Linux instance is unreachable or inaccessible. I didn't configure access to the EC2 Serial Console at the OS-level. How can I modify the OS configurations for the EC2 Serial Console and set the password for any OS user to access the instance?

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) Linux instance is unreachable or inaccessible. I didn't configure access to the EC2 Serial Console at the OS-level. How can I modify the OS configurations for the EC2 Serial Console and set the password for any OS user to access the instance?Short descriptionTo configure access to the serial console, do the following:1.    Access the instance's root volume.2.    Set the password for the root user or any other OS user.3.    Check and update the GRUB settings for the Serial Console.Note: You can skip step 3 if the EC2 Serial Console is working properly on the affected instance and you just need to set the password for your OS user.PrerequisitesTo use the serial console, make sure that you met the prerequisites, except for Set an OS user password. Setting a password is discussed in the following resolution.ResolutionAccess the instance's root volume using a rescue instanceCreate a temporary rescue instance, and then remount your Amazon Elastic Block Store (Amazon EBS) volume on the rescue instance. From the rescue instance, you can check and modify the GRUB settings for the serial console. You can also set the password for the root user or any other OS user.Important: Don't perform this procedure on an instance store-backed instance. Because the recovery procedure requires a stop and start of your instance, any data on that instance is lost. For more information, see Determine the root device type of your instance.1.    Create an EBS snapshot of the root volume. For more information, see Create Amazon EBS snapshots.2.    Open the Amazon EC2 console.Note: Be sure that you're in the correct Region.3.    Select Instances from the navigation pane, and then choose the impaired instance.4.    Choose Instance State, Stop instance, and then select Stop.5.    In the Storage tab, under Block devices, select the Volume ID for /dev/sda1 or /dev/xvda.Note: The root device differs by AMI, but /dev/xvda or /dev/sda1 are reserved for the root device. For example, Amazon Linux 1 and 2 use /dev/xvda. Other distributions, such as Ubuntu 16, 18, CentOS 7, and RHEL 7.5, use /dev/sda1.6.    Choose Actions, Detach Volume, and then select Yes, Detach. Note the Availability Zone.Note: You can tag the EBS volume before detaching it to help identify it in later steps.7.    Launch a rescue EC2 instance in the same Availability Zone.Note: Depending on the product code, you might be required to launch an EC2 instance of the same OS type. For example, if the impaired EC2 instance is a paid RHEL AMI, you must launch an AMI with the same product code. For more information, see Get the product code for your instance.If the original instance is running SELinux (RHEL, CentOS 7 or 8, for example), launch the rescue instance from an AMI that uses SELinux. If you select an AMI running a different OS, such as Amazon Linux 2, any modified file on the original instance has broken SELinux labels.8.    After the rescue instance launches, choose Volumes from the navigation pane, and then choose the detached root volume of the impaired instance.9.    Choose Actions, Attach Volume.10.    Choose the rescue instance ID ( id-xxxxx), and then set an unused device. In this example, /dev/sdf.11.     Use SSH to connect to the rescue instance.12.    Run the lsblk command to view your available disk devices:lsblkThe following is an example of the output:NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTxvda    202:0     0   15G  0 disk└─xvda1 202:1     0   15G  0 part /xvdf    202:0     0   15G  0 disk    └─xvdf1 202:1 0   15G  0 partNote: Nitro-based instances expose EBS volumes as NVMe block devices. The output generated by the lsblk command on Nitro-based instances shows the disk names as nvme[0-26]n1. For more information, see Amazon EBS and NVMe on Linux instances. The following is an example of the lsblk command output on a Nitro-based instance:NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTnvme0n1        259:0    0    8G  0 disk └─nvme0n1p1    259:1    0    8G  0 part /└─nvme0n1p128  259:2    0    1M  0 part nvme1n1        259:3    0  100G  0 disk └─nvme1n1p1    259:4    0  100G  0 part /13.    Run the following command to become root:sudo -i14.    Mount the root partition of the mounted volume to /mnt. In the preceding example, /dev/xvdf1 or /dev/nvme2n1p2 is the root partition of the mounted volume. For more information, see Make an Amazon EBS volume available for use on Linux.Note: In the following example, replace /dev/xvdf1 with the correct root partition for your volume.mount -o nouuid /dev/xvdf1 /mntNote: If /mnt doesn't exist on your configuration, create a mount directory, and then mount the root partition of the mounted volume to this new directory.mkdir /mntmount -o nouuid /dev/xvdf1 /mntYou can now access the data of the impaired instance through the mount directory.15.    Mount /dev, /run, /proc, and /sys of the rescue instance to the same paths as the newly mounted volume:for m in dev proc run sys; do mount -o bind {,/mnt}/$m; doneCall the chroot function to change into the mount directory.Note: If you have a separate /boot and /etc partitions, mount them to /mnt/boot and /mnt/etc before running the following command.chroot /mntSet the password for the root user or any other OS user.Use the passwd command to set the password for your OS user. In the following example, the user is root:passwd rootCheck and update the GRUB settings for the serial console.Note: You can skip this step if the EC2 Serial console is working properly on the affected instance and you just need to set the password for your OS user.The supported serial console port for Linux is ttyS0. If the screen remains black without providing any output when connecting to the EC2 Serial Console, you should make sure that the console entry is properly configured in the GRUB settings. The examples provided below are taken from the AWS Marketplace AMIs for the different distributions in which the serial console is working properly:GRUB2 for Amazon Linux 2, RHEL , and CentOS 71.    Verify that the console entry for the ttyS0 is properly set in the GRUB_CMDLINE_LINUX_DEFAULT line of the /etc/default/grub file:Amazon Linux 2GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"RHEL 7GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"CentOS 7GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto net.ifnames=0 console=ttyS0"2.    If the console entry for the ttyS0 is not set, add it in the GRUB_CMDLINE_LINUX_DEFAULT line. Then update GRUB to regenerate the /boot/grub2/grub.cfg file:grub2-mkconfig -o /boot/grub2/grub.cfgGRUB1 (Legacy GRUB) for Red Hat 6 and Amazon Linux 11.    Verify that the console entry for the ttyS0 is properly set in the kernel line of the /boot/grub/grub.conf file:Amazon Linux 1kernel /boot/vmlinuz-4.14.252-131.483.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295Red Hat 6kernel /boot/vmlinuz-2.6.32-573.el6.x86_64 console=ttyS0 console=ttyS0,115200n8 ro root=UUID=0e6b1614-7bbe-4d6e-bc78-a5556a123ba8 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM2.    If the console entry for the ttyS0 is not set, add it in the /boot/grub/grub.conf file according to the preceding examples.GRUB2 for Ubuntu 16.04, 18.04 and 20.041.    Verify that the console entry for the ttyS0 is properly set in the GRUB_CMDLINE_LINUX_DEFAULT line of the /etc/default/grub.d/50-cloudimg-settings.cfg file:GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295"2.    If the console entry console=ttyS0 is not present**,** add it in the GRUB_CMDLINE_LINUX_DEFAULT line. Then update the GRUB configuration using the following command:update-grubGRUB2 for RHEL 8 and CentOS 81.    Run the grubby --default-kernel command to see the current default kernel:grubby --default-kernel2.    Run the grubby --info=ALL command to see all the available kernels, their indexes, and their args:grubby --info=ALL3.    Verify that the console entry for the ttyS0 is properly set in the args line for the default kernel outlined in the step 1.RHEL 8index=0kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params"root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"CentOS 8index=2kernel="/boot/vmlinuz-4.18.0-193.19.1.el8_2.x86_64"args="ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 nvme_core.io_timeout=4294967295 nvme_core.max_retries=10 crashkernel=auto $tuned_params"root="UUID=b437cbaa-8fe5-49e4-8537-0895c219037a"initrd="/boot/initramfs-4.18.0-193.19.1.el8_2.x86_64.img $tuned_initrd"title="CentOS Linux (4.18.0-193.19.1.el8_2.x86_64) 8 (Core)"id="dc49529e359897df0b9664481b009b1f-4.18.0-193.19.1.el8_2.x86_64"4.    If the console entry for the ttyS0 isn't set, then use the following grubby command to append it to the args of the default kernel:grubby --args console=ttyS0,115200n8 --update-kernel DEFAULTUnmount and detach the root volume from the rescue instance, and then attach the volume to the impaired instance1.    Exit from chroot, and unmount /dev, /run, /proc, and /sys:exitumount /mnt/{dev,proc,run,sys,}2.    From the Amazon EC2 console, choose Instances, and then choose the rescue instance.3.    Choose Instance State, Stop instance, and then select Yes, Stop.4.    Detach the root volume id-xxxxx (the volume from the impaired instance) from the rescue instance.5.    Attach the root volume you detached in step 4 to the impaired instance as the root volume (/dev/sda1), and then start the instance.Note: The root device differs by AMI. The names /dev/xvda or /dev/sda1 are reserved for the root device. For example, Amazon Linux 1 and 2 use /dev/xvda. Other distributions, such as Ubuntu 16, 18, CentOS 7, and RHEL 7.5, use /dev/sda1.Now you can access the OS of the impaired instance through the EC2 Serial Console using the password defined in the previous step for the root or any other OS user.Related informationConfigure GRUBFollow"


Question: What are best practices for securing my Linux server running on Lightsail?

I'm a system administrator for Amazon Lightsail instances running Linux. What are some server security best practices I can use to help protect my data?

Answer: "I'm a system administrator for Amazon Lightsail instances running Linux. What are some server security best practices I can use to help protect my data?ResolutionThe following are basic Linux server security best practices. While these are important considerations for Linux server security, keep in mind that this isn't a complete list. There are many complex settings that should be configured and addressed by your local system administrator team based on your specific requirements and use case.Encrypt data communication to and from your Linux server.Use SCP, SSH, rsync, or SFTP for file transfers. Avoid using services such as FTP, Telnet, and so on, as these aren't secure. To maintain a secure (HTTPS) connection, install and configure an SSL certificate on your server.Minimize software to minimize vulnerability in Linux and perform security audits on a regular basis.Don't install unnecessary software so that you avoid introducing vulnerabilities from software or packages. If possible, identify and remove all unwanted packages.Keep the Linux kernel and software up to date.Applying security patches is an important part of maintaining your Linux server. Linux provides all of the necessary tools to keep your system updated. Linux also allows for easy upgrades between versions. Review and apply all security updates as soon as possible and make sure that you update to the latest available kernel. Use the respective package managers based on your Linux distributions, such as yum, apt-get, or dpkg to apply all security updates.Use Linux security extensions.Linux comes with various security features that you can use to guard against misconfigured or compromised programs. If possible, use SELinux and other Linux security extensions to enforce limitations on network and other programs. For example, SELinux provides a variety of security policies for the Linux kernel.Disable the root login.It's a best practice not to log in as a root user. You should use sudo to run root level commands when required. Sudo greatly enhances the security of the system without sharing the credentials with other users and administrators.Find listening network ports using SS or netstat and close or restrict all other ports.It's important to pay attention to which ports are listening on the system's network interfaces. This can be done through ss or netstat. Any open ports might be evidence of an intrusion.Configure both Lightsail firewall and OS-level firewalls on Linux servers for an additional level of security.Use Lightsail firewall to filter out traffic and allow only necessary traffic to your server. OS-level firewall is a user space application program that allows you to configure the firewalls provided by the Linux kernel. You can use iptables, ufw, firewalld, and so on, depending on your Linux distribution.Use auditd for system accounting.Linux provides auditd for system auditing. Auditd writes audit records to the disk. It also monitors various system activites, such as system logins, authentications, account modifications, and SELinux denials. These records help administrators identify malicious activity or unauthorized access.Install an intrusion detection system (IDS).Use fail2ban or denyhost as an IDS. Fail2ban and denyhost scan the log files for too many failed login attempts and block the IP address that's showing signs of malicious activity.Create backups on a regular basis.For more information, see Snapshots in Amazon Lightsail.Avoid providing read, write, and run Permissions (777) for files and directories to users, groups, and others.You can use chmod to restrict access to files and directories, such as the web-root directory, document-root, and so on. Edit the permissions to provide access to authorized users only.Related informationSecurity in Amazon LightsailCompliance Validation for Amazon LightsailInfrastructure Security in Amazon LightsailBest practices for securing Windows Server-based Lightsail instancesFollow"


Question: How do I view web interfaces that are hosted on Amazon EMR clusters?

I want to access the application user interfaces (UIs) that are on my Amazon EMR cluster.

Answer: "I want to access the application user interfaces (UIs) that are on my Amazon EMR cluster.ResolutionApplications that you install on an Amazon EMR cluster, such as Apache Spark and Apache Hadoop, publish web UIs on the master node. You have several options for accessing these user interfaces, depending on your level of technical expertise. For more information about the options, see View web interfaces hosted on Amazon EMR clusters.Follow"


Question: How can I get my Amazon SNS topic to receive Amazon RDS notifications?

I want my Amazon Simple Notification Service (Amazon SNS) topic to receive Amazon Relational Database Service (Amazon RDS) notifications.

Answer: "I want my Amazon Simple Notification Service (Amazon SNS) topic to receive Amazon Relational Database Service (Amazon RDS) notifications.ResolutionCheck if your SNS topic is encrypted1.    Open the Amazon SNS console.2.    On the navigation panel, choose Topics, and then choose the topic that you want to receive an RDS notification.3.    Choose the Encryption tab.If you see Configured in the Encryption section, then your topic is encrypted. You also see your AWS KMS key (KMS key) and KMS ARN.If your topic is encrypted, grant Amazon RDS the necessary permissions to access the AWS KMS key. For more information, see Turn on compatibility between event sources from AWS services and encrypted topics.Note: For encrypted topics to receive Amazon RDS notifications, you must use an AWS KMS key to encrypt the SNS topic. You must modify the AWS KMS key policy to add the permissions for the operations: kms:GenerateDataKey* and kms:Decrypt.If your topic isn't encrypted, continue to the Validate the access policy of your SNS topic section of this article.Validate the access policy of your SNS topicYour SNS access policy must have permissions to allow Amazon RDS to publish events to your SNS topic.1.    Open the Amazon SNS console.2.    On the navigation panel, choose Topics, and then choose the topic that you want to receive an RDS notification.3.    Choose the Access policy tab.If your SNS access policy doesn't allow Amazon RDS to publish events to your SNS topic, then complete the following steps to update your policy:1.    In the Details section of your topic page, choose Edit.2.    Expand the Access policy section, and then copy and paste the preceding policy into the JSON editor.3.    Choose Save changes.{  "Version": "2012-10-17",  "Id": "SNSAccessPolicy",  "Statement": [    {      "Sid": "PolicyForRDSToSNS",      "Effect": "Allow",      "Principal": {        "AWS": "*"      },      "Action": "SNS:Publish",      "Resource": "your-SNS-topic-ARN",      "Condition": {        "ArnLike": {          "aws:SourceArn": "arn:aws:rds:your-AWS-region:your-AWS-account-ID:*"        }      }    }  ]}Note: Update the placeholder values in the policy with your values.Verify that your RDS event notification has the correct category selected for the type of event you're expectingChoose the right category for the notification that you want. For example, if you want to receive notifications for instance restarts and shutdowns, then select the availability category and instances as the event source. The availability category covers the following events:"RDS-EVENT-0006 : The DB instance restarted""RDS-EVENT-0004 : DB instance shutdown""RDS-EVENT-0022 : An error has occurred while restarting MySQL or MariaDB"Check the configuration of the event subscription:1.    Open the Amazon RDS console.2.    On the navigation panel, choose Event subscriptions, and then choose your event subscription.3.    In the Event subscription details section of your subscription page, note the values in the following fields: Source type, Sources, and Event categories.4.    Choose the correct source and event category for the type of event that fits your use case.Edit the configuration of the event subscription:Note: The following steps assume a scenario where you want to receive notifications for all instance resources and shutdowns. For more information on the different types of supported events and their categories, see Amazon RDS event categories and event messages.1.    On the navigation panel of the Amazon RDS console, choose Event subscriptions, and then choose your event subscription.2.    On your subscription page, choose Actions, Edit.3.    In the Source section, for Source Type, select Instances.4.    For Instances to include, select All instances.5.    For Event categories to include, select Select specific event categories.6.    For Specific event categories, select availability.7.    Choose Save.Related informationEncrypting messages published to Amazon SNS with AWS KMSFollow"


Question: "How do I check EKS Anywhere cluster component logs on primary and worker nodes for BottleRocket, Ubuntu, or Redhat?"

I want to check the component logs when the creation of a control plane or data plane machines fails in Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere.

Answer: "I want to check the component logs when the creation of a control plane or data plane machines fails in Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere.Short descriptionDuring the creation of an Amazon EKS Anywhere workload cluster, you can check the logs for each machine in the control plane, etcd, and data plane.To check the component logs in each machine, the following conditions must be met:EKS Anywhere is trying to create a workload cluster, and each machine is in the process of creation.Each machine allows you to log in through SSH on the control plane, etcd, and data plane.ResolutionCheck the status of each machine with the $ kubectl get machines command.Example management cluster:$ kubectl get machines -ANAMESPACE     NAME                         CLUSTER   NODENAME      PROVIDERID                                       PHASE     AGE     VERSIONeksa-system   mgmt-etcd-bwnfq              mgmt                    vsphere://4230b0d5-7b14-4753-bd41-3dbe4987dbc4   Running   5h26meksa-system   mgmt-etcd-bzm77              mgmt                    vsphere://4230b278-1fb4-f539-0afe-9f12afebf86b   Running   5h26meksa-system   mgmt-etcd-dzww2              mgmt                    vsphere://42309b5a-b0ad-58a5-1e40-5fe39a3d1640   Running   5h26meksa-system   mgmt-jw8dl                   mgmt      10.4.11.19    vsphere://42304059-c833-48d3-9856-7f902c852743   Running   5h26m   v1.24.9-eks-1-24-7eksa-system   mgmt-md-0-66b858b477-6cbcz   mgmt      10.4.35.76    vsphere://4230efad-5d42-c570-36c5-bf9ee92ee011   Running   5h26m   v1.24.9-eks-1-24-7eksa-system   mgmt-md-0-66b858b477-8h88c   mgmt      10.4.19.38    vsphere://4230edbf-db9b-3ae9-a2e6-8421e06863fb   Running   5h26m   v1.24.9-eks-1-24-7eksa-system   mgmt-s7fb7                   mgmt      10.4.67.152   vsphere://42301d6f-feb1-d967-9750-148d0823c7b5   Running   5h26m   v1.24.9-eks-1-24-7After you check your machines' statuses and verify that you can check their component logs, log in to each machine through SSH. In the following example, user is the SSH login user that's specified in each provider's MachineConfig:$ ssh -i private_key_file user@Machine_IP_addressDepending on your machine's operating system (OS), follow the relevant steps to check its component logs.Note: The control plane section refers to a machine with a name that has the cluster name prefix ("cluster_name-"). The etcd section refers to a machine with a name that has the cluster name and etcd prefix ("cluster_name-etcd-"). The data plane section refers to a machine with a name that has the cluster name and worker node name prefix ("cluster_name-worker_node_name-"). Depending on the ClusterConfig settings, etcd might not have a dedicated machine and instead starts on the control plane.Machines with BottleRocket OSWhen you log in with SSH, you also log in to the admin container. For debugging purposes, obtain root privileges with the following command before you check the logs:$ sudo sheltiecontrol planeFor the kubelet log, run the following command:# journalctl -u kubelet.service --no-pagerFor the containerd log, run the following command:# journalctl -u containerd.service --no-pagerFor the machine initialization log, run the following command:# journalctl _COMM=host-ctr --no-pagerFor each container log, check the logs in the /var/log/containers directory.For Kubernetes kube-apiserver, kube-controller-manager, kube-scheduler, and kube-vip manifests, check the files in the /etc/kubernetes/manifest directory.etcdFor the containerd log, run the following command::# journalctl -u containerd.service --no-pagerFor the machine initialization log, run the following command::# journalctl _COMM=host-ctr --no-pagerFor the etcd log, look in the /var/log/containers directory.data planeFor the kubelet log, run the following command:# journalctl -u kubelet.service --no-pagerFor the containerd log, run the following command:# journalctl -u containerd.service --no-pagerFor the machine initialization log, run the following command:# journalctl _COMM=host-ctrFor each container log, check the logs in the /var/log/containers directory.Note: If you use AWS Snow as your provider, then also check the results of the following commands on each node:# journalctl -u bootstrap-containers@bottlerocket-bootstrap-snow.service# systemctl status bootstrap-containers@bottlerocket-bootstrap-snowMachines with Ubuntu or Red Hat Enterprise Linux OSFor debugging purposes, obtain root privileges with the following command before you check the logs:$ sudo su -control planeFor the kubelet log, run the following command:# journalctl -u kubelet.service --no-pagerFor the containerd log, run the following command:# journalctl -u containerd.service --no-pagerFor the machine initialization log, run the following command:# cat /var/log/cloud-init-output.logFor each container log, check the logs in the /var/log/containers directory.For userdata that initiates when the machine starts, run the following command:# cat /var/lib/cloud/instance/user-data.txtFor Kubernetes kube-apiserver, kube-controller-manager, kube-scheduler, and kube-vip manifests, check the files in the /etc/kubernetes/manifest directory.etcdFor the etcd log, run the following command:# journalctl -u etcd.service --no-pagerFor the machine initialization log, run the following command:# cat /var/log/cloud-init-output.logFor user data that initiates when the machine starts, run the following command:# cat /var/lib/cloud/instance/user-data.txtdata planeFor the kubelet log, run the following command:# journalctl -u kubelet.service --no-pagerFor the containerd log, run the following command:# journalctl -u containerd.service --no-pagerFor the machine initialization log, run the following command:# cat /var/log/cloud-init-output.logFor user data that initiates when the machine starts, run the following command:cat /var/lib/cloud/instance/user-data.txtFor each container log, check the logs in the /var/log/containers directory.Follow"


Question: Can I switch my ACM certificate’s validation method?

I want to change the validation method for my AWS Certificate Manager (ACM) certificate. How do I do that?

Answer: "I want to change the validation method for my AWS Certificate Manager (ACM) certificate. How do I do that?Short descriptionAfter submitting a certificate request with ACM, it's not possible to change the validation method.ResolutionIf you want to switch the ACM certificate validation method, you must request a new certificate for the same domain using your preferred validation method. After your new certificate is issued, associate it to the resources used with the previous certificate.For more information on requesting a new certificate, see Request a public certificate.Note: DNS validation has several advantages over email validation, especially if Amazon Route 53 is the DNS provider for your domain. For more information, see Using DNS to validate domain ownership.To identify which resources the previous ACM certificate was associated with, see Describe ACM Certificates.For replacing your ACM certificate on your load balancer or Amazon CloudFront distribution, see:Update an HTTPS listener for your Application Load BalancerReplace the SSL certificate for your Classic Load BalancerUpdate a TLS listener for your Network Load BalancerRotating SSL/TLS certificatesRelated informationWhy am I not receiving validation emails when using ACM to issue or renew a certificate?Why is my AWS Certificate Manager (ACM) certificate DNS validation status still pending validation?Follow"


Question: How do I troubleshoot fine-grained access control issues in my OpenSearch Service cluster?

I'm experiencing access control errors or issues in my Amazon OpenSearch Service cluster.

Answer: "I'm experiencing access control errors or issues in my Amazon OpenSearch Service cluster.Short descriptionYou might receive fine-grained access control (FGAC) errors, or require additional configuration in your OpenSearch Service cluster. To resolve these issues, follow these troubleshooting steps for your use case.Note: Because of the managed design of OpenSearch Service, anonymous access isn't supported.Resolution"security_exception","reason":"no permissions" 403 errorsTo resolve this error, first check if the user or backend role in your OpenSearch Service cluster has the required permissions. See Permissions on the OpenSearch website. Then, complete the steps from the OpenSearch website to map the user or backend role to a role."User: anonymous is not authorized to perform: iam:PassRole"You might receive this error when you try to register a manual snapshot. You must map the manage_snapshots role to Identity and Access Management (IAM) role that you used to register the manual snapshot. Then, use that IAM role to send a signed request to the domain."Couldn't find any Elasticsearch data"You might receive this error when you try to create index patterns after upgrading to OpenSearch Service version 7.9. Use the resolve index API to add indices:admin/resolve/index to all indices and aliases when creating an index pattern in an FGAC activated cluster. For more information, see API on the OpenSearch website.When this permission is missing, OpenSearch Service throws a 403 error status code. This is then mapped to a 500 error status code from OpenSearch Dashboards. As a result, the indices aren't listed.401 unauthorized errorsYou might receive a 401 unauthorized error when you use the $ or ! characters in primary credentials with curl -u "user:password". Make sure to put your credentials in single quotes, as in the following example:curl -u 'username' <Domain_Endpoint>Integrate other AWS services with OpenSearch Service when fine-grained access control is activatedTo integrate another AWS service with OpenSearch Service when fine-grained access control is activated, give the correct permissions to the IAM roles for those services. For more information, see Integrations.Provide fine-grained access to specific indices, dashboards, and visualizations based on user tenancyTo provide FGAC access to specific indices or dashboards, map the user to a role that has permissions to the tenant's Kibana index:.kibana_<hash>_<tenant_name>For more information, see Manage OpenSearch Dashboards indices on the OpenSearch website.Use fine-grained access control at a field-level or document-levelTo use fine-grained access control at the field level, set up a role with the required field-level security. Then, map the user to the role that you created. For more information, see Field-level security on the OpenSearch website.To use fine-grained access control at the document level, create an internal dashboard role with the required document-level security. Then, map the user to the internal dashboard. For more information, see Document-level security on the OpenSearch website.Related informationFine-grained access control in Amazon OpenSearch ServiceFollow"


Question: How do I install a software package from the Extras Library on an EC2 instance running Amazon Linux 2?

How do I install a software package (known as a topic) from the amazon-linux-extras repository on an Amazon Elastic Compute Cloud (Amazon EC2) instance that's running Amazon Linux 2?

Answer: "How do I install a software package (known as a topic) from the amazon-linux-extras repository on an Amazon Elastic Compute Cloud (Amazon EC2) instance that's running Amazon Linux 2?Short descriptionTo install a software package from the Extras Library, first confirm that the amazon-linux-extras repository is installed on your instance. Then, list the available software packages, enable the one you're looking for, and then install the package using yum.Note: This resolution is for Amazon Linux 2. These steps don't apply to Amazon Linux 1 2018.03.Resolution1.    Connect to your EC2 Linux instance using SSH.2.    Use the which command to confirm that the amazon-linux-extras package is installed:$ which amazon-linux-extras/usr/bin/amazon-linux-extrasIf the amazon-linux-extras package isn't installed, use yum to install it:$ sudo yum install -y amazon-linux-extras3.    List the available topics.Note: The repository is updated regularly, so the topics and versions that you see might differ from the following list.$ amazon-linux-extras0  ansible2                 available    [ =2.4.2  =2.4.6 ]2  httpd_modules            available    [ =1.0 ]3  memcached1.5             available    [ =1.5.1 ]4  nginx1.12                available    [ =1.12.2 ]5  postgresql9.6            available    [ =9.6.6  =9.6.8 ]6  postgresql10             available    [ =10 ]8  redis4.0                 available    [ =4.0.5  =4.0.10 ]9  R3.4                     available    [ =3.4.3 ]10  rust1                   available    [ =1.22.1  =1.26.0  =1.26.1  =1.27.2  =1.31.0 ]11  vim                     available    [ =8.0 ]13  ruby2.4                 available    [ =2.4.2  =2.4.4 ]15  php7.2                  available    [ =7.2.0  =7.2.4  =7.2.5  =7.2.8  =7.2.11  =7.2.13  =7.2.14 =7.2.16 ]16  php7.1                  available    [ =7.1.22  =7.1.25  =7.1.27 ]17  lamp-mariadb10.2-php7.2 available    [ =10.2.10_7.2.0 =10.2.10_7.2.4 =10.2.10_7.2.5 =10.2.10_7.2.8 =10.2.10_7.2.11 =10.2.10_7.2.13 =10.2.10_7.2.14 =10.2.10_7.2.16 ]18  libreoffice             available    [ =5.0.6.2_15  =5.3.6.1 ]19  gimp                    available    [ =2.8.22 ]20  docker=latest           available    [ =17.12.1  =18.03.1  =18.06.1 ]21  mate-desktop1.x         available    [ =1.19.0  =1.20.0 ]22  GraphicsMagick1.3       available    [ =1.3.29 ]23  tomcat8.5               available    [ =8.5.31  =8.5.32  =8.5.38 ]24  epel                    available    [ =7.11 ]25  testing                 available    [ =1.0 ]26  ecs                     available    [ =stable ]27  corretto8               available    [ =1.8.0_192  =1.8.0_202 ]28  firecracker             available    [ =0.11 ]29  golang1.11              available    [ =1.11.3 ]30  squid4                  available    [ =4 ]31  php7.3                  available    [ =7.3.2  =7.3.3 ]32  lustre2.10              available    [ =2.10.5 ]33  java-openjdk11          available    [ =11 ]34  lynis                   available    [ =stable ]4.    Enable the desired topic. The output shows the commands required for installation. For example, to enable the PHP 7.2 topic, use the following command:$ sudo amazon-linux-extras enable php7.20  ansible2                 available    [ =2.4.2 =2.4.6 ]2  httpd_modules            available    [ =1.0 ]3  memcached1.5             available    [ =1.5.1 ]4  nginx1.12                available    [ =1.12.2 ]5  postgresql9.6            available    [ =9.6.6 =9.6.8 ]6  postgresql10             available    [ =10 ]8  redis4.0                 available    [ =4.0.5 =4.0.10 ]9  R3.4                     available    [ =3.4.3 ]10  rust1                   available    [ =1.22.1 =1.26.0 =1.26.1 =1.27.2 =1.31.0 ]11  vim                     available    [ =8.0 ]13  ruby2.4                 available    [ =2.4.2 =2.4.4 ]15  php7.2=latest           enabled      [ =7.2.0 =7.2.4 =7.2.5 =7.2.8 =7.2.11 =7.2.13 =7.2.14 =7.2.16 ]_   php7.1                  available    [ =7.1.22  =7.1.25  =7.1.27 ]17  lamp-mariadb10.2-php7.2 available    [ =10.2.10_7.2.0  =10.2.10_7.2.4 =10.2.10_7.2.5 =10.2.10_7.2.8 =10.2.10_7.2.11 =10.2.10_7.2.13 =10.2.10_7.2.14 =10.2.10_7.2.16 ]18  libreoffice             available    [ =5.0.6.2_15  =5.3.6.1 ]19  gimp                    available    [ =2.8.22 ]20  docker=latest           available    [ =17.12.1  =18.03.1  =18.06.1 ]21  mate-desktop1.x         available    [ =1.19.0  =1.20.0 ]22  GraphicsMagick1.3       available    [ =1.3.29 ]23  tomcat8.5               available    [ =8.5.31  =8.5.32  =8.5.38 ]24  epel                    available    [ =7.11 ]25  testing                 available    [ =1.0 ]26  ecs                     available    [ =stable ]27  corretto8               available    [ =1.8.0_192  =1.8.0_202 ]28  firecracker             available    [ =0.11 ]29  golang1.11              available    [ =1.11.3 ]30  squid4                  available    [ =4 ]_   php7.3                  available    [ =7.3.2  =7.3.3 ]32  lustre2.10              available    [ =2.10.5 ]33  java-openjdk11          available    [ =11 ]34  lynis                   available    [ =stable ]Now you can install: # yum clean metadata # yum install php-cli php-pdo php-fpm php-json php-mysqlnd5.    Install the topic using yum. For example, to install the PHP 7.2 topic, use the following command:$ sudo yum clean metadata && sudo yum install php-cli php-pdo php-fpm php-json php-mysqlnd6.    Use the following commands to verify the installation and confirm the software version:$ yum list installed php-cli php-pdo php-fpm php-json php-mysqlndLoaded plugins: extras_suggestions, langpacks, priorities, update-motdInstalled Packagesphp-cli.x86_64                                                   7.2.16-1.amzn2.0.1                                                @amzn2extra-php7.2php-fpm.x86_64                                                   7.2.16-1.amzn2.0.1                                                @amzn2extra-php7.2php-json.x86_64                                                  7.2.16-1.amzn2.0.1                                                @amzn2extra-php7.2php-mysqlnd.x86_64                                               7.2.16-1.amzn2.0.1                                                @amzn2extra-php7.2php-pdo.x86_64                                                   7.2.16-1.amzn2.0.1                                                @amzn2extra-php7.2        $ which php/usr/bin/php        $ php --versionPHP 7.2.16 (cli) (built: Apr  3 2019 18:39:35) ( NTS )Copyright (c) 1997-2018 The PHP GroupZend Engine v3.2.0, Copyright (c) 1998-2018 Zend TechnologiesRelated informationAmazon Linux 2Follow"


Question: Why can't I access a specific folder or file in my Amazon S3 bucket?

I can't access a certain prefix or object that's in my Amazon Simple Storage Service (Amazon S3) bucket. I can access the rest of the data in the bucket. How can I fix this?

Answer: "I can't access a certain prefix or object that's in my Amazon Simple Storage Service (Amazon S3) bucket. I can access the rest of the data in the bucket. How can I fix this?Short descriptionCheck the following permissions for any settings that are denying your access to the prefix or object:Ownership of the prefix or objectRestrictions in the bucket policyRestrictions in your AWS Identity and Access Management (IAM) user policyPermissions to object encrypted by AWS Key Management Service (AWS KMS)Also, note the following:If the object is encrypted using an AWS managed KMS key, only the AWS account that encrypted the object can read it.If permissions boundaries and sessions policies are defined, the maximum permissions of the requester can be impacted. As a result, there might also be impact to object access.Restrictions might be specified in other policies such as VPC endpoint policies and service control policies (SCPs). Therefore, check these policies and update them accordingly.You can also control ownership of uploaded objects using Amazon S3 Object Ownership. If Object Ownership is set to "BucketOwnerPreferred", objects that are newly written by other accounts with the bucket-owner-full-control canned ACL transition to the bucket owner.ResolutionOwnership of the prefix or objectBy default, an S3 object is owned by the AWS account that uploaded it. This is true even when the bucket is owned by another account. If other accounts can upload to your bucket, follow these steps to get permissions to the object or prefix that you can't access:1.    Run this AWS Command Line Interface (AWS CLI) command to get the Amazon S3 canonical ID for your account:aws s3api list-buckets --query Owner.IDNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.2.    Run this command to get the Amazon S3 canonical ID of the account that owns the object you can't access:aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix index.html3.    If the canonical IDs don't match, then you (the bucket owner) don't own the object. For an individual object, the object owner can grant you full control by running this put-object-acl command:aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name --acl bucket-owner-full-controlFor objects within a prefix, the object owner must re-copy the prefix and grant you full control of the objects as part of the operation. For example, the object owner can run this cp command with the --acl bucket-owner-full-control parameter:aws s3 cp s3://DOC-EXAMPLE-BUCKET/abc/ s3://DOC-EXAMPLE-BUCKET/abc/ --acl bucket-owner-full-control --recursive --storage-class STANDARDTip: You can use a bucket policy to require that other accounts grant you ownership of objects they upload to your bucket.Restrictions in the bucket policy1.    Open the Amazon S3 console.2.    From the list of buckets, open the bucket with the policy that you want to review.3.    Choose the Permissions tab.4.    Choose Bucket policy.5.    Search for statements with "Effect": "Deny". Then, review those statements for references to the prefix or object that you can't access.For example, this bucket policy denies everyone access to the abc/* prefix in DOC-EXAMPLE-BUCKET:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "StatementPrefixDeny",            "Effect": "Deny",            "Principal": {                "AWS": "*"            },            "Action": "s3:*",            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/abc/*"        }    ]}6.     Modify the bucket policy to edit or remove any "Effect": "Deny" statements that are incorrectly denying you access to the prefix or object.Restrictions in your IAM user policy1.    Open the IAM console.2.    From the console, open the IAM user or role that you're using to access the prefix or object.3.    In the Permissions tab of your IAM user or role, expand each policy to view its JSON policy document.4.    In the JSON policy documents, search for policies related to Amazon S3 access. Then, search those policies for any "Effect": "Deny" statements that are blocking your access to the prefix or object.For example, the following IAM policy has an "Effect": "Deny" statement that blocks the IAM identity's access to the prefix abc/* within DOC-EXAMPLE-BUCKET. Then, the policy also has an "Effect": "Allow" statement that grants access to DOC-EXAMPLE-BUCKET. Despite the allow statement for the entire bucket, the explicit deny statement prevents the IAM identity from accessing the prefix abc/*.{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "StatementPrefixDeny",            "Effect": "Deny",            "Action": "s3:GetObject",            "Resource": [                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/abc/*"            ]        },        {            "Sid": "StatementFullPermissionS3",            "Effect": "Allow",            "Action": "s3:GetObject",            "Resource": [                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"            ]        }    ]}5.    Modify the policy to edit or remove any "Effect": "Deny" statements that are incorrectly denying you access to the prefix or object.Permissions to object encrypted by AWS KMSIf an object is encrypted with an AWS KMS key, then you need permissions to both the object and the key. Follow these steps to check if you can't access the object because you need permissions to an AWS KMS key:1.    Use the Amazon S3 console to view the properties of one of the objects that you can't access. Review the object's Encryption properties.2.    If the object is encrypted with a custom AWS KMS key (KMS key), then review the KMS key policy. Confirm that the key policy allows your IAM identity to perform the following KMS actions:"Action": ["kms:Decrypt"]3.    If your IAM identity is missing permissions to any of these actions, modify the key policy to grant the missing permissions.Important: If your IAM identity and KMS key belong to different accounts, then check to make sure that you have proper permissions. Both your IAM and key policies must grant you permissions to the required KMS actions.Related informationWhy can't I access an object that was uploaded to my Amazon S3 bucket by another AWS account?How can I grant a user access to a specific folder in my Amazon S3 bucket?Do I need to specify the AWS KMS key when I download a KMS-encrypted object from Amazon S3?Follow"


Question: Why can’t I connect to my Amazon EC2 instance using Session Manager?

I can't access my Amazon Elastic Compute Cloud (Amazon EC2) instance using AWS Systems Manager Session Manager.

Answer: "I can't access my Amazon Elastic Compute Cloud (Amazon EC2) instance using AWS Systems Manager Session Manager.ResolutionAccess to an instance using Session Manager can fail due to the following reasons:Incorrect session preferencesAWS Identity and Access Management (IAM) permission issuesHigh resource usage on the instanceIf you can't connect to Session Manager, then review the following to troubleshoot the issue:Verify Systems Manager prerequisitesConfirm that the instance appears as a managed instance, and then verify that all Session Manager prerequisites are met. For more information, see Why is my EC2 instance not displaying as a managed node or showing a "Connection lost" status in Systems Manager?AWS KMS configuration issuesReview the Session Manager error messages to determine the type of issue. Then, follow the relevant troubleshooting steps to resolve the issue.Error: "Encountered error while initiating handshake. Handshake timed out. Please ensure that you have the latest version of the session manager plugin"AWS Key Management Service (AWS KMS) encryption is activated in Session Manager preferences and the instance can't reach the AWS KMS endpoints.Run the following command to verify connectivity to AWS KMS endpoints. Replace RegionID with your AWS Region.$ telnet kms.RegionID.amazonaws.com 443For more information and for instructions to connect to the AWS KMS endpoints, see Connecting to AWS KMS through a VPC endpoint.Error: "Encountered error while initiating handshake. Fetching data key failed: Unable to retrieve data key, Error when decrypting data key AccessDeniedException"Confirm that the instance profile or user has the required kms:Decrypt permission for the AWS KMS key that is used to encrypt the session. For more information, see Adding Session Manager permissions to an existing instance profile.Error: "Invalid Keyname:Your session has been terminated for the following reasons: NotFoundException: Invalid keyId xxxx"Verify that the AWS KMS key Amazon Resource Name (ARN) that is specified in the Session Manager preferences to encrypt the session is valid. View the available key ARNs, and then confirm that the ARN specified in Session Manager preferences matches one of the available ARNs. For more information, see Finding the key ID and ARN.RunAs user name is not validError: "Invalid RunAs username"-or-Error: "Unable to start shell: failed to start pty since RunAs user xyz does not exist"Session Manager fails with these errors if Enable Run As support for Linux instances specifies an operating system user name that isn't valid.To fix this issue, provide a valid operating system user name (for example, ubuntu, ec2-user, or centos). The operating system user can be specified by either configuring the session manager preferences or by tagging the IAM user or role that starts the session with the tag key of SSMSessionRunAs and value of os-user-account-name. For more information, see Turn on run as support for Linux and macOS managed nodes.Or, you can clear Enable Run As support for Linux instances.Blank screen displays after starting a sessionWhen you start a session, Session Manager displays a blank screen. For troubleshooting steps, see Blank screen displays after starting a session.Other troubleshootingFor more information and other troubleshooting scenarios, see How do I troubleshoot issues with AWS Systems Manager Session Manager?Related informationTroubleshooting Session ManagerHow can I use an SSH tunnel through AWS Systems Manager to access my private VPC resources?Turn on SSH connections through Session ManagerLogging session activityFollow"


Question: Why did the master user for my RDS for SQL Server instance lose access and how can I gain it back?

"The master user for my Amazon Relational Database Service (Amazon RDS) for SQL Server instance lost access. Or, I need to grant the master user access to a database created by another user. What do I do to restore access or grant access to my master user?"

Answer: "The master user for my Amazon Relational Database Service (Amazon RDS) for SQL Server instance lost access. Or, I need to grant the master user access to a database created by another user. What do I do to restore access or grant access to my master user?Short descriptionWhen you create a new DB instance, the default master user automatically receives certain privileges for that DB instance. You can't change the master user name after the DB instance is created.Note: It's a best practice not to use the master user directly in your applications. Instead, use a database user created with the minimal privileges required for your application.If you accidentally delete the master user's permissions, you can restore them by modifying the DB instance and setting a new master user password. For more information, see Master user account privileges.ResolutionThe following are common scenarios that might lead to the master user losing access connecting to the DB instance. Or the master user might not be able to connect to and access a specific user database.Scenario 1: The master user can't connect to the DB instance due to an explicit DENYThe master user might not be able to connect to the DB instance because an explicit DENY is set on the Connect SQL privilege. By default, the master user is granted Connect SQL by the Amazon RDS System Administrator (rdsa) login. However, in Microsoft SQL Server, an explicit DENY takes precedence over an explicit GRANT.To fix this, do the following:1.    Connect to RDS for SQL Server using the login of the grantor who placed the explicit DENY on Connect SQL for the master user login.2.    Use the following T-SQL command to revoke the explicit DENY. In the following example, the RDS master user login is master_user and the grantor principal is grantor_principal. Change these values to match your use case.USE [master];GOREVOKE CONNECT SQL TO [master_user] AS [grantor_principal];GOScenario 2: The master user can't connect to a specific database because it isn't mapped to a user in the databaseThis might occur in the following circumstances:The database was created by another login account. And, the master user login isn't mapped to a database user in the database and granted privileges to the database.The database user previously mapped to the master user login with proper permissions was explicitly deleted.To resolve this issue, reset the master user password. Resetting the password creates a database user mapped to the master user login if that user was deleted. It also grants the db_owner fixed database role to the user. For instructions on resetting the master user password, see How do I reset the master user password for my Amazon RDS DB instance?Note: The AWS Identify and Access Management (IAM) user resetting the password must have permission to perform the ModifyDBInstance action on the RDS resource.Updating the master user password does the following:Grants the master user the db_owner database-level role to a database created by another user.Restores system privileges to the master user.Restores server-level roles to the master user.Restores server-level permissions to the master user.Restores access to system stored procedures to the master user.Restores access to RDS-specific stored procedures to the master user.Scenario 3: The master user can't perform certain actionsThe master user has db_owner role permission on the database but perform certain actions, such as CONNECT, SELECT, INSERT, UPDATE, ALTER, and so on. This might occur when the database user mapped to the master user login was explicitly denied certain permissions on the database.To see the list of database roles, and which database users are members of those roles, run the following T-SQL command. In the following replace database_namewith the correct values for your use case.USE [database_name];  GO  SELECT DP1.name AS DatabaseRoleName,   isnull (DP2.name, 'No members') AS DatabaseUserName FROM sys.database_role_members AS DRM RIGHT OUTER JOIN sys.database_principals AS DP1   ON DRM.role_principal_id = DP1.principal_id LEFT OUTER JOIN sys.database_principals AS DP2   ON DRM.member_principal_id = DP2.principal_idWHERE DP1.type = 'R'ORDER BY DP1.name;Run the following commands to see the list of permissions a user has in a particular database. In the following example, replace database_name with the correct value for your use case.USE [database_name];GOEXECUTE AS USER = 'master_user';SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE');GOIn this example, the master user is added to the db_denydatawriter and db_denydatareader fixed database roles. Despite being a member of the db_owner fixed database role, the deny privileges of db_denydatawriter and db_denydatareader prohibit SELECT, INSERT, UPDATE and DELETE permissions on the database.To resolve this issue:1.    Log in to the RDS for SQL Server instance using the master user.2.    Use the following T-SQL command to drop the master user as a member of these two roles:USE [database_name];GOALTER ROLE [db_denydatawriter] DROP MEMBER [master_user];ALTER ROLE [db_denydatareader] DROP MEMBER [master_user];GOAfter the commands complete, the master user has SELECT, INSERT, UPDATE, and DELETE permissions on the database restored.For more information about the specific roles the master user has, see Master user account privileges.Related informationResetting the db_owner role passwordMicrosoft SQL Server securityDENY (Transact-SQL)Follow"


Question: How do I plan an upgrade strategy for an Amazon EKS cluster?

"When I upgrade my Amazon Elastic Kubernetes Service (Amazon EKS) cluster, I want to make sure that I follow best practices."

Answer: "When I upgrade my Amazon Elastic Kubernetes Service (Amazon EKS) cluster, I want to make sure that I follow best practices.Short descriptionNew versions of Kubernetes technology introduce significant changes to your Amazon EKS cluster. After you upgrade a cluster, you can’t downgrade it. Therefore, for a successful transition to a newer version of Kubernetes, follow the best practices that are outlined in this upgrade plan.When you upgrade to a newer Kubernetes version, you can migrate to new clusters instead of performing in-place cluster upgrades. In this case, cluster backup and restore tools like VMware’s Velero can help you migrate to a new cluster. For more information, see Velero on GitHub.To see current and past versions of Kubernetes that are available for Amazon EKS, see the Amazon EKS Kubernetes release calendar.ResolutionPreparing for an upgradeBefore you begin your cluster upgrade, note the following requirements:Amazon EKS requires up to five free IP addresses from the subnets that you specified when you created your cluster.Make sure that the cluster's AWS Identity and Access Management (IAM) role and security group exist in your AWS account.If you activate secrets encryption, then make sure that the cluster IAM role has permission to use the AWS Key Management Service (AWS KMS) key.Review major updates for Amazon EKS and KubernetesReview all documented changes for the version that you’re upgrading to, and note any required upgrade steps. Also, note any requirements or procedures that are specific to Amazon EKS managed clusters.Refer to the following resources for any major updates to Amazon EKS clusters platform versions and Kubernetes versions:Updating an Amazon EKS cluster Kubernetes versionAmazon EKS Kubernetes versionsAmazon EKS platform versionsFor more information on Kubernetes upstream versions and major updates, see the following documentation on the Kubernetes website and GitHub:Kubernetes release notesKubernetes changelogUnderstand the Kubernetes deprecation policyWhen an API is upgraded, the earlier API is deprecated and eventually removed. To understand how APIs might be deprecated in a newer version of Kubernetes, read the deprecation policy on the Kubernetes website.To check whether you use any deprecated API versions in your cluster, use the Kube No Trouble (kubent) on GitHub. If you do use deprecated API versions, then upgrade your workloads before you upgrade your Kubernetes cluster.To convert Kubernetes manifest files between different API versions, use the kubectl convert plugin. For more information, see Install kubectl convert plugin on the Kubernetes website.What to expect during a Kubernetes upgradeWhen you upgrade your cluster, Amazon EKS launches new API server nodes with the upgraded Kubernetes version to replace the existing nodes. If any of these checks fail, then Amazon EKS reverts the infrastructure deployment, and your cluster remains on the previous Kubernetes version. However, this rollback doesn’t affect any applications that are running, and you can recover any clusters, if needed. During the upgrade process, you might experience minor service interruptions.Upgrading the control plane and data planeUpgrading an Amazon EKS cluster requires updating 2 main components: the control plane (master nodes) and the data plane (worker nodes). When you upgrade these components, keep the following consideration in mind.In-place Amazon EKS cluster upgradesFor in-place upgrades, you can upgrade only to the next highest Kubernetes minor version. If there are multiple versions between your current cluster version and the target version, then you must upgrade to each version sequentially. For each in-place Kubernetes cluster upgrade, you must complete the following tasks:Upgrade the cluster control plane.Upgrade the nodes in your cluster.Update your Kubernetes add-ons and custom controllers, as required.Update your Kubernetes manifests, as required.For more information, see Planning and executing Kubernetes version upgrades in Amazon EKS in Planning Kubernetes upgrades with Amazon EKS.Blue/green or canary Amazon EKS clusters migrationA blue/green or canary upgrade strategy is more complex, but it allows upgrades with easy rollback capability and no downtime. For a blue/green or canary upgrade, see Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads.Upgrading Amazon EKS managed node groupsImportant: A node’s kubelet can’t be newer than kube-apiserver. Also, it can’t be more than two minor versions earlier than kube-apiserver. For example, suppose that kube-apiserver is at version 1.24. In this case, a kubelet is supported only at versions 1.24, 1.23, and 1.22.To completely upgrade your managed node groups, follow these steps:1.    Upgrade your Amazon EKS cluster control plane components to the latest version.2.    Update your worker nodes in the managed node group.Migrating to Amazon EKS managed node groupsIf you use self-managed node groups, then you can migrate your workload to Amazon EKS managed node groups with no downtime. For more information, see Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups.Identifying and upgrading downstream dependencies (add-ons)Clusters often contain many outside products such as ingress controllers, continuous delivery systems, monitoring tools, and other workflows. When you update your Amazon EKS cluster, you must also update your add-ons and third-party tools. Be sure to understand how add-ons work with your cluster and how they’re updated.Note: It’s a best practice to use managed add-ons instead of self-managed add-ons.See the following examples of common add-ons and their relevant upgrade documentation:Amazon VPC CNI: For the best version of the Amazon VPC CNI add-on to use for each cluster version, see Updating the Amazon VPC CNI plugin for Kubernetes self-managed add-on. Also, see Update the aws-node daemonset to use IAM roles for service accounts in the Amazon EKS best practices guide on GitHub.kube-proxy self-managed add-on: Be sure to update to the latest available kube-proxy container image version for each Amazon EKS cluster version. For more information, see Updating the Kubernetes kube-proxy self-managed add-on.CoreDNS: Be sure to update to the latest available CoreDNS container image version for each Amazon EKS cluster version. For more information, see Updating the CoreDNS self-managed add-on.AWS Load Balancer Controller: Versions 2.4.0 or later of AWS Load Balancer Controller require Kubernetes versions 1.19 or later. For more information, see AWS Load Balancer Controller releases on GitHub. For installation information, Installing the AWS Load Balancer Controller add-on.Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) driver: Versions 1.1.0 or later of the Amazon EBS CSI driver require Kubernetes versions 1.18 or later. For more information, see Amazon EBS CSI driver releases on GitHub. For installation and upgrade information, see Managing the Amazon EBS CSI driver as an Amazon EKS add-on.Amazon Elastic File System (Amazon EFS) Container Storage Interface (CSI) driver: Versions 1.3.x or later of the Amazon EFS CSI driver require Kubernetes versions 1.17 or later. For more information, see Amazon EFS CSI driver releases on GitHub. For installation and upgrade information, see Amazon EFS CSI driver.Upgrading AWS Fargate nodesTo update a Fargate node, delete the pod that the node represents. Then, after you update your control plane, redeploy the pod. Any new pods that you launch on Fargate have a kubelet version that matches your cluster version. Existing Fargate pods aren't changed.Note: To keep Fargate pods secure, Amazon EKS must periodically patch them. Amazon EKS tries to update the pods in a way that reduces impact. However, if pods can't be successfully evicted, then Amazon EKS deletes them. To minimize disruption, see Fargate pod patching.Upgrading groupless nodes that are created by KarpenterWhen you set a value for ttlSecondsUntilExpired, this activates node expiry. After nodes reach the defined age in seconds, Amazon EKS deletes them. This is true even if they’re in use. This allows you to replace nodes with newly provisioned instances, and therefore upgrade them. When a node is replaced, Karpenter uses the latest Amazon EKS optimized AMIs. For more information, see Deprovisioning on the Karpenter website.The following example shows a node that’s deprovisioned with ttlSecondsUntilExpired, and therefore replaced with an upgraded instance:apiVersion: karpenter.sh/v1alpha5kind: Provisionermetadata:  name: defaultspec:  requirements:    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed      operator: In      values: ["spot"]  limits:    resources:      cpu: 1000                               # optional, recommended to limit total provisioned CPUs      memory: 1000Gi  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set  provider:        subnetSelector:      karpenter.sh/discovery/CLUSTER_NAME: '*'    securityGroupSelector:      kubernetes.io/cluster/CLUSTER_NAME: '*'Note: Karpenter doesn’t automatically add jitter to this value. If you create multiple instances in a short amount of time, then they expire near the same time. To prevent excessive workload disruption, define a pod disruption budget, as shown in Kubernetes documentation.Follow"


Question: How do I pass parameters from a scheduled trigger in EventBridge to an AWS Batch job?

I want to pass parameters from a scheduled trigger in Amazon EventBridge to an AWS Batch job.

Answer: "I want to pass parameters from a scheduled trigger in Amazon EventBridge to an AWS Batch job.Short descriptionIn AWS Batch, your parameters are placeholders for the variables that you define in the command section of your AWS Batch job definition. These placeholders allow you to:Use the same job definition for multiple jobs that use the same format.Programmatically change values in the command at submission time.It's a best practice to define your parameter as a key-value pair. For example:"Parameters" : {"test" : "abc"}If you register a job definition or submit a job, then use parameter substitution placeholders in the command field of the job's container properties. For example:"Command" : [ "echo” "Ref::test" ]When you submit the preceding job, the Ref::test argument in the container's command is replaced with the default value (abc).You can define a different parameter value for the same parameter key when you submit a job. For example:"Parameters" : {"test" : "hello"}When you submit the preceding job, the Ref::test argument in the container’s command is replaced with the custom value (hello) that you defined during job submission.ResolutionSet up your AWS Batch environment1.    Create a compute environment.2.    Create a job queue, and then associate your job queue with the compute environment that you created in step 1.3.    Create a job definition with an image (For example: nginx).Create an EventsBridge ruleImportant: You must use camel case for JSON text in your EventBridge rules.1.    Open the EventBridge console.2.    Select Create rule.3.    Enter a Name for your rule. You can optionally enter a Description.4.    In Define pattern, select Event pattern or Schedule, based on your use case.5.    In Select event bus, select the default option of AWS default event bus.6.    In Select targets, choose Batch job queue from the Target dropdown list.7.    For Job queue, enter the ARN of the job queue that you created earlier.8.    For Job definition, enter the name of the job definition that you created earlier.9.    For Job name, enter a name for your job.10.    Expand the Configure input section, and select Constant (JSON text).11.    In the text box that appears, enter the following:{"Parameters": {"name":"test"}, "ContainerOverrides": { "Command": ["echo","Ref::name"] } }The rule submits an AWS Batch job when EventBridge invokes the rule. If the job is successful, your CloudWatch logs print "test" at the following locations:Log Group: /aws/batch/jobLog Stream: yourJobDefinitionName/default/your-ecs-task-ID12.    Select Create.Related informationCreating Amazon EventBridge rules that react to eventsCreating an Amazon EventBridge rule that runs on a scheduleFollow"


Question: How can I move an Amazon RDS DB instance from a public subnet to private subnet within the same VPC?

"I have an Amazon Relational Database Service (Amazon RDS) DB instance that is in a public subnet. I want to move my DB instance from a public to a private subnet within the same VPC, and make my DB instance completely private. How can I do this?"

Answer: "I have an Amazon Relational Database Service (Amazon RDS) DB instance that is in a public subnet. I want to move my DB instance from a public to a private subnet within the same VPC, and make my DB instance completely private. How can I do this?Short descriptionAmazon RDS doesn't provide an option to change the subnet group of your DB instance, within the same VPC. However, you can use the workaround method in this article to move your DB instance from a public subnet to a private subnet. Performing this action makes your DB instance private.This method has a number of advantages, including:You don't need to create a new DB instanceYou don't need to use the snapshot-restore processIt minimizes the downtime involved in creating a new instance and diverting traffic. The only downtime that you see is the failover time.ResolutionTurn off Multi-AZ deployments and public accessibility on your DB instanceIf your DB instance is already set to Single-AZ with the Public accessibility parameter set to No, then skip this step.To modify your DB instance to turn off Multi-AZ deployments, follow these steps:Sign in to the Amazon RDS console.From the navigation pane, choose Databases, and then choose the DB instance that you want to modify.Choose Modify.From the Modify DB Instance page, for Multi-AZ deployment and Public accessibility, choose No.Choose Continue, and then review the summary of modifications.Choose Apply immediately to apply your changes.Review your changes, and if correct, choose Modify DB Instance to save.Discover the IP address of your DB instanceAfter your DB instance returns to the Available state, run dig on the DB instance's endpoint to find its underlying IP address:dig <rds-endpoint>Output:db-RDS-instance.xxxxxxxx.us-east-1.rds.amazonaws.com. 5 IN A 172.39.5.213From the private IP, you can find which subnet your primary instance is using.In this example, the list of subnet CIDR is as follows:subnet1 -> 172.39.5.0/24subnet2 -> 172.39.4.0/24Because the IP is falling under 179.39.5.0/24, you can conclude that the instance is placed in subnet1.Remove the public subnets and add private subnets on your DB instanceAdd all the required private subnets in the subnet group. Also, delete all public subnets from the subnet group except for the one that is used by your primary. In the previous example, you delete everything except subnet1 because it is used by your DB instance.Note: A private subnet is a subnet that is associated with a route table that has no route for an internet gateway.Sign in to the Amazon RDS console.From the navigation pane, choose Subnet groups, and then choose the subnet group that is associated with your DB instance.Choose Edit.From the Add subnets section, choose the Availability Zone and private subnets that you want to add.Select the public subnets that you want to delete, and then choose Remove.Choose Save.Turn on Multi-AZ on your DB instanceModify the DB instance to turn on the Multi-AZ deployment. The new secondary launches in one of the remaining private subnets.Reboot your DB instance with failover and turn off Multi-AZ deploymentWhen your DB instance fails over, the secondary, which is using the private IP, becomes the primary and the public subnet becomes the secondary.After you reboot your DB instance with failover, remove the secondary, which is now in the public subnet. To do this, modify the DB instance to turn off Multi-AZ, again. You can do this by setting Multi-AZ deployment to No.Remove the public subnetRemove the remaining public subnet from the subnet group.Note: Removing subnets from the subnet group is a configuration from the RDS side. It doesn't involve deleting any subnets from the VPC.Check that there are only private subnets in the subnet group.If your DB instance was previously in Multi-AZ deployment, then turn Multi-AZ deployment on again.This solution involves failover and turning on/turning off Multi-AZ so there are few things to consider. For more information, see Multi-AZ DB instance deployments.Note: This method is specific for RDS DB instances. If your DB instance is part of Aurora cluster, then you can use the clone option. Or you can follow the steps in this article, but instead of turning off Multi-AZ, you should delete and recreate the readers.Related informationMulti-AZ DB cluster deploymentsFollow"


Question: How can I resolve root certificate file errors when using foreign data wrappers and SSL verify-full on Amazon RDS/Aurora PostgreSQL?

"I'm using Foreign Data Wrappers (FDW) and sslmode that is set to verify-full on Amazon Relational Database Service (Amazon RDS) running PostgreSQL. When I try to create an FDW server for my DB instance, I receive the following error: "root certificate file "/home/rdsdb/.postgresql/root.crt" does not exist". How can I resolve this error?"

Answer: "I'm using Foreign Data Wrappers (FDW) and sslmode that is set to verify-full on Amazon Relational Database Service (Amazon RDS) running PostgreSQL. When I try to create an FDW server for my DB instance, I receive the following error: "root certificate file "/home/rdsdb/.postgresql/root.crt" does not exist". How can I resolve this error?Short descriptionTo enable certificate verification in PostgreSQL, sslmode must be set to verify-full. If the sslmode is set to verify-full when you create an FDW server from one Amazon RDS instance to another, you receive the root certificate file error. This error is generated on the DB instance where the CREATE SERVER command is run. You can't access the filesystem on an Amazon RDS instance directly or install the CA certificates, but the required root certificate is already installed on the DB instance. To find the location of the certificate, run the following command:postgres=> show ssl_cert_file;ssl_cert_file-----------------------------------------/rdsdbdata/rds-metadata/server-cert.pem(1 row)To resolve this error, point the FDW connection to the /rdsdbdata/rds-metadata/server-cert.pem file when creating the server.ResolutionTo point the FDW connection to the root certificate file, run a command similar to the following:CREATE SERVER my_foreign_db foreign data wrapper postgres_fdw options (host 'my_db.xyz.eu-west-1.rds.amazonaws.com', port '5432', dbname 'my_db', sslmode 'verify-full', sslrootcert '/rdsdbdata/rds-metadata/server-cert.pem');To confirm that the connection is working, create a user mapping and foreign table:Note: PostgreSQL logs passwords in cleartext in the log files. To prevent this, review How can I stop Amazon RDS for PostgreSQL from logging my passwords in clear-text in the log files?CREATE USER MAPPING FOR dbuser SERVER my_foreign_db OPTIONS (user 'dbuser', password 'dbpasswd');CREATE FOREIGN TABLE foreign_table ( id integer not null, name character(84)) SERVER my_foreign_db OPTIONS (schema_name 'public', table_name 'my_table');A connection isn't made until the table is accessed. To confirm that the connection is working, query the table:SELECT * from foreign_table ;If the FDW connection is successful, the data from the foreign table is returned.Related informationCommon management tasks for PostgreSQL on Amazon RDSPostgreSQL Documentation for postgres_fdwFollow"


Question: How do I set up Time to Live (TTL) in DynamoDB?

I want to set up Time to Live (TTL) on my Amazon DynamoDB table.

Answer: "I want to set up Time to Live (TTL) on my Amazon DynamoDB table.ResolutionAmazon DynamoDB TTL allows you to define a per-item timestamp to determine when an item is no longer needed. After the expiration of the TTL timestamp, DynamoDB deletes the item from your table within 48 hours without consuming any write throughput. The time taken to delete the items might vary depending on the size and activity level of your table.To set up TTL, see Enabling Time to Live. When you create a TTL attribute in a table, keep the following in mind:TTL attributes must use the Number data type. Other data types, such as String, aren't supported.TTL attributes must use the epoch time format. For example, the epoch timestamp for October 28, 2019 13:12:03 UTC is 1572268323. You can use a free online converter, such as EpochConverter, to get the correct value.Note: Be sure that the timestamp is in seconds, not milliseconds (for example, use 1572268323 instead of 1572268323000).Related informationTime to LiveTables, items, and attributesFollow"


Question: How do I use the Reserved Instance coverage report in Cost Explorer?

I want to use the Cost Explorer reports to understand the coverage of my Reserved Instances (RIs).

Answer: "I want to use the Cost Explorer reports to understand the coverage of my Reserved Instances (RIs).ResolutionYou can use the RI coverage reports in Cost Explorer to do the following:View the utilization of individual RIs in the chart. You can view your RI utilization in either hours or normalized units. For more information on viewing RI utilization in either hours or normalized units, see Reserved Instance reports.View the number of instance hours or normalized units covered by your RIs in the chart. You can use this information to track your required instance hours or units and how many of those are covered by RIs.View the number of hours or normalized units covered by RIs against the On-Demand table. You can use this information to understand how much you spent on On-Demand Instances and how much you could have saved had you purchased more reservations.Select a single RI or a group of RIs in the table to view their respective coverage in the table.Define a threshold for the coverage you want from RIs, called the coverage target, to see where you can reserve more RIs.To define the coverage target, enter the preferred value for Coverage target, and select Show target line on chart. You can see the target coverage on the chart as a dotted line and the average coverage in the table as a status bar.Instances with a red status bar have no RI coverage.Instances with a yellow status bar are under your set coverage target.Instances with a green status bar have met your coverage target.Instances with a gray bar aren't using your reservations.Related informationRI coverage reportsFollow"


Question: How do I change my Lightsail plan?

I want to change my current Amazon Lightsail plan to a different plan.

Answer: "I want to change my current Amazon Lightsail plan to a different plan.ResolutionYour Lightsail plan is based on the Lightsail bundle that you're using.Upgrading the planTo upgrade your Lightsail plan to a larger instance, take a snapshot, and then create a larger instance from the snapshot.Downgrading the planMoving the Lightsail plan to a smaller instance isn't supported. In Lightsail instances, the data is stored in fixed-sized SSD disks. The data in SSD isn't stored uniformly. There are no methods to downsize an SSD volume because that process can cause data loss and data corruption. This means that it's not possible to automatically move from a larger Lightsail plan to a smaller one.To migrate to a smaller instance size, you must manually copy the site contents to a smaller instance by doing the following:Create a new, smaller Lightsail instance.Back up and restore the data from the old instance to the new instance. For detailed instructions on how to make a backup and restore your applications on Bitnami stacks, see Create and restore application backups. If this method doesn't fit your application, then contact your application's support team to understand how to move the data to a smaller instance.Note: Keep the following in mind when changing your Lightsail plan:Make sure that you're taking a complete backup of the existing Lightsail instance as a snapshot.Download the backup and then upload it to a new instance using SFTP/FTP or data stores such as S3 or Lightsail object storage.If you have a static IP address, be sure to detach it from your old instance. Then, attach it to your new instance.If there's an SSL certificate installed in the old instance, check to see if the certificate files are outside the /opt/bitnami directory. If they are, then you must manually copy the certificate to the new instance.The credentials files in the Bitnami instance also must be copied from the old instance to the new one. These are credential files such as /home/bitnami/bitnami_credentials and /home/bitnami/bitnami_application_password.Related informationExtending the storage space of your Windows Server instance in Amazon LightsailFollow"


Question: How can I improve the indexing performance on my Amazon OpenSearch Service cluster?

I want to optimize indexing operations in Amazon OpenSearch Service for maximum ingestion throughput. How can I do this?

Answer: "I want to optimize indexing operations in Amazon OpenSearch Service for maximum ingestion throughput. How can I do this?ResolutionBe sure that the shards are distributed evenly across the data nodes for the index that you're ingesting intoUse the following formula to confirm that the shards are evenly distributed:Number of shards for index = k * (Number of data nodes), where k is the number of shards per nodeFor example, if there are 24 shards in the index, and there are eight data nodes, then OpenSearch Service assigns three shards to each node. For more information, see Get started with Amazon OpenSearch Service: How many shards do I need?Increase the refresh_interval to 60 seconds or moreRefresh your OpenSearch Service index so that your documents are available for search. Note that refreshing your index requires the same resources that are used by indexing threads.The default refresh interval is one second. When you increase the refresh interval, the data node makes fewer API calls. The refresh interval can be shorter or faster, depending on the length of the refresh interval. To prevent 429 errors, it's a best practice to increase the refresh interval.Note: The default refresh interval is one second for indices that receive one or more search requests in the last 30 seconds. For more information about the updated default interval, see _refresh API version 7.x on the Elasticsearch website.Change the replica count to zeroIf you anticipate heavy indexing, consider setting the index.number_of_replicas value to "0." Each replica duplicates the indexing process. As a result, disabling the replicas improves your cluster performance. After the heavy indexing is complete, reactivate the replicated indices.Important: If a node fails while replicas are disabled, you might lose data. Disable the replicas only if you can tolerate data loss for a short duration.Experiment to find the optimal bulk request sizeStart with the bulk request size of 5 MiB to 15 MiB. Then, slowly increase the request size until the indexing performance stops improving. For more information, see Using and sizing bulk requests on the Elasticsearch website.Note: Some instance types limit bulk requests to 10 MiB. For more information, see Network limits.Use an instance type that has SSD instance store volumes (such as I3)I3 instances provide fast and local memory express (NVMe) storage. I3 instances deliver better ingestion performance than instances that use General Purpose SSD (gp2) Amazon Elastic Block Store (Amazon EBS) volumes. For more information, see Petabyte scale for Amazon OpenSearch Service.Reduce response sizeTo reduce the size of OpenSearch Service's response, use the filter_path parameter to exclude unnecessary fields. Be sure that you don't filter out any fields that are required to identify or retry failed requests. Those fields can vary by client.In the following example, the index-name, type-name, and took fields are excluded from the response:curl -XPOST "es-endpoint/index-name/type-name/_bulk?pretty&filter_path=-took,-items.index._index,-items.index._type" -H 'Content-Type: application/json' -d'{ "index" : { "_index" : "test2", "_id" : "1" } }{ "user" : "testuser" }{ "update" : {"_id" : "1", "_index" : "test2"} }{ "doc" : {"user" : "example"} }For more information, see Reducing response size.Increase the value of index.translog.flush_threshold_sizeBy default, index.translog.flush_threshold_size is set to 512 MB. This means that the translog is flushed when it reaches 512 MB. The weight of the indexing load determines the frequency of the translog. When you increase index.translog.flush_threshold_size, the node performs the translog operation less frequently. Because OpenSearch Service flushes are resource-intensive operations, reducing the frequency of translogs improves indexing performance. By increasing the flush threshold size, the OpenSearch Service cluster also creates fewer large segments (instead of multiple small segments). Large segments merge less often, and more threads are used for indexing instead of merging.Note: An increase in index.translog.flush_threshold_size can also increase the time that it takes for a translog to complete. If a shard fails, then recovery takes more time because the translog is larger.Before increasing index.translog.flush_threshold_size, call the following API operation to get current flush operation statistics:curl -XPOST "os-endpoint/index-name/_stats/flush?pretty"Replace the os-endpoint and index-name with your respective variables.In the output, note the number of flushes and the total time. The following example output shows that there are 124 flushes, which took 17,690 milliseconds:{     "flush": {          "total": 124,          "total_time_in_millis": 17690     }}To increase the flush threshold size, call the following API operation:$ curl -XPUT "os-endpoint/index-name/_settings?pretty" -d "{"index":{"translog.flush_threshold_size" : "1024MB"}}"In this example, the flush threshold size is set to 1024 MB, which is ideal for instances that have more than 32 GB of memory.Note: Choose the appropriate threshold size for your OpenSearch Service domain.Run the _stats API operation again to see whether the flush activity changed:$ curl _XGET "os-endpoint/index-name/_stats/flush?pretty"Note: It's a best practice to increase the index.translog.flush_threshold_size only for the current index. After you confirm the outcome, apply the changes to the index template.Related informationBest practices for Amazon OpenSearch ServiceFollow"


Question: How do I apply a resource-based policy on an AWS Secrets Manager secret?

How can I control access to AWS Secrets Manager secrets using resource-based policies?

Answer: "How can I control access to AWS Secrets Manager secrets using resource-based policies?Short descriptionWith resource-based policies, you can specify user access to a secret and what actions an AWS Identity and Access Management (IAM) user can perform.Note: A secret is defined as a resource with Secrets Manager.Common use cases for Secrets Manager resource-based policies are:Sharing a secret between AWS accounts.Enforcing permissions, such as adding an explicit deny to the secret.In this example resource-based policy, the IAM element Effect specifies whether the statement results in allow or an explicit deny. The IAM Action element defines the actions that are performed with the secret. The IAM Resource element is the secret that the policy is attached to. The IAM Principal element specifies the user with access to perform actions with the secret.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "secretsmanager:*",      "Principal": {"AWS": "arn:aws:iam::123456789999:user/Mary"},      "Resource": "*"    }  ]}ResolutionFollow these instructions to apply a resource-based policy in Secrets Manager:Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.1.    Follow the instructions for creating a secret. Note the Secret ARN.2.    Copy and paste this policy into your favorite text editor, and then save it as a JSON file such as my_explicit_deny_policy.json.{ "Version": "2012-10-17","Statement": [    {      "Effect": "Deny",      "Action": "secretsmanager:GetSecretValue",      "Principal": {"AWS": "arn:aws:iam::123456789999:user/Mary"},      "Resource": "*"    }  ]}3.    Use the AWS CLI command put-resource-policy to place a resource policy for the secret to explicitly deny IAM user Mary from retrieving the secret value.aws secretsmanager put-resource-policy --secret-id My_Resource_Secret --resource-policy file:// My_explicit_deny_Policy.json4.    You receive an output similar to the following:{"ARN": "arn:aws:secretsmanager:<your region>:123456789999:secret:My_Resource_Secret","Name": "My_Resource_Secret"}Note: The AWS Key Management Service (AWS KMS) decrypt permission is required only if you use AWS KMS keys to encrypt your secret. A secret can't be retrieved by an IAM principal in a third-party account if the secret is encrypted by the default AWS KMS key.For more information, see Using resource-based policies for Secrets Manager.Follow"


Question: How do I access Amazon SNS topic delivery logs for push notifications?

I want to access Amazon Simple Notification Service (Amazon SNS) topic delivery logs for push notifications.

Answer: "I want to access Amazon Simple Notification Service (Amazon SNS) topic delivery logs for push notifications.Short descriptionBefore you completed the following steps, confirm that you're using SNS endpoints supported by Amazon SNS for log delivery status of notification messages:HTTP and HTTPsAmazon Kinesis Data FirehoseAWS LambdaPlatform application endpointAmazon Simple Queue Service (Amazon SQS)SMSNote: 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.ResolutionConfigure push notification delivery status attributes for Amazon CloudWatch LogsNote: As an alternative to the following console steps, you can configure message delivery status using AWS SDKs or the AWS CLI.1.    Open the Amazon SNS console.2.    On the navigation menu, expand Mobile, and then choose Push notifications.3.    In the Platform applications section, select the platform application that you want to have delivery status for.4.    Choose Edit.5.    Expand Delivery status logging – optional.6.    For Success sample rate, in the % text box, enter 100.7.    In the IAM roles section, for Service role, select Create new service role, and then choose Create new roles. The AWS Identity and Access Management (IAM) console opens.Note: If you already have an IAM role with the right permissions, then you can use that service role by selecting Use existing service role instead.8.    On the IAM console permission request page, choose Allow.9.    After returning to the Amazon SNS console, choose Save changes.Now, an IAM role is created for successful and failed deliveries with the following policy and trust relationships for Amazon SNS. See the following examples:IAM role for successful deliveries:arn:aws:iam::1111111111:role/SNSSuccessFeedbackIAM role for failed deliveries:arn:aws:iam::1111111111:role/SNSFailureFeedbackPolicy:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": [                "logs:CreateLogGroup",                "logs:CreateLogStream",                "logs:PutLogEvents",                "logs:PutMetricFilter",                "logs:PutRetentionPolicy"            ],            "Resource": [                "*"            ]        }    ]}Trust relationships:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": "sns.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}View delivery status logs1.    Open the Amazon CloudWatch console.2.    On the navigation pane, expand Logs, and then choose Log groups.3.    In the Filter search box, enter sns to find only log groups for Amazon SNS.The sns/your-AWS-region/your-account_ID/app/platform_name/application_name log group contains the successful delivery logs.sns/us-east-1/1111111111/app/GCM/Test1sns/us-east-1/1111111111/app/APNS_SANDBOX/Test2sns/us-east-1/1111111111/app/APNS/Test3The sns/your-AWS-region/your-account_ID/app/platform_name/application_name**/Failure** log group contains the failure delivery logs:sns/us-east-1/1111111111/app/GCM/Test1/Failuresns/us-east-1/1111111111/app/APNS_SANDBOX/Test2/Failuresns/us-east-1/1111111111/app/APNS/Test3/Failure4.    Choose the Amazon SNS log group that you want to view.5.    On the Log streams tab, choose a particular log stream to view the application endpoint delivery logs.Consider the following:You can't add a prefix to the streams in CloudWatch Logs.You can't directly change the default log group name for Amazon SNS.The notification content isn't written to your CloudWatch logs. That is, the SNS topic delivery logs don't log the notification content to CloudWatch, but write only the metadata to CloudWatch.If you publish on an SNS topic that has SMS and platform application endpoints, the delivery status logs are still populated for these endpoints in their respective log group.Troubleshoot notification failuresLook up the statusCode with the provider service, such as FCM or APNs. For the provider's exact response message, view the providerResponse.For a list of push notification service response codes, see Platform response codes.Related informationMobile app attributesFollow"


Question: How do I create a certificate-based VPN using AWS Site-to-Site VPN?

I want to build a certificate-based IP Security (IPSec) VPN using AWS Site-to-Site VPN. How can I do this?

Answer: "I want to build a certificate-based IP Security (IPSec) VPN using AWS Site-to-Site VPN. How can I do this?Short descriptionAWS Site-to-Site VPN supports certificate-based authentication by integrating withAWS Certificate Manager Private Certificate Authority. Using digital certificates instead of pre-shared keys for IKE authentication, you can build IPSec tunnels with static or dynamic customer gateway IP addresses.ResolutionTask 1: Create and install a root CA and a subordinate CAThe private certificate you'll create in task 2 must be issued by the subordinate CA. The subordinate CA must be in AWS Certificate Manager (ACM). If your CA is not in ACM, you can create a Certificate Signing Request (CSR) and import the signed subordinate CA into ACM.Task 2: Create a private certificate to use as the identity certificate for your customer gateway****Note: You'll install this certificate in task 5.Task 3: Create a customer gateway for your VPN connectionOpen the Amazon Virtual Private Cloud (Amazon VPC) console.Choose Customer Gateways, and then choose Create Customer Gateway.For Name, specify a name for your customer gateway.For Routing, select the routing type for your use case.Leave the IP Address field empty if your customer gateway IP address is dynamic. If your customer gateway IP address is static, you can leave this field empty, or you can specify the IP address.For Certificate ARN, choose the certificate ARN that you created in task 2.(Optional) For Device, specify a device name.Choose Create Customer Gateway.Task 4: Configure the AWS Site-to-Site VPN connection with a virtual private gatewayTask 5: Copy the end entity certificate (the private certificate that you created in task 2), root CA certificate, and subordinate CA certificate to the customer gateway deviceNote: The customer gateway presents the end entity certificate when requested by the AWS VPN endpoint for authentication. The customer gateway device must have all the certificates present (subordinate CA certificate and root CA certificate). If the customer gateway device doesn't have these certificates, VPN authentication fails when the AWS VPN endpoint presents its own certificate.Related informationAWS Site-to-Site VPN now supports certificate authenticationFollow"


Question: How can I set up access logging for API Gateway?

I'm trying to set up access logging for Amazon API Gateway. How can I do this?

Answer: "I'm trying to set up access logging for Amazon API Gateway. How can I do this?Short descriptionTo debug issues related to request execution or client access to your API, you can activate Amazon CloudWatch Logs to log API calls.ResolutionBefore you begin, make sure that you have:Deployed your API to a stage.Granted API Gateway permission to read and write logs to CloudWatch for your account.Next, to activate access logging follow steps 1-5 and 7-8 (skip step 6) in the instructions for setting up CloudWatch API logging using the API Gateway console.Note: It's a best practice not to log the full API requests and responses for production APIs. Full API requests and responses can result in logging sensitive data.You now have CloudWatch logs activated for debugging. To find errors, see How do I find API Gateway REST API errors in my CloudWatch logs?For more information, see Monitoring REST API execution with Amazon CloudWatch metrics.Related informationHow do I troubleshoot "Invalid permissions on Lambda function" errors from API Gateway REST APIs?How do I find 5xx errors from API Gateway in my CloudWatch logs?How do I turn on CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?Follow"


Question: Why am I being charged too much for Amazon Lightsail?

"I signed up for an Amazon Lightsail plan, but I'm charged more than I expected."

Answer: "I signed up for an Amazon Lightsail plan, but I'm charged more than I expected.Short descriptionHere are a few reasons why you might have incurred unexpected charges with your Amazon Lightsail plan:You signed up for the Lightsail plan that comes with the one-month free trial, but the free trial expired.You signed up for a more expensive Lightsail plan than you meant to.You signed up for Lightsail without meaning to.You exceeded your monthly data transfer allowance.In either of these cases, delete your Lightsail instance and any associated snapshots to stop charges from accruing.ResolutionSign in to the Lightsail console, and check each resource tab to see if you have any running resources. Running resources will be under the Instances, Databases, Networking, Storage, or Snapshots tabs.If you don't need a particular resource, choose the menu icon (⋮) next to the resource name, and then choose Delete.For snapshots, expand the list of snapshots, choose the menu icon (⋮) for each snapshot, and then choose Delete.Note: Lightsail instance snapshots cost less per hour than running instances. Also, you can use snapshots to relaunch an identical instance later on. If you want to save your work, consider creating or retaining snapshots as a backup.After you delete all your Lightsail resources, no more Lightsail charges accrue.Related informationLightsail pricingHow do I shut down my Amazon Lightsail resources?Follow"