AWS provides the security tools. The institution provides the operational discipline that turns the tools into a defensible posture. For public-sector institutions (government agencies, universities, healthcare entities, nonprofits), the AWS security baseline is the documented set of controls that holds up to audit, supports the institutional authorization boundary, and produces measurable risk reduction. This post is the baseline.
We covered the shared-responsibility model in AWS Shared Responsibility for Government and the GovCloud-specific pattern in Empowering Government Operations with AWS GovCloud. This post focuses on the operational baseline that applies across institutional AWS workloads.
The Six Pillars of the Institutional AWS Baseline
The institutional AWS security baseline organizes around six operational pillars. Each pillar is a documented set of controls that the institution implements, monitors, and maintains.
Pillar 1: Account Structure
The account structure is the institutional authorization boundary. The pattern that holds:
AWS Organizations as the umbrella. The institution operates a single AWS Organization with hierarchical organizational units (OUs) for environment (production, staging, development), workload class (sensitive, standard, sandbox), and business unit (department, agency, program).
Service Control Policies as guardrails. SCPs at the OU level enforce institutional baselines: no resources in non-approved regions, no creation of long-lived IAM users, no modification of CloudTrail or Config configurations, no public S3 buckets in sensitive OUs.
Workload accounts. Each workload runs in its own account. This isolates blast radius for security incidents and simplifies authorization-boundary documentation.
Centralized billing through the management account. The management account holds consolidated billing, AWS Organizations administration, and SCP policy management. No workloads run in the management account.
Logging account. A dedicated account for centralized log aggregation (CloudTrail, VPC Flow Logs, Config, application logs). Access to the logging account is highly restricted.
Security tooling account. A dedicated account for cross-account security tooling (Security Hub, GuardDuty delegated administration, Inspector). Access follows the same restriction pattern as the logging account.
Pillar 2: Identity and Access
The identity surface is where most cloud incidents start. The institutional pattern:
Federated identity through institutional IdP. AWS IAM Identity Center (formerly AWS SSO) integrates with the institutional identity provider (Okta, Azure AD, ADFS, university CAS or Shibboleth, federal HSPD-12). Users authenticate through institutional identity, not AWS-local accounts.
No long-lived access keys. IAM users with access keys are prohibited at the SCP level. All programmatic access uses IAM roles with short-lived credentials (instance profiles, Lambda execution roles, IRSA for EKS).
MFA enforced for human access. Multi-factor authentication is required for any human access to AWS, including root account, IAM users (where they exist for legacy reasons), and IdP-federated access.
Root account secured. The root account credentials are stored in institutional credential management (a hardware security module or institutional vault). MFA is enabled. The root account is used only for the small set of operations that require it.
Least-privilege IAM policies. Roles and policies grant only the permissions required for the workload. Permission boundaries protect against privilege escalation. Unused permissions are pruned on cadence.
Periodic access review. Quarterly review of who has access to what, with documented removal of access that is no longer needed. The review evidence is part of the institutional audit posture.
Pillar 3: Data Protection
Data protection is the encryption, key management, and backup posture:
Encryption at rest by default. All EBS volumes, RDS instances, S3 buckets, and EFS file systems are encrypted at rest. The default is enforced by SCP or AWS Config rules.
Customer-managed KMS keys for sensitive data. For sensitive workloads, AWS-managed keys are insufficient; customer-managed KMS keys provide audit visibility and lifecycle control. Key rotation is enabled.
Encryption in transit. TLS 1.2 minimum for all data in transit. TLS 1.3 where supported. Internal VPC traffic between services is encrypted where the data sensitivity warrants.
Backup discipline. AWS Backup or service-native backup configured for all stateful workloads. Recovery point objective and recovery time objective documented. Restore exercises performed on cadence.
Cross-region replication for critical data. S3 Cross-Region Replication, RDS automated backups copied to a secondary region, and EBS snapshot copying for critical workloads. The cross-region capability is documented and tested.
Pillar 4: Network Security
The network surface follows defense in depth:
VPC architecture. Each workload account has its own VPC with public, private, and isolated subnets. No workloads run in the default VPC.
Security Groups as the primary firewall. Stateful, instance-level rules. Rules are minimum-necessary; broad allow-all rules are prohibited at the SCP or Config-rule level.
Network ACLs for subnet-level control. Stateless rules at the subnet boundary. NACLs provide defense-in-depth against Security Group misconfiguration.
WAF in front of public-facing surfaces. AWS WAF on CloudFront distributions, ALBs, and API Gateway endpoints. Managed rule sets (AWS Managed Rules, Bot Control) are the baseline.
AWS Shield Standard everywhere; Shield Advanced for high-value targets. Shield Standard is included; Shield Advanced is added for institutional workloads with high public visibility or known DDoS exposure.
VPC Flow Logs to centralized logging. Flow logs from every VPC, retained for institutional audit retention period.
Pillar 5: Logging and Monitoring
The logging posture is what makes incidents recoverable:
CloudTrail for all accounts. Multi-region CloudTrail for both management and data events on critical resources, delivered to the centralized logging account with S3 Object Lock for tamper resistance.
AWS Config for posture monitoring. Config rules aligned to institutional standards (NIST 800-53, CIS AWS Foundations, institutional internal). Drift detection and notification on baseline deviation.
GuardDuty for threat detection. Cross-account GuardDuty with delegated administration in the security tooling account. Findings reviewed on documented cadence with response procedures exercised.
Security Hub for posture management. Cross-account Security Hub aggregating findings from GuardDuty, Inspector, Macie, and third-party tools. Compliance frameworks enabled (CIS, NIST, PCI as applicable).
CloudWatch for operational monitoring. Metrics, alarms, and dashboards for operational health. Log retention aligned to institutional retention periods.
Service-specific logs. S3 access logs, ALB access logs, CloudFront access logs, RDS audit logs. All flow to the centralized logging account.
Pillar 6: Incident Response
Incident response is the documented procedure that the institution exercises:
Runbooks for common incident types. Compromised credential, exposed S3 bucket, suspicious EC2 activity, data exfiltration indicator, account takeover. Each has a documented procedure with named owners and decision points.
Response team identified. The incident response team is named, trained, and reachable. For institutional workloads, this typically includes the cloud engineering team, security team, and institutional executives for decisions above operational thresholds.
Communication plan. Internal notifications, external notifications (institutional stakeholders, regulators where applicable, public communications), and post-incident reporting. The communication plan is documented in advance, not improvised.
Tabletop exercise on cadence. Quarterly or semi-annual tabletop exercises run through realistic scenarios. The exercises produce findings that improve the runbooks.
Post-incident review. Every incident, exercise or real, produces a documented review with root cause, response timeline, and improvement actions. The reviews are institutional learning artifacts.
What This Baseline Produces
For institutional AWS workloads with the baseline implemented and maintained:
Audit defensibility. The baseline aligns to NIST 800-53, CIS AWS Foundations, and institutional security frameworks. Audit conversations are about evidence of operation, not whether controls exist.
Risk visibility. Continuous monitoring through Security Hub, GuardDuty, Inspector, and Config produces visible risk posture. Drift is detected and remediated.
Incident readiness. When (not if) incidents occur, the institution responds from a documented playbook with practiced procedures.
Operational sustainability. The baseline scales as the workload count grows. New workloads inherit the baseline through account-vending automation. The per-workload security overhead is low.
For managed cloud operations engagements supporting public-sector institutions, this baseline is the engagement scope. For institutions operating internally, the same baseline applies at whatever depth the internal team can sustain.
Frequently Asked Questions
How long does it take to implement the institutional AWS security baseline?
For greenfield AWS adoption: 6 to 12 weeks to implement the foundational baseline (Organizations, SCPs, Identity Center, logging, monitoring) before significant workload migration. For institutions with existing AWS workloads: 3 to 6 months to remediate existing accounts to the baseline while continuing to operate.
Should institutional AWS use AWS Control Tower or roll a custom Landing Zone?
Control Tower is the right starting point for most institutions. It encodes AWS's recommended baseline and accelerates implementation by months. Custom Landing Zones make sense for institutions with specific requirements that Control Tower does not yet support (some federal-specific requirements, some institution-specific governance models). Most institutions land at Control Tower with institutional customization layered on top.
What is the typical institutional AWS security tooling stack?
AWS-native: CloudTrail, Config, GuardDuty, Security Hub, Inspector, Macie (for sensitive-data workloads), WAF, Shield. Third-party: institutional SIEM integration, vulnerability scanning, identity-provider integration, secrets management. The mix depends on institutional standards and existing tooling investments.
How does this baseline differ for AWS GovCloud workloads?
The baseline pattern is the same. The available services and the underlying compliance authorizations differ. AWS GovCloud has FedRAMP High authorization for many services, ITAR data-residency, and US-Persons-only personnel access. For institutional workloads with federal compliance requirements, GovCloud is the right region; the security baseline applies the same way.