[Pirate-of-SV]

I think it's problematic that most security features (configurable by the user) are switched off by default and require some effort to set up. This is getting better though and for S3 buckets specifically a lot of additional features have showed up lately to "solve" this.

[Moissanite]

Can you give an example? Everything I can think of is either default-deny or minimally scoped, and "system" IAM roles tend to just not exist until you need them for the first time.

[Pirate-of-SV]

Ah yeah for IAM the defaults seem sane, true! The things that I've come across recently is that encryption at rest is usually disabled ( EBS, SQS, S3, SNS, Kinesis, Cloudwatch log groups, Cloudtrail). Some of these have server side encryption and then it's easy to just check that box, other require you to set up KMS keys etc.

Audit logs are in many cases disabled by default (RDS, S3, OpenSearch, ELB).

S3 does not require TLS requests by default. ECR does not have image scanning enabled by default.

Also new accounts almost all regions enabled and a default VPC in each (and subnets, route tables, security groups, internet gateway, dhcp option set). Unused VPCs are not recommended to keep around but I suppose it makes onboarding easier.

[Moissanite]

Good points. Totally agree about encryption - I think S3 is a legacy case where SSE-S3 is implemented differently to SSE-KMS, but still I'd be on board with KMS encryption (using an AWS managed key) as the default.

Audit logging costs money, so I'm on the fence about that.

A default VPC is easy to disable in enterprise deployments, but for the rest of us it is necessary to do quick tests with EC2-adjacent services - I'd be in favour of it not existing until you try to launch something though.

[jamesfinlayson]

I think SQS encryption was enabled by default (for newly created queues) this week funnily enough.

I completely agreed though - I look at CloudConformity and so many of the warnings are for encrypted resources.