Question: "How can I get metrics from Amazon CloudWatch that show the EBS throughput of my EC2 instance, and then set up an alarm that notifies me when the EC2 instance reaches the throughput limit?"

"How can I get metrics from Amazon CloudWatch that show the aggregate Amazon Elastic Block Store (Amazon EBS) throughput of my Amazon Elastic Compute Cloud (Amazon EC2) instance? Also, how can I then set up an alarm that notifies me when the EC2 instance reaches the throughput limit?"

Answer: "How can I get metrics from Amazon CloudWatch that show the aggregate Amazon Elastic Block Store (Amazon EBS) throughput of my Amazon Elastic Compute Cloud (Amazon EC2) instance? Also, how can I then set up an alarm that notifies me when the EC2 instance reaches the throughput limit?Short descriptionThere isn't a native Amazon EBS metric that tracks the EBS throughput of a Xen-based Amazon EC2 instance in CloudWatch. However, you can use the EC2EBSThroughput/ebs-stats.sh script to measure the aggregate EBS throughput of your EC2 instance.The script collects the total read/write bytes per second across all attached volumes, and then pushes the throughput as a metric to Amazon CloudWatch. You can view those metrics in the Amazon CloudWatch console and set an alarm that triggers based on a threshold that you specify.Note: The AWS Nitro-based EC2 instances built with Amazon EBS-optimized instance burst capability include the CloudWatch metrics EBSIOBalance% and EBSByteBalance%. These metrics are available for some instance sizes that burst to their maximum performance for 30 minutes at least once every 24 hours. For a complete list of applicable instance types, see Supported instance types.The ebs-stats.sh script is for Xen-based EC2 instances in CloudWatch. The script is compatible only with Amazon Linux, Red Hat Enterprise Linux, and CentOS instances. However, you can customize the script for other Linux distributions.Note: If your instance has an instance store volume, the script reports aggregate throughput, including the throughput of the instance store volume. This means that you might not get an accurate measurement of the EBS throughput from this script.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.1.    For RHEL-based distributions, install the AWS CLI, if you haven't already done so.2.    Download the ebs-stats.sh script.3.    Place the script on your instance, and then make it executable. You must run the script as a root user or sudo. Otherwise, it fails.$sudo chmod +x ebs-stats.sh4.    From the AWS CLI, set the desired ebs-stats.sh runtime frequency by running the following command in the background:$sudo nohup ./ebs-stats.sh example-sleep-interval &Note: Replace example-sleep-interval with the desired number of seconds between each data point.5.    Create an AWS Identity and Access Management (IAM) role.6.    Attach the following policy to the role:{  "Version": "2012-10-17",  "Statement": [    {      "Action": [        "cloudwatch:ListMetrics",        "cloudwatch:GetMetricStatistics",        "cloudwatch:PutMetricData",        "autoscaling:DescribeAutoScalingInstances"      ],      "Effect": "Allow",      "Resource": "*"    }  ]}7.    Attach the IAM policy to your EC2 instance. This allows the script to push the metrics to Amazon CloudWatch.8.    From the CloudWatch console, set an alarm for EBSThroughoutMB. For more information, see Create a CloudWatch alarm based on a static threshold or Using Amazon CloudWatch alarms.Be sure that you choose the correct period based on the argument that you used.Related informationMonitoring your instances using CloudWatchList the available CloudWatch metrics for your instancesAmazon EBS-optimized instancesFollow"


Question: How do I share my AWS Managed AD directory from one AWS account to another?

I want to share an AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory from one AWS account to another. How do I do this?

Answer: "I want to share an AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory from one AWS account to another. How do I do this?Short descriptionYou can share an AWS Managed Microsoft AD directory using one of two methods:AWS Organizations: Share your directory with other trusted AWS accounts within the same organization.Handshake: Share your directory with AWS accounts that are outside of the organization.For more information, see Sharing methods.ResolutionFor a detailed tutorial, see Tutorial: Sharing your AWS Managed Microsoft AD directory for seamless EC2 domain-join.Note: Directory sharing is a Regional feature of AWS Managed Microsoft AD. If you're using multi-Region replication, share the directory separately in each Region.Related informationShare your directoryKey directory sharing conceptsFollow"


Question: How can I prevent containers from accessing Amazon EC2 instance metadata in Amazon ECS?

I want to prevent containers from accessing Amazon Elastic Compute Cloud (Amazon EC2) instance metadata in Amazon Elastic Container Service (Amazon ECS).

Answer: "I want to prevent containers from accessing Amazon Elastic Compute Cloud (Amazon EC2) instance metadata in Amazon Elastic Container Service (Amazon ECS).Short descriptionIf you run containers in an Amazon EC2 instance, it's a best practice for security reasons to avoid allowing your applications to assume an instance role.Amazon ECS provides the following networking modes to run a task with external connectivity:The bridge mode. The task uses Docker's built-in virtual network.The awsvpc mode. The task allocates an elastic network interface, and all the containers share the same networking namespace.The host mode. The containers share the host's networking namespace.The following resolution shows you how to prevent containers from accessing the instance metadata using the bridge and awsvpc networking modes.Note: It's not possible to prevent access with the host networking mode, because the Amazon ECS agent runs on the host networking namespace and requires access to it.ResolutionFor tasks using the awsvpc networking mode, add the following parameter to the Amazon ECS configuration file /etc/ecs/ecs.config:ECS_AWSVPC_BLOCK_IMDS=trueFor tasks using the bridge networking mode, use iptables to block the network traffic from the docker0 bridge.You can specify the configuration of iptables in your custom Amazon Machine Image (AMI) or at launch in Amazon EC2 instance user data. See the following example for Amazon Linux 2 AMIs.Note: If you choose Amazon EC2 instance user data, the following configuration must be written before the Docker daemon starts. The cloud-boothook user data format executes earlier in the boot process than most services.#cloud-boothookyum install iptables-services -ycat <<EOF > /etc/sysconfig/iptables *filter:DOCKER-USER - [0:0]-A DOCKER-USER -d 169.254.169.254/32 -j DROPCOMMITEOFsystemctl enable iptables && systemctl start iptablesTo include this configuration with your existing user data, use the MIME multi part archive. See the following example:Content-Type: multipart/mixed; boundary="==BOUNDARY=="MIME-Version: 1.0--==BOUNDARY==Content-Type: text/cloud-boothook; charset="us-ascii"# Set iptables configurationyum install iptables-services -ycat <<EOF > /etc/sysconfig/iptables *filter:DOCKER-USER - [0:0]-A DOCKER-USER -d 169.254.169.254/32 -j DROPCOMMITEOFsystemctl enable iptables && systemctl start iptables--==BOUNDARY==Content-Type: text/x-shellscript; charset="us-ascii"#!/bin/bash# Set any ECS agent configuration optionsecho "ECS_CLUSTER=my-ecs-cluster" >> /etc/ecs/ecs.config--==BOUNDARY==--Follow"


Question: Why did I receive an HTTP 5xx error when connecting to web servers running on EC2 instances configured to use Classic Load Balancing?

"I received an HTTP 502, 503, or 504 errors when I tried to connect to web servers running on EC2 instances configured to use Classic Load Balancing. How can I troubleshoot and resolve 5xx errors?"

Answer: "I received an HTTP 502, 503, or 504 errors when I tried to connect to web servers running on EC2 instances configured to use Classic Load Balancing. How can I troubleshoot and resolve 5xx errors?ResolutionHTTP 502 (Bad Gateway)You might receive an HTTP 502 error if either the web server or associated backend application servers running on EC2 instances return a message that can't parsed by Classic Load Balancer (CLB).To resolve this error, see I get HTTP 502 errors when I make requests through a Classic Load Balancer. How do I troubleshoot these errors?HTTP 503 (Service Unavailable)HTTP 503 errors can occur for several reasons, including:The surge queue is full. Check that your instances have enough capacity to handle the request rate by reviewing the SpilloverCount metric.There are no healthy instances. Make sure that you have healthy instances in every Availability Zone that your load balancer responds. To do this, review the HealthyHostCount metric. For more information, see Troubleshoot a Classic Load Balancer: Health checks.You haven't registered at least one instance in every AZ that your load balancer responds in. If you can't confirm that an instance is registered in each AZ, then turn on cross-zone load balancing.Connection draining is not turned on for the Classic Load Balancer that your web server instances are registered with.For help resolving this error, see How do I troubleshoot HTTP 503 errors returned while using Classic Load Balancer?HTTP 504 (Gateway Timeout)HTTP 504 errors occur for the following reasons:Web server instances or backend application server instances are busy and can't respond to requests within the configured Elastic Load Balancing (ELB) idle timeout limit. For more information, see Troubleshoot high latency on my ELB Classic Load Balancer.Web server instances or backend application server instances terminate connections before the load balancer does. This results in premature connection terminations.Web server instances or backend application server instances have crashed or restarted server processes when requests are in-flight. This results in the server breaking all connections.Apache web server instances have the AcceptFilter http/https option turned on. This instructs Apache to implement TCP_DEFER_ACCEPT on the connections.Apache web server instances have the event MPM turned on but have not optimally configured the prefork and worker MPMs. The default ELB idle timeout limit of 60 seconds. For more information, see What are the optimal settings for using Apache or NGINX as a backend server for ELB?For help resolving this error, see How do I troubleshoot HTTP 504 errors returned while using a Classic Load Balancer?Related informationWhat is Elastic Load Balancing?Tutorial: Create a Classic Load BalancerConfigure health checks for your Classic Load BalancerMonitor your Classic Load BalancerFollow"


Question: How do I configure custom outbound whisper flows in Amazon Connect?

I want to configure custom outbound whisper flows in Amazon Connect.

Answer: "I want to configure custom outbound whisper flows in Amazon Connect.Short descriptionThe default outbound whisper flow is played for customers at the start of an outbound call. You can override default outbound whisper flows by creating and setting your own outbound whisper flows.ResolutionImportant: To create and edit contact flows, you must log in to your Amazon Connect instance as a user with sufficient permissions in your security profile.Create an outbound whisper flowTo manage what customers experience immediately before being joined to an agent on an outbound call, create an outbound whisper flow.Log in to your Amazon Connect instance.Note: Replace the alias with your instance's alias.In the navigation pane, 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 outbound whisper flow.In the contact flow designer, for Enter a name, enter a name for the contact flow. For example: Outbound whisper - CustomChoose Save.Add a Set voice blockSet the text-to-speech language and voice using a Set voice contact block.In the contact flow designer, expand Set.Drag and drop a Set voice block onto the canvas.Choose the Set voice block title. The block's settings menu opens.Choose a Language and Voice for the audio prompt that the customer hears.Choose Save.Add a Play prompt blockConfigure the audio prompt that customers hear using a Play prompt contact block.In 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.Note: (Optional) To record outbound calls, add a Set recording and analytics behavior block in the flow.Add a Set recording and analytics behavior blockIn the contact flow designer, expand Set.Drag and drop a Set recording and analytics behavior block onto the canvas.Choose the Set recording and analytics behavior block title. The block's settings menu opens.For Call recording, choose the On option. For more information, see Contact block: Set recording and analytics behavior.Choose Save.For more information about call recording, see Set up recording behavior.Add an End flow / Resume blockIn the contact flow designer, expand Terminate / Transfer.Drag and drop an End flow / resume contact block onto the canvas.The block ends the outbound whisper flow while keeping the customer connected. For more information, see Contact block: End flow / Resume.Finish the Outbound whisper flowAdd and connect more contact blocks to your outbound whisper flow as needed for your use case.Connect all the connectors in your contact flow to a block. For example: Entry point > Set voice > Play prompt >End flow / resumeChoose Save to save a draft of the flow.Choose Publish to activate the flow immediately.For more information, see Create a new contact flow.Set your custom outbound whisper flowsTo override the default outbound whisper flow for outbound calls initiated from the contact center, set your new outbound whisper flow in the queue.In your Amazon Connect instance, in the navigation pane, hover over Routing, and then choose Queues.On the Queues page, choose the name of the queue where you want to override the default outbound whisper flow.On the Edit queue page, select the outbound whisper flow that you created from the Outbound whisper flow (optional) menu.Choose Save.Note: Every agent in Amazon Connect is associated with one routing profile. For every routing profile, there is one default outbound queue. The outbound whisper flow is taken from that default outbound queue for an agent.Related informationDefault contact flowsFollow"


Question: Why is my CloudWatch canary failing with the error "Cannot find module '/opt/nodejs/node_modules/myfunction"?

Why is my Amazon CloudWatch canary failing with the error "Cannot find module '/opt/nodejs/node_modules/myfunction"?

Answer: "Why is my Amazon CloudWatch canary failing with the error "Cannot find module '/opt/nodejs/node_modules/myfunction"?ResolutionIf you don't use the structure required by CloudWatch when creating a .zip file of your function and dependencies, then you receive an error. The error message reads: Cannot find module '/opt/nodejs/node_modules/myfunction.You must create your .zip file under the nodejs/node_modules file path (such as nodejs/node_modules/myCanaryFilename.js). To create your .zip file under the correct file path, do the following:1.    Create the required structure.mkdir -p /nodejs/node_modules/2.    Copy your CloudWatch canary function to /nodejs/node_modules/.Note: The handler naming convention is filename.handler.cp CanaryFunction.js /nodejs/node_modules/cp -R /lib /nodejs/node_modules/3.    Zip your directory on the top of /nodejs.zip -r Canary.zip ./nodejs/*Note: When creating a Synthetics canary from scratch, if you have multiple .js files or script dependencies, then bundle all files into a single .zip file. Use the following folder structure: "nodejs/node_modules". For example, nodejs/node_modules/myCanaryFilename.js file and other folders and files.Related informationPackaging your canary filesFollow"


Question: How can I create a Storage Gateway file share using an Amazon S3 prefix?

I want to create an AWS Storage Gateway file share that maps to a single Amazon Simple Storage Service (Amazon S3) prefix. How can I do that?

Answer: "I want to create an AWS Storage Gateway file share that maps to a single Amazon Simple Storage Service (Amazon S3) prefix. How can I do that?ResolutionWhen creating a file share for S3 File Gateways, you can specify an S3 prefix that allows you to organize your file share objects. For example, if your bucket is named examplebucket and it has the prefix exampleprefix/, you can specify this prefix while creating the file share. To do this in the console, feed examplebucket for the Amazon S3 bucket name field, and feed exampleprefix/ for the S3 prefix name field. This allows you to organize all the objects that are created in the root of the file share inside the prefix of the S3 bucket, rather than the root of the bucket. For more information on S3 prefixes, see Organizing objects using prefixes.Before you create a file share that maps to an Amazon S3 prefix, you must confirm that the prefix doesn't overlap with the prefix of another file share. It's a best practice to not create file shares with overlapping prefixes because this can lead to Read/Write conflicts. If you already created a file share that maps to the root of the bucket, then you must first update the existing file share to point to another prefix within the bucket.After you confirm that no other file shares point to the Amazon S3 prefix that you want to map your new file share to, follow the steps to create a Network File System (NFS) file share or Server Message Block (SMB) file share. For Amazon S3 bucket name, enter the name of the relevant bucket. For Prefix name, enter the prefix that you want to map the file share to.Note the following requirements for mapping a file share to an Amazon S3 prefix:The prefix must end with "/".After you create a file share with a specified prefix, you can't modify or delete the prefix on the file share's settings.Follow"


Question: How can I detect false positives caused by AWS Managed Rules and then add them to a safe list?

Legitimate requests to my application are blocked by AWS Managed Rules in AWS WAF. How can I detect false positives caused by these rules and then add them to a safe list?

Answer: "Legitimate requests to my application are blocked by AWS Managed Rules in AWS WAF. How can I detect false positives caused by these rules and then add them to a safe list?ResolutionDetect false positives caused by AWS Managed Rules1.    Find the rule inside the managed rule-group that is blocking the legitimate request. You can find the rule blocking the requests under "terminatingRuleId" field of AWS WAF logs. For more details, check the "terminatingRuleMatchDetails" section of the log.2.    Verify the part of the request parameter that's causing the false positive using one of the methods below:curl: Perform a curl on your endpoint and then check whether you are receiving "403 Forbidden" error when sending the false positive error. For example:$ curl -ikv http://<your-domain>.com/<false positive>Note: In this example, replace <your-domain> with your domain and <false positive> with your false positive vector.Web browser: Enter your domain and the false positive vector in your web browser to check whether you are receiving "403 Forbidden" error. For example:http://<your-domain>/<false positive>In the previous example, replace <your-domain> with your domain and <false positive> with your false positive vector.Postman: Use the Postman tool to send a request to an endpoint using the rule and parameter that's giving the false positive error.3.    Determine the vector that's causing the false positive. Create a custom condition rule that allows you to pass legitimate requests.For example, an internal team is making webpage changes. The requests contain scripts for those changes that cause the requests to be blocked by the rule ManagedRulesCommonRuleSet. You can use the parameters that uniquely identify the internal requests to prevent the managed rule from inspecting those requests. For example, if the legitimate requests are sourced from specific IPs, then you can create the IP set condition to exclude the IPs from inspection.Add false positives caused by AWS Managed Rules to your safe listAfter detecting the false positive, configure the Web ACL to not inspect the legitimate requests against the AWS Managed Rules rule-group that's causing the False Positive. You can then bypass the rule that's blocking the request. You have two ways to modify AWS Managed Rules:Adding labels (best practice)Using scope-down statementsLabelsYou can use labels added by AWS Managed Rules to prevent false positives. A label is metadata that a rule can add to matching web requests, regardless of the action associated with the rule. The latest version of AWS Managed Rules supports labels. By creating custom rules that match requests that have labels, you can change the default action of rules inside a managed rule-group.1.    Open the AWS WAF console, choose the correct Region, then choose IP sets.2.    Create an IP set containing legitimate IPs that you want excluded from inspection by a rule-group.3.    Choose Web ACLs from navigation pane on the AWS WAF console and choose your Web ACL.4.    Choose the Rules tab.5.    Choose the rule-group that contains the rule causing the false positive error, and then choose Edit.6.    Choose the rule causing the false positive error, and then set it to Count.7.    Choose Save rule.8.    Choose Add rule, and then choose Add my own rules and rule groups.9.    Choose Rule Builder for the rule type.10.    Enter a rule name, and then choose Regular rule as the type.11.    Set the If a request drop-down to matches all the statements (AND).12.    Select the following parameters for Statement 1:Set Inspect to Has a labelSet Match scope to LabelEnter the string containing the label name for the rule that's causing the false positive error13.    Select the following parameters for Statement 2:Turn on the Negate statement results optionSet Inspect to Originates from an IP address inSet IP set to the IP set you created containing the legitimate IPsSet IP address to use as the originating address to Source IP address14.    Set the Action to Block.15.    Under Set rule priority, set the priority of the rule to a lower priority than the AWS Managed Rules that's causing the false positive error.16.    Choose Save.Scope-down statementYou can use a scope-down statement to narrow the scope of the requests that the rule or rule-group evaluates. Adding a scope-down statement to a rule-group allows the requests to be inspected. The statement skips over any legitimate IPs included in the statement.1.    Open the AWS WAF console, choose the correct Region, and then choose IP sets.2.    Create an IP set containing legitimate IPs that you want excluded from inspection by a rule-group.3.    Choose Web ACLs on the navigation pane in the AWS WAF console, and then select your Web ACL.4.    Choose the Rules tab.5.    Choose the AWS Managed Rules entry that you want to add a scope-down statement to, and then choose Edit.6.    Create the scope-down statement excluding the IP set that you created. The following is an example of what the statement might look like:If a request: doesn't match the statements (NOT)Inspect: originates from an IP address inIP set: <your-IP-set>IP addresses to use as the originating address: Source IP address7.    Choose Save rule.Note: The scope-down statement doesn't inspect requests that fall out of scope against all the rules in a rule-group. For fine-grain explicit rule, it's best practice to use labels.Follow"


Question: How do I migrate phone numbers from one Amazon Connect instance to another?

I want to migrate a phone number or numbers from one Amazon Connect instance to another Amazon Connect instance. How can I do this?

Answer: "I want to migrate a phone number or numbers from one Amazon Connect instance to another Amazon Connect instance. How can I do this?Short descriptionThe steps to migrate your Amazon Connect phone number depend on the AWS Region and AWS account ownership of the source and destination instances. See the related resolution sections for the following scenarios:Both the source and destination instances are in the same Region and AWS accountThe source and destination instances are in different RegionsThe source and destination instances are in different AWS accountsResolutionBoth Amazon Connect instances are in the same Region and AWS accountIf the source and destination Connect instances are in the same Region and AWS account, use the ListPhoneNumbers and UpdatePhoneNumber APIs.The examples below use AWS Command Line Interface (AWS CLI) commands for these APIs.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.1.    Run the list-phone-numbers command. In the output, note the Id parameter. Replace a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 with your instance ID. Replace +xxxxxxxxxxx with the phone number that you want to migrate.$ aws connect list-phone-numbers --instance-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 --query 'PhoneNumberSummaryList[?PhoneNumber==`+xxxxxxxxxxx`]'[  {    "Id": "xyz80zxy-xyz1-80zx-zx80-11111EXAMPLE",    "Arn": "arn:aws:connect:us-west-2:123456789023:instance/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111/phone-number/xyz80zxy-xyz1-80zx-zx80-11111EXAMPLE",    "PhoneNumber": "+xxxxxxxxxxx",    "PhoneNumberType": "DID",    "PhoneNumberCountryCode": "US"  }]2.    To migrate the phone number, run the update-phone-number command. For PhoneNumberId, enter the Id you noted in the previous step. For TargetInstanceARN, enter the ARN of the instance that you want to migrate the phone number to.$ aws connect update-phone-number --phone-number-id [PhoneNumberId] --target-arn [TargetInstanceARN]To migrate multiple phone numbers, repeat the steps for each phone number that you want to migrate.The Amazon Connect instances are in different Regions or different AWS accountsIf source and destination Amazon Connect instances are located in different Regions, create an AWS Support case.If the source and destination Amazon Connect instances belong to different AWS accounts, create two AWS Support cases, one from each account.In your Support case or cases, include the following information:Source Amazon Connect instance ARNDestination Amazon Connect instance ARNThe phone number or numbers that you want to migrateA requested date and time for migrationDestination Contact flow ARN (If you want AWS to associate Amazon Contact flows with the migrated phone numbers in the destination Connect instance)Additional considerations to keep in mind for phone number migration:Your requested date and time for migration isn't guaranteed.There is 15 to 20 minutes downtime for each phone number migration.Before opening a support case, confirm that phone numbers you want to migrate aren’t specified as an outbound caller ID.If you're associating the Contact flow to a migrated phone number in destination Connect instance, confirm the Contact flow exists and is published in the destination Amazon Connect instanceDepending on phone number, migration might not be possible. You'll be contacted through your support case if this applies to your request.Follow"


Question: How do I install the rJDBC package in the R environment of my Amazon SageMaker notebook instance?

I want to install the rJDBC package in the R environment of my Amazon SageMaker notebook instance.

Answer: "I want to install the rJDBC package in the R environment of my Amazon SageMaker notebook instance.ResolutionTo install the rJDBC package in the R environment of your SageMaker notebook instance, do the following:1.    Open the SageMaker console.2.    In the navigation pane, choose Notebook, and then choose Notebook instances.3.    Choose the notebook instance where you want to install the rJDBC package.4.    Choose Open JupyterLab. Be sure that the notebook can connect to the internet. This connection is required so that you can download the rJDBC package from the Anaconda repository.5.    Open a new terminal and run the following commands in the given sequence:source activate Rconda install -y -c r r-rjdbcconda deactivate6.    Open a new Jupyter notebook with the R kernel.7.    Run the following command in a cell:dyn.load('/home/ec2-user/anaconda3/envs/R/lib/jvm/lib/server/libjvm.so')8.    To confirm that the rJDBC package is installed, run the following command in the Jupyter notebook:library(RJDBC)The output must look similar to the following:Loading required package: DBILoading required package: rJavaRelated informationAccess notebook instancesInstall external libraries and kernels in notebook instancesFollow"


Question: What factors should I consider when I perform a major version upgrade in Amazon RDS for Oracle?

I have an Amazon Relational Database Service (Amazon RDS) DB instance running Oracle. I want to know the factors that I must consider when I perform a major version upgrade.

Answer: "I have an Amazon Relational Database Service (Amazon RDS) DB instance running Oracle. I want to know the factors that I must consider when I perform a major version upgrade.Short descriptionWhen Amazon RDS starts to support a new version of the Oracle database, you can upgrade your existing Oracle database version by choosing a higher version and then performing a major version upgrade. A major version might include updates, new features, security fixes, optimizer enhancements, and performance improvements. It's a best practice to test your application's functionality, compatibility, and performance against the new version of the Oracle database in non-production environments before upgrading your production database.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.ResolutionBefore the upgradeHere are a few things to keep in mind before performing the major version upgrade:Upgrade Path: Verify the supported upgrade path from your current Oracle database version to the intended major version of Oracle database. You can check the valid upgrade paths by running the following AWS Command Line Interface (AWS CLI) command.For Windows:aws rds describe-db-engine-versions --engine engine-edition --engine-version current-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion"For Linux, macOS, or Unix:aws rds describe-db-engine-versions --engine engine-edition --engine-version current-engine-version --query 'DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion'Be sure to replace the following values in the preceding commands:engine-edition with the edition of the database engine.current-engine-version with the current version of the database engine.Suppose that you have an Amazon RDS for Oracle 12.1.0.2.v10 instance. To learn about all the valid major versions that you can upgrade your RDS for Oracle instances to, run the following command.For Windows:aws rds describe-db-engine-versions --engine oracle-ee --engine-version 12.1.0.2.v10 --query "DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion"For Linux, macOS, or Unix:aws rds describe-db-engine-versions --engine oracle-ee --engine-version 12.1.0.2.v10 --query 'DBEngineVersions[*].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion'Instance class: Verify that your current instance class is supported for the major version you are going to upgrade. For information on the instance classes that are supported by RDS for Oracle, see Supported Oracle DB instance classes. You can also check the supported instance class by running the following AWS CLI command.For Windows:aws rds describe-orderable-db-instance-options --engine engine-edition --engine-version new-engine-version --region example-region --query "OrderableDBInstanceOptions[*].DBInstanceClass"For Linux, macOS, or Unix:aws rds describe-orderable-db-instance-options --engine engine-edition --engine-version new-engine-version --region example-region --query 'OrderableDBInstanceOptions[*].DBInstanceClass'Be sure to replace the following values in the preceding commands:engine-edition with the edition of the database engine.new-engine-version with the new version that you plan to upgrade to.example-region with the Region that you are using.For example, suppose that you want to upgrade to an RDS for Oracle 12.2.0.1.ru-2020-10.r1 instance. To learn about the instance classes that support the major version in a specific Region, run the following command:aws rds describe-orderable-db-instance-options --engine oracle-ee --engine-version 12.2.0.1.ru-2020-10.rur-2020-10.r1 --region us-east-1 --query "OrderableDBInstanceOptions[*].DBInstanceClass"Be sure to replace us-east-1 in the command with the Region of your choice.Client compatibility: Verify that the Oracle client/driver versions are compatible with the new major version. Check if the drivers must be upgraded along with the major version upgrade. For information on interoperability, see Oracle documentation for Oracle Database Client and Oracle Database Interoperability.Upgrade method: You can perform the major version upgrade in either of the following ways:Modify the RDS instance and apply the new major version.Note: This method involves some downtime.Create a new RDS instance with the major version and migrate the data using AWS Data Migration Service (AWS DMS).Note: AWS DMS uses a minimalistic approach to migrate data and creates only those objects required to efficiently migrate the data. AWS DMS creates tables, primary keys, and in some cases unique indexes, but doesn't create any other objects that are not required to efficiently migrate the data from the source. For example, AWS DMS doesn't create secondary indexes, nonprimary key constraints, or data defaults. For more information, see High-level view of AWS DMS.Choose one of these methods to perform the upgrade based on your use case.Custom parameter group: If your instance has a custom parameter group, then create a new parameter group for the new major version and set the custom parameters appropriately. To identify the custom parameters that you currently use, compare the existing custom parameter group with the current version's default parameter group.Custom option group: If your instance has a custom option group, then create a new custom option group for the major version. If you have persistent or permanent options, such as time zone or Oracle Transparent Data Encryption, in your option group, then the same persistent or permanent options must be included in the new custom option group. To upgrade the time zone file version to the latest available version in the database instance along with your major version upgrade, add the TIMEZONE_FILE_AUTOUPGRADE option to the new custom option group.Dictionary statistics: Gathering dictionary statistics and fixed object statistics can reduce instance downtime during the upgrade. You can gather the statistics by running the following queries:SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;Invalid objects: Verify and make sure that your database doesn't contain invalid objects. You can do so by running the following query:SQL> SELECT OWNER, STATUS, COUNT (*) FROM DBA_OBJECTS GROUP BY OWNER, STATUS;If invalid objects are found, check which object is invalid by running the following query:SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS WHERE STATUS != 'VALID';You can compile all the invalid objects in the schema by running the following query:SQL> EXEC DBMS_UTILITY.compile_schema(schema => 'ADMIN', compile_all => false);Be sure to replace ADMIN in the query with the name of your schema.Audit trails: Be sure that the audit trails aren’t lengthy. Pre-upgrade checks and upgrades might take longer with lengthy audit trails. To truncate audit trails, see How do I truncate the sys.aud$ table on my Amazon RDS DB instance that is running Oracle? You can also use the DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedure to delete the audit trails.Passwords: Verify you are not using older version of passwords by running the following query:SQL> SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;From the query results, if you find that a user uses only the 10g version of passwords, check if the user can be recreated with a newer version of password. If you can't fix the user password version, then set the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter appropriately to avoid connection errors.When the parameter sqlnetora.sqlnet.allowed_logon_version_server is defined in an RDS for Oracle instance, the parameter denotes the minimum version of authentication protocol that's allowed when connecting to the database server. A setting of 8 permits most password versions and allows any combination of the DBA_USERS.PASSWORD_VERSIONS values 10G, 11G, and12C.When the parameter sqlnetora.sqlnet.allowed_logon_version_client is defined in an RDS for Oracle instance, the parameter denotes the minimum authentication protocol to be used when the database acts as the client.For more information, see Oracle documentation for Checking for accounts using case-insensitive password version.DBMS_JOB: The DBMS_JOB package is discontinued with the upgrade of Oracle database 12c Release 2. If you are upgrading to version 19c, it's a best practice to convert all DBMS_JOB jobs to DBMS_SCHEDULER jobs before the upgrade. During the upgrade, Oracle converts the DBMS_JOB jobs to DBMS_SCHEDULER jobs. For more information, see Oracle documentation for Support for DBMS_JOB. If you have a large number of DBMS_JOB entries, the upgrade might take longer.FreeStorageSpace: Verify that your instance is not nearing its storage capacity. Be sure that you have enough free storage space available for the upgrade to complete successfully by checking the FreeStorageSpace CloudWatch metric. For more information, see How can I create CloudWatch alarms to monitor the Amazon RDS free storage space and prevent storage full issues?Maintenance actions: Check if your instance has any pending maintenance actions in the Amazon RDS console. These actions are applied during the upgrade window. For Multi-AZ instances, if no operating system updates are required, then the primary and standby upgrades occur at the same time. If operating system updates are required, then Amazon RDS applies the upgrade as outlined in Oracle upgrades in a Multi-AZ deployment.Manual snapshot: Create a manual snapshot of your RDS for Oracle database instance for the following reasons:The snapshot can be used to roll back to the previous version, as long as the version is supported by Amazon RDS.An automated snapshot is usually created as part of the major version upgrade process. As Amazon Elastic Block Store (Amazon EBS) snapshots are incremental, the new snapshot has fewer changes to back up. Therefore, creating a manual snapshot might reduce the time taken to create the automated snapshot and the total time spent in completing the upgrade.Current configuration: Run the following query to view the current configuration of your instance and save the output. The output provides you with information on the option group, parameter group, security groups, and tags that are attached to the current RDS for Oracle instance. To rollback and perform a restore from snapshot or perform point-in-time recovery, use the information that you retrieve from this command:> aws rds describe-db-instances --db-instance-identifier example-instance-name --region example-regionBe sure to replace the following values in the query:example-instance-name with the name of your RDS for Oracle instance.example-region with the Region of your choice.Undo tablespace: Be sure that your Undo Tablespace is set to the right size to avoid resize operations during the upgrade.Triggers: Run the following query to list your logon, logoff, and startup triggers:SQL> SELECT OWNER, TRIGGER_NAME, TRIGGER_TYPE, TRIGGERING_EVENT, TABLE_OWNER, STATUS, ACTION_TYPE, TRIGGER_BODY FROM DBA_TRIGGERS WHERE TRIGGERING_EVENT LIKE '%LOGO%' or TRIGGERING_EVENT LIKE '%STARTUP%';Check if the triggers are valid and functional. Although the trigger is valid and compiles well, the trigger might throw an error at runtime and interfere with database reboots. Check if there are any logon, logoff, or startup triggers that throw an error when they run. You can deactivate these triggers by running the following queries:SQL> ALTER TRIGGER EXAMPLE-OWNER.EXAMPLE-TRIGGER DISABLE;Be sure to replace the following values in the query:EXAMPLE-OWNER with the name of the schema where you created the trigger.EXAMPLE-TRIGGER with the name of the trigger.For example:--To disable AUDIT_USERS trigger in MYADMIN schemaSQL> ALTER TRIGGER MYADMIN.AUDIT_USERS DISABLE;During the upgradeAfter you initiate the upgrade, you can monitor the progress of the upgrade by checking the following in the Amazon RDS console:Alert log located under the Logs & events tab of your instanceRecent events located under the Logs & events tab of your instanceAfter the upgradeRun the following queries to verify the patch version after connecting to the database:SQL> SELECT * FROM sys.registry$history;SQL> SELECT INSTALL_ID,PATCH_ID,ACTION,STATUS,ACTION_TIME,DESCRIPTION FROM DBA_REGISTRY_SQLPATCH;Amazon RDS updates the lsinventory-dbv.txt files within an hour of applying the patch. You can download this file from the Logs & events tab of your instance in the Amazon RDS console. Verify the applied patches by reading the Isinventory-dbv.txt file.Run the following queries to gather dictionary statistics and fixed object statistics:SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;Run the following query to verify that the number of valid and invalid objects match with those before the upgrade:SQL> SELECT OWNER, STATUS, COUNT(*) from DBA_OBJECTS GROUP BY OWNER, STATUS;Run the following query to compile all the invalid objects in the schema:SQL> EXEC DBMS_UTILITY.compile_schema(schema => 'ADMIN', compile_all => false);If you have query performance issues after the upgrade due to the optimizer features of the new major version, then consider using the OPTIMIZER_FEATURES_ENABLE parameter. You can alter this parameter at the session level and system level. For example, if you upgrade your database from release 18.1 to release 19.1, but you want to keep the release 18.1 optimizer behavior, then you can do so by setting the value of the OPTIMIZER_FEATURES_ENABLE parameter to 18.1.0.Related informationUpgrading the Oracle DB engineFollow"


Question: What is an Amazon EC2 Reserved Instance?

"What is an Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instance, and what benefits does it provide?"

Answer: "What is an Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instance, and what benefits does it provide?ResolutionAn Amazon Reserved Instance (RI) is a billing discount that allows you to save on your Amazon EC2 usage costs. When you purchase a Reserved Instance, you can set attributes such as instance type, platform, tenancy, Region, or Availability Zone (optional).Any existing or new On-Demand Instances matching the selected attributes are charged at the discounted Reserved Instance price. Reserved Instances act as an automatic discount on new or existing On-Demand Instances in your account.Note: Because a Reserved Instance is a billing discount, it doesn't affect the running of any existing instances.Receiving RI discountsThe Reserved Instance doesn't provide a discount until you launch an instance with the required specifications.You receive discounts or capacity reservations depending on the RI that you choose:Regional Reserved Instances provide a pricing discount that helps you save money. Regional RIs apply a discount to On-Demand Instances you run in a particular Region.Zonal Reserved Instances allow you to create a capacity reservation for an instance type within a specific Availability Zone. Zonal RIs also provide substantial discounts over On-Demand Pricing.For more information on the differences between zonal and Regional Reserved Instances, see Regional and zonal Reserved Instances (scope).Size of RI discountsThe size of the discount that you receive depends on whether you're using a standard RI or a convertible RI:Standard RIs provide the largest discount for a specific instance type over a long-term contract.Convertible RIs provide a smaller discount, but let you change the instance type during the contract.For more information on Standard and Convertible Reserved Instances, see Types of Reserved Instances (offering classes).Purchasing an RIIf you are considering purchasing a RI, see What should I consider before purchasing an Amazon EC2 Reserved Instance?Related informationCan I use AWS promotional credits to purchase Reserved Instances?Follow"


Question: How can I provide cross-account access to objects that are in Amazon S3 buckets?

I want to grant another AWS account access to an object that is stored in an Amazon Simple Storage Service (Amazon S3) bucket. How can I provide cross-account access to Amazon S3 buckets?

Answer: "I want to grant another AWS account access to an object that is stored in an Amazon Simple Storage Service (Amazon S3) bucket. How can I provide cross-account access to Amazon S3 buckets?Short descriptionIn Amazon S3, you can grant users in another AWS account (Account B) granular cross-account access to objects owned by your account (Account A).Depending on the type of access that you want to provide, use one of the following solutions to grant cross-account access to objects:AWS Identity and Access Management (IAM) policies and resource-based bucket policies for programmatic-only access to S3 bucket objectsIAM policies and resource-based Access Control Lists (ACLs) for programmatic-only access to S3 bucket objectsNote: When the Bucket owner enforced setting is enabled, all bucket and object ACLs are disabled. Therefore, you can't use ACLs to grant cross-account access. By default, all newly created buckets have the Bucket owner enforced setting enabled. It's also a best practice to use IAM policies and bucket policies (instead of ACLs) to manage cross-account access to buckets and objects. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.Cross-account IAM roles for programmatic and console access to S3 bucket objectsIf the requester is an IAM principal, then the AWS account that owns the principal must grant the S3 permissions through an IAM policy. Based on your specific use case, the bucket owner must also grant permissions through a bucket policy or ACL. After access is granted, programmatic access of cross account buckets is the same as accessing same account buckets.ResolutionIAM policies and resource-based bucket policiesNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Use resource-based bucket policies to manage cross-account access control and audit the S3 object's permissions. If you apply a bucket policy at the bucket level, you can define the following:Who can access the objects inside the bucket (using the Principal element)Which objects they can access (using the Resource element)How they can access the objects inside the bucket (using the Action element)Applying a bucket policy at the bucket level allows you to define granular access to different objects inside the bucket. You can also review the bucket policy to see who can access objects in an S3 bucket.To use bucket policies to manage S3 bucket access, follow these steps:Note: Replace Account variables with your account.1.    Create an S3 bucket in Account A.2.    Create an IAM role or user in Account B.3.    Give the IAM role in Account B permission to download (GET Object) and upload (PUT Object) objects to and from a specific bucket. Use the following IAM policy to also grant the IAM role in Account B permissions to call PutObjectAcl, granting object permissions to the bucket owner:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": [                "s3:GetObject",                "s3:PutObject",                "s3:PutObjectAcl"            ],            "Resource": "arn:aws:s3:::AccountABucketName/*"        }    ]}Note: Make sure to update the policy to include your user variables (such as account ID, bucket name, and ARN). Also, you can limit access to a specific bucket folder in Account A. To limit access to a specific bucket folder, define the folder name in the resource element, such as "arn:aws:s3:::AccountABucketName/FolderName/*". For more information, see How can I use IAM policies to grant user-specific access to specific folders?You can also create an IAM identity-based policy using the AWS CLI command example create-policy.4.    Configure the bucket policy for Account A to grant permissions to the IAM role or user that you created in Account B. Use this bucket policy to grant a user the permissions to GetObject and PutObject for objects in a bucket owned by Account A:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Principal": {                "AWS": "arn:aws:iam::AccountB:user/AccountBUserName"            },            "Action": [                "s3:GetObject",                "s3:PutObject",                "s3:PutObjectAcl"            ],            "Resource": [                "arn:aws:s3:::AccountABucketName/*"            ]        }    ]}You can also create an Amazon S3 bucket policy using the AWS CLI command example put-bucket-policy.Note: You can define a specific S3 bucket folder in the resource element to provide more limited access, such as "Resource": "arn:aws:s3:::AccountABucketName/FolderName/*". By using the s3:PutObject permission with a condition, the bucket owner gets full control over the objects uploaded by other accounts. Enforcing the ACL with specific headers are then passed in the PutObject API call. For more information, see Granting s3:PutObject permission with a condition requiring the bucket owner to get full control.IAM policies and resource-based ACLsIf ACLs meet your needs better than IAM and S3 bucket policies, then use object ACLs to manage permissions for specific scenarios. For more information, see When to use an ACL-based access policy (bucket and object ACLs). Amazon S3 ACLs allow users to define only the following permissions sets: READ, WRITE, READ_ACP, WRITE_ACP, and FULL_CONTROL. You can use only an AWS account or one of the predefined Amazon S3 groups as a grantee for the Amazon S3 ACL. When specifying email address or the canonical user ID for an AWS account, the ACL applies to all entities in the grantee AWS account. For example, you can't use an ACL to restrict access to individual IAM users or roles. You also can't apply ACLs to different objects that share the same prefixes.Note: The bucket owner might not have full control over the objects uploaded by the ACL grantee. This is because the ACL doesn't support the condition for the S3 operation that the ACL authorizes.To use bucket and object ACLs to manage S3 bucket access, follow these steps:1.    Create an IAM role or user in Account B. Then, grant that role or user permissions to perform the required Amazon S3 operations. Users who call PutObject and GetObject need the permissions listed in the Resource-based policies and IAM policies section.2.    Configure the bucket ACL to include at least WRITE permission for Account B. This makes sure that Account B IAM roles or users can upload objects (call PutObject API) to a bucket owned by Account A:...<AccessControlPolicy>  <Owner>    <ID> AccountACanonicalUserID </ID>    <DisplayName> AccountADisplayName </DisplayName>  </Owner>  <AccessControlList>...    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">        <ID> AccountBCanonicalUserID </ID>        <DisplayName> AccountBDisplayName </DisplayName>      </Grantee>      <Permission> WRITE </Permission>    </Grant>    ...  </AccessControlList></AccessControlPolicy>Note: To find your CanonicalUserID, see Finding an AWS account canonical user ID.3.    Configure object ACLs to include at least READ permission for Account B. This makes sure that IAM roles or users in Account B can download an object (call GetObject API) from a bucket owned by Account A:...<AccessControlPolicy>  <Owner>    <ID> AccountACanonicalUserID </ID>    <DisplayName> AccountADisplayName </DisplayName>  </Owner>  <AccessControlList>...    <Grant>      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">        <ID> AccountBCanonicalUserID </ID>        <DisplayName> AccountBDisplayName </DisplayName>      </Grantee>      <Permission> READ </Permission>    </Grant>    ...  </AccessControlList></AccessControlPolicy>ACL permissions vary based on which S3 resource, bucket, or object that an ACL is applied to. For more information, see Access control list (ACL) overview. You can configure bucket and object ACLs when you create your bucket or when you upload an object to an existing bucket. For more information, see Managing ACLs.Cross-account IAM rolesNot all AWS services support resource-based policies. Therefore, you can use cross-account IAM roles to centralize permission management when providing cross-account access to multiple services. Using cross-account IAM roles simplifies provisioning cross-account access to S3 objects that are stored in multiple S3 buckets. As a result, you don't need to manage multiple policies for S3 buckets. This method allows cross-account access to objects owned or uploaded by another AWS account or AWS services. If you don't use cross-account IAM roles, then the object ACL must be modified. For more information, see How Amazon S3 authorizes a request for an object operation.To use cross-account IAM roles to manage S3 bucket access, follow these steps:1.    Create an IAM role in Account A. Then, grant the role permissions to perform required S3 operations. In the role's trust policy, grant a role or user from Account B permissions to assume the role in Account A:Note: IAM roles need a trust policy that defines which principals can assume the role and under which conditions. IAM roles can have multiple permissions policies (inline and attached) that define the permissions that a principal assuming the role is able to perform and on which resources.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::AccountB:user/AccountBUserName"      },      "Action": "sts:AssumeRole"    }  ]}You can also create a role with the trust policy using the AWS CLI command example create-role.The following access policy allows a user who assumed this role to download and upload objects programmatically and using the Amazon S3 console. For more information, see How can I use IAM policies to grant user-specific access to specific folders?Note: If only programmatic access is required, the first two statements in the following policy can be removed:{    "Version": "2012-10-17",    "Statement": [        {            "Action": [                "s3:ListAllMyBuckets"            ],            "Effect": "Allow",            "Resource": [                "arn:aws:s3:::*"            ]        },        {            "Action": [                "s3:ListBucket",                "s3:GetBucketLocation"            ],            "Effect": "Allow",            "Resource": "arn:aws:s3:::AccountABucketName"        },        {            "Effect": "Allow",            "Action": [                "s3:GetObject",                "s3:PutObject"            ],            "Resource": "arn:aws:s3:::AccountABucketName/*"        }    ]}You can also create an IAM identity-based policy using the AWS CLI command example create-policy.2.    Grant an IAM role or user in Account B permissions to assume the IAM role that you created in Account A.**Note:**The following example policy must be added as a permissions policy of the IAM user or role.{  "Version": "2012-10-17",  "Statement": {    "Effect": "Allow",    "Action": "sts:AssumeRole",    "Resource": "arn:aws:iam::AccountA:role/AccountARole"  }}You can also create an IAM identity-based policy using the AWS CLI command example create-policy.3.    From a role in Account B, assume the role in Account A so that IAM entities in Account B can perform the required S3 operations. For more information, see Switching to a role (Console).Note: By assuming an IAM role in Account A, the Amazon S3 operation is determined by the access policy. The IAM role is deemed as an API call made by a local IAM entity in Account A. A bucket policy or an ACL for cross-account access isn't required. For more information, see Amazon S3 actions.Related informationActions, resources, and condition keys for Amazon S3Bucket policy examplesAccess policy guidelinesSetting up for cross-account native backup and restore in Amazon RDS for Microsoft SQL ServerUser policy examplesFollow"


Question: Why can’t I create or delete Organization config rules?

"When I try to create or delete an AWS Config rule for AWS Organizations, I receive a CREATE_FAILED or DELETE_FAILED error. How can I troubleshoot issues with organization config rules?"

Answer: "When I try to create or delete an AWS Config rule for AWS Organizations, I receive a CREATE_FAILED or DELETE_FAILED error. How can I troubleshoot issues with organization config rules?ResolutionVarious issues can cause organization config rules to not work, including permissions, a member account in an inactive state, or missing configuration recorders.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent version of the AWS CLI.To resolve organization config rule errors, first run the following command to get member account rule failure and success status details. Then, replace your-rule-name with your organization config rule name. The command identifies the specific member accounts in which the rule failed.aws configservice get-organization-config-rule-detailed-status --organization-config-rule-name your-rule-nameReview the output ErrorCode and ErrorMessage, and then follow these troubleshooting steps:Run the following AWS CLI command or use the Organizations console to verify that the status of all member accounts is Active.aws organizations list-accounts --query 'Accounts[*].[Id, Status]' --output tableConfirm that AWS Config is set up for each member account. You can set up AWS Config manually for a specific member account using the console, the AWS CLI, or AWS CloudFormation. After AWS Config is set up for all member accounts, deploy the rule again.Open the AWS CloudTrail console, and then choose Event history from the navigation pane. To filter the logs, choose Event name from the dropdown list, and then enter PutOrganizationConfigRule or DeleteOrganizationConfigRule in the search field. Review the filtered log results for OrganizationAccessDeniedException  errors.Verify that you are calling the PutOrganizationConfigRule API or DeleteOrganizationConfigRule API from the Organizations management account or from a delegated administrator member account. Run the following command from the management account to identify the delegated administrator member account.aws organizations list-delegated-administrators --service-principal=config-multiaccountsetup.amazonaws.comIf you receive OrganizationAccessDeniedException errors, verify that you have the required permissions. The AWS Identity and Access Management (IAM) role for AWS Config must include PutConfigRule, PutOrganizationConfigRule, and DeleteOrganizationConfigRule permissions to create and delete organization config rules.If you receive ResourceInUseException errors, review the error message to identify the cause. If the error message indicates that a remediation action is associated with the rule, then resolve the remediation action. If the error message indicates that the rule status isn't CREATE_SUCCESSFUL, then verify that the AWS Config member account IAM role includes DeleteConfigRule permissions.Custom organization config rule creationIf the Lambda function resource policy doesn't allow the AWS Config service principal to invoke it, provide permissions by running the add-permission command as follows. Replace function-name with the Lambda function name, Region with your AWS Region, and source-account with the management account ID.aws lambda add-permission --function-name --region --action "lambda:InvokeFunction" --principal config.amazonaws.com --source-account --statement-id AllowNote: To grant permissions for multiple member accounts in your organization, the command must be run for each account. Replace source-account with each member account ID.Related informationget-organization-config-rule-detailed-statuslist-accountslist-delegated-administratorsWhy isn't my AWS Config rule working?Follow"


Question: Why is my presigned URL for an Amazon S3 bucket expiring before the expiration time that I specified?

"I created a presigned URL for an Amazon Simple Storage Service (Amazon S3) bucket using a temporary token. However, the URL expired before the expiration time that I specified. Why did this happen? How can I create a presigned URL that's valid for a longer time?"

Answer: "I created a presigned URL for an Amazon Simple Storage Service (Amazon S3) bucket using a temporary token. However, the URL expired before the expiration time that I specified. Why did this happen? How can I create a presigned URL that's valid for a longer time?ResolutionIf you created a presigned URL using a temporary token, then the URL expires when the token expires. The URL expires even if the URL was created with a later expiration time.The credentials that you can use to create a presigned URL include:AWS Identity and Access Management (IAM) instance profile: Valid up to six hours.AWS Security Token Service (STS): Valid up to 36 hours when signed by an AWS Identity and Access Management (IAM) user, or valid up to one hour when signed by the root user.IAM user: Valid up to seven days when using AWS Signature Version 4.To create a presigned URL that's valid up to seven days, designate IAM user credentials (the access key and secret access key) to your SDK. Then, generate a presigned URL using AWS Signature Version 4. For examples, see Signature calculations in AWS Signature Version 4.When creating a presigned URL, keep the following points in mind:Services that assume a role, such as the AWS Lambda execution role, don't necessarily comply with the role's session duration settings.Because presigned URLs grant Amazon S3 bucket access to whoever has the URL, it's a best practice to protect them appropriately.If you created a presigned URL using a temporary token, then the URL expires when the token expires. This is true even if the URL was created with a later expiration time.To allow users access to the objects in your Amazon S3 bucket for longer than seven days, consider using one of these options:Amazon CloudFront signed URLs and cookiesAmazon CloudFront origin access identity (OAI)Web identity federation with Amazon CognitoRelated informationSharing objects using presigned URLsGetSessionTokenRetrieve security credentials from instance metadataAuthenticating requests: Using query parameters (AWS Signature Version 4)Boto 3 Docs: S3Follow"


Question: How do I increase the max connections of my Amazon RDS for MySQL or Amazon RDS for PostgreSQL instance?

I want to increase the max connections for my Amazon Relational Database Service (Amazon RDS) for MySQL or Amazon RDS for PostgreSQL DB instance.

Answer: "I want to increase the max connections for my Amazon Relational Database Service (Amazon RDS) for MySQL or Amazon RDS for PostgreSQL DB instance.ResolutionView the current max_connections valueIn Amazon RDS for MySQL, the max_connections metric monitors the set maximum number of (allowed) simultaneous client connections.By default, the max_connections parameter is based on the following formula in Amazon RDS for MySQL (calculated from the DBInstanceClassMemory value):max_connections = DBInstanceClassMemory/12582880To check the current value of max_connections, run the following command after connecting to your Amazon RDS for MySQL instance:SHOW GLOBAL VARIABLES LIKE 'max_connections';In Amazon RDS for PostgreSQL, the max_connections metric monitors the set maximum number of concurrent connections. By default, the max_connections parameter is based on the following formula in Amazon RDS for PostgreSQL (calculated from the DBInstanceClassMemory value):max_connections = LEAST({DBInstanceClassMemory/9531392}, 5000)To check the current value for max_connections, run the following command after connecting to your Amazon RDS for PostgreSQL instance:postgres=> show max_connections;The default value of max_connections for both RDS for MySQL and RDS for PostgreSQL depends on the instance class used by the Amazon RDS instance. A DB instance class with more available memory supports a larger number of database connections.Note that the default number of max_connections calculated using the formula might vary slightly from the number of default connections returned from the preceding command. This is because some of the memory out of the total DBInstanceClassMemory is reserved for the underlying OS operations. The preceding command considers only the memory that's reserved for the PostgreSQL engine and not for the underlying host OS.Review reasons for too many connectionsWhen the number of client connections exceeds the max_connections value, you get errors similar to the following:"Too many connections" error for an RDS for MySQL instance"FATAL: remaining connection slots are reserved for non replicate superuser connections" error for an RDS for PostgreSQL instanceThe following factors might cause your database connections to exceed the max_connections value:Increase in the number of client or application connections to the DB instance: This is caused by an increased workload or table/row-level locking.Improperly closing a client or application connection after the end of an operation: When a server connection isn't properly closed, the client application opens up a new connection. Over time, these new server connections can cause your instance to exceed the max_connections value. To list all active connections for your RDS for MySQL DB instance, run the following command:SHOW FULL PROCESSLISTTo view the connections for each database for your RDS for PostgreSQL instance, run the following command:SELECT datname, numbackends FROM pg_stat_database;Sleeping connections: Sleeping connections that are also known as inactive open connections are caused when you set higher values for connection timeout parameters, such as wait_timeout or interactive_timeout in MySQL. If you configure a connection limit that's very high, you might end up with higher memory usage even if those connections aren’t used. As a result, when the application server tries to open all client connections to the database, these connections might be refused. To terminate a sleeping connection in an RDS for MySQL DB instance, run the following command:CALL mysql.rds_kill(example-pid);Idle connections: You can view the idle connections in an RDS for PostgreSQL instance by running the following query. This query displays information about backend processes with one of the following states for more than 15 minutes: 'idle', 'idle in transaction', 'idle in transaction (aborted)' and 'disabled'.SELECT * FROM pg_stat_activityWHERE pid <> pg_backend_pid()AND state in ('idle', 'idle in transaction', 'idle in transaction (aborted)', 'disabled')AND state_change < current_timestamp - INTERVAL '15' MINUTE;To terminate an idle connection in an RDS for PostgreSQL instance, run the following command:SELECT pg_terminate_backend(example-pid)Tip: It's a best practice to configure only the active connections that are required for application performance. You might also consider upgrading to a larger Amazon RDS DB instance class.Increase the max_connections valueYou can increase the maximum number of connections to your RDS for MySQL or RDS for PostgresSQL DB instance using the following methods:Set a larger value for the max_connections parameter using a custom instance-level parameter group. Increasing the max_connections parameter doesn't cause any outage. Even though you can increase the value of max_connections beyond the default value, it's not a best practice. This is because, the instance might run into issues when workload increases and more memory is required. An increase in the number of connections can increase the memory usage. Instances running low on memory might crash. This is true especially for smaller instances. If you increase the max_connections value, be sure to monitor the usage of resources. Also, be sure to consult with your DBA about the increase. It's a best practice to keep the default value, or scale up to a larger instance class when more connections are required.If your DB instance is using a default parameter group, then change the parameter group to a custom parameter group. Be sure to associate the custom DB parameter group with your Amazon RDS instance and reboot the instance. After the new custom parameter group is associated with your DB instance, you can modify the max_connections parameter value. For more information, see How do I modify the values of an Amazon RDS DB parameter group?Note: Changing the parameter group can cause an outage. For more information, see Working with DB parameter groups.Scale your DB instance up to a DB instance class with more memory. Note that scaling up RDS instances impacts the account’s billing. To learn more, see DB instance billing for Amazon RDS.Warning: Downtime occurs when you modify an Amazon RDS DB instance.Follow best practices for configuring the max_connections parameterBe sure to consider the following best practices when working with the max_connections parameter for your DB instance:The default connection limits are tuned for systems that use the default values for other major memory consumers, such as the buffer pool. It's a best practice to scale up the instance class, instead of changing the instance class value. However, if your instances have a lot of free memory, then you can manually change this parameter. Before changing these settings for your DB Instance, consider adjusting the connection limit to account for the increase or decrease in available memory on the DB instances.Set the max_connections value to slightly higher than the maximum number of connections that you expect to open on each DB instance.For an RDS for MySQL instance, if you activated Performance Schema, then pay close attention to the max_connections parameter setting. The Performance Schema memory structures are sized automatically based on server configuration variables. The higher you set the variable, the more memory Performance Schema uses. In extreme cases, this condition might lead to out-of-memory issues on smaller instance types, such as T2 and T3. If you're using Performance Schema, then it's a best practice to leave the max_connections setting at the default value. If you plan to significantly increase the max_connections value (to higher than the default value), then consider disabling Performance Schema.Note: If you activate Performance Insights for an Amazon RDS for MySQL DB instance, then Performance Schema is automatically activated.For an RDS for MySQL instance, when you tune the max_connections parameter, be sure to review the following MySQL connection-related parameters: wait_timeout: Number of seconds the server waits for activity on a non-interactive TCP/IP or Unix File connection before closing the connectioninteractive_timeout: Number of seconds the server waits for activity on an interactive connection before closing the connectionnet_read_timeout: Number of seconds to wait for more data from a TCP/IP connection before dropping the read activitynet_write_timeout: Number of seconds to wait on TCP/IP connections for a block to be written before dropping the write activitymax_execution_time: Execution timeout for SELECT statements, in millisecondsmax_connect_errors: A host is blocked from further connections if there are more than this number of interrupted connectionsmax_user_connections: Maximum number of simultaneous connections allowed to any given MySQL accountFor an RDS for PostgreSQL instance, when you tune the max_connections parameter, make sure to also review the following PostgreSQL connection-related parameters:idle_in_transaction_session_timeout: Terminates any session with an open transaction that has been idle for longer than the specified duration in milliseconds. This allows any locks held by that session to be released and the connection slot to be reused. Also, the tuples visible only to this transaction are vacuumed.tcp_keepalives_idle: Number of seconds of inactivity after which the operating system sends TCP keepalive message to the clienttcp_keepalives_interval: Number of seconds after which a TCP keepalive message that's not acknowledged by the client is transmitted againtcp_keepalives_count: Number of TCP keepalives that can be lost before the server's connection to the client is considered dead.Note: This article doesn't include recommended values for the listed parameters because these values vary based on your use case.Follow"


Question: Why doesn’t my Amazon SQS FIFO queue return all messages or messages in other message groups?

My Amazon Simple Queue Service (Amazon SQS) First-In-First-Out (FIFO) queue doesn’t return some messages when I call the ReceiveMessage API. Why doesn’t my SQS FIFO queue return all messages from a specific message group ID or from other message groups?

Answer: "My Amazon Simple Queue Service (Amazon SQS) First-In-First-Out (FIFO) queue doesn’t return some messages when I call the ReceiveMessage API. Why doesn’t my SQS FIFO queue return all messages from a specific message group ID or from other message groups?ResolutionFor FIFO queues, you can’t request to receive messages from a specific message group ID. When you specify a MaxNumberOfMessages parameter in the ReceiveMessage API call, SQS returns as many messages with the same message group ID as possible. Other consumers or other ReceiveMessage calls can then process messages with a different message group ID.For FIFO queues, when you receive a message belonging to a particular message group ID, note the following:You must delete or move messages in the current receive call before you can receive more messages from the same group ID.Note: Messages must be moved from inflight available state.You can’t receive messages in other message groups.A FIFO queue looks through the first 20,000 messages to determine available message group. If all message groups in the first 20,000 messages are blocked due to inflight messages, then messages from other groups beyond the first 20,000 won't return. For more information, see Avoid having a large backlog of messages with the same group ID.Example AA FIFO queue has a total of 20,001 messages. The first 20,000 messages belong to message group 1, and the last message belongs to message group 2. When you try to receive messages from the queue, you receive a message only from group 1. Any consecutive ReceiveMessage calls result in empty receives. This happens because FIFO looks through only the messages that belong to group 1, and that group is blocked by the current call.Example BA FIFO queue has a total of 20,000 messages. The first 19,999 messages belong to message group 1, and the last message belongs to message group 2. When you try to receive messages from the queue, the first ReceiveMessage call gets a message belonging to group 1. The second ReceiveMessage call gets a message belonging to group 2. Any additional ReceiveMessage calls result in empty receives since both groups are now blocked by the current calls.Related informationAmazon SQS FIFO (First-In-First-Out) queuesUsing the Amazon SQS message group IDFollow"


Question: Why do I see high storage consumption on my source PostgreSQL database when I run an AWS DMS CDC task?

I am running an AWS Database Migration Service (AWS DMS) change data capture (CDC) task and using a PostgreSQL database as the source. Why do I see high storage consumption on my source database when I run an AWS DMS CDC task?

Answer: "I am running an AWS Database Migration Service (AWS DMS) change data capture (CDC) task and using a PostgreSQL database as the source. Why do I see high storage consumption on my source database when I run an AWS DMS CDC task?Short descriptionWhen you use PostgreSQL as a source for a CDC task, AWS DMS uses logical replication slots, a PostgreSQL feature, to get changes from the source database. These slots represent a stream of operations that are replayed in the same order that they were made in the PostgreSQL source database.By design, logical replication slots retrain translation logs (WAL) that AWS DMS requires, even when they are not connected to the PostgreSQL source. So, WAL is removed from PostgreSQL only after AWS DMS confirms that it has fetched the changes that it needs from the replication slot. AWS DMS confirms that it has the necessary changes by advancing the restart_lsn of the replication slot.Causes of high storage consumption on a PostgreSQL sourceBecause of how PostgreSQL implements the logical replication slot feature, in some scenarios, storage volume issues can occur on the source database.The AWS DMS CDC task is stopped for a long time - This means that AWS DMS isn't connected to the source database, and it is not consuming changes from the replication slot on the source. This means that PostgreSQL continuously retains WAL without deleting older WAL that hasn't been read by AWS DMS. So, the storage on the source database eventually fills up.Heavy Workload - Heavy workloads that cause excessive WAL generation can also cause storage to become full on a PostgreSQL database when the logical replication slots are in use. This happens because the WAL is still retained by PostgreSQL if the log sequence numbers (LSNs) are required by the replication slot.Idle replication slots - Even if a table, schema, or database that AWS DMS is replicating changes from is inactive, the WAL being retained by the replication slot still contains information about that table, schema or database. This causes storage to fill up on the source, even if the tables have no transactions taking place on them.ResolutionCheck if replication slots are causing high disk space usage on the PostgreSQL sourceTo check if replication slots are the cause of high disk space usage in your PostgreSQL database, run the queries listed in Why did I receive a "No space left on device” or "DiskFull" error on Amazon RDS for PostgreSQL?Note: Many of these queries can be used on self-managed PostgreSQL installations.Turn on the WAL heartbeat featureTurn on the AWS DMS WAL heartbeat feature to help you avoid consuming storage on a PostgreSQL source database. This feature mimics a dummy transaction so that idle logical replication slots don't hold on to old WAL logs. This heartbeat keeps restart_lsn moving and prevents storage from filling up on the PostgreSQL source.To turn on the WAL heartbeat feature, add this extra connection attribute (ECA) to the PostgreSQL source endpoint:heartbeatEnable=Y;Optionally, specify these additional ECAs:heartbeatFrequency=frequency;heartbeatSchema=schemaname;heartbeatFrequency determines how often (in minutes) the heartbeat transaction is run on the PostgreSQL source. For example, if you set heartbeatFrequency to a value of 15, then AWS DMS runs the heartbeat transaction every 15 minutes on the source.heartbeatSchema specifies which database schema AWS DMS creates database objects in to generate the heartbeat transaction.Note: The heartbeat transaction runs on the source only if an AWS DMS task is running. If your AWS DMS tasks are stopped, then the WAL heartbeat feature has no effect.Limit the size of a slot in PostgreSQLYou can apply max_slot_wal_keep_size on the source database in PostgreSQL 13 and later. This sets the maximum amount of WAL that can be retained by replication slots.Note: The max_slot_wal_keep_size setting can help you avoid storage full issues on the PostgreSQL source. But, it can also cause WAL to be purged from the source before the AWS DMS CDC task can read its changes from the replication slot. So, the task fails.Related informationLogical decoding conceptsExtra connection attributes when using PostgreSQL as a DMS sourceWhy did I receive a "No space left on device” or "DiskFull" error on Amazon RDS for PostgreSQL?Follow"


Question: How do I create a simple resource record set in Amazon Route 53 using the AWS CLI?

I want to use the AWS Command Line Interface (AWS CLI) to create a simple resource record set in Amazon Route 53.

Answer: "I want to use the AWS Command Line Interface (AWS CLI) to create a simple resource record set in Amazon Route 53.ResolutionTo create, delete, or change (upsert) a resource record set, use a ChangeResourceRecordSets request to the Route 53 API.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Create a ChangeResourceRecordSets requestYou can perform the following actions with a ChangeResourceRecordSets request:CREATE: Creates a record set with a specified value in the hosted zone.DELETE: Deletes a record set with a specified value in the hosted zone.UPSERT: Creates a new record set with a specified value, or updates a record set with a specified value if that record set already exists.To create, delete, or change a simple A record set, modify the following example JSON file (sample.json). The request’s body includes a list of change items, known as a change batch:{            "Comment": "CREATE/DELETE/UPSERT a record ",            "Changes": [{            "Action": "CREATE",                        "ResourceRecordSet": {                                    "Name": "a.example.com",                                    "Type": "A",                                    "TTL": 300,                                 "ResourceRecords": [{ "Value": "4.4.4.4"}]}}]}To create a resource record set for your domain in the hosted zone, use the Route 53 API with the command change-resource-record-sets. The sample.json file specifies the values for record creation:$ aws route53 change-resource-record-sets --hosted-zone-id ZXXXXXXXXXX --change-batch file://sample.jsonA Status of PENDING returns with the unique ID:$ aws route53 change-resource-record-sets --hosted-zone-id ZXXXXXXXXXXX --change-batch file://sample.json{    "ChangeInfo": {        "Status": "PENDING",         "Comment": "optional comment about the changes in this change batch request",         "SubmittedAt": "2018-07-10T19:39:37.757Z",         "Id": "/change/C3QYC83OA0KX5K"    }}If you don't see this status with the ID, then there's an error in the JSON file.To check the status of the changes, use the API call get-change with the Id value from your change-resource-record-sets response:PENDING indicates that the changes in this request aren't yet propagated to all Route 53 DNS servers. This is the initial status of all change batch requests.INSYNC indicates that the changes are propagated to all Route 53 DNS servers.Here's a PENDING status before propagation:aws route53  get-change --id /change/C3QYC83OA0KX5K{    "ChangeInfo": {        "Status": "PENDING",         "Comment": "optional comment about the changes in this change batch request",         "SubmittedAt": "2018-07-10T19:39:37.757Z",         "Id": "/change/C3QYC83OA0KX5K"    }}Here's an INSYNC status after propagation:$ aws route53  get-change --id /change/C3QYC83OA0KX5K{    "ChangeInfo": {        "Status": "INSYNC",         "Comment": "optional comment about the changes in this change batch request",         "SubmittedAt": "2018-07-10T19:39:37.757Z",         "Id": "/change/C3QYC83OA0KX5K"    }Create concurrent requestsYou must use separate Action keys for each concurrent request. For example, you can't create an A record and an MX record in one request. Instead, you must create two record sets for the same domain name with the following format:{                "Comment": "CREATE/DELETE/UPDATE",                 "Changes": [ {                             "Action": "CREATE",                            "ResourceRecordSet": {                                "Name": "a.example.com",                                    "Type": "A",                                     "TTL": 300,                                  "ResourceRecords": [{"Value": "5.5.5.5"}]                            }},{                            "Action": "CREATE",                            "ResourceRecordSet": {                                 "Name": "a.example.com",                                 "Type": "MX",                                  "TTL": 300,                                  "ResourceRecords": [{"Value": "10 example.com"}]                           }}]}Related informationHow do I troubleshoot errors that I received while creating Route 53 resource record sets using the AWS CLI?Follow"


Question: How do I monitor and troubleshoot replication lags when using the read replica for an Amazon RDS for Oracle instance?

I want to monitor and troubleshoot replication lags when I use the read replica for my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.

Answer: "I want to monitor and troubleshoot replication lags when I use the read replica for my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.Short descriptionYou can configure the read replica for your RDS for Oracle instance using the Oracle Active Data Guard License. When you create a read replica for your instance, the primary and read replica instances operate in the Data Guard maximum performance mode. For more information, see Oracle documentation for Oracle Data Guard protection modes.You can use the read replica to offload the read operations from the primary instance. You can also promote the read replica as a standalone DB instance in the event of disaster recovery. For more information, see Promoting a read replica to be a standalone DB instance.Before configuring a read replica for your instance, be sure to check the limitations related to version and licensing. Also, review Miscellaneous requirements and restrictions for Oracle replicas.ResolutionKeep in mind the following when you use the read replica for your RDS for Oracle instance:Amazon RDS is a managed service. Therefore, the replication process is managed by an internal RDS_DATAGUARD user. This user is configured when you create a read replica instance.You can't stop the managed recovery process from the admin user account.You can't configure or modify the Oracle Data Guard Broker for RDS read replica.You can't delay the replication of data from a primary instance to a read replica instance.Modifications done to the option group propagate to the read replica instance. If the read replicas are configured in the same Region, then they are associated with the same option group. For more information, see Option requirements and restrictions for Oracle replicas.Monitor the replication lagYou might experience replication lag if the replica can't keep up with the primary instance. To monitor the replication lag in Amazon CloudWatch, view the Amazon RDS metric ReplicaLag. This metric shows the replication lag in milliseconds. For more information, see Monitoring read replication and Viewing Amazon RDS metrics and dimensions.To monitor and troubleshoot the replication lag in Active Data Guard, do the following:Run the following query to check the Data Guard lag metrics:sql > SELECT name,value,datum_time,time_computed FROM v$dataguard_stats;Run the following query to check whether there is an archive log gap between the primary and read replica instances:sql >  SELECT archived.thread# THREAD,max(archived.sequence#) PRIMARY,max(applied.sequence#) STANDBY,(max(archived.sequence#) - max(applied.sequence#)) GAP FROM v$archived_log archived,v$archived_log applied WHERE archived.thread#=applied.thread# AND applied.applied='YES' GROUP BY archived.thread#;Note: RDS for Oracle doesn't alert you when there is a replication lag. To send notifications whenever the read replica doesn't keep up with the primary instance, create a CloudWatch alarm for the RDS metric ReplicaLag.Troubleshoot the replication lagIf the primary instance is unavailable, check the current state of the instance using the Amazon RDS Console. Also, check if the instance is accessible from any SQL client. If the primary instance is unavailable (for example: the instance is in incompatible-parameters state), then the read replica can't keep up with the primary instance and falls behind. Check Amazon RDS events to find why the primary instance is unavailable. Then, fix the instance to make sure that it's accessible.If the primary instance is under a high CPU or memory overload, then a high transport lag might result. Monitor the CloudWatch metrics for the instance. Also, use Enhanced Monitoring to identify whether a particular process causes an unusual memory or CPU usage spike. For more information, see Viewing OS metrics in the RDS console. When the CPU/memory load reduces, the replica might keep up with the primary instance. If the overload is as expected on the instance, you can choose to scale up the instance class, IOPS, or throughput as needed.Monitor the alert.log files for the primary instance and read replica to identify alerts or ORA errors that might affect the transport or apply processes. For more information on accessing the alert log for RDS instances, see Oracle database log files. Resolve the identified errors to reduce the lag.When you resize or change the number of redo logs in the primary instance, the changes aren't replicated in the standby instance. To replicate these changes, you must recreate the standby instance. It's a best practice to update the redo log parameters before configuring the read replica. For more information, see Changing your logging configuration.Configuring the read replica instance with less compute or IOPS capacity compared to the primary instance might slow down the application of changes in the read replica, resulting in replication lag. Monitor the RDS metrics using CloudWatch to check for throttling in both instances. If the primary instance doesn't have any throttling and the read replica experiences throttling, identify the resource that's getting throttled. Then, scale up the storage or compute configuration as needed.Related informationWorking with read replicaWorking with Oracle replicas for Amazon RDSManaged disaster recovery and managed reader farm with Amazon RDS for Oracle using Oracle Active Data GuardFollow"


Question: How do I resolve the "Network Error communicating with endpoint" error in API Gateway?

I want to resolve the "Network Error communicating with endpoint" error in Amazon API Gateway.

Answer: "I want to resolve the "Network Error communicating with endpoint" error in Amazon API Gateway.Short descriptionIf the number of API requests is significantly greater than the number of errors that you receive, then you're likely experiencing transient network issues. To resolve these issues, follow the steps in the Resolve low-frequency network errors section.If you're frequently or continuously experiencing errors, then follow the steps in the Resolve high-frequency network errors sectionResolutionResolve low-frequency network errorsUse retries with exponential backoff for failed requests.To activate access logging, see setting up Amazon CloudWatch API logging. Then, view the API Gateway log events in the CloudWatch console. For debugging, analyze the context variables $context.integration.error, $context.integration.latency, and $context.integrationStatus.Resolve high-frequency network errorsSet up Amazon CloudWatch logging. Be sure to choose the Log full requests/responses data option. This option allows you to log full API requests and responses so that you can troubleshoot errors.Consider the following resolutions:If your load balancer has multiple target groups, then use cross-zone load balancing to reduce latency. You can reduce latency by distributing incoming traffic evenly across all activated Availability Zones and preventing requests from being routed to Availability Zones without targets.Confirm that there are registered healthy instances in all your activated Availability Zones that use a Network Load Balancer and Application Load Balancer.Note: Your load balancer is most effective when each activated Availability Zone has at least one registered target. Your Availability Zone must have at least one healthy instance per target group. This healthy instance must reach healthy status in a Network Load Balancer or Application Load Balancer.To avoid exceeding the integration timeout quota of API Gateway, confirm that your target group instances serve a response to the API within 29 seconds.Activate access logging on the Network Load Balancer and the Application Load Balancer only if you have a TLS listener.If you're using a Network Load Balancer, confirm the IP addresses that can reach the instance in your Amazon Elastic Compute Cloud (Amazon EC2) security groups. Your IPs must allow traffic either from all sources or from the private IP address of the Network Load Balancer.If you're using an Application Load Balancer, confirm that the security group for your Application Load Balancer allows traffic from all sources.Note: Target instances can restrict access to only the Application Load Balancer. For stricter security, you can limit access from API Gateway IP addresses reserved for the AWS Region where the API is located. To receive a notification whenever the IP range list changes, subscribe to AWS IP address range notifications.Activate Amazon Virtual Private Cloud (Amazon VPC) Flow Logs. Then, capture the traffic information going to and from network interfaces for the Network Load Balancer and Application Load Balancer.If a Network Load Balancer is attached to the Amazon VPC link, check the TCP_Target_Reset_Count metric. A spike in this metric indicates that the target instances might not be closing connections to the Network Load Balancer.Related informationHow do I troubleshoot issues when connecting to an API Gateway private API endpoint?Follow"


Question: Why is the classic resize of my Amazon Redshift cluster taking so long to complete?

"I initiated a classic resize, but I don't see it progressing in my Amazon Redshift cluster or it's taking too long. How do I obtain a better estimate of the downtime to complete a classic resize?"

Answer: "I initiated a classic resize, but I don't see it progressing in my Amazon Redshift cluster or it's taking too long. How do I obtain a better estimate of the downtime to complete a classic resize?ResolutionThe time required for your Amazon Redshift cluster to complete a classic resize might vary (from several hours to several days). The classic resize of your cluster can take longer for the following reasons:Read workload on the source clusterNumber and size of the tables being transferredTable definition and its skewNode configuration (number and type of nodes) used in the source and target clustersFor more information, see Details of resizing a cluster in Resizing clusters in Amazon Redshift.Reducing the downtime for a classic resizeTo reduce the time required for a classic resize, consider the following approaches:Monitor the status of your resize operation using the Amazon Redshift console. Choose the Status tab on the cluster details page. The Status tab shows you the average rate of transfer, elapsed time, and remaining time.Fix skewed tables and choose an appropriate distribution key. For more information, see Amazon Redshift engineering’s advanced table design playbook: distribution styles and distribution keys.Remove unused tables. To identify unused tables, run the unscanned table summary.sql script on the GitHub website.Note: The unscanned table summary shows only the recent history from the past few days. Use the SystemTablePersistence utility on the GitHub website to capture usage data over a longer period of time.Use elastic resize. Elastic resize adds or removes nodes on an existing Amazon Redshift cluster, automatically redistributing data to the new nodes. Because elastic resize does not create a new cluster, the downtime is significantly lower than the downtime for a classic resize. For more information about elastic resize, see Resizing clusters.For more information about optimizing your resize performance, see Top 10 performance tuning techniques for Amazon Redshift.Troubleshooting classic resizeIf your cluster has a status of "NONE" in the AWS Command Line Interface (AWS CLI), then the target cluster is still being provisioned. Wait until your target cluster is provisioned. After it has been copied over, the status changes to "IN_PROGRESS".Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.If you receive an error message about insufficient disk space, then it indicates that your data does not fit into the target cluster. Resize your Amazon Redshift cluster with more nodes, a different distribution style, or a different node type. For more information, see Resizing clusters in Amazon Redshift.To cancel a resize operation before it completes, choose Cancel resize from the cluster details in the Amazon Redshift console. Alternatively, you can use the cancel-resize command from the AWS CLI.Note: You won't be able to cancel the resize operation if it's in the final stage.Related informationHow do I resize an Amazon Redshift cluster?Why does a table in an Amazon Redshift cluster consume more or less disk storage space than expected?Follow"