Cloud Sentry
AWS security

The security in your AWS account is already there. Most of it is switched off.

Amazon GuardDuty, AWS Security Hub, AWS Config, and AWS CloudTrail are already available in your AWS account, built to detect threats, aggregate findings, and track configuration drift. Depending on your account, some may already be running. Most are not, or were switched on once during setup and never revisited since. We turn on what is missing, then keep it tuned as your account, your team, and AWS itself keep changing.

The fastest way in is a discovery call: it starts with a fixed-fee, read-only review of your AWS account posture. What follows is the case for why switching AWS security on is the start of the work, not the end of it.

Sitting unused in your AWS account

AWS ships every account with a set of native security services. Turning one on is a checkbox in the console. Keeping it configured, tuned, and actually watched is the part most accounts skip. Here is what is commonly sitting unconfigured, depending on your account and region.

Amazon GuardDuty

Continuous threat detection built from signals already flowing through your account. It is opt-in and billed by usage, not included by default, and a large share of the accounts we review have never switched it on.

AWS Security Hub

Aggregates findings from GuardDuty, Config, Inspector, and AWS's own configuration checks into one place, scored against security standards you choose to enable. It has to be turned on per account and region, and the standards inside it have to be turned on too.

AWS Config

Records how your resources are configured and how that configuration changes over time, and can flag drift against rules you define. Recording has a cost per item, so it is often skipped or left running with no rules attached.

AWS CloudTrail

Every account keeps roughly ninety days of management activity automatically. A complete, durable trail across every region, retained longer and actually reviewed, has to be configured and kept configured.

IAM and IAM Access Analyzer

Identity is foundational and always on, but least-privilege policy design is not automatic. IAM Access Analyzer flags external and cross-account access and unused permissions, once it is enabled and someone is reading what it finds.

Amazon Inspector

Automated vulnerability scanning for EC2 instances, container images, and Lambda functions, where enabled. Coverage depends on which resource types you turn it on for and which accounts it is extended to.

Exact availability, defaults, and cost depend on your account structure, region, and AWS Support plan, and AWS periodically changes what ships where. Encryption key management through AWS KMS and multi-account governance through AWS Organizations extend this list further. We confirm what you actually have before we touch anything.

We switch it on, and we keep it on.

Turning on GuardDuty or enabling a Security Hub standard is a one-time task. Someone can do it from the console in twenty minutes, and AWS keeps adding wizards and default suggestions that make the initial click easier every year.

Staying configured is not a one-time task. New accounts get added to the organization, a team ships a service GuardDuty was never tuned to expect, an exception someone approved months ago is still open, and the Config rule that made sense in January quietly stops matching how the environment actually runs. That is the part a console wizard does not do, and the part a generalist IT provider rarely revisits once the initial setup is billed.

We turn the services on once, then we own them: triaging what GuardDuty and Security Hub actually find, watching Config for drift, adjusting as AWS changes defaults or ships a new service worth turning on. Turning it on is a project. Operating it is the job.

Configured once

  • Enabled during a one-time setup project, then left alone
  • Findings pile up in Security Hub with no one triaging them
  • New accounts inherit whatever the last account happened to have configured
  • No one owns the exceptions list

Cloud Sentry: operated

  • Enabled, then reviewed on a real cadence
  • GuardDuty and Security Hub findings triaged, not just collected
  • Config rules and account baselines kept current as AWS and your environment change
  • A named operator owns the exceptions, in writing

Beyond the console

What the console will not do for you

AWS secures AWS. It has nothing to say about the evidence an auditor will ask for, the rest of your cloud and IT estate, or who is accountable when a finding needs a judgment call. Turning on native AWS services is one piece of a bigger job.

Evidence, not memory

What we configure and operate in your account becomes filed evidence you can hand an auditor, not a claim made from memory in a meeting.

See inherited controls

Your other clouds and the rest of IT

Azure, GCP, and the rest of your IT estate need the same configuration and the same ongoing operation, run by the same team instead of a second vendor.

See cloud operations

A named, accountable operator

Every account we operate has a named operator behind it, not a rotating queue. You know who owns the exceptions list and who to call when a finding needs a judgment call.

The operated partnership

Start here

Start with the AWS Hygiene Check.

A fixed-fee, read-only review of your AWS account posture: what GuardDuty, Security Hub, Config, CloudTrail, and IAM are doing, what is switched off, and what to prioritize first. The fee credits forward if you grow into a tier. A discovery call is the fastest way to book the check.

Turn on the security already in your account.

Book a discovery call to see what is configured today, or read the published plan structure.

A working session on your account: GuardDuty, Security Hub, Config, and the rest, reviewed live, not quoted from a questionnaire.

The scope, the visibility, and the work we do not take on, laid out section by section.