VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How can I change the Session Manager shell to bash on EC2 Linux instances?

I want to change the Session Manager default shell on my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance. How can I do that?Short descriptionSession Manager sessions on Amazon EC2 Linux instances use the Bourne shell (sh) by default. However, bash is the default shell in major Linux distributions. If you’re more comfortable using bash than sh, you can change the default Session Manager shell to bash using configurable shell profiles. Shell profiles allow you to customize preferences within sessions when you use Session Manager, including:Shell preferencesEnvironment variablesWorking directoriesRunning multiple commands when a session startsYou can enable configurable shell profiles using the Systems Manager console or the AWS Command Line Interface (AWS CLI).

ResolutionPrerequisitesTo enable shell profiles, you must use SSM Agent version 3.0.196.0 or later. Check the SSM Agent version number on your instance. If necessary, update SSM Agent. For more information, see Automating updates to SSM Agent.To see the available shells on the instance, run the following command:$ sudo cat /etc/shellsNote: You can use any of the shells returned using this command.Enable configurable shell profiles (console)To enable configurable shell profiles and change the shell to bash using the Systems Manager console, follow these steps:1.    Open the Systems manager console, and then choose Session Manager from the navigation pane.2.    Choose the Preferences tab, and then choose Edit.3.    For "linux" under "shellProfile", enter the following:/bin/bash4.    Choose Save.Enable configurable shell profiles (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.For instructions to enable configurable shell profiles and change the shell to bash using the AWS CLI, see Create Session Manager preferences (command line).Other shell profile configuration optionsBy default, Session Manager starts in the “/usr/bin” directory. You can add a command to your shell profile to change the /usr directory on Linux instances. For example:cd /home/ec2-userYou can also use the shell profile to load specific environment variables, or to run a script at the start of the session. For example, to add the PYTHONPATH environment variable, add the following command to your shell profile:export PYTHONPATH=/usr/lib/python2.7When you are logged in, you can run the following command to verify that the environment variable is correctly set:$ sudo env

Related informationEnable configurable shell profilesGrant or deny user permissions to update Session Manager preferencesSpecify an idle session timeout value
Question: How do I resolve the "Getting error Too Many Requests" error when I submit an AWS Batch job?

My AWS Batch job fails, and I receive a "Getting error Too Many Requests" error.

Short descriptionAWS Batch throttles all API requests for AWS accounts based on an account's AWS Region. This makes sure that AWS Batch maintains consistent performance and fair usage for all customers. AWS Batch API quotas typically apply to every API, including the DescribeJobs and SubmitJob API calls.Note: The maximum number of transactions per second (TPS) for each account for SubmitJob operations is 50.When you reach your AWS Batch API quotas, AWS Batch returns the following error message:"Getting error Too Many Requests (Service: AWSBatch; Status Code: 429; Error Code: TooManyRequestsException)."There are two common reasons that Getting error Too Many Requests errors occur:Submitting multiple jobs at the same time programmatically, using the AWS Command Line Interface (CLI) or AWS SDKsUsing AWS Lambda to submit multiple jobs

ResolutionAs you troubleshoot the error, keep the following points in mind:API quotas apply only to AWS endpoints. These quotas don't apply to your account.AWS throttles Amazon API requests on a per-Region basis to prevent individual accounts from flooding the service endpoints with too many requests.AWS makes sure that all calls to all Amazon APIs don't exceed the maximum allowed API request rate. The maximum API request rate varies across Regions.Use retries and an exponential backoff algorithm with jitter, and then resubmit your jobFor more information, see Exponential backoff and jitter.Use AWS Batch array jobs to submit multiple jobs with a single SubmitJob API callFor more information, see Array jobs and SubmitJob.Note: AWS Batch array jobs allow you to submit up to 10,000 copies of a job.Adjusting API throttling quotasYou can request an increase for API throttling quotas for your AWS account. To request a quota adjustment, contact the AWS Support Center
Question: How do I resolve issues using short codes and long codes to send messages in Amazon SNS?

I want to use short codes and long codes to successfully send messages in Amazon Simple Notification Service (Amazon SNS).

Short descriptionIf you get failures after sending a message from a short code, go to the Check for a discrepancy between your message and origination identity section.If your short code is approved but messages are still sent by your long codes, go to the Troubleshoot messages sent from long codes section.Note: For information about pricing, see Worldwide SMS Pricing.Important: You can't share short codes or long codes between AWS Regions. Origination numbers are account and Region specific. You can use origination numbers only for the Region or account where the origination number was acquired.

ResolutionCheck for a discrepancy between your message and origination identityYou can get message delays or failures for multiple reasons. For example, you can get message delays or failures if your message type and the short code route type don't match.Important: You must send the appropriate message type through the same type of origination number that's acquired. That is, transactional messages must use transactional short codes, and promotional messages must use promotional short codes.To check for a discrepancy, complete the following steps:Open the Amazon SNS console.On the navigation pane, expand Mobile, and then choose Origination numbers.Check the value of the Route type for your short code.To check the message type that's set when a message is sent, check the smsType field in your delivery logs.Troubleshoot messages sent from long codesConfirm that you're sending messages from the right short code.Update the keywords and responses in your SMS settings in Amazon Pinpoint. The keywords and responses in your SMS settings must match the keywords and responses that you registered when you requested your short code.Confirm that the country that you're sending messages to with your short code is the same country where you acquired your short code.Important: You can't send messages to multiple countries with the same short code.Note: You can only send messages to US numbers using a US short code. If you send a message to a CA number from a US short code, the message is delivered from a random CA long code.

Related informationShort codesLong codes
Question: How do I resolve query timeout issues in QuickSight?

I'm trying to import data into Amazon QuickSight using direct query mode, but I get a query timeout error. How to resolve this issue?Short descriptionThe following are common reasons for getting timeout errors when you're importing data into QuickSight using direct query mode:Data preparation takes more than 50 seconds.Generating a visual takes more than 2 minutes.The query runtime exceeds the data source timeout quota for the Amazon service that you're importing from. To see the data source timeout quota for your Amazon service, see AWS service quotas.Note: You can't increase the 2-minute visual generation timeout quota.

ResolutionLimit the data that you're importingThe following are steps that you can take to limit the amount of data that you're importing into QuickSight:Unselect columns that you don't need.Add filters to your dataset in QuickSight.Use predicates in your custom SQL query such as WHERE and HAVING.Import the data into SPICEWhen you import your data into SPICE, queries process faster.Note: The 50-second timeout quota for data preparation and 2-minute timeout for generating visuals still apply when you use SPICE. However, if you're using Amazon Athena to import data into QuickSight, then the query timeout is 30 minutes.For more information on SPICE quotas for imported data and quotas for direct SQL queries, see Data source quotas.
Question: How do I update a CloudFormation stack that's failing because of a resource that I manually deleted?

I manually deleted a resource that was created by one of my AWS CloudFormation stacks, and now my stack won't update.

Short descriptionIf you delete a resource that was created by a CloudFormation stack, then your stack fails to update, and you get an error message.Choose one of the following resolutions based on your resource type:Update a resource with a unique nameUpdate a resource with a unique IDResolutionUpdate a resource with a unique nameIf the deleted resource supports a unique name, you can get your stack to update by manually creating the resource. The new resource, however, must have the same name as the deleted resource. For example, you can impact how CloudFormation handles a resource when you change a resource name. This is because AWS Identity and Access Management (IAM) roles are tracked by name. If you accidentally delete an IAM role, you can manually recreate that role with the same name.To update an IAM role or any other resource with a unique name, complete the following steps:Open the AWS CloudFormation console.Select your stack, and then choose the Resources view.In the Physical ID column, find the Physical ID of the IAM role that you want to replace with your new IAM role.Note: The Physical ID is the name of the resource.Create a new IAM role, and then give the new role the same Physical ID that you found in step 3.Update your stack.Note: For more information, see Modifying a stack template.Update a resource with a unique IDYou can't manually recreate a resource, such as a route table, with a unique ID. Instead, you must remove the resource and any references to that resource from your CloudFormation template.Note: The following resolution also works for resources that don't support a unique name or a unique ID. For example, a record set in a hosted zone.To allow CloudFormation to recreate a route table or any other resource with a unique ID, complete the following steps:In your CloudFormation template, remove the route table and any references to it.Update the stack.Note: CloudFormation tries to delete the route table. Because the resource has already been deleted, CloudFormation considers the deletion a successful operation.Add the route table and any additional resources or references that you require back to your CloudFormation template.Update your stack again.Note: CloudFormation recreates the deleted resource.

Related informationTroubleshooting AWS CloudFormation
Question: Does CloudFront support static IP addresses?

Can I associate a static IP address with my Amazon CloudFront distribution?ResolutionCloudFront doesn't support assigning a static IP address to distributions.When a user requests content from CloudFront, DNS returns 4 IP addresses of the edge location with the lowest latency. This allows content to be delivered with the best possible performance. Since edge locations are associated with different sets of IP addresses, you don't receive the same static address for your distribution when making a request.The IP address that is returned for the edge location is allocated dynamically from the IP address ranges of CloudFront edge servers list.The IP address ranges for CloudFront edge servers are subject to change. To be notified of IP address changes, subscribe to AWS Public IP Address Changes via Amazon SNS.

Related informationUsing a dedicated IP address to serve HTTPS requests (works for all clients)
Question: Why can't a target behind my Network Load Balancer connect to its own Network Load Balancer?

A target behind my Network Load Balancer is trying to connect to the same Network Load Balancer, but the connection fails. Why?Short descriptionWhen the target of an internal Network Load Balancer establishes a TCP connection to its own Network Load Balancer, the target can get routed to itself.Network Load Balancers preserve the source IP, so both the source and destination of the arriving packet are the private IP address of the target. Then, the host operating system sees the packet as not valid so it doesn't send response traffic, and the connection fails.Note: This connection failure happens only when the source and the target are the same. As a result, the connection issues happen intermittently, depending on the number of targets available to the Network Load Balancer.To correct this type of Network Load Balancer connection failure, deactivate client IP preservation for TCP and TLS target groups using the preserve_client_ip.enabled target group attribute.

ResolutionTo activate or deactivate client IP preservation using the new console, do the following:Open the Amazon EC2 console.On the navigation pane, under Load Balancing, choose Target Groups.Choose the name of the target group to open its details page.On the Attributes tab, choose Edit.To activate client IP preservation, choose Preserve client IP addresses. To deactivate client IP preservation, clear Preserve client IP addresses.Choose Save changes.If your application needs the IP addresses of the clients, activate proxy protocol support and access the client IP addresses from the proxy protocol header.

Related informationConnections time out for requests from a target to its load balancer
Question: Why is my AWS Config rule with required-tags status stuck on "Evaluating"?

I created an AWS Config managed rule using required-tags to check for specific resources. However, my AWS Config rule with required-tags status is still "Evaluating" resources, or reporting unexpected results.

ResolutionUse the following best practices when creating and editing AWS Config rules using required-tags.The AWS Config configuration recorder must be turned on and configured in the same AWS Region as the AWS Config rule. To turn the configuration recorder on or off, see managing the configuration recorder.AWS Config rules using required-tags typically return results in 20 minutes or less. Results can vary depending on the service or resource type due to downstream dependencies.If the AWS Config rules Scope of changes is set to Resources, then verify that the resource type (for example, EC2::Instance) is specified for the trigger.If the AWS Config rules Scope of changes is set to Tags with or without a tag value, then a supported resource must be tagged with a tag key.Verify that the AWS Identity and Access Management (IAM) role assigned to AWS Config has the AWS_ConfigRole managed policy attached. For more information, see IAM role policy for getting configuration details.For configuring AWS Config to record to Amazon Simple Storage Service (Amazon S3) buckets, verify that the permissions allow recording changes. For more information, see Troubleshooting for recording S3 buckets.

Related informationHow can I troubleshoot AWS Config console error messages?How can I be notified when an AWS resource is non-compliant using AWS Config?IAM role policy for getting configuration details
Question: How do I control access to my WorkSpaces?

I want to set access controls in Amazon WorkSpaces so that specific users or specific IP addresses can access my WorkSpace. How can I do that?ResolutionWorkSpaces access is managed in the directory details for your WorkSpace. The Access Control Options settings define the parameters for trusted devices. The IP Access Control Groups settings apply public IP addresses for the client connection.To access these settings for your WorkSpace, in the WorkSpaces console, choose Directories from the navigation pane. In the Actions dropdown, choose Update Details.Access Control OptionsUse Access Control Options to limit access to your WorkSpace. Do this by specifying the operating systems and certificates installed on the systems, or by choosing client platforms.To use certificates, you must have an internal certificate authority (CA) and provide two certificates:For the WorkSpaces directory: A root certificate generated by an internal CA.For a client device: An installed client certificate that links to a root certificate for the client device.For more information about creating and deploying certificates in WorkSpaces, see Restrict WorkSpaces access to trusted devices.IP Access Control GroupsUse IP Access Control Groups to restrict access based on the public IP address ranges that are allowed to connect to the WorkSpace. The allowed IP ranges are managed with groups created in the IP Access Controls navigation pane.These are the limitations of using this feature:Up to 25 IP access control groups are allowed with a single directory.100 IP access control groups are allowed in each AWS Region.For more information about IP access control groups, see IP access control groups for your WorkSpaces.Note: To find the public IP address of a user, use http://checkip.amazonaws.com/.
Question: How can I restrict access to a specific IAM role session using an IAM identity-based policy?

I want to grant permissions to a specific AWS Identity and Access Management (IAM) role session with an identity-based policy.

ResolutionCreate an IAM policy to allow access to a specific IAM role session using the AWS global condition context key aws:userid.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.The aws:userid global condition key checks if the Unique ID of the principal making the request matches the Unique ID specified in the IAM policy.For example, if you want to allow a specific IAM role session to perform only specific Amazon Elastic Compute Cloud (Amazon EC2) actions in your AWS account. Create an IAM policy similar to the following:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AllowASpecificRoleSession",            "Effect": "Allow",            "Action": [                "ec2:StartInstances",                "ec2:StopInstances",                "ec2:RebootInstances",                "ec2:TerminateInstances"            ],            "Resource": "*",            "Condition": {                "StringEquals": {                    "aws:userid": "AROAXXXXXXXXXXXXXXXXX:<role-session-name>"                }            }        }    ]}This IAM policy grants the Amazon EC2 instance access to the IAM role session in the aws:userid global condition key. Other role sessions can't perform any Amazon EC2 actions.To get the role ID for the IAM role, run the following AWS CLI command:$ aws iam get-role --role-name <rolename>You receive an output similar to the following:{    "Role": {        "Description": "Test Role",        "AssumeRolePolicyDocument":"<URL-encoded-JSON>",        "MaxSessionDuration": 3600,        "RoleId": "AROA1234567890EXAMPLE",        "CreateDate": "2019-11-13T16:45:56Z",        "RoleName": "Test-Role",        "Path": "/",        "RoleLastUsed": {            "Region": "us-east-1",            "LastUsedDate": "2019-11-13T17:14:00Z"        },        "Arn": "arn:aws:iam::123456789012:role/Test-Role"    }}In the output, check for the RoleId string. The role ID is used in the identity-based policy to scope Amazon EC2 instances access to the IAM role session.Note: The aws:userid global condition key can be used in any type of IAM policy such as an identity-based policy, resource-based policy, permission boundary policy, and so on. The values for aws:userid global condition key depend on what type of principal initiates the request. To determine the values for different types of principals, see Information available in all requests.

Related informationCan I restrict the access of IAM users to specific Amazon EC2 resources?How can I use IAM policy tags to restrict how an EC2 instance or EBS volume can be created?
Question: "How can I associate an ACM SSL/TLS certificate with a Classic, Application, or Network Load Balancer?"

How can I associate an AWS Certificate Manager (ACM) SSL/TLS certificate with a load balancer?Short descriptionACM is integrated with Elastic Load Balancing. You can request a public certificate using ACM or import a certificate into ACM. After you create or import your certificate, you can associate the certificate to your Classic, Application, or Network Load Balancer.

ResolutionFollow these steps to associate an ACM SSL certificate with your load balancer.Note: ACM certificates must be requested or imported in the same AWS Region as your Load Balancer.Associate an ACM SSL certificate with a Classic Load BalancerOpen the Amazon EC2 console.In the navigation pane, choose Load Balancers. Then, choose your Classic Load Balancer.Choose the Listeners tab, and then choose Edit.For Load Balancer Protocol, choose HTTPS.For SSL Certificate, choose Change.Select Choose a certificate from ACM.Select the certificate from Certificates dropdown list, and then choose Save.Associate an ACM SSL certificate with an Application Load BalancerOpen the Amazon EC2 console.In the navigation pane, choose Load Balancers, and then choose your Application Load Balancer.Choose Add listener.For Protocol, choose HTTPS.For port, choose 443.For Default action(s), choose Forward to, and then select your ALB target group from the dropdown list.For Default SSL certificate, choose From ACM (recommended) and then choose the ACM certificate.Choose Save.Note: Application Load Balancers support multiple SSL/TLS certificates using Server Name Identification (SNI). If you request a public certificate from ACM, you can't export private keys for ACM issued public certificates. You can't directly install Amazon-issued certificates on Amazon Elastic Compute Cloud (EC2) instances. Instead, use the certificate with a load balancer, and then register the EC2 instance behind the load balancer.Associate an ACM SSL certificate with a Network Load BalancerOpen the Amazon EC2 console.In the navigation pane, choose Load Balancers, and then choose your Network Load Balancer.Choose Add listener.For Protocol, choose TLS.For port, choose 443.For Default action(s), choose Forward to, and then select your NLB target group from the dropdown menu.For Default SSL certificate, choose From ACM (recommended) and choose the ACM certificate.Choose Save.

Related informationConfigure an HTTPS listener using the consoleCreate an HTTP listener for your Application Load BalancerNew – TLS termination for Network Load BalancersWhy can't I find my imported certificate for my load balancer or CloudFront distribution?Application Load Balancers now support multiple TLS certificates with smart selection using SNI