Question: How do I set up Okta as an OpenID Connect identity provider in an Amazon Cognito user pool?

I want to use Okta as an OpenID Connect (OIDC) identity provider (IdP) in an Amazon Cognito user pool. How do I set that up?

Answer: "I want to use Okta as an OpenID Connect (OIDC) identity provider (IdP) in an Amazon Cognito user pool. How do I set that up?Short descriptionAmazon Cognito user pools allow sign-in through a third party (federation), including through an IdP such as Okta. For more information, see Adding user pool sign-in through a third party and Adding OIDC identity providers to a user pool.A user pool integrated with Okta allows users in your Okta app to get user pool tokens from Amazon Cognito. For more information, see Using tokens with user pools.ResolutionCreate an Amazon Cognito user pool with an app client and domain nameCreate a user pool.Note: During creation, the standard attribute email is selected by default. For more information, see Configuring user pool attributes.Create an app client in your user pool. For more information, see Add an app to enable the hosted web UI.Add a domain name for your user pool.Sign up for an Okta developer accountNote: If you already have an Okta developer account, sign in.On the Okta Developer signup webpage, enter your personal information, and then choose SIGN UP. The Okta Developer Team sends a verification email to the email address that you provided.In the verification email, find the sign-in information for your account. Choose ACTIVATE, sign in, and finish creating your account.Create an Okta appOpen the Okta Developer Console. For more information about the console, see Okta’s Redesigned Admin Console and Dashboard—Now in GA! on the Okta Developer Blog.In the navigation pane, expand Applications, and then choose Applications. This opens the Applications Console. For more information, see Administrator Console on the Okta Organizations page of the Okta Developer website.Choose Create App Integration.On the Create a new app integration page, choose OpenID Connect, choose Web Application, and then choose Next.Configure settings for your Okta appOn the New Web App Integration page, under General Settings, enter a name for your app. For example, TestApp.Under Grant type, confirm that the Authorization Code check box is selected. Your user pool uses this flow to communicate with Okta OIDC for federated user sign-in.For Sign-in redirect URIs, enter https://myUserPoolDomain/oauth2/idpresponse. This is where Okta sends the authentication response and ID token.Note: Replace myUserPoolDomain with your Amazon Cognito user pool domain. You can find the domain in the Amazon Cognito console on the Domain name page for your user pool.Under CONFIGURE OPENID CONNECT, for Login redirect URIs, enter https://myUserPoolDomain/oauth2/idpresponse. This is where Okta sends the authentication response and ID token.Note: Replace myUserPoolDomain with your Amazon Cognito user pool domain. Find the domain in the Amazon Cognito console on the Domain name page for your user pool.In Controlled access, choose your preferred access setting, and then choose Save.In Client Credentials, copy the Client ID and Client secret. You need these credentials for configuring Okta in your Amazon Cognito user pool.Choose Sign On.On the Sign On page, In OpenID Connect ID Token, note the Issuer URL. You need this URL for configuring Okta in your user pool.Add an OIDC IdP in your user poolIn the Amazon Cognito console, choose Manage user pools, and then choose your user pool.In the left navigation pane, under Federation, choose Identity providers.Choose OpenID Connect.Do the following:For Provider name, enter a name for the IdP. This name appears in the Amazon Cognito hosted web UI.Note: You can't change this field after creating the provider. If you plan to include this field in your app or use the Amazon Cognito hosted web UI, use a name that you're comfortable with your app's users seeing.For Client ID, paste the Client ID that you noted earlier from Okta.For Client secret (optional), paste the Client secret that you noted earlier from Okta.For Attributes request method, leave the setting as GET.For Authorize scope, enter the OIDC scope values that you want to authorize, separated by spaces. For more information, see Scope values in OpenID Connect Basic Client Implementer's Guide 1.0 on the OpenID website.Important: The openid scope is required for OIDC IdPs, and you can add other scopes according to your user pool configuration. For example, if you kept email as a required attribute when creating your user pool, enter email openid to include both scopes. You can map the email attribute to your user pool later in this setup.For Issuer, paste the Issuer URL that you copied earlier from Okta.For Identifiers (optional), you can optionally enter a custom string to use later in the endpoint URL in place of your OIDC IdP's name.Choose Run discovery to fetch the OIDC configuration endpoints for Okta.Choose Create provider.For more information, see Add an OIDC IdP to your user pool.Change app client settings for your user poolIn the Amazon Cognito console, choose Manage user pools, and then choose your user pool.In the left navigation pane, under App integration, choose App client settings.On the app client page, do the following:Under Enabled Identity Providers, choose the OIDC provider check box for the IdP that you created earlier.(Optional) Choose the Cognito User Pool check box.For Callback URL(s), enter a URL where you want your users to be redirected after logging in. For testing, you can enter any valid URL, such as https://example.com/.For Sign out URL(s), enter a URL where you want your users to be redirected after logging out. For testing, you can enter any valid URL, such as https://example.com/.Under Allowed OAuth Flows, select the flows that correspond to the grant types that you want your application to receive after authentication from Cognito.Note: The allowed OAuth flows you enable determine which values (code or token) you can use for the response_type parameter in your endpoint URL.Under Allowed OAuth Scopes, select at least the email and openid check boxes.Choose Save changes.For more information, see App client Settings terminology.Map the email attribute to a user pool attributeIf you authorized the email OIDC scope value earlier, map it to a user pool attribute.In the Amazon Cognito console, choose Manage user pools, and then choose your user pool.In the left navigation pane, under Federation, choose Attribute mapping.On the attribute mapping page, choose the OIDC tab.If you have more than one OIDC provider in your user pool, choose your new provider from the dropdown list.Confirm that the OIDC attribute sub is mapped to the user pool attribute Username.Choose Add OIDC attribute, and then do the following:For OIDC attribute, enter email.For User pool attribute, choose Email.For more information, see Specifying identity provider attribute mappings for your user pool.Log in to test your setupAuthenticate with Okta using the Amazon Cognito hosted web UI. After you log in successfully, you're redirected to your app client's callback URL. The authorization code or user pool tokens appear in the URL in your web browser's address bar.For more information, see Using the Amazon Cognito Hosted UI for sign-up and sign-in.Related informationOIDC user pool IdP authentication flowHow do I set up Okta as a SAML identity provider with an Amazon Cognito user pool?Follow"


Question: How do I allow a legitimate IP address when using the IP reputation list or anonymous IP list in AWS WAF?

My legitimate requests are being blocked by an Amazon IP reputation list managed rule group or Anonymous IP list managed rule group. How do I allow my IP address in AWS WAF?

Answer: "My legitimate requests are being blocked by an Amazon IP reputation list managed rule group or Anonymous IP list managed rule group. How do I allow my IP address in AWS WAF?Short descriptionLegitimate requests might be blocked by one of the following AWS managed rule groups:Amazon IP reputation list managed rule groups allow you to block requests based on their source IP address that are typically associated with bots or other threats.Anonymous IP list managed rule groups contains rules to block requests from services that allow the obfuscation of viewer identity like VPNs or proxies.To allow a specific IP address or addresses, use one of the following methods to resolve this problem:Scope-down statements to narrow the scope of the requests that the rule evaluates. Choose this option for addressing logic in a single rule group.Labels on web requests to allow a rule that matches the request to communicate the match results to rules that are evaluated later in the same web ACL. Choose this option to reuse the same logic across multiple rules.ResolutionOption 1: Using scope-down statementsFirst, create an IP set.Open the AWS WAF console.In the navigation pane, choose IP sets, and then choose Create IP set.Enter an IP set name and Description - optional for the IP set. For example: MyTrustedIPs.Note: You can't change the IP set name after you create the IP set.For Region, choose the AWS Region where you want to store the IP set. To use an IP set in web ACLs that protect Amazon CloudFront distributions, you must use Global (CloudFront).For IP version, choose the version you want to use.For IP addresses, enter one IP address or IP address range per line that you want to allow in CIDR notation.Note: AWS WAF supports all IPv4 and IPv6 CIDR ranges except for /0.Examples:To specify the IPv4 address 192.168.0.26, enter 192.168.0.26/32.To specify the IPv6 address 0:0:0:0:0:ffff:c000:22c, enter 0:0:0:0:0:ffff:c000:22c/128.To specify the range of IPv4 addresses from 192.168.20.0 to 192.168.20.255, enter 192.168.20.0/24.To specify the range of IPv6 addresses from 2620:0:2d0:200:0:0:0:0 to 2620:0:2d0:200:ffff:ffff:ffff:ffff, enter 2620:0:2d0:200::/64.Review the settings for the IP set. If it matches your specifications, choose Create IP set.Then, add a scope-down statement to the specific AWS Managed Rule blocking your requests.In the navigation pane, under AWS WAF, choose Web ACLs.For Region, select the AWS Region where you created your web ACL.Note: Select Global if your web ACL is set up for Amazon CloudFront.Select your web ACL.In the web ACL Rules tab, choose the specific AWS Managed Rule group that is blocking your request, and then choose Edit.For Scope-down statement - optional, choose the Enable scope-down statement.For If a request, choose doesn't match the statement (NOT).On Statement, for Inspect, choose Originates from IP address in.For IP Set, choose the IP Set you created earlier. For example: MyTrustedIPs.For IP address to use as the originating address, choose Source IP address.Choose Save rule.Option 2: Using labels on web requestsFirst, create an IP set.Open the AWS WAF console.In the navigation pane, choose IP sets, and then choose Create IP set.Enter an IP set name and Description - optional for the IP set. For example: MyTrustedIPs.Note: You can't change the IP set name after you create the IP set.For Region, choose the AWS Region where you want to store the IP set. To use an IP set in web ACLs that protect Amazon CloudFront distributions, you must use Global (CloudFront).For IP version, choose the version you want to use.For IP addresses, enter one IP address or IP address range per line that you want to allow in CIDR notation.Note: AWS WAF supports all IPv4 and IPv6 CIDR ranges except for /0.Examples:To specify the IPv4 address 192.168.0.26, enter 192.168.0.26/32.To specify the IPv6 address 0:0:0:0:0:ffff:c000:22c, enter 0:0:0:0:0:ffff:c000:22c/128.To specify the range of IPv4 addresses from 192.168.20.0 to 192.168.20.255, enter 192.168.20.0/24.To specify the range of IPv6 addresses from 2620:0:2d0:200:0:0:0:0 to 2620:0:2d0:200:ffff:ffff:ffff:ffff, enter 2620:0:2d0:200::/64.Review the settings for the IP set. If it matches your specifications, choose Create IP set.Then, change rule actions to count in a rule group.In the web ACL page Rules tab, select the AWS Managed rule group blocking your request, and then choose Edit.In the Rules section for the rule group, do one of the following:For AWSManagedIPReputationList, turn on Count.For AnonymousIPList Rule, turn on Count.Choose Save rule.Finally, create a rule with higher numeric priority than the specific AWS Managed Rule blocking the request.In the navigation pane, under AWS WAF, choose Web ACLs.For Region, choose the AWS Region where you created your web ACL.  Note: Select Global if your web ACL is set up for Amazon CloudFront.Select your web ACL.Choose Rules.Choose Add Rules, and then choose Add my own rules and rule groups.For Name, enter a rule name, and then choose Regular Rule.For If a request, choose matches all the statements (AND).On Statement 1:For Inspect, choose Has a label.For Match scope, choose Label.For Match key, select either awswaf:managed:aws:amazon-ip-list:AWSManagedIPReputationList or  awswaf:managed:aws:anonymous-ip-list:AnonymousIPList based on that Managed Rule that was blocking your requestOn Statement 2:For Negate statement (NOT), choose Negate statement results.For Inspect, choose Originates from IP address in.For IP set, choose the IP set you created earlier.For IP address to use as the originating address, choose Source IP address.For Action, choose Block.Choose Add Rule.For Set rule priority, move the rule below the AWS Managed Rule that was blocking the request.Choose Save.Important: It’s a best practice to test rules in a non-production environment with the Action set to Count. Evaluate the rule using Amazon CloudWatch metrics combined with AWS WAF sampled requests or AWS WAF logs. When you're satisfied that the rule does what you want, change the Action to Block.Related informationHow can I detect false positives caused by AWS Managed Rules and add them to a safe list?Follow"


Question: "I'm running the sync command to transfer data between my EC2 instance and my S3 bucket, but the transfer is slow. How can I troubleshoot this?"

"I'm running the sync command to transfer data between my Amazon Elastic Compute Cloud (Amazon EC2) instance and my Amazon Simple Storage Service (Amazon S3) bucket. However, the transfer is slow. How can I troubleshoot this?"

Answer: "I'm running the sync command to transfer data between my Amazon Elastic Compute Cloud (Amazon EC2) instance and my Amazon Simple Storage Service (Amazon S3) bucket. However, the transfer is slow. How can I troubleshoot this?Short descriptionThesync command on the AWS Command Line Interface (AWS CLI) is a high-level command that includes the ListObjectsV2, HeadObject, GetObject, and PutObject API calls.To identify what might be contributing to the slow transfer:Review the architecture of your use case.Check the network connectivity.Test the speed of uploading to and downloading from Amazon S3.Review the network and resource load while sync runs as a background process.ResolutionReview the architecture of your use caseBefore you test the network connectivity, transfer speeds, and resource loads, consider the following architecture factors that can influence transfer speed:Which Amazon EC2 instance type are you using? For this transfer use case, it's a best practice to use an instance that has a minimum of 10 Gbps throughput.Are the EC2 instance and the S3 bucket in the same AWS Region? It's a best practice to deploy the instance and the bucket in the same Region. It's also a best practice to attach a VPC endpoint for Amazon S3 to the VPC where your instance is deployed.For instances and buckets that are in the same Region, is the AWS CLI configured to use the Amazon S3 Transfer Acceleration endpoint? It's a best practice to not use the Transfer Acceleration endpoint if the resources are in the same Region.What's the nature of the source data set that you want to transfer? For example, are you transferring a lot of small files or a few large files to Amazon S3? For more information about using the AWS CLI to transfer different source data sets to Amazon S3, see Getting the most out of the Amazon S3 CLI.What version of the AWS CLI are you using? Make sure that you’re using the most recent version of the AWS CLI.What's your configuration of the AWS CLI?If you're still experiencing slow transfers after following best practices, then check the network connectivity, transfer speeds, and resource loads.Check the network connectivityRun the dig command on the S3 bucket and review the query response time returned in the Query time field. In the following example, the Query time is 0 msec:Bash$ dig +nocomments +stats +nocmd awsexamplebucket.s3.amazonaws.com;awsexamplebucket.s3.amazonaws.com. INAawsexamplebucket.s3.amazonaws.com. 2400 IN CNAMEs3-3-w.amazonaws.com.s3-3-w.amazonaws.com.2INA52.218.24.66;; Query time: 0 msec;; SERVER: 172.31.0.2#53(172.31.0.2);; WHEN: Fri Dec 06 09:30:47 UTC 2019;; MSG SIZE  rcvd: 87Longer response times for the Domain Name System (DNS) resolution queries to return an IP address can impact performance. If you get a longer query response time, then try changing the DNS servers for your instance.As another network connectivity test, run traceroute or mtr using TCP to the virtual style hostname and the S3 Regional endpoint for your bucket. The request in the following mtr example is routed through a VPC endpoint for Amazon S3 that's attached to the instance's VPC:Bash$ mtr -r --tcp --aslookup  --port 443 -c50  awsexamplebucket.s3.eu-west-1.amazonaws.comStart: 2019-12-06T10:03:30+0000HOST: ip-172-31-4-38.eu-west-1.co Loss%   Snt   Last   Avg  Best  Wrst StDev  1. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  2. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  3. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  4. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  5. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  6. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0  7. AS16509  s3-eu-west-1-r-w.am 62.0%    50    0.3   0.2   0.2   0.4   0.0Test the speed of uploading to and downloading from Amazon S31.    Create five test files that contain 2 GB of content:Bash$ seq -w 1 5 | xargs -n1 -P 5 -I % dd if=/dev/urandom of=bigfile.% bs=1024k count=2048$ ls -ltotal 10244-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.1-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.2-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.3-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.4-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.52.    Run the sync command using the AWS CLI to upload the five test files. To get the transfer time, insert the time command (from Linux documentation) at the beginning of the sync command:Note: Be sure to also note the throughput speed while the sync command is in progress.Bash $ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1Completed 8.0 GiB/10.2 GiB (87.8MiB/s) with 3 file(s) remainingreal 2m14.402suser 2m6.254ssys 2m22.314sYou can use these test results as a baseline to compare to the time of the actual sync for your use case.Review the network and resource load while sync runs as a background process1.    Append & to the end of the sync command to run the command in the background:Note: You can also append a stream operator (>) to write output to a text file that you can review later.Bash$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1 \> ~/upload.log &[1] 4262$2.    While the sync command runs in the background, run the mpstat command (from Linux documentation) to check CPU usage. The following example shows that 4 CPUs are being used and they are utilized around 20%:Bash $ mpstat -P ALL 10Average:     CPU    %usr   %nice    %sys   %iowait   %irq   %soft  %steal  %guest  %gnice  %idleAverage:     all   21.21    0.00   23.12    0.00    0.00    2.91    0.00    0.00    0.00   52.77Average:       0   21.82    0.00   21.71    0.00    0.00    3.52    0.00    0.00    0.00   52.95Average:       1   21.32    0.00   23.76    0.00    0.00    2.66    0.00    0.00    0.00   52.26Average:       2   20.73    0.00   22.76    0.00    0.00    2.64    0.00    0.00    0.00   53.88Average:       3   21.03    0.00   24.07    0.00    0.00    2.87    0.00    0.00    0.00   52.03In this case, the CPU isn't the bottleneck. If you see utilization percentages that are equal to or greater than 90%, then try launching an instance that has additional CPUs. You can also run the top command to review the highest CPU utilization percentages that are running. Try to stop those processes first, and then run the sync command again.3.    While the sync command runs in the background, run the lsof command (from Linux documentation). This checks how many TCP connections are open to Amazon S3 on port 443:Note: If max_concurrent_requests is set to 20 for the user profile in the AWS CLI config file, then expect to see a maximum of 20 established TCP connections.Bash$ lsof -i tcp:443COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAMEaws     4311 ec2-user    3u  IPv4  44652      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:33156->52.218.36.91:https (CLOSE_WAIT)aws     4311 ec2-user    4u  IPv4  44654      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39240->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user    5u  IPv4  44655      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39242->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user    6u  IPv4  47528      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39244->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user    7u  IPv4  44656      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39246->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user    8u  IPv4  45671      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39248->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   13u  IPv4  46367      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39254->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   14u  IPv4  44657      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39252->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   15u  IPv4  45673      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39250->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   32u  IPv4  47530      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39258->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   33u  IPv4  45676      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39256->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   34u  IPv4  44660      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39266->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   35u  IPv4  45678      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39260->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   36u  IPv4  45679      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39262->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   37u  IPv4  45680      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39268->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   38u  IPv4  45681      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39264->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   39u  IPv4  45683      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39272->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   40u  IPv4  47533      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39270->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   41u  IPv4  44662      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39276->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   42u  IPv4  44661      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39274->52.216.162.179:https (ESTABLISHED)aws     4311 ec2-user   43u  IPv4  44663      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39278->52.216.162.179:https (ESTABLISHED)If you see other TCP connections on port 443, then try stopping those connections before running the sync command again.To get a count of the TCP connections, run this command:$ lsof -i tcp:443 | tail -n +2 | wc -l214.    After the single sync process is optimized, you can run multiple sync processes in parallel. This avoids single-process slower uploads when high network bandwidth is available, but only half of the network bandwidth is being utilized. When you run parallel sync processes, target different prefixes to get the desired throughput.For more information, see How can I optimize performance when I upload large amounts of data to Amazon S3?Follow"


Question: How do I publish MQTT messages to AWS IoT Core from my device when using Python?

I can't send or receive MQTT (MQ Telemetry Transport) messages between AWS IoT Core and my device or MQTT client. How do I publish MQTT messages to AWS IoT Core?


Question: When will my AWS bill be ready?

I want to know when I'll receive my AWS bill.

Answer: "I want to know when I'll receive my AWS bill.ResolutionYour AWS bill for the previous month is finalized at the beginning of each new month. Shortly after, the bill is charged to your default payment method, usually between the third and the fifth day of the month.Note: The billing cycle is based in the UTC (+00:00) time zone.If you use the AWS Cost and Usage Report, then check the bill/InvoiceID column. This column is blank until your bill is finalized.Related informationWhat payment methods does AWS accept?Can I use more than one payment method to pay my AWS charges?How do I view past or current AWS payments?Follow"


Question: Why isn’t my Amazon SNS topic receiving Amazon S3 event notifications?

"I created an Amazon Simple Storage Service (Amazon S3) event notification to send messages through my Amazon Simple Notification Service (Amazon SNS) topic. My Amazon SNS topic isn't publishing messages when new events occur in my Amazon S3 bucket, though."

Answer: "I created an Amazon Simple Storage Service (Amazon S3) event notification to send messages through my Amazon Simple Notification Service (Amazon SNS) topic. My Amazon SNS topic isn't publishing messages when new events occur in my Amazon S3 bucket, though.ResolutionConfirm that your Amazon S3 event type is configured correctlyWhen you configure an Amazon S3 event notification, you must specify which supported Amazon S3 event types cause Amazon S3 to send the notification. If an event type that you didn't specify occurs in your Amazon S3 bucket, then Amazon S3 doesn't send the notification.Confirm that your object key name filters are in URL-encoded (percent-encoded) formatIf your event notifications are configured to use object key name filtering, then notifications are published only for objects with specific prefixes or suffixes.If you use any special characters in your prefixes or suffixes, then you must enter them in URL-encoded (percent-encoded) format. For more information see Object key naming guidelines and Working with object metadata.Note: A wildcard character ("*") can't be used in filters as a prefix or suffix to represent any character.Confirm that you've granted Amazon S3 the required permissions to publish messages to your topicYour Amazon SNS topic's resource-based policy must allow the Amazon S3 bucket to publish messages to the topic.Check your topic's AWS Identity and Access Management (IAM) policy to confirm that it has the required permissions, and add them if needed. For more information, see Granting permissions to publish messages to an SNS topic or an SQS queue.(For topics with server-side encryption (SSE) activated) Confirm that your topic has the required AWS Key Management (AWS KMS) permissionsYour Amazon SNS topic must use an AWS KMS key that is customer managed. This KMS key must include a custom key policy that gives Amazon S3 sufficient key usage permissions.To set up the required AWS KMS permissions, complete the following steps:1.    Create a new KMS key that is customer managed and includes the required permissions for Amazon S3.2.    Configure SSE for your Amazon SNS topic using the custom KMS key you just created.3.    Configure AWS KMS permissions that allow Amazon S3 to publish messages to your encrypted topic.Example IAM policy statement that allows Amazon S3 to publish messages to an encrypted Amazon SNS topic{"version": "2012-10-17","statement": [{    "effect": "allow",    "principal": {"service": "s3.amazonaws.com"},    "action": ["kms:generatedatakey*", "kms:decrypt"],    "resource": "*"}]}If the Amazon S3 event notification still isn't received on the SNS topic, then check the Amazon SNS CloudWatch metric NumberOfMessagePublished. This metric shows whether Amazon S3 is publishing the events. If the metric doesn't populate, then there's an issue with the Amazon S3 to Amazon SNS configuration.If the NumberOfMessagePublished metric is populated, then check the NumberOfNotificationsDelivered and NumberOfNotificationsFailed metrics. These metrics show whether the messages are successfully delivered to subscribing endpoints from your Amazon SNS topic.Amazon SNS provides support to log the delivery status of notification messages sent to topics with Amazon SNS endpoints. This includes HTTP, Amazon Kinesis Data Firehose, AWS Lambda, Platform application endpoint, Amazon Simple Queue Service, and AWS SMS. Turn on Amazon SNS topic Delivery status logs to further troubleshoot the issue.Related informationAllow Amazon S3 event notifications to publish to a topicFollow"


Question: Why is my EC2 Windows instance down with an instance status check failure?

How to troubleshoot your Amazon Elastic Compute Cloud (Amazon EC2) Windows instance going down due to an instance status check failure.

Answer: "How to troubleshoot your Amazon Elastic Compute Cloud (Amazon EC2) Windows instance going down due to an instance status check failure.Short descriptionAmazon Web Services (AWS) monitors the health of each EC2 instance with two status checks. An EC2 instance becomes unreachable if a status check fails.An instance status check failure indicates a problem with the instance, such as:Networking or startup configuration issuesExhausted memoryFile system issuesFailure to boot the operating systemFailure to mount volumes correctlyIncompatible driversCPU exhaustionIf both the instance and system status checks fail, then see Why is my EC2 Windows instance down with a system status check failure or status check 0/2?ResolutionDue to instance status checks likely being caused by issues within the guest operating system, focus your troubleshooting on reviewing the following:Console outputSystem logsOperating system or application error messagesFor more information, see Troubleshooting EC2 Windows instances.Tip: You can also use EC2Rescue for Windows Server to diagnose and troubleshoot issues.Related informationTroubleshoot an unreachable instanceTroubleshooting connecting to your Windows instanceWhy is my EC2 Linux instance unreachable and failing one or both of its status checks?How do I diagnose high CPU utilization on my EC2 Windows instance when my CPU is not being throttled?Follow"


Question: How can I troubleshoot local storage issues in Aurora PostgreSQL-Compatible instances?

I am experiencing issues with local storage in my Amazon Aurora PostgreSQL-Compatible Edition DB instances.

Answer: "I am experiencing issues with local storage in my Amazon Aurora PostgreSQL-Compatible Edition DB instances.Short descriptionDB instances that are in Amazon Aurora clusters have two types of storage:Storage used for persistent data (shared cluster volume). For more information, see What the cluster volume contains.Local storage for each Aurora instance in the cluster, based on the instance class. This storage size is bound to the instance class and can be changed only by moving to a larger DB instance class. Aurora PostgreSQL-Compatible uses local storage for storing error logs and temporary files. For more information, see Temporary storage limits for Aurora PostgreSQL.ResolutionYou can monitor the local storage space that's associated with the Aurora DB instance or node by using the Amazon CloudWatch metric for FreeLocalStorage. This metric reports the amount of storage available to each DB instance for temporary tables and logs. For more information, see Monitoring Amazon Aurora metrics with Amazon CloudWatch.If your Aurora local storage is full, then use these troubleshooting steps depending on the error you receive.Local storage space is used by temporary tables or files"ERROR: could not write block XXXXXXXX of temporary file: No space left on device."This error occurs when temporary storage is exhausted on the DB instance. This can have a number of causes, including operations that:Alter large tablesAdd indexes on large tablesPerform large SELECT queries with complex JOINs, GROUP BY, or ORDER BY clauses.Use these methods to check temporary tables and temporary files size:1.    For temporary files, turn on the log_temp_files parameter on the Aurora PostgreSQL-Compatible DB instance. This parameter logs the use of temporary files that are larger than the number of specified kilobytes. After this parameter is turned on, a log entry is made for each temporary file when the file is deleted. A value of 0 logs all temporary file information. A positive value logs only the files that are larger than or equal to the specified number of kilobytes. The default value is -1, which turns off temporary file logging. Use this parameter to identify the temporary file details, and then relate these temporary files with the FreeLocalStorage metric.Note: Turning on the log_temp_files parameter can cause excessive logging on the Aurora PostgreSQL-Compatible DB instance. For this reason, it's a best practice to check the size of the Aurora PostgreSQL-Compatible log files before turning on log_temp_files. If log files are consuming the maximum space for the local storage, then reduce the value of rds.log_retention to reclaim space. The default value for rds.log_retention is three days.You can also review temporary files by using the delta of subsequent runs of this command:maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size  FROM   pg_stat_database order by temp_bytes desc;Note: In the temp_files column, all temporary files are counted—regardless of when you created the temporary file (for example, by sorting or hashing). The columns temp_files and temp_bytes in view pg_stat_database are collecting statistics for the accumulated value. This value can be reset by using the pg_stat_reset() function or by restarting the DB instance. For more information, see the PostgreSQL documentation for Additional statistics functions.If you use Aurora PostgreSQL-Compatible 10 or later, you can monitor temp_bytes and temp_files by using Performance Insights. This also applies to Amazon Relational Database Service (Amazon RDS) for PostgreSQL. Performance Insights provide native counters for your DB engine's internal metrics, in addition to wait events. For more information, see Native counters for Amazon RDS for PostgreSQL.You can also increase maintenance_work_mem and work_mem to allocate more memory to the processes that are performing the operation. This uses more memory for the operation, which can use less temporary disk storage. For more information about these parameters, see the PostgreSQL documentation for maintenance_work_mem and work_mem. It's a best practice to set the values for maintenance_work_mem and work_mem at a query or session level to avoid running out of memory. For more information, see Amazon Aurora PostgreSQL reference.2.    For temporary tables, run a query like this:maxiops=> SELECTn.nspname as SchemaName,c.relname as RelationName,CASE c.relkindWHEN 'r' THEN 'table'WHEN 'v' THEN 'view'WHEN 'i' THEN 'index'WHEN 'S' THEN 'sequence'WHEN 's' THEN 'special'END as RelationType,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSizeFROM pg_catalog.pg_class cLEFT JOIN pg_catalog.pg_namespace n    ON n.oid = c.relnamespaceWHERE  c.relkind IN ('r','s')AND  (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;It's a best practice to closely monitor your application and see which transactions create temporary tables. By doing so, you can manage the usage of the available local storage capacity. You can also move to a higher instance class for your Aurora instance so that the instance has more available local storage.Local storage used by log filesExcessive logging can also cause your DB instance to run out of local storage. These are some examples of logging parameters that can consume the local storage space. The consumption could be due to either excessive logging or retaining the error log for a long time.rds.log_retention_periodauto_explain.log_min_durationlog_connectionslog_disconnectionslog_lock_waitslog_min_duration_statementlog_statementlog_statement_statsTo identify which parameter is causing excessive logging, analyze the PostgreSQL logs to find the largest logs. Then, identify which parameter is responsible for the majority of the entries in those logs. You can then modify the parameter that is causing the excessive logging.If you're repeatedly running a query that's failing with an error, then PostgreSQL logs the errors to the PostgreSQL error log by default. Review the errors logged, and then fix the failing query to prevent logs from using excessive storage. You can also reduce the default value for rds.log_retention (three days) to reclaim space used by the error logs.If excessive logging is required and you are throttling with available local storage because of log files, consider moving to a higher instance class. This means that your Aurora DB instance has more available local storage.Related informationBest practices with Amazon Aurora PostgreSQLFollow"


Question: How do I retrieve my Windows administrator password after launching an instance?

"I launched an Amazon Elastic Compute Cloud (Amazon EC2) instance, and now I need to retrieve my Windows administrator password."

Answer: "I launched an Amazon Elastic Compute Cloud (Amazon EC2) instance, and now I need to retrieve my Windows administrator password.ResolutionRetrieve your initial administrator password with the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).Retrieve your initial administrator password using the Amazon EC2 consoleNote: This method requires an Amazon EC2 key pair.If you lost your key pair, then see How can I reset the administrator password on an EC2 Windows instance?If you need an Amazon EC2 key pair, then see Create a key pair using Amazon EC2.Follow these steps:1.    Open the Amazon EC2 console, and then choose Instances.2.    Select the check box for the instance, and then expand the Actions dropdown list. For the old console, choose Get Windows Password. For the new console, choose Security, and then choose Get Windows Password.Note: When you first launch a new instance, this option might not be available for a few minutes.3.    Choose Browse, select your key pair file, and then choose Open.-or-Paste the contents of your key pair into the text box.4.    Choose Decrypt Password.Retrieve your initial administrator password using the AWS CLINote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Use the get-password-data command. For example syntax, see Examples.Related informationGetting started with Amazon EC2 Windows instancesConnect to your Windows instanceFollow"


Question: Why can't I drop a user or role in my RDS for PostgreSQL DB instance?

"When I try to drop a user or role in my Amazon Relational Database Service (Amazon RDS) for PostgreSQL instance, I get the error "role cannot be dropped because some objects depend on it"."

Answer: "When I try to drop a user or role in my Amazon Relational Database Service (Amazon RDS) for PostgreSQL instance, I get the error "role cannot be dropped because some objects depend on it".Short descriptionWhen a user or role in RDS for PostgreSQL creates an object, such as a table or schema, the user or role is the owner of the object created. If you try to drop a user or role that owns one or more objects in any database or has privileges on these objects, then you receive an error indicating that there are objects that depend on the user or role along with granted permissions, if there are any.To drop a user or role that has dependent objects, you must do the following:Reassign the ownership of these objects to another user.Revoke any permissions that were granted to the user or role.Note: If these objects are no longer needed, consider dropping these objects and then deleting the role. You can drop all objects that are owned by a role in a database using the DROP OWNED command. You can also revoke any privileges granted to the role on objects in that database or shared objects. After the DROP OWNED command runs successfully, you can drop the role.ResolutionIn the following example, three different database roles are used:test_user: This is the user or role that must be dropped.admin_user: This is the role that's used to drop the required user or role. This user is the highest privileged user in RDS with the rds_superuser role attached to it.another_user: This is the user or role that's assigned ownership of objects owned by test_user.Run the following command to see the role with which you logged in:pg_example=> SELECT current_user;The output looks similar to the following:current_user-------------- admin_user(1 row)When you try to drop a user or role with dependent objects, you get an error similar to the following:pg_example=> DROP ROLE test_user;ERROR:  role "test_user" cannot be dropped because some objects depend on itDETAIL:  privileges for database pg_exampleowner of table test_tableowner of schema test_schemaowner of sequence test_schema.test_seqprivileges for table test_t2In this example, the role being dropped is test_user. Note that the role that's currently logged in is admin_user, which is the master user of the database.From the error message, you get the following information:The role test_user has privileges granted on the database pg_example and table test_t2.The role test_user owns the table test_table, schema test_schema, and a sequence object test_seq in test_schema.Note: if you drop a user or role when you're connected to a different database, then you get an output similar to the following:pg_another_db=> DROP ROLE test_user;ERROR:  role "test_user" cannot be dropped because some objects depend on itDETAIL:  privileges for database pg_example4 objects in database pg_exampleTo see objects that are owned by a user or role, be sure to connect to the database where the owned objects are located.To drop the user or role, you must reassign the ownership of the owned objects to another user or role and revoke associated permissions. You can use the PostgreSQL REASSIGN OWNED command to reassign the ownership of these objects to another user. When running this command, you might get an error similar to the following:pg_example=> select current_user; current_user-------------- test_userpg_example=> REASSIGN OWNED BY test_user TO another_user;ERROR:  permission denied to reassign objectsTo resolve this issue, you must grant the user or role to the user that's reassigning ownership. You can't use test_user to do so because test_user isn't the owner of another_user. Therefore, you might see an error similar to the following:pg_example=> select current_user; current_user-------------- test_userpg_example=> grant another_user to test_user;ERROR:  must have admin option on role "another_user"You can do either of the following to grant the user or role to the user that's reassigning ownership:Sign in to your master user and run the GRANT command:pg_example=> select current_user; current_user-------------- admin_userpg_example=> GRANT another_user TO test_user;GRANT ROLESign in to the user that will reassign ownership and run the GRANT command:pg_example=> select current_user; current_user-------------- another_userpg_example=> GRANT another_user TO test_user;GRANT ROLEAfter choosing one of the preceding options, reassign the ownership of objects owned by test_user to another_user after logging in to test_user:pg_example=> select current_user; current_user-------------- test_userpg_example=> reassign owned by test_user to another_user;REASSIGN OWNEDIf you sign in to your master user and attempt to drop test_user that still has existing privileges, then you might error similar to the following:pg_example=> select current_user; current_user-------------- admin_userpg_example=> DROP ROLE test_user;ERROR:  role "test_user" cannot be dropped because some objects depend on itDETAIL:  privileges for database pg_exampleprivileges for table test_t2In this case, you get an error even though the REASSIGN command is successful. This is because, the privileges of test_user must be revoked. Run the REVOKE command to revoke all usage permissions from any object on which test_user has privileges. In this example, revoke the permissions on the database pg_example and table test_t2 for test_user.pg_example=> REVOKE ALL ON TABLE test_t2 FROM test_user;REVOKEpg_example=> REVOKE ALL ON DATABASE pg_example FROM test_user;REVOKEThen, drop the user test_user:pg_example=> DROP ROLE test_user;DROP ROLEAfter revoking the privileges, you can successfully drop the role.Related informationPostgreSQL documentation for DROP ROLEFollow"


Question: How do I truncate the sys.aud$ table on my Amazon RDS DB instance that is running Oracle?

How do I truncate the sys.aud$ table on my Amazon Relational Database Service (Amazon RDS) DB instance that is running Oracle?

Answer: "How do I truncate the sys.aud$ table on my Amazon Relational Database Service (Amazon RDS) DB instance that is running Oracle?ResolutionTo truncate thesys.aud$ table, run the following command as the master user:SQL> exec rdsadmin.rdsadmin_master_util.truncate_sys_aud_table;If the procedure is successful, you receive output similar to the following:PL/SQL procedure successfully completed.SQL> select count(*) from sys.aud$; COUNT(*)----------         0Note: Truncating the table requires that your RDS DB instance can run the TRUNCATE_SYS_AUD_TABLE procedure as a master user. Oracle versions 12.1.0.2.v2 and 11.2.0.4.v6, as well as subsequent versions, support this operation.If the preceding command is unsuccessful, contact AWS Support for assistance. To determine what kind of assistance AWS Support needs to provide, run the following commands and then note their output:1.    Run the following command to determine if the TRUNCATE_SYS_AUD_TABLE procedure is available on your RDS DB instance:SQL> desc rdsadmin.rdsadmin_master_utilIf your RDS DB instance has theTRUNCATE_SYS_AUD_TABLE procedure, then you receive output similar to the following:FUNCTION IS_DML_ENABLED RETURNS BOOLEANPROCEDURE TRUNCATE_SYS_AUD_TABLEPROCEDURE TRUNCATE_SYS_FGA_LOG_TABLE2.    Run the following command to determine if theRDS_MASTER_ROLE role is available on your RDS DB instance:SQL> select role from dba_roles where role='RDS_MASTER_ROLE';If the RDS_MASTER_ROLE role is available on your RDS DB instance, then you receive output similar to the following:ROLE--------------------------------------------RDS_MASTER_ROLE3.    Run the following command to verify that the master user has permissions to run the TRUNCATE_SYS_AUD_TABLE procedure:SQL> select granted_role, grantee, admin_option from dba_role_privs where granted_role='RDS_MASTER_ROLE';If the master user has permissions to run the TRUNCATE_SYS_AUD_TABLE procedure, then you receive output similar to the following:GRANTED_ROLE         GRANTEE              ADM-------------------- -------------------- ---RDS_MASTER_ROLE      SYS                  YESRDS_MASTER_ROLE      MASTER_USER          NORelated informationOracle on Amazon RDSCommon DBA tasks for Oracle DB instancesFollow"


Question: What happens when I make a configuration change to my Amazon OpenSearch Service cluster?

I'm trying to minimize the downtime during a configuration change. What happens if I make a configuration change to my Amazon OpenSearch Service cluster?

Answer: "I'm trying to minimize the downtime during a configuration change. What happens if I make a configuration change to my Amazon OpenSearch Service cluster?ResolutionWhen you change your OpenSearch Service cluster configuration, a blue/green deployment can be triggered. During a blue/green deployment, a cluster state changes to "Processing" while a new OpenSearch Service domain is being created. When your new domain is created, the following occurs:The total number of nodes are doubled. Or, the total number of nodes is equal to the node count in the old and new domain.The number of nodes are doubled until the old domain nodes are terminated.If a shard allocation is finally in progress, the cluster state returns to "Active".Note: During blue/green deployment, you might observe some latency. To avoid any latency issues, it's a best practice to run blue/green deployment when the cluster is healthy and there is low network traffic.Configuration change durationYour configuration change can take longer depending on the cluster size, workload, shard size, and shard count. Use the cat recovery command to monitor the status of your shard relocation.To see which shards are still relocating, use the following command syntax:curl -X GET "cluster_endpoint/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | grep -v 100\.0\%To list the shard relocation by byte percentages, use the following command syntax:curl -X GET "https://<end_point>/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | tr -d "%" | sort -k 5 -nNote: To sort the data by byte percentage (which is in the fifth column), you must specify "5" for -k.If you observe minimal progress for the shard relocation, your cluster might be stuck.Reasons your blue/green deployment process is stuckYour blue/green deployment process might get stuck for the following reasons:An unhealthy cluster state from before the configuration change.Consistently high JVM memory pressure. Aim to keep your JVM memory pressure below 75% to avoid out of memory (OOM) issues.Consistently high CPU utilization. Aim to keep your CPU utilization below 80%.Too many shards on a cluster or incorrect shard sizing. It's a best practice to keep your shard count between 10 GiB and 50 GiB. For more information about indexing strategy, see Choosing the number of shards.Invalid configuration setup or too many configuration changes at the same time. Make sure to verify your configuration settings and wait to send a configuration change until the first configuration change completes.Insufficient disk space or capacity for the relocation process or requested instance type.Lack of available IPs on the requested subnet for a cluster inside a virtual private cloud (VPC).Using volume size for the instance type. Your volume size must be within the limit range.Using index settings like "index.routing.allocation.require._name" or "NODE_NAME" or "index.blocks.write": true". These settings indicate a write block. Make sure to remove these settings from your index settings before you proceed.For more information, see Why is my OpenSearch Service domain stuck in the "Processing" state?Related informationWhy is my Amazon OpenSearch Service domain upgrade taking so long?Follow"


Question: How do I resolve the "Courier fetch: n of m shards failed" error in OpenSearch Dashboards on Amazon OpenSearch Service?

"When I try to load a dashboard in OpenSearch Dashboards on my Amazon OpenSearch Service domain, it returns a Courier fetch error. How do I resolve this?"

Answer: "When I try to load a dashboard in OpenSearch Dashboards on my Amazon OpenSearch Service domain, it returns a Courier fetch error. How do I resolve this?Short descriptionWhen you load a dashboard in OpenSearch Dashboards, a search request is sent to the OpenSearch Service domain. The search request is routed to a cluster node that acts as thecoordinating node for the request. The"Courier fetch: n of m shards failed" error occurs when the coordinating node fails to complete thefetch phase of the search request. There are two types of issues that commonly cause this error:Persistent issues: Mapping conflicts or unassigned shards. If you have several indices in your index pattern using the same name but different mapping types, you might get a Courier fetch error. If your cluster is in red cluster status, it means that at least one shard is unassigned. Because OpenSearch Service can't fetch documents from unassigned shards, a cluster in red status throws a Courier fetch error. If the value of "n" in the Courier fetch error message is the same each time you receive the error, then it is likely a persistent issue. Check the application error logs for troubleshooting suggestions.Note: Persistent issues can't be resolved by retrying or provisioning more cluster resources.Transient issues: Transient issues include rejections of thread pools, search timeouts, and tripped field data circuit breakers. These issues occur when you don't have enough compute resources on the cluster. A transient issue is likely the cause when you receive the error message intermittently with a different value of "n" each time. You can also monitor Amazon CloudWatch metrics such as CPUUtilization, JVMMemoryPressure, and ThreadpoolSearchRejected to determine if a transient issue is causing the Courier fetch error.ResolutionEnable application error logs for the domain. The logs can help you identify the root cause and solution for both transient and persistent issues. For more information, see Viewing OpenSearch Service error logs.Persistent issuesThe following example shows a log entry for a Courier fetch error caused by a persistent issue:[2019-07-01T12:54:02,791][DEBUG][o.e.a.s.TransportSearchAction] [ip-xx-xx-xx-xxx] [1909731] Failed to execute fetch phaseorg.elasticsearch.transport.RemoteTransportException: [ip-xx-xx-xx-xx][xx.xx.xx.xx:9300][indices:data/read/search[phase/fetch/id]]Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default. Set fielddata=true on [request_departure_date] in order to load fielddata in memory by uninverting the inverted index.Note that this can however use significant memory. Alternatively use a keyword field instead.In this example, the issue is caused by the request_departure_date field. The log entry shows that you can resolve this issue by setting fielddata=true in the index settings or by using a keyword field.Transient issuesMost transient issues can be resolved by either provisioning more compute resources or reducing the resource utilization for your queries.Provisioning more compute resourcesScale up your domain by switching to a larger instance type, or scale out by adding more nodes to the cluster. For more information, see Creating and managing OpenSearch Service domains.Confirm that you're using an instance type that is appropriate for your use case. For more information, see Choosing instance types and testing.Reducing the resource utilization for your queriesConfirm that you're following best practices for shard and cluster architecture. A poorly designed cluster can't use all available resources. Some nodes might get overloaded while other nodes sit idle. OpenSearch Service can't fetch documents from overloaded nodes.You can also reduce the scope of your query. For example, if you query on time frame, reduce the date range or filter the results by configuring the index pattern in Kibana.Avoid running select * queries on large indices. Instead, use filters to query a part of the index and search as few fields as possible. For more information, see Tune for search speed and Query and filter context on the Elasticsearch website.Reindex and reduce the number of shards. The more shards you have in your cluster, the more likely you are to get a Courier fetch error. Because each shard has its own resource allocation and overheads, a large number of shards places excessive strain on your cluster. For more information, see Why is my OpenSearch Service domain stuck in the "Processing" state?The following example shows a log entry for a Courier fetch error caused by a transient issue:Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@26fdeb6f on QueueResizingEsThreadPoolExecutor[name = __PATH__ queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 2.9ms, adjustment amount = 50,org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@1968ac53[Running, pool size = 2, active threads = 2, queued tasks = 1015, completed tasks = 96587627]]In this example, the issue is caused by search threadpool queue rejections. To resolve this issue, scale up your domain by choosing a larger instance type. For more information, see Thread pools on the Elasticsearch website.Related informationBest practices for Amazon OpenSearch ServiceTroubleshooting Amazon OpenSearch ServiceFollow"


Question: How can I disable public access for an AWS DMS replication DB instance?

How can I disable public access for an AWS Database Migration Service (AWS DMS) replication instance?

Answer: "How can I disable public access for an AWS Database Migration Service (AWS DMS) replication instance?Short descriptionAn AWS DMS replication instance can have one public IP address and one private IP address, just like an Amazon Elastic Compute Cloud (Amazon EC2) instance that has a public IP address.To use a public IP address, choose the Publicly accessible option when you create your replication instance. Or specify the --publicly-accessible option when you create the replication instance using the AWS Command Line Interface (AWS CLI).If you uncheck (disable) the box for Publicly accessible, then the replication instance has only a private IP address. As a result, the replication instance can communicate with a host that is in the same Amazon Virtual Private Cloud (Amazon VPC) and that can communicate with the private IP address. Or the replication instance can communicate with a host that is connected privately, for example, by VPN, VPC peering, or AWS Direct Connect.After you create the replication instance, you can't modify the Publicly accessible option.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.To disable public access to your replication instance, delete the replication instance and then recreate it. Before you can delete a replication instance, you must delete all the tasks that use the replication instance.Instead of recreating the replication instance, you can change the subnets that are in the subnet group that is associated with the replication instance to private subnets. A private subnet is a subnet that isn't routed to an internet gateway. Instances in a private subnet can't communicate with a public IP address, even if they have a public IP address. For more information, see Setting up a network for a replication instance.Related informationWorking with an AWS DMS replication instanceFollow"


Question: How can I automatically discover the subnets used by my Application Load Balancer in Amazon EKS?

I want to automatically discover the subnets used by my Application Load Balancer (ALB) in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to automatically discover the subnets used by my Application Load Balancer (ALB) in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionYou can tag your AWS subnets to allow the AWS Load Balancer controller to auto discover subnets used for Application Load Balancers.Resolution1.    Deploy the AWS Load Balancer Controller for your Amazon EKS cluster.2.    Verify that the AWS Load Balancer Controller is installed:kubectl get deployment -n kube-system aws-load-balancer-controllerNote: If the Deployment is deployed in a different namespace, then replace -n kube-system with the appropriate namespace.3.    Create a Kubernetes Ingress resource on your cluster with the following annotation:annotations:    kubernetes.io/ingress.class: albNote: The AWS Load Balancer Controller creates load balancers. The Ingress resource configures the Application Load Balancer to route HTTP(S) traffic to different pods within your cluster.4.    Add either an internal or internet-facing annotation to specify where you want the Ingress to create your load balancer:alb.ingress.kubernetes.io/scheme: internal-or-alb.ingress.kubernetes.io/scheme: internet-facingNote: Choose internal to create an internal load balancer, or internet-facing to create a public load balancer.5.    Use tags to allow the Application Load Balancer Ingress Controller to create a load balancer using auto-discovery. For example:kubernetes.io/role/internal-elb                Set to 1 or empty tag value for internal load balancerskubernetes.io/role/elb                         Set to 1 or empty tag value for internet-facing load balancersNote: You can use tags for auto-discovery instead of the manual alb.ingress.kubernetes.io/subnets annotation.Example of a subnet with the correct tags for a cluster with an internal load balancer:kubernetes.io/role/internal-elb          1Example of a subnet with the correct tags for a cluster with a public load balancer:kubernetes.io/role/elb                     1Note: For cluster versions 1.18 and earlier, Amazon EKS adds the following tag to all subnets passed in during cluster creation. The tag isn't added to version 1.19 clusters. If you're using the tag and you update to cluster version 1.19 from an earlier version, then you don't have to add the tag again. The tag stays on your subnet. You can use the following tag to control where an Application Load Balancer is provisioned. Use this tag in addition to the subnet tags required for automatically provisioning an Application Load Balancer.kubernetes.io/cluster/$CLUSTER_NAME    sharedImportant: The AWS Load Balancer Controller workflow checks subnet tags for the value of " " (empty string) and 1. For private subnets, set the value of the kubernetes.io/role/internal-elb tag to an empty string or 1. For public subnets, set the value of the kubernetes.io/role/elb tag to an empty string or 1. These tags allow your subnets to be auto-discovered from the Amazon EKS VPC subnets of your Application Load Balancer.6.    Validate that your Amazon EKS VPC subnets have the correct tags:aws ec2 describe-subnets --subnet-ids your-subnet-xxxxxxxxxxxxxxxxx7.    Deploy a sample application to verify that the AWS Load Balancer Controller creates an Application Load Balancer as a result of the Ingress object:kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/examples/2048/2048_full.yaml8.    Verify that the Ingress resource gets created and has an associated Application Load Balancer:kubectl get ingress/2048-ingress -n 2048-gameEither an internal or internet-facing load balancer is created, depending on the annotations (alb.ingress.kubernetes.io/scheme:) that you defined in the Ingress object and subnets.Follow"


Question: How do I raise the priority of agent to agent or agent to queue transferred calls in Amazon Connect?

I want to raise the priority of agent to agent or agent to queue transferred calls in my Amazon Connect contact center.

Answer: "I want to raise the priority of agent to agent or agent to queue transferred calls in my Amazon Connect contact center.ResolutionImportant: To create and edit contact flows, you must log in to your Amazon Connect instance as a user with sufficient permissions in their security profile.Create a Transfer to queue contact flowLog in to your Amazon Connect instance.Important: Replace the alias with your instance's alias.In the left navigation bar, hover over Routing, and then choose Contact flows.On the Contact flows page, choose the arrow icon next to Create contact flow, and then choose Create transfer to queue flow.In the contact flow designer, for Enter a name, enter a name for the contact flow. For example: Transfer to [your_queue_name] flowChoose Save.For more information, see Create a new contact flow.Add a Play prompt block for your Transfer to queue contact flowIn the contact flow designer, expand Interact.Drag and drop a Play prompt block onto the canvas.Choose the Play prompt block title. The block's settings menu opens.For Prompt, configure the audio prompt that you want to play.Choose Save.For more information, see Contact block: Play prompt.Add a Change routing priority / age block for your Transfer to queue contact flowIn the contact flow designer, expand Set.Drag and drop a Change routing priority / age block onto the canvas.Choose the Change routing priority / age block title. The block's settings menu opens.For Set priority or routing age, configure the priority of contact by either priority or time.Note: Contacts are routed by priority. 1 is the highest priority and 5 is the lowest. Contacts are further ordered by time or age in the queue.Choose Save.For more information, see Contact block: Change routing priority / age.Add a Transfer to queue block for your Transfer to queue contact flowIn the contact flow designer, expand Transfer.Drag and drop a Transfer to queue block onto the canvas.Choose the Transfer to queue block title. The block's settings menu opens.Note: You don't need to set the Transfer to queue block, because the destination of this flow is set later with quick connects.Choose Save.For more information, see Contact block: Transfer to queue.Add a Disconnect / hang up block for your Transfer to queue contact flowIn the contact flow designer, expand Terminate / Transfer.Drag and drop a Disconnect contact block onto the canvas.For more information, see Contact block: Disconnect / hang up.Create a Transfer to agent contact flowLog in to your Amazon Connect instance.Important: Replace the alias with your instance's alias.In the left navigation bar, hover over Routing, and then choose Contact flows.On the Contact flows page, choose the arrow icon next to Create contact flow, and then choose Create transfer to agent flow.In the contact flow designer, for Enter a name, enter a name for the contact flow. For example: Transfer to [your_agent_name] flowChoose Save.Add a Play prompt block for your Transfer to agent contact flowIn the contact flow designer, expand Interact.Drag and drop a Play prompt block onto the canvas.Choose the Play prompt block title. The block's settings menu opens.For Prompt, configure the audio prompt that you want to play.Choose Save.Add a Change routing priority / age block for your Transfer to agent contact flowIn the contact flow designer, expand Set.Drag and drop a Change routing priority / age block onto the canvas.Choose the Change routing priority / age block title. The block's settings menu opens.For Set priority or routing age, configure the priority of contact by either priority or time.Note: Contacts are routed by priority. 1 is the highest priority and 5 is the lowest. Contacts are further ordered by time or age in the queue.Choose Save.Add a Transfer to agent (beta) block for your Transfer to agent contact flowIn the contact flow designer, expand Terminate / Transfer.Drag and drop a Transfer to agent (beta) block onto the canvas.Choose Save.For more information, see Contact block: Transfer to agent (beta).Note: The Transfer to agent block is a beta feature and works only for voice interactions. If you want an agent to agent transfer flow for voice, see Set up agent-to-agent transfers.Create and enable a quick connectCreate a quick connect. During creation, do the following:For Destination, choose any queue for a queue quick connect and agent for agent quick connect, because the contact doesn't actually enter the queue or agent.For Contact flow, choose the Transfer to queue or agent contact flow that you created depending on your type of quick connect.Add the quick connect to the queues where you want the agents to see it.Follow"


Question: How do I sign up for an AWS Support plan?

I'd like to speak with AWS support engineers about my resources. How do I sign up for an AWS Support plan?

Answer: "I'd like to speak with AWS support engineers about my resources. How do I sign up for an AWS Support plan?ResolutionTo sign up for an AWS Support plan, you must sign in with:AWS account root user credentials-or-AWS Identity and Access Management (IAM) user credentials with access permissions for AWS Support plans. For more information, see Manage access for AWS Support Plans.To sign up for an AWS Support plan, do the following:Open AWS Support Plans.(Optional) On the Support Plans page, compare the Support plans. For pricing information, see AWS Support Plan pricing.Under AWS Support pricing example, choose See examples, and then choose one of the Support plan options to see the estimated cost.Choose Review downgrade or Review upgrade for the plan that you want. Important: If you have an Enterprise On-Ramp or Enterprise Support plan, on the Change plan confirmation dialog box, choose Contact us, fill in the form, and then choose Submit.For Change plan confirmation, expand the support items to see the features included with the plan.Under Pricing, you can view the projected one-time charges for the new Support plan.Choose Accept and agree.If the Support plan that you choose has a monthly cost associated with it, then your payment method is automatically charged the prorated monthly cost according to the days remaining in the current month. When this charge is processed, your AWS Support subscription is activated within a few hours.To learn about the benefits and costs of the available AWS Support plans, visit AWS Support.Related informationHow do I change my AWS Support plan?Follow"


Question: How do I capture client IP addresses in the web server logs behind an ELB?

"I'm using Elastic Load Balancing (ELB) for my web server, and I can see my load balancer's IP address in the web server access logs. How do I capture client IP addresses instead?"

Answer: "I'm using Elastic Load Balancing (ELB) for my web server, and I can see my load balancer's IP address in the web server access logs. How do I capture client IP addresses instead?Short descriptionYour web server access logs capture the IP address of your load balancer because the load balancer establishes the connection to your instances. To capture the IP addresses of clients in your web server access logs, configure the following:For Application Load Balancers and Classic Load Balancers with HTTP/HTTPS listeners, the X-Forwarded-For HTTP header captures client IP addresses. You can then configure your web server access logs to record these IP addresses.For Classic Load Balancers with TCP/SSL listeners, activate Proxy Protocol support on the Classic Load Balancer and the target application. Make sure to configure Proxy Protocol support on both the load balancer and the application.For Network Load Balancers, register your targets by instance ID to capture client IP addresses without additional web server configuration. For instructions, see Target group attributes instead of the following resolutions.For Network Load Balancers when you can register only IP addresses as targets, activate proxy protocol version 2 on the load balancer. For instructions, see Enable proxy protocol instead of the following resolutions.ResolutionApplication Load Balancers and Classic Load Balancers with HTTP/HTTPS listeners (Apache)1.    Open your Apache configuration file using a text editor. The location varies by configuration, such as /etc/httpd/conf/httpd.conf  for Amazon Linux and RHEL**,** or /etc/apache2/apache2.conf for Ubuntu.2.    In the LogFormat section, add %{X-Forwarded-For}i, similar to the following:...    LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined    LogFormat "%h %l %u %t \"%r\" %>s %b" common    ...3.    Save your changes.4.    Reload the Apache service.For Sysvinit, Debian-based systems (such as Ubuntu) and SUSE (such as SLES11), run this command:# /etc/init.d/apache2 reloadFor Sysvinit, RPM-based systems (such as RHEL 6 and Amazon Linux), except SUSE, run this command:# /etc/init.d/httpd reloadFor Systemd, Debian-based systems (such as Ubuntu) and SUSE (such as SLES12), run this command:# systemctl reload apache2For Systemd, RPM-based systems (such as RHEL 7 and Amazon Linux 2), except SUSE, run this command:# systemctl reload httpd5.    Open your Apache web server access logs. The location varies by configuration.6.    Verify that client IP addresses are now recorded under the X-Forwarded-For header.Application Load Balancers and Classic Load Balancers with HTTP/HTTPS Listeners (NGINX)1.    Open your NGINX configuration file using a text editor. The location is typically /etc/nginx/nginx.conf.2.    In the LogFormat section, add $http_x_forwarded_for, similar to the following:http {    ...    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                      '$status $body_bytes_sent "$http_referer" '                      '"$http_user_agent" "$http_x_forwarded_for"';    access_log  /var/log/nginx/access.log  main;    ...}3.    Save your changes.4.    Reload the NGINX service.For example, on Amazon Linux 2 or RHEL, run this command:systemctl reload nginxNote: The command to reload the NGINX service is different on other systems. The commands to reload NGINX are similar to the commands to reload the Apache service in the previous section.5.    Open your NGINX web server access logs. The location varies by configuration.6.    Verify that client IP addresses now recorded under the X-Forwarded-For header.Classic Load Balancers with TCP/SSL Listeners (Apache)1.    Open your Apache configuration file using a text editor. The location varies by configuration, such as /etc/httpd/conf/httpd.conf for Amazon Linux and RHEL, or /etc/apache2/apache2.conf for Ubuntu.2.    Make sure that your Apache configuration loads the module mod_remoteip (available for Apache version 2.4.31 and newer). This module includes the RemoteIPProxyProtocol directive. In your configuration file, check for a line that's similar to the following:Amazon Linux or RHEL:LoadModule remoteip_module modules/mod_remoteip.soUbuntu:LoadModule remoteip_module /usr/lib/apache2/modules/mod_remoteip.so3.    Confirm that the mod_remoteip module loads:$ sudo apachectl -t -D DUMP_MODULES | grep -i remoteip4.    Review the output and verify that the output contains a line that's similar to:remoteip_module (shared)Important: If the output doesn't contain this line, then the module isn’t included or loaded in your configuration. Make sure to activate the module before you proceed.5.    Add the following line to your Apache configuration file to activate Proxy Protocol support:RemoteIPProxyProtocol On6.    Edit the LogFormat section of the configuration file to capture the remote IP address (%a) and the remote port ( %{remote}p:), similar to the following:LogFormat "%h %p %a %{remote}p %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined7.    Save your changes.8.    Reload the Apache service.For Sysvinit, Debian-based systems (such as Ubuntu), and SUSE (such as SLES11), run this command:# /etc/init.d/apache2 reloadFor Sysvinit, RPM-based systems (such as RHEL 6 and Amazon Linux), except SUSE, run this command:# /etc/init.d/httpd reloadFor Systemd, Debian-based systems (such as Ubuntu) and SUSE (such as SLES12), run this command:# systemctl reload apache2For Systemd, RPM-based systems (such as RHEL 7 and Amazon Linux 2), except SUSE, run this command:# systemctl reload httpd9.    Open the Apache web server access logs. The location varies by configuration.10.    Verify that client IP addresses are now recorded under the Proxy Protocol header.11.    Activate support for Proxy Protocol in your target application.Classic Load Balancers with TCP/SSL Listeners (NGINX)1.    Open the NGINX configuration file using a text editor. The location is typically /etc/nginx/nginx.conf.2.    Change the listen line of the server section to *NOTE: THIS IS PLACEHOLDER CONTENT THAT WILL BE REPLACED AFTER EDITING*###Long SentencesXX###Wrong/Misspelled Service Name###Link broken            or incorrect titlelink ###Sensitive TermsTerms###Changes**WAS:** **IS:** **REASON:** **WAS:** **IS:** **REASON:** **WAS:** **IS:** **REASON:** **WAS:** **IS:** **REASON:**proxy_protocolMake sure to change the log_format line of the http section to set the proxy_protocol_addr:http {    ...    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                      '$status $body_bytes_sent "$http_referer" '                      '"$http_user_agent" "$proxy_protocol_addr"';     access_log  /var/log/nginx/access.log  main;    ...}server {        ...        listen  80  default_server proxy_protocol;        ...        }...}3.    Save your changes.4.    Reload the NGINX service.For example, on Amazon Linux 2 or RHEL, run this command:systemctl reload nginxNote: The command to reload the NGINX service is different on other systems. The commands to reload NGINX are similar to the commands to reload the Apache service in the previous section.5.    Open the NGINX web server access logs. The location varies by configuration.6.    Verify that client IP addresses are now recorded under the Proxy Protocol header.7.    Activate support for Proxy Protocol in your target application.Follow"


Question: Why can't I delete my snapshot in Amazon Redshift?

"I'm trying to delete a snapshot of my Amazon Redshift cluster. However, I receive an error message indicating that my snapshot is accessible by another AWS account. How do I resolve this?"

Answer: "I'm trying to delete a snapshot of my Amazon Redshift cluster. However, I receive an error message indicating that my snapshot is accessible by another AWS account. How do I resolve this?Short descriptionIf you're trying to delete a snapshot that shares access with another AWS account, you might encounter the following error message:"Cannot delete the snapshot- xxx-xxx-xxx because other accounts still have access to it."To resolve this error message, remove the shared access from the AWS account that created the cluster snapshot in Amazon Redshift. Then, delete your cluster snapshot.ResolutionTo delete a shared cluster snapshot using the Amazon Redshift console, perform the following steps:1.    Sign in to the AWS Management Console with the AWS account that created the cluster snapshot.2.    Open the Amazon Redshift console.3.    From Clusters, choose the snapshot that you want to delete.4.    Choose Actions.5.    Choose Manage Access to view the access settings for your cluster.6.    Choose Remove Account to delete the shared access of your cluster snapshot.7.    Delete your cluster snapshot.To delete a shared cluster snapshot using the AWS Command Line Interface (AWS CLI), perform the following steps:Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.1.    Revoke the shared snapshot access using the revoke-snapshot-access command:aws redshift revoke-snapshot-access --snapshot-id my-snapshot-id --account-with-restore-access <AWS-account-id-with-access>2.    Delete your Amazon Redshift cluster snapshot using the delete-cluster-snapshot command:aws redshift delete-cluster-snapshot --snapshot-identifier my-snapshot-idFollow"


Question: How do I find out if my Amazon EC2 Reserved Instances are being fully used?

"I've purchased some Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances for my account, and I'd like to be sure that I'm getting the maximum benefit from them. How do I find out if my Reserved Instances (RIs) are being fully utilized?"

Answer: "I've purchased some Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances for my account, and I'd like to be sure that I'm getting the maximum benefit from them. How do I find out if my Reserved Instances (RIs) are being fully utilized?ResolutionTo see the billing hours that are covered by your Amazon EC2 RIs, do the following:Open the Billing and Cost Management console.Choose Bills in the navigation pane.You can view the charges for different services in the Details section.Expand the Elastic Compute Cloud section and the AWS Region to view the billing information about your RIs.You can view the Reserved Instance types and billing hours for your RIs.You can use Cost Explorer reports or Amazon EC2 usage reports to understand more about the utilization of your Reserved Instances. You can use the RI Utilization and RI Coverage reports in Cost Explorer to:Track the number of RI hours used against the number of RI hours purchasedTrack the number of hours covered by RIs against the On Demand hours in the tableTrack the number of RI hours that you have reserved but did not useFor information on how to use Cost Explorer to view your RI utilization and coverage, see How can I use Cost Explorer to analyze my spending and usage?Related informationCreating Cost and Usage ReportsUnderstanding your reservations with Cost ExplorerHow Reserved Instances are appliedFollow"


Question: How do I troubleshoot lag in my RDS for SQL Server read replica?

I have an Amazon Relational Database Service (Amazon RDS) for Microsoft SQL Server instance with read replica. I'm seeing one of the following in my DB instance:There is a sudden increase in replica lag.Modification of the instance started to cause replica lag.The database on the read replica instance isn't accessible.How can I troubleshoot these issues?

Answer: "I have an Amazon Relational Database Service (Amazon RDS) for Microsoft SQL Server instance with read replica. I'm seeing one of the following in my DB instance:There is a sudden increase in replica lag.Modification of the instance started to cause replica lag.The database on the read replica instance isn't accessible.How can I troubleshoot these issues?Short descriptionAmazon RDS for SQL Server enterprise edition supports creation of a read replica within the same Region. Data replication is asynchronous and uses Always-On technology to replicate data from a master to a replica instance. RDS for SQL Server doesn't intervene to mitigate high replica lag between a source DB instance and its read replicas.Resolution1.    Check resource utilization on the master and on the replica instance using Amazon CloudWatch. Use the Enhanced Monitoring and Performance Insights features to check resource usage at a granular level.Important considerations for metrics on the master and replica instances:Make sure that CPU utilization isn't throttled. If you're running a burstable instance class, make sure that CPU credits are available or that you're running in Unlimited mode.Make sure that there is sufficient FreeableMemory. And, make sure that ReadIOPS and WriteIOPS are hitting provisioned limits. Validate that there is sufficient burst balance available if you're using a GP2 volume. For more information, see How do I troubleshoot low freeable memory in my RDS for SQL Server instance?Make sure that ReadThroughput and WriteThroughput aren't reaching instance class limits.2.    It's a best practice to create the master and replica instances with the same instance class, storage type, and number of IOPS. This avoids replica lag due to lack of resources in the replica instance. Additionally, depending on the workload, the read replica can be scaled up or scaled down if usage is minimal compared to the master instance.3.    Identify the timeframe when replica lag started to increase and then do the following:Check the WriteIOPS, WriteThroughput, NetworkReceiveThroughput and NetworkTrasmitThroughput metrics on the master instance based on start time of replica lag. Determine if the lag is due to write activity. Check the same metrics in the same time period on the read replica.Check if there are long-running transactions on the master instance. The following is an example query to the check status of active transactions:SELECT * FROM sys.sysprocesses WHERE open_tran = 1;4.    On the replica instance, check if there are any significant lock waits or deadlocks. Deadlocks occur between Select and DDL/DML transactions and cause delays in applying transaction logs from the master instance.The following is an example query to check for blocking:SELECT * FROM sys.sysprocesses WHERE blocked > 0;5.    Query to check for replica lag and maximum replica lag.Replica lagSELECT AR.replica_server_name     , DB_NAME (ARS.database_id) 'database_name'     , AR.availability_mode_desc     , ARS.synchronization_health_desc     , ARS.last_hardened_lsn     , ARS.last_redone_lsn     , ARS.secondary_lag_secondsFROM sys.dm_hadr_database_replica_states ARSINNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id--WHERE DB_NAME(ARS.database_id) = 'database_name'ORDER BY AR.replica_server_name;Verify that the 'last_hardened_lsn' value is progressing on the read replica.Maximum replica lagFor SQL Server, the ReplicaLag metric is the maximum lag of databases that have fallen behind, in seconds. For example, if you have two databases that lag 5 seconds and 10 seconds, respectively, then ReplicaLag is 10 seconds. The ReplicaLag metric returns the value of the following query. Run the query on the master instance.select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;6.    After you initiate read replica creation, a snapshot is taken from the master instance, and then restored to create a read replica instance. Transactions logs are replayed to synchronize the data with the master instance. However, after you create new instance, that instance experiences lazy loading, which causes replica lag. This is expected behavior. To minimize the effect of lazy loading, use IO1 type storage during read replica creation and then convert it back to GP2, if required.7.    Run transactions in batches on the master instance. This avoids running long transactions and keeps the transaction log file size minimal. Don't restart the replica instance unless required during high replica lag as doing this further delays replay of transaction logs.8.    Modification of the instance class on the master or replica instance might cause temporary replica lag. This is expected behavior because logs are processing from the master instance.Changing the storage type or storage size has a longer impact on replica lag until the storage optimization is completed. It isn't possible to find how much percentage of storage optimization is completed on RDS instances.9.    If the read replica reaches the storage full state, then the transaction logs from the master instance aren't processed and replica lag increases.If you suspect that storage space is due to TempDB or temporary tables, then restart the replica instance to temporarily release space.10.    If you're experiencing no progress in replica lag status, check the status of user databases on the replica instance. To replay logs, the database status must be Online.Be aware of the following:Newly created databases aren't included in the lag calculation until they're accessible on the read replica.ReplicaLag returns -1 if RDS can't determine the lag, such as during replica setup, or when the read replica is in the error state.Related informationWorking with read replicas for Microsoft SQL Server in Amazon RDSFollow"


Question: How can I stop Route 53 health check requests that are sent to my application?

How can I stop Amazon Route 53 health check requests that are sent to my application?

Answer: "How can I stop Amazon Route 53 health check requests that are sent to my application?Short descriptionYou can configure Route 53 health checks against any public resource. If your application is receiving health check requests from Route 53 when you haven't configured health checks on your application, the cause might be:A health check was mistakenly configured against your application by another customer.A health check was configured from your account for testing purposes but wasn't deleted when testing was complete.A health check was configured against another customer's public AWS resources. However, the IP addresses of those resources were reassigned to your AWS resources. In this scenario, the health check was configured on the reassigned IP addresses. If the health check was based on domain names, the requests were sent due to DNS caching.The Elastic Load Balancing service updated its public IP addresses due to scaling, and the IP addresses were reassigned to your load balancer.ResolutionTo stop unwanted health checks requests from Route 53:Find the ID of the unwanted health check by reviewing your application logs. For more information, see How can I identify and resolve unwanted health checks from Route 53?Contact AWS. If you have an AWS Support plan, create a support case. If you don't have an AWS Support plan, complete the Stop unwanted Amazon Route 53 health checks form. In both scenarios, be sure to include the health check ID that you found in step 1.(Optional) Block the health check IP address ranges in your firewall. To find the IP address ranges for each AWS Region used by the Route 53 health check service, see the IP ranges JSON file. In the JSON file, search for "ROUTE53_HEALTHCHECKS". For more information, see Configuring router and firewall rules for Amazon Route 53 health checks.Follow"


Question: How do I install WordPress in a Lightsail instance instead of using the WordPress blueprint provided by Bitnami?

I want to install the WordPress application in my Amazon Lightsail instance instead of using the Lightsail WordPress blueprint provided by Bitnami.

Answer: "I want to install the WordPress application in my Amazon Lightsail instance instead of using the Lightsail WordPress blueprint provided by Bitnami.Short descriptionAmazon Lightsail provides WordPress blueprints that you can use to launch and start using the WordPress application. This WordPress application is packaged by Bitnami. Instead of using this Bitnami stack, you can install WordPress manually in your Lightsail OS instances, such as Amazon Linux 2, Ubuntu, CentOS, and so on. The following resolution covers the steps for installing WordPress in the major Linux distributions available in Lightsail.Before you begin, be aware of the following:WordPress recommends using either Apache or NGINX as a preferred hosting service. The following resolution installs Apache.WordPress has minimum requirements for the PHP and MariaDB versions that are used for their latest packages. A minimum of PHP7.3 and MariaDB 10.2 are suggested. It's a best practice to use newer versions of these packages and to use the latest Linux distributions available in Amazon Lightsail.For more information, see Server Environment on WordPress.org.The latest package and WordPress's minimum requirements are subject to change. The following resolution uses the configurations supported and recommended by WordPress as of October 2021.The following resolution provides the basic installation steps. You can personalize WordPress by adding plugins, modifying the OS level firewall, and so on.ResolutionFor instructions on installing WordPress in Amazon Linux 2, see Host a WordPress blog on Amazon Linux 2.Install a LAMP stackFor installing LAMP (Linux, Apache, MariaDB, and PHP) in your Lightsail instance, see How do I install a LAMP stack manually on my Lightsail instance?Create the database and a userWordPress is a database-oriented website. You must create a database and a user before the installing the WordPress application.1.    Run the following command to enter the MySQL shell as root:sudo mysql -u root -ppassword: <insert-root-password>Note: The password doesn't appear as you enter it so that it isn't visible to other users.2.    Create a database and user with a password, and then add privileges to the new database:mysql> CREATE DATABASE databasename;mysql> GRANT ALL PRIVILEGES ON databasename.* TO 'wordpress_user'@'localhost' IDENTIFIED BY 'PASSWORD';mysql> FLUSH PRIVILEGES;mysql> exit;Note: Replace databasename with the name of the database that you want to create. Replace wordpress_user with the name of the user for WordPress. Replace PASSWORD with the desired password.Install and configure the WordPress packageTo download the latest WordPress package from the official website to the /tmp directory and extract the package to access the configuration files, do the following:1.    Download the latest WordPress package:cd /tmpwget https://wordpress.org/latest.tar.gz2. Run the following command to extract the package:sudo tar -xzvf latest.tar.gz3.    Move the WordPress files to the /var/www/html directory so that they are accessible through Apache:sudo cp -pr /tmp/wordpress/* /var/www/html/4.    Create the WordPress configuration file wp-config.php by renaming the file wp-config-sample.php:cd /var/www/htmlsudo mv wp-config-sample.php wp-config.php5.    Run the following command to open the WordPress configuration file in the vi editor:sudo vi wp-config.php6.    Add the DB credentials. The following is an example snippet:// ** MySQL settings - You can get this info from your web host ** ///** The name of the database for WordPress */define( 'DB_NAME', 'databasename' );/** MySQL database username */define( 'DB_USER', 'wordpress_user');/** MySQL database password *define( 'DB_PASSWORD', 'PASSWORD' );/** MySQL hostname */define( 'DB_HOST', 'localhost' );/** Database charset to use in creating database tables. */define( 'DB_CHARSET', 'utf8' );/** The database collate type. Don't change this if in doubt. */define( 'DB_COLLATE', '' )Note: Replace databasename, wordpress_user, and PASSWORD with the credentials that you created in the previous step.7.    Save the file by pressing esc, type :wq!, and then press ENTER.8.    (Optional) In some distributions such as Ubuntu and Debian, the Apache installation might have added a pre-existing file named index.html. This file causes conflicts with the WordPress index.php file. In this occurs, delete index.html or move it to a backup file:$ sudo mv index.html backup_index.html9.    Restart the Apache service:CentOS and Amazon Linux 2$ sudo systemctl restart httpdUbuntu and Debian versions$ sudo systemctl restart apache2Verify that the port is open and listeningPort 80 is open by default when you launch a Lightsail instance. If you have SSL enabled for your website, then make sure to open port 443 so that the port is accessible over the internet. For information on adding a firewall rule to your instance, see Instance firewalls in Amazon Lightsail.Final checkAccess your instance's public IP address in your web browser, and then confirm that it goes to the page wp-admin/install.php. You can now create WP credentials in that page and then access the WordPress dashboard.Follow"