Question: How do I troubleshoot issues when I configure SSM Agent to use a proxy for managing my Amazon EC2 instance?

I receive errors when I use a proxy with SSM Agent to manage my Amazon Elastic Compute Cloud (Amazon EC2) instance with AWS Systems Manager. How can I troubleshoot proxy issues?

Answer: "I receive errors when I use a proxy with SSM Agent to manage my Amazon Elastic Compute Cloud (Amazon EC2) instance with AWS Systems Manager. How can I troubleshoot proxy issues?Short descriptionYou can use Systems Manager to manage your Amazon EC2 instances. However, if the instances are behind a proxy, then you must configure SSM Agent to communicate with the Amazon endpoints through your proxy. If SSM Agent isn’t correctly configured, you receive an error message similar to the following:Post https://ssm.RegionID.amazonaws.com/: proxyconnect tcp: dial tcp xxx.xxx.xxx.xxx:yyyy: i/o timeoutResolutionTo troubleshoot proxy issues, follow these steps:Verify that the EC2 instance can access your proxy serverEC2 Windows instancesYou can use the following Windows PowerShell command to verify connectivity to your proxy. In the following example, replace hostname with your proxy hostname, and replace port with your proxy port.> Test-NetConnection hostname -port portExpected output:ComputerName     : hostnameRemoteAddress    : xxx.xxx.xxx.xxxRemotePort       : portInterfaceAlias   : EthernetSourceAddress    : YYY.YYY.YYY.YYYTcpTestSucceeded : TruePS C:\Windows\system32>EC2 Linux instancesYou can use the following telnet or netcat commands to verify connectivity to your proxy. In the following examples, replace hostname with your proxy hostname, and replace port with your proxy port.Telnet$ telnet hostname portExpected output:Trying xxx.xxx.xxx.xxx...Connected to hostname.Escape character is '^]'.Netcat$ nc -vz hostname port'Expected output:Ncat: Version 7.50 ( https://nmap.org/ncat )Ncat: Connected to xxx.xxx.xxx.xxx:YYYY.Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.Note: Netcat doesn't come preinstalled on Amazon EC2 instances. To manually install Netcat, see Ncat on the Nmap website.Verify that your EC2 instance can reach the Systems Manager endpoint through the proxy serverRun the following command to confirm that your instance can reach the Systems Manager endpoint through your proxy server. Receiving an http error code 4xx indicates that you can reach the endpoint through your proxy server.Note: In the following command examples, replace RegionID with your AWS Region, replace hostname with your proxy hostname, and replace port with your proxy port.EC2 Windows instances> (invoke-webrequest https://ssm.RegionID.amazonaws.com -DisableKeepAlive -UseBasicParsing -Method head -Proxy http://hostname:port )Expected output:invoke-webrequest : The remote server returned an error: (404) Not Found.EC2 Linux instances$  curl -k --proxy http://hostname:port -m 5 -s -o /dev/null -w "%{http_code}" https://ssm.RegionID.amazonaws.comExpected output:404Verify that SSM Agent is configured to use your proxy informationEC2 Windows instancesYou must review the SSM Agent log to verify that the proxy settings are applied as shown in the following example. Enter the following command:> type C:\ProgramData\Amazon\SSM\Logs\amazon-ssm-agent.log | findstr -i "proxy"Expected output:2021-03-18 19:06:16 INFO Getting IE proxy configuration for current user: The operation completed successfully.2021-03-18 19:06:16 INFO Getting WinHTTP proxy default configuration: The operation completed successfully.2021-03-18 19:06:16 INFO Proxy environment variables:2021-03-18 19:06:16 INFO http_proxy: hostname:port2021-03-18 19:06:16 INFO https_proxy:2021-03-18 19:06:16 INFO no_proxy: 169.254.169.254For more information, see Configure SSM Agent to use a proxy for Windows Server instances.EC2 Linux instancesFirst, run the following command to verify whether SSM Agent currently uses the required proxy variables by checking the process environment variable:sudo cat /proc/$(pidof amazon-ssm-agent)/environ | xargs -0 -L1 -I{} echo {}Expected output:[root@host123~]# sudo cat /proc/$(pidof amazon-ssm-agent)/environ | xargs -0 -L1 -I{} echo {}LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binhttp_proxy=http://Hostname:Porthttps_proxy=http://Hostname:Portno_proxy=169.254.169.254Then, if the output does not include the proxy variables, follow the guidance below for your instance type to verify and update the relevant files.EC2 Linux instances based on an upstart such as Ubuntu 14.04Verify that the amazon-ssm-agent.override file contains the required configurations. Enter the following command and confirm that your output matches the example expected output. For more information, see Configure SSM Agent to use a proxy (upstart).Important: If you update the amazon-ssm-agent.override file, then be sure to restart SSM Agent after the file is edited.$ cat  /etc/init/amazon-ssm-agent.overrideExpected output for an HTTP proxy server:env http_proxy=http://hostname:portenv https_proxy=http://hostname:portenv no_proxy=169.254.169.254Expected output for an HTTPS proxy server:env http_proxy=http://hostname:portenv https_proxy=https://hostname:portenv no_proxy=169.254.169.254EC2 Linux instances based on Ubuntu 16.04 or later with SSM Agent installed using a snapEnter the following command and confirm that the proxy information matches the example expected output. For more information, see Configure SSM Agent to use a proxy (systemd).Important: If you update the amazon-ssm-agent.override file, then be sure to restart SSM Agent after the file is edited.$ cat /etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d/override.confExpected output for an HTTP proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=http://hostname:port"Environment="no_proxy=169.254.169.254"Expected output for an HTTPS proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=https://hostname:port"Environment="no_proxy=169.254.169.254"EC2 Linux instances based on Amazon Linux 2Enter the following command and confirm that the proxy information matches the example expected output. For more information, see Configure SSM Agent to use a proxy (systemd).Important: If you update the amazon-ssm-agent.override file, then be sure to restart SSM Agent after the file is edited.$ cat /etc/systemd/system/amazon-ssm-agent.service.d/override.confExpected output for an HTTP proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=http://hostname:port"Environment="no_proxy=169.254.169.254"Expected output for an HTTPS proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=https://hostname:port"Environment="no_proxy=169.254.169.254"EC2 Linux instances based on other operating systemsEnter the following command and confirm that the proxy information matches the example expected output. For more information, see Configure SSM Agent to use a proxy (systemd).Important: If you update the amazon-ssm-agent.override file, then be sure to restart SSM Agent after the file is edited.$ cat /etc/systemd/system/amazon-ssm-agent.service.d/amazon-ssm-agent.overrideExpected output for an HTTP proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=http://hostname:port"Environment="no_proxy=169.254.169.254"Expected output for an HTTPS proxy server:[Service]Environment="http_proxy=http://hostname:port"Environment="https_proxy=https://hostname:port"Environment="no_proxy=169.254.169.254"Related informationWorking with SSM AgentTroubleshooting SSM AgentFollow"


Question: How do I pass custom headers through API Gateway to a Lambda function using Lambda custom (non-proxy) integration?

I want to configure an AWS Lambda function through custom (non-proxy) integration to process custom headers that are passed through my Amazon API Gateway API. How do I set that up?

Answer: "I want to configure an AWS Lambda function through custom (non-proxy) integration to process custom headers that are passed through my Amazon API Gateway API. How do I set that up?Short descriptionBy default, a Lambda function processes only the method request body it receives from an API Gateway API request. To pass custom headers from an API Gateway API to a Lambda function, use a body mapping template. The API sends the updated API request to a Lambda function to process the headers. Then, the Lambda function returns one or more header values from the original API request.ResolutionConfigure the required AWS Identity and Access Management (IAM) permissionsFollow the instructions in Control access to an API with IAM permissions.For testing this procedure, you can create an IAM role and attach the following AWS managed policies:AmazonAPIGatewayInvokeFullAccessAmazonAPIGatewayPushToCloudWatchLogsCreate a Lambda function to handle custom headers from your API Gateway API1.    Open the Lambda console.2.    Choose Create function. The Create function page opens with the Author from scratch option selected.3.    In the Basic information pane, do the following:For Function name, enter a name that describes your function's purpose. For example: CustomHeaders.For Runtime, choose Node.js 14.x.4.    Under Permissions, expand Change default execution role.5.    Choose Use an existing role. A dropdown list of existing roles appears.6.    For Existing role, choose the Lambda execution role that you created previously.7.    Choose Create function.8.    On the Code source pane, replace the code in the editor pane (index.js) with the following:exports.handler = (event, context, callback) => {// TODO implementcallback(null, "This message header was processed by Amazon " +event.headers["header1"]);};9.    Choose Save.For more information, see Building Lambda functions with Node.js.Create an API Gateway REST API1.    Open the API Gateway console.2.    Choose Create API.-or-(If this is your first time using API Gateway) A page that introduces you to the features of the service appears. Under REST API, choose Build. When the Create Example API popup appears, choose OK.3.    For Choose an API type, in the REST API pane, choose Build.4.    Under Create new API, choose New API.5.    Under Settings, do the following:For API name, enter a name that describes your API's purpose. For example: SendtoLambda.(Optional) For Description, enter a short description your API's purpose.For Endpoint Type, choose Regional.6.    Choose Create API.Configure your API's integration point and body mapping template1.    In the API Gateway console, choose the name of the API that you created in the previous step. Your API's Resources page opens.2.    On the Resources page, choose Actions. Then, choose Create Resource.3.    In the New Child Resource pane, do the following:For Resource Name, enter a name that describes the resource. For example: HeadersResource.Choose Create Resource.4.    Choose Actions. Then, choose Create Method.5.    From the dropdown list under /headersresource, choose POST. Then, choose the check mark icon.6.    On the /headersresource - POST - Setup page, do the following:For Integration type, choose Lambda Function.For Lambda Region, choose the AWS Region that hosts your function.For Lambda Function, enter your function's name.Choose Save. An Add Permission to Lambda Function popup appears.In the popup, choose OK.7.    On the /headersresource - POST - Method Execution page, choose Integration Request.8.    On the /headersresource - POST - Integration Request page, do the following:Expand Mapping Templates.For Request body passthrough, choose When there are no templates defined (recommended).Choose Add mapping template.For Content-Type, enter application/json. Then, choose the check mark icon.9.    In the mapping template editor, enter the following:{  "method": "$context.httpMethod",  "body" : $input.json('$'),  "headers": {    #foreach($param in $input.params().header.keySet())    "$param": "$util.escapeJavaScript($input.params().header.get($param))"    #if($foreach.hasNext),#end    #end  }}10.    Choose Save.Deploy your API to a new stage1.    Follow the instructions in Deploy a REST API to a stage. For more information, see Setting up a stage using the API Gateway console.2.    In the Stage Editor pane, copy the Invoke URL to your clipboard.REST API Invoke URL examplehttps://1a2bc3d456.execute-api.region.amazonaws.com/testTest your setupTo confirm that message headers are being processed by your API and Lambda function, run the following curl command:Important: Replace https://restApiId.execute-api.region.amazonaws.com/stageName with your API's invoke URL.curl -H "Content-Type: application/json" -H "header1: API Gateway and AWS Lambda" -X POST -d "{\"API_body\": \"This is the body\"}" https://restApiId.execute-api.region.amazonaws.com/stageName/headersresourceExample output"This message header was processed by Amazon API Gateway and AWS Lambda"Note: To install curl on Windows, see Downloads on the Git website. For more information about curl, see the curl project website.Related informationSetting up data transformations for REST APIsLambda permissionsControl access to an API with IAM permissionsFollow"


Question: How can I send user-data output to the console logs on an EC2 instance running RHEL 7 or RHEL 8?

I'm trying to troubleshoot my Amazon Elastic Compute Cloud (Amazon EC2) Linux RHEL 7 or RHEL 8 instance bootstrap. How can I log the user-data invocation and then ship it to the console logs?

Answer: "I'm trying to troubleshoot my Amazon Elastic Compute Cloud (Amazon EC2) Linux RHEL 7 or RHEL 8 instance bootstrap. How can I log the user-data invocation and then ship it to the console logs?Short descriptionTo troubleshoot issues on your EC2 instance bootstrap without having to access the instance through SSH, you can add code to your user-data bash script that redirects all the output both to the /var/log/user-data.log and to /dev/console. When the code is executed, you can see your user-data invocation logs in your console.Note: This resolution is for RHEL 7 and RHEL 8 only. For information on Amazon Linux and Amazon Linux 2, see How can I send user-data output to the console logs on an EC2 instance running Amazon Linux or Amazon Linux 2?Resolution1.    Open the Amazon EC2 console.2.    Launch a new instance and SSH into it.3.    Edit the GRUB_CMDLINE_LINUX line in /etc/default/grub and change "console=ttyS0,115200n8 console=tty0" to "console=tty1 console=ttyS0".RHEL 7:# cat /etc/default/grubGRUB_TIMEOUT=1GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"GRUB_DEFAULT=savedGRUB_DISABLE_SUBMENU=trueGRUB_TERMINAL_OUTPUT="console"GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"GRUB_DISABLE_RECOVERY="true"RHEL 8:# cat /etc/default/grubGRUB_TIMEOUT=1GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"GRUB_DEFAULT=savedGRUB_DISABLE_SUBMENU=trueGRUB_TERMINAL_OUTPUT="console"GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"GRUB_DISABLE_RECOVERY="true"GRUB_ENABLE_BLSCFG=true4.    Recreate the /boot/grub2/grub.cfg file:RHEL 7:# grub2-mkconfig -o /boot/grub2/grub.cfgGenerating grub configuration file ...Found linux image: /boot/vmlinuz-3.10.0-1062.1.2.el7.x86_64Found initrd image: /boot/initramfs-3.10.0-1062.1.2.el7.x86_64.imgFound linux image: /boot/vmlinuz-0-rescue-026767dbe06a4910a5ce3bd0def903c0Found initrd image: /boot/initramfs-0-rescue-026767dbe06a4910a5ce3bd0def903c0.imgdoneRHEL 8:# grub2-mkconfig -o /boot/grub2/grub.cfgGenerating grub configuration file ...done5.   Stop the instance.6.    Create a new AMI from the modified instance.7.    Launch a new instance from the new AMI.8.    Enter the following command to redirect the user-data output console:#!/bin/bash -xeexec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1  yum -y update  echo "Hello from user-data!"The following is the line that redirects the user-data output:exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1The following is sample console output:RHEL 7:  subscription-manager.x86_64 0:1.24.26-3.el7_8  subscription-manager-rhsm.x86_64 0:1.24.26-3.el7_8  subscription-manager-rhsm-certificates.x86_64 0:1.24.26-3.el7_8  sudo.x86_64 0:1.8.23-9.el7  systemd.x86_64 0:219-73.el7_8.8  systemd-libs.x86_64 0:219-73.el7_8.8  systemd-sysv.x86_64 0:219-73.el7_8.8  teamd.x86_64 0:1.29-1.el7  tuned.noarch 0:2.11.0-8.el7  tzdata.noarch 0:2020a-1.el7  util-linux.x86_64 0:2.23.2-63.el7  yum.noarch 0:3.4.3-167.el7  yum-utils.noarch 0:1.1.31-54.el7_8Replaced:  iwl7265-firmware.noarch 0:22.0.7.0-72.el7Complete!+ echo 'Hello from user-data!'Hello from user-data!RHEL 8:Installed:  grub2-tools-efi-1:2.02-82.el8_2.1.x86_64  kernel-4.18.0-193.13.2.el8_2.x86_64  kernel-core-4.18.0-193.13.2.el8_2.x86_64  kernel-modules-4.18.0-193.13.2.el8_2.x86_64  linux-firmware-20191202-97.gite8a0f4c9.el8.noarchComplete!+echo 'Hello from user-data!'Hello from user-data!Related informationRunning commands on your Linux instance at launchFollow"


Question: Why is my SELECT query running slowly on my Amazon Aurora MySQL DB Cluster?

"I have an Amazon Aurora MySQL-Compatible Edition DB cluster, and I want to use the SELECT query to select data from my database. When I run the SELECT query on my DB cluster, the query is running slowly. How can I identify and fix the cause of slow SELECT queries?"

Answer: "I have an Amazon Aurora MySQL-Compatible Edition DB cluster, and I want to use the SELECT query to select data from my database. When I run the SELECT query on my DB cluster, the query is running slowly. How can I identify and fix the cause of slow SELECT queries?Short descriptionThere are several reasons that SELECT queries might run slowly on your Aurora MySQL-Compatible DB Cluster:Your Amazon Relational Database Service (Amazon RDS) system resources are over utilized. This can happen because of high CPU, low memory, or a workload that exceeds what your DB instance type can handle.The database is locking and the resulting wait events are causing SELECT queries to perform poorly.The SELECT query is doing full-table scans on large tables, or the query lacks the necessary indexes.Your InnoDB history list length (HLL) has grown considerably due to long-running transactions.ResolutionMonitor your Amazon RDS system resources using metricsIt's a best practice to always monitor your CPU utilization and free memory on your Amazon Aurora cluster. While occasional CPU spikes are normal, consistently high CPU for long periods of time can make your SELECT queries run slowly. Use the following tools to determine how and where you are using your CPU:1.    Amazon CloudWatch metrics are the easiest way to monitor your CPU utilization. For more information on what metrics are available for Aurora, see CloudWatch metrics for Aurora.2.    Enhanced monitoring gives a detailed look at OS level metrics at lower granularity. The detailed breakdown shows how the processes are using your CPU.3.    Performance Insights accurately determines your DB load. Turn on Performance Insights for your DB instance, and then check if your load is exceeding the Max vCPU. You can also monitor your load bearing queries and SQLs by waits, and identify the users that cause the maximum waits.SELECT queries can also run slowly because of disk seeks. To minimize the disk I/O, the database engine tries to cache the block read from the disk. This means that next time the database needs the same block of data, that block is fetched from the memory rather than from the disk.Use these metrics to check if you are serving a particular query from disk or from memory:VolumeReadsIOPS: This metric is the number of billed volume level [disk] read operations. It's a best practice to make sure that this value is as low as possible.BufferCacheHitRatio: This metric is the percentage of requests that the buffer cache serves. It's a best practice to make sure that this value is as high as possible. If BufferCacheHitRatio drops and your SELECT statement is slow, then you're processing the query from underlying volumes.Another important resource to identify slow SELECT statements is the slow query log. Activate slow query logging for your DB cluster to record these queries and take action later. For the MySQL 5.6 compatible version, use the My SQL Performance Schema to monitor query performance on an ongoing basis.Identify deadlocks and wait eventsAmazon RDS locks the data in your database so that only one user session can write or update a row at any given time. Any other transaction that requires this row is kept on hold. In a shared lock, the write/update transactions are kept on hold while read transactions read the data. If a query is waiting to access a row that is locked by another query, then this can cause a deadlock.To identify deadlocks on your database, enable the innodb_print_all_deadlocks parameter in your parameter groups. Then, monitor the mysql-error.log from RDS console/CLI/API.Or, log in to MySQL with an admin account, and then run this command to identify deadlocks from the command output in the Latest Detected Deadlock section:mysql> SHOW ENGINE INNODB STATUS\G;Check if your query is using an indexIf a query doesn't have an index or does full table scans, then the query runs more slowly. Indexes help to speed up SELECT queries.To check if your query is using an index, use the EXPLAIN query. This is a helpful tool for troubleshooting slow queries. In the EXPLAIN output, check the table names, key used, and number of rows scanned during the query. If the output doesn't show any keys in use, then create an index on the columns used in the WHERE clause.If the table has the indexing required, check if the table statistics are up to date. Making sure that statistics are accurate means that the query optimizer uses the most selective indexes with the correct cardinality. This improves query performance.Check the history list length (HLL)InnoDB uses a concept called Multi-version-concurrency control (MVCC). MVCC maintains multiple copies of the same record to preserve read-consistency. This means that when you commit a transaction, then InnoDB purges the older copies. But when a transaction isn't committed for a long time due to growth of the undo segments, then history list length (HLL) increases. The InnoDB history list length represents the number of unflushed changes.If your workload demands multiple open or long-running transactions, then you can expect to see a high HLL on the database.Note: Long-running transactions aren't the only cause of HLL spikes. Even if the purge threads are unable to keep up with changes on the DB, HLL can remain high.If you don't monitor the size of the HLL, then performance regresses over time. An increasing size of the HLL can also cause higher resource consumption, slower and inconsistent SELECT statement performance, and an increase in storage. In extreme cases, this can lead to database outage.To check the history list length, run the following command:SHOW ENGINE INNODB STATUS;Output:------------ TRANSACTIONS ------------Trx id counter 26368570695Purge done for trx's n:o < 26168770192 undo n:o < 0 state: running but idle History list length 1839For Aurora MySQL, because of the nature of the volumes of the shared storage, the history list length is at Cluster level and not at the individual instance level. Connect to your writer and run the following query:SELECT server_id, IF(session_id = 'master_session_id', 'writer', 'reader') AS ROLE, replica_lag_in_msec,       oldest_read_view_trx_id , oldest_read_view_lsn       from mysql.ro_replica_status;This query helps you understand the replica lag between the reader nodes and the writer node. It also details the oldest LSN used by the DB instance to read from storage, and the oldest read view TRX ID of the DB instance. Use this information to check if one of the readers is holding an old read view (as compared to the engine InnoDB status on the writer).Note: Starting from Aurora MySQL 1.19 and 2.06, you can monitor HLL using the RollbackSegmentHistoryListLength metric in CloudWatch. Or, in older versions, use trx_rseg_history_len to check HLL using the following command:select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';If Performance Insights is activated for your Aurora MySQL instances, then you can check the RollbackSegmentHistoryListLength. Navigate to the writer Performance Insight and do the following:1.    Select Manage metrics, and then select Database metrics.2.    Select the trx_rseg_history_len metric, and then select Update graph.Use the following methods to resolve issues with HLL growth:If DML (writes) cause the HLL growth: Canceling or terminating this statement involves a rollback of the interrupted transaction. This takes a significant amount of time because all of the updates made until this point of time are being rolled back.If a READ causes the HLL growth: Terminate the query using mysql.rds_kill_query.Depending on how long the query is running, work with your DBA to check whether you can terminate the query using the stored procedure.It's a best practice to avoid growth by monitoring the HLL using these methods and to avoid open or long-running transactions on the database. Also, it's a best practice to commit the data in smaller batches.Important: Don’t reboot the DB cluster or instance. It is more efficient to purge the HLL when it can access the data in memory in the buffer pool. If you reboot the database, the survivable page cache might be lost. When that happens, data pages from the cluster volume must be read in order to purge the HLL. This is slower than doing it in memory and causes additional I/O billing costs.Related informationMonitor Amazon Aurora MySQL, Amazon RDS for MySQL and MariaDB logs with Amazon CloudWatchFollow"


Question: How do I migrate a Lambda function to another AWS account or Region using an AWS SAM file?

I need to move an AWS Lambda function from one AWS account (or AWS Region) to another. How can I do that using an AWS Serverless Application Model (AWS SAM) file?

Answer: "I need to move an AWS Lambda function from one AWS account (or AWS Region) to another. How can I do that using an AWS Serverless Application Model (AWS SAM) file?Short descriptionTo migrate a Lambda function to another AWS account or Region using an AWS SAM file, do the following:1.    Download the AWS SAM file for the Lambda function along with its deployment package.2.     Upload the Lambda function’s deployment package to an Amazon Simple Storage Service (Amazon S3) bucket in the AWS Region that you’re migrating the function to.3.    Use the AWS SAM file and AWS CloudFormation to deploy and manage a new Lambda function in another AWS account or Region.For more information, see Deploying a Hello World application.Note: You can also migrate a Lambda function using the Lambda console or the AWS Command Line Interface (AWS CLI).ResolutionDownload the Lambda function AWS SAM file and its deployment package1.    In the Lambda console, choose Functions on the left panel.2.    Choose the name of the Lambda function that you want to migrate.3.    In the Lambda function window, choose Actions, and then select Export Function.4.    In the Export function window, choose Download AWS SAM file.5.    After the AWS SAM file is downloaded, return to the Export function window and choose Download deployment package to download the deployment package.Upload the Lambda function’s deployment package to an Amazon S3 bucket located in the AWS Region that you’re migrating the function to1.    Sign in to the Amazon S3 console using the AWS account you want to migrate the Lambda function to.2.    In the Buckets list, choose the name of the S3 bucket that you want to upload your files to.3.    Choose Upload.4.    On the Upload page, choose Add files.5.    Choose the Lambda function’s deployment package that you downloaded. Then, choose Open.6.    Choose Upload.7.    Choose Files and folders, and then select the deployment package file name to open it.8.    In the Object Overview section of the file, note the S3 URI value, which is the S3 path location for the deployment package. Save the value for use in the next step.Use the AWS SAM file and AWS CloudFormation to deploy and manage a new Lambda function in another AWS account or Region1.    Open the Lambda function AWS SAM file that you downloaded.Example Lambda function AWS SAM file codeAWSTemplateFormatVersion: '2010-09-09'Transform: 'AWS::Serverless-2016-10-31'Description: An AWS Serverless Specification template describing your function.Resources:  MyLambdaFunction:    Type: 'AWS::Serverless::Function'    Properties:      Handler: lambda_function.lambda_handler      Runtime: python3.6      CodeUri: .                #S3 bucket Link      Description: ''      MemorySize: 128      Timeout: 6      Role: 'arn:aws:iam::733097455070:role/service-role/FirstLambdaPolicy'    #Replace      Environment:        Variables:          homelocation: .tmp      Tags:        sampleTag: test      Tracing: Active2.    After CodeUri, replace the dot (.) with the S3 path location of the Lambda deployment package that you retrieved in the previous step.Important: Make sure that the IAM user that creates the CloudFormation stack has 's3:GetObject' permission for this S3 object.3.    For migrating a function to another AWS account, do the following:For the Role: value, delete the existing IAM role ARN. Then, replace the value with the IAM role ARN in the second AWS account.For functions with layers, add a permission in the layer for the second AWS account that allows that layer to use the first account's layer. Or, replace the Lambda layer ARN in the AWS SAM file with the Lambda layer ARN in the second AWS account.-or-For migrating a function to another AWS Region, do the following:For the Role: value, continue using the existing IAM role ARN.For functions with layers, replace the Lambda layer ARN with the Lambda layer ARN in the second AWS Region.Important: For functions in a virtual private cloud (VPC), replace the values for SecurityGroupdIds and SubnetIds with the resources in the second AWS account or Region.4.    For functions with event sources, remove the code for recreating the event sources in the second AWS account or Region from the AWS SAM file. Then, replace the values after Events: with the event sources in the second AWS account or Region.5.    Use the edited AWS SAM file to create an AWS CloudFormation stack in the second AWS account or Region you want to migrate the function to.Note: After you create the AWS CloudFormation stack, the migrated Lambda function appears in your Lambda console.Follow"


Question: How can I share a file or folder with WorkDocs?

I want to share an Amazon WorkDocs file or folder.

Answer: "I want to share an Amazon WorkDocs file or folder.ResolutionYou can share a file or folder either by sending an invite to a user or group, or by sharing a link. The best sharing method for you depends on who you want to share the file or folder with, and on your WorkDocs configuration.Note: You can't share a file or folder with an email distribution list.To view the existing access permissions for a file or folder, select or open the file or folder, and then choose Share, Permissions.Invite peopleThe Invite people method allows you to share a file or folder with a user or group within your organization. The invitees receive an email with a web link to the shared file or folder.Important: If your administrator configured WorkDocs with AD Connector, then you can invite only users or groups within the same directory as the file or folder. However, you can share a link to a file with someone outside of the directory. See the Share a link section below.For instructions to invite people to share a file or folder, see Sharing by invite.Share a linkThe Share a link share method allows you to share a file link with someone outside of your WorkDocs organization. You can also share a link to a file or folder with anyone within your WorkDocs organization.Note: Folder links can't be shared outside of your organization.For instructions to share a link to a file or folder, see Sharing a link.Related informationSharing files and foldersRemoving share permissionsFollow"


Question: How do I troubleshoot issues connecting to my EC2 instance using EC2 Instance Connect?

"I'm receiving the following error when trying to connect to my Amazon Elastic Compute Cloud (Amazon EC2) instance using Amazon EC2 Instance Connect:"There was a problem setting up the instance connectionLog in failed. If this instance has just started up, try again in a minute or two."How can I troubleshoot this?"

Answer: "I'm receiving the following error when trying to connect to my Amazon Elastic Compute Cloud (Amazon EC2) instance using Amazon EC2 Instance Connect:"There was a problem setting up the instance connectionLog in failed. If this instance has just started up, try again in a minute or two."How can I troubleshoot this?Short descriptionThe following are common reasons why EC2 Instance Connect might not work as expected:EC2 Instance Connect doesn't support the OS distribution.The EC2 Instance Connect package isn't installed on the instance.There are missing or incorrect AWS Identity and Access Management (IAM) policies or permissions.Security groups associated with the instance don't have EC2 Instance Connect service IPs listed.To connect using the browser-based client, your instance must have a public IPv4 address. If your instance doesn't have a public IP address, connect using the EC2 Instance Connect Command Line Interface (CLI) from a machine within the same VPC. For more information, see the Limitations section in Connect using EC2 Instance Connect.Note: If you’ve turned on the EC2 Serial Console for Linux, you can use it to troubleshoot supported Nitro-based instance types. The serial console helps you troubleshoot boot issues, network configuration, and SSH configuration issues. The serial console connects to your instance without requiring a working network connection. You can access the serial console using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).Before using the serial console, you must grant access to it at the account level and create IAM policies granting access to your IAM users. Also, every instance using the serial console must include at least one password-based user. If your instance is unreachable and you haven’t configured access to the serial console, you can follow the instructions for manually connecting to the instance provided in the following article links.For information on configuring EC2 Serial Console for Linux, see Configure access to the EC2 Serial Console.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Resolution1.    Verify that EC2 Instance Connect supports your instance's Linux distribution.2.    Verify that your supported instance has the EC2 Instance Connect package installed.3.    Verify that the IAM user trying to use EC2 Instance Connect has permission to push the public key to the instance.4.    Verify that the instance's security group rules list EC2 Instance Connect IPs:Browser-based SSH connectionsBrowser-based SSH connections require that your instance's security group inbound rules allow EC2 Instance Connect access to SSH on TCP port 22.EC2 Instance Connect uses specific IP ranges for browser-based SSH connections to your instance. These IP ranges differ between AWS Regions. To find the AWS IP address range for EC2 Instance Connect in a specific Region, use the following commands:Note: In the following commands, replaceus-east-1 with the AWS Region of your instance. Be sure your instance is in a Regionsupported by EC2 Instance Connect.Windows (requires Windows PowerShell for AWS)PS C:\> Get-AWSPublicIpAddressRange -Region us-east-1 -ServiceKey EC2_INSTANCE_CONNECT | select IpPrefixLinux (requires curl and jq)$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="us-east-1") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix'Update your security group inbound rules to allow TCP port 22 access from the IP range returned by the preceding commands.EC2 Instance Connect CLI connectionsUpdate your security group inbound rules to allow TCP port 22 access from your IP.Related informationSet up EC2 Instance ConnectConnect to your Linux instance using EC2 Instance ConnectHow can I connect to my Amazon EC2 instance if I lost my SSH key pair after its initial launch?Why can't I connect to my Amazon EC2 Linux instance using SSH?Follow"


Question: How do I start using Trusted Advisor?

I want to use the AWS Trusted Advisor service. How do I get started?

Answer: "I want to use the AWS Trusted Advisor service. How do I get started?Short descriptionAWS Trusted Advisor provides a set of best practice checks and recommendations to help you reduce costs, increase availability and performance, and improve security.Trusted Advisor inspects your resources across all AWS Regions and presents a summary of check results. The status types for the check results are as follows:No problems detected (check mark in a green square)Investigation recommended (exclamation mark in a yellow triangle)Action recommended (exclamation mark in a red circle)ResolutionExplore the Trusted Advisor consoleOpen the Trusted Advisor console to view the check results across the following five categories in the Trusted Advisor Dashboard:Cost OptimizationPerformanceSecurityFault ToleranceService LimitsPotential monthly savings indicates the total amount that you can save each month, if you act on all recommendations across all the checks in the pillar.The What's New section shows information on latest checks, new features, and updates to the existing checks across different categories.The Recent Changes section displays the status changes from recent checks.If you have an AWS Developer or Basic Support plan, then you have access to all the checks in Service Limits and the six Security checks only through the console.If you have an AWS Business or Enterprise Support plan, then you have access to AWS Support API and AWS Trusted Advisor in addition to all the checks.You can use the AWS Support API to pull the check results into your own tools for analysis and tracking purposes.You can use Amazon CloudWatch to set an alarm to notify you based on Trusted Advisor metrics. You can use Amazon CloudWatch Events to detect and react to the changes in the Trusted Advisor checks.Review your Trusted Advisor recommendationsTo access the recommendations against each of the checks, choose one of the following options:Choose a category in the navigation pane to see all the related checks. For example, choose Cost Optimization to see all the cost optimization checks.To see more details for your check, choose the Expand/Collapse icon next to your check.--or--To download an Excel spreadsheet with the same level of detail, choose the Download icon. This Excel spreadsheet has a tab for each check with check-level metadata.Set your preferences for resource analysis and email notificationsTo disable Trusted Advisor from accessing your resources and performing the checks:Open the Trusted Advisor console.From the navigation pane, choose Preferences.Choose Disable Trusted Advisor.To enable weekly email notifications from Trusted Advisor:Open the Trusted Advisor console.From the navigation pane, choose Preferences.For Recipients, select the appropriate option.For Notification Language, choose a language.Choose Save Email Preferences.Related informationAWS Trusted Advisor check referenceFollow"


Question: Does Amazon RDS support IPv6 addressing?

Can I use Internet Protocol version 6 (IPv6) addressing with Amazon Relational Database Service (Amazon RDS)?

Answer: "Can I use Internet Protocol version 6 (IPv6) addressing with Amazon Relational Database Service (Amazon RDS)?ResolutionIPv6 is available in all Regions, and you can add IPv6 addresses to both a virtual private cloud (VPC) and its subnets. Amazon RDS supports IPv6 with dual-stack mode. You can work with IPv6 on Amazon RDS when you create new instances or modify existing instances. When using Amazon RDS with IPv6, keep the following in mind:The range of IPv6 addresses are assigned from Amazon's pool of available IPs, and can't be selected manually. Make sure that outbound rules for security groups and ACLs are configured accordingly.When running on a dual-stack mode, Amazon RDS doesn't allow public accessibility over an internet gateway.All the subnets of the database's subnet group must have IPv4 and IPv6 CIDRs attached to them to support dual-stack mode.Don't delete subnets or CIDR disassociation at the VPC level. This can cause your RDS instance to become network incompatible if the DB subnet group stops supporting the DUAL network type.For more information about RDS with IP addressing, see Amazon RDS IP addressing.Related informationIPv6 addressing with Amazon RDSMigrate existing VPCs from IPv4 to IPv6IPv6 addressesFollow"


Question: How do I change the volume size or compute type of a WorkSpace?

I want to change the volume size or compute type of my WorkSpace in Amazon WorkSpaces. How can I do this?

Answer: "I want to change the volume size or compute type of my WorkSpace in Amazon WorkSpaces. How can I do this?ResolutionTo change the WorkSpace volume size or compute type, see Modify a WorkSpace.After you modify a WorkSpace using the WorkSpaces console, you receive the message "modification of your WorkSpace was successfully initiated." The WorkSpace reboots after you request the change. To verify that the volume size or compute type is changed, choose Refresh Data. Expect a delay of 10-15 minutes for a volume size change to become visible.If you want users to be able to access their WorkSpaces when the disk size increase is running, then verify the status of the WorkSpaces. Make sure that the WorkSpaces have a status of AVAILABLE instead of STOPPED before you resize the WorkSpace volumes. If the WorkSpaces are STOPPED, then they can't be started when the disk size increase is in progress.Note the following timelines and restrictions when changing the volume size or compute type:Review the sizing requirements for changing the volume size.You can request a WorkSpace bundle type increase one time every hour, or decrease one time every 30 days.You can request a volume increase one time every 6 hours.You can't decrease the size of root and user volumes after the WorkSpace is launched.You can't modify both the root and user volume simultaneously. To modify both, first follow the previously mentioned process for the root volume, and then repeat the process for the user volume.WorkSpaces that were created earlier than December 2016 don't support resize operations. Rebuild the WorkSpace to change the volume type to SSD. Then, resize the WorkSpace storage.Related informationAmazon WorkSpaces FAQsAmazon WorkSpaces featuresFollow"


Question: How do I collect logs from my Amazon ECS container instance automatically?

"I'm troubleshooting my Amazon Elastic Container Service (Amazon ECS) environment or opening a case with AWS Support, and I need to collect various logs from my container instances."

Answer: "I'm troubleshooting my Amazon Elastic Container Service (Amazon ECS) environment or opening a case with AWS Support, and I need to collect various logs from my container instances.Short descriptionThe Amazon ECS logs collector is a script that collects logs automatically from your container instance. The script collects general operating system logs as well as Docker and Amazon ECS container agent logs. Then, the script compresses and archives the logs into a single file that you can share when you're troubleshooting an issue.You can also use AWSSupport-CollectECSInstanceLogs runbook in AWS Systems Manager Automation to collect logs from your ECS instance. The runbook allows you to upload the logs to an S3 bucket that you created. You must provide the location of the S3 bucket in the LogDestination input parameter.Note: AWSSupport-CollectECSInstanceLogs doesn't support debug mode. For more information, see Run an automation.ResolutionDownload and run the Amazon ECS logs collector for Linux1.    Connect to your container instance.2.    To confirm that curl is installed, run the following command:curl --versionThe command output should be similar to the following:curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3Note: If the command doesn't return the expected results, install the curl package.3.    To download the Amazon ECS logs collector script, run the following command:curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh4.    To collect the logs and create an archive with the script, run the following command:[ec2-user ~]$ sudo bash ./ecs-logs-collector.shAfter you run the script, you can examine the collected logs in the collect folder that was created by the script. In the folder, you can find the collect.tgz file, which is a compressed archive of all the logs.Run the Amazon ECS logs collector in debug mode for LinuxIf the logs don't provide all the information that you need, you can turn on debug logging for the Docker daemon and Amazon ECS container agent with the --mode=enable-debug option. This option allows the script to collect the logs before turning on debug mode. The script restarts the Docker daemon and Amazon ECS agent, and then terminates all containers running on the instance. Before running the following command, consider draining the container instance and moving any important tasks to other container instances. For more information, see Container instance draining.To turn on debug mode when you run the script, run the following command:[ec2-user ~]$ sudo bash ./ecs-logs-collector.sh --mode=enable-debugDownload and run the Amazon ECS logs collector for Windows1.    Connect to your container instance.2.    To download the script, open Windows PowerShell with administrator privileges, and then run the following command:Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps13.    In the same window, run the following script to collect the logs and create the archive:.\ecs-logs-collector.ps1After you run the script, you can examine the collected logs in the collect folder that were created by the script. In the folder, you can find the collect.tgz file, which is a compressed archive of all the logs.Run the Amazon ECS logs collector in debug mode for WindowsIf the logs don't provide all the information that you need, you can turn on debug logging for the Docker daemon and Amazon ECS container agent with the -RunMode debug option. This option allows the script to collect the logs before turning on debug mode. The script restarts the Docker daemon and Amazon ECS agent, and then terminates all containers running on the instance. Before running the following command, consider draining the container instance and moving any important tasks to other container instances. For more information, see Container instance draining.To turrn on debug mode when you run the script, run the following command using Windows PowerShell with administrator privileges:.\ecs-logs-collector.ps1 -RunMode debugFollow"


Question: How can I get notified when IAM changes are made to my AWS account?

"I created an Amazon EventBridge rule to notify me when changes are made to AWS Identity and Access Management (IAM) identities or API calls. However, the event rule isn't initiating when changes are made to IAM."

Answer: "I created an Amazon EventBridge rule to notify me when changes are made to AWS Identity and Access Management (IAM) identities or API calls. However, the event rule isn't initiating when changes are made to IAM.Short descriptionCreate an EventBridge rule with an event pattern that matches a specific IAM API call or multiple IAM API calls. Then, associate the rule with an Amazon Simple Notification Service (Amazon SNS) topic. When the rule runs, an SNS notification is sent to the corresponding subscriptions.ResolutionIf you haven't already created an Amazon SNS topic, then follow the instructions for getting started with Amazon SNS.Important:The IAM service and the related AWS API calls are available only in the US East (N. Virginia) Region. This means that the EventBridge rule must be in the US East (N. Virginia) Region.This resolution uses AWS CloudTrail. For CloudTrail to send API calls to EventBridge, a trail must exist in the same Region as the EventBridge rule. Make sure that you configured the trail's management events as Write-only or All. For more information, see Read-only and write-only events.The following example custom event pattern starts a notification when CreateUser and DeleteUser API calls are made in your account.1.    Open the EventBridge console in the US East (N. Virginia) Region.2.    In the navigation pane, choose Rules, and then select Create rule.3.    Enter a Name and Description for the rule.4.    For Event bus, select the default AWS event bus. When IAM emits an event, it always goes to your account’s default event bus.5.    For Rule type, choose Rule with an event pattern, and the select Next.6.    For Event source, choose AWS events or EventBridge partner events.7.    Under Event pattern, do the following:        In the Event source dropdown list, choose AWS services.        In the AWS service dropdown list, choose IAM.        In the Event type dropdown list, choose AWS API Call via CloudTrail.        To start the rule for specific API calls, choose Specific operation(s).        In the text box, enter the name of an API call that you want to receive a notification for. For example, CreateUser.        To add more API calls, select Add.8.    Choose Edit pattern below the Event pattern preview box.9.    Copy and paste the following example template into the event pattern preview pane, and then choose Save.{  "source": [    "aws.iam"  ],  "detail-type": [    "AWS API Call via CloudTrail"  ],  "detail": {    "eventSource": [      "iam.amazonaws.com"    ],    "eventName": [      "CreateUser",      "DeleteUser"    ]  }}10.    Select Next.11.    For Target types, choose AWS service.13.    For Select a target, choose SNS topic.14.    In the Topic dropdown list, choose your SNS topic.        (Optional) ChooseAdd another target to add another target for this rule.15.    Select Next.         (Optional) Enter one or more tags for the rule. For more information, see Amazon EventBridge tags.16.    Select Next.17.    Review the details of the rule, and then select Create rule.Related informationHow can I be notified when changes are made to Route 53 hosted zone records?How can I configure an EventBridge rule for GuardDuty to send custom SNS notifications if specific AWS service event types trigger?My rule matches AWS global service API calls but it didn't runFollow"


Question: I host a website on an EC2 instance. How do I allow my users to connect on HTTP (80) or HTTPS (443)?

I host my website on an Amazon Elastic Compute Cloud (Amazon EC2) instance. I want users to connect to my website on HTTP (port 80) or HTTPS (port 443). How can I do that?

Answer: "I host my website on an Amazon Elastic Compute Cloud (Amazon EC2) instance. I want users to connect to my website on HTTP (port 80) or HTTPS (port 443). How can I do that?ResolutionTo allow traffic on port 80 and 443, you must configure the associated security group and network access control list (network ACL).Security group rulesFor HTTP traffic, add an inbound rule on port 80 from the source address 0.0.0.0/0.For HTTPS traffic, add an inbound rule on port 443 from the source address 0.0.0.0/0.These inbound rules allow traffic from IPv4 addresses. To allow IPv6 traffic, add inbound rules on the same ports from the source address ::/0. For more information on creating or modifying security groups, see Control traffic to resources using security groups.Security groups are stateful, so the return traffic from the instance to users is allowed automatically. You don't need to modify the security group's outbound rules.Note: The following example shows the security group rules for allowing IPv4 and IPv6 traffic on TCP port 80 (HTTP) and 443 (HTTPS). Determine if other sources of traffic, such as SSH or RDP to log in to the instance, must be allowed for your use case. Then, make sure that your SG has the relevant inbound rules to allow the needed traffic.Inbound rulesTypeProtocolPort RangeSourceHTTP (80)TCP (6)800.0.0.0/0HTTP (80)TCP (6)80::/0HTTPS (443)TCP (6)4430.0.0.0/0HTTPS (443)TCP (6)443::/0Network ACLThe default network ACL allows all inbound and outbound IPv4 traffic. If your users connect over IPv6 and your Amazon Virtual Private Cloud (Amazon VPC) has an associated IPv6 CIDR block, then your default network ACL also automatically adds rules allowing all inbound and outbound IPv6 traffic. However, if you use a custom network ACL with more restrictive rules, then you must explicitly allow traffic on port 80 and 443.Network ACLs are stateless, so you must add both inbound and outbound rules to allow the connection to your website. For more information on modifying network ACL rules, see Control traffic to subnets using Network ACLs.Note: The following example shows a custom network ACL that allows traffic on TCP port 80 (HTTP) and 443 (HTTPS). Network ACLs are applied to all resources in an entire subnet, not just a single EC2 instance. In the example configuration, all traffic to and from resources in the same subnet is blocked, except on destination port 80 and 443. Determine if other sources of traffic, such as SSH or RDP to log in to the instance, must be allowed for your use case. Then, make sure that you have the relevant inbound rules to allow the needed traffic.Inbound rulesRule #TypeProtocolPort RangeSourceAllow/Deny100HTTP (80)TCP (6)800.0.0.0/0ALLOW101HTTPS (443)TCP (6)4430.0.0.0/0ALLOW102HTTP (80)TCP (6)80::/0ALLOW103HTTPS (443)TCP (6)443::/0ALLOW*ALL TrafficALLALL::/0DENY*ALL TrafficALLALL0.0.0.0/0DENYOutbound rulesRule #TypeProtocolPort RangeDestinationAllow/Deny100Custom TCP RuleTCP (6)1024-655350.0.0.0/0ALLOW101Custom TCP RuleTCP (6)1024-65535::/0ALLOW*ALL TrafficALLALL::/0DENY*ALL TrafficALLALL0.0.0.0/0DENYTroubleshooting a connection refused errorA connection refused error means that the connection request is routed to the instance but isn't received from the service on the specified port. If Host A initiates a TCP connection to Host B and receives a connection refused error, then that error means the following:First, Host A sent a TCP SYN packet to Host B.Then, Host B sent a TCP RST packet in reply to Host A.If you encounter this error, even after allowing TCP ports 80 and 443 in the Security group and Network ACL, then troubleshoot the following:The service daemon, such as httpd (Apache), isn't running or is in a stopped state.To troubleshoot, check if the service is in the running state in the EC2 instance.The service is listening on a wrong port.To troubleshoot, check if the EC2 instance is listening on the required TCP port (80/443).The port is blocked by a firewall.To troubleshoot, check if an OS-level firewall in the EC2 instance is blocking incoming TCP traffic on the required port.Follow"


Question: How do I mount an Amazon EFS volume to an application directory in an Elastic Beanstalk environment?

I want to mount an Amazon Elastic File System (Amazon EFS) volume to an application directory in an AWS Elastic Beanstalk environment.

Answer: "I want to mount an Amazon Elastic File System (Amazon EFS) volume to an application directory in an AWS Elastic Beanstalk environment.Short descriptionThe following resolution provides general instructions for mounting an Amazon EFS volume on platforms based on Amazon Linux 1, using the PHP solution stack as an example.If you're using another solution stack, follow the same steps, but choose the correct application directory and staging directory for your solution stack from the following options:-----------------------------------------------------Solution stack             Application directory                    Staging directoryNodejs                     /var/app/current                         /tmp/deployment/applicationPHP                        /var/app/current                         /var/app/ondeckRuby (Passenger)           /var/app/current                         /var/app/ondeckRuby (Puma)                /var/app/current                         /var/app/ondeckJava with Tomcat           /usr/share/tomcat*/webapps/ROOT          /tmp/deployment/application/ROOTJava SE                    /var/app/current                         /var/app/stagingPython                     /opt/python/current/app                  /opt/python/ondeck/appGo                         /var/app/current                         /var/app/stagingSingle Container Docker    /var/app/current                         /var/app/stagingMulti-Container Docker     /var/app/current                         /var/app/staging-----------------------------------------------------Important: You can't mount an Amazon EFS volume directly to the application directory because the contents of /var/app/current are moved to /var/app/current.old whenever you deploy an Elastic Beanstalk application. The current deployed source bundle is moved to the application directory. If you mount the Amazon EFS volume to /var/app/current, then that volume is moved to /var/app/current.old after the deployment is completed. For example, see the following eb-activity.log output:===============================[2020-02-12T02:28:18.237Z] INFO  [3159]  - [Application deployment Sample Application@1/StartupStage1/AppDeployEnactHook/01_flip.sh] : Starting activity...[2020-02-12T02:28:18.431Z] INFO  [3159]  - [Application deployment Sample Application@1/StartupStage1/AppDeployEnactHook/01_flip.sh] : Completed activity. Result:  ++ /opt/elasticbeanstalk/bin/get-config container -k app_staging_dir  + EB_APP_STAGING_DIR=/var/app/ondeck  ++ /opt/elasticbeanstalk/bin/get-config container -k app_deploy_dir  + EB_APP_DEPLOY_DIR=/var/app/current  + '[' -d /var/app/current ']'  + mv /var/app/current /var/app/current.old  + mv /var/app/ondeck /var/app/current  + nohup rm -rf /var/app/current.old===============================Resolution1.    Confirm that your source bundle is unzipped in the staging directory. See the following example eb-activity.log output:===============================[2020-02-12T02:28:16.336Z] INFO  [3159]  - [Application deployment Sample Application@1/StartupStage0/AppDeployPreHook/01_unzip.sh] : Starting activity...[2020-02-12T02:28:16.631Z] INFO  [3159]  - [Application deployment Sample Application@1/StartupStage0/AppDeployPreHook/01_unzip.sh] : Completed activity. Result:  ++ /opt/elasticbeanstalk/bin/get-config container -k app_user  + EB_APP_USER=webapp  ++ /opt/elasticbeanstalk/bin/get-config container -k app_staging_dir  + EB_APP_STAGING_DIR=/var/app/ondeck  ++ /opt/elasticbeanstalk/bin/get-config container -k source_bundle  + EB_SOURCE_BUNDLE=/opt/elasticbeanstalk/deploy/appsource/source_bundle  + rm -rf /var/app/ondeck  + /usr/bin/unzip -d /var/app/ondeck /opt/elasticbeanstalk/deploy/appsource/source_bundle  Archive:  /opt/elasticbeanstalk/deploy/appsource/source_bundle     creating: /var/app/ondeck/.ebextensions/    inflating: /var/app/ondeck/.ebextensions/logging.config      inflating: /var/app/ondeck/scheduled.php      inflating: /var/app/ondeck/index.php      inflating: /var/app/ondeck/cron.yaml      inflating: /var/app/ondeck/styles.css     extracting: /var/app/ondeck/logo_aws_reduced.gif    + chown -R webapp:webapp /var/app/ondeck  + chmod 775 /var/app/ondeck===============================Note: All the appdeploy pre hooks in /opt/elasticbeanstalk/hooks/appdeploy/pre/ and .ebextensions are run in the staging directory.2.    Create a .ebextensions folder in the root directory of the source bundle.3.    To mount an Amazon EFS volume to a specific directory (for example, /efs), add a formatted configuration file (YAML or JSON) to your directory.4.    To mount your Amazon EFS volume to an application directory, you must create a symlink to the staging directory. To create a symlink from /efs that points to the staging directory, use container_commands to create a .config file in your .ebextensions folder. For example:container_commands:  01_symlink:    command: ln -s /efs /var/app/ondeck/Note: When appdeploy enact hooks are run during a deployment in an Elastic Beanstalk environment, the contents of the staging directory are moved to the application directory. For example, in a PHP solution, the flip.sh script moves the contents of the staging directory to the application directory. The flip.sh script is the first script of AppDeployEnactHook in /opt/elasticbeanstalk/hooks/appdeploy/enact/.Follow"


Question: How do I detect and release locks in Amazon Redshift?

There are table locks blocking my queries in Amazon Redshift. How do I find them and resolve this?

Answer: "There are table locks blocking my queries in Amazon Redshift. How do I find them and resolve this?Short descriptionLocking is a protection mechanism that controls how many sessions can access a table at the same time. Locking also determines which operations can be performed in those sessions. Most relational databases use row-level locks. However, Amazon Redshift uses table-level locks. You might experience locking conflicts if you perform frequent DDL statements on user tables or DML queries.Amazon Redshift has three lock modes:AccessExclusiveLock: Acquired primarily during DDL operations, such as ALTER TABLE, DROP, or TRUNCATE. AccessExclusiveLock blocks all other locking attempts.AccessShareLock: Acquired during UNLOAD, SELECT, UPDATE, or DELETE operations. AccessShareLock blocks only AccessExclusiveLock attempts. AccessShareLock doesn't block other sessions that are trying to read or write on the table.ShareRowExclusiveLock: Acquired during COPY, INSERT, UPDATE, or DELETE operations. ShareRowExclusiveLock blocks AccessExclusiveLock and other ShareRowExclusiveLock attempts, but doesn't block AccessShareLock attempts.When a query or transaction acquires a lock on a table, the lock remains for the duration of the query or transaction. Other queries or transactions that are waiting to acquire the same lock are blocked except for AccessShareLock. For more information about why a query might hang, see Query hangs.To solve a locking problem, identify the session (PID) that is holding the lock and then terminate the session. If the session doesn't terminate, reboot your cluster.ResolutionRun a query to identify sessions that are holding locks:select a.txn_owner, a.txn_db, a.xid, a.pid, a.txn_start, a.lock_mode, a.relation as table_id,nvl(trim(c."name"),d.relname) as tablename, a.granted,b.pid as blocking_pid ,datediff(s,a.txn_start,getdate())/86400||' days '||datediff(s,a.txn_start,getdate())%86400/3600||' hrs '||datediff(s,a.txn_start,getdate())%3600/60||' mins '||datediff(s,a.txn_start,getdate())%60||' secs' as txn_durationfrom svv_transactions a left join (select pid,relation,granted from pg_locks group by 1,2,3) b on a.relation=b.relation and a.granted='f' and b.granted='t' left join (select * from stv_tbl_perm where slice=0) c on a.relation=c.id left join pg_class d on a.relation=d.oidwhere  a.relation is not null;The output looks similar to:txn_owner | txn_db |   xid   |  pid  |         txn_start          |      lock_mode      | table_id | tablename | granted | blocking_pid |        txn_duration         | ----------+--------+---------+-------+----------------------------+---------------------+----------+-----------+---------+--------------+-----------------------------+ usr1     | db1    | 5559898 | 19813 | 2018-06-30 10:51:57.485722 | AccessExclusiveLock |   351959 | lineorder | t       |              | 0 days 0 hrs 0 mins 52 secs | usr1     | db1    | 5559927 | 20450 | 2018-06-30 10:52:19.761199 | AccessShareLock     |   351959 | lineorder | f       |        19813 | 0 days 0 hrs 0 mins 30 secs | usr1     | db1    | 5559898 | 19813 | 2018-06-30 10:51:57.485722 | AccessShareLock     |   351959 | lineorder | t       |              | 0 days 0 hrs 0 mins 52 secs |If the result in the granted column is f (false), then a transaction in another session is holding the lock. The blocking_pid column shows the process ID of the session that's holding the lock. In this example, PID 19813 is holding the lock.To release a lock, wait for the transaction that's holding the lock to finish. You can also manually terminate the session by running the following command:select pg_terminate_backend(PID);Terminating a PID rolls back all running transactions and releases all locks in the session. The locks are then claimed by the other transactions that are waiting to acquire the lock.Note: The value "1" returned by PG_TERMINATE_BACKEND(PID) typically indicates a successful termination request to the PID. However, this doesn't guarantee that the PID actually was terminated. In some cases, the PID can't be determined depending on its internal status. Therefore, it's a best practice to also check STV_SESSIONS (and other relevant system tables) to confirm whether the PID was actually terminated.If PG_TERMINATE_BACKEND(PID) doesn't successfully terminate the session, then reboot the cluster to terminate the process. The reboot can be performed by a cluster reboot through the Amazon Redshift console or through a database reboot using REBOOT_CLUSTER.Related informationLOCK (Amazon Redshift)Potential deadlock situation for concurrent write transactionsFollow"


Question: How can I resolve the IAM trust policy error "Failed to update trust policy. Invalid principal in policy"?

I receive the error "Failed to update trust policy. Invalid principal in policy." when trying to edit the trust policy for my AWS Identity and Access Management (IAM) role using the AWS Management Console.

Answer: "I receive the error "Failed to update trust policy. Invalid principal in policy." when trying to edit the trust policy for my AWS Identity and Access Management (IAM) role using the AWS Management Console.Short descriptionThis error message indicates that the value of a Principal element in your IAM trust policy isn't valid. To resolve this error, confirm the following:Your IAM role trust policy uses supported values with correct formatting for the Principal element.If the IAM role trust policy uses IAM identities (users, user groups, and roles) as principals, then confirm that the user or role wasn't deleted.Note: AWS GovCloud (US) accounts might also receive this error if the standard AWS account tries to add the AWS GovCloud (US) account number. You can't create a role to delegate access between an AWS GovCloud (US) account and a standard AWS account. For more information, see How IAM Differs for AWS GovCloud (US).ResolutionVerify the supported values for the Principal elementThe Principal element in the IAM trust policy of your role must include the following supported values.1.    Make sure that the IAM policy includes the correct AWS 12-digit AWS account ID similar to the following:"Principal": {"AWS": "123456789012"}Note: The AWS account can also be specified using the root user Amazon Resource Name (ARN). For example, arn:aws:iam::123456789012:root.2.    If the IAM trust policy principals are IAM users, roles, or federated users, then the entire ARN must be specified similar to the following:"Principal": {  "AWS": [    "arn:aws:iam::123456789012:user/user-name",    "arn:aws:iam::123456789012:role/role-name",    "arn:aws:sts::123456789012:assumed-role/role-name/role-session-name",    "arn:aws:sts::123456789012:federated-user/user-name"  ]}3.    If the IAM trust policy includes wildcard, then follow these guidelines.Note: You can't use a wildcard "*" to match part of a principal name or ARN.The following example has an incorrect use of a wildcard in an IAM trust policy:"Principal": {  "AWS": "arn:aws:iam::123456789012:user/user-*"}To match part of principal name using a wildcard, use a Condition element with the global condition key aws:PrincipalArn. Then, specify an ARN with the wildcard.To specify identities from all AWS accounts, use a wildcard similar to the following:"Principal": {  "AWS": "*"}Important: You can use a wildcard in the Principal element with an Allow effect in a trust policy. However, this allows any IAM user, assumed role session, or federated user in any AWS account in the same partition to access your role. IAM user and role principals within your AWS account don't require any other permissions. Principals in other AWS accounts must have identity-based permissions to assume your IAM role.This method doesn't allow web identity session principals, SAML session principals, or service principals to access your resources.As a best practice, use this method only with the Condition element and a condition key such as aws:PrincipalArn to limit permissions. For example, your file might look similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "*"      },      "Action": "sts:AssumeRole",      "Condition": {        "StringLike": {          "aws:PrincipalArn": "arn:aws:iam::123456789012:user/user-*"        }      }    }  ]}This example trust policy uses the aws:PrincipalArn condition key to permit only users with matching user names to assume the IAM role.4.    If your IAM role is an AWS service role, then the entire service principal must be specified similar to the following:"Principal": {  "Service": "ec2.amazonaws.com"}5.    You can use SAML session principals with an external SAML identity provider to authenticate IAM users. The trust policy of the IAM role must have a Principal element similar to the following:"Principal": {  "Federated": "arn:aws:iam::123456789012:saml-provider/provider-name"}6.    You can use web identity session principals to authenticate IAM users. The trust policy of the IAM role that provides access must have a Principal element similar to the following:"Principal": {   "Federated": "cognito-identity.amazonaws.com" }7.    If you use different principal types within a single statement, then format the IAM trust policy similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::123456789012:user/user-name",        "Service": "ec2.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}The IAM user or role must be an existing identityIf the IAM role trust policy uses IAM users or roles as principals, then confirm that those IAM identities aren't deleted. The "Invalid principal in policy" error occurs if you modify the IAM trust policy and the principal was deleted.Note: If the principal was deleted, note the unique ID of the principal in the IAM trust policy, and not the ARN.Related informationHow can I use AWS Identity and Access Management (IAM) to allow user access to resources?How do I access resources in another AWS account using AWS IAM?Why is there an unknown principal format in my IAM resource-based policy?Follow"


Question: How do I push VPC flow logs to Splunk using Amazon Kinesis Firehose?

I want to improve the integration of my AWS data with Splunk when pushing data from AWS sources to a Splunk cluster.

Answer: "I want to improve the integration of my AWS data with Splunk when pushing data from AWS sources to a Splunk cluster.ResolutionNote: Kinesis Data Firehose doesn't support Application Load Balancers or Network Load Balancers. Instead, use a Classic Load Balancer. Make sure to allow duration-based sticky sessions with cookie expiration deactivated. For more information about troubleshooting delivery stream issues with Splunk endpoints, see Data not delivered to Splunk.PrerequisitesSet up a reachable Splunk HEC HTTP Event Collector (HEC) instance. For more information, see the Splunk documentation and Splunk Enterprise on AWS.Configure the Splunk data inputs with the HEC on Splunk Web.Create a new HEC endpoint with a new token for configuring the data stream. For more information, see Set up and use HTTP Event Collector in Splunk Web (from the Splunk website). Make sure to choose the option Enable indexer acknowledgement.Install the Splunk add-on for Amazon Kinesis Data Firehose (from the Splunkbase website).Create a Kinesis Data Firehose delivery stream1.    Create your delivery stream. For Source, choose Direct PUT.2.    For Destination, choose Splunk.3.    Enter a delivery stream name.Configure record transformation with AWS Lambda1.    Configure record transformation.Note: Under Transform source records with AWS Lambda, choose Enabled for Record transformation. CloudWatch sends the logs as compressed .gzip files, and Amazon Kinesis must extract these files before you can use them.2.    For Lambda function, choose Create new.3.    On the Choose Lambda blueprint window, for Lambda blueprint, choose Kinesis Firehose CloudWatch Logs Processor.4.    Choose the new tab that opens in your browser to create the new Lambda function:For Name, enter a name for the Lambda function.For Role, choose Create a custom role.5.     Choose the new tab that opens in your browser to create a new AWS Identity and Access Management (IAM) role. For Role Name, make sure that the name is lambda_basic_execution.6.    Choose Allow to create the role, and then return to the Lambda function configuration page.7.    Choose Create function.8.    To prevent the function from timing out, increase the Timeout to 1 minute from the default 3 seconds.9.    Choose Save.Finalize the Kinesis Data Firehose delivery stream1.    Open the Amazon Kinesis console.2.    In the navigation pane, choose Data Firehose.3.    For your delivery stream, choose Lambda function, and then from the dropdown, choose the name of your new AWS Lambda function.4.    For Destination Settings, enter the Splunk HEC details, including the Splunk HEC endpoint that you created.Note: You must terminate the Splunk HEC endpoint with a valid SSL certificate. Use the matching DNS hostname to connect to your HEC endpoint. The format for the cluster endpoint is https://YOUR-ENDPOINT.splunk.com:8088.5.    For Splunk endpoint type, choose Raw endpoint, and then enter the authentication token.6.    Choose Next.7.    (Optional) Choose an existing Amazon Simple Storage Service (Amazon S3) bucket or create a new one to back up failed events or all events. Make sure to configure Amazon S3 related settings, such as buffer conditions, compression and encryption settings, and error logging options in the delivery stream wizard.8.    Under IAM role, choose Create New.9.    In the tab that opens, enter a Role name, and then choose Allow.10.    Choose Next.11.    Choose Create delivery stream.Configure Amazon VPC Flow LogsNote: If you have an Amazon VPC flow log, then proceed to the next section, Create an Amazon CloudWatch logs subscription. If you don't have a VPC flow log, then complete the following steps:1.    Open the CloudWatch console.2.    In the navigation pane, choose Logs.3.    For Actions, choose Create log group.4.    Enter a Log Group Name.5.    Choose Create log group.6.    Open the Amazon VPC console.7.    In the navigation pane under Virtual Private Cloud, choose Your VPCs.8.    In the content pane, select your VPC.9.    Choose the Flow logs view.10.    Choose Create flow log:For Filter, choose All.For Destination log group, choose the log group you just created.For IAM role, choose an IAM role that allows your Amazon VPC to publish logs to CloudWatch. If you don't have an appropriate IAM role, then under IAM role, choose Set Up Permissions, and then choose Create a new IAM role. Keep the default settings.Choose Allow to create and associate the role VPCFlowLogs with the destination log group.11.    Choose Create.12.    Establish a real-time feed from the log group to your delivery stream:For AWS Lambda instructions, see Accessing Amazon CloudWatch Logs for AWS Lambda.For Amazon OpenSearch Service instructions, see Streaming CloudWatch Logs data to Amazon OpenSearch Service.For Kinesis Data Firehose, complete the steps in the Create a CloudWatch Logs subscription section to create a CloudWatch Logs subscription.Note: If you receive errors when running AWS CLI commands, confirm that you're running a recent version of the AWS CLI.Create an Amazon CloudWatch Logs subscription1.    Grant access to CloudWatch to publish your Kinesis Data Firehose stream with the correct role permissions.2.    Open AWS CLI.3.    Use the following JSON file to create your trust policy (such as TrustPolicyforCWLToFireHose.json). Replace YOUR-RESOURCE-REGION with your resource's AWS Region.{  "Statement": {    "Effect": "Allow",    "Principal": { "Service": "logs.YOUR-RESOURCE-REGION.amazonaws.com" },    "Action": "sts:AssumeRole"  }}4.    Run the following command to create the role with permissions from the trust policy:$ aws iam create-role --role-name CWLtoKinesisFirehoseRole --assume-role-policy-document file://TrustPolicyForCWLToFireHose.json5.    Use the following JSON file to create your IAM policy (such as PermissionPolicyForCWLToFireHose.json). Replace YOUR-AWS-ACCT-NUM with your AWS account number, YOUR-RESOURCE-REGION with your resource's Region, and FirehoseSplunkDeliveryStream with your stream's name.{    "Statement":[      {        "Effect":"Allow",        "Action":["firehose:PutRecord"],        "Resource":["arn:aws:firehose:YOUR-RESOURCE-REGION:YOUR-AWS-ACCT-NUM:deliverystream/FirehoseSplunkDeliveryStream"]      },      {        "Effect":"Allow",        "Action":["iam:PassRole"],        "Resource":["arn:aws:iam::YOUR-AWS-ACCT-NUM:role/CWLtoKinesisFirehoseRole"]      }    ]}6.    Run the following command to attach the IAM policy to the role:$ aws iam put-role-policy     --role-name CWLtoKinesisFirehoseRole     --policy-name Permissions-Policy-For-CWL     --policy-document file://PermissionPolicyForCWLToFireHose.json7.    Run the following command to create a subscription filter. Replace YOUR-AWS-ACCT-NUM with your AWS account number, YOUR-RESOURCE-REGION with your resource's Region, and FirehoseSplunkDeliveryStream with your stream's name.$ aws logs put-subscription-filter    --log-group-name " /vpc/flowlog/FirehoseSplunk"    --filter-name "Destination"    --filter-pattern ""    --destination-arn "arn:aws:firehose:YOUR-RESOURCE-REGION:YOUR-AWS-ACCT-NUM:deliverystream/FirehoseSplunkDeliveryStream"    --role-arn "arn:aws:iam::YOUR-AWS-ACCT-NUM:role/CWLtoKinesisFirehoseRole"For more information on subscription filters, see Example 3: subscription filters with Amazon Kinesis Data Firehose.Related informationPower data ingestion into Splunk using Amazon Kinesis Data FirehoseDestination settingsControlling access with Amazon Kinesis Data FirehoseFollow"


Question: How do I move accounts between organizations in AWS Organizations?

I want to migrate AWS Organizations member accounts from one organization to another organization. What should I consider before starting the migration process?

Answer: "I want to migrate AWS Organizations member accounts from one organization to another organization. What should I consider before starting the migration process?Short descriptionWhen planning your migration, consider the following:You have the permissions that you need to move both the management and member accounts in the organization.You backed up any reports from the member accounts that you need to keep. The member accounts can't access these reports after leaving the Organization.You have a valid payment method on the member account to address any charges that are incurred while the accounts are migrating.You have reviewed and updated the tax information for any accounts that are changing from one organization to another.You have changed the AWS Support plan for migrating Developer or Business accounts.You understand the technical process of migrating accounts.ResolutionImportant: If you have a pricing agreement with AWS and want to move your management account to a different organization, contact your Account Manager.Account access considerationsYou must have AWS root user account access or AWS Identity and Access Management (IAM) access to both the member and management accounts. For more information on adding these permissions, see Managing access permissions for your organization.You might need to add more information to a member account before you can move it. For example, you might need to add a new payment method to the member account, or update the contact information for the account. When you remove the account from the Organization, you are prompted to add this information. For more information, see Removing a member account from your organization.When you remove a member account from an organization, the member account's access to AWS services that are integrated with the organization are lost. In some cases, resources in the member account might be deleted. For example, when an account leaves the organization, any AWS CloudFormation stacks created using StackSets are removed from the management of StackSets. You can choose to either delete or retain the resources managed by the stack. For a list of AWS services that can be integrated with AWS Organizations, see AWS services that you can use with AWS Organizations.If you use the aws:PrincipalOrgID condition key in your resource-based policies to restrict access only to the principals from AWS accounts in your organization, then you must change these policies before moving the member account to another organization.To share resources with a migrating account, you must enable resource sharing with AWS Organizations before migrating the account. For more information, see Sharing your AWS resources.Before migrating, decide the set of features that you want for your organization. By default, AWS Organizations supports consolidated billing features. To access additional features such as service control policies (SCPs), enable all features.Before migrating, consider the number of accounts in your organization. If an increase is needed, see Quotas for AWS Organizations for more information.Reporting considerationsBilling history and billing reports for all accounts stay with the management account in an organization.Important: Before you move the account to a new organization, confirm that all Cost and Usage Reports, Detailed Billing Reports, or reports generated by Cost Explorer that you want to keep are downloaded. Your historical data and graphs aren't stored when an account is migrated.Billing considerationsWhen a member account leaves an organization, all charges incurred by the account are charged directly to the standalone account. Even if the account move takes only a minute to process, it's likely that some charges are incurred by the member account.Be sure that you have a valid payment method on the member account to address any incurred charges. For example, if you are asked to add a credit card to the member account to cover the charges, then create an internal process to reimburse the member account for using its own payment method during the migration.When the member account is added to the new organization, charges are billed to the new management account.If you currently benefit from a volume discount, you might temporarily pay the normal rate for that service. This is because you changed billing entities, and your new consolidated billing family might not have reached the higher usage tier necessary to activate the volume discount. Be sure to account for this temporary change in pricing.The account that was used to purchase the Savings Plan owns the Savings Plan. If you leave the Organization, then the Savings Plan remains on the account that purchased the Savings Plan.For help with updating the payment method for the member account, contact AWS Support.Tax considerationsYou might need to update the tax settings on member accounts after you move them to the new organization.To view and edit the tax registration numbers for all member accounts in the organization, you must sign in as the management account.Migrating Developer or Business accountsIf you are migrating a Developer or Business account with an existing AWS Support Plan and don't want to be billed for this plan, then you must change the plan. For more information, see How do I cancel my AWS Support plan?Planning the migration processIf you have only a few accounts to migrate, you can use the Organizations console.If you are migrating many accounts, you might use the AWS Organizations API or AWS Command Line Interface (AWS CLI) to move the accounts instead.In either case, do the following for each member account:Remove the member account from the old organization.Send an invite to the member account from the new organization.Accept the invite to the new organization from the member account.If you want the management account of the old organization to also join the new organization, do the following:Remove the member accounts from the organization using the preceding process.Delete the old organization.Repeat the preceding process to invite the old management account to the new organization as a member account.Related informationHow do AWS Support plans work in an organization?Follow"


Question: "How can I encrypt an existing unencrypted EBS volume, or change the encryption key that my volume uses?"

"I want to encrypt an existing unencrypted Amazon Elastic Block Store (Amazon EBS) volume. Or, I want to change the encryption key that my existing encrypted Amazon EBS volume uses. How can I do this?"

Answer: "I want to encrypt an existing unencrypted Amazon Elastic Block Store (Amazon EBS) volume. Or, I want to change the encryption key that my existing encrypted Amazon EBS volume uses. How can I do this?Short descriptionYou can't encrypt existing unencrypted Amazon EBS volumes. You also can't change the AWS Key Management Service (AWS KMS) key that existing encrypted EBS volumes use. However, you can create a snapshot of the volume. Then, use the snapshot to create a new, encrypted copy of the volume. When you create the new volume, specify the encryption key that you want to use.ResolutionNote: Amazon EBS volumes that are created from snapshots go through an initialization process. This can cause an initial performance degradation for the volume. To avoid performance degradation, use one of the two options listed in step 8.Open the Amazon EC2 console.Under Elastic Block Store, select Volumes.Select the volume from the list. Note the current Availability Zone of your volume.From the Actions dropdown list, choose Create snapshot.(Optional) Enter a Description for the snapshot.Select Create snapshot.Under Elastic Block Store, select Snapshots, and then select your newly created snapshot.(Optional) To avoid latency issues, turn on Amazon EBS fast snapshot restore on your snapshot. Or, manually initialize your Amazon EBS volume after creation.From the Actions dropdown list, select Create volume from snapshot.From the Availability Zone dropdown list, select the same Availability Zone of your current volume.If the source snapshot is unencrypted, then under Encryption, select Encrypt this volume.From the KMS key dropdown list, choose the encryption key.Select Create volume.To encrypt volumes and snapshot copies by default, see How can I turn on automatic encryption of new Amazon EBS volumes and snapshot copies created in my account?Related informationAmazon EBS encryptionFollow"


Question: How can I improve the performance of the AWS SCT conversion tool when using AWS DMS?

I'm using the AWS Schema Conversion Tool (AWS SCT) to convert source database objects to a format that is compatible with my target AWS Database Migration Service (AWS DMS) database. But the conversion process is taking longer than expected. How can I improve the performance of AWS SCT conversion tool?

Answer: "I'm using the AWS Schema Conversion Tool (AWS SCT) to convert source database objects to a format that is compatible with my target AWS Database Migration Service (AWS DMS) database. But the conversion process is taking longer than expected. How can I improve the performance of AWS SCT conversion tool?Short descriptionThe AWS SCT is a locally installed tool that you can use to automatically convert your source database schema. The tool also converts a majority of the database code objects, such as views, stored procedures, and functions, to a format that's compatible with the target database. For more information, see Converting database schemas using AWS SCT.This means that the performance of the AWS SCT depends on the memory that's available on the local machine that it's installed on. If you increase the memory that's available to the AWS SCT, then you also speed up the performance of your conversion. But this means that the AWS SCT also consumes more memory resources on your local machine.Note: It's a best practice to install the AWS SCT on a separate machine that's in the same network as your source. This allows for better performance in the code conversion and data migration phases. Be sure that the source database stats are current to avoid performance issues in the data warehouse migration.ResolutionUse one of these methods to control the memory usage and performance of the AWS SCT tool.Choose how AWS SCT uses memoryRun the AWS SCT on your local machine.In the Settings menu, choose Performance and Memory.Choose one of these options:Fast conversion, but large memory consumption - This optimizes the speed of the conversion. But, it might need more memory for the object reference cache.Low memory consumption, but slower conversion - This minimizes the amount of memory used, but it results in a slower conversion. Use this option if your machine has a limited amount of memory.Balance speed with memory consumption - This provides a balance between memory use and conversion speed.Choose Apply, and then choose OK to save your settingsManually configure the amount of memory available to AWS SCTYou can control the memory that the AWS SCT consumes in a more granular way by manually configuring how much memory is available to the tool.To modify the amount of memory the AWS SCT consumes, follow these steps:Open the folder that contains the AWS SCT configuration file. For example, on a Windows system its located in C:\Program Files\AWS Schema Conversion Tool\App.Open the configuration file named AWS Schema Conversion Tool.cfg using a text editor like Notepad.In the JavaOptions section, set the minimum and maximum memory available to the AWS SCT. This example sets a minimum of 4GB and a maximum of 40GB:[JavaOptions]-Xmx48960M-Xms4096MRelated informationHow do I increase logging levels for the AWS SCT when using AWS DMS?How do I install the AWS SCT and database drivers for Windows to convert the database schema for my AWS DMS task?Follow"


Question: Why is a trailing slash added to the URL when I use Amazon S3 static website redirection feature?

I am using the Amazon Simple Storage Service (Amazon S3) static website redirection rules. Amazon S3 adds a slash at the end of the URL that breaks my website.

Answer: "I am using the Amazon Simple Storage Service (Amazon S3) static website redirection rules. Amazon S3 adds a slash at the end of the URL that breaks my website.ResolutionThe addition of a trailing slash to the redirected URL is an expected behavior with the Amazon S3 static website hosting feature.To avoid the addition of a trailing slash in the redirected URL, you can use the following workaround:Configure an index document (example: index.html) to host the S3 static website.Set the website redirect location in the metadata of the object to configure the redirect.To perform the workaround, complete these steps:Open the Amazon S3 console.From the Buckets list, choose the name of your bucket.Choose Properties.Under Static website hosting, choose Edit.On the Edit Static website hosting page, for Static website hosting, choose Enable.For Hosting type, select Host a static website.For Index document, specify the name of an object that you want to use to set the redirection metadata. Example: index.htmlDelete the Redirection rules, if any. Choose Save changes.Next, use the S3 console to configure an index. Then, complete these steps to configure the redirect:Open the Amazon S3 console.From the Buckets list, choose the name of your bucket.Under Objects, choose the index document that you configured.Choose the Properties tab.In the Metadata section, choose Edit.Under Metadata, do the following:Choose Add metadata.For Type, select System defined.For Key, choose x-amz-website-redirect-location from the dropdown list.For Value, enter the redirect URL (Example: http://www.example.com). Choose Save changes.Related informationConfiguring a webpage redirectFollow"


Question: How can I create an Application Load Balancer and then register Amazon ECS tasks automatically?

"I want to create an Application Load Balancer, and then automatically register Amazon Elastic Container Service (Amazon ECS) tasks."

Answer: "I want to create an Application Load Balancer, and then automatically register Amazon Elastic Container Service (Amazon ECS) tasks.ResolutionCreate a target groupIn the Amazon EC2 console, in the navigation pane, choose Target Groups.Choose Create target group.For Target group name, enter a name.For Target type, choose Instance or IP.Important: If your service's task definition uses the awsvpc network mode (required for the AWS Fargate launch type), you must choose IP as the target type. This is because tasks that use the awsvpc network mode are associated with an elastic network interface. These tasks aren't associated with an Amazon Elastic Compute Cloud (Amazon EC2) instance.For VPC, choose the VPC that you want to attach to your target group.Choose Create.Associate your target group with your load balancerIn the navigation pane of the Amazon EC2 console, choose Load Balancers.Choose Create Load Balancer.For Application Load Balancer, choose Create.For Name, enter a name for your load balancer.In the Listeners section, for Load Balancer Protocol, choose HTTP or HTTPS.In the Availability Zones section, for VPC, choose your VPC.For Availability Zones, choose at least two subnet IDs.Choose Next: Configure Security Settings, and then choose Next: Configure Security Groups.In the Security Group ID column, choose the security group ID that you want to attach to the load balancer.Choose Next: Configure Routing.In the Target group section, for Target group, choose Existing target group.For Name, choose the target group that you created previously in the Create a target group section.Choose Next: Register Targets, Next: Review, Create.Create an Amazon ECS service using the previous Application Load BalancerOpen the Amazon ECS console.In the navigation pane, choose Clusters, and then select your cluster.On the Services tab, choose Create.In the Configure service section, confirm that you have at least one task definition created.Important: To use a load balancer, you must use containerPort in your task definition.For Launch type, choose a launch type.For Service name, enter a service name.For Number of tasks, enter the number of tasks.Choose Next step.In the Load balancing section, for Load balancer type, choose Application Load Balancer.For Container to load balance, confirm that the container name and port are correct and choose Add to load balancer.For Production listener port, choose the application port that's used by your application (for example, 80:HTTP).For Target group name, choose the target group that you created previously in the Create a target group section.Choose Next step.For Service Auto Scaling, choose Do adjust the service's desired count or Do not adjust the service's desired count based on the setup of your Amazon ECS service application.Choose Next step, and then choose Create Service.Choose View Service, and then choose the Tasks tab.Choose the refresh icon, and then verify that your tasks are in the RUNNING state.View your tasks registered in the target groupOpen the Amazon EC2 console.Choose Target Groups, and then choose the target group that you created previously in the Create a target group section.To view the registered targets in the target group, choose the Targets tab.Note: To troubleshoot failed health checks for your Application Load Balancer, see How can I get my Amazon ECS tasks running using the Amazon EC2 launch type to pass the Application Load Balancer health check in Amazon ECS?Related informationCreating an Application Load BalancerService load balancingFollow"


Question: How do I get started with using IAM Identity Center and access the AWS access portal?

I enabled AWS IAM Identity Center (successor to AWS Single Sign-On)—how do I use the AWS access portal?

Answer: "I enabled AWS IAM Identity Center (successor to AWS Single Sign-On)—how do I use the AWS access portal?ResolutionIAM Identity Center users can access AWS accounts and cloud applications using the AWS access portal. Follow these guidelines for accessing, configuring, and managing the AWS access portal for the IAM Identity Center.Important: If you haven't already done so, follow the instructions to assign user access to cloud applications in IAM Identity Center and Add and configure a cloud application.Follow these instructions to sign in to the AWS access portal:Open the IAM Identity Center console, choose Dashboard, and then choose the link in AWS access portal URL.Follow the instructions to sign in to the AWS access portal. Note: IAM Identity Center users access the AWS access portal using the user credentials for the directory configured in the IAM Identity Center.To access cloud applications or AWS accounts of the AWS Organizations from the AWS access portal, follow the instructions for using the AWS access portal. Tip: If you can't find your cloud application or AWS account, enter the application name or AWS account you're looking for into the search box and press Enter.To sign out of the AWS access portal, see Signing out of the AWS access portal.Note: By default, the IAM Identity Center permission credential session duration is one hour. To change the credential duration, follow the instructions to set session duration.Related informationHow to create and manage users within the IAM Identity CenterMulti-account permissionsFollow"