Question: How do I resolve kubelet or CNI plugin issues for Amazon EKS?

I want to resolve issues with my kubelet or CNI plugin for Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to resolve issues with my kubelet or CNI plugin for Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionTo assign and run an IP address to the pod on your worker node with your CNI plugin (on the Kubernetes website), you must have the following configurations:AWS Identity and Access Management (IAM) permissions, including a CNI policy that attaches to your worker node's IAM role. Or, IAM permissions that you provide through service account IAM roles.An Amazon EKS API server endpoint that's reachable from the worker node.Network access to API endpoints for Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR), and Amazon Simple Storage Service (Amazon S3).Sufficient available IP addresses in your subnet.A kube-proxy that runs successfully for the aws-node pod to progress into Ready status.The kube-proxy version and VPC CNI version that support the Amazon EKS version.ResolutionVerify that the aws-node pod is in Running status on each worker nodeTo verify that the aws-node pod is in Running status on a worker node, run the following command:kubectl get pods -n kube-system -l k8s-app=aws-node -o wideIf the command output shows that the RESTARTS count is 0, then the aws-node pod is in Running status. Try the steps in the Verify that your subnet has sufficient free IP addresses available section.If the command output shows that the RESTARTS count is greater than 0, then verify that the worker node can reach the API server endpoint of your Amazon EKS cluster. Run the following command:curl -vk https://eks-api-server-endpoint-urlVerify connectivity to your Amazon EKS cluster1.    Verify that your worker node's security group settings for Amazon EKS are configured correctly. For more information, see Amazon EKS security group requirements and considerations.2.    Verify that your worker node's network access control list (network ACL) rules for your subnet allow communication with the Amazon EKS API server endpoint.Important: Allow inbound and outbound traffic on port 443.3.    Verify that the kube-proxy pod is in Running status on each worker node:kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide4.    Verify that your worker node can access API endpoints for Amazon EC2, Amazon ECR, and Amazon S3.Note: Configure these services through public endpoints or AWS PrivateLink.Verify that your subnet has sufficient free IP addresses availableTo list available IP addresses in each subnet in the Amazon Virtual Private Cloud (Amazon VPC) ID, run the following command:aws ec2 describe-subnets --filters "Name=vpc-id,Values= VPCID" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'Note: The AvailableIpAddressCount must be greater than 0 for the subnet where the pods are launched.Check whether your security group limits have been reachedIf you reach the limits of your security group's per elastic network interface, then your pod networking configuration can fail.For more information, see Amazon VPC quotas.Verify that you're running the latest stable version of the CNI pluginTo confirm that you have the latest version of the CNI plugin, see Updating the Amazon VPC CNI plugin for Kubernetes self-managed add-on.For additional troubleshooting, see the AWS GitHub issues page and release notes for the CNI plugin.Check the logs of the VPC CNI plugin on the worker nodeIf you create a pod, and an IP address doesn't get assigned to the container, then you receive the following error:failed to assign an IP address to containerTo check the logs, go to the /var/log/aws-routed-eni/ directory, and then locate the file names plugin.log and ipamd.log.Verify that your kubelet pulls the Docker container imagesIf your kubelet doesn't pull the Docker container images for the kube-proxy and amazon-k8s-cni containers, then you receive the following error:network plugin is not ready: cni config uninitializedMake sure that you can reach the Amazon EKS API server endpoint from the worker node.Verify that the WARM_PREFIX_TARGET value is set correctlyNote: This applies only if prefix delegation is turned on. If prefix delegation is turned on, then check for the following logged error message:Error: Setting WARM_PREFIX_TARGET = 0 is not supported while WARM_IP_TARGET/MINIMUM_IP_TARGET is not set. Please configure either one of the WARM_{PREFIX/IP}_TARGET or MINIMUM_IP_TARGET env variableWARM_PREFIX_TARGET must be set to a value greater than or equal to 1. If it's set to 0, then you receive the following error:See CNI configuration variables on the GitHub website for more information.Check the reserved space in the subnetNote: This applies only if prefix delegation is turned on. If prefix delegation is turned on, then check for the following logged error message:InsufficientCidrBlocksMake sure that you have sufficient available /28 IP CIDR (16 IPs) blocks in the subnet. All 16 IPs must be contiguous. If you don't have a /28 range of continuous IPs, then you receive the InsufficientCidrBlocks error.To resolve the error, create a new subnet, and launch the pods from there. Also, use an Amazon EC2 subnet CIDR reservation to reserve space within a subnet with an assigned prefix. For more information, see Use subnet CIDR reservations.Updates that are made with Infrastructure as Code (IaC) roll back with conflictsIf you use Amazon EKS managed add-ons, the update errors that use the following services roll back when the conflict method is undefined:AWS Cloud Development Kit (AWS CDK)AWS CloudFormationeksctl (from the eksctl website)Correct methods are NONE, OVERWRITE, or PRESERVE.If no method is defined, then the default is NONE. When the system detects conflicts, the update to the CloudFormation stack rolls back, and no changes are made.To set the default configuration for the add-ons, use the overwrite method. You you must use OVERWRITE when you move from self-managed to Amazon EKS managed add-ons.Use the PRESERVE method when you use custom defined configurations, such as WARM_IP_TARGET or custom networking.Nodes are in NotReady statusWhen you have aws-nodes that aren't in the Running status, it's common for nodes to be in the NotReady status. For more information, see How can I change the status of my nodes from NotReady or Unknown status to Ready status?Custom networking configuration challengesWhen custom networking is active for the VPC CNI, ENIConfig custom resource definitions (CRDs) must define the correct subnet and security groups.To verify if custom networking is active, describe the aws-node pod in the kube-system namespace. Then, see if the following environment variable is set to true:AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFGIf custom networking is active, then check that the CRDs are configured properly.kubectl get ENIConfig -A -o yamlDescribe each entry that matches the Availability Zone name. The subnet IDs match for the VPC and worker node placement. The security groups are accessible or shared with the cluster security group. For more information on best practices, see the Amazon  EKS Best Practices Guides  on the GitHub website.Follow"


Question: How do I set up weighted target groups for my Application Load Balancer?

I want to register weighted target groups for my Application Load Balancer.

Answer: "I want to register weighted target groups for my Application Load Balancer.ResolutionComplete the following steps to register your target group with a load balancer, and add weight to the target group.Create target groups1.    Open the Amazon Elastic Compute Cloud (Amazon EC2) console.2.    Choose the AWS Region that your Amazon EC2 instances are located in.3.    On the navigation pane, under LOAD BALANCING, choose Target Groups.4.    Create the first target group:     Choose Create Target group.For Target group name, specify a name for the target group.Configure the protocol, port, and virtual private cloud (VPC) for the target group.Choose Create.For Instances, select one or more instances.Specify a port for the instances.Choose Add to registered, and then choose Save.5.    Repeat step 4 to create a second target group.Create an Application Load BalancerNote: If you already have an Application Load Balancer, then proceed to the next section.1.    On the navigation pane, under LOAD BALANCING, choose Load Balancers.2.    Choose Create Load Balancer.3.    For Select load balancer type, choose Application Load Balancer.4.    Choose Continue.5.    Complete the steps in Create an Application Load Balancer.6.    Complete the Configure Routing steps:For Target group, choose Existing Target.For Name, choose the first target group that you created.Choose Next: Register Targets.7.    On the Register Targets page, the instances that you registered with the target group appear under Registered instances. You can't modify the register targets here.8.    On the Review page, choose Create.9.    After you receive a notification that your load balancer is created, choose Close.10.    Select the load balancer.Configure the Listener rules and add weight to the target groups1.    On the Listeners tab, choose View/edit rules.2.    Choose Edit rules (the pencil icon).3.    Choose Edit next to the Forward to option.4.    Add the other target group.5.    Enter the target group weight values. These values must be numeric values between zero and 999.6.    Select the check mark, and then choose Update.7.    (Optional) If the target group is sticky, then set the Group level Stickiness. When you configure this setting, routed requests remain in the target group for the duration of the session. The default value is 1 hour. After the session duration ends, requests are distributed according to the weights of the target group.Note: The Application Load Balancer distributes traffic to the target groups based on weights. If all targets in a target group fail health checks, then the Application Load Balancer doesn't route or fail over the requests to another target group. If a target group has only unhealthy registered targets, then the load balancer nodes route requests across its unhealthy targets. When all the targets in a target group are unhealthy, don't use a weighted target group as a failover mechanism.For example, if the weight of the first target is 70%, and the second target is 30%, most requests are from the first target group:$ for X in `seq 6`; do curl -so -i /dev/null -w "" http://FINAL-721458494.us-east-2.elb.amazonaws.com; done<h1> This is T1 </h1><h1> This is T1 </h1><h1> This is T1 </h1><h1> This is T1 </h1><h1> This is T2 </h1><h1> This is T2 </h1>If you set the weight of the second target as 70% and the first as 30%, then most requests are from the second target group:$ for X in `seq 7`; do curl -so -i /dev/null -w "" http://FINAL-721458494.us-east-2.elb.amazonaws.com; done<h1> This is T2 </h1><h1> This is T2 </h1><h1> This is T2 </h1><h1> This is T1 </h1><h1> This is T1 </h1><h1> This is T2 </h1><h1> This is T2 </h1>If all targets in a target group fail health checks, then the Application Load Balancer doesn't automatically route or failover the requests to another target groupFollow"


Question: How do I organize my AWS resources?

I want to organize my AWS resources so that I can manage them as a group.

Answer: "I want to organize my AWS resources so that I can manage them as a group.ResolutionYou can use AWS Resource Groups to organize and manage your AWS resources that are in the same AWS Region. With Resource Groups, you can automate tasks, such as applying security patches and updates, on a group of AWS resources at the same time.To create AWS CloudFormation stack-based Resource Groups, see Create an AWS CloudFormation stack-based group.To create tag-based Resource Groups, see Build a tag-based query and create a group.You can add tags to most of your resources to help identify and sort your resources within your organization. You can add these tags when you create or edit your AWS resources. Also, you can add tags to supported resources using Tag Editor.You can also access Resource Groups by opening the AWS Systems Manager console, and then choosing Resource Groups & Tag Editor from the navigation pane.Related informationResources you can use with AWS Resource Groups and Tag EditorAmazon Resource Names (ARNs)Follow"


Question: How do I troubleshoot AWS Marketplace connection errors in my AWS Glue ETL jobs?

"I'm using AWS Marketplace connectors in AWS Glue, but receive errors in the logs."

Answer: "I'm using AWS Marketplace connectors in AWS Glue, but receive errors in the logs.ResolutionConnectors aren't showingYou subscribe to a connector from AWS Marketplace, but you can’t find this connector in the AWS Glue Studio’s connector page. To resolve this issue, complete the following steps.Note: You can repeat these steps even if you previously subscribed to the connector.Open the AWS Marketplace.Choose Discover products, and then find the connector that you want to use.Choose Continue to Subscribe, and then, if promoted, log in to your AWS account.Choose Continue to Configure. If this option is grayed out and you can't choose it, then make sure to read the terms and conditions. Choose Accept Terms, and then wait until the Continue to Configure button becomes available.From the dropdown list, choose Delivery Method and Software Version. If you're not sure which version to choose, then choose the latest version.Choose Continue to Launch, and then choose Usage Instruction.In the pop-up window that appears, choose Active the Glue connector from AWS Glue Studio.(Optional) To install only the connector, choose Active Connector Only. For more information on this option, see Using connectors and connections with AWS Glue Studio. If you're working with custom connectors instead, then see Developing custom connectors.Issues with AWS Identity and Access Management (IAM) roleWhen trying to subscribe to a connector in the AWS Marketplace, you get an IAM permissions error similar to the following one:"You do not have the right permissions to make this request.Some controls have been disabled because you are missing the correct permission(s). The missing permission(s) are: aws-marketplace:Subscribe."To resolve this issue, add an IAM policy to the IAM user that received the error. For AWS Marketplace use, add the following IAM policies to your IAM user:To grant permissions to view subscriptions but not change them, choose AWSMarketplaceRead-only.To grant permissions to subscribe and unsubscribe, choose AWSMarketplaceManageSubscriptions.To grant complete control of your subscriptions, choose AWSMarketplaceFullAccess.For more information, see Controlling access to AWS Marketplace subscriptions.AccessDeniedException errorsYou receive an AccessDeniedException error similar to the following one in the AWS Glue job's logs:"An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/<IamRole>/GlueJobRunnerSession is not authorized to perform: ecr:GetAuthorizationToken on resource: * because no identity-based policy allows the ecr:GetAuthorizationToken action Glue ETL Marketplace - failed to download connector, activation script exited with code 1LAUNCH ERROR | Glue ETL Marketplace - failed to download connector. Please refer logs for details."This error occurs when the IAM role that's associated with your AWS Glue job has insufficient permissions when it tries to perform the GetAuthorizationToken operation. To resolve this issue, give your AWS Glue job the ecr:GetAuthorizationToken permission:Open the IAM console.Choose the IAM role that you're using in the AWS Glue job.Choose Attach policies.Under Filter policies, enter AmazonEC2ContainerRegistryReadOnly, and then choose this policy.Choose Attach Policy.After you attach the required policy to the IAM role, run the AWS Glue job again.For more information, see AmazonEC2ContainerRegistryReadOnly, Adding and removing IAM identity permissions, and Setting up IAM permissions for AWS Glue.Networking issues - No network pathway from VPCYour networking setup might not be adequate for AWS Glue connectors to work correctly when it's used in an AWS Glue job.botocore.exceptions.ConnectTimeoutError: Connect timeout on endpoint URL: "https://api.ecr.us-east-1.amazonaws.com/"Glue ETL Marketplace - failed to download connector, activation script exited with code 1LAUNCH ERROR | Glue ETL Marketplace - failed to download connector.Please refer logs for details.Exception in thread "main" java.lang.Exception: Glue ETL Marketplace - failed to download connector.In this example, there's no network pathway from the virtual private cloud (VPC) containing the job's components to the Amazon Elastic Container Registry (Amazon ECR) repository. The Amazon ECR repository contains the images for the connectors. AWS Glue stores all connectors in an Amazon ECR repository in the us-east-1 AWS Region. If the AWS Glue job wants to use a connector, then it must download it from this Region.When a connection is added to an AWS Glue job, you must establish a network route. This network route allows traffic to flow to or from the service, in this case Amazon ECR. AWS Glue uses private IPs to communicate with the components of the job and services, such as Amazon ECR. This error can occur if your connection uses a public subnet with an internet gateway in its route table.The job of the internet gateway is to route traffic. But it can't convert the private IPs that AWS Glue uses into public IPs that the Amazon ECR endpoint in the us-east-1 Region recognizes. You must use a NAT gateway in the connection subnet that's capable of performing these address translations (private to public IPs).When you create the connection, the networking information such as, VPC, subnet, and security group are optional. If you create the connection with only the connector and secrets key, then the AWS Glue job uses an internal NAT gateway. The job doesn't rely on a NAT gateway in your account.To resolve this issue, choose one of the following solutions, and incorporate it into your network design.Approach 1: Create and attach a NAT gateway to the connection subnetInstead of using an internet gateway, create and attach a NAT gateway to the connection subnet:Provision an unattached Elastic IP address to your account. Make sure that you associate this IP address with the NAT gateway.Create a NAT gateway, and then choose a public subnet and the Elastic IP address that you provisioned for the NAT gateway. This creates the NAT gateway in a public subnet.Create a private subnet (without an internet gateway route) and a related route table. In the route table, add a rule with 0.0.0.0/0 pointing to the NAT Gateway that you created. Or, you can edit one of the existing subnets to use the route table with the NAT gateway route. Make sure that there's no internet gateway route that's used with the NAT gateway route.Revise the AWS Glue connection's subnet to use the private subnet that you created in Step 3.Run the AWS Glue job again and confirm that the error doesn't re-occur.Approach 2: Don't use VPC information in the connectionDon't include VPC information in the connection. Use an internet NAT gateway instead:Create a new connection for your connector in the AWS Glue Studio.When you create the connection, specify only the Secrets Manager key. Don't add any VPC options. This means that AWS Glue uses the internal NAT instead of relying on the subnet.Edit the AWS Glue job to use the new connection, and then rerun the job.Approach 3: For private network setups, create a VPC endpointIf you have a private network setup, then you can also use a VPC endpoint instead of using a NAT gateway.Create a private networkLog in to the Amazon Virtual Private Cloud (Amazon VPC) console.From the navigation pane, choose Subnet, and then choose Create subnet.Choose your VPC ID, and then add a Subnet name, Availability Zone, IPV4 CIDR block and tags. Then, choose Create Subnet.From the navigation pane, choose Route tables. Add a name for your route table, choose your VPC, and then choose Create route table.Open the route table that you created. Under Subnet association, choose the tab for Explicit subnet associations.Choose Edit subnet association, choose the newly created subnet from the list, and then choose Save.If you check the Route tab, you can now see that there is no internet access (0.0.0.0/0).From the navigation pane, choose Security groups. Add the details for your security group, and then choose the VPC. Add an inbound rule to allow TCP protocol for port 22 with source 0.0.0.0./0.Add a second rule. For Protocol, choose ALL. For Source, choose the new security group that you created. If you can't find the new security group name in the dropdown list, then save the group, and edit the inbound rules again.Create VPC endpointNext, create three VPC endpoints: an Amazon ECR API endpoint, a VPC endpoint for the com.amazonaws.<region>.ecr.dkr service, and an Amazon Simple Storage Service (Amazon S3) endpoint.First, create the Amazon ECR API endpoint:From the navigation pane, choose Endpoints.Choose Create endpoint, and then add an endpoint name for your Amazon ECR API endpoint.For Service category, choose AWS services.For Services, add the ECR filter, and then choose com.amazonaws.<region>ecr.api.For VPC, choose the VPC that you want to create the endpoint in. Under Additional settings, choose Enable DNS Name.For Subnets, choose the Availability Zone that you created the new subnet in. Then, from the Subnet ID dropdown list, choose the Subnet name.For Security groups, choose the security group that you created.For Policy, choose Full access to allow all operations by all principles on all resources over the VPC endpoint.Add an optional tag, and then choose Create endpoint.Using the same steps, create another VPC endpoint for the service name com.amazonaws.<region>.ecr.dkr.Then, complete the following steps to create the Amazon S3 endpoint:From the navigation pane, choose Endpoints.Choose Create endpoint, and then add an endpoint name for your Amazon S3 endpoint.For Service category, choose AWS servicesFor Services, add the Type:Gateway filter, and then choose com.amazonaws.<region>.s3.For VPC, choose the VPC that you want to create the endpoint in.For Route tables, choose the route tables that you created.For Policy, choose Full access to allow all operations by all principles on all resources over the VPC endpoint.Add an optional tag, and then choose Create endpoint.Subscribe to and configure connectorsIf you already subscribed to and configured your connector in AWS Glue, then proceed to the Create AWS Glue connection section.If you didn't subscribe to and configure your connector in AWS Glue, then follow the steps in Subscribing to AWS Marketplace connectors. In the Usage instruction pop-up window that appears, choose Activate the Glue connector from AWS Glue Studio. This takes you to the Create Glue Connection page.Create AWS Glue ConnectionIf you already added your connector in the AWS Glue console, then navigate to Connections and choose your connector. Then choose, Create connection.If you followed the previous steps to subscribe to and configure connectors, then the Create Glue Connection page is open. Complete the following steps to create your connection:On the Create Glue Connection page, add a Connection name.For Network options, choose your VPC, and the subnet and security groups that you previously created.Choose Create connection and activate connector.You can now use the connection name in your AWS Glue job to control the connector.Networking issues - too many connections in the AWS Glue jobYou receive this error in the AWS Glue job's logs:INFO - Glue ETL Marketplace - Start downloading connector jars for connection: <connection name>test connection feature: "Caused by: com.amazonaws.services.glue.exceptions.InvalidInputException: Connection: does not exist"LAUNCH ERROR | Glue ETL Marketplace - failed to download connector.Please refer logs for details.AWS Glue supports one connection per job or development endpoint. If you specify more than one connection in a job, then AWS Glue uses only the first connection. If you must access more than one VPC, then see Connect to and run ETL jobs across multiple VPCs using a dedicated AWS Glue VPC.Related informationCreating ETL jobs with AWS Glue StudioFollow"


Question: I enabled public access on my bucket's ACL using the Amazon S3 console. Is my bucket open to everyone?

I used the Amazon Simple Storage Service (Amazon S3) console to update my bucket's access control list (ACL) to allow public access. Can anyone access my bucket?

Answer: "I used the Amazon Simple Storage Service (Amazon S3) console to update my bucket's access control list (ACL) to allow public access. Can anyone access my bucket?ResolutionEven if you enable all available ACL options in the Amazon S3 console, the ACL alone won't allow everyone to download objects from your bucket. However, depending on which option you select, any user could perform these actions:If you select List objects for the Everyone group, then anyone can get a list of objects that are in the bucket.If you select Write objects, then anyone can upload, overwrite, or delete objects that are in the bucket.If you select Read bucket permissions, then anyone can view the bucket's ACL.If you select Write bucket permissions, then anyone can change the bucket's ACL.For more information, see What permissions can I grant?To prevent any accidental change to public access on a bucket's ACL, you can configure public access settings for the bucket. If you select Block new public ACLs and uploading public objects, then users can't add new public ACLs or upload public objects to the bucket. If you select Remove public access granted through public ACLs, then all existing or new public access granted by ACLs is respectively overridden or denied.Important: Granting cross-account access through bucket and object ACLs doesn't work for buckets that have S3 Object Ownership set to Bucket Owner Enforced. In most cases, ACLs aren't required to grant permissions to objects and buckets. Instead, use AWS Identity Access and Management (IAM) policies and S3 bucket policies to grant permissions to objects and buckets.Related informationUsing Amazon S3 Block Public AccessManaging access with ACLsFollow"


Question: How do I configure a Lambda function to connect to an RDS instance?

I want my AWS Lambda function to connect to an Amazon Relational Database Service (Amazon RDS) instance.

Answer: "I want my AWS Lambda function to connect to an Amazon Relational Database Service (Amazon RDS) instance.Short descriptionNote: The following information and steps refer to Amazon RDS instances. However, the resolution also applies to any endpoint or database that's located in a virtual private cloud (VPC).To connect a Lambda function to an RDS instance, set the networking configurations to allow the connection.There are different configuration settings for each of the following connection types:A Lambda function and RDS instance in the same VPCA Lambda function and RDS instance in different VPCsFor security reasons, it's a best practice to keep your RDS instance in a VPC. For public databases, use a NoSQL database service such as Amazon DynamoDB.A Lambda function that's outside of a VPC can't access an RDS instance that's inside a VPC.For information on how to configure a Lambda function's network settings, see Configuring a Lambda function to access resources in a VPC. If the network settings are incorrect, then the Lambda function times out and displays a Task timed out error message.To connect a Lambda function to an Amazon Aurora DB cluster, use the Data API for Aurora Serverless.ResolutionImportant: Make sure that you change each Port Range, Source, and Destination setting that's provided in the following examples to match your own network configurations. Transmission Control Protocol (TCP) is the required protocol for each type of network configuration.A Lambda function and RDS instance in the same VPCWhen connecting a Lambda function to an RDS instance in the same VPC, use the following networking configurations.Note: By default, all subnets within a VPC contain a local route. The destination is the VPC's Classless Inter-Domain Routing (CIDR) and the target is local. For more information, see Route table concepts.1.    For Security Groups, use one of the following network settings:For instances that are attached to the same security group, make the security group the source for the inbound rule. Make the security group the destination for the outbound rule.For example, if the Lambda function and RDS instance are both in security group sg-abcd1234, then each instance has the following inbound and outbound rules.Example inbound rule for instances that are attached to the same security groupTypeProtocolPort RangeSourceCustom TCPTCP3306sg-abcd1234Example outbound rule for instances that are attached to the same security groupTypeProtocolPort RangeDestinationCustom TCPTCP3306sg-abcd1234-or-For instances in different security groups, make sure that both security groups allow access to each other.For example, if the Lambda function is in security group sg-1234 and the RDS instance is in sg-abcd, then each group has the following rules:Example outbound rule for a Lambda function in a different security group than the RDS instance that you want to connect it toTypeProtocolPort RangeDestinationCustom TCPTCP3306sg-abcdExample inbound rule for an RDS instance in a different security group than the Lambda function that you want to connect it toTypeProtocolPort RangeSourceCustom TCPTCP3306sg-1234Important: Make sure that the rules allow a TCP connection over the database's port.2.    For the network access control lists (NACLs), make sure that the inbound and outbound rules allow communication between the Lambda function and RDS instance.Note: By default, NACLs allow all inbound and outbound traffic. However, you can change these default settings.For each subnet that’s associated with the RDS instance and Lambda function, configure the NACLs to allow outbound TCP connection to the other instance’s subnets’ CIDRs.Note: The following example uses four example subnets that their CIDRs labeled:For the Lambda function's subnets, 172.31.1.0/24 and 172.31.0.0/28.For the RDS instance's subnets, 172.31.10.0/24 and 172.31.64.0/20.Example outbound rules for a Lambda function's subnets' NACLsTypeProtocolPort RangeDestinationAllow/DenyCustom TCPTCP3306172.31.10.0/24AllowCustom TCPTCP3306172.31.64.0/20AllowImportant: Apply the same Outbound rules to the NACLs of the RDS instance's subnets, but with the destination set as the Lambda's subnets' CIDRs.Make sure that the NACLs for each subnet have an inbound rule on the ephemeral ports over the CIDR range of the other instance's subnets.Example inbound rules for a Lambda function's subnets' NACLsTypeProtocolPort RangeSourceAllow/DenyCustom TCPTCP1024-65535172.31.10.0/24AllowCustom TCPTCP1024-65535172.31.64.0/20AllowImportant: Apply the same inbound rules to the NACLs of the RDS instance's subnets, but with the source set as the Lambda's subnets' CIDRs.A Lambda function and RDS instance in different VPCsFirst, use VPC peering to connect the two VPCs. Then, use the following networking configurations to connect the Lambda function in one VPC to the RDS instance in the other:Important: Be sure to turn on Domain Name System (DNS) for the VPC peering connection.1.    For the Route Table, confirm that the VPC peering connection is successful:For the Destination, look for the CIDR of the peered VPC.For the Target, look for the peering connection.Note: The following example includes two example VPCs:CIDR of source VPC (Lambda function): 10.0.0.0/16CIDR of peered VPC (RDS instance): 172.31.0.0/16Peering connection: pcx-01234abcdExample route table for a source VPC that's associated with the Lambda functionDestinationTarget172.31.0.0/16pcx-01234abcd10.0.0.0/16localExample route table for a peered VPC with an RDS instanceDestinationTarget10.0.0.0/16pcx-01234abcd172.31.0.0/16localFor more information, see Update your route tables for a VPC peering connection.2.    For Security Groups, use the following network settings:For the Lambda function's security group, make sure that traffic is allowed to go in and out of the CIDR of the RDS instance's VPC.Note: The following example includes two example subnets labeled by their CIDRs:For the RDS instance, 172.31.0.0/16For the Lambda function, 10.0.0.0/16Example outbound rule for a Lambda function in a different VPC than the RDS instanceTypeProtocolPort RangeDestinationCustom TCPTCP3306172.31.0.0/16For the RDS instance's security group, allow traffic to go in and out of the CIDR of the Lambda function's security group.Example inbound rule for an RDS instance in a different VPC than the Lambda functionTypeProtocolPort RangeSourceCustom TCPTCP330610.0.0.0/163.    For the NACLs, follow the previous procedures in step 3 of the A Lambda function and RDS instance in the same VPC section. The origin of the Lambda function's subnet CIDR is in a different VPC.Note: As an alternative to VPC peering, you can use AWS PrivateLink to access Amazon RDS across VPCs. This solution works across AWS accounts and VPCs in the same AWS Region.Follow"


Question: Why am I seeing "Error" in the Access field for some buckets in the Amazon S3 console?

I'm using the Amazon Simple Storage Service (Amazon S3) console to view buckets. Why am I seeing "Error" in the Access field for certain buckets?

Answer: "I'm using the Amazon Simple Storage Service (Amazon S3) console to view buckets. Why am I seeing "Error" in the Access field for certain buckets?ResolutionThe bucket list view in the Amazon S3 console includes an Access column that provides information about public access to each bucket. To see the Access value, the AWS Identity and Access Management (IAM) user or role using the console must have the following permissions to each bucket:s3:GetAccountPublicAccessBlocks3:GetBucketPublicAccessBlocks3:GetBucketPolicyStatuss3:GetBucketAcls3:ListAccessPointsIf the IAM identity (user or role) doesn't have the required permissions, then the identity sees "Error" in the Access field. This is also true if the identity explicitly is denied access to the required permissions.To allow an IAM identity to see Access values in the Amazon S3 console, add the required permissions to the user's or role's policy.Note: Because of eventual consistency, a bucket that recently was deleted might appear in the console with "Error" in the Access field. To confirm that a bucket was deleted, check the AWS CloudTrail event history for DeleteBucket events.Follow"


Question: How can I get my AWS::ECS::Service resources out of UPDATE_IN_PROGRESS or UPDATE_ROLLBACK_IN_PROGRESS status?

My AWS CloudFormation stack update to the AWS::ECS::Service resource got stuck in UPDATE_IN_PROGRESS or UPDATE_ROLLBACK_IN_PROGRESS status. I want to stabilize the stack and get my service to launch new tasks.

Answer: "My AWS CloudFormation stack update to the AWS::ECS::Service resource got stuck in UPDATE_IN_PROGRESS or UPDATE_ROLLBACK_IN_PROGRESS status. I want to stabilize the stack and get my service to launch new tasks.Short descriptionYour Amazon Elastic Container Service (Amazon ECS) service can get stuck in UPDATE_IN_PROGRESS or UPDATE_ROLLBACK_IN_PROGRESS status when the service fails to launch tasks.Here are some common reasons why an Amazon ECS service can fail to launch new tasks:Container image issuesA lack of necessary resources for launching tasksA health check failure on a load balancerInstance configuration or Amazon ECS container agent issuesAn Amazon ECS service that fails to launch tasks causes AWS CloudFormation to get stuck in UPDATE_IN_PROGRESS status. Then, AWS CloudFormation waits for several hours before rolling back to a previous configuration. If the issue that's causing stack failure continues during stack rollback to a previous configuration, then the stack gets stuck in UPDATE_ROLLBACK_IN_PROGRESS status. Finally, the stack changes to UPDATE_ROLLBACK_FAILED status.It can take the AWS CloudFormation stack several hours to stabilize. To stabilize your stack more quickly, complete the following steps.Important: The following resolution is intended to help you stabilize an AWS CloudFormation stack quickly without waiting for the stack to time out. The resolution isn't intended for production environments, as the Amazon ECS service is out of sync with the known state of AWS CloudFormation. To sync resources between your Amazon ECS service and the AWS CloudFormation stack, you must perform an error-free update on the stack.ResolutionChange the desired task count of the Amazon ECS serviceOpen the Amazon ECS console.Choose your cluster.Select the service, and then choose Update.Set Number of tasks to 0, and then save the configuration.Identify why the Amazon ECS service can't launch new tasksOpen the Amazon ECS console.Choose your cluster.Select the service, and then choose Events.Note: The Events section displays the reason why your service didn't stabilize.Choose a solution based on the issue that you identified:Your task failed Elastic Load Balancing (ELB) health checks.A container marked as essential for the task definition exited or died.You can't place a task because your container instance didn't meet the necessary requirements.You receive a "cannot pull container image" error.Follow"


Question: Why is the checkpoint in my Amazon Kinesis Data Analytics application failing?

The checkpoint or savepoint in my Amazon Kinesis Data Analytics application is failing.

Answer: "The checkpoint or savepoint in my Amazon Kinesis Data Analytics application is failing.Short descriptionCheckpointing is the method that is used for implementing fault tolerance in Amazon Kinesis Data Analytics for Apache Flink. Your application not being optimized or properly provisioned might result in checkpoint failures.Some of the major causes for checkpoint failures are the following:For Rocks DB, Apache Flink reads files from the local storage and writes to the remote persistent storage, that is Amazon Simple Storage Service (Amazon S3). The performance of the local disk and upload rate might impact checkpointing and result in checkpoint failures.Savepoint and checkpoint states are stored in a service-owned Amazon S3 bucket that's fully managed by AWS. These states are accessed whenever an application fails over. Transient server errors or latency in this S3 bucket might lead to checkpoint failures.A process function that you created where the function communicates with an external resource, such as Amazon DynamoDB, during checkpointing might result in checkpoint failures.Failure due to serialization of the state, such as serializer mismatch with the incoming data, can cause checkpoint failures.The number of Kinesis Processing Units (KPUs) provisioned for the application might not be sufficient. To find the allocated KPUs, use the following calculation:Allocated KPUs for the application = Parallelism / ParallelismPerKPULarger application state sizes might lead to an increase in checkpoint latency. This is because, the task manager takes more time to save the checkpoint, which can result in an out-of-memory exception.A skewed distribution of state could result in one task manager handling more data compared to other task managers. Even if sufficient KPUs(resources) are provisioned, one or more overloaded task managers can cause an out-of-memory exception.A high cardinality indicates that there is a large number of unique keys in the incoming data. If the job uses the KeyBy operator for partitioning the incoming data, and the key on which the data is partitioned has high cardinality, slow checkpointing might occur. This might eventually result in checkpoint failures.ResolutionThe size of your application state might increase rapidly, causing an increase in the checkpoint size and duration. You can monitor these values using the Amazon CloudWatch metrics lastCheckPointDuration and lastCheckpointSize. For more information, see Application metrics.Increase the parallelism of the operator that processes more data. You can define the parallelism for an individual operator, data source, or data sink by calling the setParallelism() method.Tune the values of Parallelism and ParallelismPerKPU for optimum utilization of KPUs. Be sure that automatic scaling isn't turned off for your Amazon Kinesis Data Analytics application. The value of the maxParallelism parameter allows you to scale to a desired number of KPUs. For more information, see Application Scaling in Kinesis Data Analytics for Apache Flink.Define TTL on the state to make sure that the state is periodically cleaned.Optimize the code to allow for better partitioning strategy. You can use rebalancing partitioning to help distribute the data evenly. This method uses a round robin method for distribution.Optimize the code to reduce the window size so that the cardinality of the number of keys in that window is reduced.Related informationApache Flink documentation for CheckpointsImplementing fault tolerance in Kinesis Data Analytics for Apache FlinkFollow"


Question: How can I troubleshoot the 404 "NoSuchKey" error from Amazon S3?

"My users are trying to access objects in my Amazon Simple Storage Service (Amazon S3) bucket. However, Amazon S3 is returning the 404 "NoSuchKey" error. How can I troubleshoot this error?"

Answer: "My users are trying to access objects in my Amazon Simple Storage Service (Amazon S3) bucket. However, Amazon S3 is returning the 404 "NoSuchKey" error. How can I troubleshoot this error?ResolutionAmazon S3 generally returns 404 errors if the requested object is missing from the bucket. Before users make GET or HEAD requests for an object, make sure that the object is created and available in the S3 bucket.To check if an object is available in a bucket, you can review the contents of the bucket from the Amazon S3 console. Or, you can run the head-object command using the AWS Command Line Interface (AWS CLI):aws s3api head-object --bucket awsexamplebucket --key object.jpgImportant: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Note that Amazon S3 delivers strong read-after-write consistency for all applications. After a successful write of a new object, or an overwrite or delete of an existing object, any subsequent read request immediately receives the latest version of the object. S3 also provides strong consistency for list operations. After a write, you can perform a listing of the objects in a bucket. For more information about S3 consistency, see Consistency.If the requested object was available in the S3 bucket for some time and you receive a 404 NoSuchKey error again, then check the following:Confirm that the request matches the object name exactly, including the capitalization of the object name. Requests for S3 objects are case sensitive. For example, if an object is named myimage.jpg, but Myimage.jpg is requested, then requester receives a 404 NoSuchKey error.Confirm that the requested path matches the path to the object. Otherwise, the requester receives a 404 NoSuchKey error.If the path to the object contains any spaces, be sure that the request uses the correct syntax to recognize the path. For example, if you're using the AWS CLI to download an object to your Windows machine, you must use quotation marks around the object path. The object path must look like this: aws s3 cp "s3://awsexamplebucket/Backup Copy Job 4/3T000000.vbk".Check the object name for any special characters or URL-encoded characters that are difficult to see, such as carriage returns (\r) or new lines (\n). For example, the object name test with a carriage return at the end shows as test%0A in the Amazon S3 console. To check object names for special characters, you can run the list-objects-v2 command with the parameter --output json. The JSON output makes characters like returns (\r) visible. If an object name has a special character that's not always visible, remove the character from the object name. Then, try accessing the object again.Optionally, you can enable server access logging to review request records in further detail for issues that might be causing the 404 NoSuchKey error.Note: If an object is missing from the bucket and the requester doesn’t have s3:ListBucket access, then the requester will receive a 403 Access Denied error. If you receive a 403 Access Denied error, resolve the issue related to the missing object.Related informationTroubleshooting Amazon S3Follow"


Question: How do I set up the AWS Load Balancer Controller on an Amazon EKS cluster for Fargate and deploy the 2048 game?

"I want to set up the AWS Load Balancer Controller on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for AWS Fargate. Then, I want to deploy the 2048 game."

Answer: "I want to set up the AWS Load Balancer Controller on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for AWS Fargate. Then, I want to deploy the 2048 game.Short descriptionYou can set up AWS Load Balancer Controller without any existing Application Load Balancer (ALB) Ingress Controller deployments.Before setting up the AWS Load Balancer Controller on a new Fargate cluster, consider the following:Uninstall the AWS ALB Ingress Controller for Kubernetes. The AWS Load Balancer Controller replaces the functionality of the AWS ALB Ingress Controller.Use eksctl version 0.109.0 or greater.Install Helm on the workstation.The --region variable isn't always used in the commands because the default value for your AWS Region is used. To check the default value, run the aws configure command. To change the AWS Region, use the --region flag.Amazon EKS on Fargate is available in all AWS Regions, except AWS GovCloud (US-East) and AWS GovCloud (US-West).Replace placeholder values in code snippets with your own values.ResolutionCreate an Amazon EKS cluster, service account policy, and role-based access control (RBAC) policies1.    To use eksctl to create an Amazon EKS cluster, run the following command:eksctl create cluster --name YOUR_CLUSTER_NAME --version 1.23 --fargateNote: You don't need to create a Fargate pod execution role for clusters that use only Fargate pods (--fargate).2.    Allow the cluster to use AWS Identity and Access Management (IAM) for service accounts by running the following command:eksctl utils associate-iam-oidc-provider --cluster YOUR_CLUSTER_NAME --approveNote: The FargateExecutionRole is the role that's used for the kubelet and kube-proxy to run your Fargate pod on. However, it's not the role used for the Fargate pod (that is, the aws-load-balancer-controller). For Fargate pods, you must use the IAM role for the service account. For more information, see IAM roles for service accounts.3.    To download an IAM policy that allows the AWS Load Balancer Controller to make calls to AWS APIs on your behalf, run the following command:curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/install/iam_policy.json4.    To create an IAM policy using the policy that you downloaded in step 3, run the following command:aws iam create-policy \   --policy-name AWSLoadBalancerControllerIAMPolicy \   --policy-document file://iam_policy.json5.    To create a service account named aws-load-balancer-controller in the kube-system namespace for the AWS Load Balancer Controller, run the following command:eksctl create iamserviceaccount \  --cluster=YOUR_CLUSTER_NAME \  --namespace=kube-system \  --name=aws-load-balancer-controller \  --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \  --override-existing-serviceaccounts \  --approve6.    To verify that the new service role is created, run one of the following commands:eksctl get iamserviceaccount --cluster YOUR_CLUSTER_NAME --name aws-load-balancer-controller --namespace kube-system-or-kubectl get serviceaccount aws-load-balancer-controller --namespace kube-systemInstall the AWS Load Balancer Controller using HelmImportant: For more information, see cert-manager on the Jetstack GitHub website and the discussion topic Cert-manager issues with Fargate on the Kubernetes GitHub website.1.    To add the Amazon EKS chart repo to Helm, run the following command:helm repo add eks https://aws.github.io/eks-charts2.    To install the TargetGroupBinding custom resource definitions (CRDs), run the following command:kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller//crds?ref=master"3.    To install the Helm chart, run the following command:helm install aws-load-balancer-controller eks/aws-load-balancer-controller \    --set clusterName=YOUR_CLUSTER_NAME \    --set serviceAccount.create=false \    --set region=YOUR_REGION_CODE \    --set vpcId=<VPC_ID> \    --set serviceAccount.name=aws-load-balancer-controller \    -n kube-systemTest the AWS Load Balancer ControllerYou can use the AWS Load Balancer Controller to create either an Application Load Balancer for Ingress or a Network Load Balancer for creating a k8s service. To deploy a sample app called 2048 with Application Load Balancer Ingress, do the following:1.    To create a Fargate profile that's required for the game deployment, run the following command:eksctl create fargateprofile --cluster your-cluster --region your-region-code --name your-alb-sample-app --namespace game-20482.    To deploy the sample game and verify that the AWS Load Balancer Controller creates an ALB Ingress resource, run the following command:kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/examples/2048/2048_full.yaml3.    After a few minutes, verify that the Ingress resource was created by running the following command:kubectl get ingress/ingress-2048 -n game-2048Output:NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGEingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.us-east-2.elb.amazonaws.com   80      2m32sNote: If your Ingress isn't created after several minutes, view the AWS Load Balancer Controller logs by running the following command:kubectl logs -n kube-system deployment.apps/aws-load-balancer-controllerNote: Your logs might contain error messages that can help you diagnose issues with your deployment.4.    Open a browser, and navigate to the ADDRESS URL from the previous command output to view the sample application.Note: If you don't see the sample application, then wait a few minutes and refresh your browser.Deploy a sample application with the Network Load Balancer IP address mode serviceTo use the Network Load Balancer IP address mode, you must have a cluster running at least Kubernetes v1.16 or higher.1.    To create a Fargate profile, run the following command:eksctl create fargateprofile --cluster your-cluster --region your-region-code --name your-alb-sample-app --namespace game-20482.    To get the manifest for deploying the 2048 game, run the following command:curl -o 2048-game.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/examples/2048/2048_full.yaml3.    In the manifest from step 2, delete this Ingress section:apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  namespace: game-2048  name: ingress-2048  annotations:    alb.ingress.kubernetes.io/scheme: internet-facing    alb.ingress.kubernetes.io/target-type: ipspec:ingressClassName: alb  rules:    - http:        paths:          - path: /            pathType: Prefix            backend:              service:                name: service-2048                           port:                  number: 804.    Modify the Service object:apiVersion: v1kind: Servicemetadata:  namespace: game-2048  name: service-2048  annotations:    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"    service.beta.kubernetes.io/aws-load-balancer-type: external    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facingspec:  ports:    - port: 80      targetPort: 80      protocol: TCP  type: LoadBalancer  selector:    app.kubernetes.io/name: app-20485.    To create the service and deployment manifest, run the following command:kubectl apply -f 2048-game.yaml6.    To check for service creation and the DNS name of the Network Load Balancer, run the following command:kubectl get svc -n game-2048Output:NAME           TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)        AGEservice-2048   LoadBalancer   10.100.114.197   k8s-game2048-service2-xxxxxxxxxx-yyyyyyyyyy.us-east-2.elb.amazonaws.com   80:30159/TCP   23m7.    Wait a few minutes until the load balancer is active. Then, to check that you can reach the deployment, open the fully qualified domain name (FQDN) of the NLB that's referenced in the EXTERNAL-IP section in a web browser.Troubleshoot the AWS Load Balancer ControllerIf you have issues setting up the controller, then run the following commands:$ kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller$ kubectl get endpoints -n game-2048$ kubectl get ingress/ingress-2048 -n game-2048The output from the logs command returns error messages (for example, with tags or subnets). These error messages can help you troubleshoot common errors (from the Kubernetes GitHub website). The get endpoints command shows you if the backed deployment pods are correctly registered. The get ingress commands show you if Ingress resources are deployed.Follow"


Question: How do I set up LinkedIn as a social identity provider in an Amazon Cognito user pool?

I want my app's users to be able to sign in using LinkedIn. How do I set up LinkedIn as a social identity provider (IdP) in an Amazon Cognito user pool?

Answer: "I want my app's users to be able to sign in using LinkedIn. How do I set up LinkedIn as a social identity provider (IdP) in an Amazon Cognito user pool?Short descriptionLinkedIn doesn't provide all the fields that Amazon Cognito requires when adding an OpenID Connect (OIDC) provider to a user pool.You must use a third-party service as a middle agent between LinkedIn and Amazon Cognito, such as Auth0. Auth0 gets identities from LinkedIn, and Amazon Cognito then gets those identities from Auth0.Note: Auth0 is a third-party service that's not affiliated with AWS. You might incur separate fees using Auth0.You can also use this setup for other social IdPs with similar integration issues. For more information, see Identity providers  on the Auth0 website.ResolutionCreate an Amazon Cognito user pool with an app client and domain nameFor more information on creating these prerequisites, see the following articles:Tutorial: Creating a user poolImportant: When creating a user pool, keep the standard attribute email selected.Configuring a user pool app clientAdding a domain name for your user poolSign up for an Auth0 accountEnter your email address and a password on the Auth0 website sign-up page to get started. Or, if you already have an Auth0 account, log in. After logging in, take note of your Auth0 tenant name.Create an Auth0 applicationOn the Auth0 website dashboard, choose + Create Application.Note: If you've already created the Auth0 application you want to use, continue to the next section.In the Create Application dialog box, enter a name for your application. For example, My App.Under Choose an application type, choose Single Page Web Applications.Choose Create.On the Settings pane of your new application, do the following:Find the Client ID and Client Secret and copy them. You'll need these later when connecting Auth0 to your Amazon Cognito user pool.For Allowed Callback URLs, enter https://yourDomainPrefix.auth.region.amazoncognito.com/oauth2/idpresponse.Note: Replace yourDomainPrefix and region with the values for your user pool. Find them in the Amazon Cognito console on the Domain name tab of the management page for your user pool.Choose Save changes.Sign up for a LinkedIn accountEnter your email address and a password on the LinkedIn website sign up page to get started. Or, sign in if you already have a LinkedIn account.Create a LinkedIn appOn the LinkedIn Developers website, choose Create app.On the Create an app page, complete all required and preferred fields to customize your LinkedIn app, and then choose Create app.Choose the Auth tab. Confirm that r_emailaddress and r_liteprofile are listed. These permissions are required for Auth0 to access the required LinkedIn user info.Note: If you don't see the r_emailaddress and r_liteprofile listed, then add the product "Sign In with LinkedIn" to your application. This is found on the Products tab of your LinkedIn Dev page.Under Application credentials, find the Client ID and Client Secret and copy them. You need both of these later when connecting LinkedIn to your Auth0 app.Under OAuth 2.0 settings, next to Redirect URLs:, choose the pencil icon, and then choose + Add redirect URL.Under Redirect URLs:, enter https://tenantName.us.auth0.com/login/callback, replacing tenantName with your Auth0 tenant name (or an Auth0 custom domain).Connect to LinkedIn from Auth0On the Auth0 website dashboard, in the left navigation pane, choose Authentication, and then choose Social.Choose LinkedIn.On the Settings pane of the LinkedIn dialog box, do the following:For API Key, enter the Client ID that you copied earlier from your LinkedIn app.For Secret Key, enter the Client Secret that you copied earlier from your LinkedIn app.For Attributes, select the Email address check box.Choose Save.On the Applications pane of the LinkedIn dialog box, choose the applications that you want to enable LinkedIn as a social IdP for.Choose Save.Test your LinkedIn social connection with Auth0In the LinkedIn dialog box, choose Try. Or, on the Auth0 website dashboard, in the left navigation pane, choose Connections, choose Social, and then next to LinkedIn, choose Try. A new browser tab or window opens to the LinkedIn sign-in page.Sign in to LinkedIn with your email address and password.When prompted to allow your app to access your LinkedIn user info, choose Allow.Add an OIDC provider to your user poolIn the Amazon Cognito console management page for your user pool, under Federation, choose Identity Providers.Choose OpenID Connect.Enter the details of your Auth0 app for the OIDC provider details, as follows:For Provider name, enter a name (for example, Auth0-LinkedIn). This name appears in the Amazon Cognito hosted web UI.Note: You can't change this field after creating the provider.For Client ID, enter the Client ID that you copied earlier from your Auth0 application.For Client secret (optional), enter the Client Secret that you copied earlier from your Auth0 application.For Attributes request method, leave the setting as GET.For Authorize scope, enter openid profile email.For Issuer, enter the URL of your Auth0 profile. For example, https://tenantName.auth0.com, replacing tenantName with your Auth0 tenant name.For Identifiers (optional), you can optionally enter a custom string to use later in the endpoint URL in place of your OIDC provider's name.Choose Run discovery to fetch the OIDC configuration endpoints for Auth0.Choose Create provider.For more information, see Add an OIDC IdP to your user pool.Change app client settings for your user poolIn the Amazon Cognito console management page for your user pool, under App integration, choose App client settings.On the app client page, do the following:Under Enabled Identity Providers, select the OIDC provider (for example, Auth0-LinkedIn) and Cognito User Pool check boxes.For Callback URL(s), enter a URL where you want your users to be redirected after logging in. For testing, you can enter any valid URL, such as https://example.com/.For Sign out URL(s), enter a URL where you want your users to be redirected after logging out. For testing, you can enter any valid URL, such as https://example.com/.Under Allowed OAuth Flows, select either the Authorization code grant or Implicit grant check box, or both.Note: The allowed OAuth flows you enable determine which values ("code" or "token") you can use for the response_type parameter in your endpoint URL.Under Allowed OAuth Scopes, select at least the email and openid check boxes.Choose Save changes.For more information, see App client settings terminology.Map the attributes from Auth0 to your user poolIn the Amazon Cognito console management page for your user pool, under Federation, choose Attribute mapping.On the attribute mapping page, choose the OIDC tab.If you have more than one OIDC provider in your user pool, choose your new provider from the dropdown list.Confirm that the OIDC attribute sub is mapped to the user pool attribute Username.Choose Add OIDC attribute. For the new OIDC attribute, enter email. For User pool attribute, choose Email.(Optional) Add any additional OIDC attributes you want to pass along from Auth0. For example, you might map given_name and family_name to the corresponding Amazon Cognito user pool attributes.Note: To see all the OIDC attributes stored for an Auth0 user, from the Auth0 website dashboard, in the left navigation pane, choose Users & Roles, choose Users, choose a user, and then choose Raw JSON.For more information, see Specifying identity provider attribute mappings for your user pool.Construct the endpoint URLUsing values from your own setup, construct this endpoint URL:https://yourDomainPrefix.auth.region.amazoncognito.com/oauth2/authorize?response_type=code&client_id=yourClientId&redirect_uri=redirectUrlDo the following to customize the URL for your setup:Replace yourDomainPrefix and region with the values for your user pool. Find them in the Amazon Cognito console on the Domain name tab of the management page for your user pool.If you selected only the Implicit grant flow earlier for Allowed OAuth Flows, then change response_type=code to response_type=token.Replace yourClientId with your app client's ID, and replace redirectUrl with your app client's callback URL. Find them in the Amazon Cognito console on the App client settings tab of the management page for your user pool.For more information, see How do I configure the hosted web UI for Amazon Cognito? and Authorize endpoint.Test the endpoint URLEnter the constructed endpoint URL in your web browser.Under Sign in with your corporate ID, choose the name of your OIDC provider (for example, Auth0-LinkedIn). You're redirected to the log-in page for your Auth0 application.Choose Log in with LinkedIn. You're redirected to the LinkedIn sign-in page.Note: If you're redirected to your Amazon Cognito app client's callback URL instead, then you're already signed in to LinkedIn.On the LinkedIn sign-in page, enter the email address (or phone number) and password for your LinkedIn account.Choose Sign in.After you log in successfully, you're redirected to your app client's callback URL. The authorization code or user pool tokens appear in the URL in your web browser's address bar.(Optional) Skip the Amazon Cognito hosted UIIf you want your users to skip the Amazon Cognito hosted web UI when signing in to your app, use this as the endpoint URL instead:https://yourDomainPrefix.auth.region.amazoncognito.com/oauth2/authorize?response_type=code&identity_provider=oidcProviderName&client_id=yourClientId&redirect_uri=redirectUrl&scope=allowedOauthScopesDo the following to customize the URL for your setup:Replace yourDomainPrefix and region with the values for your user pool. Find them in the Amazon Cognito console on the Domain name tab of the management page for your user pool.If you selected only the Implicit grant flow earlier for Allowed OAuth Flows, change response_type=code to response_type=token.Replace oidcProviderName with the name of the OIDC provider in your user pool. For example, Auth0-LinkedIn.(Optional) If you added an identifier for your OIDC provider earlier in the Identifiers (optional) field, you can replace identity_provider=oidcProviderName with **idp_identifier=**idpIdentifier, replacing idpIdentifier with your custom identifier string.Replace yourClientId with your app client's ID, and replace redirectUrl with your app client's callback URL. Find them in the Amazon Cognito console on the App client settings tab of the management page for your user pool.Replace allowedOauthScopes with the specific scopes that you want your Amazon Cognito app client to request.Related informationOIDC user pool IdP authentication flowHow do I set up Auth0 as a SAML identity provider with an Amazon Cognito user pool?Add an app client and set up the hosted UIFollow"


Question: How can I access my Amazon SES logs?

"I send emails using Amazon Simple Email Service (Amazon SES), and I want to get logs or notifications for bounces, complaints, delivery, failures, or rejections."

Answer: "I send emails using Amazon Simple Email Service (Amazon SES), and I want to get logs or notifications for bounces, complaints, delivery, failures, or rejections.Short descriptionTo get logs or notifications about your email-sending events on Amazon SES, use one of the following mechanisms:Email feedback forwardingAmazon Simple Notification Service (Amazon SNS) topic for event notificationsConfiguration set to publish email-sending events to Amazon SNS, Amazon CloudWatch, Amazon Pinpoint, or Amazon Kinesis Data FirehoseNote: These mechanisms don't provide logs for emails that you sent before you implemented the mechanism.ResolutionUse email feedback forwardingBy default, Amazon SES sends you a notification when a message that you send bounces or gets a complaint. The destination that you check for the bounce or complaint notifications depends on your email-sending operation. For more information, see Email feedback forwarding destination.If you de-activated email feedback forwarding, then you can re-activate feedback forwarding using the Amazon SES console.Use an Amazon SNS topic to send event notificationsYou can use an Amazon SNS topic for notifications about Amazon SES email delivery, bounces, or complaints.Follow these steps to configure an Amazon SNS topic for Amazon SES events:Create an Amazon SNS topic.Subscribe an endpoint (such as an email address) to receive notifications from the Amazon SNS topic.Configure your Amazon SES verified identity (domain or email address) to send event notifications to the Amazon SNS topic that you created. You can do this using either the Amazon SES console or the Amazon SES API.After you configure an Amazon SNS topic for Amazon SES event notifications, you receive notifications at the endpoint that you subscribed to the topic. For more information on the details in the notifications, see Amazon SNS notification contents for Amazon SES and Amazon SNS notification examples for Amazon SES.Note: Amazon SES doesn't support FIFO type topics.Use a configuration set to publish email-sending events to Amazon SNS, CloudWatch, Amazon Pinpoint, or Kinesis Data FirehoseUse an Amazon SES configuration set that publishes events to get information about the following outcomes:SendsRejectsHard bouncesComplaintsDeliveriesDelivery delaysSubscriptionsOpensClicksRendering failuresFor details about each outcome, see Event publishing terminology.To create the configuration set, first specify the event destination, and then specify the parameters for the events that you want to publish. For step-by-step instructions, see Setting up Amazon SES event publishing.Make sure that you configure your email-sending method to pass the name of the configuration set in the headers of your emails. This is required for Amazon SES to apply the configuration set to your emails. For more information, see Specifying a configuration set when you send email. You can also assign a default configuration set to the verified identity that's used as the From/Source address. Then, messages that you send from this identity automatically use the assigned default configuration set.Follow"


Question: How do I make sure I don't incur charges when I'm using the AWS Free Tier?

I'm using the AWS Free Tier to test AWS services and want to make sure that all the resources that I'm using are covered under the AWS Free Tier.

Answer: "I'm using the AWS Free Tier to test AWS services and want to make sure that all the resources that I'm using are covered under the AWS Free Tier.Short descriptionYou can help avoid unnecessary charges when using the Free Tier by following these best practices:Understand what services and resources are covered by the AWS Free Tier.Monitor Free Tier usage with AWS Budgets.Monitor costs in the Billing and Cost Management console.Find and terminate resources when you're done using them.Important: The AWS Free Tier makes certain amounts and types of resources for new AWS accounts available free of charge for a one-year period. Any amounts and types of resources that aren't covered are charged at standard rates.ResolutionUnderstand what services and resources are coveredBefore you create any new resources, do the following:Access the list of covered services and resources at AWS Free Tier.Scroll down to see the Free Tier details listing.Use the filter options or search to locate a specific service.Choose the service to expand the tile and view specific usage limits.Important: Not all AWS services are covered under Free Tier. Some services launched under the Free Tier have usage limits. If you exceed the usage limits, then you are charged at standard rates.Use AWS Budgets to monitor your Free Tier usageYou can track your Free Tier usage with the AWS Free Tier usage alerts. These alerts notify you when your free tier usage exceeds 85 percent of your monthly limit.To opt in to the AWS Free Tier usage alerts, do the following:Sign in to the AWS Management Console, and then open the Billing and Cost Management console.Under Preferences in the navigation pane, choose Billing preferences.Under Cost Management Preferences, select Receive AWS Free Tier Usage Alerts to opt in to Free Tier usage alerts.Monitor your billTrack your AWS Free Tier usage in your Billing and Cost Management console to see how much of the AWS Free Tier that you're currently using. You can use the Top AWS Free Tier Services by Usage table to check if your current usage rate will incur charges.Check your usage in the Billing and Cost Management console. Even if your resources are covered under the AWS Free Tier, you see a line item on your bill for each covered resource.Note: Most benefits offered by the AWS Free Tier apply globally to all resources on your account, not individually to each AWS Region. Be sure to monitor your usage in all AWS Regions.Find and terminate resources when you're done using themTo avoid incurring unexpected charges, it's a best practice to routinely check if you have active resources that you no longer need. Then, terminate these unneeded resources.To find your active test resources, see How do I check for active resources that I no longer need on my AWS account?To terminate your resources after testing, see How do I terminate active resources that I no longer need on my AWS account?Related informationUsing the AWS Free TierAWS Free Tier FAQsCreating a billing alarm to monitor your estimated AWS chargesI unintentionally incurred charges while using the AWS Free Tier. How do I make sure that I'm not billed again?What do I need to know if my Free Tier period with AWS is expiring?Follow"


Question: How can I configure automatic scaling in Amazon EMR?

I want to use Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling on an Amazon EMR cluster.

Answer: "I want to use Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling on an Amazon EMR cluster.Short descriptionAmazon EMR versions 5.30.0, 6.1.0, and later: Use Amazon EMR managed scaling. Or, use automatic scaling with a custom policy for instance groups.Amazon EMR versions 4.0.0-5.29.0 and 6.0.0: Use automatic scaling with a custom policy for instance groups.ResolutionAmazon EMR versions 5.30.0, 6.1.0, and laterIf you're using Amazon EMR 5.30.0, 6.1.0, or later versions, then you have two options for automatic scaling: turn on Amazon EMR managed scaling to automatically increase or decrease the number of instances or units in your cluster based on workload. Or, use automatic scaling with a custom policy for instance groups, as explained in the following section.Amazon EMR versions 4.0.0 and laterFollow the steps at Using automatic scaling with a custom policy for instance groups. For information about the Amazon CloudWatch metrics that you can use for automatic scaling in Amazon EMR, see Monitor metrics with CloudWatch. The following are two commonly used metrics for automatic scaling:YarnMemoryAvailablePercentage: This is the percentage of remaining memory that's available for YARN.ContainerPendingRatio: This is the ratio of pending containers to allocated containers. You can use this metric to scale a cluster based on container-allocation behavior for varied loads. This is useful for performance tuning.To confirm that the scaling policy is attached to the instance group, choose Events from the navigation pane.Check for automatic scaling policy events.Related informationScaling cluster resourcesFollow"


Question: How do I increase Amazon WorkSpaces quotas?

I want to increase my service quota for Amazon WorkSpaces. How can I do this?

Answer: "I want to increase my service quota for Amazon WorkSpaces. How can I do this?Short descriptionAmazon WorkSpaces-based resources in your AWS account have default quotas (also known as service limits). For more information, see Amazon WorkSpaces quotas.ResolutionTo request a quota increase, do the following:Open the WorkSpaces Limits form.Select the Region.Select the Limit type you're requesting a quota increase for. For example, Max WorkSpaces.Note: Graphics and Graphics Pro bundles are supported in the following Regions: US East (N. Virginia), US West (Oregon), EU (Ireland), EU (Frankfurt), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Asia Pacific (Singapore). You can request quota increases for Graphics and Graphics Pro in these Regions only.Enter the New Limit Value.Select Add another request to enter another increase request for the same limit type.Enter the Use Case Description explaining why you're requesting a limit increase.Note: Request for more than 200 WorkSpaces or more than 20 Graphics/Graphics Pro WorkSpaces require additional information. Make sure you answer the additional questions listed within the request form in your use case description.Enter Contact options.Select Submit.Related informationTroubleshoot WorkSpaces issuesFollow"


Question: Why is my MySQL DB instance showing a high number of active sessions waiting on SYNCH wait events in Performance Insights?

"When I activate Performance Insights, my DB instance shows a large number of Average Active Sessions (AAS) waiting on synchronization (SYNCH) wait events. I want to improve the performance of my DB instance."

Answer: "When I activate Performance Insights, my DB instance shows a large number of Average Active Sessions (AAS) waiting on synchronization (SYNCH) wait events. I want to improve the performance of my DB instance.Short descriptionPerformance Insights are activated on any of the following services:Amazon Relational Database Service (Amazon RDS) for MySQL.Amazon RDS for MariaDB.Amazon Aurora MySQL-Compatible Edition.If you see MySQL SYNCH wait events in Performance Insights, then a large number of sessions in the database are attempting to access the same protected objects or memory structures. Protected objects in MySQL include the following:The active binary log file in a binlog source instance - contains a mutex that allows only one session to read or write it at a time.The data dictionary - for writes that are usually caused by data control language (DCL) or data definition language (DDL) statements.The adaptive hash index- contains a mutex that allows only one session to read or write it at a time.The open table cache - only one session can add or remove a table from the cache.Each single database block inside the InnoDB Buffer Pool - only one session can modify the content of a block in memory at a time.ResolutionMake sure that the DB instance has enough CPU resources to handle the workloadIf you have a high number of sessions waiting on SYNCH events, then this causes high CPU usage. If the usage hits 100%, then the number of waiting sessions increases. When troubleshooting, increase the size of your DB instance to make sure that there is enough CPU to process the extra workload.Because these events are usually short-lived, the Amazon CloudWatch CPU utilization metric might not show the peak usage correctly. The best way to check this is to use the one-second CPU counters in RDS Enhanced Monitoring. These counters are more specific and detailed.Increase MySQL's mutex/lock wait arrayMySQL uses an internal data structure to coordinate threads. This array has a size of one, by default. This is suitable for single-CPU machines, but it can cause issues on machines with several CPUs. If your workload has a large number of waiting threads, then increase the array size. Set the MYSQL parameter innodb_sync_array_size to the amount of CPUs (or higher, up to 1024).Note: The innodb_sync_array_size parameter applies only at database start up.Reduce concurrencyIn general, parallelism helps to improve throughput. But when a large number of sessions try to do the same or similar activities, then the sessions need access to the same protected objects. The higher the number of sessions, the more CPU you use while waiting.Spread these activities over time, or schedule them in series. You can also bundle several operations into a single statement, such as multi-row inserts.Examine specific wait eventsUse the following examples to troubleshoot your specific wait event. For more information on Aurora MySQL wait events, see Tuning Aurora MySQL with wait events.synch/rwlock/innodb/dict sys RW lock, ORsynch/rwlock/innodb/dict_operation_lock - This indicates a high number of concurrent DCLs of DDLs are triggered at the same time. Reduce the application's dependency on using DDLs during regular application activity.synch/cond/sql/MDL_context::COND_wait_status - This indicates a high number of SQLs (including selects) trying to access a table that a DCL or DDL is modifying. Avoid running DDL statements to high-traffic tables during regular application activity.synch/mutex/sql/LOCK_open, ORsynch/mutex/sql/LOCK_table_cache - This indicates that the number of tables that your sessions are opening exceeds the size of the table definition cache or the table open cache. Increase the size of these caches.synch/mutex/sql/LOG - Your database might be executing a large number of statements, and the current logging methods can't support it. If you use the TABLE output method, then try to use FILE instead. If you use general log, then use Amazon Aurora's advanced auditing instead. If you use 0 or less than 1 for the long_query_time parameter, then try to increase it.synch/mutex/innodb/buf_pool_mutex,OR synch/mutex/innodb/aurora_lock_thread_slot_futex,OR synch/rwlock/innodb/index_tree_rw_lock - There are a large number of similar DMLs accessing the same database object at the same time. Use multi-row statements, and use partitioning to spread the workload over different database objects.synch/mutex/innodb/aurora_lock_thread_slot_futex - This occurs when one session has locked a row for an update, and then another session tries to update the same row. Your action depends on the other wait events that you see. Either find and respond to the SQL statements responsible for this wait event, or find and respond to the blocking session.synch/cond/sql/MYSQL_BIN_LOG::COND_done, ORsynch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit, ORsynch/mutex/sql/MYSQL_BIN_LOG::LOCK_log - You have turned on binary logging, and there might be one of the following:                         - a high commit throughput.                         - a large number of transactions committing.                         - replicas reading binlogs.                         - a combination of these.Consider upgrading the database to a major version compatible with 5.7 or higher. Also, use multi-row statements, or bundle several statements into a single transaction. In Amazon Aurora, use global databases instead of binary log replication, or use the aurora_binlog parameters.Related informationUsing Amazon RDS performance insightsWorking with DB parameter groupsAurora MySQL eventsFollow"


Question: How can I troubleshoot connectivity to an Amazon RDS DB instance that uses a public or private subnet of a VPC?

I can't connect to my Amazon Relational Database Service (Amazon RDS) DB instance. How can I troubleshoot connectivity issues in a public or private subnet of an Amazon Virtual Private Cloud (Amazon VPC)?

Answer: "I can't connect to my Amazon Relational Database Service (Amazon RDS) DB instance. How can I troubleshoot connectivity issues in a public or private subnet of an Amazon Virtual Private Cloud (Amazon VPC)?Short descriptionYou can launch Amazon RDS databases in the public or private subnet of a VPC. However, incorrect VPC configuration on the RDS instance side can cause connection problems. Or, configuration or connectivity issues on the client that you are connecting from might also cause connection problems.To resolve these issues, see the following resolutions depending on your environment.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.My DB instance is in a public subnet, and I can't connect to it over the internet from my local computerThis issue can occur when the Publicly Accessible property of the DB instance is set to No. To check whether a DB instance is publicly accessible:Open the Amazon RDS console, select Databases from the navigation pane, and select your DB instance. Then, review the Connectivity & Security section of your instance.-or-Use the describe-db-instances command in the AWS CLI.To change the Publicly Accessible property of the Amazon RDS instance to Yes:1.    Open the Amazon RDS console.2.    Choose Databases from the navigation pane, and then select the DB instance.3.    Choose Modify.4.    Under Connectivity, extend the Additional configuration section, and then choose Publicly accessible.5.    Choose Continue.6.    Choose Modify DB Instance.Note: This change is applied immediately, even if you don't select the Apply Immediately option. Downtime occurs only if you have pending maintenance action set up with this modification, which requires downtime, and you choose Apply Immediately.If you set the Publicly Accessible property to Yes and you're still unable to connect to your RDS instance, then check these details:Verify that your VPC has an internet gateway attached to it.Make sure that the inbound rules for the security group of your RDS instance allow connections from your source IP.My DB instance is in a private subnet, and I can't connect to it from my local computerYou can resolve this issue by using a public subnet. When you use a public subnet, all the resources on the subnet are accessible from the internet. If this solution doesn't meet your security requirements, then use AWS Site-to-Site VPN. With Site-to-Site VPN, you configure a customer gateway that allows you to connect your VPC to your remote network.Another method to resolve this issue is using an Amazon EC2 instance as a bastion (jump) host. For more information, see How can I connect to a private Amazon RDS DB instance from a local machine using an Amazon EC2 instance as a bastion host?To switch to a public subnet:1.    Open the Amazon RDS console.2.    Choose Databases from the navigation pane, and then choose the DB instance.3.    From the Connectivity & Security section, copy the endpoint of the DB instance.4.    Perform an nslookup to the DB instance endpoint from an EC2 instance within the VPC. See the following example output:nslookup myexampledb.xxxx.us-east-1.rds.amazonaws.comServer: xx.xx.xx.xxAddress: xx.xx.xx.xx#53Non-authoritative answer:Name: myexampledb.xxxx.us-east-1.rds.amazonaws.comAddress: 172.31.xx.x5.    After you have the private IP address of your RDS DB instance, you can relate the private IP address to a particular subnet in the VPC. The VPC subnet is based on the subnet CIDR range and private IP address.6.    Open the Amazon VPC console, and then choose Subnets from the navigation pane.7.    Choose the subnet that is associated to the DB instance that you found in step 5.8.    From the Description pane, choose the Route Table.9.    Choose Actions, and then choose Edit routes.10.    Choose Add route. For IPv4 and IPv6 traffic, in the Destination box, enter the routes for your external or on-premises network. Then, select the internet gateway ID in the Target list.Note: Be sure that the Inbound security group rule for your instance restricts traffic to the addresses of your external or on-premises network.    11.    Choose Save.Important: If you change a subnet to public, then other DB instances in the subnet also become accessible from the internet. The DB instances are accessible from the internet if they have an associated public address.If the DB instance still isn't accessible after following these steps, check to see if the DB instance is Publicly Accessible. To do this, follow the steps in My DB instance is in a private subnet, and I can't connect to it from my local computer.My DB instance can't be accessed by an Amazon EC2 instance from a different VPCCreate a VPC peering connection between the VPCs. A VPC peering connection allows two VPCs to communicate with each other using private IP addresses.1.    Create and accept a VPC peering connection.Important: If the VPCs are in the same AWS account, be sure that the IPv4 CIDR blocks don't overlap. For more information, see VPC peering limitations.2.    Update both route tables.3.    Update your security groups to reference peer VPC groups.4.    Activate DNS resolution support for your VPC peering connection.5.    On the Amazon Elastic Compute Cloud (Amazon EC2) instance, test the VPC peering connection by using a networking utility. See the following example:nc -zv <hostname> <port>If the connection is working, then the output looks similar to the following:$ nc -zv myexampledb.xxxx.us-east-1.rds.amazonaws.com 5439found 0 associationsfound 1 connections:     1:    flags=82<CONNECTED,PREFERRED>    outif en0    src xx.xxx.xxx.xx port 53396    dst xx.xxx.xxx.xxx port 5439    rank info not available    TCP aux info availableConnection to myexampledb.xxxx.us-east-1.rds.amazonaws.com port 5439 [tcp/*] succeeded!Related informationScenarios for accessing a DB instance in a VPCWorking with a DB instance in a VPCFollow"


Question: How do I empty an Amazon S3 bucket using a lifecycle configuration rule?

I have an Amazon Simple Storage Service (Amazon S3) bucket that stores millions of objects. I want to empty the bucket using a lifestyle configuration rule so that I won't be charged for storage anymore.

Answer: "I have an Amazon Simple Storage Service (Amazon S3) bucket that stores millions of objects. I want to empty the bucket using a lifestyle configuration rule so that I won't be charged for storage anymore.ResolutionFollow these steps to create a lifecycle configuration rule that expires current versions of objects and permanently delete previous versions of objects:1.    Open the Amazon S3 console.2.    From the list of buckets, choose the bucket that you want to empty.3.    Choose the Management tab.4.    Choose Create lifecycle rule.5.    For Lifecycle rule name, enter a rule name.6.    For Choose a rule scope, select This rule applies to all objects in the bucket.7.    Select I acknowledge that this rule will apply to all objects in the bucket.8.    For Lifecycle rule actions, select the following to create a lifecycle rule:Expire current versions of objectsPermanently delete previous versions of objectsDelete expired delete markers or incomplete multipart uploads9.    In the Expire current versions of objects field, enter "1" in the Days after object creation field.10.    In the Permanently delete previous versions of objects field, enter "1" in the Number of days after objects become noncurrent field.11.    Leave the Number of newer versions to retain field empty to delete all versions.12.    Select Delete incomplete multipart uploads and enter "1" for the Number of days field.13.    Choose Create rule.14.    Create a second lifecycle rule by repeating steps 4-7.15.    Then, select the following: Delete expired delete markers or incomplete multipart uploads16.    Select Delete expired object delete markers.17.    Choose Create rule.Amazon S3 runs lifecycle rules once every day. After the first time that Amazon S3 runs the rules, all objects that are eligible for expiration are marked for deletion. You're no longer charged for objects that are marked for deletion. However, rules might take a few days to run before the bucket is empty because expiring object versions and cleaning up delete markers are asynchronous steps. For more information about this asynchronous object removal in Amazon S3, see Expiring objects.Related informationRemoving expired object delete markersManaging your storage lifecycleHow do I delete Amazon S3 objects and buckets?Deleting a bucketFollow"


Question: How can I change my CloudTrail trail to an AWS Organizations trail?

"Instead of creating a new AWS Organizations organization trail, I want to change my existing AWS CloudTrail trail to an organization trail. How do I change my CloudTrail trail to an organization trail?"

Answer: "Instead of creating a new AWS Organizations organization trail, I want to change my existing AWS CloudTrail trail to an organization trail. How do I change my CloudTrail trail to an organization trail?Resolution(Prerequisite) Activate trusted service access with CloudTrailFollow the instructions in Activating trusted access with CloudTrail in the AWS Organizations User Guide.For more information about integrating CloudTrail into Organizations, see AWS CloudTrail and AWS Organizations.Update the Amazon S3 bucket policy for your CloudTrail log files to allow the following:The CloudTrail trail to deliver log files to the Amazon Simple Storage Service (Amazon S3) bucket.The CloudTrail trail to deliver logs for the accounts in the organization to the Amazon S3 bucket.1.    Open the Amazon S3 console.2.    Choose Buckets.3.    For Bucket name, choose the S3 bucket that contains your CloudTrail log files.4.    Choose Permissions. Then, choose Bucket Policy.5.    Copy and paste the following example bucket policy statement into the policy editor, and then choose Save.Important: Replace primary-account-id with your Organizations primary account ID. Replace bucket-name with your S3 bucket name. Replace org-id with your Organizations ID. Replace your-region with your AWS Region.{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AWSCloudTrailAclCheck",            "Effect": "Allow",            "Principal": {                "Service": "cloudtrail.amazonaws.com"            },            "Action": "s3:GetBucketAcl",            "Resource": "arn:aws:s3:::bucket-name"        },        {            "Sid": "AWSCloudTrailWrite20150319",            "Effect": "Allow",            "Principal": {                "Service": "cloudtrail.amazonaws.com"            },            "Action": "s3:PutObject",            "Resource": "arn:aws:s3:::bucket-name/AWSLogs/primary-account-id/*",            "Condition": {                "StringEquals": {                    "s3:x-amz-acl": "bucket-owner-full-control"                }            }        },        {            "Sid": "AWSCloudTrailWrite",            "Effect": "Allow",            "Principal": {                "Service": "cloudtrail.amazonaws.com"            },            "Action": "s3:PutObject",            "Resource": "arn:aws:s3:::bucket-name/AWSLogs/org-id/*",            "Condition": {                "StringEquals": {                    "s3:x-amz-acl": "bucket-owner-full-control"                }            }        }    ]}(Optional) Configure permissions to monitor the organization's CloudTrail log files using CloudWatch Logs.Note: The following steps are required only if you're monitoring CloudTrail log files with Amazon CloudWatch Logs.1.    Make sure that your organization has all features activated.2.    Follow the instructions Activate CloudTrail as a trusted service in AWS Organizations.3.    Open the AWS Identity and Access Management (IAM) console.4.    Choose Policies.5.    For Policy name, choose the IAM policy associated with your CloudWatch logs group AWS primary account.6.    Choose Edit policy, copy and paste the following example IAM policy statement, and then choose Save.Important: Replace your-region with your AWS Region. Replace primary-account-id with your Organizations primary account ID. Replace org-id with your organization ID. Replace log-group-name with your CloudWatch log group name.{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AWSCloudTrailCreateLogStream",            "Effect": "Allow",            "Action": [                "logs:CreateLogStream"            ],            "Resource": [                "arn:aws:logs:your-region:primary-account-id:log-group:CloudTrail/log-group-name:log-stream:primary-account-id_CloudTrail_your-region*",                "arn:aws:logs:your-region:primary-account-id:log-group:CloudTrail/log-group-name:log-stream:org-id*"            ]        },        {            "Sid": "AWSCloudTrailPutLogEvents",            "Effect": "Allow",            "Action": [                "logs:PutLogEvents"            ],            "Resource": [                "arn:aws:logs:your-region:primary-account-id:log-group:CloudTrail/log-group-name:log-stream:primary-account-id_CloudTrail_your-region*",                "arn:aws:logs:your-region:primary-account-id:log-group:CloudTrail/log-group-name:log-stream:org-id*"            ]        }    ]}7.    Open the CloudTrail console.8.    In the navigation pane, choose Trails.9.    For Trail name, choose your trail's name.10.    For CloudWatch logs, choose the edit icon. Then, choose Continue.11.    For Role Summary, choose Allow.Update your CloudTrail trail to an organization trail1.    Open the CloudTrail console, and then choose Trails in the navigation pane.2.    For Trail name, choose your trail.3.    For Trail settings, choose the edit icon.4.    For Apply trail to my organization, choose Yes. Then, choose Save.Related informationHow do I get started with AWS Organizations?Running update-trail to update an organization trailFollow"


Question: Can I modify the terms of my Amazon EC2 Reserved Instance?

"I purchased an Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instance, but I want to modify the attributes of my Reserved Instance contract."

Answer: "I purchased an Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instance, but I want to modify the attributes of my Reserved Instance contract.ResolutionFirst, check the conditions that are listed at Requirements and restrictions for modification. If your Reserved Instance meets the conditions, then you can request to modify the following attributes:Availability ZoneScopeInstance sizeNetwork platformIf your modification request meets the guidelines and you’re ready to request a modification, then see Submitting modification requests.If you purchased a Convertible Reserved Instance, then consider exchanging the Reserved Instance for another Convertible Reserved Instance. For more information, see Exchange Convertible Reserved Instances.Related informationAmazon EC2 FAQsHow to purchase Amazon EC2 Reserved InstancesWhat are the differences between Standard and Convertible Reserved Instances?Follow"


Question: How do I set up a trusted IP address list for GuardDuty?

I want to set up a trusted IP address list for Amazon GuardDuty.

Answer: "I want to set up a trusted IP address list for Amazon GuardDuty.Short descriptionYou can configure GuardDuty to use your own custom trusted IP list. Use this list to configure your allowed IP addresses for secure communication with your AWS infrastructure and applications. For more information, see Working with trusted IP lists and threat lists.ResolutionCreate a trusted IP listReview the accepted format for trusted IP list files. Then, follow the instructions to upload the file to an Amazon Simple Storage Service (Amazon S3) bucket.Note: The trusted IP list file must be in TXT, STIX, OTX_CSV, ALIEN_VAULT, PROOF_POINT, or FIRE_EYE format. The trusted IP list doesn't support IPv6 addresses. You can have a maximum number of 2000 IP addresses and CIDR for each trusted IP list. You can have only one trusted IP list per Detector resource. For more information, see Quotas for Amazon GuardDuty.Check IAM identity permissionsBe sure that your AWS Identity and Access Management (IAM) identity has permissions with trusted IP lists and GuardDuty:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": [        "guardduty:*IPSet*",        "guardduty:List*",        "guardduty:Get*"      ],      "Resource": "*"    }  ]}Be sure that your IAM identity has permissions for PutRolePolicy and DeleteRolePolicy for the GuardDuty service linked role AWSServiceRoleForAmazonGuardDuty.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": [        "iam:DeleteRolePolicy",        "iam:PutRolePolicy"      ],      "Resource": "arn:aws:iam::123456789123:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"    }  ]}For more information, see Editing IAM policies.Add and activate a trusted IP list in GuardDutyOpen the GuardDuty console.In the navigation pane, choose Lists.Choose Add a trusted IP list.For List name, enter a name that is meaningful to you.For Location, enter the location for your S3 bucket. For example, https://s3.amazonaws.com/bucket-name/file.txt.Choose the Format dropdown menu, and then choose your list's file type.Select the I agree check box, and then choose Add list.In Trusted IP lists, choose Active for your trusted IP list name.Note: It might take up to 5 minutes for the list to activate.If you change a trusted IP list in GuardDuty, you must update and then reactivate the list. For instructions, see To update trusted IP lists and threat lists.Related informationHow to use Amazon GuardDuty and AWS Web Application Firewall to automatically block suspicious hostsWhy did GuardDuty send me alert findings for a trusted IP list address?Follow"