Question: How do I add and verify a domain to use with WorkMail?

I want to add my organization's email domain to Amazon WorkMail.

Answer: "I want to add my organization's email domain to Amazon WorkMail.ResolutionYou can add your email domain to WorkMail by using the AWS Management Console. After adding your domain, create the required public DNS records in your DNS provider to send and receive email messages.Add your domain to WorkMailFrom the WorkMail console, choose the Alias for your organization.From the navigation pane, choose Domains, and then choose Add domain.For Domain name, enter your fully qualified domain name (FQDN) in the Domain name field. Then choose Add domain.Update the DNS records on Route 53If you use Amazon Route 53 on the same account where you have your WorkMail organization, and the domain is registered, WorkMail can automatically configure your domain DNS records. Choose Update all in Route 53 at the top of the page to configure your DNS records.Update the DNS records in other DNS providersThe procedures for publishing DNS records for your domain depend on the DNS provider you use. See the section titled Procedures for other DNS providers for instructions for adding DNS records to your domain. The procedure for adding DNS records to your domain's DNS server also varies based on your web hosting service or DNS provider.To complete the process, copy the DNS record names and values from the WorkMail console and create the corresponding DNS records in your DNS provider.Verify domain ownershipBefore you can use your domain, WorkMail needs to verify the domain ownership. For this, create a DNS TXT record.From the WorkMail console, take note of the TXT record name (for example, _amazonses) and the value (for example, Examplet1m66d11EGfsukCL7w520AaExample+TESTo=).Create a TXT DNS record with the aforementioned name and value.MX and autodiscover recordsCreate the DNS MX record so that WorkMail can start receiving email messages from your email domain. Add the autodiscover CNAME record for the client configuration.From the WorkMail console, take note of the MX record value (for example, 10 inbound-smtp.us-east-1.amazonaws.com).Create an MX DNS record with the aforementioned value.Note: The MX record needs to point to the root domain that is typically denoted by @ or is empty. This is dependent on your DNS provider.Take note of the CNAME record name (for example, autodiscover) and the record value (for example, autodiscover.mail.us-east-1.awsapps.com).Create a CNAME DNS record with aforementioned name and value.Improve WorkMail security by configuring DKIM, DMARC, and SPFTo further protect your domain from impersonation, it's a best practice to create all records listed in the following steps. For the SPF record, make sure to include all servers that send email by using your domain.From the WorkMail console, take note of the first CNAME record name (for example, ex4mpl3ac7ki6clelsdbiiudpavjpsk3._domainkey) and the value (for example, ex4mpl3ac7ki6clelsdbiiudpavjpsk3.dkim.amazonses.com).Create a CNAME DNS record with the aforementioned name and value.Repeat steps 1 and 2 for the other two CNAME records.Take note of the TXT record value (for example, v=spf1 include:amazonses.com ~all).Create a TXT DNS record with the aforementioned value.Note: The TXT record needs to point to the root domain that is typically denoted by @ or is empty. This denotation is dependent on your DNS provider.Configure the MAIL FROM domainBy default, WorkMail uses the subdomain amazonses.com as the MAIL FROM domain for all outgoing email messages. This can cause a delivery failure if DomainKeys Identified Mail (DKIM) is not set for your domain. To resolve this, configure your own domain as the MAIL FROM domain from the Amazon Simple Email Service (Amazon SES) Domains page.Follow the instructions in the console to configure a custom MAIL FROM domain.For more information about MAIL FROM, see Using a custom MAIL FROM domain.Verify the records published correctlyYou can verify that the WorkMail domain verification TXT record is published correctly to your DNS server. For more information, see Verifying TXT records and MX records with your DNS service.Note: It might take up to 72 hours for DNS records to propagate to your domain host provider.For more information about adding DNS records to Amazon Route 53, see Routing traffic to Amazon WorkMail.Procedures for other DNS providersThe procedures for publishing DNS records for your domain depend on the DNS provider you use. The following list includes links to the documentation for widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply they don't support WorkMail domain configuration.GoDaddyAdd a CNAME recordAdd a TXT recordAdd an MX recordDreamHostAdd custom DNS recordsCloudflareManage DNS recordsHostGatorManage DNS records with HostGator/EnomNamecheapAdd TXT/SPF/DKIM/DMARC records for my domainNames.co.ukChange your domain's DNS settingsWixAdd or update an MX recordAdd or update a CNAME recordAdd or update a TXT recordFollow"


Question: How do I use SSM Agent logs to troubleshoot issues with SSM Agent in my managed instance?

"AWS Systems Manager Agent (SSM Agent) fails to run successfully, but I don't know how to troubleshoot the issue using the SSM Agent logs."

Answer: "AWS Systems Manager Agent (SSM Agent) fails to run successfully, but I don't know how to troubleshoot the issue using the SSM Agent logs.Short descriptionSSM Agent runs on your managed Amazon Elastic Compute Cloud (Amazon EC2) instance and processes requests from the AWS Systems Manager service. SSM Agent requires that the following conditions are met:SSM Agent must connect to the required service endpoints.SSM Agent requires AWS Identity and Access Management (IAM) permissions to call the Systems Manager API calls.Amazon EC2 must assume valid credentials from the IAM instance profile.If any of these conditions aren't met, then SSM Agent fails to run successfully.To identify the root cause of the SSM Agent failure, review SSM Agent logs in the following locations:Linux/var/log/amazon/ssm/amazon-ssm-agent.log/var/log/amazon/ssm/errors.logWindows%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log%PROGRAMDATA%\Amazon\SSM\Logs\errors.logNote: Because SSM Agent is updated frequently with new capabilities, it's a best practice to configure automated updates for SSM Agent.ResolutionFirst, review the logs and identify whether the issue is caused by missing endpoint connections, missing permissions, or missing credentials. Then, follow the relevant troubleshooting steps for your issue.SSM Agent can't talk to the required endpointsSSM Agent can't reach the metadata serviceWhen SSM Agent can't reach the metadata service, it also can't locate the AWS Region information, IAM role, or instance ID from that service. In this case, you see an error message in the SSM Agent logs that's similar to the following:"INFO- Failed to fetch instance ID. Data from vault is empty. RequestError: send request failed caused by: Get http://169.254.169.254/latest/meta-data/instance-id"The most common reason for this error is using a proxy for outbound internet connections from your instance without configuring SSM Agent for a proxy. Be sure to configure SSM Agent to use a proxy.On Windows instances, this error might also occur from a misconfigured persistent network route when you use a custom AMI to launch your instance. You must verify that the route for the metadata service IP points to the correct default gateway.To verify if metadata is activated for your instance, run the following command in the AWS Command Line Interface (AWS CLI). Be sure to replace i-1234567898abcdef0 with your instance ID:Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.aws ec2 describe-instances --instance-ids i-1234567898abcdef0 --query 'Reservations[*].Instances[*].MetadataOptions'You receive an output that's similar to the following:[  [{    "State": "applied",    "HttpTokens": "optional",    "HttpPutResponseHopLimit": 1,    "HttpEndpoint": "enabled",    "HttpProtocolIpv6": "disabled",    "InstanceMetadataTags": "disabled"  }]]In this output, "HttpEndpoint": "enabled" indicates that metadata is activated for your instance.If metadata isn't activated, then you can turn it on with the aws ec2 modify-instance-metadata-options command. For more information, see Modify instance metadata options for existing instances.SSM Agent can't reach Systems Manager service endpointsIf SSM Agent can't connect with service endpoints, then SSM Agent fails. SSM Agent must make an outbound connection with the following Systems Manager service API calls on port 443:SSM endpoint: ssm.REGION.amazonaws.comEC2 messaging endpoint: ec2messages.REGION.amazonaws.comSSM messaging endpoint: ssmmessages.REGION.amazonaws.comNote: SSM Agent uses the Region information that the instance metadata service retrieves to replace the REGION value in these endpoints.When SSM Agent can't connect with the Systems Manager endpoints, you see error messages similar to the following in the SSM Agent logs:"ERROR [HealthCheck] error when calling AWS APIs. error details - RequestError: send request failed caused by: Post https://ssm.ap-southeast-2.amazonaws.com/: dial tcp 172.31.24.65:443: i/o timeout""DEBUG [MessagingDeliveryService] RequestError: send request failed caused by: Post https://ec2messages.ap-southeast-2.amazonaws.com/: net/http: request cancelled while waiting for connection (Client.Timeout exceeded while awaiting headers)"The following are some common reasons why SSM Agent can't connect with the Systems Manager API endpoints on port 443:Instance egress security group rules don't allow outgoing connections on port 443.Virtual private cloud (VPC) endpoint ingress and egress security group rules don't allow incoming and outgoing connections to the VPC interface endpoint on port 443.When the instance lives in a public subnet, routing table rules aren't configured to direct traffic using an internet gateway.When the instance lives in a private subnet, routing table rules aren't configured to direct traffic using a NAT gateway or VPC endpoint.If routing table rules are configured to use a proxy for all outgoing connections, then SSM Agent isn't configured to use a proxy.SSM Agent doesn't have permissions to call the required Systems Manager API callsSSM Agent failed to register itself as online on Systems Manager because SSM Agent isn't authorized to make UpdateInstanceInformation API calls to the service.The UpdateInstanceInformation API call must maintain a connection with SSM Agent so that the service knows that SSM Agent is functioning as expected. SSM Agent calls the Systems Manager service in the cloud every five minutes to provide health check information. If SSM Agent doesn't have the correct IAM permissions, then you see an error message in the SSM Agent logs.If SSM Agent uses the incorrect IAM permissions, then you see an error that's similar to the following:"ERROR [instanceID=i-XXXXX] [HealthCheck] error when calling AWS APIs. error details - AccessDeniedException: User: arn:aws:sts::XXX:assumed-role/XXX /i-XXXXXX is not authorized to perform: ssm:UpdateInstanceInformation on resource: arn:aws:ec2:ap-southeast-2:XXXXXXX:instance/i-XXXXXXstatus code: 400, request id: XXXXXXXX-XXXX-XXXXXXXINFO [instanceID=i-XXXX] [HealthCheck] increasing error count by 1"If SSM Agent doesn't have any IAM permissions, then you see an error that's similar to the following:"ERROR [instanceID=i-XXXXXXX] [HealthCheck] error when calling AWS APIs. error details - NoCredentialProviders: no valid providers in chain. Deprecated. For verbose messaging see aws.Config.CredentialsChainVerboseErrors2018-05-08 10:58:39 INFO [instanceID=i-XXXXXXX] [HealthCheck] increasing error count by 1"Verify that the IAM role that's attached to the instance contains the required permissions to allow an instance to use Systems Manager service core functionality. Or, if an instance profile role isn't already attached, then attach an instance profile role and include AmazonSSMManagedInstanceCore permissions.For more information about the required IAM permissions for Systems Manager, see Additional policy considerations for managed instances.Systems Manager API call throttlingIf a high volume of managed instances that run SSM Agent make concurrent UpdateInstanceInformation API calls, then those calls might get throttled.If the UpdateInstanceInformation API call for your instance is throttled, then you see error messages similar to the following in the SSM Agent logs:"INFO [HealthCheck] HealthCheck reporting agent health.ERROR [HealthCheck] error when calling AWS APIs. error details - ThrottlingException: Rate exceededstatus code: 400, request id: XXXXX-XXXXX-XXXXINFO [HealthCheck] increasing error count by 1"Use the following troubleshooting steps to prevent ThrottlingException errors:Reduce the frequency of API calls.Implement error retries and exponential backoffs when you make API calls.Stagger the intervals of API calls so that they don't all run at the same time.Request a throttling limit increase for UpdateInstanceInformation API calls.Amazon EC2 can't assume valid credentials from the IAM instance profileIf Amazon EC2 can't assume the IAM role, then you see a message that's similar to the following example in the SSM Agent logs:2023-01-25 09:56:19 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:19 INFO [CredentialRefresher] Sleeping for 1s before retrying retrieve credentials2023-01-25 09:56:20 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:20 INFO [CredentialRefresher] Sleeping for 2s before retrying retrieve credentials2023-01-25 09:56:22 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:22 INFO [CredentialRefresher] Sleeping for 4s before retrying retrieve credentials2023-01-25 09:56:26 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:26 INFO [CredentialRefresher] Sleeping for 9s before retrying retrieve credentials2023-01-25 09:56:35 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:35 INFO [CredentialRefresher] Sleeping for 17s before retrying retrieve credentials2023-01-25 09:56:52 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity2023-01-25 09:56:52 INFO [CredentialRefresher] Sleeping for 37s before retrying retrieve credentialsIf you try to retrieve metadata from the EC2 instance, then you also see an error that's similar to the following example:# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/profile-name{  "Code" : "AssumeRoleUnauthorizedAccess",  "Message" : "EC2 cannot assume the role profile-name. Please see documentation at https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-ec2.html#troubleshoot_iam-ec2_errors-info-doc.",  "LastUpdated" : "2023-01-25T09:57:56Z"}Note: In this example, profile-name is the name of the instance profile.To troubleshoot this error, check the trust policy that's attached to the IAM role. In the policy, you must specify Amazon EC2 as a service that's allowed to assume the IAM role. Update your IAM policy through the UpdateAssumeRolePolicy API so that it appears similar to the following example:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": ["ec2.amazonaws.com"]      },      "Action": ["sts:AssumeRole"]    }  ]}For more information, see The iam/security-credentials/[role-name] document indicates "Code":"AssumeRoleUnauthorizedAccess".Follow"


Question: Why is my Amazon RDS DB instance in the storage-optimization state for a long time?

"I updated the storage size of my Amazon Relational Database (Amazon RDS) DB instance. But, the process is taking a long time, and the instance is in the storage-optimization state."

Answer: "I updated the storage size of my Amazon Relational Database (Amazon RDS) DB instance. But, the process is taking a long time, and the instance is in the storage-optimization state.ResolutionWhen you modify the storage size of your Amazon RDS DB instance, the status of the instance changes to storage optimization. This modifies your DB instance to change the storage size or type. The storage optimization process is performed by RDS automation. RDS automation confirms that the data is evenly distributed to the Amazon Elastic Block Store (Amazon EBS) volumes after storage modification.In most cases, scaling storage doesn't cause an outage or performance degradation of the DB instance. However, this operation might take several hours. You can't make further storage modifications for either 6 hours or until storage optimization completes on the instance, whichever is longer. But, you can perform any other instance modifications, such as instance size scaling or rebooting.Typically, the storage optimization completes in a few hours, but can sometimes take up to or more than 24 hours. When the DB instance is in the storage-optimization state, the instance is operational. Your application availability isn't affected. You don't have to wait for the DB instance to be in the available state to run your applications.Note: There's no way to speed up this process. You must wait for the optimization process to complete. The process takes longer for larger storage size increases and storage usage. Because this is an automated process, there's no fixed way to determine how long it takes to complete storage optimization on your RDS DB instance.For a cluster volume, Amazon Aurora uses a custom storage solution that isn't backed by EBS volumes. Therefore, you don't need to consider storage optimization for Aurora instances. For more information, see Introducing the Aurora storage engine.Note: Any type of storage modification might result in the DB instance moving to the storage-optimization state. However, modifying the storage might also cause the instance to restart and require downtime. This is a requirement in specific cases, such as changing the storage type between SSD and magnetic. For more information, see Settings for DB instances.To monitor the amount of free storage for your DB instance, it's a best practice to create an Amazon CloudWatch alarm.Related informationManaging an Amazon RDS DB instanceFollow"


Question: How do I configure a conditional forwarder with CoreDNS in my Amazon EKS cluster?

I want to configure a conditional forwarder with CoreDNS in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I want to configure a conditional forwarder with CoreDNS in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.Short descriptionYou can use CoreDNS to configure conditional forwarding for DNS queries sent to the domains resolved by a customized DNS server. For more information, see Customizing DNS Service on the Kubernetes website.Important: Apply the modifications in the following resolution to self-managed CoreDNS only. To make configuration changes to the CoreDNS Amazon EKS add-on, determine the settings that Amazon EKS manages by checking the Amazon EKS add-on configuration. Check the add-on configuration before making any changes, because modifying a field managed by Amazon EKS prevents Amazon EKS from managing the add-on. This could result in your changes being overwritten when an add-on is updated.Resolution1.    Modify the CoreDNS ConfigMap and add the conditional forwarder configuration:$ kubectl -n kube-system edit configmap corednsOutput:apiVersion: v1kind: ConfigMapmetadata:  annotations:  labels:    eks.amazonaws.com/component: coredns    k8s-app: kube-dns  name: coredns  namespace: kube-systemdata:  Corefile: |    .:53 {        errors        health        kubernetes cluster.local in-addr.arpa ip6.arpa {          pods insecure          fallthrough in-addr.arpa ip6.arpa        }        prometheus :9153        forward . /etc/resolv.conf        cache 30        loop        reload        loadbalance    }    domain-name:53 {        errors        cache 30        forward . custom-dns-server        reload    }Note: Replace domain-name with your domain name. Replace custom-dns-server with your custom DNS server IP address.2.    Verify that domain name resolution works:$ kubectl run busybox --restart=Never --image=busybox:1.28 -- sleep 3600$ kubectl exec busybox -- nslookup domain-nameNote: Replace domain-name with your domain name.Follow"


Question: How do I view my email sending history in Amazon SES?

I want to review my email sending history in Amazon Simple Email Service (Amazon SES). How can I do that?

Answer: "I want to review my email sending history in Amazon Simple Email Service (Amazon SES). How can I do that?ResolutionUse Amazon OpenSearch Service and Amazon Kinesis to store and view your Amazon SES sending history.Create an Amazon OpenSearch Service domainCreate an Amazon OpenSearch Service domain to store your Amazon SES sending history. OpenSearch Service can be placed in a public network or in an Amazon Virtual Private Cloud (Amazon VPC). For more information on the type of network to use for your OpenSearch Service domain, see VPC versus public domains.Create a Kinesis delivery streamOpen the Kinesis console.Choose Create delivery stream.For Source, select Direct PUT. For Destination, select Amazon OpenSearch Service.For Delivery stream name, enter a name for your stream.(Optional) You can choose to transform source records with AWS Lambda, or leave this setting as Disabled.Under Destination settings, enter the following:For OpenSearch Service domain, select the domain that you created to store your Amazon SES sending history.For Index, enter an index name.For Index rotation, choose a rotation schedule. Or, leave the field with the default No rotation setting.For Type, enter a type name.For Retry duration, modify the retry duration in seconds. Or, leave the field with the default 300 seconds.For Buffer hints, configure OpenSearch Service buffer conditions for your use case. For more information on these fields, see Backup and advanced settings.Under Backup settings, enter the following:Leave Failed data only as the default setting.For S3 backup bucket, choose to store the records in an existing bucket. Or, choose Create to create a new bucket.(Optional) For S3 backup bucket prefix, enter a prefix. Or, leave this field blank.(Optional) For S3 backup bucket error output prefix, enter a prefix. Or, leave this field blank.(Optional) You can expand the Advanced settings tab to configure server-side encryption, CloudWatch error logging, permissions, and tags. Configure the settings for your use case. For more information on these fields, see Backup and advanced settings.Choose Create delivery stream.Create an Amazon SES configuration setOpen the Amazon SES console, and then choose Configuration Sets from the navigation pane.Choose Create Set.For Configuration set name, enter a name for the set.For Sending IP pool, select your preferred pool or leave default selected. Then, choose Create Set.Choose Event destinations from the top pane of the newly created set, and then choose Add destination.For Event types, select Sends, Rejects, Deliveries, Hard bounces, and Complaints. Then, choose Next.For Destination type, select Amazon Kinesis Data Firehose.In the  Name field, enter a destination name.For Delivery stream, select the delivery stream that you created.For Identity and Access Management (IAM) Role, choose a role that grants permission for Amazon SES to publish to Kinesis Data Firehose on your behalf. Then, choose Next.Note: This must be a manually created Identity and Access Management (IAM) role.Review your event destination settings, and then choose Add destination.Test your configurationSend a test email using the Amazon SES console.Important: To see the results of the test email, you must specify the configuration set that you created.For Email Format, select Formatted.For Configuration set, enter the name of the configuration set.Open the Amazon OpenSearch Service console.Choose the domain that you created for storing your Amazon SES sending history.In the General information section, choose the link next to OpenSearch dashboards URL.Create an index pattern for the index name that you configured when you created the delivery stream. For instructions, see Create a data view on the elastic.co website.After the index pattern is created, use the Discover feature in OpenSearch Dashboards to view the log of the test email that you sent. For more information, see Discover on the elastic.co website.Related informationMonitoring your Amazon SES sending activityHow do I troubleshoot Amazon CloudWatch Logs so that it streams to my Amazon OpenSearch Service domain?Follow"


Question: How can I track failed attempts to log in to my Amazon RDS DB instance that's running PostgreSQL?

I need to track the number of failed connections to my Amazon Relational Database Service (Amazon RDS) DB instance that is running PostgreSQL. How can I do this?

Answer: "I need to track the number of failed connections to my Amazon Relational Database Service (Amazon RDS) DB instance that is running PostgreSQL. How can I do this?ResolutionPostgreSQL generates new log files every hour. To track failed attempts to log in to a DB instance that is running PostgreSQL, enable the log_connections parameter in the custom parameter group that is associated with the DB instance. For more information, see Modifying Parameters in a DB Parameter Group. After you enable the log_connections parameter, when a user attempts to log in to your DB instance with the wrong credentials, the failed attempts are recorded to the log, for example, error/postgresql.log.2018-04-19-10.See the following example of an unsuccessful login attempt:2018-04-19 10:12:31 UTC:123.45.67.8(6789):[unknown]@[unknown]:[12507]:LOG: connection received: host=123.45.67.8port=123452018-04-19 10:12:31 UTC:123.45.67.8(6789):test_user@Test_DB:[12507]:FATAL: password authentication failed for user "test_user"You can also use the PostgreSQL log_connections parameter to record successful login attempts to a DB instance that is running PostgreSQL.See the following example of a successful login attempt:2018-04-19 10:19:20 UTC:123.45.67.8(6789):[unknown]@[unknown]:[17196]:LOG: connection received: host=123.45.67.8 port=123452018-04-19 10:19:20 UTC:123.45.67.8(6789):test_user@Test_DB:[17196]:LOG: connection authorized: user=test_user database=Test_DB SSL enabled (protocol=xxxx, cipher=xxxx, compression=off)You can use the log_connections and the log_disconnections parameters to record the duration of a user's session.See the following example for the duration of a session:2018-04-19 10:19:43 UTC:123.45.67.8(6789):test_user@Test_DB:[17196]:LOG: disconnection: session time: 0:00:23.753 user=test_user database=Test_DB host=123.45.67.8 port=12345Note: The IP address of the client machine is 123.45.67.8, and 6789 is the PID (Process ID) that is given to the PostgreSQL database process.Parsing the log fileDownload the log using the AWS Command Line Interface (AWS CLI) or using the Amazon RDS console. Then, use the grep utility to search the failed connections:Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.$ grep -B 1 "authentication failed" postgresql.log.2018-04-19-102018-04-19 10:12:31 UTC:123.45.67.8(6789):[unknown]@[unknown]:[12507]:LOG: connection received: host=123.45.67.8port=123452018-04-19 10:12:31 UTC:123.45.67.8(6789):test_user@Test_DB:[12507]:FATAL: password authentication failed for user "test_user"Note: The - B 1 parameter tells grep to also show the line that precedes the lines that match the pattern that you are searching for. In this example, the pattern is authentication failed.You can alsouse the PostgreSQL log_fdw extension to access these logs as foreign tables. If you want to keep PostgreSQL log files for longer than the retention period, you canexport Amazon RDS PostgreSQL logs to CloudWatch logs if you use PostgreSQL versions 9.6.6 and above and 10.4 and above.Related informationHow do I enable query logging using Amazon RDS for PostgreSQL?PostgreSQL Database Log FilesExporting Log Data to Amazon S3Publishing Aurora PostgreSQL Logs to Amazon CloudWatch LogsFollow"


Question: Why I can't ping or RDP into my Windows or Linux instance when using an AWS Site-to-Site VPN?

I can't access my Amazon Elastic Compute Cloud (Amazon EC2) instances when using an AWS Site-to-Site VPN connection.

Answer: "I can't access my Amazon Elastic Compute Cloud (Amazon EC2) instances when using an AWS Site-to-Site VPN connection.ResolutionIf you have a Site-to-Site VPN connection, but can't ping into either a Windows or Linux EC2 instance by using SSH, then follow these troubleshooting steps:Make sure that your instance is running by checking the instance status.Use the AWS VPN console to check your Site-to-Site VPN connection status. Confirm that the status of the tunnel is UP. If your connection is DOWN, then review the troubleshooting steps for phase 1 and phase 2 failures to resolve the connection downtime.For Windows instances, verify that RDP port 3389 is allowed by your AWS security group, network ACL, OS firewall and antivirus software. For Linux instances, confirm the same for SSH port 22. To activate inbound SSH, RDP, or ICMP access, see Control traffic to resources using security groups and Control traffic to subnets using Network ACLs.Verify that the route tables that are specified in your instances are correct. Make sure that you have a return route for the destination CIDR or on-premises network. Confirm that this return route points to either a transit gateway (TGW) or virtual private gateway (VGW). Confirm that this TGW or VGW is attached to your Site-to-Site VPN.If your customer gateway device implements a policy-based VPN, then make sure that the device negotiates a single Security Association (SA). AWS limits the number of security associations to a single pair. For more information, see How do I troubleshoot connection problems between an AWS VPN endpoint and a policy-based VPN?You might be using an Active/Active configuration. This means that both of your tunnels are up, and your Site-to-Site VPN terminates on a VGW or TGW with ECMP turned off. In this use case, AWS assigns one active tunnel as the preferred VPN tunnel for sending traffic from AWS to the on-premises network. When you use Active/Active configurations, the customer gateway must have asymmetric routing activated on the virtual tunnel interfaces. For more information, see How do I configure my Site-to-Site VPN connection to prefer tunnel A over tunnel B?Confirm that there are no firewalls on the OS level that are blocking inbound or outbound traffic. For Windows instances, open a command prompt, and then run the WF.msc command. For Linux instances, from the terminal, run the iptables command with the appropriate arguments.If you're using dynamic based VPN, then make sure that you're announcing the correct on-premises prefixes to AWS.If you're using a static VPN, then make sure that you've configured the correct static route for your Site-to-Site VPN. Log in to the AWS VPN console, and then under static routes, check the target network of your Site-to-Site VPN.If you're using a static VPN, then check your customer gateway device. Make sure that you've configured a static route pointing to the destination AWS Virtual Private Cloud (AWS VPC) CIDR on the device.If you're using an accelerated VPN, then check that NAT is turned on, and that traffic is using UDP 4500. This is required for traffic to flow. If NAT isn't turned on, the tunnel comes up but no traffic passes.Note: Be aware of the rules for using an accelerated VPN connection.Related InformationHow do I troubleshoot Remote Desktop Connection issues to my Amazon EC2 Windows instance?Follow"


Question: How do I verify that EC2 Auto Scaling lifecycle actions complete when using AWS CodeDeploy?

"I’m using AWS CodeDeploy with Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling lifecycle hooks. However, lifecycle actions don’t complete and EC2 instances don’t launch."

Answer: "I’m using AWS CodeDeploy with Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling lifecycle hooks. However, lifecycle actions don’t complete and EC2 instances don’t launch.Short descriptionCodeDeploy uses Amazon EC2 Auto Scaling lifecycle hooks to perform deployments. Lifecycle hooks might influence the sequence of EC2 instance lifecycle states due to:Failed deployments which cause related lifecycle actions to fail.Multiple deployment groups associated with a single EC2 Auto Scaling group which exceed CodeDeploy limits and cause timeouts.Leftover lifecycle hooks associated with deleted applications which cause timeouts.ResolutionReview the scaling activities history of your Auto Scaling group:In the EC2 console navigation pane, choose Auto Scaling Groups under Auto Scaling. In the content pane, select your Auto Scaling group. Then choose the Activity History view.In the AWS Command Line Interface (AWS CLI), use the command describe-scaling-activities.Then, check for the following issues in the history.Failed deploymentsThe following error typically indicates a failed deployment with CodeDeploy:Description: Launching a new EC2 instance: i-f362a82e. Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token 0fc62a4b-153b-4dba-9bf4-9f233e72a697 was abandoned: Lifecycle Action Completed with ABANDON Result Cause: At 2016-07-22T16:16:56Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 2 to 3.Check your deployment details to find out why your deployment failed. For more information, see Troubleshooting CodeDeploy.Multiple deployment groups associated with a single EC2 Auto Scaling groupThe following error typically occurs when multiple deployment groups are associated with a single EC2 Auto Scaling group:Description: Launching a new EC2 instance: i-649f40a2. Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token 95c60857-3c0a-4a67-8518-6dc18797e421 was abandoned: Heartbeat Timeout Cause: At 2016-07-23T05:08:35Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 1 to 2.This error indicates a timeout error due to the five-minute limit in CodeDeploy. This timeout can occur when multiple deployments send commands to the CodeDeploy agent at the same time.Consolidate your deployments in a single deployment group. Be sure to delete unnecessary deployment groups to prevent unnecessary lifecycle hooks. For more information, see Working with Deployment Groups in CodeDeploy.Leftover lifecycle hooks from deleted applicationsCheck for active lifecycle hooks associated with deployment groups that have deleted applications. This issue can occur when an application is deleted before its deployment groups are deleted.Conclude the lifecycle hooks using EC2 instances in an Auto Scaling group fail to launch and receive the error "Heartbeat Timeout.” To understand the result when you conclude a lifecycle hook, check for '--lifecycle-action-result" parameter in CompleteLifecycleAction API call in Cloudtrail.Related informationIntegrating CodeDeploy with Auto ScalingFollow"


Question: What can I do if my domain is stuck in the "verification pending" status or in the "unverified" verification status in Amazon SES?

"I added Canonical Name Records (CNAME) to my domain's DNS server that matches the specified name and value of the domain that I want to verify on Amazon Simple Email Service (Amazon SES). However, the Amazon SES verification status is still in "verification pending," or is in the "unverified" verification status. How can I fix this?"

Answer: "I added Canonical Name Records (CNAME) to my domain's DNS server that matches the specified name and value of the domain that I want to verify on Amazon Simple Email Service (Amazon SES). However, the Amazon SES verification status is still in "verification pending," or is in the "unverified" verification status. How can I fix this?Short descriptionAmazon SES domain verification might be stuck in "verification pending" or in the "unverified" verification status for one or more of the following reasons:The CNAME records contain additional characters or has missing characters.Your DNS provider automatically adds the apex domain to the end of DNS records.The CNAME records haven't been added to the delegated name servers.After you confirm that your records don't have any of these issues, then retry the domain verification on Amazon SES.ResolutionCheck if the CNAME record contains additional characters or is missing charactersTest your CNAME records using a DNS tool such as dig or nslookup. Amazon SES generates three CNAME records for Easy DKIM authentication, so you must repeat the following procedures for each record.On macOS or a Linux operating system, run the dig command:Note: Replace _domainkey.example.com with your CNAME record name in Amazon SES.C:\>nslookup -type=CNAME 4hzwn5lmznmmjyl2pqf2agr3uzzzzxyz_domainkey.example.comOn the Windows operating system, run the nslookup command:Note: Replace _domainkey.example.com with your CNAME record name in Amazon SES.$ dig CNAME 4hzwn5lmznmmjyl2pqf2agr3uzzzzxyz_domainkey.example.com +shortReview the output of the dig or nslookup command. In the output, verify that the string following canonical name= matches the CNAME value listed as the domain in the Identities list on the Amazon SES console.For example, the following output shows additional characters (spaces):dig CNAME 4hzwn5lmznmmjyl2pqf2agr3ueo2kf3d._domainkey.example.com +short" 4hzwn5lmcnmmoylkpqf2agr3uwo2kxyz.dkim.amazonses.com. "As another example, the following output shows a CNAME record that's missing the "=" character:C:\>nslookup -type=CNAME _amazonses.example.comServer: dns.example.comAddress:  192.168.1.1Non-authoritative answer:_amazonses.example.com   text = "9kFNbWDLzxvzYgPg1lUSTkUudKR1dDtzzCPuWmYhZro"When you create your CNAME record, it's a best practice to copy the values directly from the Amazon SES console. Be sure to include the exact values provided. Don't exclude any necessary characters (for example, "="), and don't include any additional characters, such as spaces.Check if your DNS provider automatically adds the apex domain to the end of DNS recordsSome DNS providers automatically append the apex domain to the end of a DNS record. For example, if you enter _amazonses.example.com, then some DNS providers might append .example.com to the record name. This changes the record name to _amazonses.example.com.example.com. Amazon SES generates three CNAME records for Easy DKIM authentication, so you must repeat the following procedures for each record.To check if the apex domain is duplicated in the DNS record, run a DNS tool such as dig or nslookup on your CNAME records with the apex domain duplicated. On macOS or a Linux operating system, run the dig command:Note: Replace  _domainkey.example.com with your CNAME record name in Amazon SES.dig CNAME 4hzwn5lmznmmjyl2pqf2agr3uzzzzxyz_domainkey.example.com.example.comOn the Windows operating system, run thenslookup command:Note: Replace  _domainkey.example.com with your CNAME record name in Amazon SES.C:\>nslookup -type=CNAME 4hzwn5lmznmmjyl2pqf2agr3uzzzzxyz_domainkey.example.com.example.comIf the command returns the value of the CNAME record that you created, then your DNS provider added the apex domain to the end of the name field of your DNS records. To resolve this, edit the CNAME record and remove the apex domain from the text that you entered for the name field. For example, replace _amazonses.example.com with only _amazonses.Check if the CNAME record hasn't been added to the delegated name serversUse a DNS tool such as dig or nslookup to get the delegated name servers of the domain that you're trying to verify on Amazon SES. On macOS or a Linux operating system, run the dig command:Note: Replace example.com with the domain that you're trying to verify on Amazon SES.$ dig -t NS example.com;; ANSWER SECTION:example.com.   172800  IN    NS    ns1.example.com.example.com.   172800  IN    NS    ns2.example.com.example.com.   172800  IN    NS    ns3.example.com.On the Windows operating system, run thenslookup command:Note: Replace  example.com with the domain that you're trying to verify on Amazon SES.C:\>nslookup -type=NS example.comNon-authoritative answer:example.com     nameserver = ns3.example.comexample.com     nameserver = ns4.example.comexample.com     nameserver = ns1.example.comexample.com     nameserver = ns2.example.comThen, go to the DNS service where you created your CNAME records to get the name servers. For example, if you created your CNAME records in Amazon Route 53, then open the Route 53 console. When you view your CNAME records in the Route 53 console, the name servers appear in the Value column.If the delegated name servers of the domain that you want to verify don't match the name servers that have the CNAME record, then do one of the following:Add the CNAME record in the delegated name servers.Configure the name servers that have the CNAME records as the new delegated name servers in your DNS registrar.Retry the domain verification on Amazon SESAfter you correct any issues on your records, retry the domain verification on Amazon SES.Follow these steps to retry domain verification when the status is "verification pending":Open the Amazon SES console.From the AWS Region selector in the navigation bar, select the Region that your domain is in.In the left navigation pane, choose Verified identities. Then, select the domain that's stuck in "verification pending."Choose Delete, and confirm the delete.Choose Create identity. Then, re-enter the domain that's stuck in "verification pending," making sure to choose the same settings as you did originally.Choose Create identity.Wait for the domain's Verification Status to change to "verified."Follow these steps to retry domain verification when the status is "unverified":Open the Amazon SES console.From the AWS Region selector in the navigation bar, select the Region that your domain is in.In the left navigation pane, choose Verified identities. Then, select the domain that's stuck in "verification pending."Choose retry.Wait for the domain's Verification Status to change to "verified."Follow"


Question: Why is my AWS Batch job stuck in RUNNABLE status?

"My AWS Batch job is stuck in RUNNABLE status. Why is this happening, and how do I get my AWS Batch job unstuck?"

Answer: "My AWS Batch job is stuck in RUNNABLE status. Why is this happening, and how do I get my AWS Batch job unstuck?Short descriptionAWS Batch moves a job to RUNNABLE status when the job has no outstanding dependencies and is ready to be scheduled to a host. RUNNABLE jobs are started as soon as sufficient resources are available in one of the compute environments that are mapped to the job's queue.If the required resources to run a job aren't available, then the job can remain in RUNNABLE status indefinitely. For more information, see Jobs stuck in a RUNNABLE status.Note: This article covers troubleshooting for Amazon Elastic Container Service (Amazon ECS) on Amazon Elastic Compute Cloud (Amazon EC2) and Amazon ECS on AWS Fargate. To troubleshoot AWS Batch on Amazon Elastic Kubernetes Service (Amazon EKS), see AWS Batch on Amazon EKS.To troubleshoot AWS Batch jobs stuck in RUNNABLE status, do the following.ResolutionVerify that your compute environment has enough resources to run your job1.    Open the AWS Batch console.2.    Choose Dashboard.3.    In the Job queue overview pane, in the RUNNABLE column, choose the job that's stuck in RUNNABLE status. The Job details page appears.4.    On the Job details page, in the Container section, review the values for vCPUs, Memory, and GPUs. You need these values to complete steps 9–10.5.    On the Job queues page, select a job queue and review its associated compute environments because any compute environment might run your job. Next, repeat steps 6–10 for each compute environment.6.    On the Compute Environments page, select a compute environment to review its permissions.7.    Verify that the compute environment's Status column is set to VALID. Also make sure that the service role associated with the environment has all the necessary permissions.Note: When there are intermittent or transient errors, it might take a few minutes for the compute environment Status to change from VALID to INVALID.8.    Verify that the State column is set to ENABLED.9.    Verify that the Max vCPUs value is high enough to allow AWS Batch to increase the number of Desired vCPUs to run jobs.Note: If you're using an AWS Fargate compute environment, then go to the "Verify the network and security settings of the compute environment" section.10.    Verify that the Desired vCPUs value is the same or higher than the number of vCPUs that the job needs to run.If Desired vCPUs is 0, check the amount of memory and CPU resources available for your Amazon EC2 instance type.-or-If Desired vCPU is higher than 0, or your job is still in  RUNNABLE status, then complete the steps in the next section.Important: At least one of the instance types for your compute environment must have more memory than what your job specifies. Also, the instance type must have CPU resources that are equal to or more than what your job specifies. If at least one instance type doesn't have enough memory or CPU resources to run your job, cancel the job. Then, run a new job that requires less CPU or memory. Or, create a new compute environment with enough resources to run the job, and then assign the job to the appropriate job queue.Verify that your compute environment has instances and the instances are available to run your jobFor the compute environment you identified as the one that must run your job, take the following steps:1.    Open the Amazon ECS console.2.    In the navigation pane, choose Clusters. Then, choose the cluster that contains your job.For general ECS troubleshooting instructions, see Amazon ECS troubleshooting.Note: The name of the cluster starts with the name of the compute environment. This is followed by _Batch_ and a random hash of numbers and letters.3.    Choose the ECS Instances view. Then, verify that container instances are available to run your job.4.    If the cluster has a container instance available to run your job, check the status of the Docker daemon. Then, check the status of the Amazon ECS container agent.Note: For more information, see How do I troubleshoot a disconnected Amazon ECS agent?If there are no instances in the Amazon ECS cluster, then verify that instances can be created in your compute environment. To verify that your instances can be created, complete one of the following procedures based on your compute environment.To verify that your instances can be created in an On-Demand compute environment:1.    Open the Amazon EC2 console.2.    In the left navigation pane, choose Auto Scaling Groups.3.    For Filter, enter the name of your compute environment.Note: Amazon EC2 can create more than one Auto Scaling group for the same compute environment.4.    For each Auto Scaling group, choose the Activity History view. Then, look for any blocking issues.The Status column shows Unsuccessful if there are any issues blocking the instances from launching.For example, if your account reaches the maximum number of instances, then Amazon EC2 might return a message similar to the following:Launching a new EC2 instance. Status Reason: Your quota allows for 0 more running instance(s). You requested at least 1. Launching EC2 instance failed.The event includes a timestamp in UTC from when you submitted the job. For example:At 2018-09-03T05:54:30Z a user request update of AutoScalingGroup constraints to min: 0, max: 1, desired: 1 changing the desired capacity from 0 to 1.At 2018-09-03T05:54:52Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.Note: AWS Batch requests instances on your behalf. If you modify the Auto Scaling groups manually, then your compute environment might be invalidated. For more information about instance limits and how to request a limit increase, see Amazon EC2 service quotas.5.    If the Auto Scaling group shows only successful events in recent events, then complete the steps in the following section.Important: Certain permissions must be set for the service-linked AWS Identity and Access Management (IAM) role AWSServiceRoleForAutoScaling. The IAM role AWSServiceRoleForAutoScaling must have user access to the customer managed AWS Key Management Service (AWS KMS) key at a minimum. This is necessary in environments with custom Amazon Machine Images (AMIs), encrypted Amazon Elastic Block Store (Amazon EBS) volumes, and customer managed AWS KMS keys. For more information, see Key policy sections that allow access to the customer managed key.To verify that your instances can be created in a Spot compute environment:1.    Open the Amazon EC2 console.2.    In the navigation pane, choose Instances. Then, choose Spot Requests.3.    In the filter, for Request type, choose fleet.4.    For Status, choose active.5.    Choose Description. Then, review the Total target capacity value to see if the Spot Instance request was fulfilled. If no instance was created, then check the History view to see a message that explains why. For example, requests that can't reach a bid price return a message similar to the following:m4.large, ami-aff65ad2, Linux/UNIX (Amazon VPC), us-east-1a, Spot bid price is less than Spot market price $0.03246.    Choose an appropriate bid percentage for your compute environment. Make sure that you create a new compute environment if you change the bid price. For more information, see Spot Instance pricing history.Note: AWS Batch creates Spot Fleet requests on your behalf. Avoid modifying Spot Fleet requests manually, or your compute environment might be invalidated.7.    If the most recent events of the Auto Scaling group show only successful events, then complete the steps in the next section.Verify the container instance IAM role1.    Open the AWS Batch console.2.    In the navigation pane, choose Compute environments. Then, choose your compute environment.3.    In the Compute environment details section, copy the Instance role name.4.    Open the IAM console.5.    In the search box, enter the Instance role name. Then, choose your instance role from the results.6.    Choose the Permissions view. Then, confirm that the AmazonEC2ContainerServiceforEC2Role managed policy is attached to the role. If the policy is attached, then your instance role is properly configured and you can skip to step 11.7.    Choose Attach Policies.8.    In the search box, enter AmazonEC2ContainerServiceforEC2Role.9.    For the AmazonEC2ContainerServiceforEC2Role policy, select the check box. Then, choose Attach Policy.10.    Choose the Trust Relationships view. Then, choose Edit trust relationship.11.    Confirm that the trust relationship contains the following policy:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Principal": {        "Service": "ec2.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}12.    If the trust relationship matches the policy in the preceding example, then choose Cancel.-or-If the trust relationship doesn't match the policy in the preceding example, then copy the policy into the Policy Document console. Then, choose Update Trust Policy.If your instance still isn't joining the Amazon ECS cluster, then complete the steps in the next section.Verify the network and security settings of the compute environment1.    Open the AWS Batch console.2.    In the navigation pane, choose Compute environments. Then, choose your compute environment.3.    In the Compute resources section, copy the Subnets and Security groups values.4.    Open the Amazon Virtual Private Cloud (Amazon VPC) console.5.    In the navigation pane, choose Subnets.6.    For each subnet in the compute environment, choose Description. Then, review the Auto-assign public IPv4 address values.If the Auto-assign public IPv4 address value is Yes, the instances launched in the subnet have the following:A public IPv4 addressA route table with a route destination of 0.0.0.0/0An internet gateway set to Target (for example: igw-1a2b3c4d)If the Auto-assign public IPv4 address value is No, the instances launched in the subnet have the following:A private IPv4 addressA route table with a route destination of 0.0.0.0/0A NAT gateway set to Target (for example: nat-12345678901234567).Note: For more information, see Routing.7.    In the navigation pane, choose Security Groups.8.    For each security group specified in the compute environment, choose the Outbound Rules view. Then, verify that a rule with the following settings exists:For Type, choose ALL Traffic.For Protocol, choose ALL.For Port Range, choose ALL.For Destination, choose and 0.0.0.0/0.Important: If the rule doesn't exist, choose Edit. Then, create the rule. For a more restrictive rule for outbound traffic, choose HTTPS (443) for Type and 0.0.0.0/0 for Destination.9.    In the navigation pane, choose Network ACLs.10.    Choose the VPC's network access control list (network ACL).11.    Confirm that the default network ACL is configured to allow all traffic to flow in and out of associated subnets.Important: If you modified the ACL, add a rule that allows outbound IPv4 HTTPS traffic from the subnet to the internet. For more information, see Control traffic to EC2 instances with security groups and Control traffic to subnets with network ACLs. To change the VPC, subnets, or security groups, create a new compute environment.If your instance still isn't joining the Amazon ECS cluster, connect to your instance. Then, check the status of the Docker daemon and the Amazon ECS container agent.Note: The procedures in this article don't cover all possible root causes and the ways to troubleshoot them. In case you must dive deeper into an issue where your AWS Batch job is stuck in RUNNABLE status, AWS CloudTrail can be useful. In CloudTrail, you can look up events with the Username attribute set to aws-batch to gather clues about errors that occur during scheduled tasks.Related informationConnect to your Linux instanceConnect to your Windows instanceFollow"


Question: Why am I getting the error "Invalid principal in policy" when I try to update my Amazon S3 bucket policy?

"I'm trying to add or edit the bucket policy of my Amazon Simple Storage Service (Amazon S3) bucket using the console. However, I'm getting the error message "Error: Invalid principal in policy.""

Answer: "I'm trying to add or edit the bucket policy of my Amazon Simple Storage Service (Amazon S3) bucket using the console. However, I'm getting the error message "Error: Invalid principal in policy."ResolutionYou receive the Error: Invalid principal in policy message when the value of a Principal in your bucket policy isn't valid. To resolve this error, check the following:Your bucket policy uses supported values for a Principal element.The Principal element is formatted correctly.If the Principal is an AWS Identity and Access Management (IAM) user or role, then confirm that the user or role wasn't deleted.Your bucket policy uses supported values for a Principal elementReview the Principal elements in your bucket policy. Check that they're using one of these supported values:The ARN of an IAM user or roleNote: To find the ARN of an IAM user, run the get-user AWS Command Line Interface (AWS CLI) command. To find the ARN of an IAM role, run the get-role AWS CLI command. If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI. An AWS account ID or AWS service principalsThe string "*" to represent all usersWarning: When used with "Action:" "Allow", the "*" Principal element grants access to all users, both authenticated and anonymous. Before you use this combination in your bucket policy, confirm that your content supports this level of access.The Principal value is formatted correctlyReview the Principal elements in the policy and check that they're formatted correctly. If Principal includes one user, then the element must be in this format:"Principal": {    "AWS": "arn:aws:iam::111111111111:user/user-name1"}When you specify users in a Principal element, you can't use "*" to indicate all users. You must include specific users for the Principal element.If the Principal element includes more than one IAM user or IAM role, then the element must be in this format:"Principal": {  "AWS": [    "arn:aws:iam::111111111111:user/user-name1",    "arn:aws:iam::111111111111:role/role-name1"  ]}If the Principal is all users, then the element must be in this format:{  "Principal": "*"}It's a best practice not to use a wildcard (*) in the Principal element of a resource-based policy with an Allow effect. Use the wildcard only if you intend to grant public or anonymous access. Specify intended principals, services, or AWS accounts in the Principal element. Then, use the Condition element to restrict access. This is especially true for IAM role trust policies because these policies allow other principals to become a principal in your account.The IAM user or role wasn't deletedIf your bucket policy includes IAM users or roles in the Principal element, then confirm that those IAM identities weren't deleted. Be sure to specify the unique identifiers instead of full ARNs in the Principal element. This can help to identify the deleted IAM users and roles in the current bucket policy.Example:"Principal": {  "AWS": [    "arn:aws:iam::111111111111:user/user-name1",     "AIDAJQABLZS4A3QDU576Q",     "arn:aws:iam::111111111111:user/user-name2"  ]}If you try to save the bucket policy with a unique identifier as the Principal element, then you get the Invalid principal in policy error. This is because the Principal element supports only valid IAM ARNs. To resolve this error, you must remove any unique identifier from the Principal element.The IAM principal's account doesn't have an AWS Region turned onIf your S3 bucket is in an AWS Region that isn't turned on by default, then confirm that the IAM principal's account has the Region turned on. For more information, see Managing AWS Regions.Related informationAWS Policy GeneratorAWS JSON policy elements: PrincipalFollow"


Question: How do I provide a counter-notice to a DMCA notice?

I have received a notice from AWS that someone has reported my content as infringing a copyright. How do I provide a counter-notice to a Digital Millennium Copyright Act (DMCA) notice?

Answer: "I have received a notice from AWS that someone has reported my content as infringing a copyright. How do I provide a counter-notice to a Digital Millennium Copyright Act (DMCA) notice?ResolutionCopyright-protected content can be removed or disabled if it was posted, used, or distributed using AWS resources without the copyright owner’s permission.If you believe that your content on AWS was removed or disabled pursuant to a DMCA takedown notice by mistake or due to misidentification of the content, you can contest the takedown by submitting a counter-notice to our DMCA Agent at ec2-abuse@amazon.com or abuse@amazonaws.com.Your counter-notice must include all the following information:The material alleged to be infringing, including its location.A statement by you declaring under penalty of perjury that you have a good-faith belief that the material at issue was either misidentified or mistakenly removed.Your name, address, and telephone number.One of the following two statements:(a) If you are located within the United States: "I consent to the jurisdiction of the United States federal district court for the judicial district in which my address is located and will accept service of process from the person who provided the notice set forth above or their agent."(b) If you are located outside of the United States: "I consent to the jurisdiction of any United States federal district court where AWS is located and will accept service of process from the person who provided the notice set forth above or their agent."Your physical or electronic signature.Note: False statements in your written counter-notice can lead to civil or criminal penalties. The AWS Abuse team won't open attachments under any circumstance. You must provide any necessary information in plaintext.What happens after you send a counter-notice?We'll review your counter-notice when we receive it. If we have questions, we'll email you asking for more information. Otherwise, if your counter-notice is complete and valid, we'll forward the information that you provided to the person who filed the complaint. If they don't notify us within 10-14 business days that they have filed a lawsuit against you, we'll take steps to restore the content that we removed or disabled.The information above is provided for general informational purposes only and is not legal advice. If you have any questions about this information or your specific situation or rights, seek legal advice from a professional.Related informationHow do I submit a Digital Millennium Copyright Act (DMCA) notice to AWS?Follow"


Question: How can I share a portfolio with accounts in my organization using AWS Service Catalog?

"I want to share a portfolio with accounts in my organization using AWS Service Catalog. Then, I want to allow users in the receiving account to view and launch those products."

Answer: "I want to share a portfolio with accounts in my organization using AWS Service Catalog. Then, I want to allow users in the receiving account to view and launch those products.Short descriptionTo share your portfolio, complete the steps in the following sections:Share the portfolio with the organization or a specific organizational unit (OU) from the provider accountImport the portfolio to the target accountAllow users to access products in the shared portfolio from the target accountResolutionShare the portfolio with the organization or a specific OU from the provider accountOpen the AWS Service Catalog console.In the navigation pane, choose Portfolios list.To choose the portfolio that you want to share, select the radio button next to the portfolio.Choose Share Portfolio.Choose Organization.For Node Type, choose Organization or Organizational Unit based on your needs.Note: To share the portfolio with all OUs in the organization, choose Organization. To share the portfolio with a single OU within the organization, choose Organizational Unit.For Input Value, enter your organization ID or OU ID.Choose Share.Now, a message confirms that you have successfully shared your portfolio.Import the portfolio to the target accountOpen the AWS Service Catalog console of the target account.In the navigation pane, choose Portfolios.Choose the Imported tab.Choose Actions, and then choose Import portfolio.For Portfolio ID, enter the portfolio ID that has been shared with this account from the management account.Choose Import.Now, the shared portfolio is listed in the Portfolios section of the Imported tab.Allow users to access products in the shared portfolio from the target accountTo allow other users, groups, and roles to see the products shared in the portfolio, complete the following steps from the target account:Open the AWS Service Catalog console of the target account.In the navigation pane, choose Portfolios list, and then choose the shared portfolio.Choose Users, Groups, and Roles, and then choose Add user, group or role.To give an AWS Identity and Access Management (IAM) entity access to products in the portfolio, choose the Groups tab, Users tab, or Roles tab, depending on your needs.Select the IAM entity that you want to add access for.Choose ADD ACCESS.Follow"


Question: How do I publish logs for Amazon RDS or Aurora for MySQL instances to CloudWatch?

I have an Amazon Relational Database Service (Amazon RDS) or Amazon Aurora instance that's running MySQL. How can I view the DB logs for my instance in Amazon CloudWatch?

Answer: "I have an Amazon Relational Database Service (Amazon RDS) or Amazon Aurora instance that's running MySQL. How can I view the DB logs for my instance in Amazon CloudWatch?Short descriptionTo view Amazon RDS logs in CloudWatch, first allow logging on the DB instance or cluster. Then, you can configure log exports on the DB instance to send the logs to CloudWatch.ResolutionAllow logging on your DB instanceFor Amazon RDS instances that run MySQL, modify the parameters for the  general_log and slow_query_log in a custom DB parameter group that's associated with the DB instance. To allow audit logging, add the MariaDB Audit Plugin to your custom option group. For more information, see How do I activate and monitor logs for an Amazon RDS for MySQL instance?For Aurora clusters that run MySQL, modify the paramters for the general_log and slow_query_log. Allow Advanced Auditing to audit the logs for your Aurora clusters by using a custom cluster parameter group.Publish logs to CloudWatchTo publish logs to CloudWatch, configure log exports on the DB instance and then set the log_output parameter to FILE. For Aurora, any selected log types are published for all instances of an Aurora DB cluster.Configure log exportsOpen the Amazon RDS console.Choose Databases from the navigation pane.Select the instance that you want to publish logs to CloudWatch for, and then choose Modify.From the Log exports section, select the log types that you want to publish.Choose Continue, and then choose Modify DB Instance.Note: This modification doesn't require downtime.Change the value of the log_output parameterNote: This step isn't required for Aurora clusters that run MySQL 5.7 unless the value of the log_output parameter was manually modified to TABLE. For Aurora clusters that run MySQL 5.7, the default value of the log_output parameter is FILE.Open the Amazon RDS console.Choose Parameter groups from the navigation pane.Select the parameter group that's associated with the instance that you want to publish logs for.Choose Parameter group actions, and then choose Edit.Use the Filter parameters field to search for the log_output parameter.Set the value of the log_output parameter to FILE.Choose Save changes.Note: This is a dynamic parameter, so this modification doesn't require a restart. For more information, see Working with parameter groups.Related informationHow do I modify the values of an Amazon RDS DB parameter group?MySQL database log filesPublishing Amazon Aurora MySQL logs to Amazon CloudWatch logsFollow"


Question: How do I use Amazon Cognito identity pools to grant users access to AWS services?

I want to use Amazon Cognito user pools to give users access to AWS resources.

Answer: "I want to use Amazon Cognito user pools to give users access to AWS resources.ResolutionYou can integrate Amazon Cognito identity pools with Amazon Cognito user pools to issue temporary credentials to access AWS resources. Set up an authentication provider by configuring an identity pool with a user pool. After authenticating a user through the user pool, use the user identity token with an authentication flow to retrieve temporary credentials from the identity pool. There's a basic authentication flow and an enhanced authentication flow to retrieve temporary credentials.Important: In the following example AWS Command Line Interface (AWS CLI) commands, replace all instances of example strings with your values. (For example, replace "example_identity_pool_id" with your identity pool ID or "abcdef" with your AWS Region's identity ID.)Basic flowNote: 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.Perform the following steps to retrieve temporary AWS credentials using the basic authflow:1.    From the old Amazon Cognito console, choose Manage Identity Pools. Select the name of the Amazon Cognito identity pool that you're updating, and then choose Edit identity pool. Under Authentication flow settings, select Allow Basic (Classic) Flow, and then save the changes.2.    To generate or retrieve a user identity in the identity pool, call the GetId API.An example get-id command:aws cognito-identity get-id --identity-pool-id "example_identity_pool_id" --logins cognito-idp.example_region.amazonaws.com/example_cognito_user_pool_id=example_cognito_user_id_tokenAn example output:{    "IdentityId": "region:abcdef"}3.    To retrieve the open ID token, use the result from step 2 to call the GetOpenIdToken API.An example get-open-id-token command:aws cognito-identity get-open-id-token --identity-id "region:abcdef" --logins cognito-idp.example_region.amazonaws.com/example_user_pool_id=example_cognito_user_id_tokenAn example output:{    "IdentityId": "region:abcdef",    "Token": "HIJKLMN"}4.    To retrieve the temporary credentials of the authenticated role, use the token from step 3 to call the AssumeRoleWithWebIdentity API.An example assume-role-with-web-identity command:aws sts assume-role-with-web-identity --role-arn "example_auth_role_arn_of_the_identity_pool" --web-identity-token "HIJKLMN" --role-session-name "example_session_name"An example output:{    "Credentials": {        AccessKeyId": "xxxxxxxxxxxx",        SecretAccessKey": "xxxxxxxxxxxx",        SessionToken": "xxxxxxxxxxxx",        Expiration": ""    },    "SubjectFromWebIdentityToken": "",    "AssumedRoleUser": {        "AssumedRoleId": "",        "Arn": ""    },    "Provider": "cognito-identity.amazonaws.com",    "Audience": ""}Enhanced flowPerform the following steps to retrieve temporary AWS credentials using the enhanced authflow:1.    To generate or retrieve a user identity in the Amazon Cognito identity pool, call the GetId API.An example get-id command:aws cognito-identity get-id --identity-pool-id "example_identity_pool_id" --logins cognito-idp.example_region.amazonaws.com/example_cognito_user_pool_id=example_cognito_user_id_tokenAn example output:{    "IdentityId": "region:abcdef"}2.    To retrieve temporary credentials from the identity pool, call the GetCredentialsForIdentity API.An example get-credentials-for-identity command:aws cognito-identity get-credentials-for-identity --identity-id region:abcdef --logins cognito-idp.example_region.amazonaws.com/example_cognito_user_pool_id = example_cognito_user_id_tokenAn example output:{    "IdentityId": "region:abcdef",    "Credentials": {        "AccessKeyId": "xxxxxxxxxx",        "SecretKey": "xxxxxxxxxx",        "SessionToken": "xxxxxxxxxx",        "Expiration": ""    }}To learn more about complex role-based access controls and attribute-based access controls, see Fine-grained access control with Amazon Cognito identity pools.Related informationIdentity pools (federated identities) authentication flowFollow"


Question: How can I test the upload speed of Amazon S3 Transfer Acceleration for a specific file size?

I want to use S3 Transfer Acceleration to improve the file upload speed to my Amazon Simple Storage Service (Amazon S3) bucket. I also want to compare the speeds between uploading directly to the S3 bucket and using S3 Transfer Acceleration. How can I do that?

Answer: "I want to use S3 Transfer Acceleration to improve the file upload speed to my Amazon Simple Storage Service (Amazon S3) bucket. I also want to compare the speeds between uploading directly to the S3 bucket and using S3 Transfer Acceleration. How can I do that?ResolutionTo compare the general upload speed across Amazon S3 Regions, you can use the Amazon S3 Transfer Acceleration Speed Comparison tool. To test the upload speed of a specific file size, use the test-upload.sh from the Amazon Web Services - Labs GitHub website.Before you run test-upload.sh, the following requirements must be met:1.    Review your AWS Identity and Access Management (IAM) user credentials to be sure that you have the permissions to enable Transfer Acceleration. You need the s3:PutAccelerateConfiguration permission to enable or disable Transfer Acceleration. Additionally, you need the s3:GetAccelerateConfiguration permission to view whether a bucket has Transfer Acceleration enabled. For more information, see Requirements for using Amazon S3 Transfer Acceleration.2.    Enable Transfer Acceleration on your S3 bucket.3.    Install and configure the AWS Command Line Interface (AWS CLI) on your machine.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Requirements for test-upload.shBefore you run test-upload.sh, you must first install the bc language on your Linux machine. Run this command to install bc on an Ubuntu or Debian machine:apt-get install bcRun this command to install bc on an Amazon Linux, CentOS, RHEL, or Fedora machine:yum install bcRequirements for test-upload.sh on a macOS machineBefore you run test-upload.sh, you must first install coreutils on your macOS machine using Homebrew. Follow these steps:1.    (Optional) If you don't have Homebrew installed, then follow the installation instructions on the Homebrew website.2.    Run this command to install coreutils using Homebrew:brew install coreutilsRelated informationUser policy examplesUsing Transfer Acceleration from the AWS Command Line Interface (AWS CLI)Follow"


Question: How do I calculate the total network usage for my EC2 instances and determine which instance used the most bandwidth within a date range?

I have Amazon Elastic Compute Cloud (Amazon EC2) instances. I want to calculate the total network usage for a period of time and determine which instance had the most network usage.

Answer: "I have Amazon Elastic Compute Cloud (Amazon EC2) instances. I want to calculate the total network usage for a period of time and determine which instance had the most network usage.Short descriptionUse the Amazon CloudWatch NetworkIn and NetworkOut metrics to determine which Amazon EC2 instance is causing high network usage. You can aggregate the data points from these metrics to calculate the network usage for your EC2 instance.Note: The CloudWatch NetworkOut metric is a different metric from the DataTransfer-Out-Bytes metric that's used in AWS Cost Explorer reports. The CloudWatch NetworkOut metric represents the amount of outbound network traffic from an instance, regardless of where it went.Prerequisites for using CloudWatch metrics:Set up an AWS Command Line Interface (AWS CLI) environment. For more information, see What is the AWS Command Line Interface? If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Turn on the cloudwatch:GetMetricStatistics permission for the AWS Identity and Access Management (IAM) user or role that you use to run the AWS CLI. See Actions, resources, and condition keys for Amazon CloudWatch for more information.Have a Bash shell to run the script.Note: The following resolution works only for instances that you can see in the Amazon EC2 dashboard. The following Bash shell script doesn't work for terminated instances. For terminated instances, add the instance IDs to the script in a space separated format.Example space separated format:ADD_INSTANCES="i-xxxx i-yyyy i-zzzz"ResolutionThe following Bash shell script identifies the network usage of all EC2 instances in an AWS Region.1.    Copy the following content to create a script:#!/bin/bashif [ $# -ne 4 ]; thenecho "Usage: $0 <REGION> <NetworkIn|NetworkOut> <START_TIMESTAMP> <END_TIMESTAMP>"echo -e "\tNote: Do not change the order of parameters."echo -e "\n\tExample: $0 ap-south-1 NetworkOut 2020-06-01T00:00:00.000Z 2020-06-30T23:59:59.000Z"exit 1fiREGION="$1"METRIC="$2"START_TIME="$3"END_TIME="$4"ADD_INSTANCES=""INSTANCES="${ADD_INSTANCES} $(aws ec2 describe-instances --region ${REGION} --query Reservations[*].Instances[*].InstanceId --output text)" || { echo "Failed to run aws ec2 describe-instances commandline, exiting..."; exit 1; }[ "${INSTANCES}x" == "x" ] && { echo "There are no instances found from the given region ${REGION}, exiting..."; exit 1; }for _instance_id in ${INSTANCES}; dounset _value_value="$(aws cloudwatch get-metric-statistics --metric-name ${METRIC} --start-time ${START_TIME} --end-time ${END_TIME} --period 86400 --namespace AWS/EC2 --statistics Sum --dimensions Name=InstanceId,Value=${_instance_id} --region ${REGION} --output text)"[ "${_value}x" == "x" ] && { echo "Something went wrong while calculating the network usage of ${_instance_id}"; continue; }echo "${_instance_id}: $(echo "${_value}" | awk '{ sum += $2 } END {printf ("%f\n", sum/1024/1024/1024)}';) GiB";doneecho -e "\nNote: If you think the values are inaccurate, please verify the input and modify if needed."2.    Save the script with any name. For example, network_usage.sh.network_usage.sh3.    Run the following command to turn on permission for the script to run:$ sudo chmod a+x network_usage.sh4.    Use the following syntax to run the script:$ bash network_usage.sh ap-south-1 NetworkOut 2020-06-01T00:00:00.000Z 2020-06-30T23:59:59.000ZReplace ap-south-1 with the Region where your instances are located. For more information, see Amazon EC2 Available Regions.Specify either NetworkIn or NetworkOut to calculate the traffic flow direction.Replace 2020-06-01T00:00:00.000Z and 2020-06-30T23:59:59.000Z with the start and end timestamps in the range that you want to calculate the network usage for.The following example shows a sample output from the preceding command:i-025a820f5ee9f1490: 0.000099 GiBi-0b56df07325d9c0fa: 0.008475 GiBi-09ad0a93b60a233b1: 0.000000 GiBi-0ba35b570c7003ffe: 0.000000 GiBi-012cc851406584b5c: 0.000000 GiBi-0ef3921993739d772: 219.884000 GiBi-01f193931c4101cf3: 0.000000 GiBi-05ca8ccc8aa7caf76: 0.009235 GiBi-06b165356b5769581: 0.000000 GiBi-06c4d1e1cb4e9139d: 0.012911 GiBi-070b6508dd4ab5040: 0.000000 GiBi-0f29e3ba7f156dfee: 0.000000 GiBRelated informationList the available CloudWatch metrics for your instancesGNU Bash (from the GNU website)Follow"


Question: Why is my WorkSpace frequently disconnecting and reconnecting?

"When I connect to my WorkSpace using the Amazon WorkSpaces client, the connection intermittently drops, and then the client attempts to reconnect to the WorkSpace. What causes my WorkSpace to disconnect frequently, and how can I fix this issue?"

Answer: "When I connect to my WorkSpace using the Amazon WorkSpaces client, the connection intermittently drops, and then the client attempts to reconnect to the WorkSpace. What causes my WorkSpace to disconnect frequently, and how can I fix this issue?Short descriptionA WorkSpace that frequently disconnects and reconnects usually indicates high round-trip time (RTT) or an unstable internet connection.For a healthy connection from your network to the AWS Region that your WorkSpace is in, the RTT should be less than 100 ms. For more information, see Amazon WorkSpaces client network requirements.If your local network has trouble maintaining connections, the WorkSpaces client drops the connection and tries to reconnect.ResolutionTo resolve issues with your WorkSpace frequently disconnecting and reconnecting, follow these steps:Verify your RTTUse Connection Health Check to verify that your internet connection is suitable for Amazon WorkSpaces:A FAST Speed Rating indicates that your RTT is less than 100 ms, resulting in a healthy connection.An ACCEPTABLE Speed Rating indicates an RTT between 100 ms and 250 ms. The RTT is suitable to connect, but you might experience degraded performance.A SLOW Speed Rating indicates an RTT above 250 ms. You might experience frequent connection issues and extreme lag while using the WorkSpace.Note: It's a best practice to use Connection Health Check several times throughout the day to see if your data changes.You can also see health checks specific to the machine that the client is running on. Launch the WorkSpaces client, and then choose Network on the bottom-right corner of the login window.Instability of the network that you access the WorkSpace from can also cause a WorkSpace to disconnect and reconnect.Note: Connection issues can occur if you're connected through a VPN, and then connect to your WorkSpace. Confirm whether the issue occurs only when you connect by using VPN or proxy, or whether the connection issues persist without VPN or proxy.You can ping the WorkSpaces API endpoint for your Region to see how much the RTT changes over the course of the ping. For example:ping -t workspaces.sa-east-1.amazonaws.comLet the ping run for at least 30 minutes to capture enough data points to determine if your network is stable. To end the ping, enter Ctrl-C.The output values for Minimum, Maximum, and Average should be similar. If any pings fail, or if you have RTT outliers in your ping, then this can indicate instability in your network.Note: If all pings time out, your network might be blocking ICMP-based traffic.To improve network stability, hard wire your computer to the network.If antivirus software is installed on the WorkSpace, make sure it doesn't interfere with the service components. You can set the exclusion for the WorkSpaces service component.Verify the client versionVerify that you're using the latest WorkSpaces client version. First, launch the client to confirm the version that you're using.For Windows, choose the gear icon, and then choose About Amazon WorkSpaces.For macOS, choose WorkSpaces on the top toolbar, and then choose About WorkSpaces.Then, visit WorkSpaces clients. Choose the Client Application link for the platform you're using to review the Release Notes. If your client is out of date, you can download the latest version from the About WorkSpaces page on the client.Reboot the WorkSpaceThere might also be an issue with the PCoIP Agent on the WorkSpace's side. Open the WorkSpaces console, and then select the WorkSpace that disconnects. Then, choose Actions, Reboot WorkSpaces. This runs through a WorkSpace initialization to make sure that all WorkSpace components are healthy.Related informationTroubleshooting WorkSpaces issuesTroubleshooting WorkSpaces client issuesFollow"


Question: How can I retrieve an Amazon S3 object that was deleted in a versioning-enabled bucket?

I want to retrieve an object that was deleted from my Amazon Simple Storage Service (Amazon S3) bucket that has versioning enabled. How can I do that?

Answer: "I want to retrieve an object that was deleted from my Amazon Simple Storage Service (Amazon S3) bucket that has versioning enabled. How can I do that?Short descriptionWhen you delete an object from a version-enabled bucket, Amazon S3 creates a delete marker for the object. The delete marker becomes the current version of the object, and the actual object becomes the previous version. With a delete marker, Amazon S3 responds to requests for the object as though the object was deleted. For example, if you send a GET request for the object, then Amazon S3 returns an error.You can retrieve an object that was deleted from a version-enabled bucket in one of these ways:Download the previous version of the object: To download the previous version of the object (the actual object), you must have permissions to s3:GetObjectVersion.Remove the delete marker: After you remove the delete marker, the actual object becomes the current version of the object. To remove the delete marker, you must have permissions to s3:DeleteObjectVersion. Also, you must remove the delete marker using the AWS account that owns or created the bucket.Note: If the bucket has MFA delete-enabled, you must use the designated multi-factor authentication (MFA) to remove the delete marker.ResolutionDownload the previous version of the object using the Amazon S3 console1.    Open the Amazon S3 console.2.    From the list of buckets, open the bucket of the deleted object.3.    Navigate to the folder of the deleted object.4.    Turn on Show versions.5.    In the search bar, enter the name of the deleted object.6.    Select the previous version of the object (the actual object rather than the delete marker). Choose Actions, and then choose Download.Download the previous version of the object using the AWS Command Line Interface (AWS CLI)Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.1.    Run the list-object-versions command on the bucket. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3api list-object-versions --bucket DOC-EXAMPLE-BUCKET --prefix example.txtNote: This example includes the --prefix option to filter the results to the specified key name prefix. This option helps reduce the number of results, which saves time when your bucket contains a large number of object versions.2.    From the command output, copy the version ID of the previous version of the object (the actual object rather than the delete marker).3.    Run the get-object command for the version ID that you copied in the previous step. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3api get-object --bucket DOC-EXAMPLE-BUCKET --key example.txt --version-id example.d6tjAKF1iObKbEnNQkIMPjj filename.txtRemove the delete marker using the Amazon S3 console1.    Open the Amazon S3 console from the AWS account that owns or created the bucket of the deleted object.2.    From the list of buckets, open the bucket of the deleted object.3.    Navigate to the folder of the deleted object.4.    Turn on Show versions.5.    In the search bar, enter the name of the deleted object.6.    Select the delete marker of the object.Warning: Review your selection carefully to be sure that it's the delete marker. If you delete an object version, it can't be retrieved.7.    Choose Delete.8.    In the Delete objects page, confirm that the correct delete marker is listed. Then, enter permanently delete to confirm deletion.9.    Choose Delete objects.Important: You can't use the Amazon S3 console to undelete folders. To do so, you must use the AWS CLI or the AWS SDK.Remove the delete marker using the AWS CLIRemove the delete mark on several objects1.    Run the list-object-versions command with the following --query parameter. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3api list-object-versions --bucket DOC-EXAMPLE-BUCKET --prefix example.txt --query 'DeleteMarkers[?IsLatest==`true`]'Note: The following example command includes the --prefix option, which filters the results to the specified key name prefix. This option helps reduce the number of results, which saves time if your bucket contains a large volume of object versions.2.    The command returns all objects in the bucket that were deleted. From the command output, copy the version ID of the delete marker for the object that you want to retrieve.Warning: Review the version ID carefully to be sure that it's the version ID of the delete marker. If you delete an object version, it can't be retrieved.3.    Run the delete-object command for the version ID that you copied in the previous step. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3api delete-object --bucket DOC-EXAMPLE-BUCKET --key example.txt --version-id 'example.d6tjAKF1iObKbEnNQkIMPjj'4.    After you remove the delete marker, the actual object is returned when you list the objects in the bucket. To verify that the delete marker was removed, run the ls command. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3 ls s3://DOC-EXAMPLE-BUCKETRemove the delete marker on thousands of objects1.    Navigate to AWS CloudShell.2.    Run the following AWS CLI command. Replace DOC-EXAMPLE-BUCKET with the name of your bucket.aws s3api list-object-versions --bucket DOC-EXAMPLE-BUCKET --prefix examplefolder/ --output json --query 'DeleteMarkers[?IsLatest==`true`].[Key, VersionId]' | jq -r '.[] | "--key '\''" + .[0] + "'\'' --version-id " + .[1]' | xargs -L1 aws s3api delete-object --bucket DOC-EXAMPLE-BUCKETNote: This example uses the JQ tool from GitHub to parse the ListObjectVersions response for current version DeleteMarkers. You can make changes to this custom script example based on your specific use case. By default, JQ is installed on AWS CloudShell. If you don't interact with the shell environment, your shell session will end.Remove the delete marker on millions of objectsIf your bucket has millions of objects, then performing the LIST call can be expensive, resulting in a timeout. Therefore, consider using a custom script with the AWS SDK.Follow"


Question: How can I share a subnet in a VPC with another AWS account?

I want to share a subnet in an Amazon Virtual Private Cloud (Amazon VPC) in my account with another AWS account. How can I do this?

Answer: I want to share a subnet in an Amazon Virtual Private Cloud (Amazon VPC) in my account with another AWS account. How can I do this?ResolutionImportant: A subnet can be shared only across accounts that are in the same AWS Organization.Turn on resource sharing within AWS Organizations using the management account.Create a resource share.Share a subnet from the account that owns the VPC (owner account) to the account that will use the subnet (participant account). The shared subnet automatically appears in the participant account.Related informationHow Amazon VPC worksShare your VPC with other accountsFollow


Question: Why can't I connect to a service when the security group and network ACL allow inbound traffic?

"I can't connect to a service running on an Amazon Elastic Compute Cloud (Amazon EC2) instance. I allowed inbound traffic to the necessary ports in both the security group and the network access control list (network ACL), but it's still not working. How can I fix this?"

Answer: "I can't connect to a service running on an Amazon Elastic Compute Cloud (Amazon EC2) instance. I allowed inbound traffic to the necessary ports in both the security group and the network access control list (network ACL), but it's still not working. How can I fix this?Short descriptionSecurity groups are stateful, so allowing inbound traffic to the necessary ports activates the connection. Network ACLs are stateless, so you must allow both inbound and outbound traffic.ResolutionTo turn on the connection to a service running on an instance, the associated network ACL must allow the following:Inbound traffic on the port that the service is listening onOutbound traffic to ephemeral portsWhen a client connects to a server, a random port from the ephemeral port range (1024-65535) becomes the client's source port.The designated ephemeral port becomes the destination port for return traffic from the service. Outbound traffic to the ephemeral port must be allowed in the network ACL. For more information on modifying network ACL rules, see Add and delete rules.By default, network ACLs allow all inbound and outbound traffic. If your network ACL is more restrictive, then you need to explicitly allow traffic to the ephemeral port range.Note: If you accept traffic from the internet, then you also must establish a route through an internet gateway. If you accept traffic over VPN/AWS Direct Connect/Transit Gateway, then you must establish a corresponding route through a virtual private gateway/transit gateway.Related informationControl traffic to subnets using Network ACLsControl traffic to resources using security groupsFollow"


Question: Can I migrate a CloudFront distribution to another AWS account?

How can I migrate my Amazon CloudFront distribution to another AWS account?

Answer: "How can I migrate my Amazon CloudFront distribution to another AWS account?ResolutionCloudFront doesn't support the migration of a distribution from one AWS account to another AWS account.However, CloudFront does support the migration of a custom CNAME from one distribution to another distribution. You can migrate the CNAME to a distribution in the same AWS account, or to a distribution in another AWS account. For instructions on how to migrate a CNAME to another CloudFront distribution, see How do I resolve the error CNAMEAlreadyExists error when I set up a CNAME alias for my CloudFront distribution?Note: The default CloudFront domain name on your distribution can't be migrated between AWS accounts. The domain name format is similar to: d1234abcd.cloudfront.netRelated informationUsing custom URLs by adding alternate domain names (CNAMEs)Adding an alternate domain nameFollow"


Question: Who turned on public access to my Amazon S3 bucket?

How can I find out which user turned on public access to an Amazon Simple Storage Service (Amazon S3) bucket?

Answer: "How can I find out which user turned on public access to an Amazon Simple Storage Service (Amazon S3) bucket?ResolutionReview the AWS CloudTrail event history to see which user updated either the bucket access control list (ACL) or the bucket policy to allow public access.Note: CloudTrail event history shows logs of up to 90 days. If the event occurred after 90 days, you must query and analyze CloudTrail logs delivered to your bucket.CloudTrail consoleFollow these steps to find the user by using the CloudTrail console:Open the CloudTrail console.From the Region selector in the navigation bar, select the AWS Region that your bucket is in.From the navigation pane, choose Event history.For Lookup attribute, select the filter that you want to use to find the event that granted public access to your bucket:To filter events by your bucket's name, select Resource name, and then enter your bucket's name.To filter events by changes to a bucket ACL, select Event name, and then enter "PutBucketAcl".To filter events by changes to a bucket policy, select Event name, and then enter "PutBucketPolicy".After you find the event that granted public access to your bucket, review the event's User name column. Then, expand the event item and choose View event to see more details, such as the user's Amazon Resource Name (ARN).AWS Command Line Interface (AWS CLI)Run this command to list CloudTrail events associated with your bucket (using your bucket's name):aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=example-bucket-name --region example-regionRun this command to list events that are changes to a bucket ACL:aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutBucketAcl --region example-regionRun this command to list events that are changes to a bucket policy:aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutBucketPolicy --region example-regionRelated informationViewing events with CloudTrail Event historyCloudTrail record contentslookup-eventsFollow"