Question: How do I troubleshoot DNS failures with Amazon EKS?

The applications or pods that are using CoreDNS in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster fail internal or external DNS name resolutions.

Answer: "The applications or pods that are using CoreDNS in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster fail internal or external DNS name resolutions.Short descriptionPods that run inside the Amazon EKS cluster use the CoreDNS service's cluster IP as the default name server for querying internal and external DNS records. If there are issues with the CoreDNS pods, service configuration, or connectivity, then applications can fail DNS resolutions.The CoreDNS pods are abstracted by a service object called kube-dns. To troubleshoot issues with your CoreDNS pods, verify that all the components of the kube-dns service are working. These components include, but are not limited to, service endpoint options and iptables rules.ResolutionThe following resolution applies to the CoreDNS ClusterIP 10.100.0.10.1.    Get the ClusterIP of your CoreDNS service:kubectl get service kube-dns -n kube-system2.    Verify that the DNS endpoints are exposed and pointing to CoreDNS pods:kubectl -n kube-system get endpoints kube-dnsOutput:NAME       ENDPOINTS                                                        AGEkube-dns   192.168.2.218:53,192.168.3.117:53,192.168.2.218:53 + 1 more...   90dNote: If the endpoint list is empty, then check the pod status of the CoreDNS pods.3.    Verify that a security group or network access control list (network ACL) aren't blocking the pods when they communicate with CoreDNS.For more information, see Why won't my pods connect to other pods in Amazon EKS?Verify that the kube-proxy pod is workingCheck your logs for timeout errors to the control plane to verify that the kube-proxy pod has access to API servers for your cluster. Also, check for 403 unauthorized errors.Get the kube-proxy logs:kubectl logs -n kube-system --selector 'k8s-app=kube-proxy'Note: The kube-proxy gets the endpoints from the control plane and creates the iptables rules on every node.Connect to the application pod to troubleshoot the DNS issue1.    To run commands inside your application pods, run the following command to access a shell inside the running pod:$ kubectl exec -it your-pod-name -- shIf the application pod doesn't have an available shell binary, then you receive an error similar to the following:OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknowncommand terminated with exit code 126To debug, update the image that's used in your manifest file for another image, such as the busybox image (from the Docker website).2.    To verify that the cluster IP of the kube-dns service is in your pod's /etc/resolv.conf, run the following command in the shell inside of the pod:cat /etc/resolv.confThe following example resolv.conf shows a pod that's configured to point to 10.100.0.10 for DNS requests. The IP must match the ClusterIP of your kube-dns service:nameserver 10.100.0.10search default.svc.cluster.local svc.cluster.local cluster.local ec2.internaloptions ndots:5Note: You can manage your pod's DNS configuration with the dnsPolicy field in the pod specification. If this field isn't populated, then the ClusterFirst DNS policy is used by default.3.    To verify that your pod can use the default ClusterIP to resolve an internal domain, run the following command in the shell inside the pod:nslookup kubernetes.default 10.100.0.10Output:Server:     10.100.0.10Address:    10.100.0.10#53Name:       kubernetes.default.svc.cluster.localAddress:    10.100.0.14.    To verify that your pod can use the default ClusterIP to resolve an external domain, run the following command in the shell inside the pod:nslookup amazon.com 10.100.0.10Output:Server:     10.100.0.10Address:    10.100.0.10#53Non-authoritative answer:Name:   amazon.comAddress: 176.32.98.166Name:    amazon.comAddress: 205.251.242.103Name:    amazon.comAddress: 176.32.103.2055.    To verify that your pod can use the IP address of the CoreDNS pod to resolve directly, run the following commands in the shell inside the pod:nslookup kubernetes COREDNS_POD_IPnslookup amazon.com COREDNS_POD_IPNote: Replace the COREDNS_POD_IP with one of the endpoint IPs from the kubectl get endpoints that you used earlier.Get more detailed logs from CoreDNS pods for debugging1.    Turn on the debug log of CoreDNS pods and add the log plugin to the CoreDNS ConfigMap:kubectl -n kube-system edit configmap coredns2.    In the editor screen that appears in the output, add the log string. For example:kind: ConfigMapapiVersion: v1data:  Corefile: |    .:53 {        log    # Enabling CoreDNS Logging        errors        health        kubernetes cluster.local in-addr.arpa ip6.arpa {          pods insecure          upstream          fallthrough in-addr.arpa ip6.arpa        }        ......Note: Reloading the configuration CoreDNS takes several minutes. To apply the changes immediately, you can restart the pods one by one.3.    Check if the CoreDNS logs are failing or getting any hits from the application pod:kubectl logs --follow -n kube-system --selector 'k8s-app=kube-dns'Update the ndots valueDNS uses nameserver for name resolutions, which is usually the ClusterIP of a kube-dns service. DNS uses search for completing a query name to a fully qualified domain name. The ndots value is the number of dots that must appear in a name to resolve a query before an initial absolute query is made.For example, you can set the ndots option to the default value 5 in a domain name that's not fully qualified. Then, all external domains that don't fall under the internal domain cluster.local are appended to the search domains before they query.See the following example with the /etc/resolv.conf setting of the application pod:nameserver 10.100.0.10search default.svc.cluster.local svc.cluster.local cluster.local ec2.internaloptions ndots:5CoreDNS looks for five dots in the domain that's queried. If the pod makes a DNS resolution call for amazon.com, then your logs look similar to the following:[INFO] 192.168.3.71:33238 - 36534 "A IN amazon.com.default.svc.cluster.local. udp 54 false 512" NXDOMAIN qr,aa,rd 147 0.000473434s[INFO] 192.168.3.71:57098 - 43241 "A IN amazon.com.svc.cluster.local. udp 46 false 512" NXDOMAIN qr,aa,rd 139 0.000066171s[INFO] 192.168.3.71:51937 - 15588 "A IN amazon.com.cluster.local. udp 42 false 512" NXDOMAIN qr,aa,rd 135 0.000137489s[INFO] 192.168.3.71:52618 - 14916 "A IN amazon.com.ec2.internal. udp 41 false 512" NXDOMAIN qr,rd,ra 41 0.001248388s[INFO] 192.168.3.71:51298 - 65181 "A IN amazon.com. udp 28 false 512" NOERROR qr,rd,ra 106 0.001711104sNote: NXDOMAIN means that the domain record wasn't found, and NOERROR means that the domain record was found.Every search domain is prepended with amazon.com before it makes the final call on the absolute domain at the end. The final domain name is appended with a dot (.) at the end, which makes it a fully qualified domain name. This means that for every external domain name query there might be four to five additional calls, which can overwhelm the CoreDNS pod.To resolve this issue, either change ndots to 1, which looks only for single dot. Or, append a dot (.) at the end of the domain that's queried or used. For example:nslookup example.com.Consider VPC resolver (AmazonProvidedDNS) limitsThe Amazon Virtual Private Cloud (Amazon VPC) resolver can accept only a maximum hard limit of 1024 packets per second per network interface. If more than one CoreDNS pod is on the same node, then the chances of hitting this limit are higher for external domain queries.To use PodAntiAffinity (from the Kubernetes website) rules to schedule CoreDNS pods on separate instances, add the following options to the CoreDNS deployment:podAntiAffinity:  preferredDuringSchedulingIgnoredDuringExecution:  - podAffinityTerm:      labelSelector:        matchExpressions:        - key: k8s-app          operator: In          values:          - kube-dns      topologyKey: kubernetes.io/hostname    weight: 100Use tcpdump to capture CoreDNS packets from Amazon EKS worker nodesUse the tcpdump tool to perform a packet capture to help diagnose DNS resolution issues. This tool helps validate whether network traffic for DNS requests is reaching your CoreDNS pods and if there are any underlying network connectivity issues. To use tcpdump, complete the following steps.1.    Locate a worker node where a CoreDNS pod is running:kubectl get pod -n kube-system -l k8s-app=kube-dns -o wide2.    Use SSH to connect to the worker node where a CoreDNS pod is running and install the tcpdump tool:sudo yum install tcpdump –y3.    Locate the CoreDNS pod process ID on the worker node:ps ax | grep coredns4.    From the worker node, perform a packet capture on the CoreDNS pod network to monitor network traffic on UDP port 53:sudo nsenter -n -t PID tcpdump udp port 535.    From a separate terminal, get the CoreDNS service and pod IPs:kubectl describe svc kube-dns -n kube-systemNote: Note the service IP that's located in the 'IP' field and the pod IPs that's located in the 'Endpoints' field.6.    Launch a pod that you'll test the DNS service from. The following example uses an Ubuntu container image:kubectl run ubuntu --image=ubuntu sleep 1dkubectl exec -it ubuntu sh7.    Use the nslookup tool to perform a DNS query to a domain, such as amazon.com:nslookup amazon.comPerform the same query explicitly against the CoreDNS service IP from step 5:nslookup amazon.com COREDNS_SERVICE_IPPerform the query against each of the CoreDNS pod IPs from step 5:nslookup amazon.com COREDNS_POD_IPNote: If you have multiple CoreDNS pods running, perform multiple queries so that at least one query is sent to the pod that you are capturing traffic from.8.    Review the packet capture results.If you experience DNS query timeouts to the CoreDNS pod that you're monitoring and don't see the query in the packet capture, then you might have a network connectivity issue. Make sure to check the network reachability between worker nodes.If you observe a DNS query timeout against a pod IP that you're not capturing from, then follow steps 2-4 to perform another packet capture on the related worker node.To save the results of a packet capture for later reference, add the -w FILE_NAME flag to the tcpdump command. The following example writes the results to a file named capture.pcap:tcpdump -w capture.pcap udp port 53Related informationCoreDNS GA for Kubernetes cluster DNSFollow"


Question: I received a conflicting DNS domain error while creating an interface VPC endpoint. How can I fix this?

"I'm creating a new interface Amazon Virtual Private Cloud (Amazon VPC) endpoint (AWS PrivateLink) for an AWS service, endpoint service, or approved AWS Marketplace service in my VPC. I received the following error message:"private-dns-enabled cannot be set because there is already a conflicting DNS domain."How can I troubleshoot this issue?"

Answer: "I'm creating a new interface Amazon Virtual Private Cloud (Amazon VPC) endpoint (AWS PrivateLink) for an AWS service, endpoint service, or approved AWS Marketplace service in my VPC. I received the following error message:"private-dns-enabled cannot be set because there is already a conflicting DNS domain."How can I troubleshoot this issue?Short descriptionThe following are common reasons for receiving a conflicting DNS domain error when creating an interface VPC endpoint:You already have an interface VPC endpoint for the same service in your VPC.Your VPC is already associated with a private hosted zone that covers the intended service name.ResolutionYou already have an interface VPC endpoint for the same service in your VPCIf you turn on PrivateDNS when creating interface endpoints, then a private hosted zone is automatically created and associated with your VPC. AWS services and AWS Marketplace partner services have PrivateDNS turned on by default. So, creating a second interface VPC endpoint for the same service with PrivateDNS turned on causes the conflicting DNS domain error. To fix this, turn off the PrivateDNS option when creating the interface endpoint. Use endpoint-specific DNS hostnames for the second VPC interface endpoint for that service.Note: For endpoint services, you see this error when turning on the PrivateDNS feature on the endpoints after they are created.Your VPC is already associated with a private hosted zone that covers the intended service nameYou can't create a new private hosted zone with the same namespace for a VPC that already has an existing private hosted zone attached to it. When you create an endpoint with PrivateDNS turned on, the creation of the interface endpoint fails. This is because the endpoint can't create a private hosted zone of the service name. To check if your VPC is associated with an existing private hosted zone, do one of the following:Navigate to your Amazon Route 53 console and check whether you already have a private hosted zone with the intended service name attached to your VPC. If your VPC is associated with an existing private hosted zone, then turn off the PrivateDNS option when creating the interface endpoint. Use endpoint-specific DNS hostnames of the interface endpoint to access it.For central hub architecture, an account in your organization might create a private hosted zone for the service name and attach it to your VPC. In this case, you don't see the private hosted zone in your Route 53 console because the owner is a different account. Use the list-hosted-zones-by-vpc API call to list all hosted zones that your VPC is part of, including hosted zones from other accounts. If your VPC is associated with a private hosted zone in a different account, do the following:Confirm that the A, Alias, or CNAME record points to an active VPC interface endpoint.Then, use the interface endpoint for the service if the routing is in place. If you can't use it, turn off the PrivateDNS option and create a new interface endpoint.Note: Run nslookup or dig from the VPC to perform DNS resolution for the service name. Determine if the service name is resolving to private IPs or public IPs. If it's resolving to private IPs, then there is a private hosted zone for the service name attached to your VPC.Follow"


Question: How do I resolve the "Image does not exist" error when my tasks fail to start in my Amazon ECS cluster?

"My Amazon Elastic Container Service (Amazon ECS) service fails to start tasks in my Amazon ECS cluster. Then, I receive an error similar to the following: "CannotPullContainerError: Error response from daemon: manifest for 1234567890.dkr.ecr.us-east-1.amazonaws.com/test:curlnginx1234 not found." How can I resolve this error?"

Answer: "My Amazon Elastic Container Service (Amazon ECS) service fails to start tasks in my Amazon ECS cluster. Then, I receive an error similar to the following: "CannotPullContainerError: Error response from daemon: manifest for 1234567890.dkr.ecr.us-east-1.amazonaws.com/test:curlnginx1234 not found." How can I resolve this error?Short descriptionThe resolution for this error applies to pulling images from an Amazon Elastic Container Registry (Amazon ECR) repository.If you didn't receive the preceding error message, choose a resolution based on one of the following issues or errors:Your container is exiting due to application issues or resource constraints.The health checks for your Application Load Balancer are failing.Docker can't pull the container image.[AWS service] was unable to place a task because no container instance met all of its requirements.[AWS service] was unable to place a task because no container instance met all of its requirements. The closest matching container-instance container-instance-id has insufficient CPU units available.[AWS service] was unable to place a task because no container instance met all of its requirements. The closest matching container-instance container-instance-id encountered error "AGENT".Note: To troubleshoot Amazon ECS service issues, check for diagnostic information in the service event log.Resolution1.    Verify that the image is declared in your Amazon ECS task definition.2.    Verify that the Docker image exists in the Amazon ECR repository.Note: To view repository information, you can use the Amazon ECR console or run the following commands:To confirm that an image exists in an ECR repository, run the following list-images command:aws ecr list-images --repository-name "hello-world"  --region us-east-1To filter for images in an ECR repository, run the following describe-images command:aws ecr describe-images --repository-name "hello-world" --region us-east-1 --query 'sort_by(imageDetails,& imagePushedAt)[*]'Note: Be sure to update your commands with the name of your ECR repository and AWS Region.3.    Use the full URI for the image when you specify an Amazon ECR image in your task definition.Important: Verify that there are no leading or trailing character spaces in the URI for the image.Follow"


Question: How do I create and prioritize query queues in my Amazon Redshift cluster?

I want to create and prioritize certain query queues in Amazon Redshift.

Answer: "I want to create and prioritize certain query queues in Amazon Redshift.Short descriptionIn Amazon Redshift, you can create extract transform load (ETL) queries, and then separate them into different queues according to priority. Queries can be prioritized according to user group, query group, and query assignment rules.To prioritize your queries, use Amazon Redshift workload management (WLM). Amazon Redshift supports the following WLM configurations:Automatic WLM: When you enable automatic WLM, your query concurrency and memory allocation are managed by Amazon Redshift. Amazon Redshift determines the amount of resources that queries need, and adjusts the amount accordingly. Unlike manual WLM, automatic WLM allows you to set a query priority value to indicate the relative priority of workloads. For both automatic and manual WLM, you can create separate query queues.Manual WLM: Manual WLM is used to manage multiple WLM queues in Amazon Redshift. With manual WLM, you must specify values for WLM query concurrency slots and memory allocation properties. For both automatic and manual WLM, you can create separate query queues. For manual WLM, the default concurrency value is five queries and memory allocation is divided equally. Use manual WLM if you want to manage your own workload or manually assign resources to queries.To prioritize your queries, choose the WLM configuration that best fits your use case.ResolutionAutomatic WLMWhen you enable automatic WLM, Amazon Redshift automatically determines how resources are allocated to each query. Concurrency is adjusted according to your workload.Note: It's a best practice to test automatic WLM on existing queries or workloads before moving the configuration to production.To prioritize your workload in Amazon Redshift using automatic WLM, perform the following steps:Sign in to the AWS Management Console.Open the Amazon Redshift console.From the navigation menu, choose CONFIG.Choose Workload management.Choose the parameter group that you want to modify.Choose the Workload management tab to view the current WLM configuration.(Optional) If your WLM parameter group is set to Automatic WLM mode, then no updates are required.(Optional) If your WLM parameter group is set to Manual WLM mode, modify the WLM configuration for your parameter group. Choose Edit workload queues to edit the WLM configuration. Then, choose Switch WLM mode to switch to Automatic WLM.Choose Add queue to add additional workload queues. You can create separate queues (with a maximum of eight queues) for each workload, associating queues with user groups or query groups.Choose Save.Assign queries to queues.Configure the priority status for your queue. By default, each queue is assigned a "Normal" priority status.Note: Superusers can apply a "Critical" priority status (the highest priority level) to a query. If a workload is marked as "Critical" priority, only one of its queries can be run at each time.(Optional) Create a WLM query monitoring rule to define performance boundaries (such as time limits or concurrency levels) for queries and queues. For example, you can set your query monitoring rule to change a query's priority status if a running query exceeds 40 seconds.Manual WLMWhen you enable manual WLM, each queue is allocated a portion of the cluster's available memory. A queue's memory is divided equally amongst the queue's query slots. If you're managing multiple WLM queues, you can configure workload management (WLM) queues to improve query processing.To prioritize your workload in Amazon Redshift using manual WLM, perform the following steps:Sign in to the AWS Management Console.Open the Amazon Redshift console.From the navigation menu, choose CONFIG.Choose Workload management.Choose the parameter group that you want to modify.Choose the Workload management tab to view the current WLM configuration.(Optional) If your WLM parameter group is set to Manual WLM mode, then no updates are required.(Optional) If your WLM parameter group is set to Automatic WLM mode, modify the WLM configuration for your parameter group. Choose Edit workload queues to edit the WLM configuration. Then, choose Switch WLM mode to switch to Manual WLM.Choose Add queue to add additional workload queues. You can create separate queues (with a maximum of eight queues) for each workload, associating queues with user groups or query groups.Choose Save.Create and define a query assignment rule.Note: Queries are assigned according to user or query group. Queries that aren't assigned run in the default queue.Use WLM dynamic memory allocation to configure the amount of memory allocated to each queue. WLM dynamic memory configuration helps you prioritize your workload according to memory usage.(Optional) Create and define a query monitoring rule to manage queries that reach metric boundaries. For example, you can use a query monitoring rule to hop or cancel a long-running query.Related informationWLM queue assignment rulesWLM system tables and viewsSTV_WLM_QUERY_QUEUE_STATESTV_WLM_QUERY_STATESTV_WLM_SERVICE_CLASS_CONFIGFollow"


Question: Why are the source filter conditions in my AWS DMS task not working?

"I have configured source filter conditions on my AWS Database Migration Service (AWS DMS) task, but they aren't working correctly. How can I troubleshoot issues with source filter conditions on my AWS DMS task?"

Answer: "I have configured source filter conditions on my AWS Database Migration Service (AWS DMS) task, but they aren't working correctly. How can I troubleshoot issues with source filter conditions on my AWS DMS task?Short descriptionThere are several reasons why source filter conditions might not be working as expected on an AWS DMS task. For example, the engine that you're using might not support the use of source filter conditions. Or, you might be affected by one or more of the limitations of the feature.ResolutionCheck if your engine supports the source filtering featureAlthough most AWS DMS sources support source filtering, some sources such as MongoDB or Amazon DocumentDB don't support this feature. Check the AWS DMS documentation about Sources for data migration to confirm whether there are limitations to the source engine that you're using.Review the AWS DMS source filtering limitationsThere are several limitations associated with source filtering. Review the limitations to check that you're using the feature correctly:Filters don't calculate columns of right-to-left languages.Filters can't be applied to large object (LOB) columns.Filters can be applied only to immutable columns that aren't updated after creating. If you apply source filters to mutable columns that can be updated after creation, then the source filters might not work as intended.Troubleshoot filters that stop working during full loadIf your issue persists, check to see at what phase that source filtering stops working.If filtering doesn't work during full load, follow these steps:1.    Confirm that any case sensitivity in the mapping rules match the source engine. For example, object names in Oracle and DB2 are upper case, by default. Similarly, object names in PostgreSQL are lower case. Make sure that the column that you are using in your filtering condition matches any case sensitivity required by your source engine.2.    When you filter with date datatypes, check that you are using the formats that AWS DMS requires. For example, AWS DMS uses the date format YYYY-MM-DD and the time format YYYY-MM-DD HH:MM:SS for filtering.3.    Reproduce the issue with debut logging level on SOURCE_UNLOAD. Then, capture the query that AWS DMS runs on the source to unload the data. This is an example of a filtering problem on a source Oracle table.Table details:CREATE TABLE DMS.FILTERS( ID NUMBER(10) NOT NULL,  ENTRY_DATE DATE,  CONSTRAINT FILTERS_PK PRIMARY KEY (ID));SQL> SELECT * FROM FILTERS;  ID       ENTRY_DATE---------- ---------         1 01-JAN-22         2 01-JUN-22         3 01-JAN-21         4 01-JUN-21         5 01-JAN-20         6 01-JUN-20An AWS DMS task is created with the mapping rules to replicate only rows with ENTRY_DATE greater than or equal to 01/01/2022:{  "rules": [    {      "rule-type": "selection",      "rule-id": "893662253",      "rule-name": "893662253",      "object-locator": {        "schema-name": "DMS",        "table-name": "FILTERS"      },      "rule-action": "include",      "filters": [        {          "filter-type": "source",          "column-name": "ENTRY_DATE",          "filter-conditions": [            {              "filter-operator": "gte",              "value": "01/01/2022"            }          ]        }      ]    }  ]}So, no records are replicated, and the task logs shows these errors:01786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]E:  ORA-01843: not a valid month  [1020417]  (oracle_endpoint_unload.c:171)Because debug logs are turned on for SOURCE_UNLOAD, the task logs show the exact query that AWS DMS runs on the source database:1786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]D:  Select statement for UNLOAD is 'SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))))'  (oracle_endpoint_utils.c:1979)In the log output, you can see that AWS DMS runs this query on the source database:SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))));AWS DMS doesn't recognize the date provided in the mapping rules because it doesn't match the date format that AWS DMS expects. So, modify the mapping rules to match the expected date format:{                            "filter-operator": "gte",                            "value": "2022-01-01"                        }Troubleshoot filters that stop working during CDCNote: Apply filters only to immutable columns that aren't updated after creation. Adding filters on changeable columns can cause unexpected results.If the columns that you use in filtering are immutable columns, you might note that filtering issues happen only during the CDC phase. Also, these issues might occur only on specific DML statements like UPDATES or DELETES. In this scenario, make sure that you have enabled sufficient logging on the source table. Follow these steps to allocate additional logging, depending on the engine you are using:OracleOracle uses supplemental logging to add additional logs on table columns. If the column that you're filtering isn't a primary key column, make sure that supplemental logging is activated for that column and primary key columns.This example replicates a table named TEST.LOGGING with a primary key ID and a filter on the column NAME. Run a command similar to the following to create the log group supplemental logging:ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;If supplemental logging is already added on all columns in a table, such as in this example, then you don't need to add more logging.ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;PostgreSQLPostgreSQL uses the REPLICA IDENTITY property to configure the logging level for a table. When REPLICA IDENTITY is set to default, then PostgreSQL records the old values of the columns of the primary key in WAL logs. But, the default logging level might not be sufficient for DELETES when you use a non-primary key column in filtering. In this scenario, perform the following steps depending on the plugin that the AWS DMS task is using: If test_decoding is used:Set REPLICA IDENTITY to full on the table. If you don't complete this step, then AWS DMS might send all the deletes to target table:ALTER TABLE tablename REPLICA IDENTITY FULL;If pglogical is used:Set REPLICA IDENTITY to full after the table is added to the replication set. This is because pglogical has a limitation that prevents the table from being added to a replication set if REPLICA IDENTITY is full.ALTER TABLE tablename REPLICA IDENTITY FULL;Note: Setting REPLICA IDENTITY to full on a table increases the number of WAL logs that are generated on the source database. This happens because all columns are then logged in WAL.SQL ServerIf you are using SQL Server, check that all of the AWS DMS CDC prerequisites are met, specifically these logging requirements:For every table with a primary key, run this query to turn on MS-CDC: Note: If MS-Replication is already used for on-premises sources, then skip this step. This step is required for cloud-based sources.exec sys.sp_cdc_enable_table@source_schema = N'schema_name',@source_name = N'table_name',@role_name = NULL,@supports_net_changes = 1GORun this query to turn on MS-CDC for every table with unique keys but no primary key. Note: This step is required for both on-premises and cloud-based sources.exec sys.sp_cdc_enable_table@source_schema = N'schema_name',@source_name = N'table_name',@index_name = N'unique_index_name',@role_name = NULL,@supports_net_changes = 1GORun this query to turn on MS-CDC for every table with no primary or unique keys/ Note: This step is required for both on-premises and cloud-based sources.exec sys.sp_cdc_enable_table@source_schema = N'schema_name',@source_name = N'table_name',@role_name = NULLGOMySQLIn MySQL, row images in binlogs are controlled by the binlog_row_image system variable. AWS DMS requires that binlog_row_image is set to full and binlog_format is set to ROW. This means that MySQL logs all columns in both the before image and the after image. So, make sure that binlog_row_image is set to full on the source database to confirm the maximum logging level in the binlogs.Related informationHow do I use source filters in my AWS DMS tasks?Using table mapping to specify task settingsUsing source filtersFollow"


Question: How do I change the public IP address of my customer gateway for my AWS VPN connection?

"The public IP address for my customer gateway has changed, and I need to update my AWS Virtual Private Network (AWS VPN) connection to reflect this change."

Answer: "The public IP address for my customer gateway has changed, and I need to update my AWS Virtual Private Network (AWS VPN) connection to reflect this change.ResolutionFollow the instructions to create a customer gateway with the new public IP address assigned to your customer gateway. Then, follow the instructions to change the customer gateway for a Site-to-Site VPN connection.Related informationHow do I create a certificate-based VPN using AWS Site-to-Site VPN?Follow"


Question: How do I troubleshoot high CPU utilization on my Amazon OpenSearch Service cluster?

My data nodes are showing high CPU usage on my Amazon OpenSearch Service cluster.

Answer: "My data nodes are showing high CPU usage on my Amazon OpenSearch Service cluster.Short descriptionIt's a best practice to maintain your CPU utilization to make sure that OpenSearch Service has enough resources to perform its tasks. A cluster that consistently performs at high CPU utilization can degrade cluster performance. When your cluster is overloaded, OpenSearch Service stops responding, resulting in a timeout request.To troubleshoot high CPU utilization on your cluster, consider the following approaches:Use the nodes hot threads API.Check the write operation or bulk API thread pool.Check the search thread pool.Check the Apache Lucene merge thread pool.Check the JVM memory pressure.Review your sharding strategy.Optimize your queries.ResolutionUse the nodes hot threads APIIf there are constant CPU spikes in your OpenSearch Service cluster, then use the nodes hot threads API. The nodes hot threads API acts as a task manager, showing you the breakdown of all resource-intensive threads that are running on your cluster.Example output of the nodes hot threads API:GET _nodes/hot_threads100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][search][T#62]'10/10 snapshots sharing following 10 elements sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737) java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647) java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269) org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)java.lang.Thread.run(Thread.java:745)Note: The nodes hot threads output lists information for each node. The length of your output depends on how many nodes are running in your OpenSearch Service cluster.Additionally, use the cat nodes API to view the current breakdown of resource utilization. You can narrow down the subset of nodes with the highest CPU utilization with the following command:GET _cat/nodes?v&s=cpu:descThe last column in your output displays your node name. For more information, see cat nodes API on the Elasticsearch website.Then, pass on the relevant node name to your hot threads API:GET _nodes/<node-name>/hot_threadsFor more information, see Hot threads API on the Elasticsearch website.Example nodes hot threads output:<percentage> of cpu usage by thread 'opensearch[<nodeName>][<thread-name>]'The thread name indicates which OpenSearch Service processes are consuming high CPU.For more information, see Nodes hot threads API on the Elasticsearch website.Check the write operation or bulk API thread poolA 429 error in OpenSearch Service might indicate that your cluster is handling too many bulk indexing requests. When there are constant CPU spikes in your cluster, OpenSearch Service rejects the bulk indexing requests.The write thread-pool handles indexing requests, which include Bulk API operations. To confirm whether your cluster is handling too many bulk indexing requests, check the IndexingRate metric in Amazon CloudWatch.If your cluster is handling too many bulk indexing requests, then consider the following approaches:Reduce the number of bulk requests on your cluster.Reduce the size of each bulk request, so that your nodes can process them more efficiently.If Logstash is used to push data into your OpenSearch Service cluster, then reduce the batch size or the number of workers.If your cluster's ingestion rate slows down, then scale your cluster (either horizontally or vertically). To scale up your cluster, increase the number of nodes and instance type so that OpenSearch Service can process the incoming requests.For more information, see Bulk API on the Elasticsearch website.Check the search thread poolA search thread pool that consumes high CPU indicates that search queries are overwhelming your OpenSearch Service cluster. Your cluster can be overwhelmed by a single long-running query. An increase in queries performed by your cluster can also affect your search thread pool.To check whether a single query is increasing your CPU usage, use the task management API. For example:GET _tasks?actions=*search&detailedThe task management API gets all active search queries that are running on your cluster. For more information, see Task management API on the Elasticsearch website.Note: The output only includes the description field if there's a search task listed by the task management API.Example output:{    "nodes": {        "U4M_p_x2Rg6YqLujeInPOw": {            "name": "U4M_p_x",            "roles": [                "data",                "ingest"            ],            "tasks": {                "U4M_p_x2Rg6YqLujeInPOw:53506997": {                    "node": "U4M_p_x2Rg6YqLujeInPOw",                    "id": 53506997,                    "type": "transport",                    "action": "indices:data/read/search",                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",                    "start_time_in_millis": 1541423217801,                    "running_time_in_nanos": 1549433628,                    "cancellable": true,                    "headers": {}                }            }        }    }}Check the description field to identify which query is run. The running_time_in_nanos field indicates the amount of time a query been running. To decrease your CPU usage, cancel the search query that's consuming high CPU. The task management API also supports a _cancel call.Note: Make sure to record the task ID from your output to cancel a particular task. In this example, the task ID is "U4M_p_x2Rg6YqLujeInPOw:53506997".Example task management POST call:POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancelThe Task Management POST call marks the task as "cancelled", releasing any dependent AWS resources. If you have multiple queries running on your cluster, then use the POST call to cancel queries one at a time. Cancel each query until your cluster returns to a normal state. It's also a best practice to set a timeout value in the query body, to prevent high CPU spikes. For more information, see Request body search parameters on the Elasticsearch website. To verify if the number of active queries has decreased, check the SearchRate metric in Amazon CloudWatch.Note: Canceling all active search queries at the same time in your OpenSearch Service cluster can cause errors on the client application side.For more information, see Thread pools on the Elasticsearch website.Check the Apache Lucene merge thread poolOpenSearch Service uses Apache Lucene for indexing and searching documents on your cluster. Apache Lucene runs merge operations to reduce the effective number of segments needed for each shard and to remove any deleted documents. This process is run whenever new segments are created in a shard.If you observe an Apache Lucene merge thread operation impacting the CPU usage, then increase the refresh_interval setting of your OpenSearch Service cluster indices. The increase in the refresh_interval setting slows down segment creation of your cluster.Note: A cluster that's migrating indices to UltraWarm storage can increase your CPU utilization. An UltraWarm migration usually involves a force merge API operation, which can be CPU-intensive.To check for UltraWarm migrations, use the following command:GET _ultrawarm/migration/_status?vFor more information, see Merge on the Elasticsearch website.Check the JVM memory pressureReview your JVM memory pressure percentage of the Java heap in a cluster node. If JVM memory pressure reaches 75%, Amazon OpenSearch Service triggers the Concurrent Mark Sweep (CMS) garbage collector. If JVM memory pressure reaches 100%, then OpenSearch Service JVM is configured to exit and eventually restarts on OutOfMemory (OOM).In the following example log, the JVM is within the recommended range, but the cluster is impacted by long running garbage collection:[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService] [515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s] collecting in the last [10.2s]For more information, see How do I troubleshoot high JVM memory pressure on my Amazon OpenSearch Service cluster?Review your sharding strategyDepending on the cluster size, your cluster might degrade in performance with too many shards. It's a best practice to have no more than 25 shards per GiB of Java heap.By default, Amazon OpenSearch Service has a sharding strategy of 5:1, where each index is divided into five primary shards. Within each index, each primary shard also has its own replica. OpenSearch Service automatically assigns primary shards and replica shards to separate data nodes, and makes sure that there's a backup in case of failure.For more information, see How do I rebalance the uneven shard distribution in my Amazon OpenSearch Service cluster?Optimize your queriesHeavy aggregations, wildcard queries (especially leading wildcards), and regex queries might be computationally expensive and cause CPU utilization spikes. Searching slow logs and indexing slow logs can help you diagnose expensive and problematic queries.For more information, see Monitoring OpenSearch logs with Amazon CloudWatch Logs.Related informationHow can I improve the indexing performance on my Amazon OpenSearch Service cluster?How do I resolve search or write rejections in Amazon OpenSearch Service?Sizing Amazon OpenSearch Service domainsFollow"


Question: Why can't I connect to my Elastic Beanstalk instance using SSH?

I can't connect to the Amazon Elastic Compute Cloud (Amazon EC2) instances in my AWS Elastic Beanstalk environment using SSH. How do I troubleshoot this issue?

Answer: "I can't connect to the Amazon Elastic Compute Cloud (Amazon EC2) instances in my AWS Elastic Beanstalk environment using SSH. How do I troubleshoot this issue?ResolutionBefore you connect to your instance using SSH, confirm the following:Your Amazon EC2 instance is in a public subnet and has a public IP address.You have an inbound rule on port 22 on the security group of your instances that allows your IP address or range of IP addresses to connect to your instance.You meet all the general prerequisites for connecting to your instance.If you continue to experience timeout issues and still can't connect to your instance, then the SSH daemon on your instance could be crashing due to high memory utilization.To troubleshoot memory issues, monitor the memory metrics of your Elastic Beanstalk instances using Amazon CloudWatch metrics.Follow"


Question: Why do I get an HTTP 403 Forbidden error when connecting to my API Gateway APIs from a VPC?

"I'm calling my Amazon API Gateway APIs from my virtual private cloud (VPC), but I get an HTTP 403 Forbidden error. Why is that?"

Answer: "I'm calling my Amazon API Gateway APIs from my virtual private cloud (VPC), but I get an HTTP 403 Forbidden error. Why is that?Short descriptionThe HTTP 403 Forbidden error most commonly occurs when private DNS is enabled for an API Gateway interface VPC endpoint that's associated with a VPC. In this scenario, all requests from the VPC to API Gateway APIs resolve to that interface VPC endpoint. However, it's not possible to connect to public APIs using a VPC endpoint.The private DNS name of a VPC endpoint is in the format *.execute-api.<REGION>.amazonaws.com. This format matches the API Gateway default invoke URL for public and private APIs. For example, the default invoke URL of a public API is https://abcd1234.execute-api.us-east-1.amazonaws.com where abcd1234 is the API ID and us-east-1 is the AWS Region of the API.When a private DNS is enabled on a VPC endpoint, the API's invoke URL is covered by the private DNS name *.execute-api.us-east-1.amazonaws.com where * is a placeholder for the API ID. When a DNS query is resolved for a public API from inside a VPC, the resolved DNS points to the private IP of the associated VPC endpoint instead of the public IP of the public API. The API call is then routed to the public API through the VPC endpoint instead of routing it through the internet. Because VPC endpoints can route traffic only to private APIs, the result is an HTTP 403 error.If private DNS isn't enabled for your interface VPC endpoint, or there is no endpoint in your VPC, go to the Connect to public APIs when private DNS isn't enabled section.ResolutionConfirm that a private DNS is enabled for an interface VPC endpoint associated with your VPCCheck your VPC to see if there's an interface VPC endpoint to access a private API. If there's an interface endpoint, check to see if the private DNS settings are enabled. For more information, see DNS attributes in your VPC.Connect to public APIs with private DNS enabledIf private DNS is enabled, set up edge-optimized custom domain names or regional custom domain names to connect to your public APIs.Important: Resources in your VPC that try to connect to your public APIs must have internet connectivity. Also, when configuring DNS records for a regional custom domain name, you must use A type alias records. However, with edge-optimized custom domain names, use either A type alias records or CNAME records.Connect to public APIs when private DNS isn't enabledIf private DNS isn't enabled in the interface VPC endpoint, or there is no endpoint in your Amazon Virtual Private Cloud (Amazon VPC) configuration, confirm that the following is true:Security groups for your VPC allow outbound traffic to your public API.The resource policy attached to your API doesn't deny access from the VPC.When your VPC has permission to access your public APIs, use public DNS to connect to your public APIs. For more information, see Controlling and managing access to a REST API in API Gateway.(Optional) Change the private DNS setting for an interface VPC endpointUsers can change the private DNS setting for an interface VPC endpoint at any time. Changing this setting affects the resolution of an API's stage URL to the private IP of the interface VPC endpoint.Note: Changing the private DNS setting affects how users can connect to private APIs and public APIs from a VPC.In the Amazon VPC console, open the Endpoints pane.Select the interface VPC endpoint.Choose Actions, and then choose Modify Private DNS names.For Enable Private DNS Name, select or clear the Enable for this endpoint check box.Choose Modify Private DNS names.For more information, see View and update DNS attributes for your VPC.Related informationAccess an AWS service using an interface VPC endpointSetting up custom domain names for REST APIsDNS attributes for your VPCFollow"


Question: How do I resolve managed node group errors in an Amazon EKS cluster?

I have issues with my managed node group in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I have issues with my managed node group in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.Short descriptionYou receive an error when you register a node with the API server.If you use an incorrect DHCP option in your custom DNS, then you receive the following error:Node "ip-x-x-x-x.eu-region.compute.internal" is invalid: metadata.labels: Invalid valueTo resolve the issue, complete the steps in the Check your DHCP options section of Resolution.You receive an error when you launch an Amazon Elastic Compute Cloud (Amazon EC2) instance in an Auto Scaling group with an Amazon Elastic Block Store (Amazon EBS) volume that's encrypted with a KMS key.Example error:AccessDeniedException: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSServiceRoleForAutoScaling/AutoScaling is not authorized to perform: kms:GenerateDataKeyWithoutPlaintext on resource: ARN of KMS keyIf a managed node uses an Amazon EBS volume that's encrypted with a KMS key, then the Auto Scaling group service role doesn't have access to it. To set up a key policy, see the Configure a key policy for your EBS volume encryption section of Resolution.Your managed node group is in Degraded status because the EC2 launch template version doesn't match the version that Amazon EKS created.If you manually update the launch template directly from the Auto Scaling group, then you receive the following error:Ec2LaunchTemplateVersionMismatchTo resolve the issue, complete the steps in the Update the launch template version section of Resolution.For other resolutions of failed nodes in managed node groups, see How can I get my worker nodes to join my Amazon EKS cluster?ResolutionCheck your DHCP optionsVerify that your hostname contains no more than 63 characters. To review your DHCP options, see Work with DHCP option sets.Specify your hostname to match the AWS Region. For an AmazonProvidedDNS server in us-east-1, specify ec2.internal. For an AmazonProvidedDNS server in other AWS Regions, specify region.compute.internal.Example of a DHCP option set in us-east-1:domain-name: ec2.internaldomain-name-servers: AmazonProvidedDNSExample of a DHCP option set in other Regions:domain-name: region name.compute.internaldomain-name-servers: AmazonProvidedDNSExample of a DHCP option set from a custom DNS:domain-name:custom DNS namedomain-name-servers: domain name serverNote: Replace region name with your Region, custom DNS name with your DNS name, and domain name server with your domain name server.For more information, see the domain-name section of Overview of DHCP option sets.Note: If your DHCP options set is associated with a VPC that has instances with multiple operating systems, it's a best practice to specify only one domain name.Configure a key policy for your EBS volume encryptionThe Auto Scaling group service role must have the following permissions to work with encrypted EBS volumes:kms:Encryptkms:Decryptkms:ReEncrypt*kms:GenerateDataKey*kms:DescribeKeykms:CreateGrantTo configure the correct KMS key policy, see Required AWS KMS key policy for use with encrypted volumes.To allow more IAM roles to work with encrypted EBS volumes, you can modify the key policies. For more information, see Allows key users to use the KMS key.For more information on KMS key access management, see Managing access to KMS keys.Update the launch template versionNote: Before you update your EC2 launch template from the managed node group, create a new version. For more information, see Create a new launch template using parameters you define.To update your EC2 launch template from the managed node group, complete the following steps:Open the EKS console.Select the cluster that contains the node group to update.Choose the Configuration tab, then choose the Compute tab.On the node groups page under launch templates, choose Change version.Select the version to apply to your node group. Make sure that the update strategy is set to Rolling Update.Choose Update.Note: It's a best practice to update the node group with the new version of the EC2 launch template.If you haven't used a custom launch template and you get the Ec2LaunchTemplateVersionMismatch error, then your worker nodes aren't using the same version as the EKS node group. To resolve this issue, go to the Auto Scaling console to revert to the version that EKS created. For more information, see Managed node group errors.Follow"


Question: Why did the bands of my anomaly detector in CloudWatch change suddenly?

I created an anomaly detection band on my Amazon CloudWatch metric but the band has changed significantly. Why did my anomaly band shift?

Answer: "I created an anomaly detection band on my Amazon CloudWatch metric but the band has changed significantly. Why did my anomaly band shift?ResolutionCloudWatch applies statistical and machine learning algorithms when you enable anomaly detection for a metric. These algorithms analyze the metric, detect normal baselines, and then surface anomalies with no user intervention. The algorithms generate an anomaly detection model. The model generates a range of expected values that represent normal metric behavior.After you create a model, CloudWatch anomaly detection continually evaluates the model and makes adjustments. It does this to make sure that its analysis is as accurate as possible. If another anomaly detection model that is trained with the most recent data performs better than the current model, then CloudWatch anomaly detection switches to the new model. This can cause the anomaly detection bands to shift.Related informationUsing CloudWatch anomaly detectionFollow"


Question: How do I troubleshoot the container health check failures for Amazon ECS tasks?

My Amazon Elastic Container Service (Amazon ECS) task is failing the container heath check. How do I resolve this?

Answer: "My Amazon Elastic Container Service (Amazon ECS) task is failing the container heath check. How do I resolve this?Short descriptionIf you receive the following error, then the Amazon ECS containers in your task are using health checks that your service can't pass:(service AWS-Service) (task ff3e71a4-d7e5-428b-9232-2345657889) failed container health checksNote: If you're experiencing Elastic Load Balancing (ELB) health check issues, see How can I get my Amazon ECS tasks running to pass the Application Load Balancer health check in Amazon ECS?ResolutionTo troubleshoot Amazon ECS container health check failures, try the following tips:Test the container locally to make sure that it passes the container health checks before provisioning to Amazon ECS.Confirm that the command that you're passing to the container is correct and that you're using the correct syntax for your Amazon ECS tasks.Make sure that your container has enough time to instantiate.If your Amazon ECS task has been running for a while, check your application logs and Amazon CloudWatch logs.Test the container locally to make sure it passes the container health checkBefore provisioning your container to Amazon ECS, make sure that your container can work as expected and pass the specified container health check. You can test your container with the Dockerfile HEALTHCHECK configuration on the Docker website. After your container passes the health check defined in Dockerfile, you can specify the health check configuration in the task definition. Specifying the health check configuration allows the Amazon ECS container agent to monitor and report the health check specified.Note: Amazon ECS doesn't monitor Docker health checks that are embedded in a container image and aren't specified in the container definition. Health check parameters that are specified in a container definition override any Docker health checks that exist in the container image.Confirm that you're using the correct syntax for your Amazon ECS tasksMake sure that you're using the correct commands and syntax for your Amazon ECS tasks.For example, if you use the AWS Management Console JSON panel, the AWS Command Line Interface (AWS CLI), or APIs, then enclose the list of commands in brackets, like this:["CMD-SHELL", "curl -f http://localhost/ || exit 1"]If you're using the AWS Management Console to edit your ECS task, then you don't need to include the brackets:"CMD-SHELL", "curl -f http://localhost/ || exit 1"Also, make sure that you're not separating the health check command with double quotes, such as ["CMD-SHELL", "healthcheck.sh", "||", "exit 1"]. Instead, use the following command syntax:["CMD-SHELL", "healthcheck.sh || exit 1"]Make sure that your container has enough time to instantiateIf your container takes a while to initiate, then your container could fail the container health check. Try setting the startPeriod in the advanced container definition parameter. This gives your Amazon ECS container enough time to bootstrap before any failed health checks are included in the maximum number of retries.Check your application logs and Amazon CloudWatch logs if the task has been running for a whileIf your Amazon ECS container has been running for a while and it fails the container health check, check your application logs. If your Amazon ECS task uses awslogs log driver, then check your application logs on Amazon CloudWatch.Note: AWS Fargate is a managed service. Therefore, you can't access the underlying infrastructure. To troubleshoot, launch your Amazon ECS tasks in Amazon Elastic Compute Cloud (Amazon EC2). Then, connect to your Amazon EC2 instances using SSH. You can also try using Amazon ECS Exec to interact directly with your ECS containers.Follow"


Question: How do I create Amazon S3 lifecycle configuration rules for noncurrent object versions?

I want to create Amazon Simple Storage Service (Amazon S3) lifecycle configuration rules for noncurrent object versions.

Answer: "I want to create Amazon Simple Storage Service (Amazon S3) lifecycle configuration rules for noncurrent object versions.ResolutionLifecycle rule for transitioning noncurrent objectsTo transition noncurrent versions, Amazon S3 uses the NoncurrentVersionTransition action. Use this action to specify when Amazon S3 must transition objects to the specified storage class.Follow these steps to create a lifecycle rule for transitioning noncurrent object versions:Open the Amazon S3 console.In the list of buckets, choose the bucket that you want to create the lifecycle rule for.Choose the Management tab, and then choose Create lifecycle rule.For Lifecycle rule name, enter a name for your rule.For Choose a rule scope:To apply this lifecycle rule for a particular prefix, select Limit the scope of this rule using one or more filters.To apply the lifecycle rule for the whole bucket, select Apply to all objects in the bucket.If you selected Limit the scope of this rule using one or more filters, then enter the prefix name.If you selected Apply to all objects in the bucket, then select I acknowledge that this rule will apply to all objects in the bucket.Under Lifecycle rule actions, select Move noncurrent versions of objects between storage classes to create a lifecycle rule.In the Transition noncurrent versions of objects between storage classes field:For Choose storage class transitions, choose the desired storage class.For Days after objects become noncurrent, enter the number of days that the object can be noncurrent before S3 transitions the object version.For Number of newer versions to retain, select the number of versions that you want to retain in the storage class.Choose Create rule.If the rule doesn't contain any errors, Amazon S3 turns it on. You can see the rule on the Management tab under Lifecycle rules.Lifecycle rule for expiration of noncurrent objectsTo delete noncurrent versions, Amazon S3 uses the NoncurrentVersionExpiration action. Use this action to specify when Amazon S3 must permanently delete noncurrent versions of objects. These deleted objects can't be recovered.Follow these steps to create a lifecycle rule for expiration of noncurrent object versions:Open the Amazon S3 console.In the list of buckets, choose the bucket that you want to create the lifecycle rule for.Choose the Management tab, and then choose Create lifecycle rule.For Lifecycle rule name, enter a name for your rule.For Choose a rule scope:To apply this lifecycle rule for a particular prefix, select Limit the scope of this rule using one or more filters.To apply the lifecycle rule for the whole bucket, select Apply to all objects in the bucket.If you selected Limit the scope of this rule using one or more filters, enter the prefix name.If you selected Apply to all objects in the bucket, select I acknowledge that this rule will apply to all objects in the bucket.Under Lifecycle rule actions, select to create a lifecycle rule.In the Permanently delete noncurrent versions of objects field:For Days after objects become noncurrent, enter the number of days that the object can be noncurrent before S3 permanently deletes them.For Number of newer versions to retain, select the number of versions that you want to retain in the storage class.Choose Create rule.If the rule doesn't contain any errors, Amazon S3 turns it on. You can see the rule on the Management tab under Lifecycle rules.Follow"


Question: How can I manage my AWS Backup settings using AWS CloudFormation templates?

"I want to use AWS Backup to back up my data from other AWS resources. Additionally, I want to use an AWS CloudFormation template to manage my AWS Backup configurations. How can I do that?"

Answer: "I want to use AWS Backup to back up my data from other AWS resources. Additionally, I want to use an AWS CloudFormation template to manage my AWS Backup configurations. How can I do that?Short descriptionYou can create CloudFormation templates using the supported AWS Backup resource types. Example CloudFormation templates that you can create for AWS Backup include:A template to create a backup plan and assign a resource to the backup plan.A template to create a backup plan, create a backup vault, and assign a resource to the backup plan.ResolutionImportant: Your backup plan must specify the tag that assigns resources to the backup plan. Before you set the backup plan, decide on the tag. Then, verify that the tag is assigned to the correct resources and that it's written correctly in the backup plan.Template to create a backup plan and assign a resource to the backup planThe following example CloudFormation template in YAML does the following:Creates a backup plan named BackupPlanWithThinBackups.Sets backups to be stored in the vault named Default.Creates a backup rule named RuleForDailyBackups that's scheduled to run a daily backup at 11:25AM.Enables Windows VSS.Sets the lifecycle of the backups to be deleted seven days after they're created.Sets the CopyAction to copy backups to the us-west-2 AWS Region for disaster recovery.Uses the AWS Identity and Access Management (IAM) role named AWSBackupDefaultServiceRole to run the backup job.Assigns the backup plan to all resources that are tagged with the key backupplan and the value dsi-sandbox-daily.AWSTemplateFormatVersion: 2010-09-09Description: >-  Backup Plan template to back up all resources tagged with backupplan=dsi-sandbox-daily at 11:25am  UTC.Resources:  BackupPlanWithThinBackups:    Type: "AWS::Backup::BackupPlan"    Properties:      BackupPlan:        BackupPlanName: "BackupPlanWithThinBackups"        AdvancedBackupSettings:          -            ResourceType: EC2            BackupOptions:              WindowsVSS: enabled        BackupPlanRule:          -            RuleName: "RuleForDailyBackups"            TargetBackupVault: Default            ScheduleExpression: "cron(25 11 ? * * *)"            Lifecycle:              DeleteAfterDays: 7            CopyActions:              -                  DestinationBackupVaultArn: arn:aws:backup:us-west-2:111222333444:backup-vault:Default                  Lifecycle:                   DeleteAfterDays: 14  TagBasedBackupSelection:    Type: "AWS::Backup::BackupSelection"    Properties:      BackupSelection:        SelectionName: "TagBasedBackupSelection"        IamRoleArn: !Sub "arn:aws:iam::111222333444:role/service-role/AWSBackupDefaultServiceRole"        ListOfTags:         -           ConditionType: "STRINGEQUALS"           ConditionKey: "backupplan"           ConditionValue: "dsi-sandbox-daily"      BackupPlanId: !Ref BackupPlanWithThinBackups    DependsOn: BackupPlanWithThinBackupsTemplate to create a backup plan, create a backup vault, and assign a resource to the backup planThe following example CloudFormation template in YAML does the following:Creates a backup vault named Default.Creates a backup plan named BackupPlanWithThinBackups.Sets backups to be stored in the vault BackupVaultWithThinBackups.Creates a backup rule named RuleForDailyBackups that's scheduled to run a daily backup. These backups are set to be deleted seven days after they're created.Enables Windows VSS.Sets the CopyAction to copy backups to the us-west-2 AWS Region for disaster recovery. These backups are set to be deleted 14 days after they're created.Creates a backup rule named RuleForWeeklyBackups that's scheduled to run a weekly backup every Monday at 11:00 AM. These backups are set to be deleted 28 days after they're created.Creates a backup rule named RuleForMonthlyBackups that's scheduled to run a backup on the first day of every month at 11:00 AM. These backups are set to be deleted 90 days after they're created.Uses the IAM role named AWSBackupDefaultServiceRole to run the backup job.Assigns the backup plan to all resources that are tagged with the key backup and the value thinbackup.AWSTemplateFormatVersion: "2010-09-09"Description: "Backup Plan template for thin backups"Resources:  BackupVaultWithThinBackups:    Type: "AWS::Backup::BackupVault"    Properties:      BackupVaultName: "BackupVaultWithThinBackups"  BackupPlanWithThinBackups:    Type: "AWS::Backup::BackupPlan"    Properties:      BackupPlan:        BackupPlanName: "BackupPlanWithThinBackups"        AdvancedBackupSettings:          -            ResourceType: EC2            BackupOptions:              WindowsVSS: enabled        BackupPlanRule:          -            RuleName: "RuleForDailyBackups"            TargetBackupVault: !Ref BackupVaultWithThinBackups            ScheduleExpression: "cron(25 11 ? * * *)"            Lifecycle:              DeleteAfterDays: 7            CopyActions:              -                  DestinationBackupVaultArn: arn:aws:backup:us-west-2:111222333444:backup-vault:Default                  Lifecycle:                   DeleteAfterDays: 14          -            RuleName: "RuleForWeeklyBackups"            TargetBackupVault: !Ref BackupVaultWithThinBackups            ScheduleExpression: "cron(0 11 ? * 2 *)"            Lifecycle:              DeleteAfterDays: 28            CopyActions:              -                  DestinationBackupVaultArn: arn:aws:backup:us-west-2:111222333444:backup-vault:Default                  Lifecycle:                   DeleteAfterDays: 14          -            RuleName: "RuleForMonthlyBackups"            TargetBackupVault: !Ref BackupVaultWithThinBackups            ScheduleExpression: "cron(0 11 1 * ? *)"            Lifecycle:              DeleteAfterDays: 90            CopyActions:              -                  DestinationBackupVaultArn: arn:aws:backup:us-west-2:111222333444:backup-vault:Default                  Lifecycle:                   DeleteAfterDays: 14    DependsOn: BackupVaultWithThinBackups  TagBasedBackupSelection:    Type: "AWS::Backup::BackupSelection"    Properties:      BackupSelection:        SelectionName: "TagBasedBackupSelection"        IamRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/service-role/AWSBackupDefaultServiceRole"        ListOfTags:         -           ConditionType: "STRINGEQUALS"           ConditionKey: "backup"           ConditionValue: "thinbackup"      BackupPlanId: !Ref BackupPlanWithThinBackups    DependsOn: BackupPlanWithThinBackupsRelated informationTroubleshooting AWS BackupFollow"


Question: How do I configure Direct Connect and VPN failover with Transit Gateway?

I want to configure AWS Direct Connect as the primary link to my on-premises resources. I also want to configure a VPN as the secondary link to the same resources. How can I do this with AWS Transit Gateway?

Answer: "I want to configure AWS Direct Connect as the primary link to my on-premises resources. I also want to configure a VPN as the secondary link to the same resources. How can I do this with AWS Transit Gateway?ResolutionTask 1:Create a transit gatewayTask 2: Attach your VPC to your transit gatewayTask 3: Create an AWS Site-to-Site VPN and attach it to your transit gatewayNote: If you have a static VPN, make sure that the defined static routes use a less specific CIDR than any dynamic propagated routes. For routes that use the same CIDR, static routes have a higher precedence than dynamic propagated routes in the Transit Gateway route evaluation order.Task 4: Attach your Direct Connect gateway to your transit gatewayFor each VPC as an attachment to your transit gateway, you must add the VPC CIDR range to the Direct Connect Gateway allowed prefix interaction. After the prefixes are added, they're advertised to the remote side over Transit Virtual Interface. You can have a maximum of 20 prefixes per AWS Transit Gateway from AWS to on-premises on a transit virtual interface. This quota can't be increased. For more information, see AWS Direct Connect quotas. If you have more than 20 VPCs, summarize the routes for multiple VPCs into a single CIDR range. Enter the summarized routes in the Direct Connect Gateway allowed prefix interaction section.If you create a summarized route for VPC CIDRs, then the CIDRs advertised over VPN are more specific than the CIDRs advertised over Direct Connect. As a result, the customer gateway prioritizes the VPN over the Direct Connect connection.To resolve this issue:Add the summarized route associated with the Direct Connect Gateway. For the target attachment, select a VPC with a CIDR that's part of the summarized route to the Site-to-Site VPN attachment transit gateway route table. The summarized route and specific routes are now both advertised over the Site-to-Site VPN.In the customer gateway, filter out the specific routes advertised over the Site-to-Site VPN. The customer gateway now has the same summarized routes over both connections. The gateway prefers the Direct Connect connection.Task 5: Create transit gateway route tables, and then turn on route propagation for all attachmentsNote: Be sure to advertise the same prefix on the Border Gateway Protocol (BGP) session on the Direct Connect Transit Virtual Interface (VIF). Or, advertise the same prefix on the BGP session over the VPN.Open the Amazon Virtual Private Cloud (Amazon VPC) console.From the navigation pane, choose Transit Gateways.Verify that the Default association route table setting for your transit gateway is set to False.Note: If the setting is set to True, skip to task 6.Choose Transit Gateway Route Tables.Choose Create Transit Gateway Route Table and then complete the following:For Name tag, enter Route Table A.For Transit Gateway ID, choose the Transit Gateway ID for your transit gateway.Choose Create Transit Gateway Route Table.Choose Route Table A (or the default route table of your transit gateway) and choose Associations, Create Association.For Choose attachment to associate, choose the association IDs for your VPCs and choose Create Association. Repeat this step until your Direct Connect gateway, VPN, and VPCs all display under Association.Choose Route Table Propagation.Choose Propagation. For Choose attachment to propagate, choose your Direct Connect gateway, VPN, and VPCs.Task 6: Configure the route table associated with your VPC and attachment subnetOpen the Amazon VPC console.From the navigation pane, choose Route Tables.Choose the route table that's attached to the attachment subnet.Choose the Routes tab and choose Edit Routes.Choose the Add Route tab and then complete the following:For Destination, choose the subnet of the on-premises network.For Target, choose your transit gateway.Choose Save routes.Follow"


Question: How can I validate ACM certificates from Route 53?

How can I validate AWS Certificate Manager (ACM) certificates from Amazon Route 53?

Answer: "How can I validate AWS Certificate Manager (ACM) certificates from Amazon Route 53?Short descriptionThere are two ways to validate domain ownership for an ACM certificate:1.    DNS validation2.    Email validationWhen you request an ACM certificate using DNS validation, ACM provides a CNAME record that you must add to your DNS configuration. ACM uses the CNAME record to validate ownership of domains. After the domain ownership is validated, the certificate status updates from Pending validation to Issued.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.If you are using Route 53 as your DNS service provider for the domains requested in the ACM certificate, you can use a one-click option available in the ACM console to create the CNAME. When you select this option, the record is automatically added to the Route 53 hosted zone of the domain.However, you must add CNAME records manually if either of the following is true:You have multiple hosted zones for the same domainYour hosted zone is in a different accountApex domain certificate requestsDetermine the name server (NS) record1.    Run the following command to find the DNS configuration for the appropriate hosted zone.For Linux and macOS:$ dig NS example.comFor Windows:$ nslookup -type=ns example.comNote: Replace "example.com" with your domain name.2.    The previous command provides the name servers included in the name server (NS) record of the DNS configuration of the domain. Add the CNAME record to the Route 53 hosted zone that has an NS record same as the name servers in your output.Example output:$ dig example.com NS; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> example.comNS;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56071;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;example.com. IN NS;; ANSWER SECTION:example.com. 300 IN NS ns-1992.awsdns-57.co.uk.example.com. 300 IN NS ns-290.awsdns-36.com.example.com. 300 IN NS ns-547.awsdns-04.net.example.com. 300 IN NS ns-1200.awsdns-22.org.Add CNAME records in Route 53After you identify the appropriate hosted zone using the NS values, add your CNAME record to it:1.    Open the Route 53 console.2.    Navigate to the hosted zone of your domain. This hosted zone must have the same NS record as the name servers you identified in the previous task.3.    Choose Create record.4.    For Name, enter the Record Name of the CNAME that ACM generated, excluding the domain portion. For more information, see How CNAME records for ACM work.5.    For Value, enter the complete Record Value that ACM provided.6.    For Record type, choose CNAME - Routes traffic to another domain name and to some AWS resources.7.    For Route Policy, choose Simple routing.8.    Choose Create Records.Verify the resolution of the CNAME recordTo confirm that the CNAME record was added correctly to your DNS configuration, run a command similar to the following, based on your use case.For Linux and macOS:dig +short _example-cname.example.comFor Windows:nslookup -type=cname _example-cname.example.comNote: Be sure to replace "example-cname.example.com" with your ACM CNAME record.If the CNAME record was added to the correct DNS configuration and propagated successfully, then the command returns the CNAME record’s value in the output.Subdomain certificate requestsIf you have a separate hosted zone for your subdomain:Follow the previously described steps for apex domain certificate requests and identify the NS record of the subdomain by replacing the domain’s name with the subdomain in the command.If you receive an output with NS values, add the CNAME records in the subdomain’s hosted zone that matches the output’s NS values.If you don't receive NS records after running the command, be sure that there's proper subdomain delegation configured between your apex domain and subdomain. To do this, create a resource record with subdomain’s NS record in the apex domain’s hosted zone. For more information, see How do I create a subdomain for a domain hosted through Route 53?If you don't have a separate hosted zone for your subdomain:If there isn't a separate hosted zone for the subdomain, add the CNAME records in the apex domain’s hosted zone. Then, verify that the CNAME record resolves as expected using previously described steps for apex domain certificate requests.Note: If there were recent changes in the DNS configuration, you might experience propagation delays based on TTL values.Follow"


Question: How can I resolve the "Volume vol-XXXXXXXXXX cannot be modified in modification state OPTIMIZING" error in CloudFormation when I try to update my Amazon EBS volume type (AWS::EC2::Volume)?

"I receive the "Volume vol-XXXXXXXXXX cannot be modified in modification state OPTIMIZING" error or similar error in AWS CloudFormation. This error happens when I try to update my Amazon Elastic Block Store (Amazon EBS) volume type. My EBS volume (AWS::EC2::Volume) gets stuck in UPDATE_IN_PROGRESS status for a long time and eventually fails to update the volume type. My stack fails to update and the subsequent update rollback also fails. Then, the stack ends up in UPDATE_ROLLBACK_FAILED status."

Answer: "I receive the "Volume vol-XXXXXXXXXX cannot be modified in modification state OPTIMIZING" error or similar error in AWS CloudFormation. This error happens when I try to update my Amazon Elastic Block Store (Amazon EBS) volume type. My EBS volume (AWS::EC2::Volume) gets stuck in UPDATE_IN_PROGRESS status for a long time and eventually fails to update the volume type. My stack fails to update and the subsequent update rollback also fails. Then, the stack ends up in UPDATE_ROLLBACK_FAILED status.Short descriptionIf you use credentials when your CloudFormation stack modifies an EBS volume, then the timeout period for the volume is approximately seven hours. If you run the stack using an AWS Identity and Access Management (IAM) service role instead, then CloudFormation increases the timeout period to 36 hours.Note: The volume's timeout period applies only to volume modification using CloudFormation. The timeout period varies for different types of resources and actions.Typically, a fully used 1-tebibyte (TiB) EBS volume takes about six hours to migrate to a new performance configuration. For more information see, Monitor the progress of volume modifications.Important: If you already initiated a stack update with CloudFormation, you must wait about seven hours until the stack stabilizes before completing the following steps. Your stack is stabilized when it enters UPDATE_ROLLBACK_FAILED status.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Recover your stack after waiting for the stack to stabilizeConsider the following example. If you change your EBS volume type from st1 to gp3, then your stack can fail to update the volume type because of volume size. In this scenario, you can recover your stack by performing the continue-update-rollback operation on your stack. For the recovery operation, you must skip the logical ID of the resource that failed to update. Your stack ends up in UPDATE_ROLLBACK_COMPLETE status.Recover your stack using either the AWS CLI or CloudFormation console.AWS CLI:aws cloudformation continue-update-rollback --stack-name your-stack-name --resources-to-skip logical-ID-of-EBS-volumeCloudFormation console:1.    Open the CloudFormation console.2.    From the navigation pane, choose Stacks.3.    From the Stack name column, select the stack that's stuck in UPDATE_ROLLBACK_FAILED status.4.    Choose Stack actions, and then choose Continue update rollback.5.    In the Continue update rollback dialog box, expand Advanced troubleshooting.6.    In the Resources to skip - optional section, select the resources that you want to skip.Note: Be sure to select the logical ID of the volume that failed to update.7.    Choose Continue update rollback.Update your stack to match the current status of your EBS volumeYou must update your stack to match the current status of your EBS volume. Your CloudFormation template is updated by your stack update, and your stack changes to UPDATE_COMPLETE status.For example, you can modify the volume type (AWS::EC2::Volume) from st1 to gp3. However, the volume type in CloudFormation remains st1 because of the rollback operation, even if the update to gp3 is accurately reflected in Amazon EBS.1.    To monitor the status of your EBS volume, use the Amazon EC2 console or run the following command:aws ec2 describe-volumes-modifications --volume-ids your-volume-ID2.    After the volume type changes to gp3 in Amazon EBS, update the CloudFormation stack with the volume type (AWS::EC2::Volume) as gp3.Note: You can modify your CloudFormation template by changing the volume type to gp3. Then, perform the update operation.3.    Use drift detection to verify that your EBS volume resource (AWS::EC2::Volume) is in sync with your stack.Important: Your stack update can take longer than 36 hours if you don't use a service role or if the volume size is high (~8 TiB). In such cases, your stack update could fail even after using a service role with 36 hours of stabilization. Then, you must wait until your stack stabilizes. During this period, you can't modify any other resource type. To resolve this issue, complete the following steps:1.    Use a Retain deletion policy to remove the EBS volume from your stack without deleting the volume.2.    Update your EBS volume outside of CloudFormation by using the Amazon EBS console instead.3.    Import your EBS volume back into your stack.If you want to keep the volume in the stack at all times, then you must keep the volume size below a threshold. For example, if 8 TiB of data takes 64 hours, then you can estimate the maximum size for 36 hours and lower the data size to 4 TiB. This threshold adjustment allows your update to complete.Follow"


Question: How do I resolve problems connecting to my Amazon DocumentDB cluster?

"I can't connect to my Amazon DocumentDB (with MongoDB compatibility) cluster. Why can't I connect, and how do I troubleshoot connection issues?"

Answer: "I can't connect to my Amazon DocumentDB (with MongoDB compatibility) cluster. Why can't I connect, and how do I troubleshoot connection issues?Short descriptionAmazon DocumentDB is a VPC-only service and doesn't support public endpoints. As a result, you can't connect directly to an Amazon DocumentDB cluster from an environment outside AWS. You can connect to Amazon DocumentDB using the following methods:Connect from an Amazon Elastic Compute Cloud (Amazon EC2) instance that is in the same Amazon Virtual Private Cloud (Amazon VPC). You can also connect from another AWS service (such as AWS Lambda or Amazon SageMaker) that is in the same VPC.Connect from an EC2 instance that is in a different VPC by using VPC peering.Connect from a machine outside AWS using an SSH tunnel.ResolutionConnect from an EC2 instance in the same VPC1.    Create an EC2 instance in the same VPC that you can use SSH to connect to from your source machine.2.    Confirm that the Amazon DocumentDB cluster's security group has rules that allow connections from the EC2 instance. By default, the security group for the Amazon DocumentDB cluster must allow inbound connections on port 27017.3.    Connect to your EC2 instance using SSH. See the following example for a Linux instance:ssh -i "keypairfile.pem" ec2-user@<EC2 DNS endpoint>4.    Install the mongo shell on EC2 instance, if you haven't already.5.    Connect to the cluster:mongo --ssl --host <Cluster endpoint> :27017 --sslCAFile rds-combined-ca-bundle.pem --username <username> --password <password>MongoDB shell version: 3.2.11connecting to: <Cluster>:27017/<user>rs0:PRIMARY>Connect from an EC2 instance in a different VPC1.    Create a VPC peering connection from an EC2 instance that is running in a different VPC than the Amazon DocumentDB cluster.2.    After the peering connection is successful, follow the steps listed under Connect from an EC2 instance in the same VPC.Connect from a machine outside AWS using an SSH tunnel1.    Set up an SSH tunnel from your local computer to an EC2 instance that is running in the same VPC as your Amazon DocumentDB cluster. For more information, see Connecting to an Amazon DocumentDB cluster from outside an Amazon VPC.ssh -i "keypairfile.pem" -L 27017:<cluster endpoint>:27017 ec2-user@<EC2 tunnel endpoint> -NThis allows you to run commands directly to the local host (27017). The commands are then sent to the Amazon DocumentDB cluster. As a best practice, avoid using this method for production environments or if you use the DocumentDB cluster as a replica set for your connections. For more information, see Connecting to Amazon DocumentDB as a replica set.TroubleshootingIf you're using one of these methods, and you're still having trouble connecting, check the following:The Amazon DocumentDB cluster has at least one instance that is in an available state. If the instances aren't in available states, they can't accept connections.The source you use to connect to the instance is listed as a source that is authorized to access the cluster in your network access control lists (ACLs), local firewalls, and security group rules.The correct DNS name or endpoint is used to connect to the Amazon DocumentDB cluster. For troubleshooting DNS and connectivity issues, see Cannot connect to an Amazon DocumentDB endpoint.The user name and password are entered correctly when you connect to the cluster. If you forgot the password, you can reset the password by modifying the Amazon DocumentDB cluster.The SSL certificate is passed when connecting from a client or an application. By default, TLS configuration is enabled for Amazon DocumentDB clusters. To disable the TLS configuration, create a new custom Amazon DocumentDB cluster parameter group. Set the tls parameter to disabled, and then modify the cluster to use the new cluster parameter group. For more information, see Managing Amazon DocumentDB cluster parameter groups.Related informationWhat is VPC peering?Follow"


Question: Why do I receive an error when I try to unlink a member account from my organization in AWS Organizations?

"I received an error when I tried to unlink a member account from my organization:"One or more of the member accounts that you want to remove has not completed the account sign-up steps."What does this error message mean, and how do I fix the error?"

Answer: "I received an error when I tried to unlink a member account from my organization:"One or more of the member accounts that you want to remove has not completed the account sign-up steps."What does this error message mean, and how do I fix the error?ResolutionBefore an account can be removed (unlinked) from an organization, you or the administrator of the member account must do the following:Provide a valid payment method.Verify the account by phone.Choose an AWS Support plan for the account.The error indicates that one or more of these steps is incomplete:You can add this information and then remove the account by following one of these procedures:If you're signing in as the member account that you want to remove from an organization, follow the instructions at Leaving an organization as a member account.If you're signing in as the management account in an organization and can access the member accounts, follow the instructions at Removing a member account from your organization.If you're signing in as the management account in an organization and can't access the member accounts, see How do I remove a member account from an organization in AWS Organizations when I can't sign in to the member account?Note: AWS Support can't change the structure or membership of your organization.Related informationHow do I remove a member account from an organization's consolidated bill in AWS Organizations?Follow"


Question: How can I connect to my Amazon RDS DB instance using a bastion host from my Linux/macOS machine?

I have an Amazon Relational Database Service (Amazon RDS) DB instance that is not publicly accessible. I would like to connect to it from my Linux/macOS machine. How can I connect to my RDS DB instance using a bastion host?

Answer: "I have an Amazon Relational Database Service (Amazon RDS) DB instance that is not publicly accessible. I would like to connect to it from my Linux/macOS machine. How can I connect to my RDS DB instance using a bastion host?Short descriptionTo connect to a private Amazon RDS or Amazon Aurora DB instance, it's a best practice to use a VPN or AWS Direct Connect. If you cannot use either a VPN or AWS Direct Connect, then the preferred option is to use a bastion host. You can also use this method to connect to Aurora Serverless and RDS Proxy from outside the VPC. This example shows you how to set up a bastion host to connect to your RDS DB instance from a Linux/macOS machine, even though the RDS DB instance is private.Resolution1.    Set your Amazon RDS DB instance to private by modifying the DB instance. Set the publicly accessible parameter to no, with private subnets (i.e., no Internet gateway - igw in route tables). Set the security group to allow the DB to port (5432, 3306) from all IPs.2.    Launch the smallest available EC2 instance in the same VPC as your DB instance. Set your Amazon Elastic Compute Cloud (Amazon EC2) instance to be accessible from internet, with public subnets (i.e., has Internet gateway - igw in route tables). Set the security group to allow the IP of the Linux/macOS machine you are trying to connect from.3.    Run the following command from your Linux/macOS machine to create a tunnel for connectivity from your machine:Syntax 1:ssh -i <identity_file> -f -l <bastion-host-username> -L <local-port-you-connect-to>:<rds-endpoint>:<rds:listening-port><bastion-host-public-ip> -vExample Command:ssh -i "private_key.pem" -f -l ec2-user -L 5432:172.31.39.62:5432  3.133.141.189 -vWhen you run the command above (SSH tunneling), you configure the following settings:debug1: Local connections to LOCALHOST: 5432 forwarded to remote address 172.31.39.62:5432debug1: Local forwarding listening on 127.0.0.1 port 5432.debug1: channel 0: new [port listener]debug1: Local forwarding listening on ::1 port 5432.Syntax 2:ssh -i "Private_key.pem" -f -N -L 5433:RDS_Instance_Endpoint:5432 ec2-user@EC2-Instance_Endpoint -vExample Command:ssh -i "private.pem" -f -N -L5433:pg115.xxxx.us-east-2.rds.amazonaws.com:5432ec2-user@ec2-xxxx-xxx9.us-east-2.compute.amazonaws.com -v4.    Now that SSH tunneling is in place, you can connect to your DB instance from your local Linux/macOS machine. The following example connects to PostgreSQL, but you can also use this method to connect to MySQL, or any other engine you want to connect to.Syntax -psql -hlocalhost -Upostgres -p<local-port-you-connect-to> -d postgres-h = localhost-U = the username present in the DB for connectivity-p = 'local-port-you-connect-to' from the SSH Tunneling command-d = Any DB, user wish to connect.Example command -a483e73d651f:.ssh rahul_saha$ psql -hlocalhost -Upostgres -p5432 -d postgresPassword for user postgres: psql (12.1, server 11.5)SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)Type "help" for help.postgres=> \l                                  List of databases   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   -----------+----------+----------+-------------+-------------+----------------------- postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |  rdsadmin  | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | rdsadmin=CTc/rdsadmin template0 | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/rdsadmin          +           |          |          |             |             | rdsadmin=CTc/rdsadmin template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +           |          |          |             |             | postgres=CTc/postgres(4 rows)$ psql -hlocalhost -Upostgres -p -d postgres$ mysql -h127.0.0.1 -uroot -pNote: MySQL tries to connect using the socket if you use the keyword localhost when connecting to DB instance. Make sure to use the hostname 127.0.0.1 when accessing a MySQL DB instance. For more information, see the MySQL documentation for Can't connect to [local] MySQL server.Related informationLinux bastion hosts on AWSConnect to a private Amazon RDS DB instance from a local machine using an Amazon EC2 instance as a bastion hostFollow"


Question: How are Amazon EC2 instance-hours billed?

I want to know how I am billed for my Amazon Elastic Compute Cloud (Amazon EC2) instances.

Answer: "I want to know how I am billed for my Amazon Elastic Compute Cloud (Amazon EC2) instances.ResolutionYour Amazon EC2 usage is calculated by either the hour or the second based on the size of the instance, operating system, and the AWS Region where the instances are launched. Pricing is per instance-hour consumed for each instance, from the time an instance is launched until it's terminated or stopped.Each partial instance-hour consumed is billed per-second for instances launched in Linux, Windows, or Windows with SQL Enterprise, SQL Standard, or SQL Web instances.Each partial instance-hour is billed as a full hour for all other instance types.When reviewing your Amazon EC2 usage, consider the following:If your instance is billed by the hour, then you're billed for a minimum of one hour each time a new instance is started—that is, when the instance enters the running state.If your instance is billed by the second, then you're billed for a minimum of 60 seconds each time a new instance is started—that is, when the instance enters the running state.An instance stays in the running state while being rebooted.If your instance is stopped and started, the AWS accounting mechanism charges more units in the hour that the instance is stopped and started. You're then billed fewer units in the hour the instance is terminated so that your overall billing remains unaffected.Instances that are in any other state aren't billed.For more information on instance pricing based on purchase options, see Amazon EC2 pricing.If you purchase an Amazon EC2 Reserved Instance, then the terms of your Reserved Instance contract can modify the way that you're billed. For more information, see What is an Amazon EC2 Reserved Instance?If you signed up for Savings Plans, then see Savings Plans FAQ.Related informationAmazon EC2 FAQsWhy am I charged for Amazon EC2 when all my instances were terminated?How are charges for Amazon EBS volumes calculated on my bill?Follow"