AWS Organizations από την πρώτη μέρα.

Το λάθος είναι σιωπηλό. Γράφεσαι στην AWS, κάνεις deploy το MVP, βγάζεις λίγους πελάτες, και κάπου εκεί κάποιος τρέχει terraform apply σε λάθος workspace, ή κολλάει prod IAM key σε dev script, ή τρέχει ένα ξεχασμένο cleanup job που βρίσκει το production S3 bucket γιατί ζει στο ίδιο account με όλα τα άλλα.

Αποφεύγεται. Η λύση είναι AWS Organizations + πολλά accounts, και πρέπει να το στήσεις πριν έχεις κάτι που αξίζει να το προστατεύσεις — γιατί η εκ των υστέρων μετάβαση, μόλις το έχεις, είναι έργο έξι μηνών.

Γιατί ένα account είναι λάθος default

Ένα account σημαίνει:

• Κάθε IAM role με ευρείες άδειες μπορεί να ακουμπήσει κάθε resource που έχεις.
• Η κατανομή κόστους απαιτεί χειροκίνητα tags σε κάθε resource. Τα tags παρεκκλίνουν. Τα tags ψεύδονται.
• Τα service quotas είναι κοινά. Το dev pipeline σου που καίει EC2 instances τρώει το headroom του prod.
• Ένα διαρρεύσαν CI key είναι δυνητικά ένα διαρρεύσαν production environment.
• Το split αργότερα σημαίνει migration δεδομένων μεταξύ accounts, που είναι πραγματικό engineering, όχι απλό click.

Το multi-account τα γυρνάει όλα. Resources σε διαφορετικά accounts είναι φυσικά απομονωμένα από το IAM. Το κόστος εμφανίζεται ανά account στο Cost Explorer χωρίς να tag-άρεις. Τα service quotas είναι ανά account. Το blast radius από οποιοδήποτε λάθος είναι περιορισμένο.

Το ελάχιστο βιώσιμο Organization

Δεν χρειάζεσαι 14 accounts την πρώτη μέρα. Χρειάζεσαι τρία:

Root org (χωρίς resources, μόνο billing)
├── management         ← το account με το οποίο γράφτηκες. Κλειδωμένο.
├── Workloads OU
│   ├── prod           ← production workloads
│   └── nonprod        ← dev, staging, ephemeral envs
└── Sandbox OU
    └── sandbox        ← προσωπικά πειράματα μηχανικών

Αυτό. Τέσσερα accounts, δωρεάν, στήνονται σε ένα απόγευμα. Κάθε account έχει το δικό του root credential (κλειδωμένο σε password manager, ποτέ σε χρήση) και τη δική του πρόσβαση μέσω IAM Identity Center για ανθρώπους.

Αν τελικά χρειαστείς logging (κεντροποιημένο CloudTrail), audit, ή shared services (private DNS, transit gateway), πρόσθεσέ τα αργότερα ως ξεχωριστά accounts. Το νόημα είναι η τοπολογία, όχι ο αριθμός των accounts.

Τα SCPs είναι η πραγματική υπερδύναμη

Τα Service Control Policies είναι organization-level guardrails που ούτε ο root user ενός member account δεν μπορεί να παρακάμψει. Από εδώ έρχεται ο πραγματικός έλεγχος blast radius.

Τρία SCPs που βάζουμε σε κάθε νέο Organization, πρώτη μέρα:

// 1. Άρνηση δημιουργίας resources εκτός EU regions (GDPR + προβλεψιμότητα κόστους)
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["eu-central-1", "eu-west-1", "us-east-1"]
    }
  }
}

(Κράτα το us-east-1 στο allowlist για IAM, CloudFront, ACM certs για CloudFront, και Route 53 — είναι global services με control planes που η AWS τα έχει εκεί.)

// 2. Αποτροπή εξόδου από το Organization ή απενεργοποίησης guardrails
{
  "Effect": "Deny",
  "Action": [
    "organizations:LeaveOrganization",
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail",
    "guardduty:DeleteDetector",
    "guardduty:DisassociateMembers"
  ],
  "Resource": "*"
}

// 3. Μπλοκάρισμα public S3 ACLs σε org level (defence in depth)
{
  "Effect": "Deny",
  "Action": ["s3:PutBucketAcl", "s3:PutObjectAcl"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "s3:x-amz-acl": ["public-read", "public-read-write", "authenticated-read"]
    }
  }
}

Τρία policies, attached στο root ή σε συγκεκριμένα OUs. Δεν κοστίζουν τίποτα και αποτρέπουν ολόκληρες κατηγορίες incidents.

Οι άνθρωποι μπαίνουν μέσω IAM Identity Center

Σταμάτα να φτιάχνεις IAM users. Το μοτίβο για το 2026 με οποιονδήποτε αριθμό accounts πάνω από ένα:

1. Ενεργοποίησε IAM Identity Center (πρώην AWS SSO) στο management account.
2. Όρισε permission sets (Admin, Developer, ReadOnly, Billing).
3. Ανάθεσε ανθρώπους σε permission sets ανά account. Ο ίδιος άνθρωπος μπορεί να έχει Admin στο sandbox και ReadOnly στο prod.
4. Οι άνθρωποι κάνουν login με aws sso login, παίρνουν short-lived credentials. Δεν υπάρχουν long-lived keys να διαρρεύσουν.

Αν η ομάδα σου είναι σε Google Workspace ή Microsoft 365, σύνδεσε το Identity Center με αυτό ως πηγή ταυτότητας. Ένα sign-on, ένα offboarding ritual.

Retrofitting: δεν είναι όσο φοβάσαι

Αν είσαι ήδη σε single-account setup, τα νέα δεν είναι καταστροφικά. Η σειρά μετάβασης που χρησιμοποιούμε:

1. Φτιάξε το Organization και πρόσθεσε ένα φρέσκο workloads-prod account.
2. Με AWS Resource Access Manager και cross-account IAM roles, ξεκίνα να καταναλώνεις shared resources από το νέο account.
3. Μετάφερε πρώτα τα stateless workloads (containers, lambdas, EC2 με rebuild scripts). Είναι εύκολα.
4. Μετάφερε τα stateful (RDS, S3) με τα κατάλληλα AWS εργαλεία. RDS Cross-Account Snapshot Sharing, S3 Batch Replication.
5. Επανάλαβε για non-prod, μετά sandbox.
6. Το αρχικό account γίνεται management — βγάλε τα workloads και χρησιμοποίησέ το για billing + Organization root μόνο.

Το επώδυνο κομμάτι δεν είναι το migration· είναι το IAM cleanup, τα hardcoded account IDs, και τα ECR repos που είχαν ξεχάσει ότι μοιράζονταν. Υπολόγισε δύο μήνες για ένα μικρό σύστημα, τέσσερις για οτιδήποτε πάνω από 30 services.

Στήνουμε AWS landing zones για ομάδες σε Ελλάδα και Ευρώπη — Organization, OUs, SCPs, Identity Center, όλο το πακέτο. Συνήθως 1–2 εβδομάδες. Πες μας.