Day 2: AWS Solutions Architect Professional Prep — Governance and Compliance in Complex Organizations
Creating a highly secure, well-managed community of accounts is an important part of building and scaling a successful digital infrastructure. To ensure compliance across dozens or even hundreds of separate “departments” or accounts requires establishing automated guardrails, non-stop inspections, and rock-solid centralized logging.
These were my big questions on the topic:
1. How do organizations establish mandatory organizational boundaries and continuously monitor compliance across multiple accounts?
2. What are the key architectural components used to centralize auditing and aggregate security findings across an AWS organization?
3. What are the best practices for managing cross-account access and why are they preferred?
4. How do multi-account strategies address compliance documentation, data residency, and the shared security responsibilities?
- How do organizations establish mandatory organizational boundaries and continuously monitor compliance across multiple accounts?
Organizations use Service Control Policies to set mandatory boundaries and AWS Config to continuously monitor compliance.
SCPs act as the digital company rule book that contains the rules that apply universally. They determine the maximum permissions anyone in an organization can possess. They stop non-compliant actions before they can happen.
Eg. An SCP can enforce that all storage buckets (S3) must use encryption, prevent public snapshots of database services (RDS) , or restrict the types of virtual servers that can be launched.
A key idea is that they never grant permissions; they only restrict them.
AWS Config is a continuous compliance monitor. Since manual checks are impossible at scale, AWS Config provides automated, tireless, non-stop inspection. It evaluates every resource against desired compliance rules. For example, an inspection rule (encrypted-volumes) can check if every hard drive connected to a server is encrypted or a rule (s3-bucket-public-write-prohibited) can check if public write access is blocked on storage buckets.
AWS Config tracks changes by taking point-in-time snapshots called Configuration Items or CIs to track exactly how resources change over time.
The Config Aggregator allows a central compliance team to view the compliance status of every single account across the entire organization in one place.
2. What are the key architectural components used to centralize auditing and aggregate security findings across an AWS organization?
CloudTrail is the main tool for centralized auditing and Security Hub is the main tool for managing security reporting.
If an incident occurs or when auditors come calling, there is a need for definitive proof of every action taken. Cloudtrail records every API call that occurs. It logs who performed the action, what specific action was called, when, where, and whether the action succeeded or failed. Cloudtrail might be referred to as the security camera and detailed visitor log for an organization’s digital environment.
The best practice is to set up an Organization CloudTrail Trail to ensure that all “recordings” are sent to a logging account – a single, separate, tamper-proof account that cannot be altered for audit purposes.
Security Hub helps to gather security insights across an organization. It takes security findings from more than 20 different services, normalizes them into a standard format called AWS Security Finding Format (ASFF), and presents them in a single view to the Master Account which gives managers a clear overall security score for the entire organization. We might call it the Executive Security Briefing Dashboard.
3. What are the best practices for managing cross-account access and why are they preferred?
The use of temporary credentials is preferred over long-term secrets- borrow permission, don’t hold permanent keys.
Best practice 1: IAM Roles Over IAM Users.
Roles provide temporary credentials or short-lived tokens that expire quickly (between 15 minutes and 12 hours) so security risk is reduced as there are no permanent access keys to manage or rotate. Using roles also provides a clear Audit Trail of who assumed which role and when. For highly sensitive operations, Multi-Factor Authentication (MFA) can be required to assume the role
Best practice 2: Resource-Based Policies
These policies are used when one service needs permission to access a specific resource in another account. They are commonly used for granting cross-account access to S3 storage buckets, Lambda functions, or KMS encryption keys.
4. How do multi-account strategies address compliance documentation, data residency, and the shared security responsibilities?
Data residency or data sovereignty is the concept that global regulations often mandate where data must physically reside. Common regulatory drivers include rules like GDPR (EU data must stay in the EU) and the Chinese Cybersecurity Law. These may require one to choose storage bucket regions based solely on these sovereignty requirements. This is termed S3 Regional Strategy. Compliance rules may also require in-country copies, or Cross-Region Replication (CRR).
AWS Artifact is the source for compliance documentation. It provides reports covering key frameworks such as SOC reports, PCI DSS, ISO Certifications, and HIPAA guidance. They prove that AWS is compliant with its responsibilities and are needed for audits.
AWS’s Role (Security OF the Cloud): AWS is responsible for the foundation, including physical security of data centers, network infrastructure, and updating the host operating systems.
• Customer’s Role (Security IN the Cloud): The customer is responsible for everything they manage, which includes patching their own guest operating systems, application security, managing user access (IAM), and ensuring data is encrypted
The Shared Responsibility Model is basically a Landlord/Tenant Model or partnership in which compliance is shared between AWS and the customer. The Landlord AWS is responsible for the security OF the cloud and The Tenant, or the Customer is Responsible for the security IN the cloud.
Security OF the cloud includes: physical data center security, network infrastructure, and patching the host server operating systems. Security IN the cloud includes locking the digital doors, patching your own application software, managing who has access (IAM), and making sure data is encrypted.
Overall, some of the big takeaways on how to build a compliant, secure, and scalable structure ready for any regulatory challenge are:
1.Utilize SCPs as guardrails that restrict permissions.
2. Use the Config Aggregator for centralized compliance monitoring
3. Use the CloudTrail Organization Trail for centralized auditing.
4. Always prioritize IAM roles when designing cross-account access.
See you tomorrow!