To make things easier, I rented a car to move flexibly between sessions at Venetian, MGM, and Mandalay. However, I couldn't do everything because I caught the flu 🤒 and had to spend half of the first two days in the hotel. Despite this, I managed to finish the re:Invent 5K run with Chibuike Nwachukwu and set a personal record of 30:20, which is below my usual PRs on Strava .

Now, enough about me. We all know Amazon Web Services (AWS) re:Invent is the largest tech conference in the world, drawing over 60,000 attendees from all around the globe. It's my favorite tech conference ever.

Even though I spent half of the first two days recovering from the flu, it was amazing reconnecting with familiar faces who have become like family, as well as meeting new professionals.

Here are some of my top security highlights from the event that I thought you might find interesting:

Security Hub:

The new Amazon Web Services (AWS) Security Hub features were announced in June 2025 during the AWS re:Inforce conference, which is a standalone security conference hosted by AWS. They introduced a refined UI, provided near real-time risk analytics and trends, unified enablement, and automated correlation that transforms security signals into actionable insights. Additionally, they added a combination of findings in Security Hub with third-party integrations like Jira, ServiceNow, and many more. Although it was in preview since June, it is now generally available with near real-time analytics and risk prioritization. I was genuinely happy with how Security Hub has improved. FAQs

AWS login

The new aws login command lets you obtain credentials for a CLI (or other applications) by using your browser session. Previously, this feature was available for AWS Identity Center users through "aws sso login" or various open-source tools, but it wasn't available for all types of account access scenarios.

Make sure you upgrade AWS CLI to AWS CLI v2 before you can enjoy the feature. Here is a link to more information on aws login

AWS Organizations: Direct Account Transfer between organizations:

Amazon Web Services (AWS) Organizations now allows direct account transfers between organizations, eliminating the need for accounts to operate as standalone accounts during the transfer process. This streamlines account transfers and ensures continued access to governance features and consolidated billing benefits. Get more information here.

Amazon GuardDuty now includes Extended Threat Detection for EC2 and ECS.

Amazon GuardDuty Extended Threat Detection now includes new attack sequence findings for Amazon EC2 instances and ECS tasks, enhancing visibility and detection of multistage attacks across virtual machine and container environments using AI and ML. For more information on how it works, check here.

Amazon S3 Block Public Access now supports organization-level enforcement.

All cloud security experts know the criticality of Data Perimeters and how insecure, overpermissive S3 buckets can lead to security incidents and many other issues. Amazon S3 Block Public Access (BPA) now offers organization-level control through AWS Organizations, allowing centralized enforcement of S3 public access settings across all accounts. This feature is available in the AWS Organizations console and AWS CLI/SDK, with no additional charges.

As an AB alumni advisor, it was such a pleasure to see my mentees and help them navigate the conference Banshaj Paudel , Omshree Butani , Taihei Mizuno , 최영훈 , Kashish Datta, CSPO® , Hsien-Cheng Huang thank you for being such an awesome group.

It was wonderful spending quality time with these kind-hearted individuals: Damien Burks Kosisochukwu Akaeze , Mariana Arce Aguilar , Aminat Usman , Chukwudi Uzoma , Oloruntobi Awoderu , Victory Eze , Rhea Katherine Minta-Jacobs , Jemil Oyebisi , Viktoria Semaan , Olushola Oladipupo , Melody Egwuchukwu , Charity Kemei , Sharanya Sisodia , Yinka Aluko , Pranjal Nawarkar , Natasha Moses , Elyas Syed , Manasse Ngendahimana , Endah Bongo-Awah , Elijah Ibidayo , Davin Latiker, MBA

A big thank you to 🖖 Andoni Alonso Fernández for the Prowler t-shirt and the unicorn sticker. Also, thank you to Norma Stevens and Marisol Jenkins for all your wonderful work for the AB Community. I’m feeling much better now.

Back story: Shai-Hulud was first discovered in September 2025, following a software supply chain attack in the open-source community. This created Panic for everyone, but it was eventually contained and mitigated. You can read more on it from the Wiz research team articles here.

Indeed, the resurgence of Sha1-Hulud 2.0: The Second Coming has caused widespread concern within the technology industry today, November 24th, 2025. This worm has triggered a wave of fear and worry across the tech space. This is to the point that Snyk, Wiz, and many other vendors were proactive in quickly addressing the malware to prevent widespread impact for their affected customers.

This outbreak has already surpassed the initial Shai-Hulud situation, with over 800 npm packages having been trojanized and numerous GitHub repositories impacted. At the time of writing this technical wiki, the blast radius has crossed over 25k, and more. The malware has rapidly spread among various maintainers, including those mentioned above ( Zapier, ENS Domains, PostHog, and Postman)

While doing more research, I found a research article by the KOI team explaining that the resurgent is so aggressive that it has a fallback mechanism, meaning when the malware fails to authenticate or establish persistence, then it attempts to destroy the victim’s entire home directly. The malware deletes every writable file owned by the current user under the home directory. Also, these fallback mechanisms are triggered if it cannot authenticate to GitHub, it cannot create a GitHub repository, it cannot fetch a GitHub token, or it cannot find an NPM token.

While researching, I found a KOI team article explaining the aggressive resurgent’s fallback mechanism. If the malware fails to authenticate or persist, it attempts to destroy the victim’s home directory by deleting all writable files under the user’s home directory. These mechanisms are triggered if authentication to GitHub, repository creation, token fetching, or NPM token finding fails.

Recommendation Action

• Snyk has updated its reporting filter, so you can search for the new campaign, such as Shai-Hulud.

• Wiz shared actionable recommendations even for non-affected organizations:

  • Monitor - Track any new package installations from affected namespaces like AsyncAPI, PostHog, Browserbase, and Postman.

  • Review CI/CD - Verify build pipelines have restricted outbound network access.

  • Rotate credentials - Implement regular rotation for npm and GitHub tokens

  • Restrict lifecycle scripts - Consider blocking preinstall/postinstall execution in production.

Check out this comprehensive research paper from Wiz on Shai-Hulud 2.0: The second coming. It has detailed research information.

In this blog, I just want to break down what cloud security flaws are, the most common examples with real-world impact, and then share practical tips for how to address cloud security flaws in your environment.

What are Cloud Security Flaws?

Cloud security flaws are vulnerabilities, misconfigurations, anomalies, or weaknesses in how your cloud resources are configured, deployed, accessed, or managed. These flaws can allow attackers to:

• Steal data (due to improper or over-permissive configuration )

• Hijack cloud resources

• Move laterally across environments

• Disrupt services or plant malware

Cloud flaws often result from poor governance, lack of awareness, or overly complex cloud architectures.

Top 5 Common Cloud Security Flaws

The most common cloud security flaws include:

1. Misconfigurations

2. Weak Identity and Access Management (IAM)

3. Insecure APIs

4. Unpatched Vulnerabilities

5. Lack of Data Protection

1. Misconfigurations

Cloud misconfigurations create vulnerabilities that attackers can exploit to gain unauthorized access to sensitive data and critical application services. Most misconfigured cloud services are

• Publicly accessible S3 buckets or Azure Blob Storage

• Open security groups (e.g., port 22 open to 0.0.0.0/0)

• Disabled logging or monitoring tools

Example

In May 2022, Pegasus Airlines experienced a data breach due to a misconfigured AWS S3 bucket. The breach exposed 6.5 terabytes of sensitive data, including personal information and operational details of flight crew members. Because the bucket was publicly accessible, attackers could download confidential files. This incident highlights S3 configurations needed: server-side encryption for S3 buckets, strict bucket policies to prevent public access, and AWS Config or a third-party tool like Wiz implementation to detect and fix misconfigurations in real time.

2. Weak Identity and Access Management (IAM)

IAM defines and controls who can access what in your cloud environment. However, when improperly configured, it can lead to unauthorized access to your cloud resources, posing a significant risk.k The following are flaws in IAM:

• Overly permissive roles (e.g., AdministratorAccess for every user)

• Lack of MFA (Multi-Factor Authentication)

• Use of long-lived access keys

• Lack of principles of least privilege and Role-Based Access Control (RBAC)

• Unused IAM users/service accounts

• Non-centralized IAM configuration

Example

In 2017, Equifax experienced one of the largest data breaches in history. Hackers found and exploited a known vulnerability in an open-source software module used in Equifax's web applications. They gained unauthorized access to important customer records, affecting about 147 million people.

Weaknesses and inconsistencies in IAM controls contributed to the breach, enabling hackers to impersonate legitimate users and move undetected through Equifax's systems for months. This resulted in substantial financial and regulatory consequences for Equifax.

3. Insecure APIs

Application programming interfaces (APIs) are essential for accessing cloud resources, but insecure APIs can be attacked by hackers, leading to data leaks, account takeovers, and service disruptions. The following are flaws in APIs:

• Lack of authentication or rate limiting

• Insecure input handling (e.g., no validation or sanitization)

• Overexposed API endpoints

• Externalized API that is not behind a firewall

Example

April 2021: Experian API Flaw
Security researcher Bill Demirkapi discovered a vulnerability in an Experian API used by third-party lending sites to assess creditworthiness. The API required minimal personal information (e.g., name, address, birthdate) to authenticate requests and returned detailed personal data, making it a classic case of a leaky API with weak authentication controls.

4. Unpatched Vulnerabilities

Cloud workloads (VMs, containers, apps) may run outdated software:

• Operating system vulnerabilities, such as using outdated AMI images

• Container misconfigurations, like running containers with root privileges

• Unpatched third-party dependencies that introduce known security flaws

• Container escape vulnerabilities which allow attackers to break out of the container and access the host system.

5. Lack of Data Protection

Lastly, Cloud environments have large volumes of data from customer data and application data; additionally, some of this data is sensitive data such as PII(Personally Identifiable Information. If all of these are not properly configured, then this flaw becomes a prime target for threat actors.

Common flaws that could cause data breaches :

• Unencrypted data at rest or in transit

• No access controls on backups

• Weak key management

How to Protect Your Cloud Environment

Below are some best practices and practical ways to prevent cloud security flaws. Most environments have a Cloud Security Program with robust capabilities, including governance, processes, and best practices for cloud security. Be sure to check with all cloud vendors for their Well-Architected Frameworks, which guide the creation of secure resources to prevent security flaws.

• Implement the Principle of Least Privilege.

• Provide users and services only with the access they require.

• Use CSPM (Cloud Security Posture Management) tools like:

  • AWS Security Hub

  • Wiz

  • Upwind

• Ensure data encryption in transit and at rest.

• Use cloud-native KMS (Key Management Services) to manage keys.

• Use hardened base images.

• Keep OS, containers, and dependencies up to date.

• Regularly train devs and engineers on secure cloud practices.

• Build security into your CI/CD pipelines (DevSecOps).

CloudWatch Logs retention is an important part of AWS security compliance that is often missed. When log groups are set to "Never Expire," organizations face several major risks:

The Risks of Unlimited Log Retention

1. Uncontrolled Cost Growth: With no expiration policy, logs accumulate indefinitely, leading to steadily increasing storage costs that can spiral out of control over time.

2. Audit Non-Compliance: Many compliance frameworks require specific data retention periods, neither too short nor too long. Indefinite retention may violate regulatory requirements for data deletion.

3. SIEM Data Volume Overload: Security Information and Event Management systems can become overwhelmed with excessive historical data, potentially degrading performance and increasing processing costs.

Now that we understand the risks of logs that never expire and how they violate compliance, there is usually a recommendation after the assessment on how to fix this according to best practices.

It's important to know that different environments have different framework controls and security best practices. Some environments might have a Record Retention Policy set to (Calendar Year +1), while others might be more than 90 days. In this lab, we will set it to 365 days of retention.

Implementing Automated Log Retention

Let's explore how to implement proper CloudWatch Log retention on existing logs using both AWS CLI and a Python boto3 Lambda function.

Option 1: AWS CLI Remediation

You can use the AWS CLI to identify log groups without retention policies and set appropriate retention periods:

aws logs describe-log-groups \
  --query "logGroups[?retentionInDays==null].logGroupName" \
  --output text

If you have JQ installed on your local machine, you can use the AWS CLI query below instead of the one above.

aws logs describe-log-groups --query "logGroups[?retentionInDays==null].logGroupName" | jq

The screenshots above show a list of CloudWatch Logs without a 365-day retention period. Now, we will select one of the logs and run the next CLI command to change it to 365 days.

aws logs put-retention-policy   --log-group-name "/aws-athena/Spark_primary"   --retention-in-days 365

Option 2: Lambda Function with Boto3

For a more automated approach, we can create a Lambda function that runs on a schedule. In this lab, we'll use a simple execution Lambda, but I will provide a GitHub repository with the automated method.

Go to your AWS console, navigate to Lambda functions, and create a function using the Python runtime. Set your IAM role with permissions for CloudWatch. Paste the code below into your Lambda function and execute it.

import boto3

def lambda_handler(event, context):
    client = boto3.client('logs')
    paginator = client.get_paginator('describe_log_groups')

    for page in paginator.paginate():
        for lg in page['logGroups']:
            if lg.get('retentionInDays') is None:
                client.put_retention_policy(
                    logGroupName=lg['logGroupName'],
                    retentionInDays=365
                )
                print(f" Set 365-day retention for {lg['logGroupName']}")

Below is the output from the executed Lambda function:

Conclusion

Implementing proper CloudWatch Log retention is a crucial security and cost management practice. By setting appropriate retention periods:

• You gain predictable and controlled costs

• You maintain compliance with audit requirements

• You prevent SIEM systems from being overwhelmed with excessive data

Over the three days, I gained a deeper understanding of AWS security, reconnected with familiar faces who have become like family, and welcomed new professionals into the alumni circle.

Grateful for the hallway conversations, fireside sessions, and insights from AWS security leaders Mark Young & Chris Haggard — your guidance continues to shape the way we build securely

Highlights worth mentioning:
ACM for external servers — AWS Certificate Manager now supports exportable public SSL/TLS certificates for secure TLS traffic termination across AWS, hybrid, and multi-cloud workloads.

Security Hub — AWS Security Hub has been enhanced to transform security signals into actionable insights. The new enhancement provides comprehensive visibility across your cloud environment, including the ability to create Jira/ServiceNow tickets for identified findings while reducing the complexity of managing resource misconfiguration.

Beyond the sessions, it was great spending quality time with old friends Shammah Una, Adebayo BALOGUN, CISSP, FIP, Aminat Usman, Kudakwashe Manhondo, Blessing Idio, Charity Kemei, Sharanya Sisodia, and meeting brilliant new minds Shakirah Odedina, Kamorudeen Amuda,

Cole O'Shaughnessy from Chainguard, thank you so much for taking the time to connect - it was great meeting you

Lastly, we explored a bit of Philadelphia’s charm together. This wasn't the first time, and it certainly won't be the last. I'm always proud to be part of a community that's passionate about building securely and supporting each other.

hashtag#AWS hashtag#reInforce2025 hashtag#CloudSecurity hashtag#CyberSecurity hashtag#AWSCommunityBuilder

When launching a new application, one of the most critical decisions is selecting the right AWS region. Should it be in North America, South America, Europe, or Asia? The answer? It depends!

Here are some key factors to consider when making this decision:

🔒 Compliance and Governance

Governments often require data to stay within the country or region where the application is deployed. Ensuring compliance with local regulations is a must when choosing a region.

⏱️ Latency

If your users are primarily located in a specific geographic area, deploying your application in a region close to them can significantly reduce latency and improve user experience. For example, if your customers are in North America, hosting your app there makes the most sense.

🛠️ Resource Availability

Not all AWS services are available in every region. If your application relies on a specific service that’s only available in certain regions, then that will heavily influence your decision 💁

💰 Pricing

Costs can vary significantly between regions. Pricing for some services may differ, so it’s worth evaluating which region offers the best balance of cost and performance for your needs.

Choosing the right region is a decision that can impact your application’s performance, compliance, and cost. So, what factors have influenced your region selection in the past?

Let’s discuss it! 👇

#AWS #TechStrategy #ApplicationDevelopment #CloudInfrastructure 🌍 🚀

These credentials would then be stored in GitHub as secrets to enable the Actions workflow. However, this approach posed significant security risks. The stored secrets could remain valid indefinitely, often exceeding the recommended 90-day rotation period for credentials.

If compromised, especially if the credentials have elevated permissions, then malicious actors could exploit them to deploy unauthorized resources like crypto miners or access sensitive data, leading to severe security breaches.

With the integration of GitHub Actions and OpenID Connect (OIDC), Deploying resources to AWS will become more secure. This publication walks you through deploying an S3 bucket to AWS using GitHub Actions and OIDC.

What Is OpenID Connect (OIDC)?

OIDC allows GitHub Actions to securely authenticate with AWS without relying on long-lived access keys. Instead, it leverages temporary credentials granted via an identity provider (IdP) trust relationship between AWS and GitHub.

This approach:

• Reduces the risk of credential exposure.

• Simplifies authentication management.

• Facilitates least-privilege access with short-lived tokens.

Prerequisites:

1. An AWS account with IAM permission to create an S3 Bucket.

2. Basic understanding of creating an AWS IAM role and its functionality.

3. Basic understanding of GitHub Actions.

4. Basic Understanding of OIDC OpenID Connector

5. GitHub repository for your project. Here is my Repository for this project

NOTE:

I’ve outlined two methods for configuring the OIDC Identity provider and connecting it to an IAM role in AWS. The first involves using the Management console, while the second involves utilizing a CloudFormation template provided in the subsequent steps below.

Step 1: Configure AWS OIDC Identity Provider

Create an Identity Provider in AWS:

• Log in to AWS Management Console:

• Go to the IAM Service:

• Select Identity Providers:

• Click on Add Provider

• Choose OpenID Connect, then add Provider Url and Audience. By default, this information is the same for everyone, as GitHub/AWS provides it.

For the provider URL: Use https://token.actions.githubusercontent.com

For the Audience Use sts.amazonaws.com

• FAQs - To add the GitHub OIDC provider to IAM, see the AWS documentation & official GitHub page action

Create an IAM Role for GitHub Actions:

Now that we've set up the Identity provider, we’ll create an IAM role with the specific permissions we want our GitHub action to have. We’ll also specify the name of the GitHub repository to which the role will grant permission. Finally, we’ll link the Identity provider to the IAM role we created.

• Click to open the created identity provider

• Click on the Assign Role button at the right corner of the screen

Choose Create a new role

Select “Web identity” as the trusted entity type. Then, fill out the form fields:

- GitHub organization

- GitHub repository

Click on NEXT.

• Attached the required permission. In our use case, we will attach S3 full access permission.

• Click on NEXT.

Provide the role name and description, and then click on Create role.

Using CloudFormation for Configuring OIDC Identity Provider in AWS

• Open the CloudFormation Template File in this Repository

• Access the CloudFormation YAML file

Update Role Name

• Look for the section defining the IAM role in the template

• Modify the RoleName property to match the desired role name.

Parameters:
  RoleName:
    Type: String
    Default: "YourUpdatedRoleName"
    Description: Name of the IAM role to be created

Update Repository Name

• Locate the parameter, resource, or property specifying the repository name.

• Replace it with the appropriate repository name.

# GitHub repository name in format owner/repo
  RepoName:
    Type: String
    Default: "YourUpdatedRepoName"
    Description: GitHub repository name in format owner/repo

Save the Changes

• Save the modified CloudFormation file locally.

Deploy the CloudFormation Template

• Use the AWS Management Console, AWS CLI, or AWS SDKs to deploy the template.

You have successfully deployed your CloudFormation stack! Everything is now set up, and your resources should be ready to use.

Step 2: Write Your GitHub Actions Workflow

In the repository below, you’ll find the GitHub action workflow and a README file that explains how the GitHub action works and how to create your own.

• Workflow

• ReadMe

Workflow Code

Create a new file .github/workflows/s3-deploy.yml in your repository with the following content:

name: Deploy AWS S3 Bucket with OIDC authentication

on:
  push

env:
  AWS_REGION : "us-east-1"
  AWS_ROLE_TO_ASSUME: "arn:aws:iam::{YOUR-AWS-ACCOUNT-ID}:role/github-actions-s3-oidc-role-dev"
  REPOSITORY_NAME: "${{ github.actor }}"
  BUCKET_NAME: "${{ github.actor }}-oidc-test-bucket"

permissions:
      id-token: write   # This is required for requesting the JWT
      contents: read    # This is required for actions/checkout

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ env.AWS_ROLE_TO_ASSUME }}
          role-session-name: s3-deploy-action-session
          aws-region: ${{ env.AWS_REGION }}

      - name: Check if bucket exists
        id: check_bucket
        run: |
          if aws s3api head-bucket --bucket ${{ env.BUCKET_NAME }} 2>/dev/null; then
            echo "Bucket ${{ env.BUCKET_NAME }} already exists"
            echo "bucket_exists=true" >> $GITHUB_OUTPUT
          else
            echo "Bucket ${{ env.BUCKET_NAME }} does not exist"
            echo "bucket_exists=false" >> $GITHUB_OUTPUT
          fi

      - name: Create S3 bucket
        if: steps.check_bucket.outputs.bucket_exists == 'false'
        run: |
          aws s3api create-bucket \
            --bucket ${{ env.BUCKET_NAME }} \
            --region ${{ env.AWS_REGION }} \
            $(if [ "${{ env.AWS_REGION }}" != "us-east-1" ]; then echo "--create-bucket-configuration LocationConstraint=${{ env.AWS_REGION }}"; fi)

          echo "Configuring bucket settings..."

          aws s3api put-bucket-versioning \
            --bucket ${{ env.BUCKET_NAME }} \
            --versioning-configuration Status=Enabled

          aws s3api put-bucket-encryption \
            --bucket ${{ env.BUCKET_NAME }} \
            --server-side-encryption-configuration '{
              "Rules": [
                {
                  "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "AES256"
                  }
                }
              ]
            }'

      - name: Configure bucket public access
        if: steps.check_bucket.outputs.bucket_exists == 'false'
        run: |
          aws s3api put-public-access-block \
            --bucket ${{ env.BUCKET_NAME }} \
            --public-access-block-configuration \
              "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Workflow Overview

The workflow triggers on every push and performs the following operations:

1. Authenticates with AWS using OIDC

2. Check if the specified S3 bucket exists

3. Creates a new bucket if it doesn't exist

4. Configures bucket security settings and encryption

Configuration Requirements

AWS IAM Role Setup

You need to replace the AWS_ROLE_TO_ASSUME environment variable with your IAM role ARN. Your role ARN should look similar to:

arn:aws:iam::{YOUR-AWS-ACCOUNT-ID}:role/github-actions-s3-oidc-role-dev

Step 3: Test the Workflow

1. Commit and push the changes to your main branch.

2. Go to the Actions tab in your GitHub repository to monitor the workflow execution.

3. Verify the S3 bucket creation in the AWS Management Console.

Key Benefits of Using OIDC with GitHub Actions

• Enhanced Security: Eliminates the need for long-term AWS credentials in GitHub Secrets.

• Scalability: Easily manage permissions for multiple repositories.

• Cost-Effective: Automates deployment without additional infrastructure.

Conclusion

By leveraging GitHub Actions with OIDC, you can build secure, streamlined CI/CD pipelines to deploy resources like S3 buckets to AWS. This setup not only reduces complexity but also ensures your workflows adhere to modern security best practices.

Next Steps

Try extending this workflow to deploy additional AWS resources, such as Lambda functions or DynamoDB tables, and explore the power of GitHub Actions in simplifying cloud deployments.

Congratulations !!!! Feel free to share your thoughts or ask questions about this guide!

Choose Your Project:

• Static website using S3 and CloudFront

• Deploy a serverless application

• Set up a multi-region architecture

• Build a CI/CD pipeline(Github Action)

• Deploy an Nginx Docker container in the EC2 instance

• Learn AWS Well-Architected Framework

• Create a cost optimization dashboard

• Design a disaster recovery solution

• Or use your imagination and design your own!

Lastly 🚨 Watch your costs 💰 👀👀👀

Fast forward to now, I just wrapped up an amazing five days at AWS re: Invent in Las Vegas. This event was a whirlwind of innovation and networking, from keynote sessions and fireside talks to learning and mentoring sessions. I even had the chance to chat with top AWS executives during mentoring sessions.

Beyond the conference, some friends and I at the event explored some iconic Las Vegas spots, like the Las Vegas Sphere, Fountain of Bellagio, and AREA15, making this trip unforgettable.

These experiences have enriched my journey as a security engineer, and I’m thrilled to apply my knowledge. Below, I’ve curated a list of top security announcements that I believe are worth sharing.

Top security, identity, and compliance announcement at AWS re:invent Las Vegas.

AWS Security Incident Response

Security Incident Response integrates with detection services and third-party tools to streamline incident response, saving time and enabling faster coordination. The service offers centralized incident management, preconfigured response teams, and real-time monitoring.

Amazon GuardDuty Extended Threat Detection

Amazon GuardDuty Extended Threat Detection uses AI and machine learning to identify sophisticated attacks targeting AWS accounts, workloads, and data. This new capability automatically correlates security signals to detect attack sequences and provides detailed findings for faster response.

Amazon OpenSearch Service zero-ETL integration with Amazon Security Lake

This integration enables efficient exploration of voluminous data sources, streamlining security investigations and providing comprehensive security landscape visibility. It offers flexible data ingestion, pre-built queries and dashboards, and performance-enhancing features, accelerating investigations and optimizing analytics efficiency and costs.

Simplify governance with declarative policies.

Declarative policies help enforce desired configurations for AWS services across organizations, ensuring compliance and reducing complexity. They can be applied at the organization, OU, or account level and prevent non-compliant actions, even those invoked by service-linked roles.

#AWS hashtag#reInvent hashtag#CloudSecurity hashtag#ContinuousLearning

What is AWS ECS and Fargate?

AWS ECS (Elastic Container Service) is a highly scalable, high-performance container management service that supports Docker containers and allows you to run applications on a managed cluster of servers. Fargate, on the other hand, is a serverless compute engine for containers that work with ECS, removing the need to manage servers or clusters. Additionally, you can deploy ECS on an EC2 instance, however you would need to manually manage the servers or cluster.

Why are we deploying NGINX? NGINX is a popular open-source web server known for its high performance, stability, and rich feature set. It's often used for load balancing, reverse proxying, and as a web server.

Prerequisites

• An AWS account with permission to use ECS

• AWS CLI installed

• Basic understanding of Docker, NGINX, and AWS AWS ECS

Step 1: Create an ECS Cluster:

A cluster is a logical grouping of your ECS resources, you would need a cluster to deploy a container. in this post, we will be using the default vpc for the cluster

To create a cluster Through AWS CLI aws ecs create-cluster --cluster-name nginx-application

To Create a cluster via AWS Console

Log in to your AWS Management Console, Navigate to the ECS service, and select “Clusters”. Create a new cluster

Step 2: Register task definition:

A Task Definition in AWS ECS is a blueprint for running containers, specifying details like container images, CPU and memory allocation, environment variables, and networking settings.

To Create a task definition via AWS Console

• Go to the Task Definitions page on the ECS console.

• Create a new task definition and select “Fargate” as the launch type.

• Configure the task with the required settings like task size (CPU and memory).

• Add a container definition for your NGINX server. Here, you'll specify the image for NGINX (you can use the official NGINX image from Docker Hub).

Step 3: Configure and Launch the Service

A service in AWS ECS creates a task by instantiating a task definition, where a task represents a running container. The service is responsible for managing and maintaining the container's desired state and scalability.

To Create a Service via AWS Console

• Return to your ECS cluster and select “Services”.

• Create a new service and select the task definition you created.

• Configure the service - set the number of desired tasks, and network and security settings.

• Launch the service. AWS Fargate will start and manage the containers for you.

Step 4: Access the NGINX Application

• Find the public IP of your running task (available in the task details in the ECS console).

• Access NGINX by entering the public IP in your web browser. You should see the NGINX welcome page.

Docker containers, Images, and everything about Microservices have gained so much popularity in different industry domains, due to their persistent nature.

This article shows you how to do the following:

• How to create an EC2 instance

• SSH into an EC2 instance

• Install Docker Desktop on an EC2 instance

• Run a container application on an EC2 instance

Step 1: Create/Provision an EC2 Instance

AWS offers several ways to create EC2 instances, such as using the console, CLI, CDK, Python boto3, CloudFormation, and Terraform. For simplicity in this lab, we will use the console.

Access EC2 in the AWS Console
In the AWS Management Console, search for EC2 and select the service. Click "Launch Instance" to begin creating a new virtual server.

Choose an Amazon Machine Image (AMI)
Select an Amazon Linux AMI, which comes with pre-configured settings for your OS and application environment. For this lab, we will choose the Amazon Linux OS.

Select an Instance Type
For small-scale applications or testing, a t2.micro instance is a cost-effective option.

Configure Security Group
Set up a security group to manage traffic to your instance. Add rules to allow:

• HTTP (port 80) & Port 8080 (We will use this for the container host port )

• HTTPS (port 443)

Create a Key Pair
Generate and download a secure SSH key pair. You'll use this to remotely access your EC2 instance. Store the private key file in a secure location.

Launch the Instance
Once the above steps are complete, launch your instance. After deployment, go to the EC2 Instances page to find your instance’s public IP address.

Step 2: Install Docker on your EC2 Instance

NOTE: This section of the lab assumes that you are now familiar with Provisioning EC2 Instances and can manage EC2 Instances.

Connect to Your EC2 Instance via SSH

Use your terminal (Mac/Linux) or an SSH client (like PuTTY for Windows) to connect:

From your terminal, go to the directory where your EC2 key pair was downloaded. In this lab, my key pair is named. docker-container.pem After that, run the following command:

NOTE: Replace the below IP Address with your EC2 instance's Public IPv4 address

chmod 400 docker-container.pem
ssh -i docker-container.pem ec2-user@13.222.94.175

Install Docker on EC2

• When you SSH into your EC2 Instance and establish a connection, then update the package manager index by running the following commands in white color:

sudo yum update -y

• Install the Docker package by running the following command:

sudo yum install docker

• Start and enable the Docker service by running the following command:

sudo systemctl start docker
sudo systemctl enable docker

• Add your EC2 instance user to the Docker group. This will let you run Docker commands without getting access denied errors.

You'll need to log out and back in for group changes to take effect.

sudo usermod -aG docker ec2-user

• Verify that Docker is running by running the following command:

sudo service docker status

You should see something like the below output

After completing the steps above, Docker should be installed and running on your Amazon EC2 instance. You can now use Docker to run and manage containers on your EC2 instance.

Step 3: Run a Docker Container

Great job so far! You've successfully created an instance, connected via SSH, and installed Docker Desktop on the instance. Now, we're at the final part of this lab: running a sample NGINX Docker container. P.S.: To learn more about Docker and Docker containers, please visit the Docker-wiki-page.

• Let’s run an NGINX container on port 8080 and name it my-nginx-container:

docker run -d --name my-nginx-container -p 8080:80  nginx

Let me break down the above command

• -d Runs the container in detached mode (in the background)

• —name allows you to name your container whatever you prefer. In this lab, my container is namedmy-nginx-container:

• -p 8080:80 maps the instance’s port 8080 to the container’s port 80

You can now open a browser and visit your EC2 instance's public IP with port 8080 to see the NGINX welcome page. Here is my URL: http://13.222.94.175:8080 By the time you read this, I will have disconnected the EC2 instance.

Here are some useful Docker commands to monitor and manage your container:

• List Running Containers docker ps

• List all Containers, including stopped containers : docker ps -a

• Stop the Container: docker stop my-nginx-container

• Start the Container Again: docker start my-nginx-container

• Restart the Container: docker restart my-nginx-container

Yay! Congratulations, you have just completed this lab.