Question: How do I add or update my tax registration number or business legal address for my AWS account?

"I want to add or update my tax registration number (for example, a TRN, VAT number, VAT ID, GSTIN, or VAT registration number) or business legal address on my AWS account."

Answer: "I want to add or update my tax registration number (for example, a TRN, VAT number, VAT ID, GSTIN, or VAT registration number) or business legal address on my AWS account.Short descriptionIf you have a tax registration number (TRN), such as a VAT ID, then you can update the TRN and associated business legal address connected with your account in the AWS Billing and Cost Management console  on the Tax Settings  page. If you're signed in as the payer account of an organization, then you can also view and edit the tax registration numbers for all linked accounts.When updating your TRN or business legal address, note the following:If you don't have a TRN, or your country isn't available in the Tax Settings page, then AWS uses the address associated with the account's default payment method, the account's contact address, and the account's billing address to determine the account's tax jurisdiction.If you're not sure which country to choose for these fields, then consult your tax advisor.If you're in Europe and receive special status or relief from VAT, then contact AWS Support and attach applicable certificates issued by the tax authorities in your country. If you don't have a certificate, then provide information about your special status or relief in your case, and include specific sections of tax legislation that are applicable to your organization.If you're in the United States, then see Does AWS charge US sales tax?You can enable tax settings inheritance to use your tax registration information for linked accounts in your organization.ResolutionTo add the tax registration number or business legal address for your accountSign in to your account, and then open the AWS Billing and Cost Management console.From the navigation pane, choose Tax Settings.Choose Manage Tax Registration, and then choose Add.Select the country from the Country drop-down menu.Enter the required information, and then choose Update.Note: The country associated with your tax identification number and the country associated with your business legal address must match.To edit or update the tax registration number or business legal address for your accountSign in to your account and open the AWS Billing and Cost Management console.From the navigation pane, choose Tax Settings.Open Manage Tax Registration, and then choose Edit.Note: If you're signed in as the payer account of an organization, then you can edit the TRN and associated business legal address of multiple accounts in the consolidated billing family at the same time. Check the box next to each account in the consolidated billing family that you want to update, open Manage Tax Registration, and then choose Edit. Bulk editing is available for all accounts except for those in China.From the Country drop-down menu, choose the country where your account resides for tax purposes.Enter the required information, and then choose Update.Note: The country associated with your tax identification number and the country associated with your business legal address must match.Your tax registration numbers are reviewed by AWS before they are applied to your account.For more information about tax and AWS, see AWS tax help.Related informationWhat do I do if the tax I'm charged for AWS services is incorrect?Follow"


Question: How do I configure an SSO user to access my Amazon EKS cluster?

"I'm using AWS IAM Identity Center (successor to AWS Single Sign-On). However, I'm unable to access the Amazon Elastic Kubernetes Service (Amazon EKS) cluster. I want to configure the SSO user to access my cluster."

Answer: "I'm using AWS IAM Identity Center (successor to AWS Single Sign-On). However, I'm unable to access the Amazon Elastic Kubernetes Service (Amazon EKS) cluster. I want to configure the SSO user to access my cluster.ResolutionBe sure that the following prerequisites are met:You turned on and configured IAM Identity Center.Your SSO user is associated with the AWS account where the Amazon EKS cluster exists.Note: The following steps use kubectl to access the cluster. After you configure kubectl access, you can see the cluster resources in the Amazon EKS console by logging in as the IAM Identity Center user.Note: If you receive errors when running the AWS Command Line Interface (AWS CLI) commands, confirm that you're running a recent version of the AWS CLI.Configure AWS CLI to use your SSO userCreate an AWS Command Line Interface (AWS CLI) profile that uses the SSO authentication when running the AWS CLI commands. For more information, see Configuring the AWS CLI to use AWS IAM Identity Center (successor to AWS Single Sign-On).The following is an example of AWS CLI SSO configuration using the automatic procedure:aws configure ssoSSO start URL [None]: https://my-sso-portal.awsapps.com/startSSO region [None]: us-east-1The AWS CLI attempts to open your default browser and begin the login process for your IAM Identity Center account.Attempting to automatically open the SSO authorization page in your default browser.If the AWS CLI can't open the browser, you get the following message with instructions on how to manually start the login process:If the browser does not open or you wish to use a different device to authorize this request, open the following URL:https://device.sso.us-east-2.amazonaws.com/Then enter the code:XXXX-XXXXThe only AWS account available to you is: 123456789999Using the account ID 123456789999The only role available to you is: ViewOnlyAccessUsing the role name "ViewOnlyAccess"CLI default client Region [us-east-2]:CLI default output format [json]:CLI profile name [ViewOnlyAccess-123456789999]: test-profileTo use this profile, specify the profile name using --profile, as shown:aws s3 ls --profile test-profileYou can now run the AWS CLI commands using this new profile. This configuration allows your SSO user to do the following:Authenticate with AWS.Assume an AWS Identity and Management (IAM) role that was created by the IAM Identity Center.Example:$ aws sts get-caller-identity{    "UserId": "AROAXMRV33N1234567890:test-user",    "Account": "123456789999",    "Arn": "arn:aws:sts::123456789999:assumed-role/AWSReservedSSO_ViewOnlyAccess_05a3861234567890/test-user"}Configure kubectl context to use AWS CLI profile that's created for SSOKubectl uses AWS CLI commands. Therefore, you must specify the new AWS CLI profile in kubectl's current context. To update kubectl context to use the new profile, run the following command:aws eks update-kubeconfig --name $CLUSTER-NAME --profile test-profileAfter you run this command, kubectl uses the profile test-profile to authenticate with the cluster API server.Build an ARN version by excluding the pathThe IAM roles that are mapped in aws-auth ConfigMap don't include path. By default, the Amazon Resource Name (ARN) of the IAM role that's associated with your SSO user includes path.Example:arn:aws:iam::123456789999:role/aws-reserved/sso.amazonaws.com/us-east-2/AWSReservedSSO_ViewOnlyAccess_05a3861234567890If you add the full ARN to the aws-auth ConfigMap, your SSO user isn't authenticated. You can't access your cluster using your SSO user. Be sure to build a version of this ARN without including the path. This version must be used in the next stepExample:arn:aws:iam::123456789000:role/AWSReservedSSO_ViewOnlyAccess_05a38657af2a0a01You can also get the IAM role without the path by running the following commands:ssorole=$(aws sts get-caller-identity --query Arn --output text --profile test-profile | cut -d/ -f2)account=$(aws sts get-caller-identity --query Account --output text --profile  test-profile)echo "arn:aws:iam::$account:role/$ssorole"arn:aws:iam::123456789000:role/AWSReservedSSO_ViewOnlyAccess_05a38657af2a0a01Add the ARN to the aws-auth ConfigMapFor your SSO user to access the Amazon EKS cluster, the IAM role that's associated with your SSO user must be mapped to Kubernetes RBAC permissions. To do this, include the IAM role ARN without the path in the aws-auth ConfigMap. Then, map it to the Kubernetes user and the groups that are linked to the Kubernetes Role and RoleBinding (or ClusterRole and ClusterRoleBinding). Use instructions from either of the following sections based on your use case.SSO user with cluster-wide admin permissionsBy default, the Kubernetes group system:masters provides cluster-wide admin permissions. This group is linked to the ClusterRole cluster-admin and the ClusterRoleBinding cluster-admin. Therefore, you don't need to create new ClusterRole and ClusterBindingRole objects. You need to only map the IAM role without path to the system:masters group.To do this, edit the aws-auth ConfigMap:kubectl edit configmap aws-auth -n kube-systemThen, add the following:- groups:  - system:masters  rolearn: arn:aws:iam::123456789000:role/AWSReservedSSO_ViewOnlyAccess_05a38657af2a0a01  username: cluster-adminSSO user with namespace-bound read permissionsIn this case, you must create a Role and a RoleBinding with read permissions within a specific namespace. Then, link these objects to the IAM role using a custom user name or group name in the aws-auth ConfigMap.1.    Create a Kubernetes Role object that allows only read permissions in your desired namespace:cat << EOF | kubectl apply -f -apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  namespace: $MY-NAMESPACE  name: reader-rolerules:- apiGroups: [""] # "" indicates the core API group  resources: ["*"]  verbs: ["get", "watch", "list"]EOFNote:Replace $MY-NAMESPACE with the name of your namespace.Replace reader-role with your custom user name.2.    Create a Kubernetes RoleBinding object that links Kubernetes role permissions to the group read-only-group:cat <<EOF | kubectl apply -f -apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: reader-binding  namespace: MY-NAMESPACEsubjects:- kind: Group  name: read-only-group  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: reader-role  apiGroup: rbac.authorization.k8s.ioEOF3.    Map the IAM role ARN without path to the group read-only-group in aws-auth ConfigMap.You can map the IAM role automatically by running the following command:eksctl create iamidentitymapping \    --cluster $CLUSTER-NAME \    --region $REGION \    --arn arn:aws:iam::123456789000:role/AWSReservedSSO_ViewOnlyAccess_05a38657af2a0a01 \    --group read-only-group \    --no-duplicate-arns \    --username read-only-user1Note: Replace$CLUSTER-NAME and$REGION with the name of your cluster and Region, respectively.Or, you can map the IAM role manually. To do this, edit the aws-auth ConfigMap:kubectl edit configmap aws-auth -n kube-systemThen, add the following under the mapRoles section:- groups:  - read-only-group  rolearn: arn:aws:iam::123456789000:role/AWSReservedSSO_ViewOnlyAccess_05a38657af2a0a01  username: read-only-user1Important: The IAM role must appear only once in the aws-auth ConfigMap. Therefore, be sure that only one section includes the IAM role.You can now use your SSO user to access your cluster:$ kubectl get podNAME    READY   STATUS    RESTARTS   AGEweb-0   1/1     Running   0          24hRelated informationTurning on IAM user and role access to your clusterFollow"


Question: How do I troubleshoot “Persistent store is Full” errors in Amazon MQ for ActiveMQ?

"I can't send messages to my Amazon MQ for ActiveMQ broker. When I review the broker's logs in Amazon CloudWatch, I see a "Persistent store is Full" error. What's causing the error, and how do I troubleshoot the issue?"

Answer: "I can't send messages to my Amazon MQ for ActiveMQ broker. When I review the broker's logs in Amazon CloudWatch, I see a "Persistent store is Full" error. What's causing the error, and how do I troubleshoot the issue?Short descriptionAmazon MQ for ActiveMQ returns a Persistent store is Full error to CloudWatch when a broker reaches its storage limit. When an Amazon MQ for ActiveMQ broker reaches its storage limit, the broker can't receive messages.To resolve Persistent store is Full errors, first confirm the cause of the error by reviewing the following CloudWatch metrics for your broker:Store Percentage UsageJournal Files for Full RecoveryJournal Files for Fast RecoveryThen, based on your broker's metrics, reduce the amount of data that's saved to the broker's persistent storage as required.To help prevent the error from occurring again, see the Best practices for preventing "Persistent store is Full" errors section of this article. For more information, see AMQ Message Store and Producer Flow Control in the Apache ActiveMQ documentation.Example CloudWatch "Persistent store is Full" error message for an Amazon MQ for ActiveMQ brokerINFO | Usage(default:store:queue://broker.name:store) percentUsage=99%, usage=537210471, limit=536870912, percentUsageMinDelta=1%;Parent:Usage(default:store) percentUsage=100%, usage=537210471, limit=536870912,percentUsageMinDelta=1%: Persistent store is Full, 100% of 536870912. Stopping producer (ID:xxxx) to prevent flooding queue://broker.name. See http://activemq.apache.org/producer-flow-control.html for more info (blocking for: 155s)ResolutionConfirm the cause of the error1.    Open the CloudWatch console.Important: Make sure that you log in to the same AWS Region that your broker is in.2.    In the left navigation pane, choose Metrics. Then, choose All metrics. The CloudWatch Metrics page opens.3.    On the Metrics page, choose Amazon MQ. Then, choose Broker Metrics.4.    In the search box, enter your broker's name. Then, press Enter on your keyboard. All of the CloudWatch metrics for the broker that you entered in the search box appear.5.    Review the Store Percentage Usage metric value. If your broker's Store Percentage Usage metric reaches 100, the broker stops receiving messages and returns a Persistent store is Full error.6.    If your broker's Store Percentage Usage metric is 100 (or close to 100), review the following metrics' values to determine the cause:**Journal Files for Full Recovery—**indicates the number of journal files that are replayed after a clean shutdown. An increase in this metric indicates that either your broker's consumers are running slow, or that there are too many pending messages in persistent storage.**Journal Files for Fast Recovery—**indicates the number of journal files that are replayed after an unclean shutdown. An increase in this metric indicates that there are too many pending messages in persistent storage.Note: An ActiveMQ KahaDB journal log file (data file) can remain in persistent storage for any of the following reasons:The data file includes a pending message for a durable topic subscription or destination.The data file includes an individual Acknowledgement (ACK) for a message that's in an in-use data file.The data file references a pending transaction.The data file is a journal file, and there's a pending write action to it.For more information, see Why do KahaDB log files remain after cleanup in the ActiveMQ documentation.To reduce the amount of data that's saved to an Amazon MQ for ActiveMQ broker's persistent storageConsume or delete the pending messages that are in the broker's queues and durable topicsFor instructions, see How do I purge a queue in the Apache ActiveMQ documentation.Note: Amazon MQ for ActiveMQ doesn't support Java Management Extensions (JMX) currently. You must use the ActiveMQ Web Console to purge your broker's queues and durable topics.Consume or delete expired messages that are in the broker's dead-letter queue (DLQ)For instructions, see the Automatically discard expired messages section of Message redelivery and DLQ handling in the Apache ActiveMQ documentation.Note: To consume messages in your broker's DLQ, first configure the DLQ as a regular queue. Then, configure your consumers to poll the DLQ directly.Best practices for preventing "Persistent store is Full" errorsVerify that you've chosen the correct broker instance type for your use caseFor more information, see Choose the correct broker instance type for the best throughput in the Amazon MQ Developer Guide.Note: Depending on your use case, adding consumers to your broker can sometimes help the broker's message throughput.Increase the number and speed of consumers that you're usingWhen you use ActiveMQ in persistent mode, writing to storage usually occurs when there are either too few consumers or when the consumers are slow. Increasing the number and speed of consumers that you're using can help reduce the amount of data your broker writes to persistent storage.Set a CloudWatch alarm based on your broker's "Store Percentage Usage" metricIf your broker's Store Percentage Usage metric reaches 100 (or close to 100), the broker stops receiving messages. To have CloudWatch alert you when this metric reaches a specific threshold, you can set an alarm in CloudWatch. Then, you can take the preventative actions described in this article before the error occurs.For instructions, see Create a CloudWatch alarm based on a static threshold in the CloudWatch User Guide.Related informationEnsuring effective Amazon MQ performanceLogging and monitoring Amazon MQ for ActiveMQ brokersFollow"


Question: Why can't my AWS Load Balancer Controller find my subnet in Amazon EKS?

My AWS Load Balancer Controller can't find my subnet in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "My AWS Load Balancer Controller can't find my subnet in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionIf your AWS Load Balancer Controller can't find your subnet in Amazon EKS, then you receive an error. To troubleshoot your error, complete the relevant steps for the error message that you receive.The following error occurs when your account's AWS Identity and Access Management (IAM) role for the AWS Load Balancer Controller doesn't have the required permissions:{"level":"error","ts":1621443417.9175518,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":" ingress-2048","namespace":" game-2048","error":"couldn't auto-discover subnets: UnauthorizedOperation: You are not authorized to perform this operation.\n\tstatus code: 403, request id: 72ee57ae-f804-4f81-b069-8b04114b67b0"}To resolve the preceding error, complete the steps in the Resolve the permission denied error section.-or-The following error occurs when your AWS Load Balancer Controller can't discover at least one subnet:{"level":"error","ts":1608229710.3212903,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":"ingress-2048","namespace":"game-2048","error":"couldn't auto-discover subnets: unable to discover at least one subnet"}To resolve the preceding error, complete the steps in the Resolve the single subnet discovery error section.-or-The following errors occur when your AWS Load Balancer Controller can't discover two or more qualified subnets:"msg"="Reconciler error" "error"="failed to build LoadBalancer configuration due to failed to resolve 2 qualified subnet with at least 8 free IP Addresses for ALB{"level":"error","ts":1606329481.2930484,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":"reciter-ing","namespace":"reciter","error":"InvalidSubnet: Not enough IP space available in subnet-xxxxxxxxxxxxxx. ELB requires at least 8 free IP addresses in each subnet.\n\tstatus code: 400, request id: 2a37780c-f411-xxxxx-xxxxx-xxxxxxxxx"}To resolve the preceding errors, complete the steps in the Resolve multiple subnet discovery errors section.ResolutionResolve the permission denied error1.    Enter the following command to verify that your service account is associated with the AWS Load Balancer Controller:$ kubectl get deploy aws-load-balancer-controller -n kube-system -o yaml | grep -i serviceAccountYou receive an output similar to the following:serviceAccount: aws-load-balancer-controllerserviceAccountName: aws-load-balancer-controllerNote: If your deployment is deployed in a different namespace, then replace -n kube-system with the appropriate namespace.2.    Verify which IAM role is attached to the service account that's associated with the AWS Load Balancer Controller:$ kubectl describe sa aws-load-balancer-controller -n kube-system | grep role-arnYou receive an output similar to the following:annotations: eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxx:role/eksctl-cluster18-addon-iamserviceaccount-kub-Role1-xxxxxxxxxxxxx3.    Grant ec2:DescribeAvailabilityZones permissions to the IAM role that you identify in step 2.Resolve the single subnet discovery error1.    Add the appropriate tags on your subnets to allow the AWS Load Balancer Ingress Controller to create a load balancer using auto-discovery.The following is an example of private subnets tags:kubernetes.io/role/internal-elb                Set to 1 or empty tag value for internal load balancersThe following is an example of private subnets tags:kubernetes.io/role/elb                         Set to 1 or empty tag value for internet-facing load balancersNote: You can manually assign subnets to your load balancer using the alb.ingress.kubernetes.io/subnets annotation. For more information, see Ingress annotations on the AWS Load Balancer Controller website.The following is an example of a subnet with the correct tags for a cluster with an internal load balancer (private subnet):kubernetes.io/role/internal-elb          1The following is an example of a subnet with the correct tags for a cluster with a public load balancer (public subnet):kubernetes.io/role/elb2.    Tag your subnets with the appropriate format.Key: kubernetes.io/cluster/your-cluster-nameValue: shared or ownedImportant: If you're using the AWS Load Balancer Controller version v2.1.1 or earlier, then you must tag your subnets in the preceding format. Tagging is optional for versions 2.1.2 or later. It's a best practice to tag a subnet if any of the following is true:You have multiple clusters that are running in the same VPC.You have multiple AWS services that share subnets in a VPC.You want more control over where load balancers are provisioned for each cluster.Resolve multiple subnet discovery errors1.    Confirm that you have at least two subnets in two different Availability Zones. This is a requirement for creating an Application Load Balancer.Note: You can create a Network Load Balancer with a single subnet.2.    For each subnet, specify a CIDR block with at least a /27 bitmask (for example: 10.0.0.0/27) and at least eight free IP addresses.3.    Confirm that the tags on the subnets are formatted correctly. For example, the tags can't have any leading or trailing spaces.Follow"


Question: How do I reduce the amount of logs generated by my AWS Glue job?

My AWS Glue job is generating too many logs in Amazon CloudWatch. I want to reduce the number of logs generated.

Answer: "My AWS Glue job is generating too many logs in Amazon CloudWatch. I want to reduce the number of logs generated.ResolutionWith AWS Glue-Spark ETL jobs, you can't control the verbosity of the logs generated by the instances that the AWS Glue jobs run on. The logs are verbose so that they can be used to monitor internal failures and help in diagnosing job failures. However, you can define the Spark logging levels by following the steps presented here.Choose the standard filter setting for continuous loggingIf you turned on continuous logging for your job, choose the Standard filter for Log filtering option. This filter can help you prune the non-useful Apache Spark driver/executor and Apache Hadoop YARN heartbeat log messages. To change the log filter setting for your AWS Glue job, do the following:Open the AWS Glue console.In the navigation pane, choose Jobs.Select the job that you want to update.Choose Action, and then choose Edit job.Expand the Monitoring options section.Select Continuous logging.Under Log filtering, select Standard filter.Choose Save.To change this setting from the AWS Command Line Interface (AWS CLI), use the following command:'--enable-continuous-cloudwatch-log': 'true''--enable-continuous-log-filter': 'true'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 more information, see Enabling continuous logging for AWS Glue jobs.Important: Even with the standard filter setting, the application master logs for the Spark jobs are still pushed to /aws-glue/jobs/output and /aws-glue/jobs/error log groups.Set the logging level using Spark context method setLogLevelYou can set the logging level for your job using the setLogLevel method of pyspark.context.SparkContext. Valid logging levels include ALL, DEBUG, ERROR, FATAL, INFO, OFF, TRACE, and WARN. For more information, see Spark documentation for setLogLevel.Use the following code to import the Spark context method and set the logging level for your job:from pyspark.context import SparkContextsc = SparkContext()sc.setLogLevel("new-log-level")Note: Be sure to replace new-log-level with the logging level that you want to set for your job.For more information, see Spark documentation for Configuring logging.Use a custom log4j.properties file to define the logging levelSpark uses log4j configurations for logging. You can include the logging preferences in a log4j.properties file, upload the file to Amazon Simple Storage Service (Amazon S3), and use the file in the AWS Glue job.To reference the Amazon S3 file in the job, do the following:Open the AWS Glue console.In the navigation pane, choose Jobs.Select the job where you want to reference the file.Choose Actions, and then choose Edit job.Expand the Security configuration, script libraries, and job parameters (optional) section.For Referenced files path, paste the full S3 path where you stored the log4j.properties file.For more information, see Providing your own custom scripts.Related informationMonitoring with Amazon CloudWatchFollow"


Question: How do I configure my local printer in my Windows WorkSpace?

Setting up a local printer can be challenging in Amazon WorkSpaces. How can I set up or confirm settings for a local printer in a WorkSpace?

Answer: "Setting up a local printer can be challenging in Amazon WorkSpaces. How can I set up or confirm settings for a local printer in a WorkSpace?ResolutionAmazon WorkSpaces printing capabilities depend on the operating system that the WorkSpace client runs on:Windows and macOS clients support local printers and cloud printing services.Other clients support network printing and cloud printing services.Depending on your WorkSpaces protocol or your local printer, you might have only basic printing options available. In your WorkSpace, open Print Management to see the available options. To use device-specific features, you might need to download and install a model-specific printer driver to your WorkSpace.To install a Windows printer driver in your WorkSpace:Download the correct local printer driver. It's a best practice to download printer drivers from the printer manufacturer's official website. You might have to unzip the downloaded file to access the driver file (.inf).Open Printers & scanners.Choose the Add a printer or scanner option and choose The printer I want isn't listed.In the Add Printer dialog box, choose Add a local printer or network printer with manual settings and choose Next.For Use an existing port, select LPT1: (Printer Port). This makes the driver available in dropdown list for later selection.For Install the printer driver, select a manufacturer and a printer, and then choose Have Disk.Choose Browse to navigate to the location of the driver file (.inf). When you find the file, choose Open and OK. Then, select the correct driver and choose Next.Don't share the printer and don't print a test page.To select a local printer driver in your WorkSpace:In Print Management, choose All Printers. Right-click the redirected local printer and choose Properties.Note: Local printers use the following naming conventions:PCoIP: <local-printer-name> (Local - <username>.<computername>)WorkSpaces Streaming Protocol (WSP): <local-printer-name> - Redirected (<-computername>)In the printer's Properties dialog box, choose the Advanced tab. For Driver, select the installed driver to assign the new driver to your redirected printer. Choose OK.After you finish changing the printer, review the printer's Properties to confirm the new option. You might need to restart the WorkSpace to see the changes.Note: When you print to a local printer, you can monitor the print job in your local printer queue.Instead of using a local printer, you can use the Microsoft Print to PDF option for your local Windows or macOS system.Related informationPrint from a WorkSpaceConfigure printer support for PCoIPConfigure printer support for WSPWhen I print from a Windows WorkSpace to a local printer, why do I experience document formatting or printer feature issues?How can I set the default printer on Amazon Windows WorkSpaces and prevent the settings from reverting?Follow"


Question: How do I resolve the "Your current user or role does not have access to Kubernetes objects on this EKS cluster" error in Amazon EKS?

I receive the following error in Amazon Elastic Kubernetes Service (Amazon EKS): "Your current user or role does not have access to Kubernetes objects on this EKS cluster."

Answer: "I receive the following error in Amazon Elastic Kubernetes Service (Amazon EKS): "Your current user or role does not have access to Kubernetes objects on this EKS cluster."Short descriptionYou might receive this error when you use the AWS Management Console with an AWS Identity and Access Management (IAM) user or role. The error indicates that the IAM user or role lacks the required RBAC (from the Kubernetes website) permissions to access Kubernetes API. To view Kubernetes resources on the AWS Management Console, your AWS IAM user or role must map to aws-auth ConfigMap in your Amazon EKS cluster.When you create an Amazon EKS cluster, your IAM user or role is automatically granted system:masters permissions in the cluster's RBAC configuration. This lets you view Kubernetes resources through the Amazon EKS console. It also lets you edit the aws-auth  ConfigMap within Kubernetes, and grant additional AWS users or roles the ability to interact with the cluster.Two different authorization systems are in use. The AWS Management Console uses IAM. The EKS cluster uses the  Kubernetes RBAC system (from the Kubernetes website). The cluster’s aws-auth ConfigMap associates IAM identities (users or roles) with cluster RBAC identities. This means that the aws-auth ConfigMap associates IAM identities with Kubernetes identities.ResolutionPrerequisitesBefore you begin, collect the following information.Non-admin user or roleIf you aren't a cluster admin IAM user or role and require visibility on the Amazon EKS console, then complete the following steps:1.    Get the IAM Identity Amazon Resource Name (ARN) of the AWS Management Console user.If it's an IAM role, then use the following ARN format:arn:aws:iam::111122223333:role/exampleImportant: Don't use the following format:arn:aws:iam::111122223333:role/my-team/developers/example2.    Provide the ARN to your cluster admin, and request that the admin add you to the aws-auth ConfigMap.Note: See the Identify the IAM identity ARN of the AWS Management Console user section for steps on how to access your ARN.Cluster creator or cluster admin user or roleIf you're the cluster creator or cluster admin, then use the kubectl tool or the eksctl tool to manage the aws-auth ConfigMap.Note: By default, the system:masters group is bound to the clusterrole that's named cluster-admin. This clusterrole uses the wildcard(“*”) for Resources and Verbs in its PolicyRule. This means that any user that's assigned to the system:masters  group has full access to all the Kubernetes resources within the cluster.See the Identify the cluster creator section for detailed steps on how cluster creators and cluster admins can identify their admin status.Identify the IAM Identity ARN of the AWS Management Console userIdentify the IAM user or role that you're using to access the console. This might be different from the identity that you use with AWS Command Line Interface (AWS CLI). Confirm that the identified IAM user or role has permissions to view nodes and workloads for all clusters in the AWS Management Console. Then, get the IAM identity's ARN. Use one of the following options to access the ARN.Use the AWS CLIIf you have AWS CLI access to the IAM user or role, then run the following command:aws sts get-caller-identity --query ArnLaunch CloudShellIf you don't have AWS CLI access, then run the following command:aws sts get-caller-identity --query ArnThe output is similar to the following:"arn:aws:iam::111122223333:role/testrole"-or-"arn:aws:iam::111122223333:user/testuser"Note:If it's an IAM role ARN, then make sure that the format is similar to the ARN format that you get from the Prerequisites section.If the ARN includes assumed-role, then you must get the ARN of the role. For example, the assumed role ARN of arn:aws:sts::123456:assumed-role/MyRole/aadams is associated with the role ARN arn:aws:sts::123456:role/MyRole. You can verify this value in the IAM console.Identify the cluster creatorTo find the cluster creator or admin role with primary permissions to configure your cluster, search for the CreateCluster API call in AWS CloudTrail. Then, check the userIdentity section of the API call.Tip: If you find the cluster creator name in CloudTrail but it's deleted, then recreate a new IAM user or role with the same name. Because this new IAM entity has the same ARN as the original cluster creator, it inherits the same admin access to the cluster.Note: CloudTrail provides only 90 days of history.Add new IAM user or role to the Kubernetes RBAC, using kubectl or eksctlBefore you choose the kubectl or eksctl tool to edit the aws-auth ConfigMap, make sure that you complete step 1. Then, follow steps 2-4 to edit with kubectl. To edit with eksctl, proceed to step 5.1.    After you identify the cluster creator or admin, configure AWS CLI to use the cluster creator IAM. See Configuration basics for more information.To verify that AWS CLI is correctly configured with the IAM entity, run the following command:$ aws sts get-caller-identityThe output returns the ARN of the IAM user or role. For example:{    "UserId": "XXXXXXXXXXXXXXXXXXXXX",    "Account": "XXXXXXXXXXXX",    "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"}Note: If you receive errors when running the CLI commands, make sure that you're using the most recent version of AWS CLI.2.     To modify the aws-auth ConfigMap with kubectl, you must have access to the cluster. Run the following kubectl command:$ kubectl edit configmap aws-auth -n kube-systemThe console shows the current configMap.If you can't connect to the cluster, then try updating your kubeconfig file. Run the file with an IAM identity that has access to the cluster. The identity that created the cluster always has cluster access.aws eks update-kubeconfig --region region_code --name my_clusterNote: Replace region_code with your EKS cluster AWS Region code and my_cluster with your EKS cluster name.The kubectl commands must connect to the EKS server endpoint. If the API server endpoint is public, then you must have internet access to connect to the endpoint. If the API server endpoint is private, then you must connect to the EKS server endpoint from within the VPC where the EKS cluster is running.3.    To edit the aws-auth ConfigMap in the text editor as the cluster creator or admin, run the following command:$ kubectl edit configmap aws-auth -n kube-system4.   Add an IAM user or role:mapUsers: |  - userarn: arn:aws:iam::XXXXXXXXXXXX:user/testuser    username: testuser    groups:    - system:bootstrappers    - system:nodes-or-Add the IAM role to mapRoles. For example:mapRoles: |  - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole    username: testrole        groups:    - system:bootstrappers    - system:nodesConsider the following information:system:masters  allows a superuser access to perform any action on any resource. This isn't a best practice for production environments.It’s a best practice to minimize granted permissions. Consider creating a role with access to only a specific namespace. See Using RBAC Authorization on the Kubernetes website for information. Also, see Required permissions, and review the View Kubernetes resources in a specific namespace section for an example on the Amazon EKS console’s restricted access.5.    The eksctl tool lets you update the aws-auth ConfigMap with the following command:eksctl create iamidentitymapping --cluster your_cluster_Name --region=your_region --arn YOUR_IAM_ARN <arn:aws:iam::123456:role testing=""> --group system:masters --username admin</arn:aws:iam::123456:role>Note: Replace your_cluster_Name with your EKS cluster name, your_region with your EKS cluster Region, and YOUR_IAM_ARN with your IAM role or use ARN.Verify access to your Amazon EKS cluster1.    Open the Amazon EKS console.2.    In the Amazon EKS section the navigation pane, choose Clusters.3.    Choose your cluster.4.    Check the Overview and Workloads tabs for errors.If you configured for a specific namespace, then you see the following error message in the Amazon EKS console:Error loading Deploymentsdeployments.apps is forbidden: User "xxxxxx" cannot list resource "deployments" in API group "apps" at the cluster scope or in the namespace "xxxxxxx"The error doesn't appear for the specific namespace.To troubleshoot error messages, see Can't see Nodes on the Compute tab or anything on the Resources tab and you receive an error in the AWS Management Console.Follow"


Question: How can I track third-party software or applications on my EC2 instances or WorkSpaces using License Manager?

"I want to track resources that are used by my Amazon Elastic Compute Cloud (Amazon EC2) instance, Amazon WorkSpaces, and so on, using Amazon License Manager."

Answer: "I want to track resources that are used by my Amazon Elastic Compute Cloud (Amazon EC2) instance, Amazon WorkSpaces, and so on, using Amazon License Manager.ResolutionNote: License Manager automatically tracks individual products based on platform or application. The example in the following resolution tracks vCPUs that are consumed by Microsoft SQL Server 2019 (64-bit) in the AWS Region us-east-1. You can use the example steps to track any application or platform that's discovered by AWS Systems Manager.PrerequisitesInstall or update the SSM Agent on all of the instances that you want to track. Make sure that all of the instances that you want to track are managed in Systems Manager Inventory. For information on how to update the SSM Agent using State Manager, see Walkthrough: Automatically update SSM Agent (CLI).To track on-premises servers, make sure that they're managed instances. A managed instance is any Amazon EC2 instance, server, or virtual machine (VM) in your on-premises environment that's configured for Systems Manager.Verify that Systems Manager is discovering your resources in License ManagerAfter installing the SSM Agent, open the License Manager console. and then choose Inventory search. Verify that all resources that you want to track are listed.Create a license configurationIn the License Manager console, choose Self-managed licenses.Choose Create self-managed license.Complete the following fields:For Self-managed license name, enter the name of the license (Microsoft SQL Server 2019, in this example).For License type, enter the type of license (vCPUs, in this example).Choose Submit.Create and assign the automated discovery ruleIn the License Manager console, select Inventory search.Search by resource ID, platform name, application name, license included, or tags. In this example, search for all instances that run the application "Microsoft SQL Server 2019 (64-bit)".In the search bar field choose Application Name, Equals.Enter "Microsoft SQL Server 2019 (64-bit)" as the application name. This lists all instances that contain the application "Microsoft SQL Server 2019 (64-bit)".Select all the EC2 resources that you want to apply the auto discovery rule to, then choose Add automated discovery rules.In the Self-managed license section, select Microsoft SQL Server 2019.In the Automated discovery rules section, choose Application for Software type.For Product name, choose Microsoft SQL Server 2019 (64-bit).Select Add.Track the licenses in the License Manager dashboardOn the License Manager console dashboard, select the license name Microsoft SQL Server 2019. All the resources that use the Microsoft SQL Server 2019 (64-bit) application are listed, as well as the vCPUs in use.Follow"


Question: How do I use the DBMS_QOPATCH on an Amazon RDS instance that's running Oracle 19c?

I have an Amazon Relational Database Service (Amazon RDS) instance that's running Oracle 19c. How can I use the queryable patch inventory (DBMS_QOPATCH) feature on Amazon RDS for Oracle?

Answer: "I have an Amazon Relational Database Service (Amazon RDS) instance that's running Oracle 19c. How can I use the queryable patch inventory (DBMS_QOPATCH) feature on Amazon RDS for Oracle?Short descriptionOracle 19c includes a queryable patch inventory feature. The feature allows users to retrieve Oracle software inventory information from within the database by using the DBMS_QOPATCH package. For more information, see the Oracle documentation for DBMS_QOPATCH.In previous versions of Oracle, users can retrieve software inventory information only by using the Oracle OPatch utility. Because Amazon RDS restricts access to the underlying operating system (OS), previous versions can't run the OPatch utility. In Oracle 19c with Amazon RDS, any users with privileges to run the DBMS_QOPATCH package can retrieve Oracle software inventory information.Note: Amazon RDS now includes a feature that allows you to access OPatch files from the log file. This feature is turned on for Oracle instances released in 2020 or later. If your Oracle instances were released in 2020 or later, then it's a best practice to use this feature. For more information, see Accessing OPatch files.ResolutionThe queryable patch inventory uses existing features like XML support and external tables. These examples show how the queryable patch inventory works.In this example, the OPATCH query is run on three new directory objects:SQL> select owner,directory_name,directory_path from dba_directories where directory_name like 'OPATCH%'This is an example output from the query:OWNER      DIRECTORY_NAME       DIRECTORY_PATH---------- -------------------- --------------------------------------------------SYS        OPATCH_SCRIPT_DIR    /rdsdbbin/oracle/QOpatchSYS        OPATCH_LOG_DIR       /rdsdbbin/oracle/QOpatchSYS        OPATCH_INST_DIR      /rdsdbbin/oracle/OPatchIn this example, the OPATCH query is run on four new system tables:SQL> select owner,table_name from dba_tables where table_name like 'OPATCH%';This is an example output from the query:OWNER           TABLE_NAME--------------- ------------------------------SYS             OPATCH_XML_INVSYS             OPATCH_XINV_TABSYS             OPATCH_INST_PATCHSYS             OPATCH_SQL_PATCHESSYS             OPATCH_INST_JOBThe main table is OPATCH_XML_INV, which is a full extract of the inventory in XML format. The table is implemented as an external table that reads from the inventory:SQL> select dbms_metadata.get_ddl('TABLE','OPATCH_XML_INV','SYS') from dual;This is an example output from the query:DBMS_METADATA.GET_DDL('TABLE','OPATCH_XML_INV','SYS')--------------------------------------------------------------------------------  CREATE TABLE "SYS"."OPATCH_XML_INV"   (    "XML_INVENTORY" CLOB   )   ORGANIZATION EXTERNAL    ( TYPE ORACLE_LOADER      DEFAULT DIRECTORY "OPATCH_SCRIPT_DIR"      ACCESS PARAMETERS      ( RECORDS DELIMITED BY NEWLINE CHARACTERSET UTF8      DISABLE_DIRECTORY_LINK_CHECK      READSIZE 8388608      preprocessor opatch_script_dir:'qopiprep.bat'      BADFILE opatch_script_dir:'qopatch_bad.bad'      LOGFILE opatch_log_dir:'qopatch_log.log'      FIELDS TERMINATED BY 'UIJSVTBOEIZBEFFQBL'      MISSING FIELD VALUES ARE NULL      REJECT ROWS WITH ALL NULL FIELDS      (    xml_inventory     CHAR(100000000)      )    )      LOCATION       ( "OPATCH_SCRIPT_DIR":'qopiprep.bat'       )    )   REJECT LIMIT UNLIMITEDThe implementation is done by the PREPROCESSOR script, qopiprep.bat. This script is located on the directory that is pointed to by OPATCH_SCRIPT_DIR. For more information, see the Oracle documentation for PREPROCESSOR. See the following example query that uses the OPATCH_SCRIPT_DIR:SQL> select owner,directory_name,directory_path from dba_directories where directory_name='OPATCH_SCRIPT_DIR';This is an example output from the query:OWNER           DIRECTORY_NAME                     DIRECTORY_PATH--------------- ---------------------------------  ----------------------------------------SYS             OPATCH_SCRIPT_DIR                  /rdsdbbin/oracle/QOpatchThe qopiprep.bat script runs the queryable patch inventory. It then generates the output in XML so that the output can be used as the input to the external table, OPATCH_XML_INV. Then, the package and functions provided by DBMS_QOPATCH can be used to extract Oracle inventory information from the table. To see the functions and procedures provided by the DBMS_QOPATCH package, see the Oracle documentation for the Summary of DBMS_QOPATCH subprograms.Run the following query to list all patches installed:with a as (select dbms_qopatch.get_opatch_lsinventory patch_output from dual) select x.patch_id, x.patch_uid, x.description from a, xmltable('InventoryInstance/patches/*' passing a.patch_output columns patch_id number path 'patchID', patch_uid number path 'uniquePatchID', description varchar2(80) path 'patchDescription') x;This is an example output from the query:PATCH_ID     PATCH_UID  DESCRIPTION----------   ---------- ---------------------------------------------------------------33613833     24537804   DSTV37 UPDATE - TZDATA2021E - NEED OJVM FIX33613829     24529874   RDBMS - DSTV37 UPDATE - TZDATA2021E32327201     24049836   RDBMS - DSTV36 UPDATE - TZDATA2020E31335037     23600477   RDBMS - DSTV35 UPDATE - TZDATA2020A29997937     23062124   RDBMS - DSTV34 UPDATE - TZDATA2019B28852325     23061696   RDBMS - DSTV33 UPDATE - TZDATA2018G29213893     24595383   DBMS_STATS FAILING WITH ERROR ORA-01422 WHEN GATHERING STATS FOR USER$ TABLE28730253     23062304   SUPPORT NEW ERA REIWA FOR JAPANESE IMPERIAL CALENDAR33561310     24538862   OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310)33515361     24589353   Database Release Update : 19.14.0.0.220118 (33515361)29585399     22840393   OCW RELEASE UPDATE 19.3.0.0.0 (29585399)To get a more detailed output in a format similar to opatch lsinventory -detail, run the following:set long 200000 pages 0 lines 200select xmltransform(DBMS_QOPATCH.GET_OPATCH_LSINVENTORY, DBMS_QOPATCH.GET_OPATCH_XSLT) from dual;This is an example output from the query:Oracle Querayable Patch Interface 1.0--------------------------------------------------------------------------------Oracle Home : /rdsdbbin/oracleInventory : /rdsdbbin/oraInventory--------------------------------------------------------------------------------Installed Top-level Products (1):19.0.0.0.0Installed Products ( 128)Oracle Database 19c 19.0.0.0.0Java Development Kit 1.8.0.201.0oracle.swd.oui.core.min 12.2.0.7.0Installer SDK Component 12.2.0.7.0Oracle One-Off Patch Installer 12.2.0.1.15Oracle Universal Installer 12.2.0.7.0oracle.swd.commonlogging 13.3.0.0.0Trace File Analyzer for DB 19.0.0.0.0Oracle USM Deconfiguration 19.0.0.0.0Oracle DBCA Deconfiguration 19.0.0.0.0......Oracle Advanced Security 19.0.0.0.0Oracle Internet Directory Client 19.0.0.0.0Oracle Net Listener 19.0.0.0.0HAS Files for DB 19.0.0.0.0Oracle Database Provider for DRDA 19.0.0.0.0Oracle Text 19.0.0.0.0Oracle Net Services 19.0.0.0.0Oracle Database 19c 19.0.0.0.0Oracle OLAP 19.0.0.0.0Oracle Spatial and Graph 19.0.0.0.0Oracle Partitioning 19.0.0.0.0Enterprise Edition Options 19.0.0.0.0Interim patches:Patch 33613833: applied on 2022-02-07T08:53:35ZUnique Patch ID: 24537804Patch Description: DSTV37 UPDATE - TZDATA2021E - NEED OJVM FIXCreated on : 9 Dec 2021, 01:32:48 hrs PST8PDTBugs fixed:33613833 Files Touched:tzdb.datfixTZa.sqlfixTZb.sql......The DBMS_QOPATCH package also provides the following procedures and functions. Run the following to verify if a specific patch is installed:select xmltransform(dbms_qopatch.is_patch_installed('<patch number>'), dbms_qopatch.get_opatch_xslt) from dual;Run the following to get a list of bugs fixed by the installed patches:select xmltransform(dbms_qopatch.get_opatch_bugs, dbms_qopatch.get_opatch_xslt) from dual;Run the following to list the bugs fixed by a specific patch number:select xmltransform(dbms_qopatch.get_opatch_bugs(<patch number>), dbms_qopatch.get_opatch_xslt) from dual;Related informationAdministering your Oracle DB instanceFollow"


Question: Which CloudHSM certificates are used for the client-server end-to-end encrypted connection?

"How does the AWS CloudHSM client end-to-end encryption work, and which HSM certificates are used?"

Answer: "How does the AWS CloudHSM client end-to-end encryption work, and which HSM certificates are used?Short descriptionThe end-to-end encrypted connection between the CloudHSM client and HSMs within a CloudHSM Cluster is established through two nested TLS connections. For more information, see CloudHSM client end-to-end encryption.ResolutionFollow these instructions to set the end-to-end encrypted communication with an HSM.Note: Be sure to use the specified certificates to avoid a TLS connection failure.Server TLS ConnectionEstablish a TLS connection from the client to the server that hosts the HSM hardware. This is a two-way TLS connection between the server and client.The server sends a self-signed certificate. You can view this self-signed certificate details by running a command similar to the following:serial=B7FA7A40976CBE82issuer= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=AWS Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.comsubject= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=AWS Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.com$ openssl s_client -connect <HSM_IP>:2223 2> /dev/null | openssl x509 -subject -issuer -serial -nooutThe HSM client verifies that this certificate is included in the CA trust path in the /opt/cloudhsm/etc/cert directory. Two certificates are included in the cloudhsm-client package similar to the following:$ cd /opt/cloudhsm/etc/certs$ ls21a10654.0  712ff948.0$ openssl x509 -subject -issuer -serial -noout -in 21a10654.0subject= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=AWS Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.comissuer= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=AWS Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.comserial=B7FA7A40976CBE82$ openssl x509 -subject -issuer -serial -noout -in 712ff948.0subject= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.comissuer= /C=US/ST=Virginia/L=Herndon/O=AWS/OU=Cryptography/CN=CloudHSM/emailAddress=cloudhsm-team@amazon.comserial=A7525B285D1C2BB5The HSM client sends the client certificate to the /opt/cloudhsm/etc/client.crt directory. The client certificate must be either the default certificate included in the CloudHSM client CA certificate on the CloudHSM client in the /opt/cloudhsm/etc/customerCA.crt directory.The server verifies that this is either the default certificate or a certificate issued by customerCA.crt.HSM TLS ConnectionEstablish a second TLS connection from the client to the HSM from within the first TLS connection layer. The server sends the CloudHSM cluster certificate issued during the cluster initialization. Download the certificate with the following command:aws cloudhsmv2 describe-clusters --query "Clusters[?ClusterId=='<Cluster_ID>'].Certificates.ClusterCertificate" --output textThe client verifies that this is a certificate issued by the customerCA.crt in the /opt/cloudhsm/etc/customerCA.crt directory. Then, the client verifies connection to the HSM in the Cluster.Note: The server certificate and the CloudHSM cluster certificate can't be changed or renewed.Related informationAWS CloudHSM client and software informationFollow"


Question: How do I change the burst credit behavior at an account level for my burstable performance EC2 instances?

I want to change the default burst credit behavior for each of my Amazon Elastic Compute Cloud (Amazon EC2) burstable performance instance families. How can I do this?

Answer: "I want to change the default burst credit behavior for each of my Amazon Elastic Compute Cloud (Amazon EC2) burstable performance instance families. How can I do this?ResolutionFor steps on how to change default burst credit behavior using the Amazon EC2 console and the AWS Command Line Interface, see Set the default credit specification for the account.Changing the default credit specification doesn't affect the credit specification for existing running or stopped instances.Note: You can modify the default credit specification for an instance family once in a rolling 5-minute period. You can make modifications up to four times in a rolling 24-hour period.Related informationWork with burstable performance instancesFollow"


Question: How can I pass secrets or sensitive information securely to containers in an Amazon ECS task?

I want to pass secrets or sensitive information securely to containers in a task for Amazon Elastic Container Service (Amazon ECS).

Answer: "I want to pass secrets or sensitive information securely to containers in a task for Amazon Elastic Container Service (Amazon ECS).Short descriptionPassing sensitive data in plaintext can cause security issues, as it's discoverable in the AWS Management Console or through AWS APIs such as DescribeTaskDefinition or DescribeTasks.As a security best practice, pass sensitive information to containers as environment variables. You can securely inject data into containers by referencing values stored in AWS Systems Manager Parameter Store or AWS Secrets Manager in the container definition of an Amazon ECS task definition. Then, you can expose your sensitive information as environment variables or in the log configuration of a container.AWS supports data injection only for the following:Tasks that use AWS Fargate platform version 1.3.0 or greater with the AWS Fargate launch typeContainer instances that use the amazon-ecs-agent version 1.22.0 or greater with the Amazon Elastic Compute Cloud (Amazon EC2) launch typeResolutionComplete prerequisites1.    Store your sensitive information in either AWS Systems Manager Parameter Store or Secrets Manager.For AWS Systems Manager Parameter Store, run the following command. Replace awsExampleParameter with your own parameters, and replace awsExampleValue with your secure value:aws ssm put-parameter --type SecureString --name awsExampleParameter --value awsExampleValueFor Secrets Manager, run the following command. Replace awsExampleParameter with your own parameters, and replace awsExampleValue with your secret value:aws secretsmanager create-secret --name awsExampleParameter --secret-string awsExampleValueNote: The Amazon ECS container agent uses a task execution AWS Identity and Access Management (IAM) role to fetch the information from the AWS Systems Manager Parameter Store or Secrets Manager. The task execution IAM role must grant permissions to the following actions: ssm:GetParameters, secretsmanager:GetSecretValue, and kms:Decrypt.2.    Open the IAM console, and then create a role with a trust relation for ecs-tasks.amazonaws.com. For example:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Principal": {        "Service": "ecs-tasks.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}3.    To create an inline policy for your role in the IAM console, choose Roles, select the role that you created in step 2, and then choose Add inline policy on the Permissions tab. Choose the JSON tab, and then create a policy with the following code. Replace us-east-1 and awsExampleAccountID with the AWS Region and account where your parameters are stored. Replace awsExampleParameter with the name of the parameters that you created in step 1:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "ssm:GetParameters",        "secretsmanager:GetSecretValue"      ],      "Resource": [        "arn:aws:ssm:us-east-1:awsExampleAccountID:parameter/awsExampleParameter",        "arn:aws:secretsmanager:us-east-1:awsExampleAccountID:secret:awsExampleParameter*"      ]    }  ]}Note: If you use a customer managed KMS key for encrypting data in AWS Systems Manager Parameter Store or Secrets Manager, then you must get permissions for kms:Decrypt.4.    (Optional) Attach the managed policy AmazonECSTaskExecutionRolePolicy to the role that you created in step 2.Important: A managed policy is required for tasks that use images stored in Amazon Elastic Container Registry (Amazon ECR) or send logs to Amazon CloudWatch.Reference sensitive information in the ECS task definitionFrom the AWS Management Console:1.    Open the Amazon ECS console.2.    From the navigation pane, choose Task Definitions, and then choose Create new Task Definition.3.    Choose your launch type, and then choose Next step.4.    For Task execution role, choose the task execution IAM role that you created earlier.5.    In the Container Definitions section, choose Add container.6.    In the Environment variables section under ENVIRONMENT, for Key, enter a key for your environment variable.7.    On the Value dropdown list, choose ValueFrom.8.    In the text box for the key, enter the Amazon Resource Name (ARN) of your Parameter Store or Secrets Manager resource.Note: You can also specify secrets in the log driver configuration.From the AWS Command Line Interface (AWS CLI):Note: If you receive errors when running AWS CLI commands, be sure that you’re using the most recent version of the AWS CLI.1.    Reference AWS Systems Manager Parameter Store or Secrets Manager resources in the task definition as environment variables using the secrets section or as log configuration options using the secretOptions section. In the example below, replace us-east-1 and awsExampleAccountID with your AWS Region and account ID. Replace awsExampleParameter with the parameter that you created earlier. Replace awsExampleRoleName with the role that you created earlier.{  "requiresCompatibilities": [    "EC2"  ],  "networkMode": "awsvpc",  "containerDefinitions": [    {      "name": "web",      "image": "httpd",      "memory": 128,      "essential": true,      "portMappings": [        {          "containerPort": 80,          "protocol": "tcp"        }      ],      "logConfiguration": {        "logDriver": "splunk",        "options": {          "splunk-url": "https://sample.splunk.com:8080"        },        "secretOptions": [          {            "name": "splunk-token",            "valueFrom": "arn:aws:secretsmanager:us-east-1:awsExampleAccountID:secret:awsExampleParameter"          }        ]      },      "secrets": [        {          "name": "DATABASE_PASSWORD",          "valueFrom": "arn:aws:ssm:us-east-1:awsExampleAccountID:parameter/awsExampleParameter"        }      ]    }  ],  "executionRoleArn": "arn:aws:iam::awsExampleAccountID:role/awsExampleRoleName"}2.    To register the task definition, run the following command:aws ecs register-task-definition --family-name yourTaskDefinitionFamily --cli-input-json file://pathToYourJsonFileWhen a task is launched using the task definition that you create, the Amazon ECS container agent automatically resolves the secrets and injects the values as environment variables to the container.Important: Sensitive data is injected into your container when the container is initially started. If the secret or Parameter Store parameter is updated or rotated, the container doesn't receive the updated value automatically. You must launch a new task. If your task is part of a service, update the service. Then, use the Force new deployment option to force the service to launch a fresh task.To force a new deployment:1.    Open the Amazon ECS console.2.    Choose Clusters, and then select the cluster with your service.3.    Select the Force New Deployment check box, and then choose Update Service.Note: To force a new deployment from the AWS CLI, run the update-service command with the --force-new-deployment flag.Follow"


Question: How do I troubleshoot instance status check failures on my EC2 Windows instance after an Application Migration Service cutover or test launch?

"I performed an AWS Application Migration Service cutover or test launch. Now, I'm receiving status check failures on my Amazon Elastic Compute Cloud (Amazon EC2) instance running Microsoft Windows."

Answer: "I performed an AWS Application Migration Service cutover or test launch. Now, I'm receiving status check failures on my Amazon Elastic Compute Cloud (Amazon EC2) instance running Microsoft Windows.Short descriptionWhen a system or instance status check fails, EC2 instances become unreachable. After using Application Migration Service for a cutover or test launch, instance status checks might fail due to one or more of the following issues:Failure to boot the operating system (OS)Network failureExhausted CPU and memoryIssues with the conversion processThe instance type isn't compatible with the OSNote: The first boot of Windows machines might take up to 45 minutes due to Windows adjusting to the AWS virtual hardware.ResolutionVerify that the source machine is compatible with the instance type that you selected in the launch template1.    Connect to your source machine.2.    Use one of the following methods to verify your OS version:Choose Control Panel, Systems Settings, and then check the Windows Edition and System Type to verify if it's 32 bits or 64 bits.orAs an Administrator, run the systeminfo command in a command prompt window. The command output lists the OS Name and System Type.3.    Verify instance type compatibility.32-bit source machinesIf your source instance is a 32-bit machine, then use one of the following instance types:t2.nanot2.micro,t2.smallt2.mediumc3.larget1.microm1.smallm1.mediumc1.medium64-bit machinesIf your source machine is 64 bit and runs one of the following Windows editions, then migrate to a XEN instance type:Windows Server 2003Windows Server 2003 R2Windows Server 2008For a full list of XEN instance types, run the following AWS Command Line Interface (AWS CLI) command:aws ec2 describe-instance-types --filters Name=hypervisor,Values=xen --query InstanceTypes[].InstanceTypeNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.If your source machine is 64 bit and runs Windows Server 2008 R2 or later, then you can use any Windows compatible instance type.TroubleshootingTurn off or remove third-party antivirus on the source machineThird-party antivirus software might interfere with the conversion process. Turn off or remove the antivirus software, and then try the target launch again.Attach a secondary ENIA third-party firewall might block connectivity on the instance's primary network adapter, causing the target instance to fail status checks. To avoid this issue, attach a secondary elastic network interface to the target instance, and then connect to the instance.Use different instance typesXEN instances use paravirtual drivers (PVs), and Nitro instances use AWS Elastic Network Adapter (ENA) and AWS NVME drivers. For a list of which drivers each instance type uses, see  Summary of networking and storage features.Using the instructions in the previous section, determine if your source machine is compatible with both of the listed Windows instance types. If your source machine is compatible with both, then try launching the target using a XEN instance and a Nitro instance. If the target instance passes status checks as one instance type but not as the other, then resize the instance to see if it succeeds. If the issue is related to the driver, then run the AWS Systems Manager Automation runbook AWSSupport-UpgradeWindowsAWSDrivers to force driver installation.Or, troubleshoot the target launch's half status checks as any other EC2 Windows instance. For more information, see Troubleshoot instances with failed status checks.Check the instance logsIf your new instance never passes status checks, then review the instance logs to determine a cause. The logs help you troubleshoot possible causes for the instance status check failure. All the following logs might not be present in the target instance:C:\Program Files (x86)\AWS Replication Agent\migrate_script.logC:\Program Files (x86)\AWS Replication Agent\migrate_script.log.sentC:\Program Files (x86)\AWS Replication Agent\aws_nvme\awsnvme_dism.logC:\Program Files (x86)\AWS Replication Agent\ena_2012R2_2016\ena_dism.logC:\Program Files (x86)\AWS Replication Agent\PVinstall.logC:\Windows\inf\setupapi.dev.logC:\Windows\inf\setupapi.offline.logC:\Program Files (x86)\AWS Replication Agent\SSMInstall.logTo access the logs, complete the following steps:1.    Stop the target instance.Note: Some data is lost when stopping an instance. For more information, see What happens when you stop an instance.2.    Detach the Amazon Elastic Block Storage (Amazon EBS) root volume from the stopped instance.3.    Attach the EBS root volume to an instance that you can access as a secondary drive, and then make it available to use.4.    Gather the logs in the locations from the preceding list. Review the logs for possible causes of the instance status check failure.Note: When using this method, the drive letter mapping might differ from the listed log locations because you're using a secondary drive (not C:\).If the preceding troubleshooting steps don't resolve the issue, then create a case with AWS Support.Related informationTroubleshoot instances with failed status checksSysteminfo (from the Microsoft website)Follow"


Question: How do I troubleshoot slow or inconsistent speeds when downloading or uploading to Amazon S3?

I want to troubleshoot high latency or inconsistent speeds when downloading or uploading to Amazon Simple Storage Service (Amazon S3) from a specific network or machine.

Answer: "I want to troubleshoot high latency or inconsistent speeds when downloading or uploading to Amazon Simple Storage Service (Amazon S3) from a specific network or machine.ResolutionCheck the following to identify and mitigate what might be contributing to slow or inconsistent speeds when downloading or uploading to Amazon S3:The location of the client making requestsThe client internet service provider (ISP)The client networkThe client resourcesThe request rate to Amazon S3The Amazon S3 server access logs to determine the Turn-Around TimeThe location of the client making requestsUse Amazon S3 buckets that are as geographically close to your client as possible. Buckets are globally accessible, but they reside in a specific AWS Region. The geographical distance between the request and the bucket contributes to the time that it takes for a response to be received.You can test the impact of geographical distance between the client and the S3 bucket. For example, you can launch an Amazon Elastic Compute Cloud (Amazon EC2) instance in the same AWS Region as the bucket. Then, launch another instance in a different Region. Test an upload and download of the same file using both instances, and then compare the throughput between the two Regions.To decrease the distance between the client and the S3 bucket, move your data into a bucket in another Region that's closer to the client. You can configure cross-Region replication so that data in the source bucket is replicated into the destination bucket in the new Region. As another option, consider migrating the client closer to the S3 bucket.The client internet service provider (ISP)Review your network path for any issues that affect how your connection traverses the internet. These issues can include packet loss, high number of hops, or other ISP-related issues.Tools such as mtr and traceroute can help provide clues for potential packet loss. They can also provide the latency of the packets that are sent to the remote host. Additionally, these tools can help identify if there's a network hop causing higher latency.For example, the following Linux traceroute command uses TCP port 80 to test connectivity to the us-west-2 (Oregon) Regional endpoint:sudo traceroute -P TCP -p 80 s3.us-west-2.amazonaws.comOn Windows operating systems, you can use a similar tool called tracert.Note: Many network devices don't respond to ICMP. For a test that resembles requests to Amazon S3, be sure to run a TCP traceroute or mtr to the Regional endpoint of the bucket.If the internet route from the client to Amazon S3 isn't optimal, consider using Amazon S3 Transfer Acceleration, which leverages Amazon CloudFront's edge locations. Review the Amazon S3 Transfer Acceleration Speed Comparison tool to see if Transfer Acceleration can improve performance for your use case.Note: If you turn on Transfer Acceleration, additional data transfer charges might apply. Be sure to review Amazon S3 pricing for data transfers.The client networkConfirm that your client network is healthy by reviewing internal packet inspections, antivirus scanning, or network access management. Additionally, review how your client or application handles DNS resolution and caching.To benefit from Amazon S3's distributed nature and availability, avoid caching the DNS resolution for long periods of time.The client resourcesThere might be latency introduced in your application or how your host that's making the requests is handling the requests sent and responses received. As a best practice, confirm that there's no resource contention within the host that might be contributing to the overall latency. For example, the resource contention within the host might be with the CPU, memory, or network bandwidth.You can check the resource usage during data transfer on most client systems using tools such as Resource Monitor or the top command. The tools available depend on your operating system.The client's storage device or system might also be a source of latency. Read or write operations to the client's storage device that experience elevated latency can impact the performance of the download or upload to Amazon S3. You must troubleshoot the IOPS of the storage device from the client side. You can analyze Amazon S3 performance with the Amazon CloudWatch metric FirstByteLatency.Note: Amazon S3 CloudWatch request metrics are billed at the same rate as custom metrics.FirstByteLatency shows how long it takes for Amazon S3 to process the request from the client and then begin sending the response to the client. The CloudWatch metric provides a bucket-level perspective of performance. You can narrow down your investigation using Amazon S3 server access logs. For more information, see the section Amazon S3 server access logs to determine the Turn-Around Time.The request rate to Amazon S3By default, S3 buckets can support thousands of requests per second per prefix. If a client is getting HTTP 5xx error responses from Amazon S3, this can indicate that the supported request rate per prefix is exceeded. To troubleshoot 5xx errors, see How do I troubleshoot an HTTP 500 or 503 error from Amazon S3?The Amazon S3 server access logs to determine the Turn-Around TimeYou can turn on Amazon S3 server access logging to review Turn-Around Time metrics. Turn-Around Time is the time between when the last byte of the request is received and when the first byte of the response is sent. This is a Time To First Byte (TTFB) metric. You can use Turn-Around Time to determine the amount of time the operation is taking from an Amazon S3 perspective. Then, you can evaluate other latencies outside of Amazon S3 that might be contributing to an overall slow download or upload.If you see latency that's higher than usual, it's a best practice to retry the request instead of waiting for the request to complete. For more information on this guidance and other performance recommendations, see Performance guidelines for Amazon S3.Follow"


Question: Why are my Amazon ECS container instances with Amazon Linux 1 AMIs disconnected?

My container instances for Amazon Elastic Container Service (Amazon ECS) are disconnected.

Answer: "My container instances for Amazon Elastic Container Service (Amazon ECS) are disconnected.Short descriptionYour Amazon ECS container agent might connect and reconnect several times an hour. These change events are normal and aren't a cause for concern.However, if your container agent remains in a disconnected state, then the container instance can't operate as part of your ECS cluster. Your agent is disconnected when agentConnected returns false. The issue can be caused by the following:Networking issues prevent communication between the instance and Amazon ECS.The container agent doesn't have the required AWS Identity and Access Management (IAM) permissions to communicate with Amazon ECS endpoints.There are problems with the host or Docker service inside the container instance.To identify the cause of the disconnection, complete the following steps.ResolutionNote: The following resolution applies to Amazon ECS-optimized Amazon Linux 1 AMIs. For a resolution that applies to Amazon ECS-optimized Amazon Linux 2 AMIs, see How do I troubleshoot a disconnected Amazon ECS agent?Verify that the Docker service is running on the container instance1.    To verify that the Docker service is running on the affected container instance, run the following command:sudo service docker statusThe command output is similar to the following:docker (pid 23013) is running...If the Docker service isn't running, or if you need to restart the service, run the following command:sudo service docker restartNote: Don't enter this command while the service is already running. First, make sure to set the container instance to the draining state. Then, restart the Docker service for existing tasks to be scheduled on another container instance.The command output must include the following lines:Stopping docker: [  OK  ]Starting docker: [  OK  ]Note: To verify that the Docker service is running after the restart command, run the sudo service docker status command.2.    To start the ECS agent, run the following command:sudo start ecsVerify that the container agent is running on the container instanceTo verify that the container agent is running on the affected container instance, run the following command:sudo status ecsIf the container agent isn't running on your container instance, then run the following command to start the agent:sudo start ecsThe command output is similar to the following:ecs start/running, process 23403Review log files for the container agent and DockerIf your container instances are still disconnected, review the log files on the container host for the container agent and Docker.To output the log files for the container agent and Docker, run the following commands:sudo cat /var/log/ecs/ecs-agent.log.YYYY-MM-DD-**sudo cat /var/log/dockerNote: To collect log information from the container instance, run the Amazon ECS logs collector.Verify that the IAM instance profile has the necessary permissionsIf the container agent is still disconnected, verify that the IAM instance profile associated with the container instance has the necessary IAM permissions.1.    Connect to the instance using SSH.2.    To view the instance metadata on the instance profile associated with the instance, run the following command:curl http://169.254.169.254/latest/meta-data/iam/infoThe command output is similar to the following:{  "Code" : "Success",  "LastUpdated" : "2019-06-29T15:47:03Z",  "InstanceProfileArn" : "arn:aws:iam::1122334455:instance-profile/ecsInstanceRole",  "InstanceProfileId" : "AIPAJ5WF3LZVY7PLUHV72"}3.    Verify that the IAM role contains the correct permissions for your container instances.4.    To verify specific credential errors with the container agent, run the following command to check the container agent log for a list of ECS logs:cat /var/log/ecs/ecs-agent.log.YYYY-MM-DD-**Note: The container agent log is rotated every hour, and the suffix automatically changes to reflect the current date and time. Update the command to include the date range and log ID for when the issue occurred.If the container agent doesn't have the necessary credentials, you receive an error similar to the following in the logs:2019-06-29T16:10:09Z [ERROR] Unable to register as a container instance with ECS: AccessDeniedException: User: arn:aws:sts::1122334455:assumed-role/ecsInstanceRole/i-0052b2e858b1891ef is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-east-1:1122334455:cluster/exampleCluster    status code: 400, request id: 0b73e260-5088-4688-a425-6f35f1ef440f2019-06-29T16:10:09Z [ERROR] Error re-registering: AccessDeniedException: User: arn:aws:sts::1122334455:assumed-role/ecsInstanceRole/i-0052b2e858b1891ef is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-east-1:1122334455:cluster/exampleCluster    status code: 400, request id: 0b73e260-5088-4688-a425-6f35f1ef440fAdditional helpIf you can't identify the issue with your ECS container instance from this resolution, contact Premium Support for help. First, use Amazon ECS logs collector to create an archive of your instance's logs. Then, attach the logs to a support ticket to help the support engineer troubleshoot the issue.Related informationAmazon ECS troubleshootingAmazon ECS container agentAmazon ECS container instance IAM roleAmazon ECS log file locationsFollow"


Question: How long is the Amazon RDS maintenance window?

What is the duration of an Amazon Relational Database Service (Amazon RDS) maintenance window?

Answer: "What is the duration of an Amazon Relational Database Service (Amazon RDS) maintenance window?ResolutionAmazon RDS maintenance is sometimes required to update a database engine version or the operating system (OS) of a DB instance or DB cluster. The duration of the maintenance varies based on the operations that Amazon RDS has scheduled for your DB instances, and the operations that start during the maintenance window.When you create or modify a DB instance, you can configure the maintenance window. You can schedule maintenance to occur once a week, during a specific time period that lasts between 30 minutes and up to 23 hours and 30 minutes. After configuring the window, Amazon RDS will start maintenance actions during the scheduled time period.You can minimize downtime during required Amazon RDS maintenance by modifying your DB instance to a Multi-AZ deployment before the scheduled update.Maintenance Window end timeUpdates can take longer to complete than the maintenance window time frame. For example, Amazon RDS can take longer to update if there is a large list of files that must be updated or if a DB instance needs to be restarted.After Amazon RDS has updated the instance, the duration of the downtime varies based on whether the maintenance is an OS update or a database engine version update.Note: You can't proactively start the Amazon managed maintenance period outside the maintenance window, but you can adjust your weekly maintenance period, accordingly. If you want scheduled maintenance to occur sooner, you can adjust the preferred DB instance maintenance window to occur according to your needs.Related informationWhat happens to Amazon RDS and Amazon Redshift queries that are running during a maintenance window?How do I configure notifications for Amazon RDS or Amazon Redshift maintenance windows?Follow"


Question: What factors affect my downtime or database performance in Amazon RDS?

I'm trying to modify my Amazon Relational Database Service (Amazon RDS) DB instance. What's the potential impact to database availability or performance during this change?

Answer: "I'm trying to modify my Amazon Relational Database Service (Amazon RDS) DB instance. What's the potential impact to database availability or performance during this change?ResolutionModifying an instance class in Amazon RDSWhen you modify the instance class of a Single-AZ instance in Amazon RDS, a new Amazon Elastic Compute Cloud (Amazon EC2) host is created. After the new Amazon EC2 host is created with the updated instance class, the existing host's database will be shut down. Data storage is then detached from the old host and reattached to the new host of a requested instance class. Your database is then restarted and the engine performs recovery to make sure that your database remains in a consistent state. Any outages during this process will be proportional to the duration of database recovery.When you modify the instance class of a Multi-AZ instance in Amazon RDS, first your standby instance is updated. After this update, a failover occurs, switching roles of the standby and primary instances. The failover mechanism also propagates the DNS endpoint of the DB instance to point to the new host. After database recovery, the database can be accessed by the application. The instance class modification is then performed on the new standby instance.Depending on your database activity or any long-running transactions, your failover might take longer than usual to complete. Failovers typically complete within 60–120 seconds. However, large transactions or a lengthy recovery process can increase failover time. It's a best practice to make sure that there are no open transactions in your database during an instance modification. You can also schedule a maintenance task to avoid any disruptions.Modifying storage in Amazon RDSIf you need additional space for data or different storage performance attributes, Amazon RDS supports updates to the following (without performance impact):Storage allocationIOPSVolume typeAmazon RDS leverages Amazon Elastic Block Store (Amazon EBS) Elastic Volumes to minimize the time required for storage scaling operations. Based on the amount of storage requested, Amazon RDS automatically stripes across multiple Amazon EBS volumes to enhance performance.When you modify your instance to add storage, your DB instance is fully operational for the application queries. After you modify storage on an RDS instance, there is a six-hour grace period before you can make additional storage updates. During this period, the instance status shows as “storage optimization”. When your instance enters the “storage optimization” phase, the new storage attributes are fully enabled, and performance isn't impacted.Scaling storage in Amazon RDSScaling storage is an online process, and the database is fully operational during the process. However, for some legacy RDS instances, a one-time storage conversion is required.During this operation, I/O performance might be impacted while Amazon RDS reads data from the old set of volumes and writes to the new set. Additionally, when scaling beyond 400 GB (or 200 GB for Oracle database instances), Amazon RDS also uses the legacy method for scaling. During the legacy method, you might experience performance degradation. All subsequent scaling storage modifications will use the elastic scaling method.Single-AZ to Multi-AZ conversions in Amazon RDSWhen you convert a DB instance from Single-AZ to Multi-AZ, Amazon RDS first creates a copy of the database. Then, the copy is restored in a different Availability Zone. Because restoring EBS snapshots is also part of this process, storage blocks will be copied over to the new volume. As a result, Single-AZ to Multi-AZ conversions can impact latency and DB instance performance. For more information, see High availability (Multi-AZ) for Amazon RDS.The impact of converting to Multi-AZ is more pronounced for write-intensive DB instances with large storage volumes, during high workload periods. Additionally, any operation that involves restoring volumes (such as creating read replicas or restoring snapshots into a new DB instance) will result in increased latency. After the storage blocks are copied over from Amazon Simple Storage Service (Amazon S3) to the new volume, any latency will subside.Follow"


Question: How do I request an EC2 vCPU limit increase for my On-Demand Instance?

I want to do the following:Calculate the Amazon Elastic Compute Cloud (Amazon EC2) vCPU limit increase for my Amazon EC2 On-Demand Instance.Request the limit increase.

Answer: "I want to do the following:Calculate the Amazon Elastic Compute Cloud (Amazon EC2) vCPU limit increase for my Amazon EC2 On-Demand Instance.Request the limit increase.Short descriptionEC2 vCPU limit increases are submitted as a vCPU value. To request an increase, first determine how many vCPUs that your On-Demand Instances are using. You can use the  vCPU limits calculator to measure the number of vCPUs that you are currently using against vCPU-based limits to determine the appropriate service limit increase to request. You can create a service limit request directly from the vCPU limits calculator.ResolutionRequest an On-Demand Instance limit increaseSign in to the Amazon EC2 console.In the Region selector, choose the AWS Region where you want to request a vCPU increase.(Optional) To view the instances that are already running, from the EC2 Dashboard, under Resources, choose Instances (running).In the navigation pane, Choose Limits.Choose Calculate vCPU limit to access the vCPU limits calculator.In the Limits calculator page, choose Add instance type.For Instance type, select an available instance type from the dropdown list.For Instance count, enter the number of new instances (of the type that you chose in step 6) that you want.Continue adding instance types as needed.Review the Limits calculation section. If the New limit exceeds the Current limit, choose Request on-demand limit increase to submit a service limit increase request. The value in the New limit field is the number of vCPUs that you must request.Example calculationsNote: You can use the vCPU limits calculator for these calculations.Scenario 1: You're not currently running any G family instances. You want to launch three g4dn.xlarge instances.Your current vCPU limit is Running On-Demand All G instances = 8 vCPU.A g4dn.xlarge instance has a footprint of 4 vCPUs. Your account can already run two g4dn.xlarge instances, based on your G instances limit of 8.In this scenario, submit a vCPU service limit increase request for 12 vCPUs (3*4).Format your request as follows:Limit type: EC2 InstancesRegion: US WestPrimary Instance Type: Running On-Demand All G instancesNew limit value: 12Note: Replace US West with the Region where you're requesting a limit increase.Scenario 2: You're currently running 64 vCPUs worth of instances. You want to launch two additional m5.2xlarge and two additional m4.10xlarge instance types.Your current vCPU limit is Running On-Demand All Standard (A, C, D, H, I, M, R, T, Z) instances = 64 vCPU.Both instance types that you want to launch are included in the "All Standard (A, C, D, H, I, M, R, T, Z) instances" limit. Usage for these instance types is added together and governed by a single limit. The instance-to-vCPU conversion rates for these two types of instances are as follows:*.2xlarge instances = 8 vCPU per instance*.10xlarge instances = 40 vCPU per instance.Therefore, the additional number of vCPUs needed is calculated as follows:[2 * 8] + [2 * 40] = 96.You need 96 additional vCPUs if your account is already running 64 vCPUs worth of instances.In this scenario, submit a vCPU service limit increase request for 160 vCPUs (64 + 96) or higher.Format your request as follows:Limit type: EC2 InstancesRegion: US WestPrimary Instance Type: Running On-Demand All Standard (A, C, D, H, I, M, R, T, Z) instancesNew limit value: 160Note: Replace US West with the Region you're requesting a limit increase in.Scenario 3: You want to test more powerful instance types, but aren't sure which instances you need. You want to play around before deciding. Therefore, your service limit increase request needs to provide you flexibility.Your current vCPU limit is Running On-Demand All P instances = 64 vCPU.The vCPUs of an instance within a family can range from 1 to 128 vCPUs, depending on the size. vCPU limits give you the versatility to start with one instance type, and then switch to another instance type without submitting a new limit increase, as long as you stay within your vCPU limit.For example, you might request a combination of P instance types:Five p3.2xlarge instances, 8 vCPU per instance = 40 vCPUOne of the largest P-Family instance type, the p3dn.24xlarge, 96 vCPU per instance = 96 vCPUIn this scenario, to keep your limit request small while retaining flexibility, submit a request for 136 vCPU (40 + 96).Format your request as follows:Limit type: EC2 InstancesRegion: US WestPrimary Instance Type: Running On-Demand All P instancesNew limit value: 136Note: Replace US West with the Region that you're requesting a limit increase in.To streamline the processing of your limit increase request, in the Use case description section of the request form, include specific instance types (for example, p3.8xlarge or p3dn.24xlarge). Also, note whether you're expecting to use the different instances in parallel or one at a time.Related informationOn-Demand InstancesTroubleshooting instance launch issuesFollow"


Question: How can I troubleshoot issues with joining my Storage Gateway file gateway to a domain for Microsoft Active Directory authentication?

"I created a file gateway on AWS Storage Gateway and I want to use Microsoft Active Directory (Microsoft AD) for authentication. However, when I try to join my file gateway with the Microsoft AD domain, I get one of these error messages:NETWORK_ERRORTIMEOUTACCESS_DENIEDHow can I troubleshoot these errors so that I can join my gateway to the domain?"

Answer: "I created a file gateway on AWS Storage Gateway and I want to use Microsoft Active Directory (Microsoft AD) for authentication. However, when I try to join my file gateway with the Microsoft AD domain, I get one of these error messages:NETWORK_ERRORTIMEOUTACCESS_DENIEDHow can I troubleshoot these errors so that I can join my gateway to the domain?ResolutionTo troubleshoot the errors, try the following checks or configurations:1.    Confirm that the gateway can reach the domain controller by running a nping test. To run a nping test, connect to AWS Storage Gateway console using ssh for Amazon Elastic Compute Cloud (Amazon EC2) and the console for VMware, Hyper-V, or KVM. Select the option Command Prompt, and then type h to list all the available commands from the console. To test the connectivity between the Storage Gateway virtual machine and the domain, run the following command:Note: Replacewith the domain DNS name and <389> with the LDAP port used. Also, verify that you have opened the required ports within your firewall.nping -d <corp.domain.com> -p <389> -c 1 -t tcpThe following is an example of a successful nping test where the gateway was able to reach the domain controller:nping -d corp.domain.com -p 389 -c 1 -t tcpStarting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTCSENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40  seq=2597195024 win=1480 RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44  seq=4170716243 win=8192 <mss 8961>Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310msRaw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)Nping done: 1 IP address pinged in 1.09 seconds<br>If there is no connectivity, the response of the nping command will look similar to the output below. The command below doesn't have a response for the destination 'corp.domain.com':nping -d <corp.domain.com> -p <389> -c 1 -t tcpStarting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTCSENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389  S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480Max rtt: N/A | Min rtt: N/A | Avg rtt: N/ARaw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)Nping done: 1 IP address pinged in 1.07 seconds2.    If the file gateway is running on an Amazon EC2 instance, then you must create a DHCP options set and then attach the set (if it's not already set) to the Amazon Virtual Private Cloud (VPC) that the instance is in. 3.    Confirm that the domain can be resolved by the file gateway. If the domain isn't resolvable by the gateway appliance, then you can't join the domain. To confirm that the Gateway is resolving the DNS of the domain, run the following command:Note: Replacewith the domain DNS name.dig -d <corp.domain.com>; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4000;; QUESTION SECTION:;corp.domain.com.        IN    A;; ANSWER SECTION:corp.domain.com.    600    IN    A    10.10.10.10corp.domain.com.    600    IN    A    10.10.20.10;; Query time: 0 msec;; SERVER: 10.10.20.228#53(10.10.20.228);; WHEN: Thu Jun 30 16:36:32 UTC 2022;; MSG SIZE  rcvd: 784.    Verify that the domain controller isn't set to read-only, and that the domain controller has enough roles for computers to join. To check this, try joining other servers in the same VPC subnet as the gateway VM to the domain.5.    It's a best practice to join the file gateway to a domain controller that is geographically closer to the gateway. If the gateway appliance can't reach or query the domain controller within 20 seconds, then the process can time out. For example, the domain-join process might time out if the gateway appliance is in the US East (N. Virginia) Region and the domain controller is in the Asia Pacific (Singapore) Region.Note: To increase the default timeout value of 20 seconds, you can run the join-domain command on the AWS Command Line Interface (AWS CLI) and include the --timeout-in-seconds option to increase the time. You can also use the JoinDomain API call and include the TimeoutInSeconds parameter to increase the time. The maximum timeout value is 3,600 seconds.If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.6.    Check whether the organizational unit (OU) of the Microsoft AD has any Group Policy Objects that create a new computer object in a location other than the default OU. For this use case, there must be a new computer object in the OU before you join the domain to the file gateway. Some environments are customized to have different OUs for newly created objects. To be sure that a computer object (for the gateway VM) under a certain OU joins the domain, try creating the computer object on your domain controller before joining the file gateway to the domain. Or, you can run the join-domain command using the AWS CLI. Then, specify the option for --organizational-unit.Note: The process of creating the computer object is called pre-staging.7.    If you still can't join the gateway to the domain after trying the previous checks and configurations, check if there are any related event logs. Check for any errors in the event viewer of the domain controller. Verify if the gateway query reached the domain controller.Follow"


Question: How can I pass variables from my Elastic Beanstalk environment to Linux and Windows instances?

I want to pass variables from my AWS Elastic Beanstalk environment to Linux and Windows Amazon Elastic Compute Cloud (Amazon EC2) instances.

Answer: "I want to pass variables from my AWS Elastic Beanstalk environment to Linux and Windows Amazon Elastic Compute Cloud (Amazon EC2) instances.Short descriptionYou can pass environment variables to Amazon EC2 instances by using the following:Elastic Beanstalk consoleElastic Beanstalk Command Line Interface (EB CLI)Option settingsAWS 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.ResolutionImportant: To pass confidential information (such as a database password) to the instance, follow the instructions at Storing private keys securely in Amazon S3.Pass your environment variablesChoose one of the following ways to pass your environment variables.Use the Elastic Beanstalk consoleTo pass your environment variables using the console, follow the instructions in Configuring environment properties.Important: Be sure to consider environment property limits.Use the EB CLITo set an environment variable in the EB CLI, run the following command:eb setenv key=valueIn the following example, the environment variable ExampleVar is set:$ eb setenv ExampleVar=ExampleValue2018-07-11 21:05:25    INFO: Environment update is starting.2018-07-11 21:05:29    INFO: Updating environment tmp-dev's configuration settings.2018-07-11 21:06:50    INFO: Successfully deployed new configuration to environment.2018-07-11 21:06:51    INFO: Environment update completed successfully.To set multiple environment properties, use the following command:$ eb setenv foo=bar JDBC_CONNECTION_STRING=hello PARAM4= PARAM5=Use option settingsYou can use Elastic Beanstalk configuration files to set environment properties and configuration options in your source code.To define environment properties, use the aws:elasticbeanstalk:application:environment namespace.See the following .ebextensions/options.config example:option_settings:  aws:elasticbeanstalk:application:environment:    API_ENDPOINT: www.example.com/apiTo set environment properties in the AWS CLI, run the following command:$ aws elasticbeanstalk update-environment --environment-name my-env --option-settings file://options.jsonFor example:[  {    "Namespace": "aws:elasticbeanstalk:application:environment",    "OptionName": "API_ENDPOINT",    "Value": "www.example.com/api"  },  {    "Namespace": "aws:elasticbeanstalk:application:environment",    "OptionName": "URL",    "Value": "http://myurl.com"  }]Access your environment variablesNote: Environment properties aren't automatically exported to the shell, even though they are present in the instance. Instead, environment properties are made available to the application through the stack that it runs in, based on the platform that you're using.To access your environment variables, see Accessing environment properties.To access your environment variables outside of application code (for example, in a script that runs during deployment), use the get.config platform script or Fn::GetOptionSetting.For Windows instances, environment properties are passed from C:\ProgramFiles\Amazon\ElasticBeanstalk\config\containerconfiguration to the Microsoft Internet Information Services (IIS) server. Warning: This file location is subject to the Elastic Beanstalk framework and can be changed without warning.Follow"