I experienced a full disk issue probably connected to a DDOS attack, the apache access log file was huge.
I know logrotation is triggered by default by file size. My server is an Ubuntu 20.04 with default apache and logrotate configuration.
My question is: does logrotate checks the file size just when its processes is scheduled, usually once a day by a daily cron job? If yes, this explains how access log can become huge in a single day.
No, by default logrotate is not triggered by the file size. Instead, with the default configuration it rotates main log files at fixed intervals. That shall answer the main question of why it happened. Packages may "register" their files for rotation by dropping configuration snippets into /etc/logrotate.d/, and these snippets may contain size directive, but the default configuration that logroate package itself installs doesn't contain it.
Another thing is, logrotate itself is not a daemon that watches the log files in real time and immediately rotates them if the size constraint is met. It is a batch program that checks the configured conditions at the moment of the run and rotates all the log files that apply. Typically it is invoked from the system scheduler (cron or systemd timers), and by default it is set to run once per day (for example, the logrotate package in Debian drops a script /etc/cron.daily/logrotate which invokes the program). So even if it is configured to operate size-based (which is possible), if will not help you to contain the size if it grows too quickly. In this configuration it will check the log sizes only once per day to determine if they need to be rotated, and rotate if these sizes are exceeded. In case of DDoS attack, probably, the log sizes must be checked far more often to keep them in check.
While it is possible to make it run as often as every minute, be aware that it could create unnecessary system load from checking all the log files for rotation every minute (perhaps even aiding the DDoS). If there is such a need, it might be wise to create a separate logrotate "instance" that runs more often for selected log-files, and to leave everything else as is. Consider also reducing the log stream by not logging every request (only interesting), or rate-limiting it in the application (although Apache HTTPd doesn't seem to offer log rate limiting).
In order to make it size-based, you need to both adjust the logrotate configuration and its invocation schedule. If you provide more details from your system and the describe how it is desired to work, I (or, perhaps, someone else) could suggest exact configuration changes to achieve this goal.
/etc/logrotate.confand relevant files from/etc/logrotate.d/). Put it into the question.fail2banto limit the effects of such attacks.