VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How do I install .NET Framework 3.5 on an EC2 Windows instance that doesn't have internet access?

I want to use .NET Framework 3.5 on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance, but my instance doesn't have internet access.When I try to install .NET Framework 3.5 using the Add Roles and Features wizard, I get an error similar to the following:"Do you need to specify an alternate source path? One or more installation selections are missing source files on the destination."How do I install .NET Framework 3.5 on my Amazon EC2 Windows instance when my instance doesn't have internet access?ResolutionIf your instance doesn't have internet access, AWS provides public Amazon Elastic Block Store (Amazon EBS) snapshots that include these extra files.Follow these steps:Find and attach the correct Amazon EBS volume for your instance using the Amazon EC2 console, Windows PowerShell, or the AWS Command Line Interface (AWS CLI). For instructions, see Adding Windows components using installation media.Bring the new volume online by making an Amazon EBS volume available for use on Windows.Install .NET Framework 3.5 using the Add Roles and Features wizard, or using Windows PowerShell.To confirm if you have successfully installed .NET Framework 3.5, see How to: Determine which .NET Framework versions are installed.

Related informationHow do I troubleshoot Remote Desktop connection issues to my Amazon EC2 Windows instance?.NET Framework 3.5 installation error: 0x800F0906, 0x800F081F, 0x800F0907
Question: How can I send memory and disk metrics from my EC2 instances to CloudWatch?

I want to send memory and disk metrics from my Amazon Elastic Compute Cloud (Amazon EC2) instances to Amazon CloudWatch Metrics. How can I do this?Short descriptionBy default, Amazon EC2 delivers a set of metrics related to your instance to CloudWatch in the AWS/EC2 namespace. This includes CPUUtilization, a set of disk Read and Write metrics, and a set of NetworkIn and NetworkOut metrics. But, EC2 doesn't provide metrics related to OS-level memory usage or disk usage metrics.To find these metrics and deliver them to CloudWatch as custom metrics, install the Unified CloudWatch Agent. Then, define these metrics in the Agent configuration file.Important: Custom metrics are charged according to their storage and API use.

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 download and install the CloudWatch agent manually using the AWS CLI or you can integrate it with AWS Systems Manager Agent (SSM Agent). The CloudWatch agent is supported on both Linux and Windows systems. Use these steps to install the CloudWatch agent:1.    Create IAM roles or users that enable the agent to collect metrics from the server and, optionally, integrate with AWS Systems Manager. Attach this IAM role to the EC2 instance that you want to install the agent on.2.    Download the agent package and install the agent package.3.    Create the CloudWatch agent configuration file and specify the metrics that you want to collect.This example shows a basic agent configuration file that reports memory usage and disk usage metrics on a Linux system:{  "metrics": {    "metrics_collected": {      "mem": {        "measurement": [          "mem_used_percent"        ]      },      "disk": {        "measurement": [          "used_percent"        ],        "resources": [          "*"        ]      }    },    "append_dimensions": {      "InstanceId": "${aws:InstanceId}"    }  }}This is an example of a basic agent configuration file for Windows systems:{  "metrics": {    "metrics_collected": {      "LogicalDisk": {        "measurement": [          "% Free Space"        ],        "resources": [          "*"        ]      },      "Memory": {        "measurement": [          "% Committed Bytes In Use"        ]      }    },    "append_dimensions": {      "InstanceId": "${aws:InstanceId}"    }  }}4.    Start the agent on your EC2 instance.When the agent is running, it reports metrics from your instance to the CWAgent namespace within CloudWatch, by default. If you experience issues, see Troubleshooting the CloudWatch agent.

Related informationMonitor your instances using CloudWatch
Question: What's the difference between the logout endpoint and the GlobalSignOut API in Amazon Cognito?

I want to understand how to use the logout endpoint and the GlobalSignOut API in Amazon Cognito.

Short descriptionThe Amazon Cognito logout endpoint clears a user session from a browser. The GlobalSignOut API invalidates all the access and refresh tokens that are issued to a specific user.

ResolutionSign out users with the logout endpointWhen you use a hosted endpoint for user authentication, Amazon Cognito stores a cookie named "cognito" in your browser. The cookie is associated with the Amazon Cognito domain that's configured with your user pool. The cookie is valid for 1 hour. When a user tries to sign in again during an active session, Amazon Cognito asks the user if they want to continue their existing session. This allows the user to sign in without providing credentials. If a user chooses the Sign in as example_username button to use an existing session, then the cookie's validity resets to 1 hour.When a user visits the logout endpoint in their browser, Amazon Cognito clears the session cookie. The user must provide their credentials to sign in again.When a user signs in with third-party identity providers (IdPs), there's an extra step to perform. If a user signs in using one of the third-party IdPs, then visiting the logout endpoint clears the "cognito" cookie from the browser. However, the IdP can still have an active session. Consider the following information when you're clearing out the user's IdP session:Amazon Cognito supports the single logout (SLO) feature for Security Assertion Markup Language version 2.0 (SAML 2.0) IdPs with HTTP POST Binding. If your provider accepts HTTP POST Binding on its SLO endpoint, then consider implementing SLO for SAML IdPs. If a user visits the logout endpoint with SLO turned on, then Amazon Cognito sends a signed logout request to the SAML IdP. Then, the SAML IdP clears the IdP session.For social and OpenID Connect (OIDC) IdPs, you must create a custom workflow to clear the IdP session from the browser.Sign out users with the GlobalSignOut APIWhen you use the GlobalSignOut API, Amazon Cognito revokes all the access and refresh tokens that are issued to a user. Note that only Amazon Cognito is informed of the token revocation. Your application might continue to accept the tokens until they expire.Your application can use both the GlobalSignOut and AdminUserGlobalSignOut APIs to globally sign out users. When your application uses REST APIs for Amazon Cognito user authentication, you must use these APIs to sign out users.When the application tries to use a revoked token, Amazon Cognito raises an error indicating that you revoked the refresh token. The user must sign in again to get a new set of JSON Web Tokens (JWTs).You can configure the expiration time for your access and ID tokens in your user pool app client. You can change the expiration time to a value between 5 minutes and 24 hours.
Question: How do I resolve the "Custom Named Resource already exists in stack" error in AWS CloudFormation?

My AWS CloudFormation stack fails to create a resource, and I receive an error message telling me that my resource already exists in the stack. How do I resolve this error?Short descriptionWhen you create a custom-named resource with the same name and set to the same value as another resource, CloudFormation can't differentiate between them. You then receive the error message, "Custom Named Resource already exists in stack." Each custom-named resource has a unique Physical ID. You can't reuse the Physical ID for most resources that are defined in CloudFormation.You can resolve this error by changing the name of the failing resource to a unique name. Or, you can choose to not define the custom name for that resource. If you don't set a custom name, then CloudFormation generates a unique name when the resource is created. This unique name won't conflict with your existing resources.Resolution1.    In the CloudFormation template that contains your failing resource, check if other explicitly declared resources have the same name as your failed resource.In the following example, the stack fails because each AWS Identity and Access Management (IAM) ManagedPolicy resource (ManagedPolicyName) has the same custom name (FinalS3WritePolicy).S3DeletePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      ManagedPolicyName:        Fn::Join:        - _        - - FinalS3WritePolicy          - Ref: EnvType      PolicyDocument:................S3WritePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      ManagedPolicyName:        Fn::Join:        - _        - - FinalS3WritePolicy          - Ref: EnvType      PolicyDocument:................2.    Update the name of any resource that has a duplicate name. For example, change the first instance of FinalS3WritePolicy in the preceding example to FinalS3DeletePolicy. Or, remove the custom name.In the following examples, Stack A succeeds because each IAM ManagedPolicy resource has a unique custom name (FinalS3DeletePolicy and FinalS3WritePolicy). Stack B succeeds because no custom name values are set for either ManagedPolicyName properties. When the resource is created, CloudFormation automatically generates a unique name for each IAM ManagedPolicy resource in Stack B.Stack A:S3DeletePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      ManagedPolicyName:        Fn::Join:        - _        - - FinalS3DeletePolicy          - Ref: EnvType      PolicyDocument:................S3WritePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      ManagedPolicyName:        Fn::Join:        - _        - - FinalS3WritePolicy          - Ref: EnvType      PolicyDocument:................Stack B:S3DeletePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      PolicyDocument:................S3WritePolicy:    Type: AWS::IAM::ManagedPolicy    Properties:      PolicyDocument:................Note: You can use the resolution in this article for related errors involving resources that exist in a different stack or resources created outside of CloudFormation.
Question: How do I resolve the "CharacterStringTooLong (Value is too long) encountered with {Value}" error that I receive when creating a TXT record using DKIM syntax?

I tried to create a DKIM text resource record that a third party provided in my Amazon Route 53 hosted zone. However, I got the following error: "CharacterStringTooLong (Value is too long) encountered with {Value}."Short descriptionDNS TXT records can contain up to 255 characters in a single string. You must split TXT record strings that are over 255 characters into multiple text strings within the same record.Note: If the value is split, then DKIM functionality doesn't break.Resolution1.    Open the resource record that you received from your third-party provider.2.    To adhere to the 255 character maximum for a single Route 53 TXT record, split the DKIM key value into two parts. To do this, follow these steps:Copy the DKIM key value from the resource record.Paste the DKIM key value in a new line of a text editor.Split the DKIM key value into two parts, and then enclose each part in double quotation marks. For example, the value for "long_string" is split into "long_""string".Note: Don't add a line break between the two parts.3.    Open the Route 53 console.4.    In the navigation pane, choose Hosted zones.5.    Select your hosted zone.6.    Choose Create Record Set.7.    In the Create Record Set panel, complete the following steps:For Name, enter the domain key identifier.For Type, choose TXT.For Alias, keep the default selection of No.For TTL, enter the number of seconds. The default value of 300 is typically sufficient.For Value, copy the split DKIM key value that you created in step 2 from your text editor. Paste the split value in the Value field.Choose Create.8.    Use dig or nslookup to confirm that the TXT record is presented as a single entry.dig:$ dig selector_key_1._domainkey.domain.com txt ...;; ANSWER SECTION: selector_key_1._domainkey.domain.com. 60 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz1xhXc+vJKhQJUch86o8Ia2+L/AYo4d5eRVrPMMWzz4EiM4eB4QC1hJ83YMCHLv5dDN2lJ3KWSd5tGOxF/FRj1KdN+Jdf+BVwuklBFO8IrDtMz/lk2CJjF8jlgIUmQAjs3lc/8Bee+" "IQeB2tLX9UWvQMpI3aZuh6Ym6hcvLnbEkALWaMQvqwgxZs1qF6t5VKMjWeNNWIScyNTYL4Ud8wDiBcWh492HustfGUxrl5zmRfEl8BzCbrOqpKPLBmk/xrHRw9PHIJyYOaZA2PFqVcp6mzxjyUmn0DH9HXdhIznflBoIOLL1dm77PyDOKdEWRkSLMCA72mZbFr9gxda72ocQIDAQAB"nslookup:    > nslookup -q=TXT selector_key_1._domainkey.domain.com...Non-authoritative answer:selector_key_1._domainkey.domain.com.    text =        "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz1xhXc+vJKhQJUch86o8Ia2+L/AYo4d5eRVrPMMWzz4EiM4eB4QC1hJ83YMCHLv5dDN2lJ3KWSd5tGOxF/FRj1KdN+Jdf+BVwuklBFO8IrDtMz/lk2CJjF8jlgIUmQAjs3lc/8Bee+"        "IQeB2tLX9UWvQMpI3aZuh6Ym6hcvLnbEkALWaMQvqwgxZs1qF6t5VKMjWeNNWIScyNTYL4Ud8wDiBcWh492HustfGUxrl5zmRfEl8BzCbrOqpKPLBmk/xrHRw9PHIJyYOaZA2PFqVcp6mzxjyUmn0DH9HXdhIznflBoIOLL1dm77PyDOKdEWRkSLMCA72mZbFr9gxda72ocQIDAQAB"Related informationTXT record type
Question: Why is my EMR cluster not terminating or terminating earlier than expected when I'm using an auto-termination policy?

I have an auto-termination policy configured for my Amazon EMR cluster. The cluster either keeps running as active or terminates earlier than the idle timeout configured in the auto-termination policy.

Short descriptionWhen you create an EMR cluster, you can turn on the auto-termination policy. The auto-termination policy terminates the cluster after a specific amount of idle time.Resolution1.    Make sure that the Amazon Elastic Compute Cloud (Amazon EC2) instance profile role, EMR_EC2_DefaultRole, has the following permissions. If the EMR EC2 instance profile role doesn't have these permissions, then the cluster stays active even if it meets the idle timeout requirement.{    "Version": "2012-10-17",    "Statement": {        "Sid": "AllowAutoTerminationPolicyActions",        "Effect": "Allow",        "Action": [            "elasticmapreduce:PutAutoTerminationPolicy",            "elasticmapreduce:GetAutoTerminationPolicy",            "elasticmapreduce:RemoveAutoTerminationPolicy"        ],        "Resource": "your-resources"    }In Amazon EMR versions 5.34 to 5.36 and 6.4.0 or later, a cluster is idle when the following are true:There are no active YARN applications.HDFS utilization is below 10%.There are no active EMR notebook or EMR Studio connections.There are no on-cluster application user interfaces in use.In Amazon EMR versions 5.30.0 to 5.33.1 and 6.1.0 to 6.3.0, a cluster is idle when the following are true:There are no active YARN applications.HDFS utilization is below 10%.The cluster has no active Spark jobs.2.    Make sure that the metrics-collector process is running. The metrics-collector process collects the metrics to determine auto termination. Run the following commands to check the metrics-collector process:ps -ef|grep metrics-collector-or-systemctl status metricscollector.serviceFor more information, see How do I restart a service in Amazon EMR?3.    When you turn on auto-termination using an auto-termination policy, Amazon EMR emits the AutoTerminationClusterIdle Amazon CloudWatch metric at a one-minute granularity. This metric evaluates if the cluster meets the idle state requirement. If this metric shows "1", then the cluster is idle. If it shows "0", then the cluster is still active.View the EMR cluster's CloudWatch metrics and verify that the AutoTerminationisCluseterIdle CloudWatch metric is continuously "1" in the cluster. If it's continuously "1", then the cluster qualifies for auto-termination.

Related informationUsing an auto-termination policyMonitor metrics with CloudWatch
Question: How can I migrate WorkSpace users between AWS Regions or AWS accounts?

I need to migrate my Amazon WorkSpaces fleet to a different AWS Region due to latency issues. I also need to migrate some of my WorkSpaces fleet to a different AWS account for billing purposes. How might I do this?ResolutionWorkSpaces doesn’t offer an authoritative mechanism to migrate a WorkSpace with user configurations and user data between AWS accounts or Regions. When a WorkSpace is created, its managed resources are bound to its directory service and subnet. However, there are methods you can use to make WorkSpaces images accessible across AWS accounts or Regions.Cross-Region redirectionAs part of its business continuity features, WorkSpaces offers a way to redirect users to another existing WorkSpace in a different AWS account or Region.For more information, see Cross-Region redirection for Amazon WorkSpaces.Sharing WorkSpace imagesWorkSpace images can be shared or migrated between AWS accounts and Regions. WorkSpaces images allow users to launch WorkSpaces resources with predefined applications and operating systems.For more information, see Share or unshare a custom WorkSpaces image and Copy a custom WorkSpaces image.

Related informationHow do I create a WorkSpaces image?How do I share WorkSpaces images or BYOL images with other AWS accounts?How do I troubleshoot WorkSpaces image creation issues?
Question: How do I create and attach an internet gateway to a VPC?

I want to create and attach an internet gateway to a virtual private cloud (VPC) so that resources in the VPC can communicate with the internet.

ResolutionFor the resources in a VPC to send and receive traffic from the internet, make sure you complete the following steps:You must attach an internet gateway to the VPC. For more information, see Create and attach an internet gateway.The route tables that are associated with your public subnet (including custom route tables) must have a route to the internet gateway.The security groups and network access control lists (network ACLs) that are associated with your VPC must allow traffic to and from the internet.Your subnet's resources must have a public IP address or an attached Elastic IP address.For more information on instructions for each of these steps, see Connect to the internet using an internet gateway.
Question: How can I enable audit logging for an Amazon RDS for MySQL or MariaDB instance and publish the logs to CloudWatch?

I want to audit database (DB) activity to meet compliance requirements for my Amazon Relational Database Service (Amazon RDS) DB instance that's running MySQL or MariaDB. Then, I want to publish the DB logs to Amazon CloudWatch. How can I do this?Short descriptionTo use the MariaDB Audit Plugin to capture events such as connections, disconnections, queries, or tables queried, you must do the following:Add and configure the MariaDB Audit Plugin and associate the DB instance with a custom option group.Publish the logs to CloudWatch.If you use Amazon Aurora MySQL-Compatible Edition, see How can I enable audit logging for my Aurora MySQL-Compatible DB cluster and publish the logs to CloudWatch?ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, confirm that you're running a recent version of the AWS CLI.Amazon RDS supports Audit Plugin option settings on the following versions for MySQL and MariaDB:All MySQL 5.7 versionsMySQL 5.7.16 and higher 5.7 versionsMySQL 8.0.25 and higher 8.0 versionsMariaDB 10.2 and higherFor more information about supported versions, see MariaDB Audit Plugin support and Options for MariaDB database engines.Add and configure the MariaDB Audit Plugin and associate the DB instance with a custom option group1.    Create a custom option group or modify an existing custom option group.2.    Add the MariaDB Audit Plugin option to the option group and configure the option settings.3.    Apply the option group to the DB instance.To apply the option to a new DB instance, configure the instance to use the newly created option group when you launch the DB instance. To apply the option to an existing DB instance, modify the DB instance and attach the new option group. For more information, see Modifying an Amazon RDS DB instance.After you configure the DB instance with the MariaDB Audit Plugin, you don't need to reboot the DB instance. When the option group is active, auditing begins immediately.Note: Amazon RDS doesn't support turning off logging in the MariaDB Audit Plugin. To turn off audit logging, remove the plugin from the associated option group. This restarts the instance automatically. To limit the length of the query string in a record, use the SERVER_AUDIT_QUERY_LOG_LIMIT option.Publish audit logs to CloudWatch1.    Open the Amazon RDS console.2.    Choose Databases from the navigation pane.3.    Select the DB instance that you want to use to export log data to CloudWatch.4.    Choose Modify.5.    From the Log exports section, select Audit log.6.    Choose Continue.7.    Review the Summary of modifications, and then choose Modify instance.You can also use the following AWS CLI command syntax to turn on CloudWatch log exports:aws rds modify-db-instance --db-instance-identifier <mydbinstance> --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'After turning on audit logging and modifying your instance to export logs, events that are recorded in audit logs are sent to CloudWatch. Then, you can monitor the log events in CloudWatch.
Question: Can I restrict the access of IAM Identity to specific Amazon EC2 resources?

I want to restrict access of an AWS Identity and Access Management (IAM) user/group/role to a specific Amazon Elastic Compute Cloud (Amazon EC2) resource on the same account. How can I do this?ResolutionAmazon EC2 has partial support for resource-level permissions or conditions. This means that for certain Amazon EC2 actions, you can control when users are allowed to use those actions based on conditions that have to be fulfilled, or specific resources that users are allowed to use.Isolating IAM users or groups of user's access to Amazon EC2 resources by any criteria other than AWS Region doesn't fit most use cases. If you must isolate your resources by Region or any conditions on the same account, be sure to check the list of Amazon EC2 actions that support resource-level permissions and conditions to verify that your use case is supported.Below is an example of a policy that can be used to restrict access of an IAM identity (user/group/role) to only Start/Stop/Reboot EC2 instances in the N. Virginia (us-east-1) Region. The instance must have a tag key of "Owner" with a tag value of "Bob." "ec2:Describe*" is added to the policy to grant permission to describe the EC2 instance and all associated resources in the AWS management EC2 console.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "ec2:Describe*",      "Resource": "*"    },    {      "Effect": "Allow",      "Action": [        "ec2:StartInstances",        "ec2:StopInstances",        "ec2:RebootInstances"      ],      "Resource": [        "arn:aws:ec2:us-east-1:111122223333:instance/*"      ],      "Condition": {        "StringEquals": {          "ec2:ResourceTag/Owner": "Bob"        }      }    }  ]}Note: Replace "Owner," "Bob," and the resource ARN with parameters from your environment.After creating the policy, you can attach it to either an IAM user, group, or roleFor tagging use cases and best practices, see Best practices.

Related informationIAM policies for Amazon EC2Identity and access management for Amazon EC2Amazon EC2 API actionsAmazon Resource Names (ARNs)