0xdabbad00

*Important Announcement. Please read carefully.*

As of May 1, 2022, Amazon Web Services, Inc. is collecting and remitting any applicable City of Chicago Lease Transaction Taxes on AWS Marketplace sales to buyer accounts with a Chicago address. Please ensure any applicable exemption certificates are up-to-date on your Chicago accounts (if any). For more information, please see: https://aws.amazon.com/tax-help/marketplace-buyers/

If you are a Marketplace buyer who has existing City of Chicago exemption(s) on file with AWS
There is no action required as your existing US exemption(s) will continue to apply. However, you will be able to view and manage these exemptions on your Tax Settings page of your AWS Billing Console via the steps detailed below.

If you are a Marketplace buyer who wants to upload new City of Chicago exemption(s) to your account(s)

Please follow the steps detailed below in order to upload and manage your US tax exemptions on the Tax Settings page of your AWS Billing Console. Any submitted 

0xdabbad00

{
    "version": "1",
    "type": "NEW_FEATURES",
    "featureDetails": [{
      "featureDescription": "On January 25, 2022 Amazon GuardDuty will expand coverage to continuously monitor and profile Amazon Elastic Kubernetes Service (Amazon EKS) cluster activity to identify malicious or suspicious behavior that represents potential threats to container workloads. Amazon GuardDuty for EKS Protection monitors control plane activity by analyzing Kubernetes audit logs from existing and new Amazon EKS clusters in your accounts. GuardDuty is integrated with Amazon EKS, giving it direct access to the Kubernetes audit logs without requiring you to turn on or store these logs. Once a threat is detected, GuardDuty will generate a security finding that includes container details such as pod ID, container image ID, and associated tags. At launch, GuardDuty for EKS Protection includes 27 new GuardDuty finding types that can help detect threats related to user and application activity captured in Kubernetes audit logs. Guar

0xdabbad00

{
    "version": "1",
    "type": "NEW_FINDINGS",
    "findingDetails": [{
        "link": "",
        "findingType": " UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS",
        "findingDescription": "On January 20, 2022 Amazon GuardDuty will add a new finding type to inform you when your EC2 instance credentials are used from another AWS account. Augmenting the existing GuardDuty capability to detect when your EC2 instance credentials are used from outside of AWS, the new finding type limits a malicious actor’s ability to evade detection by using the EC2 instance credentials from another AWS account. If you are an existing GuardDuty customer then you don’t need to take any action to start using this new capability to monitor you control plane operations as captured in AWS CloudTrail. If you are also a GuardDuty S3 Protection customer then this new threat detection will further inform you when EC2 instance credentials are used from another AWS account to invoke S3 data plane operations (e.

0xdabbad00

[{
      "version": "1",
      "type": "UPDATED_FINDINGS",
      "featureDetails": [{
        "featureDescription": "Changes to Amazon GuardDuty finding type 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration'. We are notifying you of a change to the name and behavior of the Amazon GuardDuty finding 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration' that will take effect on September 6, 2021. We are making these changes to improve the accuracy of this finding type, and in preparation for the upcoming release of a new Amazon GuardDuty finding type. These changes will take affect in all Amazon GuardDuty supported AWS regions. The finding type name 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration' will be replaced with the name 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS'. The renamed finding type 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS' will improve the accuracy of the existing finding type by learning the remote networks that in

0xdabbad00

cat botocore/data/*/*/service*.json | jq -cr '.metadata.serviceId as $service | .operations[]| $service + ":" + .name' | sort | sed 's/20.*//' | uniq | sed 's/:.*//' | uniq -c


Category	Service	API Count
Analytics	CloudSearch Domain	3
Analytics	CloudSearch	37
Analytics	Athena	28
Analytics	Data Pipeline	19
Analytics	DataExchange	22
Analytics	EMR	33

0xdabbad00

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:UpdateAccessKey",
        "ec2:RequestSpotInstances",
        "organizations:InviteAccountToOrganization",
        "lightsail:DownloadDefaultKeyPair",

0xdabbad00

#!/bin/bash

# Use the AWS CLI to collect all versions of all AWS managed policies. Example files:
# APIGatewayServiceRolePolicy.v1
# APIGatewayServiceRolePolicy.v2
# APIGatewayServiceRolePolicy.v3

# Usage: ./grab.sh

# Note that the following policies do not exist and create zero byte files:

0xdabbad00

Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020
Posted By:	Sarasaws
Created in:	Forum: Amazon Simple Storage Service (S3)
Posted on:	Apr 30, 2019 3:43 PM
Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key). In our effort to continuously improve customer experience, the path-style naming convention is being retired in favor of virtual-hosted style request format. Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted st

0xdabbad00

cat botocore/data/endpoints.json | jq -cr '.partitions[0].services | keys[] as $k | .[$k] | .endpoints|to_entries[]| .key +"\t"+ $k' | sort | cut -f1 | uniq -c | sort -nr | sed 's/^ *\([0-9][0-9]*\) /\1    /' | grep -v fips


126	us-east-1
116	us-west-2
115	eu-west-1
101	ap-southeast-2
100	ap-northeast-1
97	eu-central-1
95	us-east-2

0xdabbad00

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<xs:schema xmlns:tns="http://cloudfront.amazonaws.com/doc/2016-01-13/" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://cloudfront.amazonaws.com/doc/2016-01-13/" elementFormDefault="qualified">
<xs:element name="ActiveTrustedSigners" type="tns:ActiveTrustedSigners"/>
<xs:complexType name="ActiveTrustedSigners">
<xs:sequence>
<xs:element name="Enabled" type="xs:boolean"/>
<xs:element name="Quantity" type="xs:integer"/>
<xs:element name="Items" type="tns:SignerList" minOccurs="0"/>
</xs:sequence>
</xs:complexType>