If your business runs anything on Amazon Web Services, AWS is already keeping a 90-day record of who logged in, what they changed, and where the requests came from. After 90 days, that history disappears. For most Ontario businesses, especially those with compliance obligations or any need to review security incidents after the fact, 90 days is not enough. The good news is that you can keep those logs indefinitely with a few configuration changes, and doing so is not expensive.
Why 90 days is not enough
Most data breaches are not discovered immediately. The gap between an attacker gaining access and your team noticing can be months. If you only keep 90 days of logs, the evidence of how they got in is already gone by the time you know you need it.
Compliance standards also expect longer retention. If you handle credit card data, health records, or work with clients who require annual audits, you will be asked to produce logs that cover the full audit period. That means a year or more, not three months.
Even without a breach or audit, your team may need to trace back what happened. Who changed a permission setting six months ago? Who accessed a customer file last quarter? Those questions come up in normal operations, and you cannot answer them if the logs are gone.
What to turn on
AWS CloudTrail is the service that records this activity. It is already running in your account, but by default it only keeps that 90-day history. To keep logs longer, you create what AWS calls a trail. That trail sends a copy of every event to an Amazon S3 bucket, where you control how long the files are kept.
Set up the trail to cover all AWS Regions, even the ones you do not think you use. If an attacker gets into your account, they will often try less-watched Regions first. You want to see that activity.
Turn on log file integrity validation. This feature creates a cryptographic record that proves whether a log file has been tampered with. If you ever need to show logs to an auditor or use them in a legal matter, you will be asked if they can be trusted. Validation gives you a yes.
Enable data events for S3 and Lambda if you store sensitive information or run business logic through those services. Data events show who accessed which files and when. They are higher volume than the default management events, so they cost more to log, but the visibility is worth it if the data matters.
Where to store the logs
Do not store CloudTrail logs in the same AWS account where your applications run. If that account is compromised, an attacker can delete the logs that would show what they did. Put the logs in a separate AWS account with restricted access, so even if your main environment is breached, the audit trail survives.
Turn on versioning and MFA delete for the S3 bucket that holds the logs. Versioning means that if someone tries to delete a log file, S3 keeps the old version. MFA delete requires a second authentication factor before a file can be permanently removed. These controls make it much harder for someone to cover their tracks, whether the deletion is malicious or accidental.
What this means for your business
If you already have a managed service provider handling your AWS environment, ask them to confirm that CloudTrail is configured with a trail, that logs are being sent to S3, and that retention is set to at least one year. Most providers do this as part of their baseline setup, but it is worth checking.
If you manage AWS internally, this is a task for whoever has administrative access to your AWS account. It does not require ongoing maintenance once it is set up. You pay for the S3 storage, which is typically a few dollars per month for a small to mid-sized environment, and optionally for data events if you turn those on.
For businesses with compliance requirements, do this now. Your next audit will ask for it, and you cannot go back in time to capture logs you did not keep. For everyone else, treat it as insurance. You may never need to look at these logs, but if you do need them, you will need them badly.
When to get help
If your team is not confident working in AWS, or if you are not sure whether your current setup meets these standards, this is a good conversation to have with a managed IT provider. The configuration itself is not complicated, but getting it wrong means the logs either do not get captured or do not get protected properly.
If you use AWS for anything customer-facing or any system that touches regulated data, consider asking for a review of your CloudTrail setup as part of a broader security audit. The same principles that apply to logging also apply to access controls, encryption, and monitoring, and those pieces need to work together.
