The most expensive AWS account is often not the one with the largest workload, but the one created without ownership, access boundaries or cost attribution. A strong foundation makes secure behavior the default and gives every resource an owner, environment, audit trail and budget before production begins.
Landing zone: separate control, evidence and workloads
SCPs define the maximum available permission. IAM policies still grant the actual permission inside each account.
Use a multi-account landing zone
Create an AWS Organization and keep the management account free of workloads. At minimum, separate security, log archive, shared services and production from non-production. Larger organizations can split by business unit and workload, but should avoid account sprawl without lifecycle automation. AWS recommends restricting management-account access because service control policies do not constrain identities there; see the Organizations management-account practices.
AWS Control Tower can establish and govern the landing zone, enroll accounts and apply controls. It is not a substitute for architecture decisions: define organizational units, account vending, allowed Regions, data residency, exception handling and delegated administrators first.
Design OUs around policy, not the org chart
An organizational unit exists to receive a coherent set of controls. Production may deny public RDS instances and unapproved Regions; sandbox may allow broader experimentation but cap spend and block access to corporate data. If two accounts require materially different policy, placing them in one OU creates exceptions that weaken the model. Keep SCPs small and test their effective permissions: an SCP never grants access, it limits what IAM could grant.
Use a documented account lifecycle: request, approval, automated provisioning, baseline verification, owner review, quarantine and closure. Reuse email aliases and naming conventions that do not depend on one employee. Quarantine is particularly important because immediately closing an unknown account can destroy evidence.
Secure identities before creating resources
- Protect the root user, enable MFA, remove root access keys and define a monitored emergency-access procedure.
- Use IAM Identity Center with your corporate identity provider for humans; use short-lived roles for workloads.
- Create permission sets by job function, require MFA and separate read-only, operator and administrator duties.
- Use least privilege and permission boundaries for delegated builders. Avoid shared users and permanent access keys.
The AWS sign-in guidance recommends root MFA and an administrative user in IAM Identity Center rather than daily root use.
Separate human, workload and emergency identity
Human access should originate in the corporate identity provider, be group-based and produce short-lived sessions. Workloads should assume roles through their runtime or CI/CD identity; access keys in source code or shared secrets have no acceptable rotation story. Emergency access is a third path: tightly held, MFA-protected, monitored in real time and tested periodically. If the emergency procedure has never been exercised during an identity-provider outage, it is documentation, not resilience.
Make the audit trail hard to alter
Enable organization-wide CloudTrail across all Regions and deliver it to a dedicated log-archive account with encryption, retention and restricted deletion. Add AWS Config where configuration history and compliance evidence are required. Centralize GuardDuty, Security Hub and IAM Access Analyzer findings in the security account. Alert on root use, failed console logins, CloudTrail changes, KMS key changes, public storage and security-group exposure.
Separate collection from detection and response. CloudTrail answers who called an AWS API; VPC Flow Logs show network acceptance/rejection; RDS/PostgreSQL logs show database authentication and SQL events; AWS Config records resource state over time. None replaces the others. Normalize timestamps, define retention by evidence requirement, and verify that a compromised workload account cannot delete the central copy.
Establish the network and data baseline
Standardize VPC address allocation, subnet tiers, egress, DNS and connectivity. Databases belong in private subnets and should accept traffic only from explicit application or administration security groups. Encrypt data at rest with an intentional KMS key strategy, enforce TLS in transit, store credentials in Secrets Manager and test rotation. Decide how backups cross accounts and Regions, and test restoration.
Availability boundaries must be explicit
A subnet in a second Availability Zone is useful only if the application, routing, NAT/egress dependency and database failover path also survive the first AZ. A second Region is a disaster-recovery design, not a checkbox: define which data is copied, how keys and secrets exist there, how DNS changes, which infrastructure is pre-provisioned and what consistency can be lost under the RPO.
Install cost controls on day one
- Set account and workload budgets with alerts to owners and finance.
- Enable Cost Explorer, Cost and Usage Reports, Cost Anomaly Detection and Cost Optimization Hub.
- Define mandatory tags such as
Owner,Application,Environment,CostCenter,DataClassificationandManagedBy; activate the appropriate cost-allocation tags. - Create policies for approved Regions and instance families, snapshot retention and deletion protection.
Tags serve different systems: finance needs allocation, operations needs ownership, security needs classification and automation needs lifecycle intent. Define permitted values and inheritance rules. A tag policy can standardize keys and values, but a deployment control or remediation is needed when a missing tag must block or correct creation. Pair budgets with anomaly detection: budgets track expected accumulation; anomaly detection catches unexpected shape.
Codify and continuously verify
Build accounts, networks, roles, logging and alerts with Terraform, CloudFormation or CDK. Review changes through pull requests and deploy through short-lived CI/CD roles. A good “day-zero” test proves that a new account receives identity, logs, controls, budgets and network baselines automatically. Re-run the evidence regularly because governance drifts.
Production-ready checklist: named owner, root protected, federated access, workload account separated, CloudTrail centralized, security findings delegated, budgets active, required tags enforced, private database network, backups restored in a test, and all foundation code versioned.
How PG Monitoring helps after the AWS foundation is in place
Cloud governance proves that an RDS instance is encrypted, private and tagged; it does not prove that autovacuum is keeping up, a query plan is stable, replication meets its SLA or capacity will survive the next peak. PG Monitoring fills that database-operating gap with a least-privileged PostgreSQL role, organization-scoped visibility and historical evidence across instances. Teams can correlate incidents, query regressions, locks, bloat, replication and growth without giving every operator broad AWS or database-admin access.
Practical outcome: the landing zone governs where the database may run; PG Monitoring shows whether the database is actually healthy and explainable. Talk to our team to add a PostgreSQL observability baseline to your AWS account factory.