You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've historically set up s3 server access logging with a single taget bucket and the source buckets are configured to use their own bucket name as the prefix.
This doesn't seem practical in cloudformation/CDK where the BucketName would normally be left to be generated by Cloudformation Bucket object, but the LoggingConfiguration has to be passed into that bucket object.
I thought of making a custom resource which calls put-bucket-logging and takes the bucket as a prop, but I think this will cause the bucket to drift.
Is our pattern transferrable into CDK or do we need a new pattern?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
We've historically set up s3 server access logging with a single taget bucket and the source buckets are configured to use their own bucket name as the prefix.
E.g.
This doesn't seem practical in cloudformation/CDK where the
BucketName
would normally be left to be generated by CloudformationBucket
object, but theLoggingConfiguration
has to be passed into that bucket object.I thought of making a custom resource which calls
put-bucket-logging
and takes the bucket as a prop, but I think this will cause the bucket to drift.Is our pattern transferrable into CDK or do we need a new pattern?
Beta Was this translation helpful? Give feedback.
All reactions