Question: How does IAM evaluation logic work using an explicit Deny policy with multiple condition keys?

I want to create an AWS Identity and Access Management (IAM) explicit Deny policy that restricts creating Amazon Elastic Compute Cloud (Amazon EC2) instances and Amazon Elastic Block Store (Amazon EBS) volumes. How do I do that?

Answer: "I want to create an AWS Identity and Access Management (IAM) explicit Deny policy that restricts creating Amazon Elastic Compute Cloud (Amazon EC2) instances and Amazon Elastic Block Store (Amazon EBS) volumes. How do I do that?Short descriptionYou can use IAM policy tags to restrict the launch of EC2 instances and EBS volumes by using Allow with StringLike or Deny with StringNotLike condition operators. For instructions about using Allow with StringLike condition operators, see How can I use IAM policy tags to restrict how an EC2 instance or EBS volume can be created?ResolutionUse the following example IAM policy that uses Deny with StringNotLike to restrict creating EC2 instances and EBS volumes.Note: It's a best practice to use Deny with StringNotLike to prevent accidental privileged access.If your policy has multiple condition operators or multiple keys attached to a single condition operator, then the conditions are evaluated using AND logic. With Deny multiple tag values, each RequestTag key must be used in separate statements to get the same AND logic.Note: Setting all RequestTag key values in one condition with a Deny policy might not work as expected. This is because the action is allowed until all conditions are met. When all conditions are met, the action is denied.Note the following required tags:The cost_center tag must have a non-null value.The EC2 instance has a tag key named Production.The identifier tag must be a combination of any five characters.The env tag value must be sandbox, dev, or prod.{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AllowToDescribeAll",            "Effect": "Allow",            "Action": [                "ec2:Describe*"            ],            "Resource": "*"        },        {            "Sid": "AllowRunInstances",            "Effect": "Allow",            "Action": "ec2:RunInstances",            "Resource": [                "arn:aws:ec2:*::image/*",                "arn:aws:ec2:*::snapshot/*",                "arn:aws:ec2:*:*:subnet/*",                "arn:aws:ec2:*:*:network-interface/*",                "arn:aws:ec2:*:*:security-group/*",                "arn:aws:ec2:*:*:key-pair/*"            ]        },        {            "Sid": "AllowRunInstancesWithRestrictions1",            "Effect": "Deny",            "Action": [                "ec2:CreateVolume",                "ec2:RunInstances"            ],            "Resource": [                "arn:aws:ec2:*:*:volume/*",                "arn:aws:ec2:*:*:instance/*"            ],            "Condition": {                "StringNotLike": {                    "aws:RequestTag/cost_center": "?*"                }            }        },        {            "Sid": "AllowRunInstancesWithRestrictions2",            "Effect": "Deny",            "Action": [                "ec2:CreateVolume",                "ec2:RunInstances"            ],            "Resource": [                "arn:aws:ec2:*:*:volume/*",                "arn:aws:ec2:*:*:instance/*"            ],            "Condition": {                "ForAllValues:StringNotLike": {                    "aws:TagKeys": "Production"                }            }        },        {            "Sid": "AllowRunInstancesWithRestrictions3",            "Effect": "Deny",            "Action": [                "ec2:CreateVolume",                "ec2:RunInstances"            ],            "Resource": [                "arn:aws:ec2:*:*:volume/*",                "arn:aws:ec2:*:*:instance/*"            ],            "Condition": {                "StringNotLike": {                    "aws:RequestTag/identifier": "?????"                }            }        },        {            "Sid": "AllowRunInstancesWithRestrictions4",            "Effect": "Deny",            "Action": [                "ec2:CreateVolume",                "ec2:RunInstances"            ],            "Resource": [                "arn:aws:ec2:*:*:volume/*",                "arn:aws:ec2:*:*:instance/*"            ],            "Condition": {                "StringNotLike": {                    "aws:RequestTag/env": [                        "sandbox",                        "dev",                        "prod"                    ]                }            }        },        {            "Sid": "AllowRunInstances1",            "Effect": "Allow",            "Action": [                "ec2:CreateVolume",                "ec2:RunInstances"            ],            "Resource": [                "arn:aws:ec2:*:*:volume/*",                "arn:aws:ec2:*:*:instance/*"            ]        },        {            "Sid": "AllowCreateTagsOnRunInstance",            "Effect": "Allow",            "Action": "ec2:CreateTags",            "Resource": "*",            "Condition": {                "StringEquals": {                    "ec2:CreateAction": "RunInstances"                }            }        }    ]}Note the following enforcement values:The aws:TagKeys value enforces checks on case sensitivity of Production.The ????? value enforces that the combination of any five characters can be used (leading or trailing spaces are ignored).The ?* value enforces that at least one character is present in the value field so that EC2 instances can't launch with empty tag values.Related informationHow do I create an IAM policy to control access to Amazon EC2 resources using tags?Tagging your Amazon EC2 resourcesControlling access to AWS resources using resource tagsEvaluation logic for conditions with multiple keys or valuesFollow"


Question: How do I troubleshoot the failure of my Amazon EMR Spark job using Amazon Athena?

My Spark job on Amazon EMR has failed. I want to troubleshoot the failure by querying the Spark logs using Amazon Athena.

Answer: "My Spark job on Amazon EMR has failed. I want to troubleshoot the failure by querying the Spark logs using Amazon Athena.ResolutionWhen Amazon EMR applications run on Amazon EMR, they produce log files. You can create a basic table for the EMR log files and then use Athena to query these EMR logs. You can identify events and trends for applications and clusters by querying the EMR logs.Run a command similar to the following to create a basic table myemrlogs based on the EMR log files saved to your Amazon S3 log location:CREATE EXTERNAL TABLE `myemrlogs`(  `data` string COMMENT 'from deserializer')ROW FORMAT DELIMITED  FIELDS TERMINATED BY '|'LINES TERMINATED BY '\n'STORED AS INPUTFORMAT   'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT   'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'LOCATION  's3://aws-logs-111122223333-us-west-2/elasticmapreduce/j-1ABCDEEXAMPLE/containers/application_1111222233334_5555/'Replace the following in the above query:myemrlogs with the name of the table111122223333 with the AWS account numberj-1ABCDEEXAMPLE with the clusterIDus-west-2 with your preferred Regionapplication_1111222233334_5555 with the application IDNote: The S3 bucket mentioned in the example is the default bucket used by Amazon EMR. To verify your log bucket path, open the Amazon EMR console, choose your cluster, and then check the Log URI field in the Summary tab.Then, run a command similar to the following to check for occurrences of FAIL, ERROR, WARN, EXCEPTION, FATAL, or CAUSE in myemrlogs:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'FAIL|ERROR|WARN|EXCEPTION|FATAL|CAUSE') limit 100;Note: Replace myemrlogs with the name of the table that you’ve created from the EMR log files.The EMR logs can be queried in different ways to find out at which step the Spark application failed. Here are a few ways to query the logs to troubleshoot if the application failed at the job, stage, task, or executor level.Run a command similar to the following to get the exit code of the application:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'exitCode');Run a command similar to the following to check which host the Spark executor is running on:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'executor ID');Run a command similar to the following to track the mapping of tasks to stages:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'TID');Run a command similar to the following to check the heap memory details of containers:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'space');Run a command similar to the following to track the progress of each job/stage on the Directed Acyclic Graph (DAG) scheduler:SELECT *,"$PATH" FROM myemrlogs WHERE regexp_like(data, 'DAGScheduler');You can also create a partitioned table based on Amazon EMR logs and then use Athena to query these logs. For more information, see Creating and querying a partitioned table based on Amazon EMR logs.Related informationHow can I troubleshoot stage failures in Spark jobs on Amazon EMR?Follow"


Question: What are some best practices for securing my AWS account and its resources?

What are some best practices for securing my AWS account and its resources?-or-I want to protect my AWS resources or account from unauthorized activity.

Answer: "What are some best practices for securing my AWS account and its resources?-or-I want to protect my AWS resources or account from unauthorized activity.Short descriptionAWS offers many tools to help secure your account. However, because many of these measures aren't active by default, you must take direct action to implement them. Here are some best practices to consider when securing your account and its resources:Safeguard your passwords and access keysActivate multi-factor authentication (MFA) on the AWS account root user and any users with interactive access to AWS Identity and Access Management (IAM)Limit AWS account root user access to your resourcesAudit IAM users and their policies frequentlyCreate Amazon Elastic Block Store (Amazon EBS) snapshots, Amazon Relational Database Service (Amazon RDS) snapshots, and Amazon Simple Storage Service (Amazon S3) object versionsUse AWS Git projects to scan for evidence of unauthorized useMonitor your account and its resourcesNote: If you're using AWS Identity Center or IAM federated users, the best practices for IAM users also apply to federated users.ResolutionSafeguard your passwords and access keysThe two main types of credentials used for accessing your account are passwords and access keys. Passwords and access keys can be applied to the AWS root user account and individual IAM users. It's a best practice to safeguard passwords and access keys as securely as you would any other confidential personal data. Never embed them in publicly accessible code (for example, a public Git repository). For added security, frequently rotate and update all security credentials.If you suspect that a password or access key pair was exposed, follow these steps:Rotate all access key pairs.Change your AWS account root user password.Follow the instructions in What do I do if I notice unauthorized activity in my AWS account?Activate MFAActivating MFA can help secure the accounts and prevent unauthorized users from logging in to accounts without a security token.For increased security, it's a best practice to configure MFA to help protect your AWS resources. You can  activate a virtual MFA for IAM users and the AWS account root user. Activating MFA for the root user affects only the root user credentials. IAM users in the account are distinct identities with their own credentials, and each identity has its own MFA configuration.For more information, see Activating MFA devices for users in AWS.Limit root user access to your resourcesRoot user account credentials (the root password or root access keys) grant unlimited access to your account and its resources. It's a best practice to both secure and minimize root user access to your account.Consider the following strategies to limit root user access to your account:Use IAM users for day-to-day access to your account. If you're the only person accessing the account, see Creating your first IAM admin user and user group.Eliminate the use of root access keys. Instead, rotate them to IAM access keys, and then remove unused access keys.Use an MFA device for the root user of your account.For more information, see Safeguard your root user credentials and don't use them for everyday tasks.Audit IAM users and their policies frequentlyConsider the following best practices when working with IAM users:Be sure that the IAM users have the most restrictive policies possible, with only enough permissions to allow them to complete their intended tasks (least privilege).Use AWS IAM Access Analyzer to analyze your existing permissions. For more information, see IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity.Create different IAM users for each set of tasks.When associating multiple policies with the same IAM user, keep in mind that the least restrictive policy takes precedence.Frequently audit your IAM users and their permissions, and find unused credentials.If your IAM user needs access to the console, you can set up a password to allow console access while limiting the user's permissions.Set up individual MFA devices for each IAM user who has access to the console.You can use the visual editor in the IAM console to help you define secure policies. For examples of common business use cases and the policies you might use to address them, see Business use cases for IAM.Create Amazon EBS snapshots, Amazon RDS snapshots, and Amazon S3 object versionsTo create a point-in-time snapshot of an EBS volume, see Create Amazon EBS snapshots.To activate Amazon RDS automated snapshots and set the backup retention period, see Activating automated backups.To create a standard S3 bucket for backup and archive, see Creating standard S3 buckets for backup and archive. To create S3 bucket versioning, see Using versioning in S3 buckets.To create an AWS Backup plan using the console, see Create a scheduled backup. To create an AWS Backup plan using AWS Command Line Interface (AWS CLI), see How can I use the AWS CLI to create an AWS Backup plan or run an on-demand job?Use AWS Git projects to protect against unauthorized useAWS offers Git projects that you can install to help protect your account:Git Secrets can scan merges, commits, and commit messages for secret information (access keys). If Git Secrets detects prohibited regular expressions, it can reject those commits from being posted to public repositories.Use AWS Step Functions and AWS Lambda to generate Amazon CloudWatch Events from AWS Health or by AWS Trusted Advisor. If there's evidence that your access keys are exposed, the projects can help you to automatically detect, log, and mitigate the event.Monitor your account and its resourcesIt's a best practice to actively monitor your account and its resources to detect any unusual activity or access to your account. Consider one or more of the following solutions:Create a billing alarm to monitor your estimated AWS charges to receive automated notifications when your bill exceeds thresholds you define. For more information, see Amazon CloudWatch FAQs.Create a trail for your AWS account to track what credentials are used to initiate particular API calls and when they're used. Doing so can help you to determine if the usage was accidental or unauthorized. You can then take the appropriate steps to mitigate the situation. For more information, see Security best practices in AWS CloudTrail.Use CloudTrail and CloudWatch in conjunction to monitor access key usage and receive alerts for unusual API calls.Activate resource-level logging (for example, at the instance or OS level) and Amazon S3 default bucket encryption.Activate Amazon GuardDuty for your AWS account in all supported Regions. After it's turned on, GuardDuty starts to analyze independent streams of data from AWS CloudTrail management and Amazon S3 data events, Amazon VPC Flow Logs, and DNS logs to generate security findings. The primary detection categories include account compromise, instance compromise, and malicious intrusions. For more information, see Amazon GuardDuty FAQs.Note: It's a best practice to turn on logging for all Regions, not just the ones that you regularly use.Related informationAWS Cloud securityBest practices for managing AWS access keysBest practices for security, identity, and complianceHow can I secure the files in my Amazon S3 bucket?Amazon S3 monitoring and auditing best practicesFollow"


Question: How can I automate the RefreshCache operation on Storage Gateway?

"I have a Network File System (NFS) or Server Message Block (SMB) file share on my AWS Storage Gateway file gateway. The file gateway is associated with an Amazon Simple Storage Service (Amazon S3) bucket. However, when I upload files directly to the bucket, I can't see the files on my file share. How can I automate the refresh of my file share?"

Answer: "I have a Network File System (NFS) or Server Message Block (SMB) file share on my AWS Storage Gateway file gateway. The file gateway is associated with an Amazon Simple Storage Service (Amazon S3) bucket. However, when I upload files directly to the bucket, I can't see the files on my file share. How can I automate the refresh of my file share?ResolutionStorage Gateway updates the file share cache automatically when you write files to the cache locally using the file share. However, Storage Gateway doesn't automatically update the cache when you upload a file directly to Amazon S3. When you do this, you must perform a RefreshCache operation to see the changes on the file share.Storage Gateway allows you to automate the RefreshCache operation based on a Time To Live (TTL) value. TTL is the length of time since the last refresh. When a user accesses the file directory after the TTL value, the file gateway refreshes the directory's contents from the S3 bucket. Valid TTL values for automating the RefreshCache operation range from 300 seconds to 2,592,000 seconds (5 minutes to 30 days).Note: After your specified TTL value expires, the file gateway invokes the ListObjects Amazon S3 API call at the folder level. Setting the TTL to a low value can result in more Amazon S3 API requests.To automate the RefreshCache operation using the Storage Gateway console, follow these steps:Open the Storage Gateway console.Choose File shares.Choose the file share that you want to automate the RefreshCache operation for.Choose Actions, and then choose Edit File Share Settings.For Automated cache refresh from S3 after, select Set refresh interval.Set the time in days, hours, and minutes to refresh the file share's cache using TTL.Choose Save.To automate the RefreshCache operation using the Storage Gateway API, use the UpdateNFSFileShare API call or the UpdateSMBFileShare API call. For both API calls, you need to update the CacheAttributes parameter to automate the RefreshCache operation.To run RefreshCache at one point in time instead of automating the operation, see Why aren't changes on my Amazon S3 bucket showing on the Storage Gateway file share?Note the following considerations about the RefreshCache operation:The time that the refresh process takes to complete depends on the following:Number of objects cached on the gateway.Number of objects added to or removed from the bucket since the last refresh.Refreshing the cache initiates the refresh operation. However, file refresh is a separate process. You can set up refresh cache notifications to get updates on the file refresh process. The refresh-complete notification indicates that the file refresh process is complete.Follow"


Question: "How do I create an IAM policy for tag based restriction with the PrincipalTag, ResourceTag, RequestTag and TagKeys condition keys?"

"I want to create an AWS Identity and Access Management (IAM) policy for tag-based restriction. How do I use the PrincipalTag, ResourceTag, RequestTag, and TagKeys condition keys?"

Answer: "I want to create an AWS Identity and Access Management (IAM) policy for tag-based restriction. How do I use the PrincipalTag, ResourceTag, RequestTag, and TagKeys condition keys?Short descriptionUse the following IAM example policies to create tag-based restriction with condition keys for your use case.ResolutionPrincipalTag condition keyThe aws:PrincipalTag condition key is used to match the tag attached to the principal making the request with the tag in the IAM policy. The value of the PrincipalTag key is compared with the value of the IAM tag with matching tag key if present on the request's principal.The following example IAM policy provides restriction for an Amazon Simple Storage Service (Amazon S3) bucket. The Amazon S3 PutObject action denied permission to the bucket to all users except those with the title "Product-Manager".{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "DenyAllButProductManagers",      "Effect": "Deny",      "Principal": {        "AWS": "*"      },      "Action": [        "s3:PutObject"      ],      "Resource": [        "arn:aws:s3:::productionbucket/*"      ],      "Condition": {        "StringNotEquals": {          "aws:PrincipalTag/job-title": "Product-Manager"        }      }    }  ]}ResourceTag condition keyThe aws:ResourceTag/tag-key condition key compares the tag key-value pair specified in the IAM policy with the key-value pair that's attached to the AWS resource. For more information, see Controlling access to AWS resources.During the IAM policy evaluation, the ResourceTag tag is compared with the IAM tag. The value of the ResourceTag key is compared with the value of the IAM tag with the matching key-value pair, if present for the AWS resource. This condition key can be used with global version aws:ResourceTag and AWS services such as ec2:ResourceTag. For more information, see Actions, resources, and condition keys for AWS services.The following example IAM policy allows users to start, stop, and terminate instances that are in the "test" environment.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowOnlyForTestEnvironment",      "Effect": "Allow",      "Action": [        "ec2:TerminateInstances",        "ec2:StartInstances",        "ec2:StopInstances"      ],      "Resource": "arn:aws:ec2:*:*:instance/*",      "Condition": {        "StringLike": {          "ec2:ResourceTag/Env": "test"        }      }    }  ]}RequestTag condition keyThe aws:RequestTag/tag-key condition key used to compare the key-value pair passed in the user request with the tag pair specified in the IAM policy. The condition key is available for actions that create a resource or tag on a resource, and checks the value of the tag.For example, see the following IAM policy. It enforces users to create a specific tag "Env" with values "Dev", "Prod" or "QA" when creating an Amazon Elastic Block Store (Amazon EBS) volume.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowCreateVolumeWithEnvTag",      "Effect": "Allow",      "Action": "ec2:CreateVolume",      "Resource": "arn:aws:ec2:*:*:volume/*",      "Condition": {        "StringEquals": {          "aws:RequestTag/Env": [            "Dev",            "Prod",            "QA"          ]        }      }    }  ]}TagKeys condition keyThe aws:TagKeys condition key is used to compare the tag keys in a request with the keys specified in the IAM policy. The value of the TagKeys key is compared with the list of tags in the AWS resource request. The TagKeys condition key is used to validate the tag-keys attached to a resource.Because you can define multiple tag key-value pairs in a request, the request can have multiple values. These values can be compared using the ForAllValues or ForAnyValue set operators.The following example policy restricts the tags created on an AWS resource. The "Env" and "CostCenter" tags are the only tag keys that users can create with a new Amazon EBS volume. Using the ForAllValues set operator with aws:TagKeys restricts users to attach only the required tags on the AWS resource. This doesn't require users to provide these tag keys in the resource creation request, but it prevents users from creating tags with other key-value pairs.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": "ec2:CreateVolume",      "Resource": "arn:aws:ec2:*:*:volume/*",      "Condition": {        "ForAllValues:StringEquals": {          "aws:TagKeys": [            "Env",            "CostCenter"          ]        }      }    }  ]}Related informationIAM tutorial: Define permissions to access AWS resources based on tagsControlling access during AWS requestsFollow"


Question: How do I troubleshoot ReceiptHandleIsInvalid and InvalidParameterValue errors when calling the AWS SQS DeleteMessage API?

I receive a ReceiptHandleIsInvalid or InvalidParameterValue error when I try to delete messages from my Amazon Simple Queue Service (Amazon SQS) queue. How do I successfully delete messages?

Answer: "I receive a ReceiptHandleIsInvalid or InvalidParameterValue error when I try to delete messages from my Amazon Simple Queue Service (Amazon SQS) queue. How do I successfully delete messages?Short descriptionEvery time you receive a message from an Amazon SQS queue, you receive a receipt handle for the message. The handle is associated with the action of receiving the message rather than the message itself. To delete the message, you must provide the receipt handle.The error message varies depending on whether you use FIFO queues or standard SQS queues, and whether the receipt handle is incorrect or expired.FIFO SQS queuesIf the receipt handle is incorrect, then you see an error similar to the following:An error occurred (ReceiptHandleIsInvalid) when calling the DeleteMessage operation: The input receipt handle 'YOUR RECEIPT HANDLE' is not a valid receipt handle.For FIFO queues, a receipt handle expires after a visibility timeout period. When a receipt handle expires, the message returns to the queue. When you receive the message again, you get a new receipt handle. If you try to delete the message outside of the visibility timeout period, then you see an error similar to the following:An error occurred (InvalidParameterValue) when calling the DeleteMessage operation: Value 'YOUR RECEIPT HANDLE' for parameter ReceiptHandle is invalid. Reason: The receipt handle has expired.Standard SQS queuesIf the receipt handle is incorrect, then you see an error similar to the following:An error occurred (ReceiptHandleIsInvalid) when calling the DeleteMessage operation: The input receipt handle 'YOUR RECEIPT HANDLE' is not a valid receipt handle.For standard queues, you might sometimes succeed in using an older receipt handle. However, it’s a best practice to use the latest receipt handle for DeleteMessage API calls. Using an older receipt handle can result in an error similar to the following:An error occurred (InvalidParameterValue) when calling the DeleteMessage operation: Value 'YOUR RECEIPT HANDLE' for parameter ReceiptHandle is invalid. Reason: The receipt handle has expired.ResolutionTo prevent invalid or expired receipt handle errors, you must delete the message within the SQS queue visibility timeout period using the correct receipt handle.If you receive a message more than once, review the most recent ReceiveMessage API call response and identify the ReceiptHandle value. Then, use the identified ReceiptHandle value when you call the DeleteMessage API.Related informationReceiveMessageDeleteMessageFollow"


Question: How do I use automatic WLM to manage my workload in Amazon Redshift?

I have different workloads and want to create separate queues using automatic workload management (WLM). How do I use Amazon Redshift automatic WLM to manage and prioritize my workload?

Answer: "I have different workloads and want to create separate queues using automatic workload management (WLM). How do I use Amazon Redshift automatic WLM to manage and prioritize my workload?Short descriptionAmazon Redshift automatic WLM dynamically manages memory and concurrency, helping you prioritize queries for mixed workloads. With automatic WLM, Amazon Redshift manages resource assignments according to the following conditions:After the query is submitted to Amazon Redshift, the resources are assigned according to query priority.If there are no competing workloads, then the lower priority queries have access to all the system resources.For concurrent workloads, higher priority queries are chosen. Higher priority queries are then assigned more resources than the lower priority queries are.The predictable performance for a high priority workload comes at the cost of other lower priority workloads.Note: Lower priority queries might progress at a slower pace. However, Amazon Redshift makes sure that lower priority queries don't suffer from starvation.Lower priority workloads can run longer because of priority status or from working with less resources.To effectively use Amazon Redshift automatic WLM, consider the following:Assign priorities to a queue.Change your query priorities.Monitor your query priorities.Check whether the query is running according to assigned priorities.ResolutionAssigning priorities to a queueTo manage your workload using automatic WLM, perform the following steps:1.    Define and separate your workload into categories (such as ETL, dashboards, and analytics).2.    Identify individual users and group them according to workload.3.    Create and assign different queues to a particular user or query group. For more information, see Assigning queries to queues.4.    Turn on concurrency scaling for queues, so that Amazon Redshift automatically adds additional cluster capacity when needed. For example, you can turn on concurrency scaling on queues if you tend to experience bursts in traffic. For more information, see Configuring concurrency scaling queues.Here's an example JSON configuration for automatic WLM:[ {  "query_group" : [ ],  "query_group_wild_card" : 0,  "user_group" : [ "ETL_users" ],  "user_group_wild_card" : 1,  "priority" : "highest",  "queue_type" : "auto",  "auto_wlm" : true    }, {  "query_group" : [ ],  "query_group_wild_card" : 0,  "user_group" : [ "Dashboard_users" ],  "user_group_wild_card" : 0,  "priority" : "high",  "queue_type" : "auto",  "auto_wlm" : true}, {  "query_group" : [ "Adhoc_query" ],  "query_group_wild_card" : 1,  "user_group" : [ "Analytics_users" ],  "user_group_wild_card" : 1,  "priority" : "normal",  "queue_type" : "auto",  "auto_wlm" : true}, {  "query_group" : [ ],  "query_group_wild_card" : 0,  "user_group" : [ ],  "user_group_wild_card" : 0,  "priority" : "low",  "queue_type" : "auto",  "auto_wlm" : true}, {  "short_query_queue" : true} ]Note: If you don’t set a query priority, all queues are automatically set to "normal" priority status.Changing query prioritiesIn Amazon Redshift, you can change the queue priority by using WLM query monitoring rules (QMRs) or built-in functions.Method 1: WLM query monitoring rulesUse the WLM query monitoring rules when you want to manage workload according to metrics-based performance boundaries. When you set your WLM query monitoring rules, specify the query priority metric and query priority action. For example:{  "query_group" : [ ],  "query_group_wild_card" : 0,  "user_group" : [ ],  "user_group_wild_card" : 0,  "rules" : [ {    "rule_name" : "long_running_queries",    "predicate" : [ {      "metric_name" : "query_execution_time",      "operator" : ">",      "value" : 3600    } ],    "action" : "change_query_priority",    "value" : "high"  } ],  "priority" : "low",  "queue_type" : "auto",  "auto_wlm" : true}, {  "short_query_queue" : true} ]Method 2: Built-in functionsImportant: Built-in functions require proper permissions. To use a built-in function, you either must be a superuser, or a superuser must grant you the permission to use one.In Amazon Redshift, built-in functions are independent of WLM configurations. To grant a standard user the permission to use a built-in function, create a stored procedure that specifies SECURITY DEFINER. Then, grant permission to the standard user.A superuser can change query priority using the following built-in functions:Query-level: CHANGE_QUERY_PRIORITYSession-level: CHANGE_SESSION_PRIORITYUser-level: CHANGE_USER_PRIORITYNote: "Critical" priority status can only be assigned using built-in functions. Only one critical query is allowed in the system at any time.Monitoring query prioritiesTo check query priority for a queue or active query, run the following query:select query, service_class, query_priority, state from stv_wlm_query_state where service_class>=100;To check query priority for a completed query, use the following query:select query, service_class, service_class_start_time as starttime, query_priorityfrom stl_wlm_query where query=<query_id>;To check whether your query priority changed because of a QMR rule, use the following query:select * from stl_wlm_rule_action where query= <Query_ID> and action= ‘change_query_priority’;In your output, check the action_value column to verify the changed priority for your query.To check your QMR configurations, run the following query:select * from stv_wlm_QMR_config where action= ‘change_query_priority’;To check the current value of the query_group parameter, run the following query:select current_setting(‘query_group’);To check the automatic WLM queue configuration, run the following query:select s.service_class,rtrim(s.name) as name, s.num_query_tasks as slots, s.query_working_mem as mem, s.max_execution_time as max_time, s.user_group_wild_card as user_wildcard, s.query_group_wild_card as query_wildcard,rtrim(c.condition) as condition, s.query_priority from stv_wlm_service_class_config s left join stv_wlm_classification_config c on s.service_class = c.action_service_class where s.service_class > 4 order by service_class;Note: If auto_wlm is turned on and set to "true", then the service class ID indicates 100-107. The num_query_tasks and query_working_mem columns also indicate a value of -1.Checking whether the query is running according to assigned prioritiesQueries are routed to queues based on assigned priorities, query monitoring rules, and matching wildcards for user groups and query groups. Amazon Redshift then automatically assigns the query to the first matching queue.If your query doesn't run in the desired queue, check whether the following conditions are true:User or query_group is set to "superuser": If your user or query group is set to "superuser", then the query runs in the superuser queue (service_class = 5).User is listed as a member of a user group, but a different query group is assigned for that particular query: If a query is assigned to a different query group from its listed group membership, then it runs in the first matching queue. By default, queries in Amazon Redshift run according to the queue's set priority.Improper permissions for using built-in functions: If you are using built-in functions (like CHANGE_QUERY_PRIORITY, CHANGE_USER_PRIORITY, and CHANGE_QUERY_PRIORITY), you must have superuser privileges. Or, you must be granted the proper permissions to use a built-in function by a superuser.User is a member of multiple groups: If you're listed as a member of multiple groups, then the query is assigned to the first matching queue. The queue matches are performed according to the WLM query assignment rules.To confirm whether a query priority was successfully changed, run the following query:select query, service_class, query_priority, state from stv_wlm_query_state where query= <Query_ID>;To confirm whether a user is listed as a member of multiple groups, run the following query:SELECT usename, gronameFROM pg_user, pg_groupWHERE pg_user.usesysid = ANY(pg_group.grolist)AND pg_group.groname in (SELECT DISTINCT pg_group.groname from pg_group);To identify whether a query group was set for a query, run the following query:select q.userid, q.query, rtrim(q.label) as label, w.service_class, w.query_priority from stl_query q join stl_wlm_query w on q.query = w.query where q.query = <Query_ID>;Check the label column in the output to confirm a query's group membership. If a query has no matching query or user group, then it runs in the default queue.Follow"


Question: How can I revoke my ACM private certificate?

How can I revoke an AWS Certificate Manager (ACM) private certificate?

Answer: "How can I revoke an AWS Certificate Manager (ACM) private certificate?Short descriptionYou can revoke an ACM private certificate using the revoke-certificate AWS Command Line Interface (AWS CLI) command.ResolutionFollow these instructions depending on whether the ACM private certificate was created with the IssueCertificate API or in the AWS Management Console with the RequestCertificate API.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Revoke an ACM private certificate that was created using the IssueCertificate APIStep 1: Get the certificates serial numberThe following AWS CLI command get-certificate outputs the base64-encoded PEM format certificate and saves it in the certificate.pem file:Note: Replace the ARN in these examples with your ARN.aws acm-pca get-certificate --certificate-authority-arn arn:aws:acm-pca:eu-west-1:111111111111:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate-arn arn:aws:acm-pca:eu-west-1:111111111111:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/3d295f5691637e577f3c192acd79d401 \ --query 'Certificate' > certificate.pem --output textStep 2: Decode the certificate with OpenSSL to get the serial numberopenssl x509 -in certificate.pem -noout -textExample output:Serial Number: 3d:29:5f:56:91:63:7e:57:7f:3c:19:2a:cd:79:d4:01 \Step 3: Revoke the certificateRun the AWS CLI command revoke-certificate similar to the following:Note: Replace the serial number example with your serial number output from step 2.aws acm-pca revoke-certificate \ --certificate-authority-arn arn:aws:acm-pca:eu-west-1:111111111111:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate-serial 3d:29:5f:56:91:63:7e:57:7f:3c:19:2a:cd:79:d4:01 \ --revocation-reason "KEY_COMPROMISE"Use one of the following values to specify why you revoked the certificate:UNSPECIFIEDKEY_COMPROMISECERTIFICATE_AUTHORITY_COMPROMISEAFFILIATION_CHANGEDSUPERSEDEDCESSATION_OF_OPERATIONPRIVILEGE_WITHDRAWNA_A_COMPROMISENote: The revoke-certificate command doesn't return a response.Revoke an ACM private certificate that was created using the AWS Management Console or RequestCertificate APIStep 1: Get the certificate's serial numberRun the AWS CLI command describe-certificate similar to the following:aws acm describe-certificate --certificate-arn arn:aws:acm:region:account:certificate/12345678-1234-1234-1234-123456789012Example output:"Serial" : "3d:29:5f:56:91:63:7e:57:7f:3c:19:2a:cd:79:d4:01"Step 2: Revoke the certificateRun the AWS CLI command revoke-certificate similar to the following:Note: Replace the serial number example with your serial number output from step 1.aws acm-pca revoke-certificate \    --certificate-authority-arn arn:aws:acm-pca:eu-west-1:111111111111:certificate-authority/12345678-1234-1234-1234-123456789012 \    --certificate-serial 3d:29:5f:56:91:63:7e:57:7f:3c:19:2a:cd:79:d4:01 \  --revocation-reason "KEY_COMPROMISE"Use one of the following values to specify why you revoked the certificate:A_A_COMPROMISEPRIVILEGE_WITHDRAWNCESSATION_OF_OPERATIONSUPERSEDEDAFFILIATION_CHANGEDCERTIFICATE_AUTHORITY_COMPROMISEKEY_COMPROMISEUNSPECIFIEDNote: The revoke-certificate command doesn't return a response.Confirm that the ACM private certificate was revokedCreate an audit report using the AWS CLITo create an audit report that lists every time that your CA private key is used, run the AWS CLI command create-certificate-authority-audit-report:aws acm-pca create-certificate-authority-audit-report \ --certificate-authority-arn arn:aws:acm-pca:eu-west-1:111111111111:certificate-authority/12345678-1234-1234-1234-123456789012 \ --s3-bucket-name acmcrl2 \ --audit-report-response-format JSONExample output:{     "AuditReportId": "10e5767f-6259-4a23-90bb-628f5a5e1fee",     "S3Key": "audit-report/12345678-1234-1234-1234-123456789012/10e5767f-6259-4a23-90bb-628f5a5e1fee.json" }Note the Amazon Simple Storage Service (Amazon S3) key ID.Get the Amazon S3 object with the AWS CLI command get-object:aws s3api get-object --bucket acmcrl2 --key audit-report/12345678-1234-1234-1234-123456789012/10e5767f-6259-4a23-90bb-628f5a5e1fee.json revoked.txtExample output:"revokedAt": "2021-01-30T15:24:55+0000"Note the timestamp in the revokedAt value. The revokedAt value exists only when the certificate status is REVOKED.Create an audit report using the AWS Management ConsoleFollow the instructions to create an audit report using the AWS Management Console.For more information, see Revoking a private certificate.Related informationACM Private CA best practicesFollow"


Question: How do I upload files that are blocked by AWS WAF?

I need to upload (POST) a file that uses an extension that's blocked by AWS WAF.

Answer: "I need to upload (POST) a file that uses an extension that's blocked by AWS WAF.Short descriptionTo understand why a POST request is blocked by AWS WAF, note the following points:AWS WAF BODY filters inspect only the first 8,192 bytes of the payload of a POST request for malicious scripts.The SQL injection and cross-site scripting (XSS) rules are sensitive to files that contain random characters in their metadata. These random characters might invoke web ACL rules due to their similarity to an actual XSS or SQL injection signature in AWS WAF.Filtering for specific file types isn't supported by AWS WAF. You must use other methods to eliminate false positives from uploading files or images.First, review the common rules that might block file uploads. If a common rule isn't blocking the upload, then consider additional options to allow blocked files.The following rules commonly block file uploads:CrossSiteScripting_BODYSQLi_BODYWindowsShellCommands_BODYGenericLFI_BODYSizeRestrictions_BODYResolutionFile uploads blocked by SQLi_BODY and CrossSiteScripting_BODY rulesCheck the terminatingRuleMatchDetails field in the AWS WAF comprehensive logs for the rule information.Note: The terminatingRuleMatchDetails field populates only for SQLi_BODY and CrossSiteScripting_BODY attacks.The following is an example of matchedData for CrossSiteScripting_BODY:"terminatingRuleMatchDetails": [{        "conditionType": "XSS",        "location": "BODY",        "matchedData": [            "<?",            "`"        ]The following is an example of matchedData for SQLi_BODY:"terminatingRuleMatchDetails": [{        "conditionType": "SQL_INJECTION",        "location": "BODY",        "matchedData": [            ")",            "*",            "(",            "0"        ]To address blocked uploads by SQLi_BODY or CrossSiteScripting_BODY, choose one of the following options:Option 1If you know the IP address range that accesses the application, then add well-known IP addresses to a safe list rule with IP match conditions. For instructions, see Working with IP match conditions.Option 2Use a safe list with a string or regular expression (regex) match condition to allow the request. You can create a safe list based on a URI, HTTP headers, or a phrase that's associated with the BODY of the AWS WAF files.To create your safe list, create a new custom rule to block XSS or SQLi vectors with an exception condition that's based on matched data. Be sure to override the action for the specific rule that causes the false positive.To create this custom rule, complete the following steps:1.    Open the AWS WAF console.2.    In the navigation pane, under AWS WAF, choose Web ACLs.3.    For Region, select the AWS Region where you created your web ACL.Note: Select Global if your web ACL is set up for Amazon CloudFront.4.    Select your web ACL.5.    In the web ACL Rules tab, choose Rules.6.    Choose Add Rules, and then choose Add my own rules and rule groups.7.    For Name, enter a rule name, and then choose Regular Rule.8.    For If a request, choose matches all the statements (AND).9.    Complete Statement 1 with the following fields:For Inspect, select Has a label.For Match scope, select Label.For Match key, enter the label for the rule that creates the false positive. For example, if the CrossSiteScripting_BODY rule creates the false positive, then enter awswaf:managed:aws:core-rule-set:CrossSiteScripting_Body.10.    Complete Statement 2 with the following fields:Select the check box for Negate statement results.For Inspect, select Body.For Match type, select Contains string.For String to match, enter the value that you want to match to the rule.11.    (Optional) For Text transformation, choose a Text transformation or None.12.    For Action, choose Block.13.    Choose Add rule.14.    For Set rule priority, move the rule below the managed rule that was blocking the request.15.    Choose Save.Important: It’s a best practice to test rules in a non-production environment with the Action set to Count. Evaluate the rule using Amazon CloudWatch metrics combined with AWS WAF sampled requests or AWS WAF logs. When the rule does what you want, change the Action to Block.File uploads blocked by WindowsShellCommands_BODY, GenericLFI_BODY, or SizeRestrictions_BODY rulesTake an HTTP Archive (HAR) file while the file is being uploaded and review it for WindowsShellCommands_BODY, GenericLFI_BODY, or SizeRestrictions_BODY rules. For instructions, see How do I create a HAR file from my browser for an AWS Support case?To allow the false positives for WindowsShellCommands_BODY, GenericLFI_BODY, or SizeRestrictions_BODY, first set the corresponding rule to Count mode. For instructions, see Overriding a rule group's evaluation result to Count.Then, create a custom rule for the specific managed rule that causes the false positive with an exception condition using Labels:1.    Open the AWS WAF console.2.    In the navigation pane, under AWS WAF, choose Web ACLs.3.    For Region, select the AWS Region where you created your web ACL.Note: Select Global if your web ACL is set up for Amazon CloudFront.4.    Select your web ACL.5.    In the web ACL Rules tab, choose Rules.6.    Choose Add Rules, and then choose Add my own rules and rule groups.7.    For Name, enter a rule name, and then choose Regular Rule.8.    For If a request, choose matches all the statements (AND).9.    Complete Statement 1 with the following fields:For Inspect, select Has a label.For Match scope, select Label.For Match key, enter the label for the rule that creates the false positive. For example, if the WindowsShellCommands_BODY rule creates the false positive, then enter awswaf:managed:aws:windows-os:WindowsShellCommands_Body.10.    Complete Statement 2 with the following fields:Select the check box for Negate statement results.For Inspect, select URI path.For Match type, select Exactly matches string.For String to match, enter the URI path where requests are being made.11.    (Optional) For Text transformation, choose a Text transformation or None.12.    For Action, choose Block.13.    Choose Add rule.14.    For Set rule priority, move the rule below the managed rule that was blocking the request.15.    Choose Save.Important: It’s a best practice to test rules in a non-production environment with the Action set to Count. Evaluate the rule using CloudWatch metrics combined with AWS WAF sampled requests or AWS WAF logs. When the rule does what you want, change the Action to Block.Additional options for allowing blocked filesNote: Rules are processed in the order that they're listed in the web ACL. For the following recommendations, be sure to reorder your rule priorities as needed.Choose the best method for your use case:Apply selective exclusion with a string match rule statement (AWS WAF) or a string match condition (AWS WAF Classic). Add specific phrases that are associated with the BODY of the files to your safe list. If false positives occur on a certain URI path, then add the path to your safe list.Use a separate domain for file uploads. Be sure to consider if this is a cost-effective option for your use case.Scan (scrub) files and images for embedded code and data. You can perform this action on the client side before uploading the files. Or, if you create an exclusion rule, then you can perform this action on the backend after uploading the files.Compress files before uploading them.Caution: Make sure that you don't compress malicious files.If the upload happens from a range of known IP addresses, then add those IP addresses to your safe list.Use base64 encoding to encode all image data so that AWS WAF doesn't invoke XSS or SQLi on images.Caution: Be sure to avoid encoding malicious images.Implement image optimization techniques, such as chunk removal or randomization of bits.Follow"


Question: What outbound caller ID is used when calls in my Amazon Connect contact center are transferred to an external number?

"When agents in my Amazon Connect contact center transfer calls to an external number, what outbound caller ID appears on the destination number's side?"

Answer: "When agents in my Amazon Connect contact center transfer calls to an external number, what outbound caller ID appears on the destination number's side?ResolutionNote: There are three ways agents in your Amazon Connect contact center can transfer calls to an external number. The outbound caller ID that appears on the external destination number's side depends on the transfer method used.If the call is transferred with an external quick connectThe outbound caller ID depends on if the agent is on an active call or not.If the agent is on an active callThe original queue that the call is serviced from provides the outbound caller ID.For more information, see Set up outbound caller ID.If the agent isn't on an active callThe outbound queue of the agent's routing profile provides the outbound caller ID.Note: You can override the outbound caller IDs in your agents' routing profiles by using the Call phone number block in a custom outbound whisper flow.For more information, see Create quick connects.If the call is transferred with the Quick Connect number padThe original queue that the call is serviced from provides the outbound caller ID.For more information, see Transfer calls to a quick connect or external number.If the call is transferred with the Transfer to phone number contact block in a contact flowThe outbound caller ID depends on if a caller ID is configured in your Transfer to phone number contact block or not.If a caller ID is configuredThe configured caller ID appears as the outbound caller ID on the external destination number's side.If a caller ID isn't configuredThe caller's caller ID appears as the outbound caller ID on the external destination number's side.For more information, see the Properties section of Contact block: Transfer to phone number.Important: If you're using Amazon Connect outside of the United States, it's a best practice to set the Caller ID number as an Amazon Connect number. Local regulations may cause telephony providers to block or redirect non-Amazon Connect phone numbers.Related informationWhy your caller ID might not appear correctly to customersFollow"


Question: How can I use AWS Health Aware to send events to channels across my organization in Organizations?

I want to use AWS Health to send events to channels across my organization in AWS Organizations.

Answer: "I want to use AWS Health to send events to channels across my organization in AWS Organizations.Short descriptionYou can use AWS Health Aware (AHA) to send events to channels such as Slack, Microsoft Teams, and Amazon Chime across your organization. With AHA, you can get aggregated public or account-specific events for accounts in your AWS Organizations.For more information on the benefits of using AHA, see AWS Health Aware – customize AWS Health alerts for organizational and personal AWS accounts.ResolutionTo deploy AHA, see Deployment Options on the GitHub website.Note: Because AHA uses the Health API, you must have a Business or Enterprise Support plan.Related informationAre you a first-time AWS Health user?Follow"


Question: How can I access and download the results of an Amazon Athena query?

I want to find the results of my Amazon Athena queries.

Answer: "I want to find the results of my Amazon Athena queries.ResolutionUse one of the following options to access the results of an Athena query:Download the query results files using the Athena console.Download the query results files from the Amazon Simple Storage Service (Amazon S3) that you specified for the query location. For more information, see Specifying a query result location.Related informationViewing recent queriesFollow"


Question: How do I configure my CloudFront distribution to use an SSL/TLS certificate?

I want to configure my Amazon CloudFront distribution to use an SSL/TLS certificate.

Answer: "I want to configure my Amazon CloudFront distribution to use an SSL/TLS certificate.ResolutionCloudFront assigns a default domain name to your distribution, for example, d111111abcdef8.cloudfront.net. If you use this domain name, then you can use the CloudFront default SSL/TLS certificate already selected for your distribution. If you use a different domain name for your distribution, then it's a best practice to do one of the following to avoid domain-name-related certificate warnings:Request a public certificate from AWS Certificate Manager.Import certificates into AWS Certificate Manager.If you use an Amazon issued certificate:You must request the certificate in the US East (N. Virginia) Region.You must have permission to use and request the ACM certificate.If you use an imported certificate with CloudFront:Your key length must be 1024 or 2048 bits and cannot exceed 2048 bits.You must import the certificate in the US East (N. Virginia) Region.You must have permission to use and import the SSL/TLS certificate.Note: If you are missing permissions, the CloudFront console displays Missing permission acm:ListCertificates in the Custom SSL Certificate settings. If you don't have a certificate in the US East (N. Virginia) Region, or if your key size exceeds 2048 bits, the setting for Custom SSL Certificate is grayed out.For more information, see requirements for using SSL/TLS certificates with CloudFront.Then, configure your CloudFront distribution to use the new certificate and require HTTPS between viewers and CloudFront. For more information, see viewing and updating CloudFront distributions.After you save the changes to your CloudFront distribution configuration, CloudFront propagates the changes to all edge locations. The status of your CloudFront distribution in the CloudFront console changes from InProgress to Deployed when propagation is complete.If you require HTTPS for communication between CloudFront and your custom origin, then you can also use SSL/TLS certificates on a custom originTo update settings for your CloudFront distribution, see updating your CloudFront distribution.Related informationAWS Certificate Manager benefitsIssuing and managing certificatesHow can I troubleshoot issues with using a custom SSL certificate for my CloudFront distribution?Clients are receiving certificate error messages when trying to access my website using HTTPS connections. How do I resolve this?Follow"


Question: How do I install a wildcard Let's Encrypt SSL certificate in a Bitnami stack hosted on Amazon Lightsail?

How do I install a wildcard SSL certificate for my website in an Amazon Lightsail instance with a Bitnami stack?

Answer: "How do I install a wildcard SSL certificate for my website in an Amazon Lightsail instance with a Bitnami stack?Short descriptionThe following resolution covers installing a wildcard Let's Encrypt SSL certificate for websites hosted in a Lightsail instance with a Bitnami stack. Examples of these instance blueprints include WordPress, LAMP, Magento, MEAN, and so on. If you have a different instance blueprint or want to install a standard certificate, see one of the following:Standard Let's Encrypt certificatesTo install a standard Let's Encrypt SSL certificate in a Lightsail instance without a Bitnami stack, see How do I install a standard Let's Encrypt SSL certificate in a Lightsail instance? This includes instances such as Amazon Linux 2 and Ubuntu.To install a standard Let's Encrypt SSL certificate in a Lightsail instance with a Bitnami stack, see How do I install a Let's Encrypt SSL certificate in a Bitnami stack hosted on Amazon Lightsail? This includes instances such as WordPress, LAMP, and Magento.Wildcard Let's Encrypt certificates (for example, *.example.com)To install a wildcard Let's Encrypt certificate in a Lightsail instance without a Bitnami stack, see How do I install a wildcard Let's Encrypt SSL certificate in Amazon Lightsail? This includes instances such as Amazon Linux 2 and Ubuntu.ResolutionThe steps used to install a wildcard Let's Encrypt SSL certificate on a Bitnami hosted Lightsail instance depend on which DNS provider your domain uses. To determine which method to use, verify if your DNS provider is listed in DNS Providers in the Lego documentation. Then, select the appropriate method to use:Method 1: Use the Lego tool provided by Bitnami If your domain uses one of the listed DNS providers.Method 2: Use the Certbot package if your domain isn't using any of the listed DNS providers.Note: The file paths mentioned in this article might change depending on whether your Bitnami stack uses native Linux system packages (Approach A), or if it is a self-contained installation (Approach B). To identify your Bitnami installation type, run the command following command:test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."Method 1Along with bncert-tool, Bitnami stack provides the Lego tool. This tool supports the creation of wildcard SSL certificates, while bncert-tool does not.Prerequisites and limitationsThe following steps cover installing the certificate in the server. You must manually complete additional steps, such as configuring the webserver to use the certificate and setting up HTTPS redirection.The domain must be using one of the DNS providers listed in DNS Providers in the Lego documentation.Note: In the following example, the DNS provider is Amazon Route 53 or Amazon Lightsail.1.    Create an AWS Identity and Access Management (IAM) user with programmatic access. For the minimum permissions required to be attached to the IAM user for Lego to complete the DNS challenge, see Policy in the Lego documentation.2.    Run the following commands in the instance to open the file /root/.aws/credentials file in nano editor.sudo mkdir /root/.awssudo nano /root/.aws/credentials3.    Copy the following lines to the file. Then save the file by pressing  ctrl+x, then press y and then ENTER.In the following command, replace aws_access_key_id with the Access Key ID created in step 1. Replace a aws_secret_access_key with the Secret Access Key created in step 1.[default]aws_access_key_id = AKIA************Eaws_secret_access_key = 1yop**************************l4.    If your Bitnami instance doesn't include the directory /opt/bitnami/letsencrypt/, then manually install the Lego client using the following commands:cd /tmpcurl -Ls https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i - -O lego.tar.gztar xf lego.tar.gzsudo mkdir -p /opt/bitnami/letsencryptsudo mv lego /opt/bitnami/letsencrypt/lego5.    Create a Let's Encrypt certificate in the server. Replace EMAIL-ADDRESS with the email address where you want to receive further updates about your certificate. Replace DOMAIN with your domain name.Route 53 name serverssudo /opt/bitnami/letsencrypt/lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="*.DOMAIN" --dns route53 --path="/opt/bitnami/letsencrypt" runLightsail name serverssudo /opt/bitnami/letsencrypt/lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="*.DOMAIN" --dns lightsail --path="/opt/bitnami/letsencrypt" runAfter the SSL certificate generates successfully, you receive the message "Server responded with a certificate". The SSL certificate and private key generate in the following locations:/opt/bitnami/letsencrypt/certificates/DOMAIN.crt/opt/bitnami/letsencrypt/certificates/DOMAIN.key6.    Link the SSL certificate and certificate key file to the locations that are currently being read by your web server:Apache under Approach AIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/apache2/conf/bitnami/certs/server.crt /opt/bitnami/apache2/conf/bitnami/certs/server.crt.oldsudo mv /opt/bitnami/apache2/conf/bitnami/certs/server.key /opt/bitnami/apache2/conf/bitnami/certs/server.key.oldsudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/apache2/conf/bitnami/certs/server.keysudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/apache2/conf/bitnami/certs/server.crtsudo /opt/bitnami/ctlscript.sh restart apacheApache under Approach BIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/apache2/conf/server.crt /opt/bitnami/apache2/conf/server.crt.oldsudo mv /opt/bitnami/apache2/conf/server.key /opt/bitnami/apache2/conf/server.key.oldsudo mv /opt/bitnami/apache2/conf/server.csr /opt/bitnami/apache2/conf/server.csr.oldsudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/apache2/conf/server.keysudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/apache2/conf/server.crtsudo /opt/bitnami/ctlscript.sh restart apacheNGINX under Approach AIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.crt /opt/bitnami/nginx/conf/bitnami/certs/server.crt.oldsudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.key /opt/bitnami/nginx/conf/bitnami/certs/server.key.oldsudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/nginx/conf/bitnami/certs/server.keysudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/nginx/conf/bitnami/certs/server.crtsudo /opt/bitnami/ctlscript.sh restart nginxNGINX under Approach BIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/nginx/conf/server.crt /opt/bitnami/nginx/conf/server.crt.oldsudo mv /opt/bitnami/nginx/conf/server.key /opt/bitnami/nginx/conf/server.key.oldsudo mv /opt/bitnami/nginx/conf/server.csr /opt/bitnami/nginx/conf/server.csr.oldsudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/nginx/conf/server.keysudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/nginx/conf/server.crtsudo /opt/bitnami/ctlscript.sh restart nginx7.    Set up automatic certificate renewal.The Let’s Encrypt certificates are valid for 90 days. To automate certificate renewal so that the certificate automatically renews before it expires, do the following:Run the following command to open the crontab editor:sudo crontab -e -u bitnamiAdd the following lines to the crontab file, and then save the file. Replace EMAIL-ADDRESS with your email address, DOMAIN with your domain name and DNS with your name server provider name (Route 53, Lightsail, and so on).0 0 * * * sudo /opt/bitnami/letsencrypt/lego --path /opt/bitnami/letsencrypt --email="EMAIL-ADDRESS" --domains="DOMAIN"  --domains="*.DOMAIN" --dns DNS renew >> /var/log/letsencrypt.log 2>&1 && sudo /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf -k graceful8.    Set up HTTPS redirection. For more information, see the following information on the Bitnami website:Force HTTPS redirection with ApacheForce HTTPS redirection with NGINXMethod 2Prerequisites and limitationsThe following steps cover installing the certificate in the server. You still must manually complete additional steps, such as configuring the webserver to use the certificate and setting up HTTPS redirection.Automatic certificate renewal isn't supported in this method.Note: Before beginning the following steps, install Certbot. For installation instructions, see How do I install the Certbot package in my Lightsail instance for Let's Encrypt certificate installation?For Bitnami-hosted instances, the Linux distribution is either Debian or Ubuntu. Run the following command to confirm which Linux distribution you have:cat /etc/os-release | grep -i ^id1.    This method requires adding TXT records in the domain's DNS provider. This process might take some time, so it's a best practice to run the commands in Linux GNU Screen to prevent the session from timing out. To start a Screen session, enter the following command:screen -S letsencrypt2.    Enter the following command to start Certbot in interactive mode. This command tells Certbot to use a manual authorization method with DNS challenges to verify domain ownership. Replace  example.com with your domain name.sudo certbot certonly --manual --preferred-challenges dns -d example.com -d *.example.com3.    You receive a prompt to verify that you own the specified domain by adding TXT records to the DNS records for your domain. Let's Encrypt provides either a single or multiple TXT records that you must use for verification.4.    When you see a TXT record in the screen, first add the provided record in your domain's DNS.Important: Do not press enter until you confirm that the TXT record is propagated to internet DNS. Also, do not press CTRL+D because doing so will terminate the screen session.5.    To confirm that the TXT record was propagated to internet DNS, look it up at DNS Text Lookup on MxToolbox. Enter the following text into the text box, and then choose TXT Lookup to run the check. Be sure to replace example.com with your domain._acme-challenge.example.com6.    If your TXT records are propagated to the internet’s DNS, you see the TXT record value in the page. Then, go back to the screen and press ENTER.7.    If you're removed from the shell, go back in using the command screen -r SESSIONID. Get the Session ID by running the command screen -ls.8.    If the Certbot prompt asks you to add another TXT record, complete steps 4 -7 again.9.    After the SSL certificate generates successfully, you receive the message "Successfully received certificate". The certificate and key file locations are also provided. Save these file locations to a notepad for use in the next step.10.    Only the certificate installation and renewal setup is complete. You still must configure your web server to use this certificate and set up HTTPS redirection. Use one of the following sets of commands to configure your web server to use the certificate.Apache under Approach AIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/apache2/conf/bitnami/certs/server.crt /opt/bitnami/apache2/conf/bitnami/certs/server.crt.oldsudo mv /opt/bitnami/apache2/conf/bitnami/certs/server.key /opt/bitnami/apache2/conf/bitnami/certs/server.key.oldsudo ln -sf /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/apache2/conf/bitnami/certs/server.keysudo ln -sf /etc/letsencrypt/live/DOMAIN/fullchain.pem /opt/bitnami/apache2/conf/bitnami/certs/server.crtsudo /opt/bitnami/ctlscript.sh restart apacheApache under Approach BIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/apache2/conf/server.crt /opt/bitnami/apache2/conf/server.crt.oldsudo mv /opt/bitnami/apache2/conf/server.key /opt/bitnami/apache2/conf/server.key.oldsudo ln -sf /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/apache2/conf/server.keysudo ln -sf /etc/letsencrypt/live/DOMAIN/fullchain.pem /opt/bitnami/apache2/conf/server.crtsudo /opt/bitnami/ctlscript.sh restart apacheNGINX under Approach AIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.crt /opt/bitnami/nginx/conf/bitnami/certs/server.crt.oldsudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.key /opt/bitnami/nginx/conf/bitnami/certs/server.key.oldsudo ln -sf /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/nginx/conf/bitnami/certs/server.keysudo ln -sf /etc/letsencrypt/live/DOMAIN/fullchain.pem /opt/bitnami/nginx/conf/bitnami/certs/server.crtsudo /opt/bitnami/ctlscript.sh restart nginxNGINX under Approach BIn the following example commands, replace the DOMAIN placeholder with your domain name.sudo mv /opt/bitnami/nginx/conf/server.crt /opt/bitnami/nginx/conf/server.crt.oldsudo mv /opt/bitnami/nginx/conf/server.key /opt/bitnami/nginx/conf/server.key.oldsudo ln -sf /etc/letsencrypt/live/DOMAIN/privkey.pem /opt/bitnami/nginx/conf/server.keysudo ln -sf /etc/letsencrypt/live/DOMAIN/fullchain.pem /opt/bitnami/nginx/conf/server.crtsudo /opt/bitnami/ctlscript.sh restart nginx8.    Set up HTTPS redirection. For more information, see the following information on the Bitnami website:Force HTTPS redirection with ApacheForce HTTPS redirection with NGINXFollow"


Question: How do I set up dynamic port mapping for Amazon ECS?

I want to set up dynamic port mapping for my container instance in Amazon Elastic Container Service (Amazon ECS).

Answer: "I want to set up dynamic port mapping for my container instance in Amazon Elastic Container Service (Amazon ECS).Short descriptionThe Classic Load Balancer doesn't allow you to run multiple copies of a task on the same instance. Instead, when using the Classic Load Balancer, you must statically map port numbers on a container instance. However, an Application Load Balancer uses dynamic port mapping, so you can run multiple tasks from a single service on the same container instance.Note: Network Load Balancers can also be used for dynamic port mapping. See Network Load Balancer and Creating a Network Load Balancer.ResolutionTo set up dynamic port mapping, follow these steps:Create an Application Load Balancer and a target group.Important: To route health check traffic correctly when you create a target group, expand Advanced health check settings. For Port, select traffic port.Open the Amazon ECS console, and then set the host port to 0 for the task definition that you're creating or updating. Be sure to set the container port mappings for your application.Important: The host and awsvpc network modes do not support dynamic host port mapping.Add a rule to allow inbound traffic from your load balancer to your container instances. The security group and network access control list (network ACL) must allow traffic from the load balancer to the instances over the ephemeral port range.Note: For more information about ephemeral port ranges, see PortMapping.Open the Amazon ECS console, and then configure your service to use the Application Load Balancer that you created.Important: You can add a load balancer only during the creation of the service. After service creation, you can't change the target group's Amazon Resource Name (ARN), container name, or the container port specified in the service definition. You can't add, remove, or change the load balancer configuration of an existing service. If you update the service task definition, then the container name and container port specified at service creation must remain in the task definition. For more information, see Service load balancing.Open the Amazon Elastic Compute Cloud (Amazon EC2) console, and then choose Target Groups from the navigation pane. Choose the hyperlinked name for your target group. From the Targets tab, you can see what port is used for the task in the service that you created.If dynamic port mapping is set up correctly, then you see the registered targets in the target group and the assigned port for the task. You also see the task in the registered targets for the following ephemeral port ranges: 49153–65535 and 32768–61000.Related informationWhat is Elastic Load Balancing?What is an Application Load Balancer?Follow"


Question: Why do I get the "EMR_DefaultRole is invalid" or "EMR_EC2_DefaultRole is invalid" error when I create an Amazon EMR cluster?

"When I try to create an Amazon EMR cluster, I get one of these error messages:"EMR_DefaultRole is invalid""EMR_EC2_DefaultRole is invalid""

Answer: "When I try to create an Amazon EMR cluster, I get one of these error messages:"EMR_DefaultRole is invalid""EMR_EC2_DefaultRole is invalid"Short descriptionThese errors usually happen when you edit one or more of the AWS Identity and Access Management (IAM) policies that are attached to the Amazon EMR default roles. To troubleshoot, compare the modified roles to the original versions (AmazonElasticMapReduceRole or AmazonElasticMapReduceforEC2Role).If you can't find the source of the problem, then delete and recreate the roles.ResolutionCompare the modified roles to the original versionsIf you added policies to the IAM roles EMR_DefaultRole or EMR_EC2_DefaultRole, then review the changes that you made. Compare the modified versions of the roles to the original versions (AmazonElasticMapReduceRole or AmazonElasticMapReduceforEC2Role). If you can't determine what caused the problem, delete the roles and the instance profile, as explained in the following section.Delete and recreate the roles and instance profileBefore you begin, note the following:Be sure that you don't have any running EC2 instances that use the role or instance profile that you're about to delete. Deleting a role or instance profile that's associated with a running instance breaks applications that are running on the instance.The following steps reset EMR_DefaultRole and EMR_EC2_DefaultRole to their original configurations. If you customized the IAM policies attached to these roles, then those changes are lost.AWS Management Console1.    Use the IAM console to delete the roles. IAM automatically deletes the instance profile and policies associated with the role.2.    Open the Amazon EMR console.3.    Create an EMR cluster. For Permissions, choose Default. Amazon EMR creates the default roles when it launches the cluster. These roles are available to any clusters that you launch later.AWS Command Line Interface (AWS CLI)Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.1.    Remove EMR_EC2_DefaultRole from the instance profile:aws iam remove-role-from-instance-profile --instance-profile-name EMR_EC2_DefaultRole --role-name EMR_EC2_DefaultRole2.    Delete the instance profile:aws iam delete-instance-profile --instance-profile-name EMR_EC2_DefaultRole3.    Remove the IAM policy that's associated with  EMR_EC2_DefaultRole:aws iam detach-role-policy --role-name EMR_EC2_DefaultRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonElasticMapReduceforEC2Role4.    Delete EMR_EC2_DefaultRole:aws iam delete-role --role-name EMR_EC2_DefaultRole5.    Remove the IAM policy that's associated with EMR_DefaultRole:aws iam detach-role-policy --role-name EMR_DefaultRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonElasticMapReduceRole6.    Delete EMR_DefaultRole:aws iam delete-role --role-name EMR_DefaultRole7.    Recreate the default roles:aws emr create-default-roles8.    Launch a new EMR cluster.Related informationConfigure IAM service roles for Amazon EMR permissions to AWS services and resourcesFollow"


Question: How do I increase the available disk space on my Amazon ECS container instances if I launched my ECS cluster from the AWS Management Console?

How do I increase the total disk space on my Amazon Elastic Container Service (Amazon ECS) container instances if I launch my ECS cluster from the AWS Management Console?

Answer: "How do I increase the total disk space on my Amazon Elastic Container Service (Amazon ECS) container instances if I launch my ECS cluster from the AWS Management Console?Short descriptionTo increase the storage space on your container instances, you must launch replacement instances, and then terminate your original instances.To increase the storage space using this method, complete the steps in the Resolution section. If you launched your container instances using another method, then skip this article and complete the steps in one of the following articles:How do I increase the available disk space on my Amazon ECS container instances if I launched my cluster manually with an Auto Scaling group?How do I increase the available disk space on my Amazon ECS container instances if I launched my container instances as standalone Amazon EC2 instances?Note: Your Amazon Elastic Block Store (Amazon EBS) volume configuration varies depending on the Amazon ECS optimized Amazon Machine Image (AMI) that you're using. For more information and commands on how to check the available space on your instances, see AMI Storage Configuration.Important: The following steps terminate the original container instances in your Amazon ECS cluster. Any data that's stored on the EBS volumes for those instances will be lost when you complete these steps.ResolutionUpdate the storage size and launch replacement instancesOpen the Amazon ECS console, and then identify the name of the ECS cluster where you want to launch your new container instances.Identify the instances that are running in your Auto Scaling group.Open the AWS CloudFormation console, and then select the stack for your ECS cluster.Note: The stack name is in the following format: EC2ContainerService-yourEcsClusterName.Choose Actions, and then choose Update Stack.In the Select Template section, choose Use current template, and then choose Next.Set the EBsVolumeSize parameter to the new size required for your instances in GB.Set the AsgMaxSize parameter to increase the size of the Auto Scaling group, and then launch new replacement instances.Note: For Amazon ECS optimized Amazon Linux 1 AMIs, use /dev/xvda for the operating system, and use /dev/xvdcz for Docker images and metadata with logical volume management (LVM) devices. For Amazon ECS optimized Amazon Linux 2 AMIs, use /dev/xvda for the operating system and for Docker images and metadata.Set the DeviceName for your Amazon Linux version.Step through the rest of the setup wizard by choosing Next for each page, and then choose Update to launch your new replacement instances.Now, the launch configuration for your Auto Scaling group is updated to the new storage configuration. This increased configuration also applies to any new instances that are launched by the Auto Scaling group.Terminate your original instancesImportant: To be sure that your services remain available, you must drain the container instances to reschedule your tasks, and then terminate your original instances in batches. You can also automate this draining workflow when an instance is terminated.Open the Amazon ECS console, identify the first batch of instances that are running in your Auto Scaling group, and then drain your instances in this batch.Note: You can drain the previous instances in batches to avoid downtime for your Amazon ECS services. When you drain service tasks for container instances, container instances that are in the RUNNING state are stopped and replaced according to the service's deployment configuration parameters, minimumHealthyPercent and maximumPercent. Any PENDING or RUNNING tasks that don't belong to the service are unaffected. You must either wait for these tasks to finish or stop them manually.After all the tasks on the container instance are stopped, terminate the container instance.Note: After several minutes, the underlying Auto Scaling group launches a replacement instance with increased storage to replace the terminated instance.Repeat steps 1-2 until you replace all the original instances with your new container instances.Your tasks should now be running on the new instances with more storage available.Related informationAMI storage configurationUsing data volumes in tasksFollow"


Question: How do I calculate the render rate for a MediaTailor configuration?

I want to calculate the render rate for my ad impressions in AWS Elemental MediaTailor. How do I use Amazon CloudWatch for this?

Answer: "I want to calculate the render rate for my ad impressions in AWS Elemental MediaTailor. How do I use Amazon CloudWatch for this?Short descriptionAmazon CloudWatch monitors metrics and logs from AWS Elemental MediaTailor. CloudWatch metrics provide a variety of reports, including MediaTailor billing. The metrics show a granular view or a per-configuration view of the total number of advertisements inserted. CloudWatch metrics also calculate the render rate. Render rate is the percentage of ad impressions served out of the total number of ads received back from the Ad Decision Server (ADS). MediaTailor calculates the render rate as (AdImpressions/AdsReturned)*100.CloudWatch records AdImpressions as Avail.impression. The value increments when the first segment of an advertisement is requested. AdsInserted is recorded as AdDecisonServer.Ads. The value increments when MediaTailor inserts an advertisement in the manifest.ResolutionOpen the CloudWatch console.On the left-hand navigation bar, choose Metrics, All metrics.In the All metrics tab, in AWS namespaces, choose MediaTailor. This displays all metrics for the MediaTailor service.Under Metrics, choose Configuration Name. In the search bar, enter the name of the configuration that you want to calculate the render rate for.For the specific ConfigurationName, select the AdDecisionServer.Ads metric.In the same ConfigurationName, select the Avail.Impression metric.In the upper right corner of the graph, select the time period. Change the format of the graph from Line to Number.In the Graphed metrics, for the Statistic, choose Sum. This displays the total number of impressions as a number.Calculate the render rate for this configuration using the math percentage expression:In the Graphed metrics tab, select the arrow next to Math expression.Choose Common, Percentage. This creates a new row in the table with an Id.For the Label, enter Render Rate. Make a note of the IDs for AdDecisionServer.Ads and Avail.Impression.In Details, enter 100*(ID for Avail.Impression/ID for AdDecisionServer.Ads). For example, if m1 is the AdDecisionServer.Ads and m2 is the Avail.Impression, then enter 100*(m2/m1). Under the Untitled graph you see the Render Rate.To add a name to the metrics and the graph, select the pencil icon next to Untitled graph. Enter the name for the graph. To change the label of the Id, select the pencil icon next to the label.Scenarios that might result in low impressionsScenario 1If the first request for an ad manifest has an ad break one minute before the live edge, then you might see a low impression count. By default, MediaTailor fills the ad break with ads. If the player starts playing at the live edge, the viewer doesn't see the ad that MediaTailor inserted. In this case, the best practice is to turn on avail suppression. See Configuring ad break suppression for details.Scenario 2When an ad break starts in a stream that a viewer is watching, if MediaTailor inserts multiple ads but the viewer closes the player during the first ad, MediaTailor doesn't send impressions for the remaining unwatched ads.There might be additional scenarios that result in lower than expected impressions. For more information, see Monitoring and tagging in the AWS Elemental MediaTailor User Guide.Follow"


Question: How do I allow domain users RDP access to an EC2 Windows instance using group policy in AWS Managed Microsoft AD or Simple AD?

"My Amazon Elastic Compute Cloud (Amazon EC2) Windows instance is joined to AWS Directory Service for Microsoft Active Directory or Simple Active Directory (Simple AD). I want to allow domain users Remote Desktop Protocol (RDP) access for the instance. When I try to connect using the built-in Remote Desktop Users group as a domain user, I receive the following message: "The connection was denied because the user account is not authorized for remote login." How can I fix this?"

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) Windows instance is joined to AWS Directory Service for Microsoft Active Directory or Simple Active Directory (Simple AD). I want to allow domain users Remote Desktop Protocol (RDP) access for the instance. When I try to connect using the built-in Remote Desktop Users group as a domain user, I receive the following message: "The connection was denied because the user account is not authorized for remote login." How can I fix this?Short descriptionAWS Managed Microsoft AD and Simple AD don't allow you to add domain users to the built-in Remote Desktop Users domain group. Instead, create a Group Policy Object (GPO) using the built-in Admin account, and then apply the policy to the delegated computers.Note: The GPO applies to all computers in the organizational unit (OU) that the policy is linked to. Any users that you add to the group using the following procedure will have RDP access to any computer in the OU.ResolutionBefore you start:Join an EC2 Windows instance (Windows Server 2012 R2 or later) to a Simple AD or AWS Managed Microsoft AD directory.Install the Remote Server Administration Tools (RSAT) and Group Policy Management console on the instance.To allow domain users RDP access to the domain joined Windows instances, follow these steps:Connect to your Windows EC2 instance using RDP.Create a user. Repeat this step if you need more than one user.Create a security group. Note the security group name for a later step.Add the new users to the new security group.Open Group Policy Management. Select your domain’s Forest, expand Domains, and then expand your domain name.Expand your delegated OU (NetBIOS name of the directory). Open the context (right-click) menu for Computers, and then choose Create a GPO in this domain, and Link it here.For Name, enter a name, and then choose Ok.In the navigation pane, expand Computers. Open the context (right-click) menu for the policy, and then choose Edit.In the Computer Configuration section of the navigation pane, expand Preferences, Control Panel Settings.Open the context (right-click) menu for Local Users and Groups, and then choose New, Local Group.For Group name, choose Remote Desktop Users (built-in), and then choose Add.For Name, enter the name of the security group that you created in step 3, and then choose Ok.This policy updates your environment at the next policy refresh interval. To force the policy to apply immediately, run the gpupdate /force command on the target server.Related informationAWS Managed Microsoft ADSimply Active DirectoryManage users and groups in AWS Managed Microsoft ADFollow"


Question: Why are the tasks in my Amazon ECS cluster failing to start?

"I'm trying to place a task in my Amazon Elastic Container Service (Amazon ECS) cluster. However, my task placement is failing, and my task won't change to the RUNNING state in my cluster."

Answer: "I'm trying to place a task in my Amazon Elastic Container Service (Amazon ECS) cluster. However, my task placement is failing, and my task won't change to the RUNNING state in my cluster.Short descriptionTo successfully place your task in your cluster, choose one of the following solutions:If you placed your task with the Amazon ECS service, then complete the steps in the Check your service event messages and the Check the stopped task for errors sections.If you ran your task a standalone task or scheduled task, then complete the steps in the Check the stopped task for errors section.ResolutionCheck your service event messagesOpen the Amazon ECS console.In the navigation menu, choose Clusters, and then select the cluster that contains your service.On the Services tab of your cluster's page, in the Service Name column, select the service that you want to inspect.On your service's page, choose Events.In the Message column, look for errors or other useful information.Based on your findings from step 5, review Service event messages to troubleshoot your error.Note: Service events display only the last 100 events.Check the stopped task for errorsImportant: You can see a stopped task that was stopped only in the last 1 hour.Open the Amazon ECS console.In the navigation menu, choose Clusters, and then select the cluster that contains your stopped task.On your cluster's page, choose the Tasks tab.In the Desired task status table header, choose Stopped, and then select the stopped task to inspect. The most recent stopped tasks are listed first.On the Details tab of your stopped task, inspect the Stopped reason field to find out why your task was stopped.If there is a container that's stopped and the Stopped reason is Task failed to start, expand the container, and then inspect the Status reason row to see what caused the task state to change.Based on your findings from step 5, review the following information to resolve your error:Task failed ELB health checks in (elb elb-name): The current task failed the Elastic Load Balancing health check for the load balancer that's associated with the task's service. For more information, see Troubleshooting service load balancers.Note: This root cause is applicable only for tasks launched as part of the service.Scaling activity initiated by (deployment deployment-id): When you reduce the desired count of a stable service, some tasks must be stopped to reach the desired number. You see this Stopped reason for tasks that are stopped due to the downscaling of services. For more information, see Troubleshooting service auto scaling.Note: This root cause is applicable only for tasks launched as part of the service.Host EC2 (instance id) stopped/terminated: You see this Stopped reason if you stop or terminate an Amazon Elastic Compute Cloud (Amazon EC2) container instance with running tasks. To investigate why your Amazon EC2 instance was terminated, see Why did Amazon EC2 terminate my instance?Container instance deregistration forced by user: If you force the deregistration of a container instance with running tasks, then you see this Stopped reason.Essential container in task exited: If a container marked as essential in the task definition exits or dies, the task might be stopped. You see this Stopped reason when an essential container exiting is the cause of a stopped task. In this case, the findings from step 6 provide more diagnostic information about why the container stopped.Also, review API failure reasons.Based on your findings from step 6, review the following information to resolve your error:If the container status has the error CannotPullContainerError, see CannotPullContainer task errors.For other error messages returned and more information on these error messages, see Stopped tasks error codes.If this inspection doesn't provide enough information and you used the EC2 launch type, then connect to the container instance with SSH and inspect the Docker container locally. For more information, see Inspect Docker containers.Note: If you're using any task placement constraints or strategies, your cluster must use instances that meet the requirements of your constraints or strategies.Related informationHow do I resolve the "[AWS service] was unable to place a task because no container instance met all of its requirements" error in Amazon ECS?How do I resolve "the closest matching container-instance container-instance-id has insufficient CPU units available" error in Amazon ECS?How do I resolve "the closest matching container-instance container-instance-id encountered error 'AGENT'" error for my service in Amazon ECS?How can I resolve the Amazon ECR error "CannotPullContainerError: API error" in Amazon ECS?How can I resolve the “CannotPullContainerError: Error response from daemon:Get https://registry-name/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)” error in Amazon ECS?Follow"


Question: How do I troubleshoot the "Unable to execute HTTP request... connect timed out" error in AWS Glue?

My AWS Glue job fails with the error "Unable to execute HTTP request... connect timed out".

Answer: "My AWS Glue job fails with the error "Unable to execute HTTP request... connect timed out".Short descriptionWhen you run an AWS Glue job with a connection attached to it, it might fail when it tries to connect to another service endpoint. For example, it might try to connect to a service endpoint such as Amazon Simple Storage Service (Amazon S3) and AWS Key Management Service (AWS KMS). The job fails if the networking route to this service endpoint is missing in the subnet that's used in the AWS Glue connection. The "Unable to execute HTTP request" or "failed: connect timed out" error message appears in AWS Glue job logs.You get this error for the following reasons:The subnet that's configured in your AWS Glue connection contains an internet gateway or no route in the route table for the failed service endpoint.When you run your AWS Glue job, it interacts with the AWS Glue APIs. This happens if you use any operations that require listing AWS Glue Data Catalog tables, creating new tables, or reading from one. When your job needs to access the AWS Glue API, it sends an HTTP REST API request. Similarly, you might make other service API calls to Amazon S3, Amazon Simple Notification Service (Amazon SNS), or AWS Secret Manager. When you make the API call, then the job tries to connect with these service endpoints and the request fails with a timed-out error. This happens because although the job is able to send the request, it didn't receive the response within the timeout period.AWS Glue creates elastic network interfaces in the subnet specified in the AWS Glue connection. For more information, see Setting up network access to data stores.Resources in AWS Glue jobs have private IP addresses only. This means that jobs are unable to connect to other resources using an internet gateway. The AWS Glue job tries to send requests to the public AWS service endpoint, but these requests come from a private IP address. So the endpoint is unable to send a response back and the job fails with "connect timed out" error message.ResolutionThe error message that you find in logs looks similar to one of following, depending on your use-case:AWS Glue REST API:AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: com.amazonaws.SdkClientException: Unable to execute HTTP request: Connect to glue.ap-southeast-1.amazonaws.com:443Amazon S3 request:Unable to execute HTTP request: Connect to s3BucketName.us-east-1.amazonaws.com:443 [s3BucketName.s3.us-east-1.amazonaws.com/xx.xxx.xx.xxx ] failed: connect timed outAWS KMS request:Unable to execute HTTP request: Connect to kms.us-east-1.amazonaws.com:443 [kms.us-east-1.amazonaws.com/xx.xxx.xx.xxx ] failed: connect timed outConfirm that the traffic between the AWS Glue job and the service that the job is trying to make an API request to is allowed. You can check this by using a virtual private cloud (VPC) endpoint, or by using a NAT gateway.Using a VPC endpointUse the Amazon Virtual Private Cloud (Amazon VPC) console to create an interface VPC endpoint for the service that you get the error for. For example, the AWS Glue job might fail and throw an error while trying to access the AWS Glue API. Create the interface endpoint for AWS Glue in the same VPC subnet that's configured for your AWS Glue connection. This confirms that the traffic that's supposed to connect to the AWS Glue endpoint does so using this interface.Open the Amazon VPC console.In the navigation pane, choose Endpoints.Choose Create endpoint.For Service category, choose AWS services.For Service name, choose the service that you're connecting to. For more information, see AWS services that integrate with AWS PrivateLink.For VPC, choose the VPC that you want to access the AWS service from.To create an interface endpoint for Amazon S3, you must clear Additional settings and Enable DNS name. This is because Amazon S3 doesn't support private DNS for interface VPC endpoints.For Subnets, choose one subnet per Availability Zone (AZ) that you want to access the AWS service from.For Security group, choose a security group to associate with the endpoint network interfaces. The security group rules must allow resources that will use the VPC endpoint. The VPC endpoint communicates with the AWS service, which then communicates with the endpoint network interface.For Policy, choose Full access. This allows all operations by all principals on all resources over the VPC endpoint. Or, choose Custom to attach a VPC endpoint policy. This policy controls the permissions that principals have to perform actions on resources over the VPC endpoint. This option is available only if the service supports VPC endpoint policies. For more information, see VPC endpoint policies.(Optional) To add a tag, choose Add new tag, and then enter the tag key and the tag value.Choose Create endpoint.Using a NAT gatewayAn AWS NAT Gateway connects resources privately and securely using the private internet. Create a private subnet and point your AWS Glue connection towards a private subnet. At the same time, create a NAT gateway in one of the public subnets of your AWS Glue VPC. Configure the route table of your AWS Glue connection subnet so that if traffic is routed to internet, it does so using this NAT Gateway. For more information, see How do I set up a NAT gateway for a private subnet in Amazon VPC? and NAT gateways.Note: If you are using a NAT gateway, then traffic to your service goes through the internet.Additional troubleshootingCheck that the connection security group and subnet network ACL allow AWS Glue to send traffic when making the API request.To test the connectivity issue, launch an EC2 instance in same VPC, subnet, and security group that you used when creating the AWS Glue connection. Then run the following command to confirm connectivity with the service endpoint:telnet <glue endpoint url> 443dig <glue endpoint url>Examples:$ telnet glue.us-east-1.amazonaws.com 443$ dig glue.us-east-1.amazonaws.comRelated informationTroubleshooting errors in AWS GlueFollow"