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

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

Answer: "I want to use the Cost Explorer reports to understand the utilization of my Reserved Instances (RIs).ResolutionYou can use the RI utilization reports in Cost Explorer to do the following:View the combined usage of your purchased RIs in the chart by selecting up to ten leases at one time.View the utilization of individual RIs in the chart by selecting the RI from the table.View the utilization of your RIs as the percentage of purchased RI hours in the chart.View the number of RI hours used against the number of RI hours purchased in the table.Define a utilization threshold, known as a utilization target, and identify RIs that meet your utilization target and RIs that are underutilized.To define the utilization target, enter the preferred value for Utilization target (%), and select Show target line on chart. You can see the target utilization as a dotted line in the chart and as an RI utilization status bar in the table.RIs with a red status bar haven't used reservation hours.RIs with a yellow status bar are under your utilization target.RIs with a green status bar have met your utilization target.Instances with a gray bar aren't using reservations.Related informationRI utilization reportsHow do I use the Reserved Instance coverage report in Cost Explorer?How can I use Cost Explorer to analyze my spending and usage?Follow"


Question: Why does my Spark or Hive job on Amazon EMR fail with an HTTP 503 "Slow Down" AmazonS3Exception?

"My Apache Spark or Apache Hive job on Amazon EMR fails with an HTTP 503 "Slow Down" AmazonS3Exception similar to the following:java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; Request ID: 2E8B8866BFF00645; S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE=), S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE="

Answer: "My Apache Spark or Apache Hive job on Amazon EMR fails with an HTTP 503 "Slow Down" AmazonS3Exception similar to the following:java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; Request ID: 2E8B8866BFF00645; S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE=), S3 Extended Request ID: oGSeRdT4xSKtyZAcUe53LgUf1+I18dNXpL2+qZhFWhuciNOYpxX81bpFiTw2gum43GcOHR+UlJE=Short descriptionThis error occurs when the Amazon Simple Storage Service (Amazon S3) request rate for your application exceeds the typically sustained rates of over 5,000 requests per second, and Amazon S3 internally optimizes performance.To improve the success rate of your requests when accessing the S3 data using Amazon EMR, try the following approaches:Modify the retry strategy for S3 requests.Adjust the number of concurrent S3 requests.ResolutionTo help identify the issue with too many requests, it's a best practice to configure Amazon CloudWatch request metrics for the S3 bucket. You can determine the solution that best works for your use case based on these CloudWatch metrics.Configure CloudWatch request metricsTo monitor Amazon S3 requests, turn on CloudWatch request metrics for the bucket. Then, define a filter for the prefix. For a list of useful metrics to monitor, see Monitoring metrics with Amazon CloudWatch.Modify the retry strategy for S3 requestsBy default, EMRFS uses an exponential backoff strategy to retry requests to Amazon S3. The default EMRFS retry limit is 15. However, you can increase the retry limit on a new cluster, on a running cluster, or at application runtime.To increase the retry limit, change the value of fs.s3.maxRetries parameter. If you set a very high value for this parameter, then you might experience longer job duration. Try setting this parameter to a high value (for example, 20), monitor the duration overhead of the jobs, and then adjust this parameter based on your use case.For a new cluster, you can add a configuration object similar to the following when you launch the cluster:[  {    "Classification": "emrfs-site",    "Properties": {      "fs.s3.maxRetries": "20"    }  }]After the cluster is launched, Spark and Hive applications running on Amazon EMR use the new limit.To increase the retry limit on a running cluster, do the following:1.    Open the Amazon EMR console.2.    In the cluster list, choose the active cluster that you want to reconfigure under Name.3.    Open the cluster details page for the cluster and choose the Configurations tab.4.    In the Filter dropdown list, select the instance group that you want to reconfigure.5.    In Reconfigure dropdown list, choose Edit in table.6.    In the configuration classification table, choose Add configuration, and then enter the following:For Classification: emrfs-siteFor Property: fs.s3.maxRetriesFor Value: the new value for the retry limit (for example, 20)7.    Select Apply this configuration to all active instance groups.8.    Choose Save changes.After the configuration is deployed, Spark and Hive applications use the new limit.To increase the retry limit at runtime, use a Spark shell session similar to the following:spark> sc.hadoopConfiguration.set("fs.s3.maxRetries", "20")spark> val source_df = spark.read.csv("s3://awsexamplebucket/data/")spark> source_df.write.save("s3://awsexamplebucket2/output/")Here's an example of how to increase the retry limit at runtime for a Hive application:hive> set fs.s3.maxRetries=20;hive> select ....Adjust the number of concurrent S3 requestsIf you have multiple jobs (Spark, Apache Hive, or s-dist-cp) reading and writing to the same S3 prefix, then you can adjust the concurrency. Start with the most read/write heavy jobs and lower their concurrency to avoid excessive parallelism. If you configured cross-account access for Amazon S3, keep in mind that other accounts might also be submitting jobs to the same prefix.If you see errors when the job tries to write to the destination bucket, then reduce excessive write parallelism. For example, use Spark .coalesce() or .repartition() operations to reduce number of Spark output partitions before writing to Amazon S3. You can also reduce the number of cores per executor or reduce the number of executors.If you see errors when the job tries to read from the source bucket, then adjust the size of objects. You can aggregate smaller objects to larger ones so that the number of objects to be read by the job is reduced. Doing this makes your jobs to read datasets with fewer read requests. For example, use s3-dist-cp to merge a large number of small files into a smaller number of large files.Related informationBest practices design patterns: optimizing Amazon S3 performanceWhy does my Amazon EMR application fail with an HTTP 403 "Access Denied" AmazonS3Exception?Why does my Amazon EMR application fail with an HTTP 404 "Not Found" AmazonS3Exception?Follow"


Question: How do I build a Direct Connect LAG?

I want to build a AWS Direct Connect link aggregation group (LAG).

Answer: "I want to build a AWS Direct Connect link aggregation group (LAG).Short descriptionA LAG is a logical interface that uses the link aggregation control protocol (LACP) to aggregate multiple connections at a single Direct Connect endpoint. This aggregation allows you to treat the multiple connections as a single managed connection.All LAGs have an attribute that determines the minimum number of connections in the LAG required for the LAG to be operational. By default, new LAGs have this attribute set to 0. You can update your LAG to specify a different value. If the number of operational connections fall below your updating setting, then your LAG becomes non-operational. This attribute is also used to prevent over-utilization of the remaining connections.Before you build a LAG, make sure of the following:Your connection must be on the same AWS device (terminating at the same Direct Connect endpoint)All connections must use the same bandwidthThe overall connection limit for the AWS Region where you're creating the LAG can't be exceededAll connections must be dedicated and have speeds of 1 Gbps, 10 Gbps, 100 GbpsImportant: Connections that are associated to the LAG must be on the same device. AWS can't guarantee enough available ports on a given Direct Connect endpoint when you create a LAG or associate connections to a LAG. All connections in a LAG operate in Active/Active mode.ResolutionCreate a LAG by one of the following methods:Create a LAG with new connectionsCreate a LAG with existing connectionsCreate a LAG with new connections1.    Sign into the AWS Management Console and open the Direct Connect console.2.    In the navigation pane, choose LAGs.3.    Choose Create LAG.4.    Under Lag creation type, choose Request new connections, and provide the following information:Lag name: a name for your LAG.Location: the location of your LAG.Port speed: The port speed of your connections.Number of new connections: The number of new connections you're going to create. You can have a maximum of four connections for port speeds of 1G or 10G and two connections for a port speed of 100G.Note: Steps 5 and 6 are optional. If you don't want to configure MAC security settings or add or remove a tag, then skip to step 7.5.    (Optional) Configure MAC security for your connection. Under Additional Settings, select Request a MACsec capable port.Note: MACsec is only available on dedicated connections.6.    (Optional) Add or remove a tag as follows:To add a tag, choose Add tag, and then enter the key name for Key and enter the key value for Value.To remove a tag, choose Remove tag next to the tag.7.    Choose Create LAG.Note: Make sure you download the Letter of Authorization and Connecting Facility Assignment (LOA-CFA) for each new physical connection individually from the Direct Connect console.Create a LAG with existing connections1.    Sign into the AWS Management Console and open the Direct Connect console.2.    In the navigation pane, choose LAGs.3.    Choose Create LAG.4.    Under Lag creation type, choose Use existing connections, and provide the following information:Lag name: a name for your LAG.Existing connections: The Direct Connect connection that you're going to use for the LAG.(Optional) Number of new connections: The number of new connections you're going to create. You can have a maximum of four connections for port speeds of 1G or 10G and two connections for a port speed of 100G.Minimum links: The minimum number of connections that must be operational for the LAG to be operational. If you don't specify a value, then a default value of 0 is assigned.5.    (Optional) Add or remove a tag as follows:To add a tag, choose Add tag, and then enter the key name for Key and enter the key value for Value.To remove a tag, choose Remove tag next to the tag.6.    Choose Create LAG.Follow"


Question: Why is my Amazon DynamoDB maximum latency metric high when the average latency is normal?

"When I review the Amazon CloudWatch metrics for my Amazon DynamoDB workloads, the maximum latency metric is high. But, average latency is normal."

Answer: "When I review the Amazon CloudWatch metrics for my Amazon DynamoDB workloads, the maximum latency metric is high. But, average latency is normal.ResolutionWhen you analyze the CloudWatch metric SuccessfulRequestLatency, it's a best practice to check the average latency. Maximum latency doesn't give a picture of overall latency on your DynamoDB table. Instead, it shows the maximum time taken by a single request in that period. For example, if you have 100 requests on a DynamoDB table at one time, even if 99 requests take 10 ms and a single request takes 100 ms, then the maximum latency metric is 100 ms.DynamoDB is a mass-scaled distribution system, with thousands of nodes in the backend fleet. So, a DynamoDB table might have multiple partitions in the tablespace, and each partition has multiple copies in the backend fleet. When you make an API call to DynamoDB, the DynamoDB service endpoint receives your call, and then routes it to one of the back end nodes for processing. When the call is successfully processed, DyanamoDB routes the results back to your client.In most cases, the API call is successfully processed in a single attempt, and you observe small latency on the client side. But, sometimes the first attempt fails if the back end node is experiencing:A busy periodFailoverPartition splitConnectivity issuesIn cases like these, the first attempt fails within a timeout on the server side (5000 ms). Then, the server automatically retries the API call on another node, often multiple times. The server returns the result back to your client when the API call is successfully processed. When this happens, you observe elevated latency for that particular request.So, a high maximum latency metric is generally not a cause for concern. If the DynamoDB service observes a consistently high latency from one node, then the service automatically removes that component from the back end fleet. You might observe an elevated level of latency for a certain percentage of API calls when the previously mentioned localized failure occurs on the service side. This is reflected in a high level of maximum SuccessfulRequestLatency in the CloudWatch metrics for the related DynamoDB tables. For this reason, localized failures can increase your maximum latency, but you do not need to take any action to control this failure.But, you can configure your application to react quickly by failing fast with exponential backoff retry. This means that the new request hits the new node, and you get faster results. For more information, see Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.Related informationHow can I troubleshoot high latency on an Amazon DynamoDB table?Latency metrics loggingFollow"


Question: "Why is my EC2 instance slow, unresponsive, or inaccessible, but my CPU and memory consumption aren't high?"

"I'm having trouble connecting to an Amazon Elastic Compute Cloud (Amazon EC2) instance that has an Amazon Elastic Block Store (Amazon EBS) General Purpose SSD (gp2) root volume. The connection is slow or times out, even though CPU and memory aren't fully used."

Answer: "I'm having trouble connecting to an Amazon Elastic Compute Cloud (Amazon EC2) instance that has an Amazon Elastic Block Store (Amazon EBS) General Purpose SSD (gp2) root volume. The connection is slow or times out, even though CPU and memory aren't fully used.Short descriptionThere are many possible causes of slow or unresponsive EC2 instances when CPU and memory aren't fully used, including:Problems with an external service that your instance relies on.Disk thrashing.Network connectivity issues.This resolution discusses one common cause: depleted I/O burst credits on the gp2 root volume. In most Regions, gp2 is the default storage drive for root volumes. For more information, see Amazon EBS volume types.ResolutionCheck I/O burst credit balanceOpen the Amazon EC2 console.In the navigation pane, choose Instances, and then select the instance.On the Storage tab, choose the Volume ID of the root device.Choose the Monitoring tab for the EBS volume, and then find the Burst Balance metric. A burst balance of 0% means that all the burst credits are used and the volume can't burst above its baseline performance level.Use one of the following methods to resolve this problem.Estimate IOPS requirements, and then modify the volume to support the loadFind the root EBS volume's VolumeReadOps and VolumeWriteOps metrics in Amazon CloudWatch. For more information, see Searching for available metrics.Use the CloudWatch Sum statistic to get the peak levels of VolumeReadOps and VolumeWriteOps. Then, add the two numbers together. Example:VolumeReadOps = 737,000 VolumeWriteOps = 199,000Total = 936,000To estimate how many IOPS that you need, divide the total from the previous step by the number of seconds in the measurement period.Example:Measurement period = 5 minutes (300 seconds)936,000 / 300 = 3,120 IOPSBaseline performance for gp2 volumes scales linearly at 3 IOPS per GiB of volume size. This means that a volume with 3,120 IOPS must be scaled up to 1,040 GiB to improve performance (3,120 / 3 = 1,040).Or, change your volume from gp2 to Provisioned IOPS SSD (io1). With io1 volumes, you can specify how many IOPS you need without increasing the volume size. For more information about when to use io1 volumes, see Provisioned IOPS SSD volumes. For a cost comparison of gp2 and io1 volumes, see Amazon EBS pricing.Change how you distribute your workloadWhen you have multiple applications on an EC2 instance, those applications compete for the root EBS volume’s IOPS. As your workload grows over time, the IOPS demand increases. To improve performance on your instance, consider using additional non-root EBS volumes for your applications. Also, consider using the root volume for the operating system only.If you still have trouble connecting to your EC2 instance after modifying the volume size and the workload distribution, see Troubleshoot connecting to your instance.Related informationI/O characteristics and monitoringHow do I optimize the performance of my Amazon EBS Provisioned IOPS volumes?How are charges for Amazon EBS volumes calculated on my bill?Follow"


Question: How do I recreate a default subnet for my default Amazon VPC?

I deleted the default subnet for my default Amazon Virtual Private Cloud (Amazon VPC). How do I recreate a default subnet for my default Amazon VPC?

Answer: "I deleted the default subnet for my default Amazon Virtual Private Cloud (Amazon VPC). How do I recreate a default subnet for my default Amazon VPC?ResolutionYou can create a default subnet in any Availability Zone that doesn't have a default subnet. For more information, see Create a default subnet.Note: Default subnets can be created only in a default Amazon VPC. If you deleted your default Amazon VPC, you can create a new default Amazon VPC that contains a default subnet in each Availability Zone in the Region.Related informationDefault VPCsDelete your default subnets and default VPCWhat is Amazon VPC?Follow"


Question: How can I enable logs on an Aurora Serverless cluster so I can view and download the logs?

I want to audit database activity to meet compliance requirements for my Amazon Aurora Serverless v1 (Amazon Aurora Serverless version 1) clusters that run Amazon Aurora MySQL-Compatible Edition or Amazon Aurora PostgreSQL-Compatible Edition. Then I want to publish the logs to Amazon CloudWatch to view or download them. How can I do that?

Answer: "I want to audit database activity to meet compliance requirements for my Amazon Aurora Serverless v1 (Amazon Aurora Serverless version 1) clusters that run Amazon Aurora MySQL-Compatible Edition or Amazon Aurora PostgreSQL-Compatible Edition. Then I want to publish the logs to Amazon CloudWatch to view or download them. How can I do that?Short descriptionFor Aurora MySQL-Compatible DB clusters, you can enable the slow query log, general log, or audit logs. For Aurora PostgreSQL-Compatible DB clusters, you can control the level of logging by using the log_statement parameter.By design, Aurora Serverless V1 connects to a proxy fleet of DB instances that scales automatically. There isn't a direct DB instance to access and host the log files. This means that you can't view the logs directly from the Amazon Relational Database Service (Amazon RDS) console. However, you can view and download logs that are sent to the CloudWatch console.To enable Advanced Auditing, see How can I enable audit logging for my Amazon Aurora MySQL DB cluster and publish the logs to CloudWatch?ResolutionTo enable logs, first modify the cluster parameter groups for an Aurora Serverless V1 cluster. Aurora Serverless V1 then automatically uploads the logs to CloudWatch. For MySQL-compatible DB clusters, use an Aurora MySQL 5.6/5.7 cluster parameter group family based on your cluster version. For PostgreSQL-compatible DB clusters, use an Aurora PostgreSQL 10 cluster parameter group family.Enabling the logging for Aurora Serverless V1Note: If your DB cluster is already using a custom DB cluster parameter group, then skip steps 1 and 3 of this process.Create a custom DB cluster parameter group.Modify the DB cluster parameter group values. For MySQL-compatible clusters, the error log is enabled by default. To enable the slow query and general logs, modify the following parameters:general_log=1slow_query_log=1For PostgreSQL-compatible clusters, log_statement parameter controls which SQL statements are logged, and the default value is none. Modify the following parameter to log the query and error logs:log_statement=allTip: It's a best practice to set log_statement to all to log all statements when you debug issues in your DB instance. To log all data definition language (DDL) statements (such as CREATE, ALTER, and DROP), set the parameter value to ddl. To log all DDL and data modification language (DML) statements (such as INSERT, UPDATE, and DELETE), set the parameter value to mod.Modify your DB cluster to use the custom DB parameter group that you created in step 2.After you modify your DB cluster, Aurora Serverless V1 attempts to perform an automatic seamless scale to apply the parameter changes.Note: Aurora Serverless V1 uses the ForceApplyCapacityChange timeout action when applying this change. This means that that if your Aurora Serverless V1 DB cluster can't find a scaling point before timing out, connections might be dropped.Viewing the logs in CloudWatchBecause Aurora Serverless V1 automatically publishes these logs to CloudWatch, you can view and download the logs and view in the CloudWatch console:Open the CloudWatch console.Choose Log groups from the navigation pane.Select the appropriate log group from the list.For more information, see Monitoring log events in Amazon CloudWatch.Related informationHow do I publish logs for Amazon RDS or Aurora MySQL-Compatible instances to CloudWatch?Publishing Aurora MySQL-Compatible logs to Amazon CloudWatch LogsPublishing Aurora PostgreSQL-Compatible logs to Amazon CloudWatch LogsPublishing database logs to Amazon CloudWatch LogsFollow"


Question: How do I access orphaned resources of a deleted user in QuickSight?

"A user in my Amazon QuickSight account got deleted, and now I can't access the orphaned resources owned by the deleted user. How do I regain access?"

Answer: "A user in my Amazon QuickSight account got deleted, and now I can't access the orphaned resources owned by the deleted user. How do I regain access?Short descriptionTo restore access to a deleted user's orphaned resources in Amazon QuickSight, use the AWS Command Line Interface commands to identify the resources. Then, make another QuickSight user the owner of the resources.Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent AWS CLI version.ResolutionNote: In the following AWS CLI commands, where necessary replace:account_id with the deleted user's AWS account IDRegion with the AWS Region that you're inquicksight_user_arn with the ARN of the other QuickSight user (new resource owner)analysis_id with the ID of the orphaned analysisdashboard_id with the ID of the orphaned dashboarddataset_id with the ID of the orphaned datasetdata_source_id with the ID of the orphaned data sourceIdentify the IDs of the orphaned analyses1.    Use the list-analyses CLI command to identify the IDs of the orphaned analyses:aws quicksight list-analyses --aws-account-id account_id --region Region2.    Use the update-analysis-permissions CLI command to make another QuickSight user the owner of each analysis:aws quicksight update-analysis-permissions --aws-account-id account_id --analysis-id analysis_id --grant-permissions Principal=quicksight_user_arn,Actions=quicksight:RestoreAnalysis,quicksight:UpdateAnalysisPermissions,quicksight:DeleteAnalysis,quicksight:DescribeAnalysisPermissions,quicksight:QueryAnalysis,quicksight:DescribeAnalysis,quicksight:UpdateAnalysis --region RegionIdentify the IDs of the orphaned dashboards1.    Use the list-dashboards CLI command to identify the IDs of the orphaned dashboards:aws quicksight list-dashboards --aws-account-id account_id --region Region2.    Use the update-dashboard-permissions CLI command to make another QuickSight user the owner of each dashboard:aws quicksight update-dashboard-permissions --aws-account-id account_id --dashboard-id dashboard_id --grant-permissions Principal=quicksight_user_arn,Actions=quicksight:DescribeDashboard,quicksight:ListDashboardVersions,quicksight:UpdateDashboardPermissions,quicksight:QueryDashboard,quicksight:UpdateDashboard,quicksight:DeleteDashboard,quicksight:UpdateDashboardPublishedVersion,quicksight:DescribeDashboardPermissions --region RegionIdentify the orphaned datasets1.    Use the list-data-sets CLI command to identify the IDs of the orphaned datasets:aws quicksight list-data-sets --aws-account-id account_id --region Region2.    Use the update-data-set-permissions CLI command to make another QuickSight user the owner of each dataset:aws quicksight update-data-set-permissions --aws-account-id account_id --data-set-id dataset_id --grant-permissions Principal=quicksight_user_arn,Actions=quicksight:UpdateDataSetPermissions,quicksight:DescribeDataSet,quicksight:DescribeDataSetPermissions,quicksight:PassDataSet,quicksight:DescribeIngestion,quicksight:ListIngestions,quicksight:UpdateDataSet,quicksight:DeleteDataSet,quicksight:CreateIngestion,quicksight:CancelIngestion --region RegionIdentify the orphaned data sources1.    Use the list-data-sources CLI command to identify the IDs of the orphaned data sources:aws quicksight list-data-sources --aws-account-id account_id --region Region2.    Use the update-data-source-permissions CLI command to make another QuickSight user the owner of each data source:aws quicksight update-data-source-permissions --aws-account-id account_id --data-source-id data_source_id --grant-permissions Principal=quicksight_user_arn,Actions=quicksight:UpdateDataSourcePermissions,quicksight:DescribeDataSource,quicksight:DescribeDataSourcePermissions,quicksight:PassDataSource,quicksight:UpdateDataSource,quicksight:DeleteDataSource --region RegionRepeat the steps for each of the deleted user's resources.Follow"


Question: How can I resolve the "SYNTAX_ERROR: line 1:8: SELECT * not allowed in queries without FROM clause" error in Amazon Athena?

"When I run an Amazon Athena query, I get the error "SYNTAX_ERROR: line 1:8: SELECT * not allowed in queries without FROM clause"."

Answer: "When I run an Amazon Athena query, I get the error "SYNTAX_ERROR: line 1:8: SELECT * not allowed in queries without FROM clause".ResolutionCheck the table's permissionsIf the table is registered with AWS Lake Formation, then be sure that the user or role that's querying the table has SELECT permissions for the table. For more information, see Using Athena to query data registered with Lake Formation and Permissions example scenario.Check the table's classificationIf you created the table using the AWS Glue crawler, then be sure that the following are true:The table's classification isn't UNKNOWN.The table has defined columns.If the classification is UNKNOWN, then there's a problem with the table schema. Fix the schema and run the crawler again. For more information, see Adding classifiers to a crawler in AWS Glue.Related informationSHOW CREATE TABLEUsing AWS Glue jobs for ETL with AthenaFollow"


Question: How do I troubleshoot issues configuring authentication in my Application Load Balancer?

I receive an error when I configure authentication in my Application Load Balancer.

Answer: "I receive an error when I configure authentication in my Application Load Balancer.ResolutionMisconfigurations with the identity provider (IdP) or Application Load Balancer can cause errors when configuring authentication for the Application Load Balancer. Follow these steps to troubleshoot authentication errors.redirect_mismatchIf you're using Amazon Cognito, then set the callback URL to https://<domain>/oauth2/idpresponse. If you're using a different IdP, then set the redirect URI to https://<domain>/oauth2/idpresponse.Note: Replace <domain> with the domain used to access the Application Load Balancer.HTTP 401: UnauthorizedConfigure the following identically on your Application Load Balancer and IdP:IssuerAuthorization endpointToken endpointClient ID/Client SecretAlso, set Action on unauthenticated request to either Allow or Authenticate (client reattempt), based on your use case.HTTP 500: Internal Server ErrorComplete the following steps if you receive an "HTTP 500: Internal Server Error" error:Add an outbound rule to allow traffic to the IdP endpoints over HTTPS (port 443).Configure the network access control list rules on each Application Load Balancer subnet to allow traffic to and from the IdP endpoints.For egress rules, specify: Destination IP - Identity provider, Destination port -443 Allow.For ingress rules, specify: Source IP - Identity provider, Destination port 1024-65535 Allow.Configure the route table to include a route for the Application Load Balancer to access the IdP endpoints.For public Application Load Balancers and public endpoints, configure an internet gateway route for the route table.For private Application Load Balancers and private endpoints, configure a network address translation (NAT) gateway for the route table. Or, configure a NAT instance route for the IdP.For other scenarios, configure the route tables of the Application Load Balancer subnets with appropriate route entry to route connectivity to the IdP endpoints.Select a valid OAuth2 Grant type. Application Load Balancers support the Authorization code grant to obtain an access token. If an incorrect grant is configured at the IdP, then the Application Load Balancer generates an error.Additional HTTP error codesFor troubleshooting additional HTTP error codes generated by Application Load Balancers, see The load balancer generates an HTTP error.Related informationSimplify login with Application Load Balancer built-in authenticationAuthenticate users using an Application Load BalancerConfiguring a user pool app clientFollow"


Question: How do I integrate IAM Identity Center with an Amazon Cognito user pool?

I want to configure AWS IAM Identity Center (successor to AWS Single Sign-On) with a third-party identity provider (IdP) for my Amazon Cognito user pool.

Answer: "I want to configure AWS IAM Identity Center (successor to AWS Single Sign-On) with a third-party identity provider (IdP) for my Amazon Cognito user pool.Short descriptionAmazon Cognito user pools allow for signing in through third-party IdPs. Users can use IAM Identity Center to federate through the Security Assertion Markup Language version 2.0 (SAML 2.0) IdP. For more information, see How federated sign-in works in Amazon Cognito user pools.A user pool integrated with IAM Identity Center allows users to get user pool tokens from Amazon Cognito. For more information, see Using tokens with user pools.ResolutionTo integrate an Amazon Cognito user pool with IAM Identity Center, take the followings steps.Note: If you already have a user pool with an app client, then skip the following section.Create an Amazon Cognito user pool with an app client and domain name1.    Create a user pool.2.    Add an app client and set up the hosted web UI.3.    Add a domain name for your user pool.Note: If you already have a working IAM Identity Center environment, then skip the following section.Activate IAM Identity Center and add a user1.    Before activating IAM Identity Center, review the prerequisites and considerations.2.    Activate IAM Identity Center.3.    Choose your identity source and create a user.Configure a SAML application from the IAM Identity Center console1.    Open the IAM Identity Center console and then, from the navigation pane, choose Applications.2.    Choose Add application and Add custom SAML 2.0 application, and then choose Next.3.    On the Configure application page, enter a Display name and a Description.4.    Copy the URL of the IAM Identity Center SAML metadata file or choose the Download hyperlink. You use these resources in later steps to create an IdP in a user pool.5.    Under Application metadata, choose Manually type your metadata values. Then provide the following values.Important: Make sure to replace the domain-prefix, region, and userpool-id values with information that's specific to your environment.Application Assertion Consumer Service (ACS) URL: https://<domain-prefix>.auth.<region>.amazoncognito.com/saml2/idpresponse Application SAML audience: urn:amazon:cognito:sp:<userpool-id>6.    Choose Submit. Then, go to the Details page for the application that you added.7.    Select the Actions dropdown list and choose Edit attribute mappings. Then, provide the following attributes.User attribute in the application: subjectNote: subject is prefilled.Maps to this string value or user attribute in IAM Identity Center: ${user:subject}Format: PersistentUser attribute in the application: emailMaps to this string value or user attribute in IAM Identity Center: ${user:email} Format: BasicThe mapped attributes are sent to Amazon Cognito when signing in. Make sure that all your user pool's required attributes are mapped here. To learn more about attributes available for mapping, see Supported IAM Identity Center attributes.8.    Save your changes.9.    Choose the Assign Users button and then assign your user to the application.Configure IAM Identity Center as a SAML IdP in your user pool1.    Configure a SAML IdP in your user pool. Apply the following settings:Under Metadata document, provide the metadata URL or upload the file that you downloaded in step 4 of the previous section. For more information, see Integrating third-party SAML identity providers with Amazon Cognito user pools.Enter your SAML Provider name. For more information, see Choosing SAML identity provider names.(Optional) Enter any SAML Identifiers.2.    Configure a SAML provider attribute mapping. Apply the following settings:In the SAML attribute field, provide an email value that matches the user attribute value provided in step 7 of the previous section. In the User pool attribute field, select Email from the dropdown list.Note: Add any other attributes configured in IAM Identity Center in step 7 of the previous section.3.    Save your changes.Integrate the IdP with the user pool app client1.    Sign in to the new Amazon Cognito console.2.    Choose User Pools and select an appropriate user pool.3.    Choose the App integration tab and then choose App client list.4.    Select the appropriate app client.5.    From the Hosted UI section, choose Edit.6.    Select the appropriate IdP.7.    Save your changes.Test the setup1.    Launch a hosted UI or construct the login endpoint URL using the following naming pattern:https://example_domain_prefix.auth.example_region.amazoncognito.com/login?response_type=token&client_id=example_client_id&redirect_uri=example_redirect_urlFor example: https://my-user-pool.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=a1b2c3d4e5f6g7h8i9j0k1l2m3&redirect_uri=https://example.comFor OAuth 2.0 grant types, choose Authorization code grant so the login endpoint prompts Amazon Cognito to return authorization codes when users sign in. For OAuth 2.0 grant types, choose Implicit grant for Amazon Cognito to return access tokens when users sign in. Then, replace response_type=code with response_type=token in the URL.2.    Choose IAM IdC.If you're redirected to your app client's callback URL, then you're already logged in as user in your browser. The user pool tokens appear directly in the URL of the web browser's address bar.Note: To skip this step, create an Authorize endpoint URL with the following naming pattern:https://yourDomainPrefix.auth.region.amazoncognito.com/oauth2/authorize?response_type=token&identity_provider=samlProviderName&client_id=yourClientId&redirect_uri=redirectUrl&scope=allowedOauthScopes3.    Enter the user credentials and choose Login.4.    When you're redirected to the callback URL that includes a code or token from Amazon Cognito in the browser's address bar, the setup is complete.Note: Amazon Cognito supports only service provider (SP) initiated sign-ins. You must use the login endpoint or the authorize endpoint to test the setup. Starting an IdP-initiated sign in with the AWS access portal for IAM Identity Center doesn't work.Follow"


Question: How can I forward the host header with private integration for an API Gateway REST API?

I want to use the host header value for my Amazon API Gateway endpoint or custom domain. How can I forward the host header with private integration for an API Gateway REST API?

Answer: "I want to use the host header value for my Amazon API Gateway endpoint or custom domain. How can I forward the host header with private integration for an API Gateway REST API?Short descriptionAmazon API Gateway overwrites the host value that it receives in the original request to the integration endpoint. Amazon API Gateway assigns the host value depending on the integration request endpoint URL.To use the host header value of an API Gateway endpoint in the backend, use the custom header. You can use the custom header in the integration request that contains the value of the request host header.ResolutionCreate an API Gateway REST API1.    Open the API Gateway console.2.    Choose Create API.-or-(If this is your first time using API Gateway) A page that introduces you to the features of the service appears. In REST API, choose Build. When the Create Example API popup appears, choose OK.3.    For Choose an API type, in the REST API pane, choose Build.4.    In Create new API, choose New API.5.    In Settings, do the following:For API name, enter a name that describes your API's purpose. For example: ForwardHostHeader.(Optional) For Description, enter a short description of your API's purpose. for example, Forward host header for private integration.For Endpoint Type, choose either Regional, Edge optimized, or Private.6.    Choose Create API.Configure your API's method request and Integration request1.    Open the API Gateway console.2.    Follow the instructions to create an API with private integration using the API Gateway console.3.    In Method Request, add HTTP Request Headers as host.4.    In Integration Request, expand HTTP Headers, and choose Add header.5.    Enter a name for the custom header. For example, my_host.6.    In Mapped from, enter the method request. For example, method.request.header.host, and then choose the check mark icon.Deploy your API to a new stage1.    Open the API Gateway console.2.    Follow the instructions to Deploy a REST API to a stage. For more information, see Setting up a stage using the API Gateway console.3.    In the Stage Editor pane, copy the Invoke URL to your clipboard. You can use this URL to invoke your API.REST API invoke URL example:https://1a2bc3d456.execute-api.us-east-1.amazonaws.com/stage4.    If you use an Application Load Balancer for your backend, you can test this configuration by adding a rule. Choose "http header" as a condition and specify "my_host" as the same header and value as the API Gateway host value.5.    Paste the API Gateway URL into a browser window to invoke your API. The "my_host" header configuration in API Gateway forwards the API Gateway host value to the Application Load Balancer. The Application Load Balancer matches the condition set and then returns the response as configured.Related informationSet up request and response data mappings using the API Gateway consoleSet up an API using the API Gateway consoleAmazon API Gateway important notesHow do I integrate an API Gateway REST API with an Application Load Balancer?Follow"


Question: How do I troubleshoot consistent and intermittent DNS-related errors in AWS Lambda?

I see DNS-related errors in my AWS Lambda function when I attempt to reach a host.

Answer: "I see DNS-related errors in my AWS Lambda function when I attempt to reach a host.ResolutionDNS-related errors in AWS Lambda, like Temporary failure in name resolution, getaddrinfo, ENOTFOUND, and ETIMEDOUT, can be consistent or intermittent. The troubleshooting process for consistent errors is different from the intermittent error troubleshooting process.Troubleshooting consistent DNS-related errorsMisconfigured DNS servers, incorrect permissions, and network connectivity issues can cause consistent DNS-related errors. Take the following steps to troubleshoot consistent DNS-related errors:When you're accessing public resources with a virtual private cloud (VPC)-configured Lambda function, verify that the Lambda function has internet access.When you're accessing private resources, verify that the correct VPC and DNS servers are configured for the Lambda function.When you're using custom DHCP option sets for a VPC, verify the DNS query response through Amazon Route 53 Resolver Query Logs.Run your Amazon Elastic Compute Cloud (Amazon EC2) instance with the same network configuration as AWS Lambda. Then verify that you can resolve and reach the endpoint.Verify that the hostname is correct for ENOTFOUND errors.Try to access the target using an IP address instead of the hostname. This way, you can confirm whether the issue is caused by the hostname resolution or a missing endpoint route.Make sure that the Lambda function's security group and network access control list (network ACL) allow inbound traffic to the necessary ports and IP ranges.Troubleshooting intermittent DNS-related errorsNetwork congestion, high traffic, and other external factors can cause intermittent DNS-related errors. Take the following steps to troubleshoot intermittent DNS-related errors:Implement retries and exponential backoff for the Lambda function to handle intermittent DNS errors.Consider using runtime-specific DNS libraries that allows local caching of DNS queries. This helps in scenarios where your DNS servers reach the per-second packet limit. This can also happen with custom DNS servers.Make sure that the Lambda function has enough resources to perform its tasks.Monitor the Lambda errors in Amazon CloudWatch and then set up CloudWatch alarms based on the error messages to check for patterns.Related informationHow does DNS work and how do I troubleshoot partial or intermittent DNS failures?Follow"


Question: How do I use DynamoDB Accelerator (DAX) with AWS Lambda?

I want to use my Amazon DynamoDB Accelerator (DAX) cluster with my AWS Lambda function. How do I do that?

Answer: "I want to use my Amazon DynamoDB Accelerator (DAX) cluster with my AWS Lambda function. How do I do that?ResolutionAfter you create a DAX cluster, note the VPC ID, subnets, and security group launched with the DAX cluster. Keep this information available for reference. Then, follow the steps below to use your Lambda function with your DAX cluster.Create a Lambda function with access to your DAX cluster's VPC1.    Open the Lambda console. Then, open the Functions page.2.    Choose Create function, and then enter a Function name.3.    Choose the Runtime and Architecture under Basic information.4.    Expand Advanced settings. Then, check the box to the left of Enable VPC.5.    In the VPC dropdown list, choose the previously noted VPC. This is the VPC in which your DAX Cluster was launched.6.    In the Subnets dropdown list, choose the previously noted subnets. Select all that apply.7.    In the Security group dropdown list, choose the previously noted VPC security group. The console shows the inbound and outbound rules for that security group.Important: For the Lambda function to connect with the DAX Cluster, the Inbound rules for the security group must display TCP as the Protocol. Also, 8111 or 9111 must appear under Ports. 8111is for unencrypted clusters, and 9111 is for encrypted clusters.8.    Choose Create function.Configure an existing Lambda function to access your DAX cluster's VPC1.    Open the Lambda console. Then, open the Functions page.2.    Choose the function that you want to use with your DAX Cluster.3.    Choose Configuration from the ribbon, and then choose VPC. Choose Edit.4.    Follow steps 4 through 6 in the previous section, Create a Lambda function with access to your DAX cluster's VPC.5.    Choose Save.Test the connection from your Lambda function to your DAX clusterImportant: You must first prepare a deployment package because amazondax isn't available by default in Lambda. See the All versions section in Amazon DynamoDB Accelerator (DAX) to install amazon-dax-client.After you install amazon-dax-client, follow the steps in Deploy Python Lambda functions with .zip file archives to create a deployment package. Use the following Python code to create the package:import amazondaximport boto3def lambda_handler(event, context):    daxclient = amazondax.AmazonDaxClient(endpoint_url='<endpoint-from-your-cluster>')    print("Connected!!")In the deployment package, change the endpoint_url to the one found in your DAX cluster. To do this:1.    Open the DynamoDB console.2.    In the navigation pane, under DAX, choose Clusters.3.    Select the previously created DAX cluster, and then choose Overview.4.    Under General information, find Cluster endpoint. Copy the URL listed there.5.    Replace  in the Python code with your copied URL.    Upload the deployment package as a .zip file or through an S3 URL. Then, choose Test.   If your connection is successfully configured, then the Execution results display “Connected!!”Related informationConfiguring VPC access (console)Use DynamoDB Accelerator (DAX) from Lambda to increase performance while reducing costsDeveloping with the DynamoDB Accelerator (DAX) clientFollow"


Question: How do I check CloudWatch logs for errors when I import users into a user pool with an AWS Lambda trigger?

I want to check for errors that are reported when I import users into a user pool with a user migration AWS Lambda trigger.

Answer: "I want to check for errors that are reported when I import users into a user pool with a user migration AWS Lambda trigger.Short descriptionAmazon Cognito allows you to import users into an Amazon Cognito user pool with a user migration Lambda trigger. This import process receives metadata about users who try to sign in. Then, it returns user profile information from an external data source or another user pool.For information on common errors during the import process, see How do I troubleshoot common errors with importing process in Amazon Cognito?To check for common errors, do the following:Find the name of the Lambda trigger.Find the CloudWatch log group.Use CloudWatch log stream.ResolutionFind the name of the Lambda triggerUsing the older Amazon Cognito interfaceOpen the Amazon Cognito console.Choose Manage User Pools.Choose your user pool.In the navigation pane, choose Triggers under General settings.Find the User Migration section, and note the name of the Lambda function.Using the new Amazon Cognito interfaceOpen the Amazon Cognito console.Choose your user pool.Under the User pool properties tab, find the information for the Lambda triggers.Note the name of the Lambda function for Migrate user Lambda trigger found under the section Attached Lambda function.Using the Lambda consoleOpen the AWS Lambda console.Search for the Lambda trigger that you created for your import job.Lambda migration trigger name example:TestingMigrationFind the CloudWatch log groupOpen the CloudWatch console.Expand Logs in the navigation pane, and then select Log Groups.Use the Log Groups search bar functionality to look for the Lambda migration trigger name that you noted earlier.CloudWatch log group example:/aws/lambda/TestingMigrationOr, you can also use Lambda console directly to access the CloudWatch log groups.Using the Lambda consoleOpen the AWS Lambda console.Search for the Lambda trigger that you created for your import job.Under the Monitor tab, select View logs in CloudWatch.This automatically redirects you to the Amazon CloudWatch console for the Lambda trigger's CloudWatch logs.Find the CloudWatch log streamWhile still in CloudWatch, select the log group that you found for your user pool during the previous steps.Select the Log Streams tab, and find the log stream.Select the log stream to check the log events for the Lambda migration import error.CloudWatch log stream example:[Timestamp]    START RequestId: 801399c5-b60a-40b4-ae54-f7c51c29043c Version: $LATEST[Timestamp]    [ERROR] Runtime.UserCodeSyntaxError: Syntax error in module 'lambda_function': unexpected indent (lambda_function.py, line 31) Traceback (most recent call last):   File "/var.....[Timestamp]    END RequestId: 801399c5-b60a-40b4-ae54-f7c51c29043cNote: Based on this example, the error reported in CloudWatch log stream shows that there's an indentation issue in the code that's causing the Lambda trigger to fail.Related informationImporting users into user pools with a user migration Lambda triggerHow do I troubleshoot common errors with importing process in Amazon Cognito?Follow"


Question: How can I troubleshoot the "Runtime.InvalidEntrypoint" error for my Lambda function that's from a Docker image?

I received a "Runtime.InvalidEntrypoint" error when trying to create an AWS Lambda function from a Docker image.

Answer: "I received a "Runtime.InvalidEntrypoint" error when trying to create an AWS Lambda function from a Docker image.ResolutionWhen the entry in the Lambda function configuration is incorrect, you receive the "Runtime.InvalidEntrypoint". To resolve this issue, check the following configuration settings for your Lambda function.Verify that the ENTRYPOINT and CMD to your container image include the absolute path as the location and doesn't contain a symlink as the ENTRYPOINT. For more information, see Container: Error occurs on runtime InvalidEntrypoint.Make sure that the ENTRYPOINT is correct in the Lambda function's configuration. Also, the ENTRYPOINT must match the command in the container's Dockerfile that's used for the runtime.Verify that the container image is pushed to the correct Amazon Elastic Container Registry (Amazon ECR).Make sure that the Docker image's architecture and the Lambda function are same. Lambda supports arm64 and x86_64 instruction set architectures.When the Lambda deployment package doesn't have the correct security permissions, you receive a "permission denied" error along with the "Runtime.InvalidEntrypoint" error occurs. In Unix permissions symbolic notation (from Wikipedia), 644 is the correct permissions for all files within a Lambda deployment package. For folders within a deployment package, the correct permissions setting is 755. For more information, see How do I troubleshoot "permission denied" or "unable to import module" errors when uploading a Lambda deployment package?Related informationHow do I create a Lambda layer using a simulated Lambda environment with Docker?Troubleshoot container image issues in LambdaHow do I use container images with Lambda?Follow"


Question: How do I update all Amazon EMR nodes after the bootstrap phase?

I want to update all nodes on an Amazon EMR cluster after the BOOTSTRAPPING state is complete.

Answer: "I want to update all nodes on an Amazon EMR cluster after the BOOTSTRAPPING state is complete.Short descriptionThe bootstrap phase occurs before Amazon EMR installs and configures applications such as Apache Hadoop and Apache Spark. To make additional changes on all cluster nodes after Amazon EMR installs and configures the applications, run a bootstrap action that downloads and runs another script.Resolution1.    Create a bash script that specifies the changes that you want to make on all cluster nodes. Refer to the following examples.Example 1: This script waits for a configuration file ( /etc/hadoop/conf/hadoop-env.sh) to become available, and then performs additional work.#!/bin/bash## This is an example of script_b.sh#while [ ! -f /etc/hadoop/conf/hadoop-env.sh ]do  sleep 1done## Now the file is available, do your work here#exit 0Example 2: This script waits for the EMR cluster to enter the WAITING state before implementing additional customization. This allows the EMR cluster to finish installing and configuring Hadoop and other applications.#!/bin/bash## This is an example of script_b.sh## Wait for EMR provisioning to become successful.#while [[ $(sed '/localInstance {/{:1; /}/!{N; b1}; /nodeProvision/p}; d' /emr/instance-controller/lib/info/job-flow-state.txt | sed '/nodeProvisionCheckinRecord {/{:1; /}/!{N; b1}; /status/p}; d' | awk '/SUCCESSFUL/' | xargs) != "status: SUCCESSFUL" ]];do  sleep 1done## Now the EMR cluster is ready. Do your work here.#exit 02.    Launch an EMR cluster and add a bootstrap action similar to the following. This script downloads the script that you created in the previous step ( script_b.sh) and then runs it in the background.#!/bin/bashaws s3 cp s3://doc-example-bucket/script_b.sh .chmod +x script_b.shnohup ./script_b.sh &>/dev/null &Related informationUnderstanding the cluster lifecycleFollow"


Question: How can I create a private connection from Amazon QuickSight to an Amazon Redshift cluster or an Amazon RDS DB instance that's in a private subnet?

I want to create a private connection from Amazon QuickSight to an Amazon Redshift cluster or database instance in a private subnet. How can I do that?

Answer: "I want to create a private connection from Amazon QuickSight to an Amazon Redshift cluster or database instance in a private subnet. How can I do that?Short descriptionAmazon QuickSight supports Amazon Virtual Private Cloud (Amazon VPC) connections to AWS data sources. The Amazon VPC connection allows you to privately connect to an Amazon Redshift cluster or an Amazon Relational Database Service (Amazon RDS) instance.To create a private connection from QuickSight, you must provide a subnet and security group from a VPC in the same AWS Region. Then, create a private connection from QuickSight to the private subnet. After the private connection is established, you can allow traffic between the new security group and the Amazon Redshift cluster or DB instance security group.Note: The data source must be in the same account and Region that's used for QuickSight.ResolutionImportant: These steps apply to Amazon QuickSight Enterprise Edition. It's a best practice to upgrade to Amazon QuickSight Enterprise Edition to securely access data in private VPCs. For more information about Enterprise Edition pricing, see Amazon QuickSight pricing.1.    Identify the ID of the subnet QuickSight will use to establish a private connection to your datasource. You can either use an existing subnet in the same VPC with a route to the database instance or create a new subnet.2.    Create a new security group for QuickSight in the same VPC.3.    Add an inbound rule to the QuickSight security group that allows all communication from the Amazon Redshift cluster or RDS DB instance.For Type, choose All TCP.For Source, choose Custom, and then enter the ID of the security group used by your Amazon Redshift cluster or RDS DB instance.4.    Add an outbound rule to the QuickSight security group that allows all traffic to the Amazon Redshift cluster or RDS DB instance.For Type, choose Custom TCP Rule.For Port Range, enter the port used by the Amazon Redshift cluster or RDS DB instance. The default Amazon Redshift port is 5439. The default Amazon RDS port is 3306.For Destination, choose Custom, and then enter the ID of the security group used by your Amazon Redshift cluster or RDS DB instance.5.    In the Amazon Redshift cluster or RDS DB instance's security group, add an inbound rule. The inbound rule must allow all incoming traffic from the QuickSight security group that you created in Step 2.For Type, choose Custom TCP Rule.For Port Range, enter the port used by the Amazon Redshift cluster or RDS DB instance. The default Amazon Redshift port is 5439. The default Amazon RDS port is 3306.For Source, choose Custom, and then enter the QuickSight security group ID.6.    In the Amazon Redshift cluster or RDS DB instance's security group, add another outbound rule. This outbound rule must allow all traffic to the QuickSight security group that you created.For Type, choose All TCP.For Destination, choose Custom, and then enter the QuickSight security group ID.7.    Create a private connection from QuickSight to Amazon VPC.For VPC ID, select the VPC for your Amazon Redshift cluster or RDS DB instance.For Subnet ID, select the private subnet that you created in Step 1.For Security group ID, enter the QuickSight security group that you created.8.    Create a new dataset from the Amazon Redshift cluster or RDS DB instance.For Connection type, choose the VPC connection that you created in Step 5.Example security group configurationIn SG-123345678f (QuickSight security group):Inbound:Type             Protocol          Port Range         Source                  Description------------------------------------------------------------------------------------------------------------------All TCP           All              0 - 65535       sg-122887878f         Amazon RDS/Amazon Redshift security groupOutbound:Type              Protocol          Port Range           Source                  Description------------------------------------------------------------------------------------------------------------Custom TCP          TCP            5439 or 3306       sg-122887878f       Amazon RDS/Amazon Redshift security groupIn SG-122887878f (Amazon RDS or Amazon Redshift security group):Inbound:Type             Protocol          Port Range           Source                Description-----------------------------------------------------------------------------------------------------Custom TCP         TCP            5439 or 3306        sg-123345678f        QuickSight security groupOutbound:Type            Protocol          Port Range          Source                  Description-------------------------------------------------------------------------------------------------All TCP           TCP             0 - 65535           sg-123345678f        QuickSight security groupRelated informationConnecting to a VPC with Amazon QuickSightFollow"


Question: How do I create cron jobs on Amazon EC2 instances in Elastic Beanstalk environments?

I want to create a cron job that runs a custom script on all Amazon Elastic Compute Cloud (Amazon EC2) instances in an existing AWS Elastic Beanstalk environment.

Answer: "I want to create a cron job that runs a custom script on all Amazon Elastic Compute Cloud (Amazon EC2) instances in an existing AWS Elastic Beanstalk environment.Short descriptionYou can use Elastic Beanstalk configuration files, called .ebextensions, to create cron jobs that run on all Amazon EC2 instances in an Elastic Beanstalk environment. In the Elastic Beanstalk application zip file, create a directory named .ebextensions. The zip file contains configuration files that run when the application is deployed to Amazon EC2 instances.Note: The steps in the following resolution add a cron job that runs on all Amazon EC2 instances in an Elastic Beanstalk environment at the same time. If you have a periodic task to be run on only one instance, consider using the cron-leaderonly-linux.config file for web environments. If you're using a dedicated worker environment, consider using periodic tasks.ResolutionCreate or update your configuration fileThere are two keys in the cron-linux.config file: files and commands.The files key specifies the location of the myscript.sh file on Elastic Beanstalk instances and the required file permissions. The commands key specifies a list of commands to run on the instances.Download the cron-linux.config template from the AWS GitHub repository.--or--Create or update an existing configuration file based on the following example:files:    "/etc/cron.d/mycron":        mode: "000644"        owner: root        group: root        content: |            * * * * * root /usr/local/bin/myscript.sh    "/usr/local/bin/myscript.sh":        mode: "000755"        owner: root        group: root        content: |            #!/bin/bash            date > /tmp/date            # Your actual script content            exit 0commands:    remove_old_cron:        command: "rm -f /etc/cron.d/mycron.bak"Note: When you name your configuration file, consider that multiple configuration files in the .ebextensions directory are run in alphabetical order by file name. You can name your configuration file cron-linux.config.The cron-linux.config file creates a cron file named /etc/cron.d/mycron that is configured to run a script every minute. The myscript.sh script outputs the date and then exits when it runs. Every time the cron-linux.config is applied during deployments, a backup of the /etc/cron.d/mycron file is created, named /etc/cron.d/mycron.bak. The last command in cron-linux.config cleans up the /etc/cron.d directory by removing /etc/cron.d/mycron.bak.For more information about customizing your environment using .ebextensions, see Advanced environment customization with configuration files (.ebextensions).Create an application source bundleTo add the configuration file to the application source code of your web application, complete the following steps:1.    In the root of your application folder, create a directory named .ebextensions.2.    Move the cron-linux.config file that you created or updated to the .ebextensions folder.3.    Create a zip folder for your application files, including the new configuration file.The following example shows the structure of the .ebextensions directory and cron-linux.config file in the application zip file:|-- .ebextensions|        |-- cron-linux.config |        |-- other .config files|-- other application filesRelated informationConfiguring Elastic Beanstalk environmentsCustomizing software on Linux serversCustomizing software on Windows serversFollow"


Question: How can I find out which S3 buckets allow access from the internet?

I want to know which of my Amazon Simple Storage Service (Amazon S3) buckets are publicly accessible from the internet.

Answer: "I want to know which of my Amazon Simple Storage Service (Amazon S3) buckets are publicly accessible from the internet.ResolutionTo check whether S3 buckets are publicly accessible, use any of the following methods:Use the Amazon S3 console to configure public access settings.Use AWS Trusted Advisor to check Amazon S3 bucket permissions.Use Access Analyzer to set up alerts for buckets that are publicly accessible.If you have a large number of S3 buckets in your AWS account, then AWS Config can provide a more efficient method. AWS Config rules allow you to quickly identify which buckets allow public read or write access. Also, you can set up AWS Config to notify you if any S3 buckets become publicly accessible after your initial review.To create AWS Config rules that flag which S3 buckets are publicly accessible, follow these steps:Note: Before you use AWS Config to analyze your S3 buckets, be sure to set up AWS Config on your AWS account.Open the AWS Config console and set the Region selector to an AWS Region that supports AWS Config rules.Note: AWS Config performs the compliance check for buckets in the corresponding AWS Region. If you have buckets in multiple Regions, then set up AWS Config rules in each Region.In the navigation pane, choose Rules.Select + Add rule.In the search bar, enter s3-bucket-public-read-prohibited. Then, choose the s3-bucket-public-read-prohibited rule. This rule flags buckets that allow public read access as Noncompliant.Select Save.Choose + Add rule.In the search bar, enter s3-bucket-public-write-prohibited. Then, choose the s3-bucket-public-write-prohibited rule. This rule flags buckets that allow public write access as Noncompliant.Select Save.It might take several minutes for AWS Config to complete the evaluation of your S3 buckets based on the new rules. After the AWS Config evaluation is complete, open the Rules page from the AWS Config console. Then, open each rule to see which S3 buckets are flagged as noncompliant. Noncompliant buckets are those that allow either public write or read access from the internet.To set up notifications from AWS Config when an S3 bucket becomes noncompliant, see Notifications that AWS Config sends to an Amazon SNS topic.For more information on setting permissions for S3 buckets, see Identity and access management in Amazon S3.Related informationEvaluating resources with AWS Config rulesFollow"


Question: Why can't I connect to my Amazon RDS for Oracle database instance?

I can't connect to my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.

Answer: "I can't connect to my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.Short descriptionSome of the most common reasons why you can't connect to your Amazon RDS for Oracle DB instance include the following:You have incorrect configurations in your security group, network access control lists (ACLs), or local firewalls that might block traffic to the instance.Your instance isn't in the available state.You used incorrect user credentials.ResolutionUse the tnsping utility to check if the Oracle client can connect to the RDS for Oracle DB instance when these conditions are both true:You have an Oracle client installed.You added the database entry to the tnsnames.ora file on the client side.If the Oracle client can't connect to the DB instance, then check the following:If you're connecting from outside the VPC, be sure that the Publicly Accessible property of the DB instance is set to Yes. If this property is set to No, then the database isn't assigned a public IP address. Only Amazon Elastic Compute Cloud (Amazon EC2) instances and clients inside the Amazon Virtual Private Cloud (Amazon VPC) can connect to your database using the Amazon RDS private IP address. Additional configurations, such as VPC peering or AWS Direct Connect, must be configured for access from different VPCs or on-premises networks. If the Publicly Accessible property of the instance is set to Yes, then clients from outside the VPC that RDS is hosted in can connect to your DB instance through the internet using an internet gateway.Be sure that the security group for your RDS DB instance allows the appropriate incoming traffic to your database.Network ACLs act as a firewall for resources in a specific subnet in a VPC. If you use ACLs in your VPC, then be sure that they have rules that allow inbound and outbound traffic to and from your DB instance. By default, network ACLs allow all inbound and outbound traffic. If your network ACL is more restrictive, then you must explicitly allow traffic to the ephemeral port range.If the client connection is originated from the on-premises network, check with your network administrator to determine if your network allows traffic to and from the ports that the DB instance uses for inbound and outbound communication.Verify the network connection by running the following command. Be sure to replace the example-rds-endpoint and example-port-number values in the command with the RDS endpoint and port number.Note: Amazon RDS doesn't support internet control message protocol (ICMP) traffic, including ping.telnet example-rds-endpoint example-port-numberVerify that the DNS server configured on the client side resolves the DNS endpoint name of the RDS instance to the correct IP address using the NSLOOKUP command:nslookup  example-instance.example-accountcode.example-region.rds.amazonaws.comBe sure that your RDS for Oracle DB instance is in the available state. Database activities, such as version upgrade, instance class upgrade, or Multi-AZ failover might cause brief outages. The outages might change the database instance state and cause connection issues to the database.If the connection reaches the RDS for Oracle DB instance, but still fails, then be sure that the user credentials, such as the user name and password, used to connect to the database instance are accurate. You can reset the master user password, if required.Related informationTroubleshooting for Amazon RDS - Can't connect to Amazon RDS DB instanceFollow"


Question: How do I expand the Amazon EBS root volume of my Amazon EC2 Windows instance?

I ran out of space on my Amazon Elastic Compute Cloud (EC2) Windows instance. I want to dynamically expand the Amazon Elastic Block Store (Amazon EBS) volumes of my Windows instances.

Answer: "I ran out of space on my Amazon Elastic Compute Cloud (EC2) Windows instance. I want to dynamically expand the Amazon Elastic Block Store (Amazon EBS) volumes of my Windows instances.ResolutionAn Amazon EC2 Windows instance created from an Amazon Machine Image (AMI) has a default 30 GB gp2 (General Purpose SSD) Amazon EBS root volume. To expand the disk space of a Windows instance, follow these steps.Use the Amazon EC2 console or AWS Command Line Interface (AWS CLI) to expand the EBS volume that's attached to a Windows instance.Use Disk Management or PowerShell to extend the volume's file system at the operating system level.Expand the EBS volumeNote: By default, Windows root volumes are the master boot record (MBR). You can extend the volumes up to 2 TB.Using the earlier Amazon EC2 console1.    Open the Amazon EC2 console, and then choose Instances from the navigation pane.2.    Select the instance that you want to expand. From the Description tab, choose the Block devices name. Then, choose the EBS ID.3.    Select the volume. From Actions, choose Modify Volume.4.    In the Size field, enter the Size and IOPS based on the volume type.5.    Choose Modify, and then choose Yes. Refresh the console page. In the Description tab, the State shows the progress of Optimization for successful modification calls. After the volume enters the Optimizing state, proceed to the instructions for extending the volume's file system.Using the new Amazon EC2 console1.    Open the Amazon EC2 console, and then choose Instances from the navigation pane.2.    Select the instance. From the Storage tab, choose the EBS Volume ID.3.    Select the volume. From Actions, choose Modify Volume.4.    In the Size field, enter the Size and IOPS based on the volume type.5.    Choose Modify, and then choose Yes. Refresh the console page. In the Description tab, the State shows the progress of Optimization for successful modification calls. After the volume enters the Optimizing state, proceed to the instructions for extending the volume's file system.Using AWS CLINote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent AWS CLI version.Use the modify-volume AWS CLI command to expand the EBS volume. Run a command similar to the example command here. Replace RegionName, VolumeId, NewSize, NewType, and NewIops with your values: aws ec2 modify-volume --region RegionName --volume-id VolumeId --size NewSize --volume-type NewType --iops NewIopsNote: To view the progress of your task, run the following command:aws ec2 describe-volumes-modifications --volume VolumeId --region RegionNameExtend the volume space at the operating system levelUsing Disk Management1.    Use Remote Desktop Protocol (RDP) to connect to your EC2 Windows instance.2.    Open a command prompt, and then run the diskmgmt.msc command to launch Disk Management. From Action, choose Refresh.3.    Open the context (right-click) menu for the Volume, and then choose Extend Volume.4.    Choose Next, Next, Finish.Repeat these steps for any additional volumes.Using PowerShell1.    Use RDP to connect to your EC2 Windows instance.2.    Run PowerShell as an administrator.3.    Run the Get-Partition command. PowerShell returns the corresponding partition number for each partition, the drive letter, offset, size, and type. Note the drive letter of the partition to extend.4.    Run the following command to rescan the disk:"rescan" | diskpart5.    Use the drive letter from step 3 to run the following command. Replace the YourDriveLetter with your values. PowerShell returns the minimum and maximum size of the partition allowed, in bytes.Get-PartitionSupportedSize -DriveLetter YourDriveLetter6.    To extend the partition to a specified amount, use the following command, entering the new size of the volume in place of NewSize. You can enter the new size in KB, MB, or GB. For example, if the earlier size is 30 GB and you want to extend by 2 GB, then the value for the new size is 32 GB.Resize-Partition -DriveLetter YourDriveLetter -Size NewSize7.    To extend the partition to the maximum available size, run the following command:Resize-Partition -DriveLetter YourDriveLetter -Size $(Get-PartitionSupportedSize -DriveLetter YourDriveLetter).SizeMaxFor more information, see Extend a Windows file system using PowerShell.Note: Before extending a file system that contains valuable data, it's best practice to create a snapshot of the volume. Use the snapshot to roll back your changes as needed. For more information, see Create Amazon EBS snapshots.Follow"


Question: How can I determine whether my DNS queries to the Amazon-provided DNS server are failing due to VPC DNS throttling?

My DNS queries to the Amazon-provided DNS server are failing or timing out. Are the DNS queries from my instance failing because of VPC DNS throttling?

Answer: "My DNS queries to the Amazon-provided DNS server are failing or timing out. Are the DNS queries from my instance failing because of VPC DNS throttling?Short descriptionAmazon-provided DNS servers enforce a limit of 1024 packets per second per elastic network interface. Amazon provided DNS servers reject any traffic exceeding this limit.VPC Flow Logs don't capture the traffic your application sends to Amazon provided DNS servers. You can use packet captures or Traffic Mirroring to identify the cause of the DNS query failures.Note: Amazon Route 53 query logging captures only the traffic that reaches the VPC.2 resolver (AmazonProvidedDNS). However, DNS queries are throttled at the elastic network interface level. So, throttled queries don't appear in the query logging.ResolutionFirst, use one of the following methods to identify the source of DNS query failures. Then, if you determine that the cause is DNS throttling, use one of the following recommended fixes.Determine the source of the DNS query failuresOption 1: Use tcpdump (Linux only)1.    Use the following command to take rotating packet captures on your EC2 instance. The following command captures the initial 350 bytes of the packet and saves 20 files of 100 MB each while overwriting the old packet captures.sudo tcpdump -i eth0 -s 350 -C 100 -W 20 -w /var/tmp/$(curl http://169.254.169.254/latest/meta-data/instance-id).$(date +%Y-%m-%d:%H:%M:%S).pcap2.    Run the following Linux command to determine the number of DNS queries sent.tcpdump  -r <file_name.pcap> -nn dst port 53 | awk -F " " '{ print $1 }' | cut -d"." -f1 | uniq -c3.    If the number of DNS queries is greater than or equal to 1024 per second, any additional queries are throttled.Option 2: Use Traffic MirroringIf it's not feasible to take the tcpdump in your use case, then you can leverage Traffic Mirroring to identify whether DNS queries are throttled.Note: Traffic Mirroring is available for Nitro-based instances and non-Nitro instance types. Traffic Mirroring charges apply.First, capture traffic data:1.    Complete the Traffic Mirroring prerequisites.2.    Create a traffic mirror target. Confirm that the target elastic network interface or Network Load Balancer allows inbound traffic on port UDP 4789.3.    Create a traffic mirror filter. For Filter settings, confirm that amazon-dns is enabled for Network services - optional.4.    Create a traffic mirror session. After you configure Traffic Mirroring, mirrored traffic is gathered and stored on the traffic mirror target.Note: Traffic Mirroring is a live stream of data. To capture the mirrored packets coming on the target and save in a pcap file, capture the traffic with UDP port 4789.Then, analyze the captured data using Wireshark:1.    Open the captured traffic in Wireshark.2.    Choose the Statistics tab.3.    Select the I/O Graph and clear all options.4.    (For Linux only) Under Display Filter, add a filter using the VXLAN Network Identifier and DNS query flag. For example, if the VXLAN Network Identifier is 53 and the DNS query flag is 0x0100, the display filter for the graph is (vxlan.vni == 53) && (dns.flags == 0x0100).5.    Review the graph to check whether it flatlines around 1024 (the Amazon-provided DNS server's packet per second limit). If the graph flatlines around this value, then DNS throttling is happening on the mirrored source.Option 3: Elastic Network Adapter (ENA) driver network performance metricIf your EC2 instance is running one of the following ENA driver versions, you can review the real-time metrics for DNS throttle using the linklocal_allowance_exceeded metric:Linux: 2.2.10 or laterWindow: 2.2.2.0 or laterThe linklocal_allowance_exceeded metric indicates the number of packets shaped and dropped due to PPS rate allowance exceeded for local services. Examples of local services are Amazon VPC DNS Service, Instance Metadata Service (IMDS), and Amazon Time Sync Service. You can verify this metric at multiple intervals to observe if the count is increasing. Because this metric is cumulative since the last restart of the driver (usually due to a stop and start or reboot of the instance), this metric is only significant if it's increasing.To retrieve the metric linklocal_allowance_exceeded value, run the following command:ethtool -S eth0Correct DNS throttling issuesIf you find that the cause of your DNS failures is DNS throttling, you can:Enable DNS caching on the instance.Increase the DNS retry timer on the application.Related informationTraffic Mirroring quotas and considerationsWorking with Traffic MirroringMonitor network performance for your EC2 instanceFollow"


Question: Why is my Storage Gateway activation failing when I try to activate my gateway using an Amazon VPC endpoint?

"I'm trying to activate my gateway on AWS Storage Gateway using an Amazon Virtual Private Cloud (Amazon VPC) endpoint (provided by AWS PrivateLink). However, the activation is failing."

Answer: "I'm trying to activate my gateway on AWS Storage Gateway using an Amazon Virtual Private Cloud (Amazon VPC) endpoint (provided by AWS PrivateLink). However, the activation is failing.ResolutionBefore you begin, confirm that your gateway meets the hardware and storage requirements for Storage Gateway.Troubleshooting a gateway that's hosted on-premisesNote: These troubleshooting steps don't apply to an on-premises file gateway that uses an Amazon Simple Storage Service (Amazon S3) VPC endpoint for Amazon S3 traffic.Confirm that your on-premises local network can communicate with your Amazon VPC, either over AWS Direct Connect or VPN. You can check this connection by pinging the private IP address of an Amazon Elastic Compute Cloud (Amazon EC2) instance within the VPC from your virtual machine or server that's on premises.Check the security group that's attached to the VPC endpoint. Confirm that the security group allows inbound traffic from the gateway's IP address on TCP ports 443, 1026, 1027, 1028, 1031, and 2222.Review the on-premises AWS Network Firewall. Confirm that the firewall allows outbound traffic to the gateway's domain name or IP address on TCP ports 443, 1026, 1027, 1028, 1031, and 2222. Additionally, confirm that the firewall allows inbound traffic to the gateway's IP address on TCP port 80.Confirm that your gateway can connect to the VPC endpoint by running a network connectivity test from your gateway's local console.Troubleshooting an on-premises file gateway that uses an Amazon S3 Gateway type VPC endpointIf your on-premises file gateway uses an Amazon S3 Gateway type VPC endpoint (over Direct Connect or VPN) for Amazon S3 traffic, such as creating a file share or reading and writing to an S3 bucket, then you must create an HTTP proxy. The HTTP proxy can be hosted on an Amazon EC2 instance.Note: In this configuration, you must also have a VPC endpoint for Storage Gateway, in addition to the VPC endpoint for Amazon S3. If your HTTP proxy is using a Squid proxy server, then the default TCP port is 3128.To troubleshoot failing activation for an on-premises file gateway that uses an Amazon S3 Gateway type VPC endpoint, perform these checks:Confirm that the private IP address of the EC2 instance (HTTP proxy host) is configured on the on-premises gateway with outbound HTTP proxy traffic allowed on TCP port 3128.Check the security group that's attached to the EC2 instance (HTTP proxy host). Confirm that the security group allows inbound traffic from the gateway's IP address on TCP port 3128.Check the security group that's attached to the Storage Gateway VPC endpoint. Confirm that the security group allows inbound traffic from the EC2 instance's (HTTP proxy host) IP address on TCP ports 443, 1026, 1027, 1028, 1031, and 2222.Review the on-premises Network Firewall. Confirm that the firewall allows outbound traffic to the EC2 instance's (HTTP proxy host) private IP address on TCP port 3128.Troubleshooting a gateway that's hosted on Amazon EC2Check the security group that's attached to the VPC endpoint. Confirm that the security group allows inbound traffic from the gateway's IP address on TCP ports 443, 1026, 1027, 1028, 1031, and 2222.Check the security group that's attached to the gateway. Confirm that the security group allows inbound traffic on TCP port 80.Confirm that the workstation you're using to activate the gateway can communicate with the VPC of the gateway instance over Direct Connect or VPN.Tip: If your workstation can't communicate with the VPC, try activating the gateway from another instance within the same VPC.Using VPC Flow Logs to troubleshoot Storage Gateway activation using a VPC endpointTo get more information about what's causing your gateway's activation to fail, enable VPC flow logs on the network interface of the VPC endpoint.After you enable VPC Flow Logs, review the flow records for the VPC endpoint. For example, use the flow logs to determine if any ports are rejecting the traffic required for your gateway's activation.Follow"


Question: How do I transfer my AWS account to another person or business?

I want to transfer the ownership of my AWS account and its associated resources to another party.

Answer: "I want to transfer the ownership of my AWS account and its associated resources to another party.ResolutionTo transfer ownership of your AWS account or change the root user sign-in information, you must have the root user's email address and password.Transfer AWS account root user access to another individualFor example, suppose you’re transferring ownership to a colleague.Before you transfer the ownership of your AWS account, consider the following:If you're using multi-factor authentication (MFA), first deactivate the device. Or, add another MFA device, and then deactivate unnecessary devices after the account transfer. For more information, see Deactivating MFA devices.If you configured security challenge questions, inform the new account owner to configure their own security challenge questions. For more information, see Setting or changing security challenge questions.A default payment method is required for all active accounts. Be sure to work with the new owner to update or remove your payment method. For more information, see How do I change the default payment method associated with my AWS account?Warning: If your AWS account and Amazon.com retail account share the same email address and password, then their login information is linked. In this case, updating the email address or password on one of the accounts changes information on the other account.To transfer your AWS account root access and change the account and billing information on that account to another individual, do the following:1.    Sign in to the AWS Management Console as the root user.2.    On the navigation bar, choose your account name, and then choose Account.3.    Choose Edit next to Account Settings.4.    Choose Edit next to the field to update the existing account credentials to use the sign-in credentials for the new root user.5.    Choose Save Changes after updating the field.6.    After changing the account credentials, choose Done.7.    The account is now updated to allow the new user to sign in as the AWS account root user.Transfer ownership to a different party or businessFor example, the AWS account currently owned by your business has been acquired by another business. To assign ownership of your AWS account and its resources to another party or business, complete a Consent to Assignment agreement. This process is handled by the AWS Sales team.To initiate the Consent to Assignment process, complete the Sales Support form with the relevant information.Note: Be sure to select Sales Support for Nature of Inquiry. For the text entry under Tell us about your project, state that you want to transfer ownership of your account through a Consent to Assignment agreement. After you submit your form, it's reviewed by the AWS Sales team, and a team member contacts you later to complete the transfer process.After initiating the Consent to Assignment process through AWS Sales, transfer your account's root access and billing information to the business that's acquiring the account. Follow the steps outlined above in Transfer AWS account root user access to another individual.If you belong to the AWS Solution Provider Program, then consult your partner development manager for additional information on this process.To migrate AWS Organizations member accounts from one Organization to another Organization, see How do I move accounts between organizations in AWS Organizations?Follow"


Question: How do I check the version number for an Amazon Aurora for MySQL or PostgreSQL DB instance?

I want to check the version number for my Amazon Aurora MySQL-Compatible Edition or Amazon Aurora PostgreSQL-Compatible Edition DB instance.

Answer: "I want to check the version number for my Amazon Aurora MySQL-Compatible Edition or Amazon Aurora PostgreSQL-Compatible Edition DB instance.ResolutionUse the version number to cross-reference the database engine updates to see what features and enhancements are available for that particular Amazon Aurora version.1.    Log in to your Aurora instance using a client. For MySQL, use MySQL Workbench. For PostgreSQL, use psql or SQL Workbench/J.2.    Run a command similar to the following:select AURORA_VERSION();select @@aurora_version;show variables like '%version';3.    After you get your Aurora version number, check the Database engine updates for Aurora MySQL or Aurora PostgreSQL updates. These will show new features and improvements.Note: Aurora releases updates regularly. Updates are cluster-wide, and they require a simultaneous restart of all the instances in the cluster, which can cause brief interruptions in connectivity. If you use Aurora for MySQL, then under certain conditions the zero downtime patch feature can prevent interruptions in connectivity on the writer node. If you use Aurora for PostgreSQL, a reboot is required. To plan for these restarts, view or change your maintenance window settings from the Amazon Relational Database Service (Amazon RDS) console. For more information about changing your maintenance window, see Adjusting the preferred DB instance maintenance window.Related informationThe Amazon RDS maintenance windowMySQL bugs fixed by Aurora MySQL database engine updatesAmazon Aurora PostgreSQL releases and engine versionsFollow"


Question: Why can’t I install SSM Agent on my Amazon EC2 Linux instance?

"When I try to install SSM Agent on my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance, installation fails. How can I troubleshoot this issue?"

Answer: "When I try to install SSM Agent on my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance, installation fails. How can I troubleshoot this issue?Short descriptionSSM Agent is pre-installed on most Amazon Web Services (AWS) provided Amazon Machine Images (AMIs), including the following:Amazon LinuxAmazon Linux 2Amazon Linux 2 ECS-optimized base AMIsUbuntu Server 16.04, 18.04, and 20.04However, to manage instances based on RedHat, SUSE, or CentOS AMIs, you must install SSM Agent manually.ResolutionVerify the following to troubleshoot SSM Agent installation failures:Unsupported operating system versionSSM Agent isn’t available for all operating system (OS) versions. SSM Agent installation fails if you run an unsupported version of an OS. Verify the list of supported operating systems to confirm whether SSM Agent is available for your OS version.Package download failureDuring the manual installation process for SSM Agent, the SSM Agent package downloads and installs from an Amazon Simple Storage Service (Amazon S3) repository. If the instance can’t connect to the S3 bucket to download the package, SSM Agent installation fails.Verify that your Amazon EC2 instance has access to the S3 repository to download the SSM Agent package:If your instance is in a private subnet with a network address translation (NAT) gateway, then see NAT gateways.If your instance is in a private subnet with a NAT instance, then see NAT instances.If your instance is in a public subnet with an internet gateway, then see Enable internet access.If your instance is in a private or public subnet with an Amazon S3 virtual private cloud (VPC) endpoint, then see Endpoints for Amazon S3.The package download can also fail under the following circumstances:The Domain Name System (DNS) servers configured within the OS can’t resolve the Amazon S3 endpoint URLs.DNS resolution is deactivated for the VPC.Run the following command to verify that the /etc/resolv.conf file includes the correct IP address for your DNS server. Then, review the output and confirm that the nameserver IP matches the IP address for your DNS server.$ cat /etc/resolv.confFor more information, see Why can’t I connect to an S3 bucket using a gateway VPC endpoint?Missing public key for SSM Agent packageSSM Agent package files are cryptographically signed. To verify that the agent package is original, you can use a public key to verify the installer package signature using either RPM or GPG. RPM packages already include the required signature for RPM verification. However, if you use GPG to verify the installer package, you must manually import the public key. Otherwise, installation fails with the error “Public key for amazon-ssm-agent.rpm is not installed”.For more information, see Verifying the signature of the SSM Agent.Related informationHow do I install AWS Systems Manager Agent (SSM Agent) on an Amazon EC2 Linux instance at launch?Automating updates to SSM AgentInstalling and configuring SSM Agent on EC2 instances for LinuxFollow"


Question: How do I manually install the AWS CLI on an Amazon EC2 Windows instance?

I want to use the AWS Command Line Interface (AWS CLI) on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.

Answer: "I want to use the AWS Command Line Interface (AWS CLI) on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.Short descriptionYou can use the AWS CLI to manage multiple AWS services and to automate common service and resource actions through scripts.Note: To install the AWS CLI on an instance, the instance must have internet access using a network address translation (NAT) instance or an internet gateway.ResolutionFor instructions to install the AWS CLI on a Windows instance, see Installing or updating the latest version of the AWS CLI.Important: If you already installed AWS CLI version 1, then it's a best practice to uninstall version 1 and use only AWS CLI version 2.To view a description of a command in the AWS CLI, append help to the command. For more information, see Getting help with the AWS CLI.For a general overview of how AWS CLI commands are structured, see Command structure in the AWS CLI.Related informationTroubleshooting AWS CLI errorsMigrating from AWS CLI version 1 to version 2Follow"


Question: How do I allow Amazon QuickSight access to an S3 bucket with a deny policy?

How can I be sure that my Amazon Simple Storage Service (Amazon S3) bucket policy allows access from Amazon QuickSight?

Answer: "How can I be sure that my Amazon Simple Storage Service (Amazon S3) bucket policy allows access from Amazon QuickSight?Short descriptionWhen your Amazon S3 bucket uses a Deny policy, that policy overrides any S3 permissions that you specify in the Amazon QuickSight console. To allow Amazon QuickSight to access the S3 bucket, add the Amazon QuickSight service role (aws-quicksight-service-role-v0) as an exception in your Deny policy.Resolution1.    Be sure that Amazon QuickSight has permission to access the S3 bucket.2.    Use the AWS Command Line Interface (AWS CLI) or AWS Identity and Access Management (IAM) API to get the unique ID for the aws-quicksight-service-role-v0 role. The ID is unique to each Amazon QuickSight account. For example:aws iam get-role --role-name aws-quicksight-service-role-v0 --query 'Role.RoleId' --output json "AROAEXAMPLEID"Note: If you receive an error while running your AWS CLI commands, be sure that you’re using the most recent version of the AWS CLI.3.    Open the Amazon S3 console.4.    Choose the bucket that you want to access with Amazon QuickSight.5.    Choose the Permissions view.6.    Choose Bucket Policy.7.    Enter a bucket policy similar to this example. Replace AROAEXAMPLEID with your unique ID. If you want to add an exception for an IAM user, replace AIDAEXAMPLEUSERID with the unique ID of the IAM user. The IAM user policy must also contain an Allow statement for the S3 bucket. For example:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Deny",      "Principal": "*",      "Action": "s3:*",      "Resource": [        "arn:aws:s3:::examplebucketname",        "arn:aws:s3:::examplebucketname/*"      ],      "Condition": {        "StringNotLike": {          "aws:userid": [            "AROAEXAMPLEID:*",            "AIDAEXAMPLEUSERID"          ]        }      }    }  ]}This Deny policy adds exceptions for the Amazon QuickSight service role and an IAM user.Note: If you delete the Amazon QuickSight service role and the IAM user, you will be locked out of the bucket. To resolve this problem, log in as the AWS account root user, and then use the delete-bucket-policy command to delete the bucket policy.Related informationHow to restrict Amazon S3 bucket access to a specific IAM roleFollow"