Question: I want to upgrade my Amazon RDS MySQL version

"I want to upgrade my Amazon Relational Database Service (Amazon RDS) for MySQL version. How do I perform the version upgrade? Also, how long does the upgrade take or why is the upgrade taking longer than expected?"

Answer: "I want to upgrade my Amazon Relational Database Service (Amazon RDS) for MySQL version. How do I perform the version upgrade? Also, how long does the upgrade take or why is the upgrade taking longer than expected?ResolutionPerforming an Amazon RDS for MySQL version upgradeTo manually upgrade the engine version of a DB instance, use the AWS Management Console, AWS Command Line Interface (AWS CLI), or Amazon RDS API.Note: If you receive errors when running an AWS CLI command, make sure that you’re using the most recent version of the AWS CLI.Amazon RDS MySQL upgrade timeThe duration of the upgrade process depends on the upgrade type, data, and resources available. It's a best practice to first test the upgrades on separate test instances (similar to your production environment) to understand the approximate upgrade duration. You can also use a snapshot restore or read replica to launch test instances for upgrades, either with major or minor version upgrades. For more information about major and minor version upgrades, see Upgrading the MySQL DB engine.Factors that can impact upgrade timeFor all version upgrades of Amazon RDS for MySQL, the following is true:A snapshot is taken (if backups are enabled) while the instance is still running on the previous version. If Amazon RDS doesn't find any recent backups, a full snapshot is taken during the upgrade process, which can impact the overall upgrade time. The size of your changes determines how long it takes for the upgrade to complete. However, your instance can still continue accepting traffic while the snapshot is taken.After a backup completes, the instance is shut down. MySQL then runs the new engine version on a disabled network, preventing any remote connections.Note: If you're performing a major version upgrade, then the shutdown can take longer.For major version upgrades of Amazon RDS for MySQL, the following is true:Amazon RDS employs a slow shutdown by setting the innodb_fast_shutdown parameter value to "0". This mode performs additional flushing, such as merging the change buffer and performing a full purge of deleted rows. The slow shutdown can take minutes or hours, depending on the amount of data being recovered. Slow shutdown of a database with a large change buffer or long history list length can take longer. For more information about the bottleneck caused by a slow shutdown, see Change buffer on the MySQL website. For more information about innodb_fast_shutdown mode, see innodb_fast_shutdown on the MySQL website.The mysql_upgrade program runs on the MySQL database to convert system and user tables to a new version for major upgrade versions. Depending on the state of your table, your table might need to be recreated to conform to a new version. In most cases, no changes are required and mysql_upgrade updates the metadata in the table to indicate that the database was upgraded. If you have a larger number of tables, Amazon RDS MySQL might take longer to complete the major version upgrade. For more information, see mysql_upgrade — Check and Upgrade MySQL Tables on the MySQL website.During major version upgrades to version 5.7, Amazon RDS for MySQL rebuilds some of your tables. All date and time column types are converted to the new format, which can take several hours to days. The duration depends on the amount of data in your tables. For more information, see Upgrades to MySQL version 5.7 might be slow.Related informationUpgrading a DB instance engine versionBest practices for upgrading Amazon RDS for MySQL and Amazon RDS for MariaDBFollow"


Question: What are some of the best practices to create a composite key for my Amazon DynamoDB table?

I want to learn the best practices to create a composite key for my Amazon DynamoDB table.

Answer: "I want to learn the best practices to create a composite key for my Amazon DynamoDB table.ResolutionWhen you create a composite key for your DynamoDB table, it's a best practice to do the following:Choose a unique partition key with high cardinality: The partition key for a DynamoDB table must be unique. Choosing a partition key with low cardinality might affect the way data is stored and distributed over different partitions in the table. Therefore, be sure to choose a partition key with a high cardinality. For more information on data distribution in DynamoDB, see Partitions and data distributions.Choose a sort key that compliments access patterns: Choose a sort key that gathers related information together in one place so that the information can be queried efficiently. Carefully choosing the sort key attribute is important because it can significantly improve the selectivity of the items retrieved by a query. Also, a composite sort key allows you to define a hierarchical relationship in your data so that you can query at any level of the hierarchyFor example, a composite sort key must look similar to the following:[building]#[department]#[team]#[manager]In this case, you can select employeeID as the partition key so that you can have unique combinations all the way up to manager.For more information, see Best practices for using sort keys to organize data. The combination of partition key and sort key or composite sort key creates a new unique composite key that allows for effective querying and distribution of data over partitions in DynamoDB.Consider the following when you design your composite key:The combination of the partition key and sort key must form a unique value.You can have repeating partition keys with different sort keys.Related informationChoosing the right DynamoDB partition keyFollow"


Question: How do I troubleshoot Classic Load Balancer capacity issues in ELB?

My Amazon CloudWatch metric SurgeQueueLength for my Classic Load Balancer has an increased maximum statistic. Clients also receive HTTP 503 Service Unavailable or HTTP 504 Gateway Timeout errors when they try to connect to my Classic Load Balancer. How do I troubleshoot these Elastic Load Balancing capacity issues?

Answer: "My Amazon CloudWatch metric SurgeQueueLength for my Classic Load Balancer has an increased maximum statistic. Clients also receive HTTP 503 Service Unavailable or HTTP 504 Gateway Timeout errors when they try to connect to my Classic Load Balancer. How do I troubleshoot these Elastic Load Balancing capacity issues?Short descriptionThe Classic Load Balancer metric SurgeQueueLength measures the total number of requests queued by your Classic Load Balancer. An increased maximum statistic for SurgeQueueLength indicates that backend systems can't process incoming requests as fast as the requests are received. Possible reasons for a high SurgeQueueLength metric include:Overloaded Amazon Elastic Compute Cloud (Amazon EC2) instances behind the Classic Load Balancer that are unable to process all incoming requestsApplication dependency issues due to external resource performance issuesMaximum allowable connection limits for instancesWhen requests exceed the maximum SurgeQueueLength, the SpilloverCount metric starts to measure rejected requests. The maximum SurgeQueueLength is 1024.ResolutionConfigure Auto Scaling groups with your Classic Load Balancer to scale your instances based on demand.Configure CloudWatch to monitor your Classic Load Balancer.Turn on detailed monitoring for instances behind your Classic Load Balancer to monitor the CPUUtilization metric. You can also get statistics for a specific instance. If CPU utilization spikes, your instances are too busy processing existing requests to accept new requests. Consider scaling out your instances or scaling up to an instance type with more processing power.Troubleshoot HTTP errors for your Classic Load Balancer. Load-related issues typically return 503 or 504 HTTP errors.If your Amazon EC2 instances run Apache, then see How do I tune Apache web server's memory allocation to prevent out of memory errors in an EC2 Linux instance?For performance issues related to normal traffic increases over time, consider increasing your instance capacity.Related informationCloudWatch metrics for your Classic Load BalancerFollow"


Question: Why is the TIMESTAMP result empty when I query a table in Amazon Athena?

"When I query a column of TIMESTAMP data in my Amazon Athena table, I get empty results or the query fails. The data exists in the input file."

Answer: "When I query a column of TIMESTAMP data in my Amazon Athena table, I get empty results or the query fails. The data exists in the input file.Short descriptionThe TIMESTAMP data might be in the wrong format. Athena requires the Java TIMESTAMP format:YYYY-MM-DD HH:MM:SS.fffffffffTo change TIMESTAMP data to the correct format:Define the column as STRING.Use Presto's date and time functions to read the column as DATE or TIMESTAMP in your query.ResolutionDefine the column as STRINGRun a command similar to the following:CREATE EXTERNAL TABLE 'test' ('ts' STRING)ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'LOCATION 's3://doc-example-bucket/path-to-data/'Use Presto's date and time functions to read the column as DATE or TIMESTAMP in your queryIf your input data is in the following format:20200921T01500520200923T095605Then use the date_parse function as shown in the following example:SELECT date_parse(ts,'%Y%m%dT%h%i%s') FROM timestamptestcsv3Note: The format in the date_parse(string,format) function must be the TIMESTAMP format that's used in your data.If your input data is in ISO 8601 format, as in the following:2020-11-14T02:34:48ZThen use the from_iso8601_timestamp() function to read the ts field as TIMESTAMP. Example:SELECT from_iso8601_timestamp(ts) FROM timestamptestcsv3Related informationData types in Amazon AthenaFollow"


Question: How do I fix an Amazon WorkDocs Drive for Windows that is stuck or crashing after logging in?

"After logging in, my Amazon WorkDocs Drive client for Windows is stuck at the authentication screen or is shutting down. How can I fix this?"

Answer: "After logging in, my Amazon WorkDocs Drive client for Windows is stuck at the authentication screen or is shutting down. How can I fix this?Short descriptionThe Message Queuing service is failing or not in the Started status. The WorkDocs Drive client requires the Message Queuing service to write to the System Journal file.ResolutionFor Windows 10 OS1.    Open a PowerShell session as Administrator.2.    Run the Enable-WindowsOptionalFeature -Online -FeatureName MSMQ-ADIntegration -All command.For Windows ServerFirst, uninstall the Message Queueing service from the Windows operating system.1.    Open a PowerShell session as Administrator.2.    Run the Import-Module ServerManager command.3.    Run the Uninstall-WindowsFeature -Name MSMQ -Restart command. The Windows operating system restarts.After the Windows operating system restarts, reinstall the Messaging Queueing service.1.    Open a PowerShell session as Administrator.2.    Run the Import-Module ServerManager command.3.    Run the Install-WindowsFeature -Name MSMQ command.You can now log in to the WorkDocs Drive client.Related informationTroubleshooting Amazon WorkDocs issuesFollow"


Question: How can I publish a message to an Amazon SNS topic using a Lambda function?

I want to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic from an AWS Lambda function.

Answer: "I want to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic from an AWS Lambda function.ResolutionFollow these steps to send a message to an Amazon SNS topic using a Lambda function.Note: The example in this article uses a Python runtime, but you can use your preferred Lambda runtimes.1.    Create an Amazon SNS topic.2.    Create a Lambda function.3.    From the Lambda function, make sure that the Lambda execution role has permissions to publish the SNS message similar to the following:Note: Replace your-region, your-account-number, and your-topic-name with your variables.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PublishSNSMessage",      "Effect": "Allow",      "Action": "sns:Publish",      "Resource": "arn:aws:sns:<your-region>:<your-account-number>:<your-topic-name>"    }  ]}4.     Choose the Code tab. Then, in Code source, copy and paste the following code for the Publish Boto3 action into the code editor:import jsonimport boto3client = boto3.client('sns')def lambda_handler(event, context):   response = client.publish(TopicArn='arn:aws:sns:<region>:<account-number>:<topic-name>',Message="Test message")   print("Message published")   return(response)5.    Test your Lambda function.If your Lambda function is connected to an Amazon Virtual Private Cloud (Amazon VPC), then do one of the following:If your Lambda function requires internet access, make sure that you grant internet access. For more information, see How do I give internet access to a Lambda function that's connected to an Amazon VPC?-or-For private networks, create an Amazon VPC endpoint for Amazon SNS in the same VPC. For more information, see Creating an Amazon VPC endpoint for Amazon SNS.Related informationWhy do I get an authorization error when I try to subscribe my Lambda function to my Amazon SNS topic?Follow"


Question: How do I temporarily turn off call recording for security in Amazon Connect when a customer enters sensitive information?

"I want to record calls coming into my Amazon Connect contact center, but turn off recording while my customers are entering sensitive information. How do I set that up?"

Answer: "I want to record calls coming into my Amazon Connect contact center, but turn off recording while my customers are entering sensitive information. How do I set that up?Short descriptionCreate a Transfer to queue contact flow using the Sample secure input with agent sample contact flow. Then, create a quick connect to transfer contacts to this flow.The sample contact flow uses Hold customer or agent contact blocks to do the following:Put the agent on hold while turning off call recording as the customer enters their information.Conference the customer and agent while turning call recording back on and continuing the call.ResolutionNote: Call recording is activated by default when creating a new Amazon Connect instance. If call recording isn't currently activated in your instance, then activate call recording by following the instructions in Update instance settings.Set up recording behavior in a contact flow1.    Log in to your Amazon Connect instance using your access URL (https://alias.awsapps.com/connect/login -or- https://alias.my.connect.aws)Important: You must log in as a user that has Edit and Create permissions for quick connects. For more information, see Security profiles.2.    If you haven't done so already, add a Set recording behavior block to a contact flow that handles contacts that you want to monitor. For more information and instructions, see Set up recording behavior.Create a Transfer to queue contact flow1.    In the left navigation bar, pause on Routing. Then, choose Contact flows.2.    Under Contact flows, choose Sample secure input with agent. The contact flow designer opens.3.    In the contact flow designer, next to Save, choose the arrow icon, and then choose Save as.Note: This option saves your new contact flow as a copy instead of overwriting the sample.4.    In the Save as window, enter a New name and Description for your contact flow.5.    Choose Save as.For more information, see Sample contact flows.Configure the audio prompt and customer input encryption settings1.    Choose the block title of the Store customer input block. The block's settings menu opens.2.    Under Prompt, specify the audio prompt that you want your customers to hear before entering their information. For more information, see Create prompts.3.    Under Customer input, choose and configure a type of Custom input or Phone number format.Note: If you choose Custom input, keep the Encrypt entry (recommended) check box selected and configure encryption. For more information, see Encrypt customer input.4.    Choose Save.Name the contact attribute for the stored customer input1.    Choose the block title of the Set contact attributes block. The block's settings menu opens.2.    Under Attribute to save, choose Use attribute.3.    For Destination key, enter a name to use as a reference to the attribute.Note: Keep the same settings for Type (System) and Attribute (Stored customer input).4.    Choose Save. The block's settings menu closes.5.    Choose Save to save a draft of the flow.6.    Choose Publish to activate the flow immediately.Create and activate a Queue quick connect1.    Create a queue quick connect by following the instructions in Create quick connects. While you're creating the quick connect, do the following:For the Destination, choose any queue (the contact doesn't enter the queue).For Contact flow, choose the Transfer to queue contact flow that you created.2.    Add the quick connect to the queues used in your contact flows by following the instructions in Allow agents to see quick connects.3.    Confirm that the queues that include your quick connect are in a routing profile assigned to the agents who will use the quick connect. For more information, see Set up routing.For more information, see How do I allow agents in my Amazon Connect contact center to transfer contacts using the CCP? Also, Set up contact transfers.Test the setupDuring an incoming call to an agent, have the agent use the quick connect that you created to start secure entry for the caller. Call recording is turned off automatically during the caller's data entry. Then, call recording is turned back on afterward so that the agent and caller can continue their recorded conversation.To confirm that the setup worked as expected, review the recording stored in Amazon Simple Storage Service (Amazon S3).Related informationSet up your contact centerCapture customer audio: Live media streamingFollow"


Question: How do I troubleshoot service auto scaling issues in Amazon ECS?

The service auto scaling configured for my Amazon Elastic Container Service (Amazon ECS) service isn't scaling in or scaling out the desired task count as required.

Answer: "The service auto scaling configured for my Amazon Elastic Container Service (Amazon ECS) service isn't scaling in or scaling out the desired task count as required.Short descriptionYou can update the desired count of tasks for your Amazon ECS service automatically by integrating your ECS service with the Application Auto Scaling service and Amazon CloudWatch alarms.Service auto scaling might not be able to add or remove tasks as expected due to one or more of the following reasons:The scaling policies aren't configured correctly.The CloudWatch alarm that triggers the scaling policies are deleted or edited.The cron expression format is incorrectly specified in the scheduled action.You updated the desired task count manually or through AWS CloudFormation or AWS Cloud Development Kit (AWS CDK) to a value that's less than the minimum or more than the maximum value set in service auto scaling.Your ECS Cluster doesn't have enough resources or capacity to run new tasks.ResolutionTroubleshooting CloudWatch alarms and scaling policiesScalable targetBe sure that the ECS service is registered as a scalable target with Application Auto Scaling. If the service isn't registered, register the service using the following command. Then, configure the scaling policies and CloudWatch alarms accordingly. For more information, see How can I configure Amazon ECS Service Auto Scaling on Fargate?aws application-autoscaling register-scalable-target --service-namespace ecs --scalable-dimension ecs:service:DesiredCount \--resource-id service/your-cluster/your-service-name --min-capacity 1 --max-capacity 10 --region example-regionUse the following commands to retrieve information about the service auto scaling of your ECS service:aws application-autoscaling describe-scalable-targets --service-namespace ecs --region example-region aws application-autoscaling describe-scaling-policies --service-namespace ecs --region example-regionaws application-autoscaling describe-scaling-activities --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount --resource-id service/your-cluster/your-service-name --region example-regionWhen you create or update the CloudWatch alarms for your ECS service auto scaling, be sure that the metrics, dimensions, statistics, period, condition, and threshold values are specified correctly. Otherwise, the alarm isn't triggered to update the associated scaling policy.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Step scalingCheck whether the CloudWatch alarms associated with the scaling policies are being triggered. Check whether there were any errors by viewing the CloudWatch alarms history.For step scaling policies, check whether the breach threshold, step adjustments, and scaling adjustment type are set in the CloudWatch alarm. If there is no matching step adjustment for the breach delta, that is threshold subtracted from the metric value, then you can see the following error message in the alarm history: Failed to execute AutoScaling action: No step adjustment found for metric value [xx, xx] and breach delta xxTherefore, be sure that all step adjustments, that is from -infinity to 0 for scale-in and 0 to +infinity for scale-out, are covered in your policies.Note: Typically, for a scale-out policy, in the step adjustments, only the upper bound can be null (positive infinity). For a scale-in policy, only the lower bound can be null (negative infinity). For more information, see Step adjustments.Target tracking scalingBecause target tracking scaling policies are AWS managed, Application Auto Scaling creates CloudWatch alarms for scaling in and scaling out based on the target value or threshold that's specified during the creation of these policies. Therefore, don't edit or delete these alarms. Editing or deleting these alarms affects the scaling behavior. If you modified or deleted these alarms, be sure to recreate the target tracking policy again.You can have multiple target tracking scaling policies for an ECS service as long as each policy uses a different metric. The intention of Application Auto Scaling is to prioritize the availability. Therefore, the behavior of these policies differs depending on whether the target tracking policies are ready for scaling out or scaling in. Application Auto Scaling scales out the tasks if any of the target tracking policies are ready for scale out, but scales in only if all of the target tracking policies (with the scale-in portion enabled) are ready to scale in.When multiple scaling policies, including target tracking and step scaling policies, are configured for an ECS service, be sure that they don't conflict. These conflicts might cause undesirable behavior, such as having consecutive scale-in and scale-out, resulting in unnecessary oscillation of task count.For more information, see Target tracking scaling policies for Application Auto Scaling.Troubleshooting incorrect cron expressionBe sure that the cron expression specified in the schedule is correct in the configuration of scheduled actions for Application Auto Scaling. The cron format that's supported by Application Auto Scaling consists of six fields separated by white spaces: [Minutes] [Hours] [Day_of_Month] [Month] [Day_of_Week] [Year].For more information, see Example scheduled actions for Application Auto Scaling.Troubleshooting the desired task count updateKeep the following in mind when you either manually update or use CloudFormation or AWS CDK to update the desired task count for your ECS service:If you updated the desired task count for your ECS service to a value that's below the minimum capacity value, and an alarm triggers a scale-out activity, service auto scaling scales the desired count up to the minimum capacity value. Then, service auto scaling continues to scale out as required, based on the scaling policy associated with the alarm. However, a scale-in activity doesn't adjust the desired count, because the desired count is already below the minimum capacity value.If you updated the desired task count for your ECS service to a value that's above the maximum capacity value, and an alarm triggers a scale in activity, service auto scaling scales the desired count out to the maximum capacity value. Then, service auto scaling continues to scale in as required, based on the scaling policy associated with the alarm. However, a scale-out activity doesn't adjust the desired count, because the desired count is already above the maximum capacity value.If you created your ECS service with CloudFormation or CDK without specifying the DesiredCount field, then the desired count is set to a default value of 1. However, when the same service is updated through CloudFormation or CDK without specifying the DesiredCount field, then the existing desired count in the current deployment is used for the new deployment. Therefore, when the desired count value is specified in the CloudFormation stack or AWS CDK, be sure that the value is between the minimum and maximum values during the service update.Troubleshooting cluster capacity issuesWhen your ECS cluster doesn't have enough resources, such as Amazon Elastic Compute Cloud (Amazon EC2) container instances, to run tasks, then the scaling activity initiated by the scaling policies remains unfulfilled. In this case, an error message is logged in service events. To avoid these Amazon EC2 capacity issues and launch the tasks successfully, leverage Amazon ECS capacity providers to provision EC2 instances automatically, as required.Note: During scaling activities, service auto scaling uses the actual running task count in a service as the starting point, as opposed to the desired count. This prevents excessive scaling that might not be satisfied, for example, if there aren't enough container instance resources to place the additional tasks. If the container instance capacity is available later, the pending scaling activity might succeed. Then, further scaling activities continue after the cooldown period.Related informationService auto scalingAWS CLI command reference for application-autoscalingFollow"


Question: Why does the HTTPS connection between my CloudFront distribution and load balancer fail?

I have HTTPS and HTTP listeners configured on my Classic Load Balancer or Application Load Balancer as the origin for my Amazon CloudFront distribution. The HTTPS communication between CloudFront and my load balancer fails. I want to resolve the HTTPS communication issues.

Answer: "I have HTTPS and HTTP listeners configured on my Classic Load Balancer or Application Load Balancer as the origin for my Amazon CloudFront distribution. The HTTPS communication between CloudFront and my load balancer fails. I want to resolve the HTTPS communication issues.ResolutionThe HTTPS communication failure might be caused by issues with the associated SSL certificate, security groups, or network access control list (ACL). Be sure that your distribution and load balancer meet the following security requirements:You must have a valid SSL certificate installed on the load balancer. If you're still getting HTTPS errors after installing an SSL certificate, troubleshoot the SSL connection between CloudFront and the custom origin server.If your CloudFront distribution connects to your load balancer on port 443, then the security groups associated with your load balancer must allow traffic on port 443 from CloudFront IP addresses. For more information on updating security groups, see Configure security groups for your Classic Load Balancer or Security groups for your Application Load Balancer. To allow only CloudFront IP addresses in security group attached to your distribution, use the AWS managed prefix list. This list contains all CloudFront IP addresses and is updated automatically if there are any changes in IP addresses. For more information, see Limit access to your origins using the AWS managed prefix list for Amazon CloudFront.The network ACLs associated with your load balancer's Amazon Virtual Private Cloud (Amazon VPC) must allow traffic from CloudFront on HTTPS ports (typically port 443).Note: Application Load Balancers support multiple TLS certificates with smart selection using Server Name Indication (SNI). If your CloudFront distribution caches based on the host header, then verify that the Application Load Balancer has a TLS certificate configured with the same name. Otherwise, the Application Load Balancer offers its default certificate, which might not match the SNI associated with the ClientHello message from CloudFront.Related informationRequiring HTTPS for communication between CloudFront and your custom originFollow"


Question: How do I use IAM Identity Center permission sets?

I want to use AWS IAM Identity Center (successor to AWS Single Sign-On) permission sets to provide users and groups access to an AWS account.

Answer: "I want to use AWS IAM Identity Center (successor to AWS Single Sign-On) permission sets to provide users and groups access to an AWS account.ResolutionUse IAM Identity Center to create a permission set for a user or group. Then, confirm the permissions from the user portal. In the following example, a federated user receives the ViewOnlyAccess permission set.Create a ViewOnlyAccess permission setOpen the IAM Identity Center console.In the navigation pane, choose AWS accounts.Select the AWS account that you want to create the permission set for. Then, choose Assign users or groups.Select the users that you want to create the permission set for. Then, choose Next.In Assign permission sets, choose Create permission set. For more information, see Create a permission set.Choose Create.In Permission set, choose ViewOnlyAccess, and then choose Finish.When you successfully create your permission set, you receive the following message:"We have successfully configured your AWS account. Your users can access this AWS account with the permissions you assigned".Verify that the user has ViewOnlyAccess permissionChoose Proceed to AWS accounts.In the navigation pane, choose Dashboard.In AWS access portal URL, choose your access portal URL.In the user portal login page, log in to your user portal with your user name and password for the IAM Identity Center user.Choose the AWS Account icon.Choose the account dropdown list. Note that the account has ViewOnlyAcccess permission.Choose Management console for the ViewOnlyAccess set.You are signed in to the AWS Management Console with ViewOnlyAcccess permission.Remove or delete permission setsYou can remove a permission set from an AWS account or completely delete it. Before you delete a permission set, you must remove it from all accounts. For more information, see Delete permission sets.Related informationSingle sign-on access to AWS accountsFollow"


Question: How do I use external Python libraries in my AWS Glue 1.0 or 0.9 ETL job?

"I want to use an external Python library in my AWS Glue 1.0 or 0.9 extract, transform, and load (ETL) job."

Answer: "I want to use an external Python library in my AWS Glue 1.0 or 0.9 extract, transform, and load (ETL) job.Short descriptionTo use an external library in an Apache Spark ETL job, do the following:1.    Package the library files in a .zip file (unless the library is contained in a single .py file).2.    Upload the package to Amazon Simple Storage Service (Amazon S3).3.    Use the library in a job or JobRun.ResolutionThe following is an example of how to use an external library in a Spark ETL AWS Glue 1.0 or 0.9 ETL job.Important: If you want to use an external library in your AWS Glue 2.0 job, then see How do I use external Python libraries in my AWS Glue 2.0 ETL job? If you want to use an external library in a Python shell job, then follow the steps at Providing your own Python library.1.    Create a Python 2 or Python 3 library for boto3. Be sure that the AWS Glue version that you're using supports the Python version that you choose for the library. AWS Glue version 1.0 supports Python 2 and Python 3, and AWS Glue version 0.9 supports only Python 2.Note: Libraries and extension modules for Spark jobs must be written in Python. Libraries, such as pandas, that are written in C aren't supported in Glue 0.9 or 1.0. If you need to use a Library written in C, then upgrade AWS Glue to at least version 2.0 and use the --additional-python-modules option. For more information, see How do I use external Python libraries in my AWS Glue 2.0 ETL job?2.    Launch an Amazon Elastic Compute Cloud (Amazon EC2) Linux instance.3.    Connect to the Linux instance using SSH.4.    Run the following commands to install Python and Boto3. For more information, see Boto3 documentation for Quickstart.sudo yum groupinstall "Development Tools"sudo yum -y install openssl-develwget https://www.python.org/ftp/python/3.6.9/Python-3.6.9.tgztar xvf Python-3.6.9.tgzcd Python-3.6.9/./configure --enable-optimizationssudo make installsudo pip install boto35.    Confirm the location of the Python site-packages directory:python -m siteYou receive an output similar to the following:/usr/lib/python3.6/site-packages6.    Package the external library files in a .zip file unless the library is contained in a single .py file. The .zip file must include an __init__.py file, and the package directory must be at the root of the archive. The __init__.py file can be empty. For more information, see Python documentation for Packages.Example:cd /usr/lib/python3.6/site-packagessudo zip -r -X "/home/ec2-user/site-packages.zip" *7.    Upload the package to Amazon S3:aws s3 cp /home/ec2-user/site-packages.zip s3://awsexamplebucket/8.    Use the library in a job or JobRun.To use an external library in a development endpoint, do the following:1.    Package the library and upload the file to Amazon S3, as explained previously.2.    Create the development endpoint. For Python library path, enter the Amazon S3 path for the package. For more information, see Loading Python libraries in a development endpoint.Related informationUsing Python libraries with AWS GlueFollow"


Question: How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?

My AWS Lambda function is producing "Rate exceeded" and 429 "TooManyRequestsException" errors.

Answer: "My AWS Lambda function is producing "Rate exceeded" and 429 "TooManyRequestsException" errors.ResolutionLambda functions are sometimes throttled to protect your resources and downstream applications. Even though Lambda automatically scales to accommodate incoming traffic, your function can still be throttled for various reasons.To troubleshoot Lambda throttling issues, including Rate exceeded and TooManyRequestsException errors, review the following steps.Verify what resource is throttledThrottle errors might not be from your Lambda function. Throttles can also occur on API calls during your function's invocation.To confirm what resource is throttled, check the following resources.Check your Amazon CloudWatch Logs to see if there are throttling errors, but no corresponding data points in the Lambda Throttles metricsIf there are no Lambda Throttles metrics, then the throttling is happening on API calls in your Lambda function code.Check your function code for any throttled API callsIf certain API calls are throttled, make sure that you use exponential backoff in your code to retry the API calls.Note: If you need a higher transactions per second (TPS) quota for an API call, then request a service quota increase. Not all quotas are adjustable.Check your function's concurrency metricsReview your Lambda metrics in Amazon CloudWatchCheck the ConcurrentExecutions metric for your function in the AWS Region where you see throttling.Compare the ConcurrentExecutions metric with the Throttles metric for the same timestampView the Maximum statistic for ConcurrentExecutions and the Sum statistic for Throttles. See if the maximum ConcurrentExecutions are close to your account-level concurrency quota in the Region, along with corresponding data points in the Throttles graph.Check if you're exceeding the initial burst concurrency quota for a particular AWS RegionOn the Metrics page for Lambda in the CloudWatch console, reduce the graph's time range to 1 minute. If you're limited by burst scaling, then you see a spike of Throttles that corresponds to a stair-step pattern of ConcurrentExecutions on the graph.Note: To work around burst concurrency limits, you can configure provisioned concurrency.Check for spikes in Duration metrics for your functionConcurrency depends on function duration. If your function code is taking too long to complete, there might not be enough compute resources.Try increasing the function's memory setting. Then, use AWS X-Ray and CloudWatch Logs to isolate the cause of duration increases.Note: Changing the memory setting can affect the charges that you incur for execution time.You can add the function to an Amazon Virtual Private Cloud (Amazon VPC). When the function is in an Amazon VPC, see How do I give internet access to a Lambda function that's connected to an Amazon VPC?Check for an increase in Errors metrics for your functionIncreased errors can lead to retries and cause an overall increase in invocations. Increased invocations can lead to an increase in concurrency. Use CloudWatch Logs to identify and eliminate errors, and have your function code handle exceptions.Note: Your function can also be throttled based on invocation requests per Region (requests per second), which is 10 times your concurrent executions quota.Configure reserved concurrencyConfirm that you configured reserved concurrency on your functionUse the Lambda console to check the setting for reserved concurrency. If reserved concurrency isn't configured, then the function uses unreserved concurrency. When invocations with functions exceed the unreserved concurrency, throttling occurs.Note: If you configured a function with zero reserved concurrency, then the function is throttled because it can't process any events. Make sure that you increase the value to a number greater than zero.Review the Maximum statistic in CloudWatch for your functionSee if the function metric hits the maximum value for the ConcurrentExecutions metric at any point.Increase the reserved concurrency for your function to a concurrency value that keeps the function from being throttledUse the Lambda console to change the setting, or call the PutFunctionConcurrency API.Use exponential backoff in your appTo retry throttled requests, it's a best practice to use exponential backoff in your application that's calling your Lambda function.Use a dead-letter queueFor asynchronous event sources, such as Amazon Simple Storage Service (Amazon S3) and Amazon EventBridge, configure your function with a dead-letter queue (DLQ). Then, verify the error handling for asynchronous invocation configuration. The DLQ catches any events that are discarded due to constant throttles and can protect your data if you're seeing significant throttling.Note: For Amazon Simple Queue Service (Amazon SQS) event sources, you must configure the DLQ on the Amazon SQS queue.Request a service quota increaseIf your workload requires a higher service quota for concurrent executions, then use the Service quota console to request a service quota increase.Related informationBest practices for working with AWS Lambda functionsTroubleshoot invocation issues in AWS LambdaError handling and automatic retries in AWS LambdaFollow"


Question: How is the pricing benefit of a Savings Plan applied across an organization's consolidated bill?

How is the pricing benefit of a Savings Plan applied in an organization's consolidated billing family?

Answer: "How is the pricing benefit of a Savings Plan applied in an organization's consolidated billing family?ResolutionSavings Plans can be purchased in any account within the organization's consolidated billing family.Savings Plans apply to accounts in an organization's consolidated billing family depending upon whether sharing is turned on or off for the accounts. By default, sharing for all accounts in an organization is turned on. The management account of an organization can change this setting by turning off sharing for an account.If Savings Plans sharing is turned on for an account in an organization, then:At least one account in the organization's consolidated billing family must have AWS compute usage for the plan type of the Savings Plans to apply to the management account's bill.Savings plans first apply to usage in the purchasing account. Then, if there is any unused hourly commitment, the Savings Plans apply towards other accounts in the organization that have sharing turned on. This happens automatically and is applied to usage with the largest calculated savings.Savings Plans purchased on a member account won't apply to the consolidated bill if the member account leaves the organization or is removed from the organization by the management account. For more information, see Before removing an account from an organization.If Savings Plans sharing is turned off for an account in an organization, then:Savings Plans apply only to the account that purchased the Savings Plans.Savings Plans from other accounts in the organization's consolidated billing family don't apply.The charges accrued on that account are still added to the organization's consolidated bill and are paid by the management account.Capacity reservations can be shared within an AWS organization at no additional cost. For more information, see Work with shared Capacity Reservations.Reserved instances can also be applied across an organization's consolidated bill. For more information, see How is the pricing benefit of a Reserved Instance applied across an organization's consolidated bill?Related informationConsolidated billing for AWS OrganizationsUnderstanding consolidated billsFollow"


Question: How do I set up Amazon Inspector Classic to run security assessments on my Amazon EC2 instances?

How can I set up Amazon Inspector Classic to perform a security assessment on my Amazon Elastic Compute Cloud (Amazon EC2) instance?

Answer: "How can I set up Amazon Inspector Classic to perform a security assessment on my Amazon Elastic Compute Cloud (Amazon EC2) instance?ResolutionYou can use the Amazon Inspector Classic service to create and run security assessments for your Amazon EC2 instances by following these steps.Important: Before you begin, consider moving from Amazon Inspector Classic to the new Amazon Inspector. This is because the new Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure. For instructions, see Moving to the new Amazon Inspector.Create a service-linked role for Amazon Inspector and tag your Amazon EC2 instancesOpen the Amazon Inspector console, and in the navigation pane choose Switch to Inspector Classic.Follow the instructions for One-click setup.Open the Amazon EC2 console, and then choose Instances from the navigation pane.Select the instances that you want Amazon Inspector to perform an assessment on, and then choose the Tags tab.Choose Add/Edit Tags, and then choose Create Tag.Enter a Key and Value name, and then choose Save.Install the Amazon Inspector agentFollow the instructions for installing the Amazon Inspector agent for the OS of your Amazon EC2 instance:Installing the agent on a Linux-based EC2 instanceInstalling the agent on a Windows-based EC2 instanceAmazon Linux 2 AMI with the Amazon Inspector Classic agentInstalling the agent on multiple EC2 instances using the Systems Manager Run Command (SSM Agent required)For information about automating the installation of the Amazon Inspector agent, see How to simplify security assessment setup using Amazon EC2 Systems Manager and Amazon Inspector.Define the assessment targetOpen the Amazon Inspector Classic console, and then choose Assessment targets.Choose Create, enter the name for your assessment target.Choose the Key and Value pairs for the Amazon EC2 instances that you want to include in the assessment, such as "examplekey" and "examplevalue."Uncheck Install Agents, and then choose Preview to view and verify the instances that are included.Choose OK, and then choose Save.Define the assessment template and run the assessmentOpen the Amazon Inspector Classic console, choose Assessment templates, and then choose Create.In Assessment Template, enter a Name and Target name.For Rules packages, choose Common Vulnerabilities.For Duration, choose how long you want your assessment to run. Note: It's a best practice to choose a duration of one hour if you have more than one rule package or instance.Uncheck Assessment Schedule, and then choose Create and run.After the assessment is complete, choose Findings or Assessment runs from the navigation pane.Run the assessmentOpen the Amazon Inspector Classic console.Select the Assessment templates section to see the available assessments.Choose the template that you created.Choose Run to start the assessment immediately.After the assessment is complete, choose Findings or Assessment runs from the navigation pane.Note: You can also set up automatic assessment runs through an AWS Lambda function.Assessment runs include a list of all assessment runs. You can review information about a particular assessment, generate a report from that assessment, or navigate to the security findings for specific assessments. For more information, see assessment reports.Findings include a list of all Findings for all assessment runs. You can filter these results to see specific findings. Findings are identified security vulnerabilities or configuration exposures that are discovered during the Amazon Inspector assessment. To learn more about an Amazon Inspector finding, choose the arrow next to the finding to expand the detailed view. For more information, see Amazon Inspector Classic findings.Note: Amazon Inspector assessment targets can include only Amazon EC2 instances that have a supported OS installed. See Amazon Inspector Classic supported operating systems and Regions for more information.Related informationGetting started with Amazon Inspector ClassicFollow"


Question: How do I use AWS Systems Manager to join a new EC2 Windows instance to my AWS Directory Service domain?

I want to use AWS Systems Manager to join a new Amazon Elastic Compute Cloud (Amazon EC2) instance to an AWS Directory Service domain at launch. How can I do this?

Answer: "I want to use AWS Systems Manager to join a new Amazon Elastic Compute Cloud (Amazon EC2) instance to an AWS Directory Service domain at launch. How can I do this?Short DescriptionYou can use AWS Systems Manager to automatically join a new instance to the domain at launch. You can host the domain on AWS Directory Service using either AWS Directory Service for Microsoft Active Directory or Simple AD. The domain can also be located over an on-premises network using the AD Connector directory gateway.Note: If you use VPC endpoints for Systems Manager, then requests to join an EC2 instance to an AWS Directory Service domain fail. For more information, see VPC endpoint restrictions and limitations.ResolutionYou can seamlessly join new Windows EC2 instances to an AWS Directory Service directory at launch using the Amazon EC2 launch instance wizard.PrerequisitesAWS Directory Service directoryAWS Identity and Access Management (IAM) instance profile role configured for Systems Manager and directory join accessConfigure and launch the EC2 instanceOpen the Amazon EC2 console, choose your Region, and then choose Launch Instance.For Choose an Amazon Machine Image (AMI), locate a Windows Amazon Machine Image (AMI) that includes the AWS Systems Manager Agent, and then choose Select.Note: The agent is included in all AWS-provided AMIs for Windows Server 2016 and Windows Server 2019, and in Windows Server 2008-2012 R2 AMIs published in November 2016 or later. For more details, see Installing and configuring SSM Agent on Windows Server instances.For Choose an Instance Type, select the hardware configuration and size of the instance that you want to launch, and then choose Next: Configure Instance Details.For Configure Instance Details, enter the following:For Domain join directory, choose the Directory ID of the AWS Directory Service directory.For IAM role, choose an IAM instance profile role that is configured for Systems Manager and directory join access. For more details, see Create an IAM instance profile for Systems Manager.Review and update the remaining instance configuration details to meet your requirements, and then continue following the launch wizard steps. When you reach the Review Instance Launch page, choose Launch. For more information, see Launching an instance using the Launch Instance Wizard.Verify that the instance successfully joined the domainOpen the AWS Systems Manager console, choose your Region, and then choose Managed Instances from the navigation pane.Select the instance in the list, then choose Associations.Locate the association used to join the domain, which has a Document name in the following format: awsconfig_Domain_<DIRECTORYID>_<DOMAIN_NAME>.Verify that the Association status is Success.TroubleshootingIf the instance fails to join the directory domain, verify that the instance is able to communicate with Directory Service using the DirectoryServicePortTest application.For more information about working with the AWS Systems Manager agent and other troubleshooting steps, see AWS Systems Manager Managed Instances.For more troubleshooting strategies, see How to troubleshoot errors that occur when you join Windows-based computers to a domain on the Microsoft website.Related InformationWhat Is AWS Directory Service?How do I use AWS Systems Manager to join a running EC2 Windows instance to my AWS Directory Service domain?How can I manage an AWS Managed Microsoft AD or Simple AD directory from an Amazon EC2 Windows instance?Follow"


Question: How do I resolve "MalformedPolicyDocument" errors in AWS CloudFormation?

"When I try to create or update an AWS CloudFormation stack, I get a "MalformedPolicyDocument" error message. I still get the error, even after I validate the template."

Answer: "When I try to create or update an AWS CloudFormation stack, I get a "MalformedPolicyDocument" error message. I still get the error, even after I validate the template.Short descriptionThe ValidateTemplate API in AWS CloudFormation can validate only the syntax of your template. The API can't validate the property values that you specify for a resource. Because a policy document is configured as part of the property value, the validity of the policy isn't verified.You get the "MalformedPolicyDocument" error when the policy document isn't syntactically or semantically correct, according to the grammar of the policy language.To resolve this error, you must confirm that the policy document is valid for the particular resource type that it's a part of.ResolutionLook for error message details in your stack eventsOpen the AWS CloudFormation console.From the navigation pane, choose Stacks.Choose the stack that returned the error, and then choose the Events tab.Search the Status reason column for a message that explains the cause of the error.If you still can't find the cause of the error, then complete the steps in the Get more information on the AWS CloudTrail event that caused the error section.Get more information on the AWS CloudTrail event that caused the errorYou can get a more information by checking the errorMessage property of the CloudTrail event for the operation on your resource type that caused the error.For example, if "MalformedPolicyDocument" results from an error in an inline policy that's attached to an AWS Identity and Access Management (IAM) role, complete the following steps:Open the AWS CloudTrail console.From the navigation pane, choose Event history.In the Filter search box, select Event name as the lookup attribute, and then enter PutRolePolicy in the corresponding text box.For Time range, set the time of the CloudTrail event to the time that you see in the error message shown in AWS CloudFormation events.In the Event name column, choose your event.From the Event record, check the value of the errorMessage property for a detailed message.Validate the policy passed in the CloudTrail eventThe CloudTrail event for the API-level action on the resource that's causing the error usually contains the resolved form of the policy document. You can copy this resolved policy document, and then create a new policy in the AWS Management Console directly for that particular resource.For example, if "MalformedPolicyDocument" results from an error in an inline policy attached to an IAM role, complete the following steps:Open the CloudTrail console.From the navigation pane, choose Event history.In the Filter search box, select Event name as the lookup attribute, and then enter PutRolePolicy in the corresponding text box.For Time range, set the time of the CloudTrail event to the time that you see in the error message shown in AWS CloudFormation events.In the Event name column, choose your event.From the Event record, copy the value of the policyDocument property under the requestParameters.In a text editor, remove any "" escape characters from the policy document.Open the IAM console.From the navigation pane, choose Policies.Choose Create policy, and then choose the JSON tab.Enter the policy document that you copied from step 6, and then choose Review policy.Check the contents of the error message shown in the red dialogue box at the beginning of the page. The error message provides a more detailed explanation of the validation failure of the policy.Related informationGrammar of the IAM JSON policy languageIAM JSON policy elements referenceFollow"


Question: How can I tag my AWS resources to divide up my bill by cost center or project?

"I want to track my Amazon Web Services (AWS) usage and spending across different projects, cost centers, or development environments."

Answer: "I want to track my Amazon Web Services (AWS) usage and spending across different projects, cost centers, or development environments.ResolutionTags are key-value pairs that let you organize your AWS resources into groups.To locate and tag resources, use the Tag Editor console. For instructions on tagging, see Finding resources to tag.Note: Not all resources support tags. For the list of resources that can be tagged, see Supported resources.You can use tags to:Visualize information about tagged resources in one place in conjunction with AWS resource groups.View billing information using AWS Cost Explorer and AWS Cost and Usage Reports.Send notifications about spending limits by Configuring a budget action.Use logical groupings of your resources that make sense for your infrastructure or business.For example, you can organize your resources by:ProjectCost centerDevelopment environmentApplicationDepartmentUse user-defined cost allocation tags to create cost allocation tags for your use case.Related informationUsing AWS cost allocation tagsFollow"


Question: Why do my Amazon Athena queries take a long time to run?

My Amazon Athena queries are taking a long time to run. The query queuing times are high. How can I speed up the query processing?

Answer: "My Amazon Athena queries are taking a long time to run. The query queuing times are high. How can I speed up the query processing?Short descriptionAthena is a serverless interactive query service. After you submit your queries to Athena, the queries are run on a pool of resources in the backend. These resources are shared by all users in the Region. Your queries might be temporarily queued before they run. Queries generally take a long time to run because of either a higher queuing time or a higher engine processing time.ResolutionCall the GetQueryExecution API for your query ID. This API returns information about a single processing of the query. The information includes useful details, such as the following:Time spent by the query in queuing (QueryQueueTimeInMillis)Time spent by the query in planning (QueryPlanningTimeInMillis)Engine processing time (EngineExecutionTimeInMillis)This information can be viewed in the Statistics parameter of the API response.Higher queueing timeYour queries might have a higher queuing time because of high resource usage in the backend. The queuing time in Athena is dependent on resource allocation. After you submit your queries to Athena, the queries are processed by assigning resources based on the following:Overall service loadNumber of incoming requestsIf your queries have a higher queuing time, then do the following to improve query performance:Consider distributing your queries over a period of time. If you submit queries in batches, then submit small batches more frequently rather than submitting large batches less frequently. This might reduce the time a query stays in QUEUED state and improve the overall query processing time.Run a combination of simple and complex queries instead of running a set of complex queries at the same time. Also, consider submitting simple queries first followed by complex queries. Because simple queries are processed quickly, resources can be allocated to the complex queries without incurring a higher queuing time.If you are scheduling your queries in scenarios, such as generating periodic reports or loading new partitions, then avoid scheduling them at the start of the hour and 30 minutes past the hour timeframes. Most automated scripts and cron jobs are run during these timeframes. Therefore, the service load is usually higher during these periods, resulting in increased queuing times.If your use case permits, run your queries in multiple Regions. This can distribute the load and help acquire more backend resources. This approach can reduce the query queuing time.Important: You might incur Amazon Simple Storage Service (Amazon S3) cross-Region charges.Higher planning timeIf your queries have a higher planning time, it might be caused by over-partitioning the table. Tables with hundreds or thousands of partitions can result in slower query processing. To improve query performance, try one or more of the following:Consider reducing the number of partitions.Query over one partition at a time and concatenate the results.Use partition projection to help speed up query processing of highly partitioned tables and automate partition management.Higher processing timeIf your queries have a higher engine processing time, then do the following to improve query performance:Partition your tables to restrict the amount of data scanned by each query. Partitions act as virtual columns and keeps related data together based on column values. Partitioning your tables can improve query performance and reduce costs. For more information, see Partitioning data.If the Amazon S3 file that you query is small (generally less than 128 MB), then the query processing time might be higher. The increase in time is due to the overhead involved in tasks, such as opening the S3 file, listing directories, and setting up data transfer. Use the S3DistCp utility on Amazon EMR to combine smaller S3 files into larger objects. Larger objects require fewer Amazon S3 requests, which reduces the query processing time.Perform other storage and query optimizations to improve performance and lower the engine processing times. For more information, see Top 10 performance tuning tips for Amazon Athena.Note: You can submit several queries to Athena at the same time based on the default query-related quotas in your Region. Athena processes queries by assigning resources based on the overall service load and the number of incoming requests. Therefore, all your submitted queries might not run concurrently.Related informationPerformance tuning in AthenaFollow"


Question: How do I resolve an “authorization error" when attempting to view or modify a cross-account SQS subscription's attributes on the Amazon SNS console?

"I subscribed my Amazon Simple Queue Service (Amazon SQS) queue to an Amazon Simple Notification Service (Amazon SNS) topic in a different AWS account. When viewing or editing my cross-account subscription’s attributes from the Amazon SNS console, I get an "authorization error" that I need to resolve."

Answer: "I subscribed my Amazon Simple Queue Service (Amazon SQS) queue to an Amazon Simple Notification Service (Amazon SNS) topic in a different AWS account. When viewing or editing my cross-account subscription’s attributes from the Amazon SNS console, I get an "authorization error" that I need to resolve.Short descriptionIf you create a SNS topic subscription for an SQS queue from an account that doesn't own the topic, then the account that owns the SQS queue owns the subscription. If you then view or edit SNS subscription attributes in the account that created the SNS topic, you get an authorization error.Note: Subscription-related permissions to view and edit can't be included in SNS Topic Policy actions. Use the following solutions instead.ResolutionUsing the AWS consoleOpen the Amazon SNS console in the account that owns the SNS topic.In the navigation pane, choose Topics.Choose the name of the topic. Then, from the Subscriptions tab, copy the Subscription ID of the SQS queue subscription.Open the Amazon SNS console in the account that owns the SQS queue.On the Subscriptions menu option, choose the Subscription ID that you copied in step 3.View and edit the subscription attributes as needed.Using GetSubscriptionAttributesNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.View subscription attributes by using GetSubscriptionAttributes in the account that was used to create the subscription using the AWS Command Line Interface (AWS CLI) or the SDK. To run this command, the IAM user or role must have permissions for the SNS actions SetSubscriptionAttributes and GetSubscriptionAttributes.The following example uses the GetSubscriptionAttributes from the AWS CLI, using SubscriptionArn as a request parameter. To retrieve SubscriptionArn, use ListSubscriptionsByTopic.aws sns get-subscription-attributes --subscription-arn arn:aws:sns:eu-central-1:1234567890:TestTopicSubOwnerSQS:53XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX{  "Attributes": {    "Owner": "9876543210",    "RawMessageDelivery": "false",    "TopicArn": "arn:aws:sns:eu-central-1:1234567890:TestTopicSubOwnerSQS",    "Endpoint": "example@amazon.com",    "Protocol": "email",    "PendingConfirmation": "false",    "ConfirmationWasAuthenticated": "false",    "SubscriptionArn": "arn:aws:sns:eu-central-1:1234567890:TestTopicSubOwnerSQS:53XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"   }}Delete and recreate the subscriptionIf you want the AWS account that owns the SNS topic to control the SNS topic subscription's attributes:Delete the existing subscription.Create the same subscription from the account that owns the SNS topic.The AWS account that owns the SNS topic is now the owner of the created subscription resource.Related informationHow do I recreate a "Deleted" Amazon SNS topic subscription for an Amazon SQS queue in another AWS account?How do I resolve authorization errors when trying to add subscribers to an Amazon SNS topic?How do I resolve HTTP 400 “AccessDeniedException” errors from Amazon SNS?How can I get my Amazon SQS subscription to successfully receive a notification from my Amazon SNS topic?Why do I get an authorization error when I try to subscribe my Lambda function to my Amazon SNS topic?Follow"


Question: How do I stop AWS OpsWorks Stacks from unexpectedly restarting healthy instances?

"AWS OpsWorks Stacks restarts my Amazon Elastic Compute Cloud (Amazon EC2) instances, even if the instances pass Amazon EC2 health checks. Why is this happening and how do I stop it?"

Answer: "AWS OpsWorks Stacks restarts my Amazon Elastic Compute Cloud (Amazon EC2) instances, even if the instances pass Amazon EC2 health checks. Why is this happening and how do I stop it?Short descriptionIf the OpsWorks Stacks auto healing feature is activated and the service determines that an instance it manages fails, one of the following occurs:If the instance is backed by Amazon Elastic Block Store (Amazon EBS), then the OpsWorks Stacks API stops and starts the failed instance.If the instance is backed by an Amazon EC2 instance store, the instance is terminated. Then, the instance is recreated when OpsWorks Stacks starts the instance again.If the instance is registered with an OpsWorks stack and is on-premises, then the instance's status is changed to connection lost, but isn't restarted.To prevent OpsWorks Stacks from auto healing the instances that it manages, first follow the troubleshooting steps in this article. If the problem persists, you can also turn off auto healing in your OpsWorks Stacks layer's General Settings.For more information, see Instances unexpectedly restart in the AWS OpsWorks debugging and troubleshooting guide.ResolutionVerify that the Amazon EC2 instances that are managed by OpsWorks Stacks have internet accessIf an Amazon EC2 instance loses its connection to the OpsWorks Stacks service, then OpsWorks Stacks treats the instance as failed.To verify that your Amazon EC2 instances have internet access, do the following:Make sure that your instances have access to the internet through either an internet gateway or Network Address Translation (NAT) gateway.Verify that inbound HTTPS access is allowed through port 443 at the instance, security group, and network access control list (network ACL) level.To troubleshoot NAT gateway connectivity issues, see Why can't my EC2 instances access the internet using a NAT gateway?To troubleshoot internet gateway connectivity issues, see Why can't my Amazon EC2 instance connect to the internet using an internet gateway?Verify that your application has enough memory and CPU capacity at the instance level to function when the instance is under extra loadWhen there aren't enough instance-level resources to allow the OpsWorks agent to send its keepalive signal, OpsWorks Stacks treats the instance as failed.To review your instances' metrics, follow the instructions in Monitoring stacks using Amazon CloudWatch.To set alarms to warn you if your instance has a high load of CPU, memory, or network traffic, see Creating Amazon CloudWatch alarms.Verify that the Amazon EC2 instance wasn't stopped outside of the OpsWorks Stacks console or the OpsWorks Stacks APINote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.If an OpsWorks Stacks-managed instance is stopped in the Amazon EC2 console, then OpsWorks Stacks stops receiving the keepalive signal from the OpsWorks agent. OpsWorks Stacks then treats the instance as failed.To verify if your instance was stopped in the Amazon EC2 console, then try stopping the instance in the OpsWorks Stacks console. If the instance is in the stop_failed state and you receive an Internal Error message, then the instance was stopped in the Amazon EC2 console.To stop an instance in OpsWorks Stacks after it has been stopped in the Amazon EC2 console, run the AWS CLI stop-instance command.Important: The stop-instance command must include the --force parameter for this use case.For more information, see How do I troubleshoot "Internal Error" messages when stopping an AWS OpsWorks Stacks instance that's in the "stop_failed" state?Verify that the Amazon EC2 instance uses Instance Metadata Service Version 1 (IMDSv1)OpsWorks Stacks supports IMDSv1 only, not IMDSv2. If an OpsWorks Stacks-managed instance uses IMDSv2, OpsWorks Stacks treats the instance as failed.To check what metadata service your instance uses and to reconfigure the instance if needed, see Configure the instance metadata options.Related informationWhat is Amazon CloudWatch Logs?Instances unexpectedly restartMonitoring AWS Systems ManagerFollow"


Question: How can I provide granular access to Lambda functions?

I want to grant read and write access to a specific AWS Lambda function that's identified by its Amazon Resource Name (ARN). How can I provide granular access to Lambda functions?

Answer: "I want to grant read and write access to a specific AWS Lambda function that's identified by its Amazon Resource Name (ARN). How can I provide granular access to Lambda functions?Short descriptionYou can configure the permissions for Lambda functions using AWS Identity and Access Management (IAM) policies to:Create a Lambda functionDelete a Lambda functionView the configuration details of a Lambda functionModify a Lambda functionInvoke a Lambda functionMonitor a Lambda functionIn the following policy examples, Lambda API actions that support resource-level permissions are restricted to a specific Lambda function that is listed in the Resource element of each statement. A specific function name is used in the Condition element for API actions that support those elements.API actions that don't support resource-level permissions require a wildcard ("*") in the Resource element, and can't apply any Lambda service-specific condition keys. For more information about IAM actions, resources, and conditions that are supported by Lambda, see actions, resources, and condition keys for AWS Lambda.The value of a statement's Resource element uses the ARN to identify the resources that the statement applies to. For example, when the Action is Invoke, then the Resource is a function ARN. IAM matches this ARN against the ARN of the function that's identified by the FunctionName and Qualifier parameters of an Invoke request. For more information, see AWS Lambda function versions.Note: If you use multiple versions and aliases, you might need to include "arn:aws:lambda:region:AccountID:function:function_name:*" in the resource element.ResolutionPermissions required to create a Lambda functionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Both lambda:CreateFunction and iam:PassRole permissions are required to create a Lambda function using the AWS Command Line Interface (AWS CLI) or an SDK. For example policies, see Identity-based IAM policies for AWS Lambda. The following policy allows the API caller to create a Lambda function, pass the IAM role as the Lambda execution role for the function, and then upload the code from your local machine:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionToCreateFunction",      "Effect": "Allow",      "Action": [        "lambda:CreateFunction"      ],      "Resource": [        "arn:aws:lambda:region:AccountID:function:function_name"      ]    },    {      "Sid": "PermissionToPassARole",      "Effect": "Allow",      "Action": [        "iam:PassRole"      ],      "Resource": "arn:aws:iam::AccountID:role/role_name"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.If you upload the code from an Amazon Simple Storage Service (Amazon S3) bucket, then add a policy similar to the following to the existing IAM policy to grant the required permissions for Amazon S3:...{  "Sid": "PermissionToUploadCodeFromS3",  "Effect": "Allow",  "Action": "s3:GetObject",  "Resource": "arn:aws:s3:::S3BucketName/FileName.zip"}...Note: Update the policy to include your relevant S3 bucket and file names.Because the code can't be provided when the function is created in the Lambda console, API permissions, such as read-level API actions and permission to view and update the function, are required. Add a policy similar to the following to grant these permissions:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionsToViewFunctionsInConsole",      "Effect": "Allow",      "Action": [        "lambda:ListFunctions",        "lambda:GetAccountSettings"      ],      "Resource": "*"    },    {      "Sid": "PermissionsToCreateAndUpdateFunction",      "Effect": "Allow",      "Action": [        "lambda:CreateFunction",        "lambda:GetFunction",        "lambda:UpdateFunctionCode"      ],      "Resource": [        "arn:aws:lambda:region:AccountID:function:function_name"      ]    },    {      "Sid": "PermissionToListExistingRoles",      "Effect": "Allow",      "Action": [        "iam:ListRoles"      ],      "Resource": "*"    },    {      "Sid": "PermissionToPassARole",      "Effect": "Allow",      "Action": [        "iam:PassRole"      ],      "Resource": "arn:aws:iam::AccountID:role/role_name"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.To create an IAM role during the Lambda function creation process, add additional IAM permissions similar to the following:...{  "Sid": "PermmissionsToCreateAndUpdateARole",  "Effect": "Allow",  "Action": [    "iam:CreateRole",    "iam:CreatePolicy",    "iam:PutRolePolicy",    "iam:AttachRolePolicy"  ],  "Resource": "*"}...Permissions required to delete a Lambda functionTo delete a Lambda function using the AWS CLI or an SDK, add permissions similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionToDeleteFunction",      "Effect": "Allow",      "Action": [        "lambda:DeleteFunction"      ],      "Resource": [        "arn:aws:lambda:region:AccountID:function:function_name"      ]    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.To delete a Lambda function using the Lambda console, add Lambda read access permissions similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionsToViewFunctionsInConsole",      "Effect": "Allow",      "Action": [        "lambda:ListFunctions",        "lambda:GetAccountSettings"      ],      "Resource": "*"    },    {      "Sid": "PermissionToDeleteFunction",      "Effect": "Allow",      "Action": [        "lambda:DeleteFunction"      ],      "Resource": [        "arn:aws:lambda:region:AccountID:function:function_name"      ]    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.Permissions required to view the configuration details of a Lambda functionTo give a user permission to view the configuration details of a Lambda function, add permissions similar to the following:Note: Depending upon the level of read access that you want to grant, you might need to grant all or a subset of following permissions when using the AWS CLI or an SDK.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "ActionsWhichSupportResourceLevelPermissions",      "Effect": "Allow",      "Action": [        "lambda:GetFunction",        "lambda:GetFunctionConfiguration",        "lambda:GetPolicy",        "lambda:GetAlias",        "lambda:ListVersionsByFunction",        "lambda:ListAliases"      ],      "Resource": [        "arn:aws:lambda:region:AccountID:function:function_name"      ]    },    {      "Sid": "ActionsWhichDoNotSupportResourceLevelPermissions",      "Effect": "Allow",      "Action": [        "lambda:ListTags",        "lambda:GetEventSourceMapping",        "lambda:ListEventSourceMappings"      ],      "Resource": "*"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.To view the configuration details of a function by using the Lambda console, add permissions similar to the following:...{  "Sid": "PermissionsToViewFunctionsInConsole",  "Effect": "Allow",  "Action": [    "lambda:ListFunctions",    "lambda:GetAccountSettings"  ],  "Resource": "*"}...The Lambda console uses the tagging Lambda functions allowing you to filter Lambda functions by tags. To use the AWS Tagging Service, add permissions similar to the following:...{  "Sid": "PermissionsToFilterFunctionsByTags",  "Effect": "Allow",  "Action": [     "tag:GetResources"  ],  "Resource": "*"}...The Lambda console displays details about the IAM role that is associated with a Lambda function and the resources that the function's IAM role has access to. To view these details, add permissions similar to the following:...{  "Sid": "PermissionsToViewRolesAndPolicies",  "Effect": "Allow",  "Action": [    "iam:GetPolicy",    "iam:GetPolicyVersion",    "iam:GetRolePolicy",    "iam:ListRoles",    "iam:ListRolePolicies",    "iam:ListAttachedRolePolicies"  ],  "Resource": "*"}...Note: Depending upon your requirements and the services integrated with your Lambda function, you might need to grant additional permissions for other AWS services. For more information, see AWS Lambda permissions.Permissions required to modify a Lambda functionTo give a user permission to modify a Lambda function, add permissions similar to the following:Note: Depending upon the level of write access that you want to grant, you might need to grant all or a subset of the following permissions when using the AWS CLI or an SDK.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "ActionsWhichSupportResourceLevelPermissions",      "Effect": "Allow",      "Action": [        "lambda:AddPermission",        "lambda:RemovePermission",        "lambda:CreateAlias",        "lambda:UpdateAlias",        "lambda:DeleteAlias",        "lambda:UpdateFunctionCode",        "lambda:UpdateFunctionConfiguration",        "lambda:PutFunctionConcurrency",        "lambda:DeleteFunctionConcurrency",        "lambda:PublishVersion"      ],      "Resource": "arn:aws:lambda:region:AccountID:function:function_name"    },    {      "Sid": "ActionsWhichSupportCondition",      "Effect": "Allow",      "Action": [        "lambda:CreateEventSourceMapping",        "lambda:UpdateEventSourceMapping",        "lambda:DeleteEventSourceMapping"      ],      "Resource": "*",      "Condition": {        "StringEquals": {          "lambda:FunctionArn": "arn:aws:lambda:region:AccountID:function:function_name"        }      }    },    {      "Sid": "ActionsWhichDoNotSupportResourceLevelPermissions",      "Effect": "Allow",      "Action": [        "lambda:UntagResource",        "lambda:TagResource"      ],      "Resource": "*"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.You can further restrict access using lambda:AddPermission and lambda:RemovePermission to a principal that is included in a passed policy. You can also limit lambda:UpdateEventSourceMapping  and lambda:DeleteEventSourceMapping to a particular event source mapping. For more information, see Identity-based IAM policies for AWS Lambda.To specify a customer managed AWS Key Management Service (AWS KMS) key to encrypt environment variables, add additional KMS permissions by using an IAM policy snippet similar to the following:...{  "Sid": "PermissionsForCryptoOperations",  "Effect": "Allow",  "Action": [    "kms:Encrypt",    "kms:Decrypt",    "kms:CreateGrant"  ],  "Resource": "arn:aws:kms:region:AccountID:key/keyID"},{  "Sid": "PermissionsToListExistingKeys",  "Effect": "Allow",  "Action": [    "kms:ListKeys",    "kms:ListAliases"  ],  "Resource": "*"}...Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.To modify a Lambda function's configurations using the Lambda console, add permissions similar to the following:...{  "Sid": "PermissionsToViewFunctionsInConsole",  "Effect": "Allow",  "Action": [    "lambda:ListFunctions",    "lambda:GetAccountSettings"  ],  "Resource": "*"}...Permissions required to invoke a Lambda functionTo manually invoke a Lambda function for testing purposes using the AWS CLI or an SDK, add permissions similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionToInvoke",      "Effect": "Allow",      "Action": "lambda:InvokeFunction",      "Resource": "arn:aws:lambda:region:AccountID:function:function_name"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.To list Lambda functions using the Lambda console, add permissions similar to the following:...{  "Sid": "PermissionsToViewFunctionsConfigInConsole",  "Effect": "Allow",  "Action": [    "lambda:ListFunctions",    "lambda:GetAccountSettings",    "lambda:GetFunction"  ],  "Resource": "*"}...To allow other services to invoke a Lambda function, use resource-based policies for AWS Lambda. You can also use function policies to provide cross-account access to Lambda functions. The following example policy can be used to allow a user from a different AWS account to manually invoke a Lambda function:{  "Version": "2012-10-17",  "Id": "default",  "Statement": [    {      "Sid": "PermissionToInvoke",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::ExternalAccountID:user/username"      },      "Action": "lambda:InvokeFunction",      "Resource": "arn:aws:lambda:region:AccountID:function:function_name"    }  ]}Note: Update the policy to include your relevant Region, account ID, function name, ARN, and so on.Permissions required to monitor Lambda functionsTo view Amazon CloudWatch metrics in the Monitoring view of the Lambda console, add permissions similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PermissionForCloudWatchMetrics",       "Effect": "Allow",       "Action": [          "cloudwatch:GetMetricStatistics",          "cloudwatch:GetMetricData"        ],        "Resource": "*"     }  ]}To grant permission to specific CloudWatch metrics and CloudWatch Logs Insights, see Amazon CloudWatch permissions reference and CloudWatch logs permissions reference.Follow"


Question: What are the best practices for migrating a RDBMS database to Amazon Redshift using AWS DMS?

I have a Relational Database Management System (RDBMS) database that I want to migrate to Amazon Redshift using the AWS Database Migration Service (AWS DMS). What are some best practices that I can follow when migrating an RDBMS database to Amazon Redshift?

Answer: "I have a Relational Database Management System (RDBMS) database that I want to migrate to Amazon Redshift using the AWS Database Migration Service (AWS DMS). What are some best practices that I can follow when migrating an RDBMS database to Amazon Redshift?ResolutionUse the best practices in this article to help you migrate RDBMS databases to Amazon Redshift using AWS DMS.Use parallel load with your table-setting rules when you migrate data to an Amazon Redshift endpoint. For more information on using parallel load, and how it can be used to speed up migration, see Using parallel load for selected tables, views, and collections.AWS DMS versions 3.4.5 and later include support for the use of the ParallelLoad task settings during full load to Amazon Redshift target endpoints. For more information, see Multithreaded full load task settings for Amazon Redshift.If you are migrating a large amount of data to Amazon Redshift, increase the endpoint attribute values for maxFileSize and fileTransferUploadStreams. Doing this can help improve full load performance. Then, increase CommitRate value to improve performance.Because AWS DMS doesn't support Full Lob Mode when you use Amazon Redshift as a target for your databases, be sure to configure LobMaxSize to an appropriate value.Make sure that your Amazon Redshift tables have a primary key. If your target table doesn't have a primary key, then inserts are made in BatchApply mode. But because updates and deletes are then applied one-by-one, this affects performance. So, be sure that AWS DMS migrates CDC data in batches to the Amazon Redshift target to avoid any performance issues.Adjust the batch apply settings according to the workload to reduce the number of commits on the target. Batch apply settings include BatchApplyTimeoutMin, BatchApplyTimeoutMax, and BatchApplyMemoryLimit.Use BatchSplitSize to set the maximum number of changes applied in a single batch. The default value is 0, which means that there is no limit applied.Create target Amazon Redshift tables with the appropriate distribution and sort keys. When AWS DMS creates tables for Amazon Redshift targets, it creates tables with a default distribution key and no sort keys. Amazon Redshift stores data on disk in a sorted order, according to the sort key. The Amazon Redshift query optimizer uses sort order when determining optimal query plans. So, when you run a query, the query optimizer redistributes rows to the compute nodes as needed to perform any joins and aggregations. For more information, see Choose the best sort key and Working with data distribution styles.If you have a heavy transactional workload, use settings similar to these. These example settings mean that an 8000-MB batch buffer is filled in 1800 seconds, using 32 parallel threads, and with a 250-MB maximum file size. Amazon Redshift endpoint settings:MaxFileSize=250000;Task settings:BatchApplyEnabled=true;BatchSplitSize =8000;BatchApplyTimeoutMax =1800;BatchApplyTimeoutMin =1800;ParallelApplyThreads=32;ParallelApplyBufferSize=100;Make sure that there are no locks or blocking sessions present in Amazon Redshift. For more information, see How do I detect and release locks in Amazon Redshift?Use the Amazon Redshift Workload Management (WLM) tool to manage your workload. Amazon Redshift WLM can be used to define multiple query queues, and to route queries to the appropriate queues at runtime. For more information, see Workload management.Related informationUsing an Amazon Redshift database as a target for AWS Database Migration ServiceHow can I use Amazon Redshift as the target endpoint for my AWS DMS task?Follow"


Question: How do I limit access to my endpoints that are behind the AWS Global Accelerator?

I want to limit access to my endpoints by configuring security group rules on endpoints.

Answer: "I want to limit access to my endpoints by configuring security group rules on endpoints.Short descriptionAWS Global Accelerator can have Application Load Balancers, Network Load Balancers, Amazon Elastic Compute Cloud (Amazon EC2) instances, or Elastic IP addresses as endpoints. Limiting access to these endpoint depends on whether the endpoint has source IP preservation turned on or off.ResolutionSource IP preservation is onWhen you use an internal Application Load Balancer or an EC2 instance with Global Accelerator, the endpoint always has its client IP address preservation tuned on. The IP address preservation, by default, is always on for new accelerators in an internet-facing Application Load Balancer that’s an endpoint with the accelerator. In this setup, the endpoints only see real client IP addresses instead of the Global Accelerator’s IP addresses. You can limit access to these endpoints as follows:Configure the security groups on endpoints to allow connection from known client IP addresses.Launch the endpoint in a private subnet so that client can only access the endpoint through Global Accelerator.Source IP preservation is offYou've the option to turn off client IP preservation when you use one of the following as an endpoint:an external-facing Application Load Balancera Network Load Balanceran Elastic IP addressIn this setup, the endpoint only sees Global Accelerator’s IP addresses.Because Global Accelerator uses a range of IP addresses, you must create a prefix list for Global Accelerator’s IP ranges. A prefix list is a set of one or more CIDR blocks, which you can reference in your VPC security group’s rules to restrict access. Install the necessary tools to create a custom prefix list. Then, configure it to allow connections to the endpoint, only if they originate through AWS Global Accelerator.Install the toolsInstall the following tools to build the custom prefix list:Install AWS CLI with the correct security credentials and access settings.Note: If you receive errors when running the CLI commands, make sure that you're using the most recent version of AWS CLI.Install 'jq' on Amazon Linux 2. Run:sudo yum install -y jqInstall Aggeregate6 from GitHub:sudo yum install -y python3 python3-devel python-pippip3 install --user aggregate6  Create a custom prefix listAWS publishes its current IP address ranges in ip-ranges.json.Identify the IP address ranges that are associated with AWS Global Accelerator's edge servers.Compress the list to generate an IP prefix. Use it as an argument to create a custom prefix list, as shown below:aws ec2 create-managed-prefix-list --prefix-list-name <name-of-prefix-list> --address-family ipv4 --max-entries 99 --entries=$(curl -s https://ip-ranges.amazonaws.com/ip-ranges.json |jq -r '.prefixes[] |select( .service == "GLOBALACCELERATOR" ) |select( .region != "GLOBAL" ) |.ip_prefix' |aggregate6 |jq -R -M '{"Cidr": .}' |jq -s -c -M)Note: Replace <name-of-prefix-list> with the name of your list.Review the output. It must look similar to this:{    "PrefixList": {        "PrefixListId": "pl-0abcde123456789",        "AddressFamily": "IPv4",        "State": "create-in-progress",        "PrefixListArn": "arn:aws:ec2:us-east-1:1234567890:prefix-list/pl-0abcde123456789",        "PrefixListName": "aga-regional-all",        "MaxEntries": 99,        "Version": 1,        "Tags": [],        "OwnerId": "1234567890"    }}View the IP addresses in this prefix list as follows:aws ec2 get-managed-prefix-list-entries --prefix-list-id <prefix-list-id>Note: Replace <prefix-list-id> with the ID of your list.Add the custom prefix list to the security groupSpecify the prefix list that you created earlier as the source for an inbound rule on the security group associated with the accelerator’s endpoint. For more information on referencing prefix list in a security group, see VPC security groups.Related informationLocation and IP address ranges of Global Accelerator Edge serversGroup CIDR blocks using managed prefix listsFollow"


Question: "How can I allow communication between multiple VPCs from a single VPN connection attached to my transit gateway, without allowing access between the VPCs?"

I have two virtual private clouds (VPCs). On-premises users need access to both VPCs with a single VPN connection. I want to establish network connectivity between the VPCs and the on-premises network through a single VPN connection. How can I do this?

Answer: "I have two virtual private clouds (VPCs). On-premises users need access to both VPCs with a single VPN connection. I want to establish network connectivity between the VPCs and the on-premises network through a single VPN connection. How can I do this?Short descriptionIf you have two VPCs, such as a production and development environments, with a single VPN connection, follow these steps to establish network connectivity between resources in multiple VPCs so that:On-premises users can access resources from all VPCs across the VPNVPC resources can't access resources in the other VPCsResolutionCreate a transit gateway, and then attach your VPCs and a site-to-site VPNIn the Amazon Virtual Private Cloud (Amazon VPC) console, create a transit gateway.Note: Turn off the Default association route table setting when creating your transit gateway.Attach your VPCs to your transit gateway.Create a site-to-site VPN connection and attach it to your transit gateway.Note: To automatically propagate VPN routes to the transit gateway route table, choose Dynamic for Routing option. This option requires Border Gateway Protocol.Create a transit gateway route table and associate it with your VPCsOpen the Amazon VPC console.From the navigation pane, choose Transit gateways.Verify that the Default association route table setting for your transit gateway is set to Disable.Note: If Default associate route table is set to Enable, skip to step 9.Choose Transit gateway route tables.Choose Create transit gateway route table.For Name tag, enter Route Table A.For Transit gateway ID, choose the ID for your transit gateway.Then, choose Create transit gateway route table.Choose the Route Table A that you created in the previous step, or the default route table of your transit gateway.Choose Associations, then choose Create association.For Choose attachment to associate, choose the association IDs for your VPCs. Then, choose Create association. Repeat this step until all of your VPCs display under Association.Delete the VPN association from default transit gateway route table.Create a second transit gateway route table and associate it with your VPN connectionIn the Amazon VPC console, choose Transit gateway route tables.Choose Create transit gateway route table.For Name tag, enter Route Table B.For Transit gateway ID, choose the ID for your transit gateway..Then, choose Create transit gateway route table.Choose the Route Table B that you created in the previous stepChoose Associations, then choose Create association.Associate the VPN connection that you created with Route Table B.Propagate routes from your VPCs and VPN to both route tablesIn the Amazon VPC console, choose Transit gateway route tables.Select Route Table A.Choose Actions, and then choose Create propagation.For Choose attachment to propagate, choose the propagation for the VPN. If you have propagation enabled for all of the attachments, verify that the VPN connection association is not enabled in this route table.Important: If you created a static route VPN connection, rather than dynamic routing, you must create a static route for the on-premises network to the VPN on Route Table A. For policy-based static VPN connections, only one pair of security association (SA) is allowed. Consolidate the on-premises CIDR and CIDR of VPCs to a single SA. For more information, see How do I troubleshoot connection problems between an AWS VPN endpoint and a policy-based VPN?Choose Create propagation.From the Transit gateway route tables, select Route table B.Choose Actions, and then choose Create propagation.For Choose attachment to propagate, choose the propagation for all of the VPCs. Then, choose Create propagation.Configure the route table associated with your VPC and attachment subnetIn the Amazon VPC console, choose Route tables.Choose the route table that's attached to the attachment subnet.Choose the Routes tab, and then choose Edit routes.Choose the Add route tab.For Destination, choose the subnet of the on-premises network.For Target, choose your transit gateway.Choose Save routes.Note: If your use case requires more restrictive access between your VPCs, create a separate route table for each VPC and configure the routes. Keep in mind:Routing in the transit gateway route table is based on the association of the transit gateway association and the transit gateway route table.You can configure routes to any destination in the transit gateway attachment in any transit gateway route table. The transit gateway attachment doesn't need to be associated with that specific route table.Follow"


Question: How can I configure private and public Aurora endpoints in the Amazon RDS console?

How can I configure private and public Amazon Aurora endpoints for Aurora DB instances running in the Amazon Relational Database Service (Amazon RDS)?

Answer: "How can I configure private and public Amazon Aurora endpoints for Aurora DB instances running in the Amazon Relational Database Service (Amazon RDS)?Short descriptionAn Amazon Aurora cluster can be launched only in Amazon Virtual Private Cloud (Amazon VPC), based on the Amazon VPC service. The DB subnet group that you choose for your DB cluster must span at least two Availability Zones in the Region you want to deploy your cluster. For the Aurora DB instance to be publicly accessible, or accessible only inside the VPC, configure the following two settings, one at the VPC subnet level, and the second at the DB instance level.You can make your DB subnets public or private-only based on the route table associated with the subnet. Be sure that the subnets in the DB subnet group all have the same configuration to avoid any connection issues after the failover.At the DB instance level, you can set the publicly accessible parameter to yes or no. This determines whether your DB instance is reachable through the internet or not.It's also important to make sure that the VPC security group used by the DB instance allows the source IP address or CIDR range. For more information, see Security group rules for different use cases.ResolutionCreating a publicly accessible Aurora DB clusterWhen creating an Amazon Aurora DB cluster using the AWS Management Console, Amazon RDS automatically creates a VPC for you. Or you can use an existing VPC or create a new VPC for your Aurora DB cluster.Create a DB subnet group that defines at least two subnets in the VPC. Make sure that the route table associated with the subnets is configured for public access.Create an Aurora DB cluster in the VPC.On the Create database pane, from the Connectivity section, select the Virtual Private Cloud (VPC) that you created.From Subnet group, select the DB subnet group that has publicly available subnets.From the Connectivity section, set Public access to Yes.From VPC security group, choose a security group that grants access to the public IP addresses and CIDR ranges that you want to have access from.To create a private only Aurora DB cluster, follow the preceding steps, but in step 6 set Public access to No.Changing public accessibility of running instances in an Aurora DB clusterTo change whether the running instances in the Aurora cluster are publicly accessible:Sign in to the Amazon RDS console.In the navigation pane, choose Databases, and then select the Aurora DB instance in the Aurora Cluster that you want to modify.Choose Modify.From the Modify DB instance page, under Connectivity, expand the Additional Configuration section. Set Public access to Yes or No.Choose Continue, and check the summary of modifications.To apply the changes immediately, select Apply immediately. Changing this setting on the existing DB instance in the cluster affects the network connectivity.Note: You can't give an Amazon Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC), based on the Amazon VPC service. For more information, see Using Amazon Aurora Serverless v1.Related informationHow to create a VPC for use with Amazon AuroraModify a DB instance in a DB clusterFollow"