# Resource inventory for Accelerate All the resources that AMS Accelerate deploys to your AWS account or accounts are listed in the [samples/resource_inventory.zip](samples/resource_inventory.zip) file (Excel spreadsheet). **Note** In the *Resource Name* column, the prefix *CFN:* indicates a CloudFormation logical ID instead of a resource name. These are shown for unnamed resources, for example, for S3 bucket policies. AMS deploys a set of services as described in the [Service description](acc-sd.md). The cost of deploying them is low when deployed to an empty account, but the cost increases as utilization grows. For example, logs are created and config rules are invoked as resources change. When multiple changes are made to the config rules, multiple config compliance invocation can be triggered, leading to higher costs. The same possibility applies for Amazon CloudWatch used for monitoring instances—the more granular your monitoring, the higher the cost of the service. AWS Backup is another example. If you have multiple backups stored, or if you have higher retention periods, you are using more storage and the cost is higher. These numbers are hard to predict. During your monthly business review with your cloud service delivery manager (CSDM), keep track of the changes and work to identify areas of opportunity for cost reduction. # Infrastructure controls AMS Accelerate deploys resources that might be flagged as misconfigurations in certain controls. However, these configurations are either intentional cost-optimization trade-offs or are covered by compensating controls. AMS recommends using the information in this documentation to either enable the control or to mark an exception in AWS Security Hub. **Topics** + [Self-remediation Security Hub controls in Accelerate](acc-self-remediation-controls.md) + [Other Security Hub controls in Accelerate](acc-other-controls.md) # Self-remediation Security Hub controls in Accelerate The following self-remediation controls are available in Accelerate. **Topics** + [S3.7 - S3 general purpose buckets should use cross-Region replication](#acc-s37-control) + [S3.11 - S3 general purpose buckets should have event notifications enabled](#acc-s311-control) + [S3.13 - S3 general purpose buckets should have Lifecycle configurations](#acc-s313-control) + [S3.15 - S3 general purpose buckets should have Object Lock enabled](#acc-s315-control) + [Config.1 - AWS Config should be enabled and use the service-linked role for resource recording](#acc-config1-control) ## S3.7 - S3 general purpose buckets should use cross-Region replication *Resources:* + arn:aws:s3:::ams-a-alarmmanager- + arn:aws:s3:::ams-a-patch-data-reporting- + arn:aws:s3:::ams-a-patch-data-reporting--audit + arn:aws:s3:::ams-config-recorder-bucket- + arn:aws:s3:::ams-config-recorder-bucket--audit The S3 buckets used by AMS infrastructure components do not have cross-Region replication enabled to optimize costs for you. Enabling cross-Region replication incurs data transfer charges for replicating data between regions, plus additional storage costs in the destination region. For buckets that support internal AMS operations and do not require geographic redundancy by default, cross-Region replication would add significant ongoing costs without providing necessary benefits. Since these buckets store operational data such as alarm management, patch reporting, and configuration recording within a single region, cross-Region replication is not required for normal AMS operations. However, AMS offers the capability to enable cross-Region replication on these buckets based on your specific disaster recovery or compliance requirements. Contact AMS if you require assistance configuring cross-Region replication for your use case. ## S3.11 - S3 general purpose buckets should have event notifications enabled *Resources:* + arn:aws:s3:::ams-a-alarmmanager- + arn:aws:s3:::ams-a-patch-data-reporting- + arn:aws:s3:::ams-a-patch-data-reporting--audit + arn:aws:s3:::ams-config-recorder-bucket- + arn:aws:s3:::ams-config-recorder-bucket--audit The S3 buckets used by AMS infrastructure components do not have event notifications enabled to optimize costs for you. Enabling S3 event notifications incurs charges for the notification delivery mechanism (such as Amazon Simple Notification Service, SQS, or AWS Lambda invocations), which can add up depending on the volume of S3 operations. See [Amazon SNS Pricing](https://aws.amazon.com/sns/pricing/) for more information. Since these buckets support internal AMS operations and do not require event-driven workflows by default, we did not enable event notifications to avoid unnecessary costs. However, AMS offers the capability to enable event notifications on these buckets based on your specific monitoring or automation requirements. Contact AMS if you require assistance configuring event notifications for your use case. ## S3.13 - S3 general purpose buckets should have Lifecycle configurations *Resources:* + arn:aws:s3:::ams-config-recorder-bucket- + arn:aws:s3:::ams-config-recorder-bucket--audit Historically, the component these S3 resources belong to has not included these configurations for cost-efficiency reasons for you. However, AMS offers the capability to remediate this control using your configuration. Contact AMS if you require assistance in doing so. ## S3.15 - S3 general purpose buckets should have Object Lock enabled *Resources:* + arn:aws:s3:::ams-a-alarmmanager- The S3 buckets used by the AMS Alarm Manager system don't have Object Lock enabled due to cost-efficiency considerations for you. Enabling Object Lock can increase costs (require additional API calls resulting to an increase CloudTrail data) and operational complexity, particularly for buckets that require frequent object updates or deletions as part of normal operations. However, you can manually enable Object Lock on these buckets if your compliance or data retention requirements necessitate this feature. Contact AMS if you require assistance with this configuration. *Resources:* + arn:aws:s3:::ams-a-patch-data-reporting- + arn:aws:s3:::ams-a-patch-data-reporting--audit Object Lock can't be enabled on the `ams-a-patch-data-reporting-` and `ams-a-patch-data-reporting--audit` buckets due to AWS service limitations. The patch-data-reporting bucket receives data from Systems Manager inventory through SSM Resource Data Sync, which is incompatible with S3 Object Lock. The audit bucket serves as an S3 server access logs destination, which cannot have Object Lock enabled. For more information, see [Creating a resource data sync for Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/inventory-create-resource-data-sync.html) in the *AWS Systems Manager User Guide*. These AWS service constraints make Object Lock technically impossible while maintaining required functionality. ## Config.1 - AWS Config should be enabled and use the service-linked role for resource recording *Resources:* + Config Recorder During onboarding, AMS deploys AWS Config with the service-linked role `AWSServiceRoleForConfig` by default. However, this control might fail if you have supplied custom AWS Identity and Access Management roles for AWS Config instead of using the service-linked role to reduce costs. While custom roles can work, they require manual policy management and might not automatically receive updates when AWS Config adds support for new resource types or features. You can self-remediate this finding by updating your AWS Config recorder to use the service-linked role `AWSServiceRoleForConfig`. This is the recommended configuration and aligns with AWS best practices. For detailed instructions on AWS Config infrastructure deployed by AMS, see [Infrastructure security monitoring](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sec-infra-sec.html). # Other Security Hub controls in Accelerate The following compensating controls are available in Accelerate. **Topics** + [Lambda.3 - Lambda functions should be in a VPC](#acc-lambda3-control) + [S3.17 - S3 general purpose buckets should be encrypted at rest with AWS KMS keys](#acc-s317-control) + [KMS.2 - IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys](#acc-kms2-control) + [S3.9 - S3 general purpose buckets should have server access logging enabled](#acc-s39-control) + [EC2.6 - VPC flow logging should be enabled in all VPCs](#acc-ec26-control) ## Lambda.3 - Lambda functions should be in a VPC *Resources:* + AMSAlarmManagerDeploymentHandler + AMSAlarmManagerOrphanedAlarmCleanup + AMSAlarmManagerRemediation + AMSAlarmManagerReporting + AMSAlarmManagerTriggerEvaluation + AMSAlarmManagerValidation + AMSConfigExtensionDeploymentHandler + AMSConfigFSXExtension + AMSConfigOutpostExtension + AMSConfigSyntheticCanaryExtension The AWS Lambda functions deployed by AMS don't communicate with resources in your accounts. Therefore, they don't require dedicated Elastic Network Interfaces (ENIs) or VPC placement. Deploying these functions outside of a VPC reduces costs and improves deployment speed. This approach doesn't introduce any security concerns for intra-resource communication. Since these Lambda functions operate independently and don't access VPC-based resources, VPC deployment adds unnecessary complexity and expense without providing additional security benefits. ## S3.17 - S3 general purpose buckets should be encrypted at rest with AWS KMS keys *Resources:* + arn:aws:s3:::ams-a-alarmmanager- The Amazon Simple Storage Service buckets used by the AMS Alarm Manager system use Amazon-managed encryption keys (SSE-S3) instead of customer-managed KMS keys (SSE-KMS). Implementing customer-managed keys requires you to grant AMS explicit permissions to use your KMS keys through key policies. This introduces additional operational complexity and risk. Using this control provides strong encryption at rest while avoiding additional costs and operational complexity for you. If you modify key policies, rotate keys improperly, or accidentally delete or disable your keys, AMS monitoring immediately fails for you. This dependency on customer-managed key availability compromises AMS critical monitoring and alerting infrastructure. It could potentially disrupt real-time monitoring capabilities, alert delivery, incident response, and service health visibility. Amazon-managed encryption keys automatically encrypt data at rest without requiring you to manage key policies, rotation schedules, or access permissions. This implementation meets encryption requirements while maintaining cost efficiency and operational simplicity for AMS-managed infrastructure. *Resources:* + arn:aws:s3:::ams-a-cloudtrail-log--audit The AWS CloudTrail audit logging bucket cannot use AWS KMS encryption due to AWS service limitations. S3 buckets that serve as server access logging destinations must not have KMS key encryption enabled. For more information, see [Configuring default encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) and [Troubleshoot server access logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting-server-access-logging.html) in the *Amazon Simple Storage Service User Guide*. Enabling AWS KMS encryption on logging destination buckets can cause logging failures and create operational issues. This bucket uses Amazon S3-managed encryption (SSE-S3) instead. This provides encryption at rest while maintaining compatibility with S3 server access logging functionality. ## KMS.2 - IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys *Resources:* + KMS Key: alias/ams/patchreporting The inline policy contains "Resource": ["\$1"] in a KMS key policy, which is a resource-based policy attached to a specific KMS key (ams\$1ssm\$1inventory\$1bucket\$1kms\$1key). Key policies are inherently scoped to the individual key, and using \$1 in the Resource element is standard AWS practice since the policy scope is already constrained by the key itself. For more information, see [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) and [Default key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html) in the *AWS KMS keys Developer Guide*. This configuration poses no security risk as access is limited to a single KMS key, not all keys in the account. ## S3.9 - S3 general purpose buckets should have server access logging enabled *Resources:* + ams-config-recorder-bucket--audit These S3 buckets are access logging destination buckets for AWS Config Recorder buckets. S3 recommends against setting up access logging on these buckets as it will generate an infinite loops of logging, driving up cost unnecessarily. AWS Security Hub instead recommends that resources in this scenario should have findings suppressed. *Remediation:* You should suppress this finding for these affected buckets as the findings aren't useful. If you don't want to suppress the findings, then you can optionally configure self-logging on the bucket. Self-logging comes with the risk that the logging might be removed if AMS updates the bucket. ## EC2.6 - VPC flow logging should be enabled in all VPCs *Resources:* + Default vpc at account create By default, AMS doesn't enable VPC Flow logs for the default VPC. *Remediation:* You can self-remediate the control by adding the `ams:managed=true` tag key/value, clearing the state of the config rule and re-running the evaluation of the rule. The auto-remediation component of AMS enables VPC Flow Logs on the vpc.