VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How do I request an AWS Health event for testing integration with AWS Health?

I want to use an AWS Health event to test integration with AWS Health.

ResolutionIf you have a Developer, Business or Enterprise Support plan, then you can open a technical support case to request an AWS Health test event. You can then use this AWS Health event for testing purposes with the AWS Health service.Note: If you have a Basic Support plan, then you can upgrade your Support plan. For more information, see How do I change my AWS Support plan?1.    Open the AWS Support Center. Or, in the AWS Management Console, choose the question mark icon, and then choose Support Center.2.    Choose Create case, choose Technical, and then choose Next step: Additional information.3.    Choose the Service dropdown list, and then choose Health.4.    Choose the Category as Other, and the Severity as General guidance.5.    Enter the following information in the case details:A brief overview of the solution being testedThe date for when you want AWS to create the test eventThe AWS Region for the eventThe event type categoryThe event start time (the time that the event begins or began)The event end time (the time that the event ends or ended)6.    Choose Submit.

Related informationWhat is AWS Health?
Question: How does WorkSpaces manage operating system updates for Windows?

I need more information about how Amazon WorkSpaces manages operating system (OS) updates for Windows. What do I need to know?ResolutionWindows WorkSpaces are configured to download and install updates and patches during default maintenance windows. The running mode for your WorkSpace determines its default maintenance windows. As a best practice, keep Windows Update active in your WorkSpaces.Note: The default time zone for a WorkSpace is the same as its AWS Region.AlwaysOn WorkSpaces maintenance windows for updates and patchesThe default maintenance window for AlwaysOn WorkSpaces OS updates is a 4-hour time period each week. Updates can run each Sunday from 00h00–04h00 in the time zone set for the WorkSpace. When time zone redirection is turned on, the time zone of the WorkSpace is updated when a user connects from another Region.Note: To learn more about turning off time zone redirection, see Turn off time zone redirection for PCoIP and Turn off time zone redirection for WSP.AutoStop WorkSpaces maintenance windows for updates and patchesThe default maintenance window for AutoStop WorkSpaces OS updates is a 5-hour time period each day for up to 2 weeks each month. OS updates can run starting the third Monday of the month and can run on any day during the 2-week maintenance window. Updates can run from 00h00–05h00 in the time zone set for the WorkSpace.Microsoft releases software patches on the second Tuesday of each month. AutoStop WorkSpaces scan for and install any software patches on any day during the 2-week maintenance window.Additional update considerationsWhen you set up customizations through group policy, you might restrict or control Windows updates. You need to configure Windows OS update settings for maintenance windows to function in WorkSpaces.For PColP and other WorkSpace components, the system scans for updates during maintenance windows. Updates are pushed upon each reboot.For more information about settings that can affect Windows updates, see Manage Windows WorkSpaces.You can manage Windows updates for WorkSpaces by configuring a Windows Server Update Server (WSUS Server). When a WorkSpace has no outbound internet access, configuring a WSUS server is the only way to update the WorkSpace.For more information, see Deploy Windows Server Update Services on the Microsoft website.If you prefer, you can temporarily change your WorkSpace state to Maintenance so that you can manually perform OS maintenance tasks.For more information about changing your WorkSpace state to perform maintenance, see Manual maintenance.

Related informationWorkSpace maintenanceBest practices for deploying Amazon WorkSpaces
Question: How do I encrypt Amazon RDS snapshots using a KMS key?

I've enabled encryption on an unencrypted Amazon Relational Database Service (RDS) instance, and I want to take an encrypted snapshot of that instance. How do I take an encrypted snapshot of my RDS instance?ResolutionYou can't take an encrypted snapshot of an unencrypted DB instance. However, you can perform a workaround that achieves the same results. The following steps are applicable to Amazon RDS for MySQL, Oracle, SQL Server, PostgreSQL, or MariaDB.Important: If you use Amazon Aurora, you can restore an unencrypted Aurora DB cluster snapshot to an encrypted Aurora DB cluster. However, you must specify an AWS Key Management Service (AWS KMS) encryption key when you restore from the unencrypted DB cluster snapshot. For more information, see Limitations of Amazon RDS encrypted DB instances.1.    Open the Amazon RDS console, and then choose Snapshots from the navigation pane.2.    Select the snapshot that you want to encrypt.3.    Under Snapshot Actions, choose Copy Snapshot.4.    Choose your Destination Region, and then enter your New DB Snapshot Identifier.5.    Change Enable Encryption to Yes.6.    Select your AWS KMS Key from the list.7.    Choose Copy Snapshot.After the snapshot status is available, the Encrypted field is set to "True" to indicate that the snapshot is encrypted. You can now use this encrypted DB snapshot to restore the DB instance from the DB snapshot.

Related informationCreating a DB snapshotEncrypting Amazon RDS resources
Question: How do I update to a newer version of a Node.js solution stack in Elastic Beanstalk?

I receive an error when I try a manual or managed update to a newer version of a Node.js solution stack in AWS Elastic Beanstalk.

Short descriptionYour update might fail if your current node version isn't supported by the node version in the solution stack that you're upgrading or downgrading to — that is, the target solution stack.If your update fails, you might receive an error similar to the following:============="Failed Environment update activity. Reason: Configuration validation exception: Invalid option value: '4.8.4' (Namespace: 'aws:elasticbeanstalk:container:nodejs', OptionName: 'NodeVersion'): Value is not one of the allowed values: [4.8.7, 4.9.1, 5.12.0, 6.15.1, 6.16.0, 6.17.0, 6.17.1, 7.10.1, 8.14.0, 8.15.0, 8.15.1, 8.16.0, 8.16.1, 8.16.2, 8.17.0, 10.14.1, 10.15.0, 10.15.1, 10.15.3, 10.16.0, 10.16.1, 10.16.2, 10.16.3, 10.17.0, 10.18.0, 10.18.1, 10.19.0, 12.14.0, 12.14.1, 12.15.0, 12.16.1]".=============To resolve this error, choose one of the following options:To create a new environment, perform a blue/green deployment.To use your existing environment, perform a two-part update based on the steps in the following Resolution section. First, update your Node.js node version, and then update your solution stack.

ResolutionImportant: The following steps are valid only for the discontinued Amazon Linux AMI (also called Amazon Linux 1) based solution stacks. For Amazon Linux 2 based solution stacks, the node version can be changed only by creating a new environment of the matching solution stack. For more information on configuring your version of Node.js on Amazon Linux 2 platforms, see Specifying Node.js dependencies with a package.json file.Open the Elastic Beanstalk console.In the navigation pane, choose Environments, and then choose your environment.In the navigation pane section for your environment, choose Configuration.For the Software row in the Category column, choose Edit.For Node.js version, select a node version that's supported by your target solution stack.Important: The node version must be supported by both your current solution stack and target solution stack. For example, if your Elastic Beanstalk environment is running on a 64bit Amazon Linux 2018.03 v4.5.1 running Node.js solution stack with node version 8.11.3, then you can upgrade only to a target solution stack that supports node version 8.11.3. To see what node versions are supported by each type of solution stack, see Node.js platform history.To upgrade or downgrade your node version, choose Apply.Upgrade or downgrade to the platform version of your target solution stack.
Question: How do I remove contacts from a callback queue in Amazon Connect?

I want to remove all contacts in my Amazon Connect contact center's callback queue.

ResolutionTo remove specific contacts from your callback queue, it's a best practice to use the StopContact API.Note: If you want to remove a contact but don't know the contact ID, then Subscribe to Amazon Connect contact events.If you can't use the StopContact API, then refer to the following options:Manually answer the contacts in the queue.Wait 7–14 days for Amazon Connect to remove the contacts.Deactivate the callback queue. Then, create a new callback queue to replace the deactivated queue. After you create the new callback queue, change the Set working queue parameter to the new queue in the contact flow. For instructions, see Create a flow for queued callbacks. Also, add the new callback queue to your agents' routing profile.Important: If you deactivate the callback queue, then keep the following points in mind:Deactivating the callback queue doesn't remove the contacts from the queue. Deactivating the queue only prevents Amazon Connect from adding new contacts to the queue.If you don't change the Set working queue parameter in the associated contact flow, then Amazon Connect doesn't create new callback contacts.You must update any APIs that use the previous queue's Amazon Resource Name (ARN) with the new callback queue's ARN. For example: the GetMetricData action.For more information, see Set up routing in the Amazon Connect Administrator Guide.
Question: How do I resolve a HTTP 503 or HTTP 504 error in Amazon OpenSearch Service?

I received an HTTP 503 or HTTP 504 error in Amazon OpenSearch Service. How do I resolve these errors?ResolutionHTTP 503: This error indicates that one or more cluster nodes don't have enough capacity to handle the request. For more information, see How do I resolve an HTTP 503 Service Unavailable error in Amazon OpenSearch Service?HTTP 504: This error happens when a request fails to complete within the idle timeout period. For more information, see How can I prevent HTTP 504 gateway timeout errors in Amazon OpenSearch Service?Related informationTroubleshooting Amazon OpenSearch Service
Question: How do I lock down API access to specific IP addresses in my Amazon EKS cluster?

I want to lock down API access to specific IP addresses in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Short descriptionYou can lock down access to two types of Amazon EKS API server access endpoints:Public access endpoints: Access to the API server is open to the public by default. You can lock down access to specific CIDR blocks and IP addresses.Private access endpoints: The API server can be accessed only from within an Amazon Virtual Private Cloud (Amazon VPC). You can further lock down access to specific VPC CIDR blocks through cluster security groups.

ResolutionLock down API public access endpointsOpen the Amazon EKS console.In the navigation pane, choose Clusters, and then select your cluster.In the Networking section, choose Update.Expand Advanced Settings.Note: The Advanced Settings options appear only when you activate public access.Enter a CIDR block that you want to allow access from.Note: For example, you can summarize an IP address range from 54.240.193.129 to 54.240.193.190 as 54.240.193.129/26. You can form a single IP address with a /32 notation (for example, 54.240.193.130/32). These CIDR blocks can't include reserved addresses.(Optional) To enter additional blocks, choose Add Source.Choose Update.Keep the following in mind:If you don't specify any CIDR blocks, then the public API server endpoint receives requests from all (0.0.0.0/0) IP addresses.It's a best practice to activate private endpoint access so that worker nodes and AWS Fargate pods (if used) can communicate with the cluster through the private endpoint.Without the private endpoint activated, your public access endpoint CIDR sources must include the egress sources from your Amazon VPC. For example, if you have a worker node in a private subnet that communicates with the internet through a NAT gateway, then you must add the outbound IP address of the NAT gateway as part of a CIDR block that's allowed on your public endpoint.Lock down API private access endpointsOpen the Amazon EKS console.In the navigation pane, choose Clusters, and then select your cluster.In the Networking section, note the name of the cluster security group and any additional security groups.Add ingress rules to any one of the security groups that you noted in step 3.Note: For your ingress rule, set TCP as the protocol, and set 443 as the port and source IP from which you allow access.

Related informationModifying cluster endpoint access
Question: How does my SageMaker container access Amazon S3 data and push logs to CloudWatch when I turn on network isolation?

I turned on network isolation for my Amazon SageMaker container. I want to know how the container accesses the Amazon Simple Storage Service (Amazon S3) data and pushes the logs to Amazon CloudWatch.

ResolutionWhen you turn on network isolation, SageMaker accesses Amazon S3 and CloudWatch in isolation to the training or inference containers. If you don't specify an Amazon Virtual Private Cloud (Amazon VPC), then data access and logging happens on the server side. In this case, the container can't access the network.When you specify VpcConfig in your training, processing, or model configuration, SageMaker creates two elastic network interfaces in the specified Amazon VPC. All the traffic is routed through these two elastic network interfaces in the specified VPC. One elastic network interface is for the algorithm container, and the other is for Amazon S3 and logging access. If you specify an Amazon VPC in VpcConfig, then the network isolation setting doesn't create the elastic network interface for the algorithm container. This blocks the container from all outbound networking calls. The other elastic network interface remains, and you can use it for Amazon S3 and logging access.In both cases, the internal SageMaker processes that are running on the nodes download the data. Then, the input channels that are specified in the job definition make this data available to the algorithm container. Also, the internal processes that are running on the node make the logs and metrics available to CloudWatch. These nodes connect to CloudWatch through the VPC that's in VpcConfig.Whether or not you specify VpcConfig, the container doesn't have access to any AWS credentials to make API calls to AWS services.

Related informationNetwork isolation
Question: How do I troubleshoot slow connections to a website hosted on my EC2 instance?

I'm running a public website on my Amazon Elastic Compute Cloud (Amazon EC2) instance. Connections to my website are slow. How do I resolve this?Short descriptionOver-utilization of your instance's resources might cause slow connections to a website hosted on the instance. Check the following to make sure that you aren't over-utilizing your instance's resources:Check the instance's system log for exhausted memory or disk full errors.Make sure that the instance's system log indicates the web service started correctly and is running.Make sure that the instance is within CPU utilization limitsMake sure that the Amazon Elastic Block Store (Amazon EBS) volume attached to the instance hasn't hit the IOPS or throughput limits.

ResolutionCheck the instance's system log for exhausted memory or disk full errorsCheck the instance's system logs for errors such as "Out of memory: kill process".Check the instance's system logs for error such as "oom-killer, "failure to fork", or other insufficient memory errors. For more information, see How do I tune memory allocation for an Apache web server running on an Amazon EC2 Linux instance?Check the instance screen shot for errors.Note: You might see out of memory or other insufficient memory errors if you're using docker containers, cgroups, and so on. These errors might be intentional due to your configuration.Make sure that the instance's system log indicates the web service started correctly and is runningReboot the instance and check to see your web service started normally or look for any errors that might prevent the restart.Make sure that the instance is within CPU utilization limitsCheck the NetworkIn and NetworkOut instance metrics in the CloudWatch metrics table.For T2 or T3 instances, check the CPU credit metrics in the CloudWatch metrics table to determine if the CPU credits are at or near zero. If the CPU credits are at zero, the CPUUtilization metric shows a saturation plateau at the baseline performance for the instance. The baseline performance might be 20%, 40%, or so on, depending on the instance type.For information on resolving this issue, see My EC2 Linux instance failed the instance check due to over-utilization of its resources. How do I troubleshoot this?Make sure that the Amazon Elastic Block Store (Amazon EBS) volume attached to the instance hasn't hit the IOPS or throughput limitsVerify that your EBS volume isn't hitting IOPS limits. If your volume hits its IOPS limit, latency increases, which negatively impacts your website. For information on optimizing volume performance, see How do I optimize the performance of my Amazon EBS Provisioned IOPS volumes?If you're using a GP2 volume, check that your volume hasn't exhausted the burst credits.

Related informationHow do I troubleshoot an unresponsive website hosted on my EC2 instance?
Question: How do I update my telephone number to reset my lost MFA device?

I want to update my telephone number to reset my lost multi-factor authentication (MFA) device.

Short descriptionI followed the instructions for recovering a root user MFA device or How do I reset my AWS root user account MFA device? I received the verification email, but not the automated telephone call with the code.

ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.You can update the AWS account telephone number using an AWS Identity and Access Management (IAM) user if:The IAM user who is active on the AWS account has administrator access permission.The IAM user has access to the AWS Billing console.Be sure that the telephone number has the correct international dialing code standard with no additional spaces or special characters. Also be sure to remove any leading zeros after the country code. For example, the UK country code is +44. Enter the telephone number 07911 123456 as +447911123456 for the UK.To update your phone number, do the following:1.    Log in to the AWS Billing and Cost Management Console with your IAM user credentials for the AWS account that you want to update. For more information on logging in as the correct user, see Signing in to the AWS Management Console as an IAM user or root user.2.    Choose Edit next to Contact Information.3.    Update your phone number that's associated to your account.Important: Be sure that the phone number is using the correct country code and doesn't have extra spaces.4.    Choose Update.The telephone number is now updated. To reset the lost MFA device using the AWS root user account, see How do I reset my AWS root user account MFA device?Note: It's a best practice to create an IAM user with administrator access and lock away the root user credentials. For more information, see Creating your first IAM admin user and user group.You can also manage primary and alternate contacts on AWS accounts within your organization from the AWS Organizations console, the AWS CLI, or AWS SDKs. For more information, see Accessing or updating the alternate contacts and Accessing or updating the primary account contact.If you need additional assistance, see Lost or unusable multi-factor authentication (MFA) device. Expand I'm still having problems and would like to contact AWS Support. Then, complete the Request assistance with lost or unusable MFA device form, and choose Submit.

Related informationHow do I change the email address that's associated with my AWS account?Managing an AWS account
Question: Why am I getting the error “Insufficient Lake Formation permissions on <Amazon S3 location>” in Amazon Athena even though my IAM user or role has the required S3 permissions?

When I try to create a database/table in Amazon Athena using the Amazon Simple Storage Service (Amazon S3) location that's registered with AWS Lake Formation, the query fails with the error "Insufficient Lake Formation permission(s) on      ". However, the Athena AWS Identity and Access Management (IAM) user or role has the necessary IAM permissions.

ResolutionYou get this error when the following conditions are true:The IAM user or role tries to create or alter a Data Catalog resource (database or table) on an Amazon S3 bucket that's registered with Lake Formation.The IAM user or role doesn’t have the appropriate data location permissions from Lake Formation.To resolve this error, you must grant appropriate data location permissions to the IAM user or role that you use to create the database or table. When you're using Athena with Lake Formation, be sure to grant the required S3 permissions to the IAM user or role from Lake Formation in addition to the data access permissions required by the IAM user or role. Data access permissions allow the IAM user or role to read and write data to the underlying Amazon S3 location. However, data location permissions in Lake Formation allow an IAM user or role to create and alter Data Catalog resources that point to the registered Amazon S3 location.To resolve this error, do the following:Verify that S3 path in Athena is registered with Lake Formation successfully.Grant the required data location permissions to the IAM user or role to access the S3 path.Verify that the data lake location is registered with Lake FormationSign in to the AWS Lake Formation console with data lake administrator role.In the navigation pane, under Register and Ingest, choose Data lake Locations.In the Data lake locations listing, verify that the S3 path pointed by the Data Catalog resources is registered with Lake Formation.Grant data location permissions from the AWS Lake Formation consoleIn the navigation pane, choose Data locations.Select Grant.In the Grant permissions dialog box, select My account.For IAM users and roles, select the IAM user or role that you want to grant permissions for.For Storage locations, select the S3 path that you’re getting the error from.Choose Grant.Note: Follow these steps only if the S3 path is within the same account. If the S3 path is in a different account, then be sure that all cross-account access prerequisites are met. Then, follow the instructions provided in Granting data location permissions (external account).

Related informationGranting data location permissions