4 AWS Security Governance and Operations
Learn how AWS security governance assigns responsibilities, structures accounts, enforces controls, and uses logs and monitoring to support ongoing security operations.
Governance and shared responsibility
AWS security governance translates business, legal, and risk requirements into rules, assigned responsibilities, and repeatable checks. A useful process is to identify the data and workloads to protect, define required security outcomes, assign owners, and verify that controls continue to work. Governance is an ongoing operational practice, not a one-time configuration.
Under the , AWS secures the infrastructure of the cloud, including facilities, hardware, and foundational services. Customers secure what they deploy and configure in the cloud. The division depends on the service: for Amazon EC2, customers manage the guest operating system and applications; for more abstracted services such as Amazon S3, AWS manages more of the underlying stack, while customers remain responsible for their data, access, and service configuration.
AWS compliance reports can support a customer's assessment, but they do not by themselves make the customer's workload compliant. Customers remain responsible for configuring, operating, and verifying their workloads.
Accounts, guardrails, and access
Separate AWS accounts provide boundaries for workloads, teams, environments, and security functions. Related accounts can be grouped into organizational units (OUs) so that consistent guardrails apply to them. For example, an organization might use separate OUs for production and development, with stricter controls on production. Dedicated accounts for centralized logging and security operations can help separate those functions from workload administration. AWS Control Tower can help establish and govern a multi-account landing zone.
AWS Organizations provides central management for accounts and organization-wide policies. set the maximum permissions available to principals in member accounts; they do not grant permissions. An SCP can deny use of a service or restrict activity to approved Regions. An IAM policy must still grant the action, and applicable guardrails must allow it. SCPs do not affect principals in the organization's management account, so that account must be protected and tightly limited separately.
Use IAM to grant people and workloads only the access they need. Prefer roles and temporary credentials over long-lived credentials where practical, apply least privilege, and review permissions regularly. Organization-wide guardrails complement IAM; they do not replace account-level identity and resource policies.
Policies and control types
A security policy states an intended outcome, such as requiring encryption for production data or requiring security logs to be retained centrally. Controls implement and verify that outcome. AWS Control Tower groups controls into three broad types:
block prohibited actions, such as attempting to disable a required safeguard.
identify noncompliant resource configurations and report them.
check supported infrastructure-as-code deployments before resources are provisioned.
These controls can be implemented using mechanisms such as Organizations policies, rules, and CloudFormation hooks. A control helps enforce or observe a requirement, but teams still need owners and processes to address exceptions and findings.
Logging and audit evidence
Logging records what happened; monitoring evaluates signals and helps people or automated systems respond. records account activity and API events, supporting investigation and audit. An organization trail can collect events across accounts. records resource configurations and evaluates them against rules, helping teams track changes and detect noncompliance. The services answer different questions: CloudTrail can show who performed an action and when; Config can show how a resource was configured and whether it meets a rule.
Centralize logs in a protected location, such as a dedicated log archive account, and limit who can alter or delete them. Define retention, access, and review practices to meet operational and evidence needs. Include relevant service and workload logs, not just API activity: application and operating-system events may be needed to understand an incident.
Continuous monitoring and response
Continuous monitoring turns records and configuration data into timely signals. analyzes supported data sources for suspicious activity and generates findings. helps centralize security posture checks and findings. collects metrics and logs and can trigger alarms. can identify configuration drift or rule violations. These services complement one another: a suspicious API pattern, an exposed resource, and an application error may require different signals and response actions.
A practical operating loop connects collection to learning:
Collect activity, configuration, workload, and service logs.
Detect suspicious behavior and policy violations.
Triage findings by severity, affected account, and business impact.
Respond using documented procedures, such as restricting access or isolating a resource when appropriate.
Learn from the event by fixing root causes, tuning detections, and updating controls or procedures.
Monitoring is effective only when findings reach an owner and a response process. Test alert routing and incident procedures, review exceptions, and verify that logging and detection coverage remains enabled as accounts and workloads change.