#office-hours - February 2022

Thank you for your patience while the service team reviewed your feedback.

The team have reversed the Automatic enabling of GuardDuty EKS Protection for customers and you will need to explicitly enable EKS once it’s done.

For current Amazon GuardDuty customers AWS will no longer enable by default GuardDuty for EKS Protection. GuardDuty for EKS Protection is the new container security coverage for Amazon Elastic Kubernetes Service (EKS). It was introduced on January 26, 2022 and allows GuardDuty to continuously monitor EKS workloads for suspicious activity, such as API operations performed by known malicious or anonymous users, misconfigurations that can result in unauthorized access to Amazon EKS clusters, and patterns consistent with privilege-escalation techniques.

All existing GuardDuty customers that currently have EKS Protection enabled will remain in a free usage period until Monday February 7, 2022, at which time GuardDuty for EKS Protection will no longer be on, and will remain off by default. Customers can then choose to re-enable GuardDuty for EKS Protection at the time of their choosing with a few clicks in the Amazon GuardDuty console or through the APIs. All accounts that enable GuardDuty for EKS Protection will receive 30 days of free usage and an estimated spend will be available in the GuardDuty console to help with planning purposes after the free period expires. After the free usage period, GuardDuty for EKS Protection will continue to monitor EKS workloads and can be disabled at any time. All EKS Protection security findings generated between January 26, 2022 and February 7, 2022 will be available for review for the next 90 days.

Because many customers have asked for a way to opt-in to an always-on enablement for new security coverage, later this year there will be a new feature introduced in GuardDuty that will allow customers to opt in to all future service coverage of GuardDuty.

The team will also look into the way these kind of information is communicated to the contacts on the account, to make sure the relevant information is shared with the correct billing preferences on file.

About ARM processor – we currently support it with our MDR platform and we also support it with our remote collectors. Please see links below.

<https://docs.alertlogic.com/requirements/agent.htm>

<https://docs.alertlogic.com/prepare/remote-log-collector-linux.htm?Highlight=arm>

We are planning to spend some time next week investigating new approaches to migration tooling and will follow up with the results of our investigation.