DEV Community: Olawale Adepoju

Accelerating AI Innovation with the AWS Cloud Adoption Framework

Olawale Adepoju — Fri, 16 Jan 2026 20:37:49 +0000

Introduction

Cloud adoption is critical for organizations looking to leverage Artificial Intelligence (AI), Machine Learning (ML), and Generative AI (GenAI). But scaling AI in the cloud isn’t just about spinning up servers — it requires strategy, governance, and alignment across people, processes, and technology.

The AWS Cloud Adoption Framework (CAF) provides a structured approach to navigate this journey, ensuring organizations can adopt AI and ML in a secure, scalable, and business-aligned way.

Introduction to Artificial Intelligence

Artificial Intelligence (AI) is the field focused on creating machines that can perform tasks traditionally requiring human intelligence, such as understanding language, perceiving images, making decisions, and solving problems. Many AI systems work by generating probabilistic outcomes—predictions or decisions with a high degree of certainty—helping automate or enhance knowledge-based work.

A large part of modern AI relies on Machine Learning (ML), which allows computers to learn from data rather than being explicitly programmed. ML models generalize from examples, making them versatile across a wide range of applications. A specialized branch, Deep Learning, uses multi-layered neural networks to analyze complex data, especially unstructured information like images and text, enabling breakthroughs in areas such as image recognition, speech processing, and natural language understanding.

Building on this, Generative AI represents a frontier in AI research, enabling machines to create new content—text, images, or even music—mimicking human-like reasoning and creativity. Advances in computing, data, and algorithms have made generative AI practical, unlocking applications across entertainment, art, research, and beyond.

Navigating Your AI Adoption Journey

Adopting a transformative technology like AI is a long, evolving journey. While every organization’s path is unique, patterns from thousands of successful AI adopters have emerged. To help de-risk this journey, the AWS Cloud Adoption Framework for AI (CAF-AI) offers guidance and best practices.

When approaching your AI transformation, consider four critical elements:

Outcome: Define the business outcomes you want to achieve and work backward from them.
AI Flywheel: High-quality data fuels AI models, which generate predictions that improve business outcomes, creating more valuable data in a self-reinforcing cycle.
Data Strategy: Strong data management keeps the AI flywheel spinning.
Foundational Capabilities: These core capabilities determine success or failure in AI adoption.

The transformation is best approached iteratively, in four stages:

Envision: Identify AI opportunities aligned with business objectives, map required data, and engage key stakeholders.
Align: Establish cross-functional alignment, address dependencies, and ensure organizational readiness for AI adoption.
Launch: Deliver pilot projects or proofs of concept to demonstrate value, learn from outcomes, and refine strategies.
Scale: Expand successful pilots across the organization, maximizing both technical and business impact.

Throughout the journey, avoid trying to do everything at once. Pair long-term ambition with pragmatic, measurable steps to evolve capabilities, improve readiness, and deliver sustained business value. Incremental progress brings organizations closer to achieving their AI transformation goals.

What is the AWS Cloud Adoption Framework?

The AWS Cloud Adoption Framework for AI, ML, and Generative AI (CAF-AI) provides a structured guide for organizations embarking on or advancing their AI journey. It helps teams plan mid- to long-term strategies, align stakeholders, and move beyond isolated proofs of concept toward enterprise-wide adoption.

CAF-AI can be used in different ways: you may focus on specific sections to develop targeted skills or leverage the full framework to assess organizational maturity and prioritize near-term improvements. Built on the same foundational capabilities as the AWS Cloud Adoption Framework (AWS CAF), CAF-AI extends and adapts them to meet the unique demands of AI adoption while introducing new capabilities critical for AI success.

The AWS CAF organizes cloud adoption into six perspectives:

Business – aligns cloud adoption with organizational strategy and value creation.
People – addresses skills, training, and change management.
Governance – ensures policies, risk management, and compliance.
Platform – focuses on the architecture, infrastructure, and cloud foundation.
Security – manages risk, compliance, and secure AI/ML deployments.
Operations – ensures operational excellence, monitoring, and continuous improvement.

When applied to AI/ML, each perspective helps organizations avoid common pitfalls like skill gaps, uncontrolled experimentation, and poor model governance.

Applying CAF to AI, ML, and Generative AI

Business Perspective:

Define business outcomes for AI projects (e.g., predictive analytics, intelligent automation, personalized recommendations).
Prioritize AI initiatives based on ROI and feasibility.
Establish KPIs for AI adoption, such as model accuracy, time-to-deploy, and business impact

People Perspective:

Build AI/ML capabilities through training in Python, TensorFlow, PyTorch, and AWS AI services.
Empower teams with generative AI tools (e.g., Amazon Bedrock, SageMaker JumpStart).
Create a culture of experimentation and innovation while maintaining responsible AI practices.

Governance Perspective:

Implement AI governance frameworks: model versioning, data lineage, and bias mitigation.
Ensure ethical AI practices and compliance with regulations (e.g., GDPR, HIPAA).

Platform Perspective:

Build scalable AI/ML infrastructure using AWS services like SageMaker, Data Pipeline, and managed data lakes (S3 + Lake Formation).
Standardize environments for reproducibility and collaboration.

Security Perspective:

Protect sensitive data with encryption, IAM policies, and private endpoints.
Secure ML pipelines and generative AI endpoints against misuse.
Monitor model access, drift, and vulnerabilities.

Operations Perspective:

Monitor model performance, accuracy, and drift in production.
Automate retraining and CI/CD pipelines for ML models.
Apply MLOps best practices to reduce operational risk and downtime.

Architecting for AI Excellence: Exploring AWS’s Three New Well-Architected Lenses Announced at re:Invent 2025

Olawale Adepoju — Fri, 16 Jan 2026 15:13:13 +0000

Artificial intelligence is no longer an experimental workload in AWS—it is rapidly becoming a core part of production architectures. From generative AI applications to large-scale machine learning pipelines, architects are now expected to design AI systems that are not only powerful, but also secure, reliable, cost-efficient, and responsible.

At AWS re:Invent 2025, AWS expanded its AI guidance within the Well-Architected Framework by introducing one new lens and two major updates designed specifically for AI workloads: the Responsible AI Lens, the Machine Learning (ML) Lens, and the Generative AI Lens. Together, these lenses offer practical, end-to-end architectural guidance for organizations at every stage of their AI journey—whether teams are just beginning to explore machine learning or operating complex, production-grade AI systems at scale.

The AWS Well-Architected Framework itself defines proven architectural best practices for building and operating workloads in the cloud that are secure, reliable, performance-efficient, cost-optimized, and sustainable. By extending the framework with AI-focused lenses, AWS enables architects to apply these core principles to the unique challenges and considerations of modern AI and machine learning workloads.

The Responsible AI Lens: Designing AI Systems with Trust, Fairness, and Transparency

The Responsible AI Lens provides a structured framework that helps teams evaluate, track, and continuously improve their AI workloads against established best practices. It enables architects and developers to identify potential gaps in their AI implementations and offers actionable guidance to improve system quality while aligning with responsible AI principles. By applying the Responsible AI Lens, organizations can make informed architectural decisions that balance business objectives with technical requirements—accelerating the transition from AI experimentation to production-ready, trusted solutions.

Key Takeaways from the Responsible AI Lens:

Every AI system carries responsible AI considerations:
Whether intentionally designed or not, all AI systems introduce responsible AI implications. These considerations must be actively addressed throughout the system lifecycle rather than left to chance.

AI systems may be used beyond their original intent:
Applications are often adopted in ways developers did not initially anticipate. Combined with the probabilistic nature of AI, this can lead to unexpected outcomes—even within intended use cases—making early and deliberate responsible AI decisions essential.

Responsible AI enables innovation and builds trust:
Rather than limiting progress, responsible AI practices act as a catalyst for innovation by establishing stakeholder confidence, strengthening customer trust, and reducing long-term operational and reputational risks.

The Responsible AI Lens serves as the foundational guidance for AI development on AWS, providing core principles that inform and support both the Machine Learning Lens and the Generative AI Lens implementations.

The Machine Learning Lens: Building Strong ML Foundations on AWS:

The Machine Learning Lens acts as a practical foundation for teams designing and running ML workloads on AWS. It brings together proven, cloud-agnostic best practices mapped to the Well-Architected Framework pillars, covering every stage of the ML lifecycle. Whether you’re experimenting with your first model or operating complex AI systems in production, the updated ML Lens provides a consistent way to think about architecture, operations, and scale.

Since its initial release in 2023, AWS’s ML ecosystem has evolved significantly—and the updated ML Lens reflects that progress. It incorporates modern tooling and services that help teams move faster, collaborate better, and operate ML workloads more efficiently and responsibly.

What’s new in the updated Machine Learning Lens:

Streamlined collaboration between data and AI teams using Amazon SageMaker Unified Studio
AI-assisted development to boost developer productivity with Amazon Q
Scalable, distributed training for foundation models and fine-tuning using Amazon SageMaker HyperPod
Flexible model customization, including fine-tuning and knowledge distillation, using Amazon Bedrock, Kiro, and Amazon Q Developer
No-code ML workflows with Amazon SageMaker Canvas, now enhanced with Amazon Q
Stronger bias detection and responsible AI practices with improved fairness metrics in Amazon SageMaker Clarify
Faster access to business insights through automated dashboards in Amazon QuickSight
Modular inference architectures that simplify deployment and scaling using Inference Components
Deeper observability with improved debugging and monitoring across the ML lifecycle
Better cost control through SageMaker Training Plans, Savings Plans, and Spot Instances

One of the strengths of the ML Lens is its flexibility. You can apply it early during architecture design or use it later to review and improve existing production workloads. Regardless of where you are in your cloud or ML journey, the ML Lens—powered by services like Amazon SageMaker Unified Studio, Amazon Q, Amazon SageMaker HyperPod, and Amazon Bedrock—helps teams build ML systems that are scalable, efficient, and ready for production.

The Generative AI Lens: Practical Architecture Guidance for Foundation Models:

The Generative AI Lens helps architects and builders take a structured, repeatable approach to designing systems that use large language models (LLMs) and other foundation models to deliver real business value. It focuses on the architectural decisions teams face most often when building generative AI applications—such as choosing the right model, designing effective prompts, customizing models, integrating workloads, and continuously improving system performance.

Unlike the broader Machine Learning Lens, which applies across the entire ML spectrum, the Generative AI Lens zooms in on the unique requirements of foundation models and generative AI workloads. It distills best practices drawn from AWS’s experience working with thousands of customers and aligns them with the Well-Architected Framework, helping teams move from experimentation to production with confidence.

What’s new in the updated Generative AI Lens:

Expanded guidance on orchestrating complex, long-running generative AI workflows using Amazon SageMaker HyperPod
A stronger Responsible AI foundation, including a detailed breakdown of AWS’s eight core Responsible AI dimensions
A new agentic AI preamble introducing architectural patterns for building AI agents and multi-step reasoning systems

By building on the foundation provided by the ML Lens, the Generative AI Lens offers focused, practical guidance for teams tackling the distinct challenges—and opportunities—of generative AI and foundation model–based applications on AWS.

Implementing Well-Architected AI/ML Guidance

The three new AI-focused lenses—Responsible AI, Machine Learning, and Generative AI—are designed to work together as a single, cohesive guidance model rather than standalone frameworks. Each lens plays a specific role, but together they help teams build AI systems that are production-ready, trustworthy, and scalable.

The Responsible AI Lens sets the baseline by focusing on safe, fair, and secure AI development. It helps teams balance business goals with technical and ethical requirements, making it easier to move from proof-of-concept experiments into production. The Machine Learning Lens then provides broader guidance across both traditional ML and modern AI workloads, with recent updates that improve collaboration between data and AI teams, introduce AI-assisted development, support large-scale infrastructure provisioning, and enable more flexible model deployment. On top of this foundation, the Generative AI Lens focuses specifically on LLM-based architectures, with new guidance for Amazon SageMaker HyperPod, emerging agentic AI patterns, and updated architectural scenarios for common generative AI applications.

What’s Next?

With the launch of these lenses at re:Invent 2025, AWS gives organizations a clear path to building AI systems that are not just powerful, but also responsible and trustworthy. By covering the full range of AI workloads—from traditional ML to generative AI—these lenses help teams accelerate innovation while maintaining strong architectural and responsible AI standards.

Detecting and Filtering Harmful Content with Amazon Bedrock Guardrails

Olawale Adepoju — Thu, 08 Jan 2026 14:12:04 +0000

Technical Overview

Amazon Bedrock Guardrails provide a centralized control layer that sits between your application and the foundation models (FMs) used to generate responses. Guardrails allow you to define enforceable safety, privacy, and compliance rules that are applied consistently—regardless of which model is used underneath.

From an architecture perspective, guardrails are evaluated on both inbound prompts and outbound responses, ensuring that unsafe content is blocked or transformed before it reaches the model or the end user.

High-Level Architecture Flow

User Request Enters the Application
A user interacts with the application (for example, a chatbot, banking portal, or call center system). The request is passed to the application backend through an API or UI layer.
Prompt Evaluation via Bedrock Guardrails
Before the request is sent to a foundation model, the application invokes Amazon Bedrock with an associated guardrail configuration.
At this stage, guardrails inspect the user prompt for:

Harmful or toxic language
Disallowed topics (such as financial or legal advice)
Sensitive data patterns (PII, depending on configuration)

If the prompt violates defined policies, Bedrock can:

Block the request
Return a predefined safe response
Log the event for auditing and monitoring

Model Invocation (If Prompt Is Allowed)
Only prompts that pass guardrail evaluation are forwarded to the selected foundation model (for example, Claude, Titan, or other Bedrock-supported models).
This decouples safety logic from the model itself and ensures consistent behavior even when models are swapped or upgraded.
Response Evaluation via Guardrails
After the foundation model generates a response, guardrails are applied again—this time on the model output.
Guardrails can:

Detect and block toxic or unsafe responses
Prevent disallowed advice or policy violations
Redact or mask personally identifiable information (PII)

Final Response Returned to the User Only responses that comply with guardrail rules are returned to the application and displayed to the user. If the response violates policies, a controlled fallback message is returned instead.

Example Architecture Use Cases

Chatbot Architecture
Guardrails validate user input before inference and scan model output after inference to ensure no abusive or harmful content is surfaced to users.
Financial Services Architecture
Guardrails act as a policy enforcement layer that blocks prompts or responses related to investment advice, reducing regulatory risk while still allowing general financial information.
Contact Center Summarization Pipeline
Conversation transcripts are sent through Bedrock with guardrails configured to detect and redact PII before summaries are stored in downstream systems such as S3, OpenSearch, or CRM platforms.

Why This Architecture Matters

By separating safety controls from application logic and model selection, Amazon Bedrock Guardrails enable:

Centralized governance across multiple AI workloads
Model-agnostic safety enforcement
Easier auditing, compliance, and policy updates without code changes

This approach allows teams to scale generative AI applications while maintaining predictable, controlled, and compliant behavior across environments.

Amazon Bedrock Guardrails Policies and Enforcement Capabilities

Amazon Bedrock Guardrails provide a set of configurable safeguards (referred to as policies) that are evaluated during prompt processing and model inference. These policies allow teams to detect, block, redact, or validate content before it reaches a foundation model and again before a response is returned to the user.

Each policy type can be enabled independently and tuned to match application-specific risk tolerance.

Content Filters

Content filters are used to detect and block harmful text or image content in user prompts and model responses.

Guardrails classify content into predefined categories:

Hate
Insults
Sexual
Violence
Misconduct
Prompt Attacks (jailbreak attempts)

For each category, you can configure the filter strength (for example, permissive vs. strict), allowing fine-grained control based on the sensitivity of your application.

Both Classic and Standard tiers support these categories.
With the Standard tier, content detection is extended into code-level elements, including:

Comments
Variable and function names
String literals

This is especially important for developer tools, code assistants, and AI-generated scripts.

Denied Topics

Denied topics allow you to explicitly define subjects that are out of scope or not allowed for your application.

If a denied topic is detected in either:

The user query, or
The model’s response

the request can be blocked or replaced with a safe fallback message.

In the Standard tier, denied topic detection also applies inside code elements such as comments, variables, function names, and strings—preventing policy violations from being hidden in generated code.

This is commonly used in regulated environments (for example, blocking medical or investment advice).

Word Filters

Word filters allow exact-match blocking of specific:

Words
Phrases
Profanity

This is useful for enforcing business-specific restrictions, such as:

Offensive language
Competitor names
Brand misuse

Word filters are deterministic and operate as a straightforward enforcement layer within the guardrail evaluation process.

Sensitive Information Filters

Sensitive information filters help detect and block or mask personally identifiable information (PII) in both prompts and responses.

Detection is probabilistic and supports standard formats for entities such as:

Social Security Numbers
Dates of birth
Addresses

In addition to built-in PII detection, you can configure custom regular expressions to identify organization-specific identifiers, such as customer IDs or internal reference numbers.

This policy is critical for applications that store outputs in downstream systems like S3, OpenSearch, CRMs, or analytics platforms.

Policy Violation Handling

In addition to defining policies, you can configure custom user-facing messages that are returned when:

A user input violates a policy, or
A model response fails guardrail evaluation

This allows applications to fail safely and consistently, rather than returning generic errors or silent failures.

Integration Options in the Architecture

Guardrails can be used in two primary ways:

1.　During Model Inference
Guardrails are applied by specifying the guardrail ID and version during the Bedrock inference API call.
In this mode, guardrails evaluate both:

Input prompts
Model completions

Standalone Guardrail Evaluation Using the ApplyGuardrail API, guardrails can be applied without invoking a foundation model. This is useful for:

Pre-validating user input
Post-processing outputs from external systems
Enforcing policies in RAG pipelines before inference

For RAG and Conversational Applications

In RAG or multi-turn conversational architectures, you may want to evaluate only the user’s current input, while excluding:

System instructions
Retrieved search results
Conversation history
Few-shot examples

This approach ensures that guardrails focus on user intent, rather than falsely flagging internal context or system-generated content.

From Governance to Value: Running an Effective Architecture Review Board

Olawale Adepoju — Mon, 05 Jan 2026 17:27:25 +0000

As I navigate the enterprise architecture world in my role as an Application Architect, one thing has become increasingly clear: the pace of change in modern computing landscapes is relentless. Cloud adoption, artificial intelligence, and continuous technology innovation are transforming how organizations build and operate systems. While these advancements create enormous opportunities, they also introduce complexity and risk—especially in large enterprises where consistency, security, and compliance cannot be compromised.

Organizations are now challenged to move faster without losing control, ensuring that new initiatives and projects align with established enterprise standards, architectural principles, and regulatory requirements. This is where an effective Architecture Review Board (ARB) plays a critical role. When designed and operated well, an ARB helps organizations maintain strong enterprise guardrails while still accelerating the delivery of initiatives across an increasingly busy project pipeline.

In this post, I explore what an Architecture Review Board really is, the key components of an efficient and practical architecture review process, and how to build and operate an effective enterprise ARB. Drawing from my own experience navigating enterprise architecture, I aim to show how an ARB can evolve from a perceived governance bottleneck into a strategic enabler of sound architectural decisions and sustainable innovation.

What Is an Architecture Review Board?

An Architecture Review Board (ARB) is a cross-functional group responsible for reviewing solution architectures to ensure alignment with enterprise standards, best practices, and long-term supportability. It typically includes representatives from Security, Development, Enterprise Architecture, Infrastructure, and Operations. Bringing these perspectives together early helps prevent rework caused by missed stakeholder input.

An ARB does not operate in isolation. It is embedded within the project delivery lifecycle, reviewing solution designs, custom builds, and third-party products to ensure enterprise alignment. Reviews usually occur after the design phase—before build or purchase decisions—and again before deployment to confirm that the implemented solution matches the approved architecture.

While most organizations recognize the value of an ARB, many struggle to run it effectively. When designed well, an efficient architecture review process reduces costs, lowers security risk, and limits the accumulation of technical debt—turning governance into a catalyst for better outcomes rather than a delivery bottleneck.

What Is an Architecture Review Board in an AWS Cloud-Native Environment?

In an AWS cloud-native and agile environment, an Architecture Review Board (ARB) exists to help teams build solutions that align with the AWS Well-Architected Framework while maintaining enterprise guardrails. Rather than acting as a gatekeeper, a modern ARB enables teams to design architectures that are secure, reliable, performant, cost-efficient, operationally excellent, and sustainable—without slowing delivery.

A cloud-native ARB is inherently cross-functional, bringing together Security, Engineering, Platform, Enterprise Architecture, and Operations. This mirrors the Well-Architected approach, where architectural quality is the result of shared ownership across disciplines. Early collaboration reduces late-stage rework and helps teams make informed trade-offs across the Well-Architected pillars.

Unlike traditional review boards, a Well-Architected–aligned ARB is embedded into the delivery lifecycle. Reviews occur early in design to guide service selection and architectural patterns, and again before release to ensure the implemented solution matches the approved design. In mature AWS environments, many of these reviews are reinforced through infrastructure as code, policy as code, guardrails, and reusable “golden paths,” allowing teams to move fast while staying compliant.

Architecture Without a Review Framework

One of the biggest challenges in software architecture is achieving human consensus. In any organization, teams bring diverse priorities, perspectives, and constraints to the table. Without a formal architecture review process, these differences often turn into prolonged debates, inconsistent decisions, and stalled delivery.

In the absence of a shared review model and clear architectural guardrails, discussions become opinion-driven rather than principle-driven. Over time, this slows down teams and increases friction between stakeholders. In practice, we often see individuals gravitate toward a few common personas:

The Late Reviewer

Offers thoughtful feedback, but only at the final stages of delivery. Late input reduces the team’s ability to incorporate feedback effectively and often leads to rework.

The Central Gatekeeper

Insists on being involved in every architectural decision. While well-intentioned, this behavior limits scalability and creates single points of decision failure.

The Over-Designer

Passionate about craftsmanship and innovation, but tends to introduce unnecessary complexity. Solutions risk becoming difficult to operate and evolve.

The Idealist

Strives for perfection at every step. This often delays decisions and prevents teams from delivering incremental value.

Benefits of an Architecture Review Board

Establishing an Architecture Review Board (ARB) delivers measurable value by improving architectural quality while enabling teams to move fast with confidence.

Improved compliance

A consistent review process helps ensure architectures align with enterprise standards, regulatory requirements, and approved design patterns. By reviewing decisions early, the ARB reinforces shared guardrails without slowing delivery.

Reduced technical debt

Technical debt often starts with small design compromises that scale into long-term problems. The ARB identifies these risks early, promoting sustainable patterns and long-term thinking. This results in cleaner architectures, more maintainable systems, and less rework over time.

Greater efficiency and lower costs

Contrary to common perception, a well-run ARB reduces friction rather than creating it. Standardized architectures and reusable patterns improve delivery speed, resource utilization, and cost predictability—while avoiding expensive late-stage rewrites.

Improved supportability and reliability

By embedding operational considerations into design reviews, the ARB ensures systems are easier to operate, monitor, and troubleshoot. Cross-functional representation surfaces supportability concerns early, leading to more resilient systems and fewer production incidents.

Security by design

Security is the most critical outcome of an effective ARB. By integrating security reviews into architectural decisions from day one, the ARB helps protect against data exposure, unauthorized access, and evolving threats. This proactive approach strengthens trust with customers and stakeholders while reducing downstream risk.

For more details on the review process, see Well-Architected Framework: The review process

SCP Automation for AWS Organization

Olawale Adepoju — Tue, 14 Jan 2025 05:16:00 +0000

Understanding AWS Service Control Policies (SCPs) in AWS Organizations

As organizations grow and adopt cloud technologies, managing access and ensuring compliance across multiple accounts becomes increasingly complex. AWS Organizations, a service that allows you to centrally manage and govern multiple AWS accounts, provides a powerful feature called Service Control Policies (SCPs) to help you enforce governance at scale.
AWS Service Control Policies (SCPs) are a powerful tool for managing permissions and enforcing governance across your AWS environment. By using SCPs effectively, you can ensure that your organization remains secure, compliant, and well-managed as you scale your cloud operations. Whether you’re restricting access to specific services, enforcing compliance standards, or managing permissions across multiple accounts,
In this blog, we’ll explore what SCPs are, how they work, and why they are essential for managing your AWS environment.

What Are Service Control Policies (SCPs)?

Service Control Policies (SCPs) are a type of policy in AWS Organizations that allow you to define and enforce permissions for AWS accounts within your organization. SCPs act as guardrails, specifying the maximum permissions that accounts in an organizational unit (OU) or the entire organization can have. They do not grant permissions themselves but instead restrict what actions can or cannot be performed, even if permissions are granted at the account level.

Think of SCPs as a way to set boundaries for what is allowed in your AWS environment. For example, you can use SCPs to ensure that no account in your organization can delete critical resources, use specific regions, or access certain AWS services.

How Do SCPs Work?

SCPs are applied at the organizational level and are evaluated alongside Identity and Access Management (IAM) policies. Here’s how they work:

Hierarchy of Application: SCPs can be attached to the root of your organization, specific organizational units (OUs), or individual accounts. Policies applied at a higher level (e.g., the root) cascade down to all child OUs and accounts.
Deny by Default: SCPs operate on a "deny by default" principle. If an action is not explicitly allowed by the SCP, it is implicitly denied, even if an IAM policy grants the action.
No Direct Permissions: SCPs do not grant permissions. They only define the maximum permissions that can be granted by IAM policies. For example, if an SCP denies access to a service, no IAM policy can override that denial.
Policy Evaluation: When a user or role attempts to perform an action, AWS evaluates the SCPs attached to the account, the IAM policies, and any resource-based policies. If the action is not allowed by the SCP, it is denied.

Why Use SCPs?

SCPs are a critical tool for organizations that need to enforce governance and compliance across multiple AWS accounts. Here are some key benefits:

Centralized Control: SCPs allow you to manage permissions across all accounts in your organization from a single location, reducing the risk of misconfigurations.
Enforce Compliance: You can use SCPs to enforce compliance with organizational policies, such as restricting the use of certain AWS regions or services.
Limit Risk: By restricting access to sensitive services or actions, SCPs help reduce the risk of accidental or malicious changes to your AWS environment.
Simplify Management: SCPs make it easier to manage permissions across multiple accounts by applying consistent policies at the OU or organizational level.

Use Cases for SCPs

In this use case we will look at SCP to deny member accounts from leaving the organization, this policy will be applied at Root OU of the AWS Organization, and also another SCP to deny user from creating console login access in a member account, this policy will be applied a Compliant OU level( which is a child ou of the root).

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": "organizations:LeaveOrganization",
        "Resource": "*"
      }
    ]
  }

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateLoginProfile"
      ],
      "Resource": "arn:aws:iam::*:user/*"
    }
  ]
}

Kindly check out the repo for detailed code for setting up the SCP's at different OU levels and unit testing of each attached policies. https://github.com/olawaleade/aws_scp_automation

Deploy App on AWS ECS Fargate using Github Actions

Olawale Adepoju — Tue, 23 Apr 2024 07:02:02 +0000

In this blog, i will show how to deploy an application on Amazon ECS using the Fargate for efficient containerized deployment and also Github actions will be used for the CI/CD.

Step 1: Create your repository on ECR( Amazon Elastic Container Registry)

Step 2: Create cluster in ECS

Step 3: Create a Task Definition

You can create a task role if you don't have existing role created. These are the two policies required for the role

For the container, give a name, and copy the image URL created in the ECR previously.
Add the port in which your application is accessed.

Step 4: Create a Service
Note: After creating this service it will fail because there is no image pushed to the ECR yet.
Click on the cluster created, and create service.

Step 5: While service is creating, configure your application github workflow. The application is packaged using Docker.

Hence the dockerfile



FROM node:16.20.1
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 5000
CMD ["npm","run","start"]

github workflow is as below



name: CICD

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: [ ubuntu-latest ]
    steps:
      - name: Checkout source
        uses: actions/checkout@v3
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
        with:
          mask-password: 'true'

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: latest
          REPOSITORY: nodeapp
        run: |
          # Build a docker container and
          # push it to ECR so that it can
          # be deployed to ECS.
          docker build -t $ECR_REGISTRY/$REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$REPOSITORY:$IMAGE_TAG
          echo "image=$ECR_REGISTRY/$REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT    

      - name: Fill in the new image ID in the Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: nodejs-app-task-definition.json 
          container-name: nodejs-app
          image: ${{ steps.build-image.outputs.image }}    
      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: nodejs-app-service
          cluster: DevCluster
          wait-for-service-stability: true

Note:

Create the task definition file(nodejs-app-task-definition.json) in the directory of your project. Copy the json file and paste in the file created.
The environment variables are set in github settings

After the image is built and pushed to ECR, the service becomes active and running.

Click on the task to see the configuration to see the public ip address.

Integrating AzureAD to Auth0

Olawale Adepoju — Mon, 15 Apr 2024 01:03:20 +0000

Introduction to Auth0

Auth0 is a versatile plug-and-play solution for adding authentication and authorization services to your application. Your company may save the cost, effort, and risk associated with developing your own authentication and authorization solution.

When you build an application and you want to incorporate user authentication and authorization so that your users will be able to log in either with a username/password or with their social accounts (such as Microsoft Account).

Integrating the Auth0 with Azure Active Directory might be challenging, so I will cover the procedures to be followed when implementing the integration. There are numerous steps that are broken down below:

Configure App In Azure AD
Create The Client Secret In Azure AD
Configure API Permissions
Create Enterprise Connection In Auth0
Enable Enterprise Connection For Application
Testing

Configure App In Azure AD

By now you must have had an account registered in the Azure portal, navigate to Azure AD in the Azure Portal.

Click the “App Registrations” button in the side menu.

In Azure AD App Registrations, create a new App Registration.

You should now see the App Registration screen.

Enter the name for your application (you can change this later if you get it wrong).
Select “Accounts in this organizational directory only” (multi-tenant is beyond the scope of this article).
Configure redirect URI selecting “Web” and entering the callback URL https://{your-auth0-tenant}.auth0.com/login/callback (obviously, replace {your-auth0-tenant} with your Auth0 tenant name)
Click “Register”.

You should now see the newly created app Overview screen.

NOTE !! Copy the Application (client) ID from the overview screen of your newly created app registration, we'll need this later.

Create The Client Secret In Azure AD

Select the “Certificates & Secrets” area from the App registration side menu

Click the “New client secret” button in the “Client secrets” section.
You should now see the Client Secret creation dialog

Enter the name for the description.
Select expiry “Custom” depending on preference.
Click the “Add” button.
You should now see the new client secret listed in the “Client secrets” section.

Configure API Permissions

We need to configure access to the MS Graph API for retrieving basic user profile and directory info. This will be done with delegated permissions which give access to the "User.Read" and directory.Read.All' permissions.

On your App registration overview screen, click on the API permission
You should now see the API permissions screen, click on add permission.

On the Microsoft APIs, click on the Microsoft graph.
You should see that “Delegated” permission for "User.Read" is already configured by default. Also, follow the steps below to replace Directory.Read.All

In the search text field under the “Select Permissions” heading enter the text "Directory.Read.All'. Tick the checkbox next to the “Directory.Read.All” permission.

Click the “Add Permissions” button.

Create Enterprise Connection in Auth0

Here you have to be logged in to your Auth0 tenant control panel, and it is assumed you have an application running in the Auth0. We establish an enterprise connection in Auth0, to connect the Azure AD to the application in the Auth0 tenant.

Click on Authentication> Enterprise

Click the + button next to Azure AD
You should see the New Azure AD connection screen

Enter the connection name (Needs to be unique).
Enter the domain in the Microsoft Azure AD Domain field.
Enter your Azure AD app registration Application (client) ID and Client Secret (which is the value in the client secret). You should have saved these while creating your Azure App registration.
Leave everything else as a default
Click the "create" button

Enable Enterprise Connection For Application

Having created the Enterprise Connection you should be looking at the connection already. If not navigate to Connections> Enterprise> Microsoft Azure AD> Your-Enterprise-Connection.

Click the "Applications" tab in the main heading, click on your application and enable the toggle next to it.

Testing

Open Authentication> Enterprise> Microsoft Azure AD, click on the try button

You should be redirected to the Azure AD login screen

After Login, accept the permissions request (may not be shown depending on Azure AD config for granting permissions).
If successful you should see the “It Works!” Message.

Overview of AWS Cost Explorer

Olawale Adepoju — Tue, 09 Apr 2024 01:27:21 +0000

Why AWS Cost Explorer?

AWS Cost Explorer is a tool that enables you to view and analyze your costs and usage. You can explore your usage and costs using the main graph, the Cost Explorer cost and usage reports, or the Cost Explorer RI reports. You can view data for up to the last 13 months, forecast how much you're likely to spend for the next 12 months, and get recommendations for what Reserved Instances to purchase. You can use Cost Explorer to identify areas that need further inquiry and see trends that you can use to understand your costs.https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html

AWS Cost Explorer offers an easy-to-use interface to visualize and understand your AWS cost and usage over time. Previously, Cost Explorer provided up to 13 months of cost and usage data at daily and monthly granularity as a free feature, with an option for hourly granularity over the past 14 days as a paid feature. However, customers requiring multi-year analysis or understanding cost drivers with resource level details couldn’t complete these tasks in Cost Explorer. Now, with extended multi-year history and more granular resource level data within Cost Explorer, customers no longer need to leave Cost Explorer to perform the above analysis

Cost Explorer now offers the following features for free:

Multi-year data at monthly granularity: you can now access up to 38 months of historical data at monthly granularity, allowing for more comprehensive long-term trend analysis.
Resource-level data at daily granularity: Cost Explorer offers resource-level data at daily granularity, spanning over the past 14 days, enabling you to dive into your cost drivers.

Note: The hourly data as well as daily resource-level data is available for the past 14 days.

Enabling Cost Explorer

You can enable Cost Explorer for your account by opening Cost Explorer for the first time in the AWS Cost Management console. You can't enable Cost Explorer using the API. After you enable Cost Explorer, AWS prepares the data about your costs for the current month and the last 13 months, and then calculates the forecast for the next 12 months. The current month's data is available for viewing in about 24 hours. The rest of your data takes a few days longer. Cost Explorer refreshes your cost data at least once every 24 hours.
You can launch Cost Explorer if your account is a member account in an organization where the management account enabled Cost Explorer.

Note:
An account’s status within an organization determines what cost and usage data are visible:

A standalone account joins an organization. After this, the account can no longer access cost and usage data from when the account was a standalone account.
A member account leaves an organization to become a standalone account. After this, the account can no longer access cost and usage data from when the account was a member of the organization. The account can access only the data that's generated as a standalone account.
A member account leaves organization A to join organization B. After this, the account can no longer access cost and usage data from when the account was a member of organization A. The account can access only the data that's generated as a member of organization B.
An account rejoins an organization that the account previously belonged to. After this, the account regains access to its historical cost and usage data.

To sign up for Cost Explorer

Sign in to the AWS Management Console and open the AWS Cost Management console.
In the navigation pane, choose Cost Explorer.
On the Welcome to Cost Explorer page, choose Launch Cost Explorer.

Starting Cost Explorer

After you enable Cost Explorer, you can launch it from the AWS Cost Management console.
Start Cost Explorer by opening the AWS Cost Management console.

To open Cost Explorer

Sign in to the AWS Management Console and open the AWS Cost Management console at https://console.aws.amazon.com/cost-management/home.

This opens the Cost dashboard that shows you the following:

Your estimated costs for the month to date
Your forecasted costs for the month
A graph of your daily costs
Your five top cost trends
A list of reports that you recently viewed

To set up multi-year and granular data

Enable multi-year data at monthly granularity and resource-level data at daily granularity
Using the management account, you can enable multi-year data and granular data in Cost Explorer. You do this in the Cost Management preferences in the console.

However, in order to enable multi-year and granular data, you first need to manage access to view and edit your Cost Management preferences.

You can enable multi-year data at monthly granularity and resource-level data at daily granularity from Cost management preference page available to management account of your organization. Once these features are enabled, they can be used by all accounts in your organization.

Note: Enabling multi-year data at monthly granularity: You can click on the checkbox to enable this feature. Once enabled, your data should be available within 48 hours in Cost Explorer.

Enabling resource-level data at daily granularity: You can select specific services you want to enable resource data for. The services are listed in the order of their contribution to your AWS bill, with the most expensive service on top. Once enabled, your data will be available in Cost Explorer within 48 hours.

Sign in to the AWS Management Console and open the AWS Cost Management console at https://console.aws.amazon.com/cost-management/home
In the navigation pane, choose Cost Management preferences.
To get historical data for up to 38 months, select Multi-year data at monthly granularity.
To enable resource-level or hourly granular data, consider the following options:

Hourly granularity
- Select Cost and usage data for all AWS services at hourly granularity to get hourly data for all AWS services without resource-level data.
- Select EC2-Instances (Elastic Compute Cloud) resource-level data to track EC2 cost and usage at instance level at hourly granularity.
Daily granularity
- Select Resource-level data at daily granularity to get resource-level data for individual or all AWS services.
- Choose services from the AWS services at daily granularity dropdown list that you want to enable resource-level data for.

Enabling historical data display for 38 months

Your business, applications, and architecture have matured in the past few years and you are wondering how your AWS spend has evolved along with that. You can now perform this analysis for the past three years in Cost Explorer and get a better understanding of your year-over-year or quarter-over-quarter spend patterns. In Cost Explorer, you can now select a start date within the past three years and set an end date to any date up to the present day to create multi-year data view. You can filter and group this data by various dimensions, such as service, account, region, usage type to perform comprehensive analysis.

Enable Resource-level data at daily granularity

Note: Hourly granularity(up to 14 days of past data) is a paid feature https://docs.aws.amazon.com/cost-management/latest/userguide/ce-hourly-granularity.html

You have noticed variance in your Lambda spend in the past two weeks and you are wondering what is causing that at the resource level. You can now perform this analysis in Cost Explorer and pinpoint the exact Lambda functions responsible for the variance. You can then discuss these functions with respective teams to differentiate intended from unintended spend.

You can filter Cost Explorer for Lambda service to focus on Lambda cost and usage.

Kinesis Producers

Olawale Adepoju — Mon, 01 Apr 2024 06:28:12 +0000

Kinesis Producers

A producer for Amazon Kinesis Data Streams is an application that feeds user data records into a Kinesis data stream (also called data ingestion). The Kinesis Producer Library (KPL) makes it easier to construct producer applications by allowing developers to achieve high write throughput to a Kinesis data stream.

There are different methods to stream data into Amazon kinesis streams:

Kinesis SDK
Kinesis Producer Library (KPL)
Kinesis Agent

Other third-party libraries include:

Spark, Log4J, Appenders, Flume, Kafka Connect, NiFi

Kinesis Producer SDK - PutRecord(s)

PutRecord (one record) and PutRecords (many records) APIs are utilized.
PutRecords leverages batching and enhances performance, resulting in fewer HTTP calls.
AWS Mobile SDKs: Android, iOS, etc...
Managed Amazon Web Services sources for Kinesis Data Streams:
- AWS IoT
- CloudWatch Logs
- Kinesis Data Analytics

Use cases:
low throughput, higher latency, simple API, AWS Lambda

Kinesis Producer Library (KPL)

Easy to use and highly configurable C++/Java library
Used for building high-performance, long-running producers
Automated and configurable retry mechanism
Synchronous or Asynchronous APIs (better performance for async)
Submits metrics to CloudWatch for monitoring.
Batching (both turned on by default) – increase throughput, decrease cost:
- Collect Records and Write to multiple shards in the same PutRecords API call.
- Aggregate – increased latency.

Kinesis Producer Library (KPL) Batching

By inserting some delay using RecordMaxBufferedTime, batching efficiency can be impacted (default 100ms)

NOTE: When not to use the Kinesis Producer Library

The KPL can incur an additional processing delay of up to RecordMaxBufferedTime within the library (user-configurable)
Larger values of RecordMaxBufferedTime result in higher packing efficiencies and better performance
Applications that cannot tolerate this additional delay may need to use the AWS SDK directly

Kinesis Agent

Monitor Log files and sends them to Kinesis Data Streams
Java-based agent, built on top of KPL
Install in Linux-based server environments

Features:

Write from multiple directories and write to multiple streams
Routing feature based on directory/log file
Pre-process data before sending to streams (single line, CSV to JSON, log to JSON)
The agent handles file rotation, checkpointing, and retry upon failures
Emits metrics to CloudWatch for monitoring

AWS Kinesis API - Exceptions

Provisioned Throughput Exceeded Exceptions
Happens when sending more data (exceeding MB/s or TPS for any shard)
Make sure you don't have a hot shard (such as your partition key is bad and too many data goes to that partition) Solution:
- Retries with backoff
- Increase shards (scaling)
- Ensure your partition key is a good one

AWS Cost Optimization Hub

Olawale Adepoju — Mon, 25 Mar 2024 08:34:38 +0000

Overview of Cost Optimization Hub

Cost Optimization Hub is an AWS Billing and Cost Management feature that helps you consolidate and prioritize cost optimization recommendations across your AWS accounts and AWS Regions, so that you can get the most out of your AWS spend.

Cost Optimization Hub provides the following main benefits:

Automatically identify and consolidate your AWS cost optimization opportunities.
Quantify estimated savings that incorporate your AWS pricing and discounts.
Aggregate and deduplicate savings across related cost optimization opportunities.
Prioritize your cost optimization recommendations with filtering, sorting, and grouping.
Measure and benchmark your cost efficiency.

Accounts supported by Cost Optimization Hub

The following AWS account types can opt in to Cost Optimization Hub:

Standalone AWS account

A standalone AWS account that doesn't have AWS Organizations enabled. For example, if you opt in to Cost Optimization Hub while signed in to a standalone account, Cost Optimization Hub identifies cost optimization opportunities and consolidates recommendations.

Member account of an organization

An AWS account that's a member of an organization. If you opt in to Cost Optimization Hub while signed in to a member account of an organization, Cost Optimization Hub identifies cost optimization opportunities and consolidates recommendations.

Management account of an organization

An AWS account that administers an organization. If you opt in to Cost Optimization Hub while signed in to a management account of an organization, Cost Optimization Hub gives you the option to opt in the management account only, or the management account and all member accounts of the organization.

Note: To opt in all member accounts for an organization, make sure that the organization has all features enabled. For more information, see Enabling All Features in Your Organization

Getting started with Cost Optimization Hub

When you access Cost Optimization Hub for the first time, you're asked to opt in using the account that you’re signed in with.
Before you can use the feature, you must opt in. In addition, you can also opt in using the Cost Optimization Hub API, AWS Command Line Interface (AWS CLI), or SDKs.

By opting in, you authorize Cost Optimization Hub to import cost optimization recommendations generated by multiple AWS services in your account and all member accounts of your organization. These include rightsizing recommendations from AWS Compute Optimizer and Savings Plans recommendations from AWS Billing and Cost Management. These recommendations are saved in the US East (N. Virginia) Region.

Enabling Cost Optimization Hub

To enable Cost Optimization Hub

Sign in to the AWS Management Console.
In the navigation pane, choose Cost Optimization Hub.
On the Cost Optimization Hub page, choose your relevant organization and member account settings:
- Enable Cost Optimization Hub for this account and all member accounts: Recommendations in this account and all member accounts will be imported into Cost Optimization Hub.

Choose Enable.

After you enable Cost Optimization Hub, AWS starts to import cost optimization recommendations from various AWS products, such as AWS Compute Optimizer. It can take as long as 24 hours for Cost Optimization Hub to import recommendations for all supported AWS resources.

Accessing the console

When your setup is complete, access Cost Optimization Hub.

To access Cost Optimization Hub

Sign in to the AWS Management Console
In the navigation pane, choose Cost Optimization Hub.

Opting out of Cost Optimization Hub

You can opt out of Cost Optimization Hub at any time. However, the organization account can't opt out all member accounts. Each member needs to opt out at account level.

To opt out of Cost Optimization Hub

Sign in to the AWS Management Console.
In the navigation pane, choose Cost Management Preferences.
In Preferences, choose Cost Optimization Hub.
On the Cost Optimization Hub tab, clear Enable Cost Optimization Hub.
Choose Save preferences.

Viewing your cost optimization opportunities

Cost optimization findings for your resources are displayed on the Cost Optimization Hub dashboard. You can use this dashboard to filter cost optimization opportunities and aggregate estimated savings. You can compare your total savings opportunities against your previous month's AWS spend.

Use the dashboard to group your savings opportunities by AWS account, AWS Region, resource types, and tags. View the distribution of your savings opportunities, explore the recommended actions, and identify the areas with the most savings opportunities. The dashboard is refreshed daily and all costs reflect your usage up to the previous day. For example, if today is December 2, the data includes your usage through December 1.

Viewing the dashboard

Use the following procedure to view the dashboard and your cost optimization opportunities.

Sign in to the AWS Management Console and open the AWS Billing and Cost Management.
In the navigation pane, choose Cost Optimization Hub. By default, the dashboard displays an overview of cost optimization opportunities for AWS resources across all AWS Regions in the account that you're currently signed in to.
You can perform the following actions on the dashboard:
- To view the cost optimization findings for a particular AWS Region in the account, choose the Region in the chart.
- To view the cost optimization findings for resources in a particular account, under Aggregate estimated savings by, choose AWS account, and then choose an account ID in the chart.
- To view cost optimization findings by resource type, under Aggregate estimated savings by, choose Resource type.
- To view recommended actions, under Aggregate estimated savings by, choose Recommended action.
- To filter findings on the dashboard, under Filter, choose from the filter options.
- To go to the list of resources available for optimization, choose View opportunities.

Switching the dashboard view

The Cost Optimization Hub dashboard provides you two styles for viewing your cost optimization opportunities:

Chart view
Table view

You can set the style by choosing one of the views on the top right corner of the chart or table.

Reference

You can also reference here

Migrating repository from github to gitlab

Olawale Adepoju — Tue, 19 Mar 2024 05:15:16 +0000

I will be showing how I migrated a repository from GitHub to GitLab. There are two methods;

Option 1
Firstly you can do it on the console by going to GitLab and authenticating your GitHub credential there and you will be able to import all the repositories you want on GitLab.

Choose the import project option

Choose the GitHub option

It will show the option of Authorization from GitHub.

you can import all repositories or choose the repository to be migrated. Also, there is an option of importing issues pull request events.

Option 2
The second option, let's say your GitHub is in a private network and you want to take one repository and push it to GitLab, where GitLab is on some other network or hosted in some other cloud environment. How do you migrate in this case?

Clone the GitHub repository you want to migrate. use

git clone --bare <GitHub URL>

Create a new project in GitLab, and choose the create the blank project option

Give a project name and click create project.

Push the cloned repository to GitLab.

git push --mirror <GitLab URL>

Error Alert: while I push to GitLab I encountered an error

How did I solve it?
Go to project: "Settings" → "Repository" → "Expand" on "Protected branches" and click on unprotect.

Now the GitHub repository is migrated successfully to GitLab

Add alternate contacts to AWS Organization member accounts programmatically

Olawale Adepoju — Tue, 12 Mar 2024 07:04:00 +0000

To manage the alternate contacts (billing, operations, and security) on your member accounts in AWS Organizations can be daunting sometimes especially when there are quite a large number of member account in the AWS Organization. To input it one after the other can be tasking, so i will be showing how to set the same alternate contacts across all of your accounts programmatically across Organization.

#### Why Alternate Account?

Mostly we want to right people to receive AWS notification regarding billing, operations and security on all of your accounts so that your Cloud Center of Excellence (CCoE) team can receive important notifications about your AWS accounts and take due actions.
Managing alternate contacts become even more important as your organization scales to hundreds or thousands of accounts, saving you time and reducing operational burden.
We’re going to use AWS CloudShell, a browser-based shell that is automatically authenticated with your AWS console credentials and accessible via the upper navigation bar of the AWS console.

Note:
First need to make sure that the AWS Identity and Access Management (IAM) user or role you want to manage alternate contacts with has the following permissions:

account: GetAlternateContact – allows the user to view the current alternate contact
account: PutAlternateContact – allows the user to set a new alternate contact
account: DeleteAlternateContact – allows the user to delete an alternate contact

Better so grant the requisite permissions to manage alternate contacts by attaching the AWSAccountManagementFullAccess managed policy to your IAM user or role.

Next, you’ll need to enable the AWS Account Management service for your organization so you can centrally manage alternate contacts. You can do this by using this CLI command from the management account:

aws organizations enable-aws-service-access --service-principal account.amazonaws.com

Finally, you can register a delegated administrator so users don’t need access to the management account to manage alternate contacts.

aws organizations register-delegated-administrator --account-id <YOUR-CHOSEN-ACCOUNT-ID> --service-principal account.amazonaws.com

#### Automating the Alternate contacts

loop-accounts.sh – This script gathers a list of all accounts in your organization and then executes the security-contact.sh script. Paste the script in your CloudShell

cat << EOF > loop-accounts.sh
#! /bin/bash
    managementaccount=\`aws organizations describe-organization --query Organization.MasterAccountId --output text\`

    for account in \$(aws organizations list-accounts --query 'Accounts[].Id' --output text); do

            if [ "\$managementaccount" -eq "\$account" ]
                     then
                         echo 'Skipping management account.'
                         continue
            fi
            ./security-contact.sh -a \$account
            sleep 0.2
    done
EOF
chmod 755 loop-accounts.sh

Note: The management account is explicitly excluded from the account list. This is because alternate contacts for the management account can only be modified using the standalone context, not the organization context.

security-contact.sh – This script sets the security alternate contact to the member account in the AWS Organization. Paste the script in your CloudShell

cat << EOF > security-contact.sh
#! /bin/bash
while getopts a: flag
do
    case "\${flag}" in
        a) account_id=\${OPTARG};;
    esac
done

echo 'Put security contact for account '\$account_id'...'
aws account put-alternate-contact \
  --account-id \$account_id \
  --alternate-contact-type=SECURITY \
  --email-address=mysecurity-contact@example.com \
  --phone-number="+1(111)222-3333" \
  --title="Security Contact" \
  --name="My Name"
echo 'Done putting security contact for account '\$account_id'.'

EOF
chmod 755 security-contact.sh

FYI: make sure to replace the contact details with your actual contact information.