Forem: Isaac Oppong-Amoah

The Unofficial Guide to Reconstructing a Cloud Breach in Minutes

Isaac Oppong-Amoah — Fri, 27 Feb 2026 12:53:07 +0000

Most security conversations in the cloud start with the wrong question.

We ask:

Are all regions secured?
Are backups enabled?
Is SSO working?
Is encryption turned on?

But the better question is:

If we were breached right now, could we reconstruct exactly what happened within minutes?

Cloud security maturity isn’t about enabled services.
It’s about forensic clarity under pressure.

Region Control: The Illusion of Coverage

AWS Security Hub allows you to aggregate findings across regions. At scale, many organizations want:

One approved region
All other regions disabled

At the organization level, this is governed via AWS Organizations and its policy types.

The critical nuance: Organizations policy operators are deterministic — not expressive.

They evaluate literally.
They don’t “subtract dynamically.”
They don’t infer intent.

Relying on implicit behavior (e.g, enabling “all supported regions except one”) introduces:

Drift
Silent misconfiguration
Inconsistent security posture

The mature pattern is explicit region assignment using supported policy constructs.

Security guardrails should be:

Explicit
Testable
Predictable

Backups Don’t Equal Recovery

AWS Backup makes centralized protection elegant:

Tag-based backup plans
Cross-account vault copies
Automated scheduling
Policy-based governance

But complexity increases when:

Using customer-managed KMS keys
Performing cross-account restores
Protecting services with limited integration support

Encryption boundaries matter.

AWS-managed keys cannot be shared across accounts for cross-account copy.
Customer-managed keys require:

Explicit key policies
Grants
Proper principal scoping

Most organizations validate backup jobs.
Few validate cross-account restore under incident constraints.

If your incident response role cannot decrypt your backup during a breach,
you don’t have recovery — you have storage.

Identity: The Quiet Failure Plane

AWS IAM Identity Center (formerly AWS SSO) issues temporary credentials.

Console sessions may appear active.

But underneath:

Temporary credentials expire
SigV4 signatures have time validation
Services re-authenticate per request

An expired signature error doesn’t necessarily mean the session ended — it often means the underlying temporary credentials exceeded their validity window.

In incident response scenarios, this can:

Interrupt forensic log retrieval
Break console queries mid-analysis
Cause confusion around privilege changes

The identity plane in AWS is intentionally ephemeral.

Security operations must treat credential lifecycle as a first-class operational dependency.

The Shift: From Configuration to Reconstruction

Cloud-native security leadership requires three shifts:

1. Deterministic Guardrails

Test the organization's policies before deployment.
Avoid assumption-based logic.

2. Recovery Engineering

Quarterly restore drills.
Cross-account decryption validation.
Isolated forensic restore environments.

3. Identity Observability

Monitor session duration.
Correlate session activity using AWS CloudTrail.
Detect anomalous token usage.

The Real Metric of Security Maturity

Not:

Number of services enabled
Number of findings resolved
Number of policies attached

But:

Time to reconstruct the incident timeline.

Can you answer, within minutes:

Which role was assumed?
From where?
Which API calls were made?
What data was accessed?
Whether backups are clean and restorable?

If not, your environment isn’t necessarily insecure.

It’s opaque.

👤👤👤 What Organizations on AWS Should Do

If you're running workloads on AWS at scale, this is non-negotiable:

1. Make Policy Behavior Explicit

Use @@assign in the organization's policies.
Standardize approved regions.
Continuously validate guardrails in a test OU before production rollout.

2. Engineer for Recovery, Not Reporting

Perform quarterly cross-account restore drills.
Validate KMS key grants from incident response roles.
Simulate ransomware-style account lockouts and test recovery paths.

3. Centralize and Protect Logs

Enable organization-wide AWS CloudTrail.
Send logs to a dedicated log archive account.
Enable immutable storage and restricted access.

4. Treat Identity as Tier-0 Infrastructure

Standardize session duration policies.
Monitor STS token usage.
Alert on unusual AssumeRole patterns.
Enforce MFA everywhere possible.

5. Measure Reconstruction Time

Track:

Time to detect
Time to identify compromised role
Time to confirm data access
Time to validate backup integrity

Make incident timeline reconstruction speed a board-level KPI.

👤 What Individuals (Engineers & Security Practitioners) Should Do

Cloud resilience isn’t only organizational; it’s personal.

1. Understand Evaluation Models

Don’t just use services — understand how they evaluate:

Organizations policies
IAM policy logic
SCP inheritance
Region enforcement behavior

Read the documentation. Test edge cases.

2. Practice Restore Drills Yourself

Spin up:

A test account
Cross-account KMS encryption
Backup copy and restore workflows

Break it intentionally. Learn how it fails.

3. Monitor Your Own Credential Behavior

Understand:

Session duration
Temporary credential expiration
SigV4 signing validity

Know why “Signature expired” happens — before it happens during an incident.

4. Think Like an Investigator

When you build something, ask:

If this is abused, will I see it?
Where will the logs appear?
Can I correlate this action in under 5 minutes?

Design for your future stressed self.

To Conclude

Cloud security isn’t about stacking services.

It’s about deeply understanding:

Policy evaluation models
Encryption boundaries
Identity lifecycle behavior

Because protection is prevention.
But resilience is reconstruction speed.

And the organizations that lead in the cloud
are the ones that can explain exactly what happened without guessing.

References

Beyond Firewalls: How AWS WAF Becomes Your First Line of Cloud Defense

Isaac Oppong-Amoah — Tue, 10 Feb 2026 16:15:09 +0000

Most cloud breaches don’t start with zero-days or kernel exploits.
They start with a login endpoint, an exposed API, or an unvalidated input field.

That’s where AWS WAF quietly decides whether your application survives the internet.

This isn’t a beginner’s overview.
This is how AWS WAF works in real environments, how security teams actually use it, and why it’s a non-negotiable control for production workloads.

Why Application-Layer Security Is the Real Battleground

Infrastructure security answers who can reach your system.
Application security answers what they can do once they get there.

Attackers don’t brute-force IAM roles — they:

Inject SQL through query strings
Abuse APIs at scale
Weaponize bots against login flows
Probe business logic, not ports

AWS WAF exists precisely at that intersection: before code execution, after network routing.

What AWS WAF Really Is (and Isn’t)

AWS WAF is a Layer 7 policy engine, not a traditional firewall.

It:

Inspects HTTP/S requests in real time
Evaluates them against ordered rules
Applies deterministic actions: allow, block, or observe

It does not:

Replace secure coding
Patch vulnerable applications
Protect resources exposed directly via public IPs

Think of AWS WAF as programmable intent enforcement for your application edge.

Where AWS WAF Lives in the Request Path

AWS WAF is enforced before traffic reaches your application logic.

Request lifecycle

Client sends request
CloudFront / ALB / API Gateway receives it
AWS WAF evaluates the Web ACL (top-down)
Decision is made in milliseconds
Only clean traffic reaches your app

This is why WAF mistakes are expensive — and why tuning matters.

The Rule Engine: Where Security Becomes Strategy

AWS WAF doesn’t “detect threats.”
It enforces intent.

Managed Rules: Your Baseline

AWS-managed rule groups protect against:

SQL injection
Cross-site scripting (XSS)
Known bad inputs
OS command injection
Common scanners and exploits

They are continuously updated and should be enabled by default.

But managed rules alone don’t win wars.

Custom Rules: Where You Win

Custom rules encode business logic security — the things attackers can’t predict.

Examples:

APIs that must only be called with a custom header
Admin paths restricted to VPN IPs
Requests missing mandatory tokens
Abnormal payload structures

Example: Block requests without a required header

{
  "Statement": {
    "NotStatement": {
      "Statement": {
        "ByteMatchStatement": {
          "FieldToMatch": { "SingleHeader": { "Name": "x-internal-token" } },
          "SearchString": "expected-value",
          "TextTransformations": [{ "Type": "NONE", "Priority": 0 }],
          "PositionalConstraint": "EXACTLY"
        }
      }
    }
  },
  "Action": { "Block": {} }
}

This is where AWS WAF stops being generic — and starts being powerful.

Rate Limiting: The Most Underrated Control

Most real attacks aren’t clever. They’re loud and fast.

Rate-based rules stop:

Credential stuffing
API scraping
Login brute-force attempts
Layer 7 denial-of-service attacks

They work because legitimate users behave predictably.
Attack tools don’t.

One well-placed rate rule can eliminate entire attack classes.

Bot Control: Defending Against Automation, Not Humans

Bots don’t look like attackers.
They look like browsers.

AWS WAF Bot Control uses:

Behavioral analysis
Browser fingerprinting
Reputation intelligence
Request pattern modeling

This is critical for:

Public APIs
E-commerce platforms
Authentication endpoints
SaaS applications

If your app is public and valuable, bots will find it.

Visibility: Turning Blocks into Intelligence

A WAF that blocks without logging is blind.

AWS WAF integrates with:

CloudWatch (metrics)
S3 (full request logs)
Kinesis Firehose
SIEM platforms

Production rule lifecycle

Deploy in COUNT mode
Observe real traffic
Tune false positives
Enforce with BLOCK
Re-evaluate continuously

Security without feedback loops fails quietly.

AWS WAF and DDoS: Know the Boundary

AWS WAF and AWS Shield are complementary.

Layer	Service	Purpose
L3/L4	Shield	Volume-based attacks
L7	WAF	Logic-based attacks

WAF filters intent.
Shield absorbs force.

You need both for public-facing workloads.

Operating at Scale: The Enterprise Reality

In multi-account environments:

Web ACLs should be centrally managed
Policies should be shared consistently
Drift should be prevented

AWS Firewall Manager enables:

Organization-wide WAF enforcement
Standardized protections
Easier audits
MSSP-scale operations

Security should scale faster than engineering teams.

Hard-Won Best Practices

Always protect CloudFront, not just ALBs
Enable managed rules first — customize second
Never deploy directly in BLOCK mode
Log everything, sample nothing
Separate prod and non-prod Web ACLs
Treat WAF alerts as security signals, not noise

Final Verdict

AWS WAF isn’t flashy.
It doesn’t replace secure code or zero trust.
It doesn’t stop every breach.

But it buys time, reduces blast radius, and filters chaos before it hits your code.

In cloud security, that difference is everything.

If your application is public and AWS WAF isn’t in front of it —
you’re not exposed.

You’re unguarded.

📚 References

The Definitive Blueprint for Constructing a Fortified Cloud Infrastructure: A Focus on AWS

Isaac Oppong-Amoah — Fri, 30 Jan 2026 17:46:18 +0000

Cloud isn’t the future anymore.
It’s the battlefield.

Every modern organization runs on cloud infrastructure, and every attacker knows it. The question is no longer “Should we secure the cloud?”—it’s “How do we design cloud security so deeply that failure becomes expensive, loud, and recoverable?”

This is not a checklist.
This is a blueprint—the kind used by teams that expect to scale and survive.

🧠 First Principle: Cloud Security Is Architecture, Not a Tool

If your cloud security strategy starts with a product, you’re already late.

Real security starts with architectural intent:

Identity before network
Automation before humans
Detection before prevention
Recovery before perfection

On AWS, this mindset is formalized in the Well-Architected Framework (Security Pillar)—a model that treats security as a system, not a feature.
👉 https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

🏗️ Step 1: Choose a Cloud Provider That Assumes Breaches Will Happen

Security maturity shows in what a provider prepares for—not what they market.

What actually matters:

Independent compliance validation (ISO 27001, SOC 2, GDPR)
Native DDoS and application-layer protection
Clear shared responsibility boundaries

AWS doesn’t just claim compliance—it publishes it, audits it, and operationalizes it.
👉 https://aws.amazon.com/compliance
👉 https://aws.amazon.com/shield
👉 https://aws.amazon.com/waf

Design assumption: attacks are inevitable. Survival is optional.

🔐 Step 2: Encrypt Everything (Then Control the Keys)

Encryption is table stakes. Key ownership is power.

Minimum baseline:

TLS everywhere (no exceptions)
Encryption at rest by default
Centralized key lifecycle control

AWS makes this boring—in a good way:

AWS KMS for managed encryption
CloudHSM for high-assurance key control
Native encryption across S3, EBS, RDS

👉 https://aws.amazon.com/kms
👉 https://aws.amazon.com/cloudhsm

If your data leaks and it isn’t encrypted, the incident becomes a headline.

🧍 Step 3: Identity Is the New Perimeter

Firewalls don’t stop credential abuse.
Identity design does.

Modern cloud security assumes:

No implicit trust
No standing privileges
No shared credentials

AWS IAM enables this through:

Least-privilege policies
Mandatory MFA
Permission analysis with IAM Access Analyzer
Full activity logging via CloudTrail

👉 https://aws.amazon.com/iam
👉 https://aws.amazon.com/cloudtrail

If identity fails, everything else is decoration.

🌐 Step 4: Network Security Still Matters—Just Differently

Yes, zero trust matters.
No, networks are not obsolete.

Strong cloud networks provide:

Isolation via VPCs
Explicit traffic control via Security Groups and NACLs
Behavioral threat detection

AWS GuardDuty continuously watches for malicious activity using threat intelligence and ML—without agents, tuning, or fatigue.
👉 https://aws.amazon.com/guardduty
👉 https://aws.amazon.com/vpc

Design for containment, not just prevention.

🔍 Step 5: Continuous Security Is the Only Real Security

Annual audits don’t stop real attackers.

Modern security is:

Always on
Always measuring
Always verifying assumptions

AWS enables this with:

Amazon Inspector for vulnerability scanning
Amazon Macie for sensitive data discovery
Continuous configuration tracking via AWS Config

👉 https://aws.amazon.com/inspector
👉 https://aws.amazon.com/macie

Security that sleeps is security that fails.

🚨 Step 6: Incident Response Is a Feature, Not a Document

If your incident response plan lives in a PDF, it won’t survive first contact.

Cloud-native IR requires:

Real-time detection
Automated containment
Forensic-grade logging
Post-incident accountability

AWS operationalizes this with:

CloudWatch for signals
CloudTrail for evidence
WAF & Shield for active defense
AWS Config for state reconstruction

👉 https://aws.amazon.com/cloudwatch

Resilience is the ability to respond without panic.

🔄 Step 7: Patch Like an Engineer, Not a Hero

Unpatched systems remain the easiest way in.

Manual patching does not scale.
Automation does.

AWS Systems Manager handles:

Patch automation
Compliance reporting
Hybrid environments

👉 https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html

If patching depends on memory, it will fail.

🧠 Step 8: Humans Are Part of the Attack Surface

Most breaches still start with people—not packets.

Security-mature teams invest in:

Continuous security awareness
Phishing simulations
Role-based cloud training

AWS provides structured learning through AWS Training & Certification and Skill Builder.
👉 https://aws.amazon.com/training

Culture is the last line of defense.

⚖️ Step 9: Governance Is How Security Scales

Without governance, security collapses under growth.

AWS enables scalable control using:

AWS Organizations for multi-account isolation
AWS Artifact for audit evidence
AWS Config for policy enforcement

👉 https://aws.amazon.com/organizations
👉 https://aws.amazon.com/artifact

Compliance isn’t red tape—it’s institutional memory.

🏁 Final Thought: Cloud Security Is a System, Not a Silo

The strongest cloud environments aren’t secured by luck or tools.

They are:

Designed
Automated
Measured
Rehearsed

AWS doesn’t eliminate risk—but it gives engineers the primitives to build systems that fail safely, recover fast, and scale confidently.

The real question is no longer “Is the cloud secure?”
It’s “Did you design it to be?”

📚 References

AWS Well-Architected Framework – Security Pillar
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
AWS Shared Responsibility Model & Compliance Programs
https://aws.amazon.com/compliance
https://aws.amazon.com/compliance/shared-responsibility-model
AWS Identity & Access Management (IAM) and Access Analyzer
https://aws.amazon.com/iam
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html
AWS Encryption Services (KMS & CloudHSM)
https://aws.amazon.com/kms
https://aws.amazon.com/cloudhsm
AWS Network & Threat Protection (VPC, GuardDuty, WAF, Shield)
https://aws.amazon.com/vpc
https://aws.amazon.com/guardduty
https://aws.amazon.com/waf
https://aws.amazon.com/shield
Continuous Security & Monitoring (Inspector, Macie, CloudTrail, CloudWatch)
https://aws.amazon.com/inspector
https://aws.amazon.com/macie
https://aws.amazon.com/cloudtrail
https://aws.amazon.com/cloudwatch
Patch Management & Governance (Systems Manager, Organizations, Artifact)
https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html
https://aws.amazon.com/organizations
https://aws.amazon.com/artifact
AWS Security Training & Certification
https://aws.amazon.com/training

AWS Cloud Security: Designing Self-Securing Systems

Isaac Oppong-Amoah — Tue, 27 Jan 2026 11:53:27 +0000

Cloud security is evolving faster than most teams can react. As we kick off 2026, one truth is unavoidable:

Security is no longer about reacting to incidents — it’s about building systems that secure themselves.

AWS re:Invent 2025 didn’t just release new features; it redefined the future of cloud security. Here’s what engineers, DevSecOps teams, and SOCs need to know going forward.

Why 2026 Demands a New Security Mindset

Old habits die hard:

Build → Misconfigure → Detect → Respond → Repeat

In 2026, that cycle is broken. Teams that still focus on “faster response” are already behind. AWS’s announcements show that prevention, automation, and context are now the keys to cloud security.

🎥 AWS re:Invent2025 Security sessions:
AWS re:Invent2025 Security sessions

1. Security Starts at Design Time

The AWS Security Agent (Preview) now surfaces risks during design and development, before workloads reach production.

Identifies architectural risks early
Detects insecure code patterns
Provides remediation guidance aligned with AWS best practices
Supports proactive security testing

The cheapest vulnerability to fix is the one that never reaches production.

2. SOC Work Is AI-Assisted, Not Manual

AWS’s AI-driven approach to SOC operations is redefining incident response:

Correlates signals automatically
Provides contextual insights
Reduces mean-time-to-response

🔗 AWS Security: AWS Security
🎥 re:Invent SOC & detection sessions:

Human analysts focus on judgment, not alert noise.

3. Least Privilege Becomes Automatic

IAM Policy Autopilot finally ends manual IAM tuning:

Observes real application behavior
Generates least-privilege policies automatically
Eliminates dangerous wildcard permissions

🔗 AWS IAM Best Practices: IAM Docs
🎥 re:Invent IAM sessions:

The future: Over-permissioned roles are unacceptable.

4. Cloud-Native XDR Is the Baseline

GuardDuty now correlates identity, workload, and network signals into attack narratives, not isolated alerts:

EC2 and ECS detection combined
Threat sequences mapped to MITRE ATT&CK
Prioritized insights instead of alert noise

🔗 Docs: GuardDuty
🔗 MITRE ATT&CK: MITRE ATT&CK
🎥 re:Invent GuardDuty & threat detection sessions:

SOC teams investigate stories, not signals.

5. Risk, Not Compliance, Drives Action

AWS Security Hub now focuses on risk-based prioritization:

Unified visibility across services
Remediation guidance built-in
Prioritizes what matters most

🔗 Docs: Security Hub

Compliance alone is no longer sufficient; risk-based action is the new baseline.

6. AI Governance Is Security

With AI integrated into cloud operations, security now includes model behavior, access, and accountability:

Policy enforcement for AI agents
Auditable model decisions
Privacy-preserving controls

🔗 AWS AI security & governance

🔗 Unifying Data, AI, and governance at scale

In 2026, the attack surface includes your AI models.

What Should Organizations Do Now?

Embed security into CI/CD pipelines
Automate least-privilege IAM everywhere
Adopt cloud-native XDR practices
Train SOC teams to collaborate with AI
Treat AI governance as a first-class security problem

What Should Cloud Engineers Do?

As an AWS practitioner:

Eliminate long-lived credentials
Learn GuardDuty attack-chain analysis
Automate security checks in IaC
Understand AI’s role in cloud security
Stay current with AWS-native security tooling

The most secure systems in 2026 won’t rely on heroics. They’ll be secure by design.

Refence

AWS IAM Identity Center (Formerly AWS SSO): Complete Guide

Isaac Oppong-Amoah — Tue, 27 Jan 2026 08:33:24 +0000

AWS IAM Identity Center helps you centrally manage access to multiple AWS accounts and cloud applications using single sign-on (SSO). It simplifies identity management across AWS Organizations while improving security, visibility, and scalability.

This guide covers:

What IAM Identity Center is
How it works
Initial configuration
Permission sets and roles
Integration with Service Control Policies (SCPs)
Identity providers and best practices

🔍 What Is AWS IAM Identity Center?

IAM Identity Center is a centralized identity and access management service for AWS Organizations. It allows users to sign in once and securely access:

Multiple AWS accounts
AWS-managed applications
Third-party SaaS applications

⭐ Key Features

Centralized access across AWS Organizations
Built-in directory or external identity provider support
Account-level permission assignments
Support for SAML 2.0–based IdPs
Short-lived credentials for improved security

🧩 Architecture Overview

IAM Identity Center sits between your identity source and AWS accounts:

Users authenticate with an IdP
Permission sets define allowed actions
Temporary IAM roles are created automatically
Access is granted without long-lived credentials

🏢 Using Service Control Policies (SCPs) with IAM Identity Center

Service Control Policies define the maximum permissions an AWS account can have. SCPs do not grant permissions — they limit what IAM roles and permission sets can do.

🔐 Example: Restrict AWS Regions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

💡 Even admins using IAM Identity Center cannot bypass SCP restrictions.

⚙️ Initial Setup of IAM Identity Center

Step-by-Step

Open IAM Identity Center in the AWS Console
Enable it for your AWS Organization
Choose an identity source:

AWS-managed directory
External identity provider
1. Create or sync users and groups
2. Assign users or groups to AWS accounts using permission sets

🔗 Supported Identity Providers

IAM Identity Center supports many enterprise identity providers, including:

AWS IAM Identity Center directory
Microsoft Entra ID (Azure AD)
Okta
OneLogin
Google Workspace (SAML)
Any SAML 2.0–compliant IdP

This enables seamless integration with existing corporate identity systems.

🧾 Permission Sets Explained

Permission sets are reusable access templates that define what users can do in an AWS account. Internally, they create IAM roles automatically.

Example: Admin Permission Set (YAML)

Name: AdminAccess
ManagedPolicies:
  - arn:aws:iam::aws:policy/AdministratorAccess
SessionDuration: PT1H

📌 Permission sets can include:

AWS-managed policies
Customer-managed policies
Inline policies
Session duration controls

👥 Managing Access with Groups

Group-based access simplifies large-scale management.

Benefits

Assign permissions once to a group
Automatically applies to all group members
Reduces operational overhead

Limitations

No nested groups
Group sync depends on IdP capabilities

Common group examples:

DevOps-Team
Security-Analysts
Finance-Admins

🔄 Service Roles and Automation

AWS services such as Lambda, CloudFormation, and EC2 use service-linked roles to interact with AWS APIs securely.

IAM Identity Center works alongside these roles by:

Limiting who can deploy or modify services
Ensuring automation follows least-privilege rules

🕐 Temporary and Cross-Account Access

IAM Identity Center uses temporary credentials via role assumption, eliminating static access keys.

Cross-Account Trust Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AccountA>:role/SSOUserRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This enables secure access between accounts without credential sharing.

✅ Best Practices

Use SCPs to enforce guardrails
Assign permissions to groups, not users
Keep session durations short
Use least-privilege permission sets
Integrate with an external IdP for lifecycle management

🧠 Summary

AWS IAM Identity Center provides:

Centralized identity and access management
Secure, temporary credentials
Scalable permissions across AWS Organizations
Seamless SSO for AWS and third-party apps

When combined with SCPs and strong governance, it forms the backbone of a secure enterprise AWS environment.

📚 References

Securing Hundreds of AWS Accounts for Streamlined Governance 🚀🔒🌍

Isaac Oppong-Amoah — Mon, 14 Apr 2025 17:51:11 +0000

Managing and securing multiple AWS accounts can be a daunting task, especially as organizations scale their cloud footprint. Without a streamlined governance model, security risks can proliferate, leading to compliance gaps and operational inefficiencies. In this post, we’ll explore best practices for securing hundreds of AWS accounts while ensuring centralized governance and operational efficiency. 🏢🔐⚙️

The Challenge of Managing Multiple AWS Accounts 🤯🔎🚨

As organizations grow, so do their AWS environments. Companies often operate multiple AWS accounts for various reasons, such as application isolation, compliance requirements, and cost allocation. However, this expansion introduces security challenges, including:

Inconsistent security policies across accounts
Lack of centralized visibility into security events
Complicated IAM and access management
Difficulty in enforcing compliance

A well-structured approach to governance can help mitigate these challenges. 🏛️📏✅

1. Implement AWS Organizations for Centralized Governance 🏢📜🔐

AWS Organizations provides a hierarchical structure to manage multiple accounts under a single entity. This enables organizations to:

Apply Service Control Policies (SCPs) to enforce security baselines
Use Organizational Units (OUs) to categorize accounts by function (e.g., production, development, sandbox)
Enable consolidated billing for cost management

Best Practices:

Use OUs to group accounts logically and apply specific SCPs.
Restrict root user access across all accounts.
Implement mandatory MFA for all IAM users and roles. 🛡️✅🔑

AWS CLI: Setting Up AWS Organizations 🏗️🔧🖥️

aws organizations create-organization
aws organizations create-organizational-unit --parent-id r-235433899xxx --name Security
aws organizations attach-policy --target-id ou-4555xxxxxx --policy-id p-7889xxx

2. Enforce Security Policies with AWS Control Tower 🏗️🔎🛡️

AWS Control Tower simplifies multi-account governance by automating account provisioning and applying security guardrails. It integrates with AWS Organizations and provides:

Pre-configured guardrails for security and compliance
Baseline security configurations for new accounts
Centralized logging via AWS CloudTrail and AWS Config

Best Practices:

Leverage AWS Control Tower for setting up new AWS accounts with predefined security controls.
Enable AWS Config to monitor configuration drift across all accounts.
Use AWS Security Hub to get a unified view of security alerts. 🔄🔍📊

AWS CLI: Deploying AWS Control Tower 🏢🛠️🖥️

aws controltower enable-control --control-identifier AWS-GUARDRAIL-EXAMPLE --target-identifier ou-4555xxxxxx

3. Implement Centralized IAM and Access Management 🔐👥📂

Managing access across hundreds of accounts can become complex without a clear IAM strategy. Some key approaches include:

AWS IAM Identity Center (formerly AWS SSO): Enables centralized user access management across multiple accounts.
Least Privilege Principle: Restrict access to only necessary permissions.
Federated Authentication: Use an identity provider (IdP) such as Okta, Azure AD, or AWS IAM Identity Center.

Best Practices:

Enforce strong authentication policies (e.g., MFA, password policies).
Use IAM roles instead of IAM users to limit long-lived credentials.
Regularly audit IAM policies with AWS Access Analyzer. 🕵️‍♂️✅🔎

AWS CLI: Configuring IAM Identity Center 🏢🔑🛠️

aws sso-admin create-permission-set --instance-arn arn:aws:sso:::instance/ssoins-example1234 --name AdminAccess

4. Centralized Logging and Monitoring with AWS Security Services 📜📊🚀

Security teams need visibility into activities across all AWS accounts. AWS provides several tools to centralize security monitoring:

AWS CloudTrail: Logs all API activity for auditing and compliance.
Amazon GuardDuty: Detects threats and anomalies across AWS workloads.
AWS Security Hub: Aggregates security findings from multiple AWS services.

Best Practices:

Enable CloudTrail across all accounts and store logs centrally in S3.
Use GuardDuty for continuous monitoring of malicious activity.
Set up AWS Security Hub to correlate security findings. 🔍📈🛑

AWS CLI: Setting Up AWS Security Hub 🔐🛠️📊

aws securityhub enable-security-hub
aws securityhub create-insight --name "Unusual API Calls" --filters '{"Action":"Count","Operator":"GREATER_THAN","Value":10}'

5. Automate Compliance and Remediation 🤖⚙️✅

Maintaining compliance across a large AWS environment requires automation. AWS provides several tools to enforce security policies and automate remediation:

AWS Config Rules: Automatically check compliance against predefined rules.
AWS Lambda & EventBridge: Automate responses to security events.
AWS Systems Manager: Automate patch management and operational tasks.

Best Practices:

Define custom AWS Config rules to enforce security policies.
Use AWS Lambda to remediate misconfigurations automatically.
Implement patch automation for EC2 instances and containerized workloads. 🔄⚡🔍

AWS CLI: Automating Compliance with AWS Config 🛠️🔍🤖

aws configservice put-config-rule --config-rule-name "restricted-ssh" --source Identifier=AWS-EBS-ENCRYPTION-BY-DEFAULT

Next Steps 🚀🔎

Securing hundreds of AWS accounts requires a well-structured governance model that enforces consistency, enhances security visibility, and automates compliance. Here’s what you can do next:

✅ Review your AWS account structure and governance model.
✅ Implement security best practices using AWS Organizations, Control Tower, and IAM Identity Center.
✅ Set up centralized logging and security monitoring.
✅ Automate compliance and remediation with AWS Config and Lambda.
✅ Continuously monitor and improve security posture.

REFRENECE

https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html
https://www.youtube.com/watch?v=2J1xGKmnNQI
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html
https://docs.aws.amazon.com/images/whitepapers/latest/aws-security-incident-response-guide/images/incident-response-account-structure.png
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html

Multi-Factor Authentication (MFA) on AWS: A Critical Security Measure

Isaac Oppong-Amoah — Sat, 15 Mar 2025 22:53:39 +0000

Security threats are evolving, and traditional authentication methods are no longer enough to protect sensitive data. Multi-Factor Authentication (MFA) provides an additional layer of security, ensuring that users are who they claim to be. In AWS, implementing MFA is a critical step toward strengthening identity and access management.

Why MFA Matters

MFA is essential for preventing unauthorized access due to:

Account Takeover (ATO): Attackers use stolen credentials to access AWS accounts.
Phishing Attacks: Users unknowingly provide login details to malicious actors.
Brute-Force Attacks: Without MFA, simple or reused passwords can be easily cracked

A username and password alone are no longer sufficient to protect AWS accounts and applications. Organizations must adopt MFA as a fundamental security measure.

Implementing MFA on AWS

AWS provides different MFA methods, including:

Virtual MFA Devices: (e.g., Microsoft Authenticator, Google Authenticator, Authy)
Hardware MFA Devices: (e.g., YubiKey)
SMS-based MFA: One-time passcodes sent via text message (not recommended due to SIM-swapping risks)

How to Enable MFA on AWS?

AWS allows MFA implementation across various services, including:

1. AWS Management Console MFA

Navigate to the AWS IAM Console.
Select the IAM user and choose "Manage MFA."
Register a virtual MFA app or hardware device.
Complete the setup by scanning the QR code and entering the authentication codes.

2. AWS CLI MFA:

Configure MFA by adding an MFA serial number to the AWS CLI profile.
Use the command aws sts get-session-token --serial-number --token-code to generate temporary credentials.

Example:
aws sts get-session-token --serial-number arn:aws:iam::5587899900xx:mfa/worshop --token-code 806789

3. MFA for AWS Workloads and Applications:

Enforce MFA for API calls and AWS IAM roles.
Use AWS Cognito for MFA implementation in user authentication workflows.
Integrate AWS SSO with MFA for centralized identity management.

What Can Businesses Do?

Organizations should implement and enforce MFA policies to protect AWS environments. Some best practices include:

Enforce MFA for all IAM users and privileged accounts.
Use IAM roles with MFA instead of long-lived access keys.
Enable MFA for AWS SSO and third-party integrations.
Monitor MFA usage with AWS CloudTrail and AWS Config.

What Can Users Do?

As an AWS root/IAM user, you can:

Enable MFA on all AWS accounts and services you interact with.
Use a secure authenticator app instead of SMS for added protection.
Regularly review IAM policies and access logs for suspicious activities.
Educate team members on the importance of MFA and security best practices

Final Thoughts

MFA is a necessity, not an option. Organizations must prioritize implementing MFA across AWS services to enhance security. The time to act is now—secure your AWS environment with MFA today.

References

AWS Documentation: Multi-Factor Authentication
NIST Guidelines: Digital Identity Guidelines
Two-Factor Authentication: https://twofactorauth.org
DevSecOps: Multi-Factor Auth: A Call to Action

EC2 Web Application Firewall (WAF) Protection via AWS CLI

Isaac Oppong-Amoah — Thu, 27 Feb 2025 09:25:34 +0000

TASKS

Create an IAM User (workshop-sec)
Grant Access to Manage AWS WAF and ALB
Use workshop-sec Credentials for Deployment
Deploy the Web App with WAF Protection

1. Create an IAM User

Creating an IAM user workshop-sec with permissions to manage EC2, ALB, and WAF.

Create the IAM User

aws iam create-user --user-name workshop-sec

Attach IAM Policy for WAF and ALB Management

Creating a custom policy allowing ALB and WAF actions:

aws iam create-policy \
  --policy-name WAF-ALB-Management \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:*",
          "elasticloadbalancing:*",
          "wafv2:*",
          "iam:GetUser"
        ],
        "Resource": "*"
      }
    ]
  }'

Attaching the policy to workshop-sec IAM user:

aws iam attach-user-policy \
  --user-name workshop-sec \
  --policy-arn arn:aws:iam:::469031999xxx:policy/WAF-ALB-Management

2. Generating Access Credentials for `workshop-sec`:

aws iam create-access-key --user-name workshop-sec

Store the Access Key ID and Secret Access Key securely.

3. Use `workshop-sec` Credentials

Updating the AWS CLI profile:

aws configure --profile workshop-sec

Provide:

Access Key ID
Secret Access Key
Region (e.g., us-east-1)
Output format (e.g., json)

Verify:

aws sts get-caller-identity --profile workshop-sec

4. Deploying the Web App on Ec2 (Amazon-linux) with WAF Protection :

Launching the EC2 Instance with Apache

aws ec2 run-instances \
  --image-id ami-05b10e08d247fb927 \
  --count 1 \
  --instance-type t2.micro \
  --key-name Seckey-2025 \
  --security-groups WebServerSG \
  --user-data "#!/bin/bash
  yum update -y
  yum install -y httpd
  systemctl start httpd
  systemctl enable httpd
  echo 'Hello, AWS WAF!' > /var/www/html/index.html" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer}]' \
  --profile workshop-sec

Creating ALB and Attach EC2

aws elbv2 create-load-balancer \
  --name WebAppALB \
  --type application \
  --subnets 0f4679cf88554ab67 03b90dbf86a29d7db \
  --security-groups sg-0019ab95b18d2cf94 \
  --profile workshop-sec

Creating AWS WAF WebACL

aws wafv2 create-web-acl \
  --name WebAppFirewall \
  --scope REGIONAL \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=WebAppMetrics \
  --rules '[{"Name": "AWSManagedRulesCommonRuleSet","Priority": 0,"Statement": {"ManagedRuleGroupStatement": {"VendorName": "AWS","Name": "AWSManagedRulesCommonRuleSet"}},"Action": {"Allow": {}},"VisibilityConfig": {"SampledRequestsEnabled": true,"CloudWatchMetricsEnabled": true,"MetricName": "WebAppMetrics"}}]' \
  --region us-east-1 \
  --profile workshop-sec

Associate WAF with ALB

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:469031999xxx:regional/webacl/WebAppFirewall/34345678-abcd-534-1d8d-5134567890ab  \
  --resource-arn arn:aws:elasticloadbalancing:us-east-1:469031999xxx:loadbalancer/app/WebAppALB/6dc6c495c0c9188 \
  --region us-east-1 \
  --profile workshop-sec

Verification

Check API Identity

   aws sts get-caller-identity --profile workshop-sec

Check WAF Logs
- Go to AWS WAF Console → WebACL → View Request Logs.

CONCLUSION

Created IAM user workshop-sec can manage EC2, ALB, and WAF.
Deployed AWS-managed WAF rules in place to secure the web application.
Associated WAF WebACL with the ALB to enforce protection.
Operations use the workshop-sec profile

Building Robust Security, Identity, & Compliance Frameworks in AWS

Isaac Oppong-Amoah — Mon, 13 Jan 2025 12:38:16 +0000

Effective security, identity, and compliance strategies are essential for safeguarding cloud environments. This post offers valuable insights into best practices, along with a practical lab and accompanying lab code for AWS security automation.

Key Concepts: Security, Identity, and Compliance

Security:

Implementing robust protection mechanisms ensures data and workloads are safe from malicious actors. Examples include network segmentation, encryption, and regular vulnerability scans.

Identity:

IAM (Identity and Access Management) ensures that the right individuals and services have appropriate access to resources. Tools like MFA, federated identities, and least privilege access are critical.

Compliance:

Compliance frameworks, such as ISO 27001 or PCI DSS, mandate specific security practices. Automated tools and audits can streamline adherence.

Lab 1: Enforcing MFA for AWS IAM Users

Lab Objective:

Set up a policy requiring all IAM users to enable Multi-Factor Authentication (MFA).

Prerequisites:

An AWS account
Basic IAM knowledge

Steps:

1. Create a Policy to Enforce MFA:

Use the following JSON policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

Go to the IAM Console.
Select Policies > Create Policy.
Paste the JSON and save the policy.

2. Attach the Policy to IAM Users:

Navigate to the Users section in the IAM Console.
Select the users to enforce MFA.
Attach the newly created policy.

3. Test the Policy:

Log in as a user without MFA enabled.
Attempt to access an AWS service.
Verify that access is denied.
Enable MFA and retry the service access.

Lab Code: Automating MFA Enforcement with AWS CLI

# Step 1: Create the MFA Enforcement Policy
aws iam create-policy \  
    --policy-name MFAEnforcementPolicy \  
    --policy-document file://mfa-enforcement-policy.json

# Step 2: Attach the Policy to a User
aws iam attach-user-policy \  
    --user-name ExampleUser \  
    --policy-arn arn:aws:iam::aws:policy/MFAEnforcementPolicy

# Step 3: List Users Without MFA Enabled
aws iam list-users | jq '.Users[] | select(.PasswordLastUsed != null) | .UserName'

# Step 4: Enable MFA for a User
aws iam enable-mfa-device \  
    --user-name ExampleUser \  
    --serial-number arn:aws:iam::5535678310xx:mfa/ExampleDevice \  
    --authentication-code1 34689 \  
    --authentication-code2 71098

Lab 2: Automating Security Group Rules with AWS Lambda

Lab Objective:

Create an AWS Lambda function that automatically adjusts security group rules based on incoming CloudWatch Events.

Prerequisites:

An AWS account
Familiarity with Lambda and CloudWatch

Steps:

1. Create a CloudWatch Event Rule:

Navigate to the CloudWatch Console.
Create a rule to capture specific API calls (e.g., AuthorizeSecurityGroupIngress).
Set the target to invoke a Lambda function.

2. Create a Lambda Function:

Deploy the following Python function to manage security group rules dynamically:

Lab Code via AWS Lambd

import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    security_group_id = event['detail']['requestParameters']['groupId']

    # Example: Revoke all inbound rules
    response = ec2.describe_security_groups(GroupIds=[security_group_id])
    for rule in response['SecurityGroups'][0]['IpPermissions']:
        ec2.revoke_security_group_ingress(
            GroupId=security_group_id,
            IpPermissions=[rule]
        )

    print(f"Cleared inbound rules for {security_group_id}")

Navigate to the Lambda Console.
Create a new function and paste the code.
Attach the necessary IAM role with ec2:DescribeSecurityGroups and ec2:RevokeSecurityGroupIngress permissions.

3. Test the Function:

Trigger the CloudWatch Event.
Verify that the Lambda function executed successfully and security group rules were updated.

Lab 3: Centralized Logging with Amazon CloudWatch and S3

Lab Objective:

Set up centralized logging by sending AWS CloudWatch logs to an S3 bucket for long-term storage and compliance.

Prerequisites:

An AWS account
Basic knowledge of CloudWatch and S3

Steps:

1. Create an S3 Bucket:

Navigate to the S3 Console.
Create a new bucket (e.g., lab-centralized-logs-bucket).
Configure appropriate permissions to allow CloudWatch to write to the bucket.

2. Set Up CloudWatch Log Group:

Navigate to the CloudWatch Console.
Create or select an existing log group.
Set up a subscription filter to send logs to the S3 bucket.

3. Verify Log Storage:

Generate logs in the CloudWatch log group.
Check the S3 bucket to confirm logs are being stored.

Lab Code: Automating Centralized Logging Setup with AWS CLI

# Step 1: Create an S3 Bucket
aws s3api create-bucket --bucket lab-centralized-logs-bucket --region us-east-1

# Step 2: Put a Bucket Policy
aws s3api put-bucket-policy --bucket lab-centralized-logs-bucket --policy file://bucket-policy.json

# Step 3: Set Up CloudWatch Log Group
aws logs create-log-group --log-group-name MyLogGroup

# Step 4: Create a Destination for Logs
aws logs put-destination \  
    --destination-name S3Logs \  
    --target-arn arn:aws:s3:::lab-centralized-logs-bucket

Lab 4: Using AWS Config for Compliance Auditing

Lab Objective:

Implement AWS Config to monitor compliance and generate reports for resources violating best practices.

Prerequisites:

An AWS account
Basic knowledge of AWS Config

Steps:

1. Enable AWS Config:

Navigate to the Config Console.
Create a configuration recorder and delivery channel.
Choose rules based on compliance requirements (e.g., restricted-common-ports).

2. View Compliance Reports:

Navigate to the compliance dashboard in the Config Console.
Analyze non-compliant resources and take action as needed.

3. Automate Remediation (Optional):

Set up an AWS Lambda function for automatic remediation.
Use Config rules to trigger the Lambda function when violations are detected.

Lab Code: Enabling AWS Config with CLI

# Step 1: Create a Configuration Recorder
aws configservice put-configuration-recorder \  
    --configuration-recorder-name default \  
    --role-arn arn:aws:iam::5535678310xx:role/AWSConfigRole

# Step 2: Start Recording
aws configservice start-configuration-recorder \  
    --configuration-recorder-name default

# Step 3: Add a Config Rule
aws configservice put-config-rule \  
    --config-rule-name restricted-common-ports \  
    --source "Owner=AWS,SourceIdentifier=RESTRICTED_COMMON_PORTS"

Lab 5: Implementing Data Loss Prevention with Amazon Macie

Lab Objective:

Leverage Amazon Macie to identify and protect sensitive data stored in S3 buckets.

Prerequisites:

An AWS account
Familiarity with S3 and IAM

Steps:

1. Enable Amazon Macie:

Navigate to the Macie Console.
Enable Macie for your account.
Assign the appropriate IAM roles to allow Macie access to S3 buckets.

2. Run a Data Discovery Job:

Create a job in the Macie Console.
Select the target S3 buckets.
Configure the job to identify sensitive data, such as PII or financial information.

3. Review Findings:

Navigate to the findings section in the Macie Console.
Review and address flagged sensitive data.

Lab Code: Setting Up Macie Data Discovery Jobs with CLI

# Step 1: Enable Macie
aws macie2 enable-macie

# Step 2: Create a Classification Job
aws macie2 create-classification-job \  
    --job-type ONE_TIME \  
    --name SensitiveDataDiscovery \  
    --s3-job-definition '{"bucketDefinitions":[{"accountId":"5535678310xx","buckets":["my-sensitive-data-bucket"]}]}'

# Step 3: List Findings
aws macie2 list-findings

# Step 4: Get Finding Details
aws macie2 get-finding \  
    --finding-id 3457900x-34rt-433d-566h-45678770vbxx

Conclusion

AWS provides a comprehensive suite of tools and services designed to automate and streamline security, identity management, and compliance processes. By automating critical security and compliance workflows, businesses can reduce human error, improve operational efficiency, and achieve consistent policy enforcement across their AWS environments.

Refrence
https://docs.aws.amazon.com/security/
https://docs.aws.amazon.com/iam/

AWS GuardDuty for ATP (Advanced Threat Detection)

Isaac Oppong-Amoah — Fri, 22 Mar 2024 17:12:07 +0000

In today's cybersecurity landscape, proactive threat detection is paramount. AWS GuardDuty, a managed threat detection service, offers an effective solution for identifying and prioritizing potential security threats in your AWS environment. Let's explore how to leverage GuardDuty with practical examples and CloudFormation code.

1. Enable GuardDuty: Start by enabling GuardDuty in your AWS account. You can do this through the AWS Management Console or by using CloudFormation. Here's a CloudFormation snippet to enable GuardDuty:

Resources:
  MyGuardDutyDetector:
    Type: AWS::GuardDuty::Detector
    Properties: {}

2. Configure GuardDuty: Customize GuardDuty settings to suit your security requirements. This includes specifying which AWS regions to monitor, setting up threat intelligence feeds, and defining alert thresholds.

Resources:
  MyGuardDutySettings:
    Type: AWS::GuardDuty::Detector
    Properties:
      FindingPublishingFrequency: FIFTEEN_MINUTES
      EnableThreatIntelSets: true
      ...

3. Analyze Findings: GuardDuty continuously analyzes logs from various AWS data sources, such as CloudTrail, VPC Flow Logs, and DNS logs. It then generates findings based on identified threats, anomalies, or suspicious activities.

Resources:
  MyGuardDutyCloudTrail:
    Type: AWS::GuardDuty::Filter
    Properties:
      DetectorId: !Ref MyGuardDutyDetector
      Action: ARCHIVE
      FindingCriteria:
        Criterion:
          - Field: type
            Eq: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

4. Respond to Threats: Once GuardDuty identifies a potential threat, it generates findings that you can investigate further. You can integrate GuardDuty with AWS Lambda to automate response actions, such as isolating compromised instances or updating security group rules.

Resources:
  MyGuardDutyLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      ...
  MyGuardDutyInvocator:
    Type: AWS::Lambda::Permission
    Properties:
      ...

5. Monitor and Fine-Tune: Regularly review GuardDuty findings and adjust settings as needed. Monitor GuardDuty metrics and alarms in Amazon CloudWatch to ensure effective threat detection and response.

6. Benefits: By incorporating AWS GuardDuty into your AWS security strategy, you can strengthen your defenses against evolving cyber threats. With its comprehensive threat detection capabilities and seamless integration with AWS services, GuardDuty empowers you to safeguard your cloud infrastructure with confidence.

AWS RE: INFORCE 2024 ABW GRANT

Isaac Oppong-Amoah — Thu, 21 Mar 2024 12:18:42 +0000

🚀 Exciting news...I am so thrilled to finally share that we are expanding the ABW Grant program to AWS re:Inforce 2024!

🔒 AWS re:Inforce is our annual cloud security learning conference focused exclusively on AWS security solutions, cloud security, compliance, and identity.

This year, the conference will take place in 🔔 Philadelphia, PA from June 10 - 12, 2024
✍️ Applications for the re:Inforce ABW Grant are open now and will close on Monday, April 1, 2024 at 5:00 PM EST
Apply here
🎯 Eligibility requirements include:

First five years in cloud security
21 years or older
Not an employee, intern, contractor, etc. of Amazon, AWS, or affiliates

Identify as being part of a group that is underrepresented in tech or have faced barriers or disadvantages in your technology career due to discrimination actions against underrepresented groups
Most notable for this group 📣 All re:Invent Grant Alumni ARE eligible to apply if you meet the other requirements above. We are allowing folks to receive the grant more than once if its for a different event, so apply asap if you are in the cloud securi ty field!

:speaking_head_in_silhouette: Please share with your networks and help us get the word out!
AWS Social Posts to share:

Please also share out with any relevant professional networks, internal affinity groups at your company, or anywhere else that will reach folks breaking into the cloud security field!

AWS RE: INVENT 2023 ABW GRANT

Isaac Oppong-Amoah — Fri, 25 Aug 2023 22:04:48 +0000

What's up, everyone!!!!
Do you enjoy attending technology conferences?
Are you a budding IT professional?
Are you a technologist with fewer than 5 years of experience?!?!
Then look no further since the AWS All Builders Welcome Grant is now LIVE!
What exactly is the ABW Grant?
Individuals can attend the AWS Re: Invent conference for free thanks to this award.

Program Benefits. Participants of the Program will receive the following benefits:

-A full conference pass to re: Invent 2023

Roundtrip flight Las Vegas, NV
5 nights Hotel accommodations in Las Vegas, NV -And other exciting prices at the event

You must be 21+ or older to apply for this grant.
This grant is open to EVERYONE on the earth who meets the aforementioned conditions.
You CAN apply regardless of where you live. All builders are welcome.

Apply for ABW grant now

Remember applications for the ABW Grant are now open and will close on September 1, 2023, at 11:59 PM (PDT).

If you have any queries about the application, please leave them in the comments section below.