Security and Governance on AWS
Security and governance on AWS
AWS offers strong isolation and strong preventative controls, but only when the account structure and policy hierarchy are set up deliberately. We establish the organisation, the guardrails and the identity model first, then enable detection in a way that produces a prioritised queue with named owners rather than a wall of findings. Where an estate has grown account by account, the early work is usually consolidation and containment rather than new tooling. The trade to understand up front is that organisation-scope policy on AWS mostly takes permissions away, so anything that has to repair configuration is engineering work you own.
Why AWS
When this is the right platform.
- AWS Organizations and AWS Control Tower separate workloads by account, so the blast radius of a compromised credential is bounded by an account boundary rather than by a tagging convention someone has to maintain.
- Service control policies cap what principals in an account may do, and resource control policies cap who may reach a resource, including principals outside your organisation. Neither can be overridden by an account administrator, which is a hard ceiling rather than a guideline.
- IAM Identity Center federates to the identity provider you already run, including Microsoft Entra ID, and issues short-lived credentials per account and role instead of long-lived access keys sitting on developer laptops.
- Amazon GuardDuty, Amazon Inspector and Amazon Macie are managed detections you enable rather than detections you build, and GuardDuty now correlates related signals into a single attack sequence finding instead of leaving an analyst to join the dots.
- Amazon Security Lake normalises logs and findings into an open schema in storage you own, so the security data stays yours and the choice of analytics tool remains reversible later.
Where it is less suited
We would rather say this now than after a migration.
- Organisation-scope policy mostly subtracts. Service control policies and resource control policies remove permissions and cannot deploy or repair anything, and declarative policies currently cover only a limited set of EC2, EBS and VPC settings. Anything that has to bring a resource up to standard is built from Config rules plus automation, which is real engineering work with a maintenance cost rather than a setting you switch on.
- Security services are enabled and priced per account and per region. Turning everything on everywhere across a large estate becomes expensive quickly, particularly GuardDuty on high-volume S3 data events and Macie scanning large object stores, so scope has to be a conscious decision reviewed against the value of the coverage.
- IAM policy evaluation combines identity policies, resource policies, permission boundaries, service control policies, resource control policies and session policies. Reaching genuine least privilege is real engineering effort with real review cycles, and in practice misconfiguration rather than platform capability is the usual cause of exposure.
- Security service naming has shifted and the documentation has not caught up evenly. The original Security Hub was renamed Security Hub CSPM and a new service took the name with a different findings schema, so blog posts, older runbooks and existing infrastructure code disagree. We confirm behaviour against your deployed configuration and date what we record.
- Region parity is a genuine constraint in Australia. Newer security capability generally reaches Sydney before Melbourne and sometimes neither for a while, so a design assuming a feature exists in the region you prefer needs verifying at design time rather than during a go-live weekend.
- AWS Artifact provides AWS's own attestations for the infrastructure AWS operates, and Audit Manager collects evidence for estates already on it though it is now in maintenance mode. They do not make your workloads compliant, and the control narratives for everything you build on top remain your responsibility.
Business outcomes
What AWS delivers here.
- A blast radius you can draw on one page
- Production, non-production, security tooling and shared services sit in separate accounts with explicit trust between them. Platform and risk leads get a containment boundary they can explain to an assessor without a caveat.Agreed measure: Share of production workloads in a dedicated account under the intended organizational unit, verified at handover.
- Credentials with a short life
- Engineers and pipelines assume roles for the task at hand instead of holding permanent access keys. Retiring the last few keys is always slower than the first ninety per cent, because they belong to automation nobody remembers writing.Agreed measure: Count of active long-lived IAM access keys remaining across the organisation, tracked monthly.
- Findings in one prioritised queue
- Posture, vulnerability, threat and data-exposure findings converge into a single ranked view with an owner per account. The security lead stops chasing account owners for context and starts tracking closure rates instead.Agreed measure: Control pass rate per account plus the age of the oldest unowned finding, reported monthly.
- Data reachable only from inside the organisation
- Public access is blocked at the organisation level, resource policies are constrained so an external principal cannot reach a bucket or a key, and encryption moves under keys you control. Classification and loss prevention are a separate programme we scope on their own merits.Agreed measure: Number of buckets, keys and secrets reachable by a principal outside your organisation, counted at handover.
- Evidence collected as you go
- Control evidence accumulates continuously instead of being reconstructed the month before a review. When a client asks for assurance, the response draws on current artefacts and a written exception register rather than on recollection.Agreed measure: Elapsed time to produce evidence for a named control set, baselined on your last assurance request.
- Guardrails that stop the change, not just log it
- Actions nobody should ever take, such as disabling logging or deploying outside agreed regions, are denied above the account. Engineering teams get an immediate, specific error rather than a compliance finding weeks later.Agreed measure: Controls enforced at organisation scope, with every exception recorded against a named approver and a date.
Common client problems
What we usually hear first.
We have around 40 AWS accounts and no consistent view across any of them.
We bring the accounts under a single organisation with an account inventory, an owner per account and a landing zone that applies a baseline everywhere, enrolling what exists rather than rebuilding it. Findings and logs are then delegated to a dedicated security account so one view is possible at all. Some accounts will turn out to be cheaper to replace than to remediate, and we will say which ones rather than enrolling everything on principle.
There are long-lived access keys everywhere and I could not tell you which ones are still used.
We list every IAM user and access key with its last-used timestamp and the services it touched, which separates dormant credentials from live automation. Active use is migrated to roles or IAM Identity Center on a dated plan, then the keys are disabled before deletion so a rollback is possible. Expect a long tail: the last handful of keys usually belong to a scheduled job with no owner, and finding out what breaks is part of the work.
GuardDuty is switched on but the findings just accumulate in a shared inbox.
We agree in advance which finding types are actioned, which are suppressed with a recorded reason and who owns each account, then route the remainder into a triage queue with severity thresholds. Automated response is added only for the finding types where the correct action is unambiguous, because an automation that terminates the wrong instance costs more credibility than the finding was worth.
Our security spend went up last quarter and nobody can explain which service caused it.
We attribute security service cost by account, region and feature, which usually surfaces a small number of causes such as S3 data event logging, broad Macie scanning, duplicated log destinations or a detection service enabled in every opted-in region. Scope is then reset against the value of the coverage, with the decision written down and revisited monthly rather than argued again next quarter.
Our biggest client is asking for a SOC 2 report and we genuinely do not know where to start.
We map your current AWS configuration to the control themes an assessor will test, identify the gaps and build the evidence collection that keeps the answers current. We prepare and align the environment; the audit and any resulting report come from an independent assessor you engage separately. The part clients underestimate is the non-technical half, since policies, training records and vendor management sit outside AWS entirely.
Half the AWS documentation we find contradicts the console in front of us.
That is a real problem at the moment rather than your team misreading things. Security service naming and packaging has shifted recently, most visibly around Security Hub, where the original service was renamed Security Hub CSPM and a new service took the old name with a different findings schema. Blog posts, older runbooks and existing infrastructure code do not all agree. We confirm current behaviour against your deployed configuration rather than trusting an article, and we date what we record.
How we deliver
Our AWS delivery approach.
- 01
Assessment and advisory
The AWS review works from the organisation downwards, because account structure and policy hierarchy determine what every control below them can achieve. Findings are backed by exportable configuration, not interviews alone.
- Organisation and account map. Every account with its owner, its purpose, its enrolment state and the service control policies and resource control policies applied to its organizational unit.
- Access keys listed with last use. IAM users, long-lived keys and roles carrying wildcard permissions across all accounts, with last-used data and unused access findings so dormant credentials are separated from live automation.
- CloudTrail coverage verified. Organisation trail coverage including management events, selected data events, log file validation, and whether the destination can be altered from a workload account.
- Config and Security Hub baseline. Rule coverage and standard results per account and region, recording which controls are disabled and the reason given, because the disabled list is usually the interesting part.
- Data exposure at the bucket edge. Public access settings, bucket and key policies granting access to external principals, and scoped Macie discovery aimed at the stores most likely to hold regulated material rather than the whole estate.
- Essential Eight rating with evidence. The estate assessed against the maturity model and the control themes an ISO 27001 or SOC 2 assessor will test, documenting the AWS configuration behind each rating.
- 02
Architecture and implementation
We build the organisation, identity and encryption layers before enabling detection, because detection on a weak foundation mostly generates work. Everything is expressed as code and applied to a test organizational unit first.
- Landing zone established or remediated. AWS Control Tower separating security, log archive, network and workload accounts, enrolling existing accounts where a rebuild is not warranted and flagging the ones where it is.
- Permission ceiling above the account. Service control policies denying actions no account should perform, resource control policies restricting who may reach a resource, and declarative policies pinning the EC2, EBS and VPC settings they currently cover.
- Identity Center as the human route. Permission sets per job function federated to your existing identity provider, then long-lived IAM users retired in a sequence that does not break running automation.
- Least privilege proven, not asserted. Permission boundaries and roles built from the specific API calls a workload makes, with the reduction verified against IAM Access Analyzer findings rather than assumed from a policy review.
- Customer managed keys with separation. Encryption at rest under AWS KMS keys where key control matters, with key policies, rotation, and the account owning the key separated from the account using it.
- Secrets rotated and edge protected. Application credentials moved into AWS Secrets Manager with rotation and stripped from environment variables and repositories, with AWS WAF and AWS Shield in front of public applications.
- 03
Governance, detection and assurance
Detection services are enabled organisation-wide from a delegated security account, then tuned against your architecture. Evidence collection is set up at the same time so assurance is a by-product of running the platform.
- GuardDuty organisation-wide, delegated. Enabled across accounts and regions from the security account, with finding types actioned or suppressed by prior agreement and attack sequence findings treated as the priority queue.
- Inspector findings sent to the builder. Continuous vulnerability assessment of instances, container images and functions, routed to the team that owns the build rather than to a central security inbox.
- One prioritised queue, one owner. Posture standards used as the control baseline with GuardDuty, Inspector, Macie and AWS Config results consolidated into a single ranked backlog with an owner per account.
- Security Lake in an open schema. Logs and findings normalised into storage you own, with retention tiers set to the period you agreed rather than the period a default chose for you.
- Detective for cross-account behaviour. Used where a finding needs behaviour across time and accounts, with the investigation path recorded so the next analyst does not repeat the work.
- Evidence collected as you go. Config conformance packs plus a third-party evidence platform for a new build, since AWS Audit Manager is in maintenance mode and closed to new-account setup. AWS Artifact still covers AWS's own attestations for the infrastructure it operates. The audit opinion comes from an independent assessor, not from us.
- 04
Adoption and enablement
Engineering teams have to be able to keep shipping while the controls tighten. Every restrictive change is tested against real activity before it is enforced anywhere that matters.
- IAM users retired workload by workload. Teams moved to IAM Identity Center one workload at a time, with the old path left in place until the new one is proven and then removed on a dated plan.
- Account owners see their own findings. Read access to their own findings plus a short guide to which control failures block a release and which do not, so triage is not centralised by default.
- New policies tested on one OU. Service control policies and resource control policies applied to a test organizational unit and the deny paths checked against real CloudTrail activity before the scope widens.
- Short-lived credentials made routine. Engineers trained to obtain credentials through the command line and the access portal on their own repositories, because the habit is what retires the keys.
- Automated response only where obvious. Automation added for finding types where the correct action is unambiguous, and deliberately withheld where a wrong automated action would be worse than a slow human one.
- Regions governed on entry. Who approves opting into a region and what detection and logging must be in place before a workload may deploy there, since coverage varies by region.
- 05
Managed security operations
AWS ships new controls and new finding types constantly, and account estates grow between reviews. We keep the baseline applied, the findings triaged and the evidence current, during agreed support hours and through an escalation path you have approved. This is not overnight monitoring, and we will tell you if your risk profile needs that instead.
- Control pass rate reported by account. Monthly reporting on pass rate per account, GuardDuty finding trend by severity, and findings still open past their agreed age.
- Findings triaged to a named playbook. Triage against an agreed severity model with escalation through a playbook that names the person, the channel and the fallback contact.
- Entitlement drift reviewed quarterly. Unused roles, keys and permissions removed on the evidence of last-used data and IAM Access Analyzer results rather than on a policy read-through.
- Config and policies in version control. AWS Config rules, service control policies and remediation automation held in a repository and tested in a sandbox organizational unit before promotion.
- Security spend attributed monthly. Config, GuardDuty, Macie and Security Lake cost tracked by account and region, with scope adjusted where cost is growing faster than the value of the coverage.
- Control evidence kept current. The assessment and its evidence maintained between review cycles, so an assurance response is assembly rather than a rebuild each time one is requested.
Reference architecture
The AWS security control set, layer by layer.
How the pieces fit together on AWS. Every engagement adapts this, and we will tell you which layers you already have.
- 01
Organisation and identity
One organisation, federated workforce sign-in, no long-lived local users.
- AWS Organizations
- IAM Identity Center
- Permission sets
- 02
Permission ceiling
Principals, resources and a few service settings constrained above the account.
- Service control policies
- Resource control policies
- Declarative policies
- 03
Workload controls
Least privilege, key custody and secrets, built per account rather than inherited.
- IAM roles and boundaries
- AWS KMS
- AWS Secrets Manager
- IAM Access Analyzer
- 04
Detect and investigate
Managed detections enabled organisation-wide from a delegated security account.
- Amazon GuardDuty
- Amazon Inspector
- AWS Security Hub CSPM
- Amazon Detective
- 05
Evidence
Audit records and control evidence in an account the workloads cannot alter.
- AWS CloudTrail
- Amazon Security Lake
- Config conformance packs
Across every layer
- Permission sets granted to groups, never to individuals
- Delegated administration so the management account stays out of daily use
- Every policy and detection promoted from version control
- One named owner per account and per finding
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Identity and account governance
AWS Identity and Access ManagementRoles, policies and permission boundaries for workloads and pipelines. We use it to replace wildcard permissions with the specific API calls a workload makes, and use IAM Access Analyzer to prove the reduction.
IAM Identity CenterFederated human access with permission sets per job function, issuing short-lived credentials per account and role so long-lived access keys can be retired.
AWS OrganizationsThe account hierarchy and the policy plane above it: service control policies capping what principals may do, resource control policies capping who may reach a resource, and declarative policies pinning supported service settings.
AWS Control TowerLanding zone setup and ongoing conformance, giving a consistent baseline for new accounts and a controlled way to enrol accounts that already exist.
Threat detection and investigation
Amazon GuardDutyManaged threat detection over CloudTrail, DNS, VPC flow and selected data events, delegated to the security account, with related signals correlated into attack sequence findings rather than left as isolated alerts.
Amazon InspectorContinuous vulnerability assessment of compute instances, container images and serverless functions, with findings routed to the team that owns the build.
AWS Security HubThe single prioritised queue. We use the posture standards as the control baseline and consolidate GuardDuty, Inspector, Macie and Config findings into one ranked backlog, confirming which of the two Security Hub services your estate is actually running.
Amazon DetectiveInvestigation of behaviour across time and accounts when a finding needs context, with the investigation path recorded so the analysis is reusable.
Encryption, secrets and data boundary
AWS KMSCustomer managed keys, key policies, rotation and cross-account separation, so encryption decisions and key custody are explicit rather than implied by a default.
AWS Secrets ManagerCustody and rotation of database credentials, API keys and application secrets, allowing credentials to be removed from repositories, pipeline variables and environment configuration.
Amazon MacieScoped discovery aimed at the object stores most likely to hold regulated material, used here to establish exposure. The classification and loss prevention programme belongs to our data governance and compliance work.
Configuration, logging and evidence
AWS ConfigResource configuration history and conformance rules, used both for drift detection and as the record that shows when a resource changed and to what.
AWS CloudTrailThe organisation-wide audit trail. We verify coverage, enable log file validation and place the destination in a log archive account that workload accounts cannot alter.
Amazon Security LakeNormalised, centralised security data in storage you own, with retention tiers matched to investigation needs and the analytics choice left open.
AWS Audit ManagerEvidence collection for estates already using it. It is in maintenance mode and cannot be set up in new accounts, so a new build starts on Config conformance packs plus a third-party evidence platform, which is where AWS itself points customers.
AWS ArtifactAccess to AWS's own compliance reports and agreements covering the infrastructure AWS operates, used as supporting evidence for the shared responsibility boundary.
Patching and edge protection
AWS Systems ManagerPatch baselines, maintenance windows and inventory across instances, which is where the Essential Eight patching strategies are actually evidenced on AWS.
AWS WAFManaged and custom rules in front of public applications and APIs, tuned against real traffic and released in count mode before blocking.
AWS ShieldProtection and visibility for the internet-facing edge against volumetric and application-layer denial-of-service activity.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
AWS questions
What people ask about doing this on AWS.
Cost, lock-in and the parts that go wrong, answered before you have to ask twice.
What do AWS security services cost across a large account estate?
More than most first estimates, because nearly everything is priced per account and per region. GuardDuty, Inspector, Config, Security Hub and Macie each add a line to every enrolled account, and Config in particular scales with how many resources change. The two costs that surprise clients are S3 data event logging and broad Macie scanning, both of which can dwarf the rest. We model cost at your actual account count and region set before enabling anything organisation-wide, and we would rather enable four services deliberately than nine by default.
What is the difference between an SCP, an RCP and a declarative policy?
A service control policy caps what principals inside your accounts may do. A resource control policy caps who may reach your resources, which is how you stop an external principal accessing a bucket or a key even if someone attaches a permissive resource policy. A declarative policy is different in kind: it pins a service configuration in the control plane and keeps it pinned as new APIs appear, but today it covers only a limited set of EC2, EBS and VPC settings. None of the three can repair an existing resource, which is the gap teams coming from Azure Policy do not expect.
Do we need a third-party CSPM tool, or is Security Hub enough?
For a single-cloud AWS estate, the native services are usually enough and considerably cheaper, and we will say so rather than resell something. The arguments for a third-party tool are genuine in two situations: you run more than one cloud and want one posture view, or you need attack path analysis and asset context the native services do not assemble. Be honest about the second one, because the difference between a tool that finds more findings and a tool that helps you close more findings is not visible in a demonstration.
We have no security team. Can we run GuardDuty ourselves?
You can operate it, and the harder question is who reads the findings. GuardDuty needs almost no tuning to produce useful detections, which is exactly why it accumulates in an inbox nobody owns. If nobody in your organisation can spend an hour a week on triage, the sensible sequence is to fix identity and exposure first and enable detection when there is somebody to act on it. Enabling it earlier is not harmful, but do not mistake it for a control until a name is attached to the queue.
Are the AWS security services available in the Sydney and Melbourne regions?
The core set is, and the qualification matters more than the answer. New capability generally lands in Sydney ahead of Melbourne, and occasionally in neither for some time after launch, so a design that assumes a specific feature in a specific Australian region needs verifying rather than assuming. We confirm availability per service and per region at design time and record the date we checked, because this changes often enough that a six-month-old answer is not evidence.
If we adopt AWS Control Tower and service control policies, how locked in are we?
The controls themselves are AWS-specific and not portable, so be clear-eyed about that. What does carry across is the design: the control baseline, the account and boundary model, the tagging standard and the exception process are all platform-independent, and that is the part worth documenting properly. The heavier commitment is operational rather than technical, since a policy hierarchy your workloads depend on becomes something you maintain, and unpicking it later is a project rather than a configuration change.
Related industries
Where this work has the most leverage.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Healthcare and Community Services
Administrative automation, policy search, workforce analytics and privacy uplift for healthcare and community providers, with clinical decisions left entirely to clinicians.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Free discovery workshop
Start with a security and governance discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.