Forem: Oluwasegun Adedigba

Non-functional Application Requirements: Compliance

Oluwasegun Adedigba — Tue, 25 Nov 2025 12:58:58 +0000

Compliance isn't just a checkbox. It's the difference between a thriving business and a company facing €1.2 billion in fines. In 2023, Meta paid that staggering amount for GDPR violations related to improperly transferring user data from the EU to the U.S. Meanwhile, healthcare organizations faced $4.75 million settlements for HIPAA failures, and retailers continued paying for breaches years after they occurred.

Understanding compliance isn't optional anymore. It's the foundation of sustainable software development. Whether you're building a healthcare app, processing payments, or launching a SaaS platform, compliance requirements shape your architecture, influence your cloud provider choices, and directly impact your bottom line.

This article breaks down what compliance really means, why it matters more than ever, and exactly how to implement it using AWS services before you become the next cautionary tale.

What: Understanding Compliance Frameworks and Requirements

Compliance represents your legal and contractual obligation to handle data according to specific regulatory standards. Unlike optional best practices, compliance failures result in mandatory fines, lawsuits, and business shutdowns. Modern applications typically need to comply with multiple frameworks simultaneously. A healthcare SaaS might need HIPAA, GDPR, and SOC 2 compliance all at once.

The Major Compliance Frameworks

1. GDPR (General Data Protection Regulation)

Scope: Any organization processing personal data of EU residents, regardless of company location.

Key Requirements:

Lawful Basis for Processing: You must have a valid legal reason to process personal data (consent, contract, legitimate interest, etc.)
Data Subject Rights: Users can request access, deletion, portability, and rectification of their data
Privacy by Design: Data protection must be built into systems from the start
Breach Notification: Must notify authorities within 72 hours of discovering a breach
Data Protection Officer (DPO): Required for organizations processing data at scale

Real-World Violation: In May 2023, Ireland's Data Protection Commission fined Meta €1.2 billion for transferring EU user data to the U.S. without adequate safeguards. This remains the largest GDPR fine ever imposed. More recently, in 2024, the Dutch DPA fined Uber €290 million for transferring sensitive driver data from the EU to the US without proper transfer mechanisms after they stopped using Standard Contractual Clauses in 2021.

2. HIPAA (Health Insurance Portability and Accountability Act)

Scope: U.S. healthcare providers, health plans, healthcare clearinghouses, and their business associates.

Key Requirements:

Privacy Rule: Establishes standards for protecting individuals' medical records and personal health information (PHI)
Security Rule: Requires administrative, physical, and technical safeguards to protect electronic PHI (ePHI)
Breach Notification Rule: Mandates notification to affected individuals, HHS, and sometimes the media
Risk Analysis: Organizations must conduct thorough security risk assessments
Business Associate Agreements (BAAs): Required contracts with any vendor handling PHI

Real-World Violation: In February 2024, Montefiore Medical Center settled with HHS for $4.75 million following a malicious insider cybersecurity investigation. The breach occurred when an employee stole and sold the protected health information of 12,517 patients. This case highlighted that threats don't just come from external hackers. Insider threats require equally rigorous controls.

3. PCI DSS (Payment Card Industry Data Security Standard)

Scope: Any organization that stores, processes, or transmits cardholder data.

Key Requirements:

Build and Maintain a Secure Network: Install firewalls and don't use vendor-supplied defaults
Protect Cardholder Data: Encrypt transmission and storage of cardholder data
Maintain a Vulnerability Management Program: Use and regularly update antivirus, develop secure systems
Implement Strong Access Control Measures: Restrict access on a need-to-know basis
Regularly Monitor and Test Networks: Track and monitor all access, regularly test security systems
Maintain an Information Security Policy: Create comprehensive security policies for personnel

Real-World Violation: In 2013, Target suffered one of the most infamous PCI compliance breaches when hackers stole 40 million credit card numbers. Despite having a $1.6 million malware detection tool in place, Target missed critical warnings for three weeks. The result? An $18.5 million multi-state settlement, over $202 million in total costs, and lasting reputational damage.

4. SOC 2 (System and Organization Controls 2)

Scope: Service organizations that store customer data in the cloud.

Key Requirements (Trust Service Criteria):

Security: Protection against unauthorized access
Availability: System accessibility as contractually agreed
Processing Integrity: System processing is complete, valid, accurate, timely, and authorized
Confidentiality: Information designated as confidential is protected
Privacy: Personal information is collected, used, retained, disclosed, and disposed of properly

Business Impact: Many enterprise organizations won't even consider vendors without SOC 2 Type II certification. A failed audit can mean losing major deals and damaging your market position.

5. ISO 27001

Scope: Any organization seeking to establish, implement, maintain, and continually improve an information security management system (ISMS).

Key Requirements:

Risk Assessment: Identify and assess information security risks
Risk Treatment: Implement controls to address identified risks
Documentation: Maintain comprehensive documentation of the ISMS
Internal Audits: Regular internal audits of the ISMS
Management Review: Senior management oversight and commitment
Continuous Improvement: Ongoing enhancement of the ISMS

Business Impact: ISO 27001 certification is often required for government contracts and enterprise partnerships, particularly in Europe and internationally.

6. CCPA/CPRA (California Consumer Privacy Act/California Privacy Rights Act)

Scope: Businesses collecting personal information of California residents meeting certain thresholds.

Key Requirements:

Right to Know: Consumers can request what personal information is collected
Right to Delete: Consumers can request deletion of their personal information
Right to Opt-Out: Consumers can opt out of the sale of their personal information
Right to Correct: Consumers can request correction of inaccurate information (CPRA)
Right to Limit Use: Consumers can limit use of sensitive personal information (CPRA)

Why: The Critical Importance of Compliance

Security isn't just a "nice-to-have" feature. It's essential. Let's consider why a robust compliance strategy is non-negotiable:

Financial Impact

The numbers tell a compelling story:

€5.88 billion: Total GDPR fines issued since 2018 through 2025
€1.2 billion: Single largest GDPR fine (Meta, 2023)
$4.88 million: Average cost of a data breach globally in 2024 (IBM)
$174,000: Additional average cost for non-compliant organizations per breach
10%: Year-over-year increase in breach costs, the highest total ever recorded

For payment processing, the stakes are equally high:

$5,000 - $100,000/month: Typical PCI non-compliance penalties
$50 - $90 per customer: Additional fines per affected individual after a breach
Revoked merchant license: The ultimate penalty, losing the ability to accept credit cards entirely

Trust and Reputation

A single data breach can erode user trust for years. The reputational damage leads to:

Customer churn and loss of market share
Media fallout and public relations crises
Difficulty attracting enterprise customers
Challenges in recruiting top talent
Investor concern and reduced valuations

When TikTok faced its €530 million GDPR fine in 2025 for transferring EU user data to China without adequate safeguards, the damage extended far beyond the financial penalty. The investigation revealed that engineers in China routinely accessed sensitive information of European users. That revelation intensified regulatory scrutiny and user concern globally.

Operational Stability

Insecure, non-compliant applications are more vulnerable to:

Cyber attacks that cause downtime and data loss
Ransomware incidents that halt operations
Regulatory investigations that consume resources
Mandatory forensic examinations after breaches
Court-ordered operational changes

The Compound Effect

When compliance is compromised, it's not just a technical issue. It's a business crisis. Consider LinkedIn's 2024 experience: the Irish DPC fined them €310 million for processing user data for behavioral analysis and targeted advertising without a valid legal basis. The company not only paid the fine but was ordered to bring its data processing into compliance, requiring significant technical and operational changes.

When: Embedding Compliance from Day One

In today's rapid development environments, compliance needs to be part of the design and development process from the outset. The earlier compliance is embedded, the less costly it is to manage and mitigate issues later. This "shift-left" approach focuses on integrating compliance practices throughout the entire development lifecycle.

Key Stages to Integrate Compliance

Design Phase

Data Flow Mapping: Document what data you collect, where it's stored, how it flows through your system, and who has access
Compliance Requirements Analysis: Identify which frameworks apply to your business based on geography, industry, and data types
Privacy Impact Assessments: Evaluate how new features or systems might affect user privacy
Architecture Decisions: Choose infrastructure and services that support compliance requirements (e.g., data residency)

Development Phase

Secure Coding Practices: Implement encryption, input validation, and secure authentication from the start
Data Minimization: Collect only the data you actually need
Access Controls: Build role-based access control (RBAC) into your application
Audit Logging: Implement comprehensive logging of data access and modifications
Configuration as Code: Use infrastructure as code to ensure consistent, compliant deployments

Testing and QA Phase

Compliance Testing: Automated checks for compliance with relevant standards
Penetration Testing: Regular security assessments to identify vulnerabilities
Data Protection Testing: Verify encryption, access controls, and data handling procedures
Audit Trail Verification: Ensure all required events are being logged correctly

Deployment and Operations Phase

Continuous Monitoring: Real-time compliance posture assessment
Automated Remediation: Immediate response to compliance drift
Incident Response Plans: Documented procedures for breach notification and handling
Regular Audits: Scheduled compliance assessments and certifications

The Cost of Delay

Addressing compliance after the fact is exponentially more expensive:

Design phase fix: ~1x cost
Development phase fix: ~6x cost
Testing phase fix: ~15x cost
Production fix: ~100x cost

By shifting compliance left, you address potential issues early, reducing the risk of costly fixes, regulatory penalties, and reputational damage down the road.

Where: Leveraging AWS Compliance Services

AWS offers a comprehensive suite of services that cover different aspects of application compliance. Let's explore the key tools and how they work together to create a robust compliance infrastructure.

AWS CloudTrail: Your Audit Log Foundation

CloudTrail is the foundational service for compliance on AWS. It records all API activity across your AWS infrastructure, providing an immutable audit log that's essential for compliance.

Key Features:

Comprehensive Logging: Captures API calls from the console, CLI, SDKs, and other AWS services
Event History: 90 days of management events free, with trails for longer retention
CloudTrail Lake: Enables SQL-based querying of event data for investigations
Integrity Validation: Log file integrity validation ensures logs haven't been tampered with

Compliance Value:

Satisfies audit logging requirements for HIPAA, PCI DSS, SOC 2, and GDPR
Provides evidence for security investigations and incident response
Enables detection of unauthorized access or suspicious activity

# Example: Creating a CloudTrail trail with log file validation
import boto3

cloudtrail = boto3.client('cloudtrail')

response = cloudtrail.create_trail(
    Name='compliance-trail',
    S3BucketName='your-audit-logs-bucket',
    IncludeGlobalServiceEvents=True,
    IsMultiRegionTrail=True,
    EnableLogFileValidation=True,
    KMSKeyId='your-kms-key-arn'  # Encrypt logs at rest
)

AWS Config: Continuous Configuration Assessment

AWS Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of configurations against desired compliance rules.

Key Features:

Configuration Recording: Tracks resource configurations over time
Config Rules: Define rules that evaluate configurations against compliance requirements
Conformance Packs: Collections of rules mapped to compliance standards (PCI DSS, HIPAA, etc.)
Automatic Remediation: Trigger automated fixes when resources drift from compliance

Pre-Built Conformance Packs:

AWS Operational Best Practices for PCI DSS 3.2.1
AWS Operational Best Practices for HIPAA
AWS Operational Best Practices for GDPR
AWS Operational Best Practices for CIS AWS Foundations Benchmark

# Example: AWS Config Rule for S3 bucket encryption
Resources:
  S3BucketEncryptionRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-server-side-encryption-enabled
      Description: Checks whether S3 buckets have server-side encryption enabled
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket

AWS Security Hub: Centralized Security Posture Management

Security Hub aggregates findings from multiple AWS security services and third-party tools, providing a comprehensive view of your security and compliance posture.

Key Features:

Automated Security Checks: Continuous compliance evaluation against industry standards
Finding Aggregation: Centralized view from GuardDuty, Inspector, Config, and third-party tools
Security Score: At-a-glance view of overall compliance status
Cross-Account Visibility: Aggregate findings across your entire AWS organization

Supported Compliance Standards:

CIS AWS Foundations Benchmark (v1.2.0, v1.4.0, v3.0.0)
AWS Foundational Security Best Practices
PCI DSS v3.2.1
NIST Special Publication 800-53 Revision 5

# Example: Enabling Security Hub with standards
import boto3

securityhub = boto3.client('securityhub')

# Enable Security Hub
securityhub.enable_security_hub(
    EnableDefaultStandards=False
)

# Enable specific standards
securityhub.batch_enable_standards(
    StandardsSubscriptionRequests=[
        {
            'StandardsArn': 'arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0'
        },
        {
            'StandardsArn': 'arn:aws:securityhub:::ruleset/pci-dss/v/3.2.1'
        }
    ]
)

AWS Audit Manager: Automated Audit Evidence Collection

Audit Manager helps you continuously audit your AWS usage and simplify how you assess risk and compliance with regulations and industry standards.

Key Features:

Prebuilt Frameworks: Ready-to-use frameworks for GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001, and more
Automated Evidence Collection: Automatically gathers evidence from CloudTrail, Config, Security Hub
Custom Frameworks: Create frameworks tailored to your specific compliance needs
Assessment Reports: Generate audit-ready reports for stakeholders and auditors

Evidence Types Collected:

Configuration data from API calls
User activity from CloudTrail logs
Compliance check results from Security Hub and AWS Config
Manual evidence uploads for documentation and procedures

# Example: Creating an assessment in Audit Manager
import boto3

audit_manager = boto3.client('auditmanager')

# Create an assessment using the SOC 2 framework
response = audit_manager.create_assessment(
    name='SOC2-Annual-Audit-2025',
    description='Annual SOC 2 Type II audit assessment',
    assessmentReportsDestination={
        'destinationType': 'S3',
        's3BucketName': 'your-audit-reports-bucket'
    },
    scope={
        'awsAccounts': [
            {'id': '123456789012'}
        ],
        'awsServices': [
            {'serviceName': 'S3'},
            {'serviceName': 'EC2'},
            {'serviceName': 'RDS'},
            {'serviceName': 'Lambda'}
        ]
    },
    roles=[
        {
            'roleType': 'PROCESS_OWNER',
            'roleArn': 'arn:aws:iam::123456789012:role/AuditProcessOwner'
        }
    ],
    frameworkId='SOC2-framework-id'  # Use prebuilt SOC 2 framework
)

AWS Artifact: Compliance Documentation Hub

AWS Artifact provides on-demand access to AWS compliance documentation and enables you to manage agreements with AWS.

Key Features:

Compliance Reports: Access AWS SOC reports, PCI DSS attestation, ISO certifications
Agreements: Accept and manage AWS Business Associate Agreement (BAA) for HIPAA
Third-Party Audit Reports: Review independent auditor assessments of AWS
Self-Service Access: Download reports anytime for audit preparation

Available Reports Include:

SOC 1, SOC 2, and SOC 3 Reports
PCI DSS Attestation of Compliance
ISO 27001, 27017, 27018, and 9001 Certifications
FedRAMP Documentation
HIPAA Eligible Services and BAA

AWS Macie: Automated Data Discovery and Protection

Amazon Macie uses machine learning to automatically discover, classify, and protect sensitive data in AWS.

Key Features:

Automated Discovery: Continuously scans S3 buckets for sensitive data
Classification: Identifies PII, PHI, financial data, and custom data types
Security Alerts: Generates findings when sensitive data is at risk
Data Inventory: Provides visibility into what sensitive data exists and where

Compliance Value:

Supports GDPR data mapping requirements
Helps maintain HIPAA PHI inventories
Identifies PCI DSS cardholder data exposure

Layer 1 - CloudTrail (Foundation): Records all API activity
Layer 2 - AWS Config (Configuration): Monitors resource configurations against rules
Layer 3 - Security Hub (Dashboard): Aggregates findings and provides compliance scores
Layer 4 - Audit Manager (Evidence): Collects evidence and generates audit reports

Who: The Roles and Responsibilities in Compliance

Compliance is a shared responsibility. It's not just within your organization but also with your cloud provider. Understanding AWS's Shared Responsibility Model is crucial for compliance success.

The AWS Shared Responsibility Model

AWS is responsible for:

Physical security of data centers
Infrastructure hardware and software
Network infrastructure
Virtualization layer

You are responsible for:

Data encryption and protection
Identity and access management
Network traffic protection
Application security
Operating system and platform configuration
Compliance with specific regulations for your industry

Roles Within Your Organization

Compliance Officers

Define compliance requirements and policies
Coordinate with legal and regulatory bodies
Oversee audit processes and certifications
Report to executive leadership on compliance posture

Cloud Architects and DevOps Engineers

Design compliant architectures
Implement security controls and automation
Configure AWS compliance services
Maintain infrastructure as code for consistent deployments

Developers

Write secure, compliant code
Implement data protection at the application level
Follow secure SDLC practices
Conduct code reviews with security in mind

Security Analysts

Monitor security alerts and compliance dashboards
Investigate potential violations
Respond to incidents
Conduct risk assessments

Data Protection Officers (where required)

Ensure GDPR compliance
Handle data subject requests
Conduct privacy impact assessments
Advise on data protection matters

Building a Compliance Culture

Successful compliance requires more than tools and processes. It requires a culture where everyone understands their role:

Executive Sponsorship: Compliance initiatives must have visible support from leadership
Training Programs: Regular training on compliance requirements and procedures
Clear Ownership: Defined responsibilities for each compliance domain
Incentive Alignment: Ensure security and compliance goals are reflected in team objectives
Continuous Communication: Regular updates on compliance status and changes

Compliance Best Practices: Building a Resilient Application

1. Implement Defense in Depth

Don't rely on a single control. Layer your compliance measures:

Network segmentation and encryption
Application-level access controls
Data encryption at rest and in transit
Comprehensive logging and monitoring

2. Automate Everything Possible

Manual compliance processes don't scale:

Use AWS Config conformance packs for automated evaluation
Implement automated remediation for common issues
Deploy infrastructure as code for consistent, compliant deployments
Schedule automated compliance reports

3. Maintain Comprehensive Documentation

Auditors will ask for evidence:

Document all security policies and procedures
Maintain records of training and awareness programs
Keep evidence of regular reviews and updates
Archive audit logs with integrity verification

4. Plan for Breach Notification

Hope for the best, prepare for the worst:

Create incident response playbooks
Define notification procedures for each regulation
Maintain contact information for regulatory authorities
Practice incident response with tabletop exercises

5. Implement Data Minimization

You can't lose what you don't have:

Collect only the data you need
Implement data retention policies
Securely delete data when no longer needed
Anonymize or pseudonymize where possible

6. Regular Compliance Audits

Don't wait for the external audit to find issues:

Conduct internal audits quarterly
Use AWS Audit Manager for continuous assessment
Address findings promptly
Track remediation progress

7. Monitor Third-Party Risk

Your compliance extends to your vendors:

Require compliance certifications from vendors
Include compliance requirements in contracts
Regular assessment of third-party security
Maintain business associate agreements (BAAs) where required

Conclusion: Compliance as a Competitive Advantage

In an era where data breaches make headlines daily and regulatory scrutiny intensifies, compliance isn't just about avoiding fines. It's a competitive differentiator.

Companies that prioritize compliance:

Win enterprise deals that require SOC 2 and ISO 27001 certifications
Expand globally with confidence in meeting GDPR and regional requirements
Build customer trust through demonstrated commitment to data protection
Reduce risk of costly breaches and regulatory actions
Operate efficiently with automated compliance processes

AWS provides the tools to make compliance manageable and affordable. By combining CloudTrail for audit logging, AWS Config for continuous monitoring, Security Hub for centralized visibility, and Audit Manager for evidence collection, you can build a compliance program that scales with your business.

Remember: The best time to implement compliance was when you started building. The second best time is now.

Cover Image: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels

This article is part of a series on Non-functional Application Requirements. Read the previous articles:

Next up: Accessibility - Designing for Everyone

Provisioning AWS Infrastructure using Terraform and GitHub Actions

Oluwasegun Adedigba — Thu, 02 Oct 2025 12:32:15 +0000

Introduction

Availability, repeatability, and security are table stakes for production workloads. This guide provisions a baseline AWS stack with Terraform that's resilient to AZ failures, enforces least-privilege boundaries, integrates with CI/CD, and manages Terraform state with an S3 and DynamoDB backend. We'll deploy four Apache web servers across two availability zones with a Multi-AZ RDS database, all automated through GitHub Actions.

Why This Matters

Incidents rarely happen at convenient times. You want deterministic deployments, blast-radius isolation, and multi-AZ redundancy so failures degrade gracefully. When one availability zone experiences issues, your application continues running on servers in the healthy zone without any manual intervention.

Equally important is proper Terraform state management. State must be remote rather than stored on a laptop, it must be locked to prevent concurrent modifications, it must be encrypted and versioned for security and recovery, and it should be accessible via IAM rather than passed around in Slack or email. This becomes critical when working in teams or using automated CI/CD pipelines because everyone needs access to the same source of truth about what infrastructure exists.

This article covers both infrastructure resources and state management so you can run with confidence. We'll also set up a complete GitHub Actions pipeline that automatically detects changes to your Terraform code and deploys them, replacing the manual apply process with automated continuous deployment.

What We're Building

The architecture we're building includes these components working together to create a highly available system. We'll provision a VPC with public and private subnets spread across two availability zones in the London region. In the public subnets, we'll deploy four EC2 instances running Apache web servers, with two instances in each availability zone. An Application Load Balancer will distribute incoming traffic across these four servers, automatically routing requests away from any unhealthy instances.

For the database tier, we'll create a Multi-AZ RDS MySQL instance that automatically maintains a standby replica in a different availability zone. If the primary database fails, RDS automatically promotes the standby to become the new primary without requiring any code changes. The database will live in private subnets with no internet access, protected by security groups that only allow connections from the web servers.

For state management, we'll configure an S3 bucket with versioning and encryption to store the Terraform state file, along with a DynamoDB table that provides locking to prevent multiple people or automation pipelines from modifying the infrastructure simultaneously. Finally, we'll set up GitHub Actions workflows that automatically run terraform plan on pull requests so you can review changes, and terraform apply when changes merge to the main branch, giving you the same automation benefits that Jenkins provides but using GitHub's native platform.

Here's what we're deploying:

Networking: VPC, 2 public subnets, 2 private subnets, Internet Gateway, route tables
Compute: 4 Apache web servers across 2 availability zones in an Auto Scaling Group
Ingress: Application Load Balancer with health checks and automatic failover
Data: RDS MySQL Multi-AZ in isolated private subnets
Security: Security groups scoped per role, encrypted storage, IMDSv2 enforcement
State: S3 remote state with DynamoDB locking, versioned and encrypted
CI/CD: GitHub Actions pipeline for automated terraform plan and apply
Observability: CloudWatch metrics and alarms

Prerequisites

Before starting, you'll need Terraform version 1.6 or higher installed on your local machine. You'll also need the AWS CLI configured with an IAM user or role that has permissions to create VPC, EC2, RDS, and S3 resources. While we'll create the S3 bucket and DynamoDB table for state management as our first step, you'll need initial AWS credentials to bootstrap that infrastructure.

You should also have a GitHub account and a repository where you'll store your Terraform code. The GitHub Actions workflows will run directly in your repository, so you'll need to configure AWS credentials as GitHub Secrets to allow the automation to deploy infrastructure on your behalf.

Step 1. Remote State Backend (S3 + DynamoDB)

The first thing we need to do is create the infrastructure that will manage our Terraform state. This is a one-time bootstrap process. We're creating an S3 bucket to store the state file and a DynamoDB table to provide state locking. The bucket will have versioning enabled so you can recover from accidental deletions or corrupted state, and we'll enforce encryption at rest using AES256. We're also blocking all public access to ensure the state file, which may contain sensitive information like database passwords, remains private.

The DynamoDB table uses on-demand billing so you only pay for the lock operations that actually occur, which is minimal. Terraform will write a lock entry to this table whenever someone runs an apply or plan operation, preventing others from making concurrent changes that could corrupt your infrastructure.

Create a file called backend-bootstrap.tf:

# This is a one-time setup file to create the S3 bucket and DynamoDB table
# After running this once, you can delete this file or move it to a separate directory

provider "aws" {
  region = "eu-west-2"
}

# S3 bucket to store Terraform state files
resource "aws_s3_bucket" "state" {
  bucket = "tf-state-prod-stack-eu-west-2"

  # Prevent accidental deletion of the state bucket
  lifecycle {
    prevent_destroy = true
  }
}

# Enable versioning so we can recover from bad state changes
resource "aws_s3_bucket_versioning" "state" {
  bucket = aws_s3_bucket.state.id

  versioning_configuration {
    status = "Enabled"
  }
}

# Encrypt state files at rest for security
resource "aws_s3_bucket_server_side_encryption_configuration" "state" {
  bucket = aws_s3_bucket.state.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# Block all public access to the state bucket
resource "aws_s3_bucket_public_access_block" "state" {
  bucket                  = aws_s3_bucket.state.id
  block_public_acls       = true
  block_public_policy     = true
  restrict_public_buckets = true
  ignore_public_acls      = true
}

# DynamoDB table for state locking to prevent concurrent modifications
resource "aws_dynamodb_table" "lock" {
  name         = "tf-state-locks-prod-stack"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Run this bootstrap process once:

terraform init
terraform apply

After the bucket and table are created, you can delete this bootstrap file or move it to a separate directory. The state infrastructure is now ready to use.

Step 2. Backend Configuration

Now that we have our state storage infrastructure, we need to configure Terraform to use it. We'll create a backend configuration file for each environment. This separation allows you to have different state files for development, staging, and production environments, preventing changes in one environment from affecting others.

Create a directory structure for your environments and add a backend configuration file. For production, create envs/prod/backend.hcl:

bucket         = "tf-state-prod-stack-eu-west-2"
key            = "envs/prod/global.tfstate"
region         = "eu-west-2"
dynamodb_table = "tf-state-locks-prod-stack"
encrypt        = true

In your main Terraform directory, create a main.tf file and add the backend configuration block. Notice that we don't specify the actual bucket name here because we'll pass that in via the backend config file. This allows us to use the same Terraform code across multiple environments:

terraform {
  # Require Terraform version 1.6 or higher
  required_version = ">= 1.6"

  # Backend configuration for remote state storage
  backend "s3" {}

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-2"
}

Initialize Terraform with the backend configuration:

terraform init -backend-config=envs/prod/backend.hcl

Terraform will now store its state remotely in S3 and use DynamoDB for locking. You can verify this worked by checking that Terraform created a .terraform directory with backend configuration.

Step 3. Variables

We need to define variables for values that change between environments or that should not be hardcoded. Database credentials are particularly important to handle as variables because you never want to commit passwords to version control. The sensitive flag ensures these values won't appear in Terraform's output logs.

Create a variables.tf file:

variable "db_username" {
  description = "Database administrator username"
  type        = string
  sensitive   = true
}

variable "db_password" {
  description = "Database administrator password"
  type        = string
  sensitive   = true
}

variable "environment" {
  description = "Environment name used for resource tagging and naming"
  type        = string
  default     = "prod"
}

variable "aws_region" {
  description = "AWS region for resource deployment"
  type        = string
  default     = "eu-west-2"
}

variable "instance_type" {
  description = "EC2 instance type for web servers"
  type        = string
  default     = "t3.micro"
}

variable "db_instance_class" {
  description = "RDS instance class"
  type        = string
  default     = "db.t3.micro"
}

Create a terraform.tfvars file with actual values. This file should never be committed to version control, so add it to your .gitignore:

db_username       = "admin"
db_password       = "YourSecurePasswordHere123!"
environment       = "prod"
aws_region        = "eu-west-2"
instance_type     = "t3.micro"
db_instance_class = "db.t3.micro"

Add this line to your .gitignore:

terraform.tfvars
*.tfvars
.terraform/

For GitHub Actions, we'll pass these values as GitHub Secrets instead of using a tfvars file.

Step 4. Networking Infrastructure

The networking layer is the foundation of your infrastructure. We're creating a VPC with a CIDR block that gives us over 65,000 possible IP addresses, which is more than enough for most applications. We're enabling DNS support and hostnames so that resources within the VPC can resolve each other by DNS names rather than having to use IP addresses.

We'll create two public subnets and two private subnets, with one of each type in each availability zone. The public subnets will host the load balancer and web servers, while the private subnets will host the database. By spreading resources across two availability zones, we ensure that if one entire data center goes offline, our application continues running in the other.

The Internet Gateway provides the connection point between our VPC and the internet. We'll create route tables that define how traffic flows. The public route table will direct internet-bound traffic to the Internet Gateway, while the private route table will have no internet route, keeping the database completely isolated.

Create a network.tf file:

# Fetch available availability zones in the current region
data "aws_availability_zones" "available" {
  state = "available"
}

# Main VPC - this is the container for all our networking resources
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "${var.environment}-vpc"
    Environment = var.environment
  }
}

# Internet Gateway provides internet access for public subnets
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.environment}-igw"
    Environment = var.environment
  }
}

# Public Subnet 1 - hosts ALB and web servers in first AZ
resource "aws_subnet" "public_1" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = data.aws_availability_zones.available.names[0]
  map_public_ip_on_launch = true

  tags = {
    Name        = "${var.environment}-public-1"
    Environment = var.environment
    Type        = "Public"
  }
}

# Public Subnet 2 - hosts ALB and web servers in second AZ
resource "aws_subnet" "public_2" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = data.aws_availability_zones.available.names[1]
  map_public_ip_on_launch = true

  tags = {
    Name        = "${var.environment}-public-2"
    Environment = var.environment
    Type        = "Public"
  }
}

# Private Subnet 1 - hosts RDS in first AZ (completely isolated)
resource "aws_subnet" "private_1" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = data.aws_availability_zones.available.names[0]

  tags = {
    Name        = "${var.environment}-private-1"
    Environment = var.environment
    Type        = "Private"
  }
}

# Private Subnet 2 - hosts RDS in second AZ (completely isolated)
resource "aws_subnet" "private_2" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = data.aws_availability_zones.available.names[1]

  tags = {
    Name        = "${var.environment}-private-2"
    Environment = var.environment
    Type        = "Private"
  }
}

# Route table for public subnets - routes internet traffic to Internet Gateway
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.environment}-public-rt"
    Environment = var.environment
  }
}

# Route that directs all internet-bound traffic to the Internet Gateway
resource "aws_route" "public_internet" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.igw.id
}

# Associate public subnet 1 with the public route table
resource "aws_route_table_association" "public_1" {
  subnet_id      = aws_subnet.public_1.id
  route_table_id = aws_route_table.public.id
}

# Associate public subnet 2 with the public route table
resource "aws_route_table_association" "public_2" {
  subnet_id      = aws_subnet.public_2.id
  route_table_id = aws_route_table.public.id
}

# Route table for private subnets - no internet route, completely isolated
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.environment}-private-rt"
    Environment = var.environment
  }
}

# Associate private subnet 1 with the private route table
resource "aws_route_table_association" "private_1" {
  subnet_id      = aws_subnet.private_1.id
  route_table_id = aws_route_table.private.id
}

# Associate private subnet 2 with the private route table
resource "aws_route_table_association" "private_2" {
  subnet_id      = aws_subnet.private_2.id
  route_table_id = aws_route_table.private.id
}

Step 5. Security Groups

Security groups act as virtual firewalls that control traffic to and from your resources. We're implementing a defense-in-depth strategy where each tier of the application can only communicate with the tiers it needs to. The load balancer accepts traffic from the internet, the web servers accept traffic only from the load balancer, and the database accepts traffic only from the web servers.

This layered security approach means that even if someone discovers the IP address of a web server, they cannot connect to it directly because the security group will reject any traffic that doesn't originate from the load balancer. Similarly, the database is completely inaccessible except from the web servers, even though it exists in the same VPC.

Create a security-groups.tf file:

# Security Group for Application Load Balancer
# Accepts HTTP and HTTPS from the internet, forwards to web servers
resource "aws_security_group" "alb" {
  name        = "${var.environment}-alb-sg"
  description = "Security group for application load balancer"
  vpc_id      = aws_vpc.main.id

  # Allow HTTP from anywhere on the internet
  ingress {
    description = "HTTP from internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow HTTPS from anywhere on the internet
  ingress {
    description = "HTTPS from internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outbound traffic so ALB can forward to web servers
  egress {
    description = "Allow all outbound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "${var.environment}-alb-sg"
    Environment = var.environment
  }
}

# Security Group for Web Servers
# Only accepts HTTP from the load balancer, not directly from internet
resource "aws_security_group" "web" {
  name        = "${var.environment}-web-sg"
  description = "Security group for web server instances"
  vpc_id      = aws_vpc.main.id

  # Only allow HTTP from the load balancer security group
  # This prevents direct access to web servers from the internet
  ingress {
    description     = "HTTP from ALB only"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # Allow all outbound for package updates and external API calls
  egress {
    description = "Allow all outbound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "${var.environment}-web-sg"
    Environment = var.environment
  }
}

# Security Group for RDS Database
# Only accepts MySQL connections from web servers
resource "aws_security_group" "database" {
  name        = "${var.environment}-db-sg"
  description = "Security group for RDS database"
  vpc_id      = aws_vpc.main.id

  # Only allow MySQL from the web server security group
  # Database is completely inaccessible from the internet
  ingress {
    description     = "MySQL from web servers only"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
  }

  tags = {
    Name        = "${var.environment}-db-sg"
    Environment = var.environment
  }
}

Step 6. IAM Roles for EC2

We need to create an IAM role that our EC2 instances will assume. This role grants permissions for AWS Systems Manager Session Manager, which allows you to connect to instances without needing SSH keys or opening port 22. This is a more secure approach because you don't have to manage SSH keys, and all session activity is logged in CloudTrail for audit purposes.

Create an iam.tf file:

# IAM role that EC2 instances will assume
resource "aws_iam_role" "ec2_role" {
  name = "${var.environment}-ec2-role"

  # Trust policy allowing EC2 service to assume this role
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })

  tags = {
    Name        = "${var.environment}-ec2-role"
    Environment = var.environment
  }
}

# Attach AWS-managed policy for Systems Manager access
# This allows SSM Session Manager connections without SSH
resource "aws_iam_role_policy_attachment" "ec2_ssm" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# Instance profile wraps the role so it can be attached to EC2 instances
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "${var.environment}-ec2-profile"
  role = aws_iam_role.ec2_role.name
}

Step 7. Load Balancer and Web Servers

Now we'll create the Application Load Balancer and the Auto Scaling Group with four web servers. The load balancer will perform health checks on each web server, and if a server fails its health check, the load balancer automatically stops sending traffic to it until it becomes healthy again.

The Auto Scaling Group will maintain exactly four instances running at all times, distributed evenly across the two availability zones. If an instance fails or is terminated, the Auto Scaling Group automatically launches a replacement. The user data script installs Apache and creates a simple HTML page that displays the hostname, allowing you to see which server is responding to each request.

Create a compute.tf file:

# Fetch the latest Ubuntu 20.04 AMI
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical's AWS account ID

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

# Application Load Balancer distributes traffic across web servers
resource "aws_lb" "main" {
  name               = "${var.environment}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = [aws_subnet.public_1.id, aws_subnet.public_2.id]

  enable_deletion_protection = false

  tags = {
    Name        = "${var.environment}-alb"
    Environment = var.environment
  }
}

# Target group defines the pool of web servers
resource "aws_lb_target_group" "web" {
  name     = "${var.environment}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  # Health check configuration
  # ALB will mark instances as unhealthy if they fail these checks
  health_check {
    enabled             = true
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 5
    interval            = 30
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200"
  }

  tags = {
    Name        = "${var.environment}-tg"
    Environment = var.environment
  }
}

# HTTP listener on port 80
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web.arn
  }
}

# Launch template defines the configuration for EC2 instances
resource "aws_launch_template" "web" {
  name_prefix   = "${var.environment}-web-"
  image_id      = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  # Attach IAM role for SSM access
  iam_instance_profile {
    arn = aws_iam_instance_profile.ec2_profile.arn
  }

  # Enforce IMDSv2 for enhanced security
  # This prevents SSRF attacks against the instance metadata service
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.web.id]
  }

  # User data script installs Apache and creates a simple test page
  UserData:
          Fn::Base64: !Sub |
            #!/bin/bash
            set -e
            apt-get update
            apt-get install -y apache2
            systemctl enable apache2
            systemctl start apache2
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "${var.environment}-web-server"
      Environment = var.environment
    }
  }
}

# Auto Scaling Group maintains 4 web servers across 2 AZs
resource "aws_autoscaling_group" "web" {
  name                = "${var.environment}-asg"
  vpc_zone_identifier = [aws_subnet.public_1.id, aws_subnet.public_2.id]
  target_group_arns   = [aws_lb_target_group.web.arn]

  # Maintain exactly 4 instances (2 per AZ)
  desired_capacity = 4
  min_size         = 4
  max_size         = 8

  # Use ELB health checks so unhealthy instances are replaced
  health_check_type         = "ELB"
  health_check_grace_period = 300

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }

  tag {
    key                 = "Name"
    value               = "${var.environment}-web-instance"
    propagate_at_launch = true
  }

  tag {
    key                 = "Environment"
    value               = var.environment
    propagate_at_launch = true
  }
}

Step 8. RDS Database

The RDS database will be deployed in Multi-AZ mode, which means AWS automatically maintains a standby replica in a different availability zone. If the primary database fails, RDS promotes the standby to primary automatically, typically within sixty to one hundred twenty seconds. Your application continues working because the database endpoint DNS name stays the same, it just points to the new primary instance.

The database will be completely isolated in the private subnets with no route to the internet. It can only be accessed from the web servers through the security group rules we configured earlier.

Create a database.tf file:

# DB subnet group defines which subnets RDS can use
resource "aws_db_subnet_group" "main" {
  name       = "${var.environment}-db-subnet-group"
  subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]

  tags = {
    Name        = "${var.environment}-db-subnet-group"
    Environment = var.environment
  }
}

# RDS MySQL instance with Multi-AZ for high availability
resource "aws_db_instance" "main" {
  identifier = "${var.environment}-mysql"

  # Database configuration
  engine               = "mysql"
  engine_version       = "8.0.40"
  instance_class       = var.db_instance_class
  allocated_storage    = 20
  storage_type         = "gp3"
  storage_encrypted    = true

  # Multi-AZ creates standby replica in different AZ
  multi_az = true

  # Network configuration
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.database.id]
  publicly_accessible    = false

  # Authentication
  username = var.db_username
  password = var.db_password

  # Backup configuration
  backup_retention_period = 7
  backup_window          = "03:00-04:00"
  maintenance_window     = "mon:04:00-mon:05:00"

  # Disable final snapshot for easier cleanup (change for production)
  skip_final_snapshot = true

  # Enable deletion protection in production
  deletion_protection = false

  tags = {
    Name        = "${var.environment}-mysql"
    Environment = var.environment
  }
}

Step 9. Outputs

Outputs display important information after Terraform completes. We'll output the load balancer DNS name, which is the URL you'll use to access your application, and the database endpoint for connecting your application to the database.

Create an outputs.tf file:

output "alb_dns_name" {
  description = "DNS name of the Application Load Balancer"
  value       = aws_lb.main.dns_name
}

output "alb_url" {
  description = "URL to access the application"
  value       = "http://${aws_lb.main.dns_name}"
}

output "db_endpoint" {
  description = "RDS database endpoint"
  value       = aws_db_instance.main.endpoint
  sensitive   = true
}

output "db_address" {
  description = "RDS database address"
  value       = aws_db_instance.main.address
  sensitive   = true
}

output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

Step 10. GitHub Actions CI/CD Pipeline

Now we'll set up GitHub Actions to automatically deploy infrastructure changes. This replaces Jenkins from the original article but provides the same functionality. When you push changes to your Terraform code, GitHub Actions will automatically run terraform plan to show you what will change. When you merge a pull request to the main branch, it will automatically run terraform apply to deploy those changes.

Create .github/workflows/terraform.yml:

name: 'Terraform CI/CD'

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

env:
  TF_VERSION: '1.6.0'
  AWS_REGION: 'eu-west-2'

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest

    # These permissions are needed for the GitHub token
    permissions:
      contents: read
      pull-requests: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Terraform Format Check
        id: fmt
        run: terraform fmt -check
        continue-on-error: true

      - name: Terraform Init
        id: init
        run: terraform init -backend-config=envs/prod/backend.hcl

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        if: github.event_name == 'pull_request'
        run: |
          terraform plan -no-color -input=false \
            -var="db_username=${{ secrets.DB_USERNAME }}" \
            -var="db_password=${{ secrets.DB_PASSWORD }}"
        continue-on-error: true

      - name: Comment Plan on PR
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
            #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
            #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`

            <details><summary>Show Plan</summary>

            \`\`\`terraform
            ${{ steps.plan.outputs.stdout }}
            \`\`\`

            </details>

            *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`;

            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })

      - name: Terraform Plan Status
        if: steps.plan.outcome == 'failure'
        run: exit 1

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: |
          terraform apply -auto-approve -input=false \
            -var="db_username=${{ secrets.DB_USERNAME }}" \
            -var="db_password=${{ secrets.DB_PASSWORD }}"

Create a destroy workflow at .github/workflows/terraform-destroy.yml:

name: 'Terraform Destroy'

on:
  workflow_dispatch:
    inputs:
      confirm:
        description: 'Type "destroy" to confirm'
        required: true

jobs:
  destroy:
    name: 'Destroy Infrastructure'
    runs-on: ubuntu-latest

    steps:
      - name: Verify Confirmation
        if: github.event.inputs.confirm != 'destroy'
        run: |
          echo "Confirmation failed. You must type 'destroy' to proceed."
          exit 1

      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: '1.6.0'

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-2

      - name: Terraform Init
        run: terraform init -backend-config=envs/prod/backend.hcl

      - name: Terraform Destroy
        run: |
          terraform destroy -auto-approve -input=false \
            -var="db_username=${{ secrets.DB_USERNAME }}" \
            -var="db_password=${{ secrets.DB_PASSWORD }}"

Setting Up GitHub Secrets

In your GitHub repository, go to Settings → Secrets and variables → Actions, and add these secrets:

AWS_ACCESS_KEY_ID: Your AWS access key
AWS_SECRET_ACCESS_KEY: Your AWS secret key
DB_USERNAME: Database admin username (e.g., "admin")
DB_PASSWORD: Database admin password

These secrets allow GitHub Actions to deploy infrastructure on your behalf without exposing credentials in your code.

Step 11. Deployment Process

Now that everything is set up, here's how to deploy your infrastructure. First, you'll create the remote state backend locally, then push your code to GitHub where the automated pipeline takes over.

Initial Setup

First, create the state backend infrastructure:

# Create the bootstrap file and run it
terraform init
terraform apply

After the S3 bucket and DynamoDB table are created, update your main configuration to use the remote backend:

# Initialize with remote backend
terraform init -backend-config=envs/prod/backend.hcl

Terraform will ask if you want to migrate your local state to S3. Type "yes" to proceed.

Deploy via GitHub Actions

Commit and push your code to GitHub:

git add .
git commit -m "Initial infrastructure setup"
git push origin main

GitHub Actions will automatically run terraform plan and terraform apply. You can watch the progress in the Actions tab of your repository.

Making Changes

To make infrastructure changes, create a feature branch:

git checkout -b update-instance-type
# Make your changes to the Terraform files
git add .
git commit -m "Update instance type to t3.small"
git push origin update-instance-type

Create a pull request on GitHub. The GitHub Actions workflow will automatically run terraform plan and post the results as a comment on your PR. Review the plan to see exactly what will change. If everything looks good, merge the pull request. GitHub Actions will automatically run terraform apply to deploy your changes.

Monitoring Deployments

You can view deployment progress in real-time by going to the Actions tab in your GitHub repository. Each workflow run shows all the steps and their outputs. If a deployment fails, you can see the exact error message and debug from there.

Step 12. Testing Your Infrastructure

Once deployment completes, you can test your infrastructure. Get the load balancer URL from the Terraform outputs:

terraform output alb_url

Visit that URL in your browser. You should see the custom welcome page showing the instance ID and availability zone. Refresh the page multiple times and you'll notice the instance ID changes as the load balancer distributes requests across your four web servers.

To verify Multi-AZ deployment:

# Check Auto Scaling Group distribution
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names prod-asg \
  --query 'AutoScalingGroups[0].Instances[*].[InstanceId,AvailabilityZone]' \
  --output table

# Check RDS Multi-AZ status
aws rds describe-db-instances \
  --db-instance-identifier prod-mysql \
  --query 'DBInstances[0].MultiAZ'

You should see two instances in each availability zone, and the RDS Multi-AZ status should return true.

Deployed Architecture Overview

Troubleshooting Common Issues

Let me walk you through solutions to common problems you might encounter. If your web servers aren't showing up as healthy in the load balancer target group, first check that Apache is actually running on the instances. Connect via Systems Manager Session Manager and run systemctl status apache2 to verify. Check the security group rules to ensure the web server security group allows traffic from the load balancer security group on port eighty.

If you can't connect to the database from your web servers, verify the security group rules allow MySQL traffic from the web server security group. Check that the database is in the available state using the RDS console. Verify that the web servers can resolve the database endpoint DNS name. Test connectivity using telnet or nc to the database endpoint on port 3306.

If Terraform apply fails with state locking errors, someone else might be running Terraform at the same time. Wait for their operation to complete. If Terraform crashed and left a stale lock, you can forcefully unlock using terraform force-unlock followed by the lock ID shown in the error message. Use this carefully because unlocking while someone else is actively making changes can corrupt your state.

If instances launch but immediately fail health checks, check the user data script logs at /var/log/cloud-init-output.log on the instance. The user data script might be failing, preventing Apache from starting. Verify that the instance can reach the internet to download packages by checking the route tables and internet gateway attachment.

If your GitHub Actions pipeline fails, check that you've configured all the required secrets in GitHub. Verify that the AWS credentials have sufficient permissions to create all the resources. Check the Actions logs for specific error messages that will point you to the problem.

Conclusion

You've now built a production-grade, highly available infrastructure on AWS using Terraform and GitHub Actions. This infrastructure can handle availability zone failures gracefully, automatically scales to meet demand, and deploys changes through an automated pipeline. The four Apache web servers distributed across two availability zones ensure your application remains available even when problems occur.

The Multi-AZ RDS database provides automatic failover if the primary database fails, and the remote state management with S3 and DynamoDB ensures your team can collaborate safely on infrastructure changes. The GitHub Actions pipeline replaces manual terraform apply commands with automated deployments that happen consistently every time.

This foundation gives you a solid starting point that you can evolve as your needs grow.

If you would prefer to use Jenkins as the CI/CD tool, check this out

Building the Classic Jotto Word Puzzle Game with Amazon Q Developer CLI

Oluwasegun Adedigba — Sat, 21 Jun 2025 23:44:03 +0000

Retro Journey: Building a Classic Jotto Word Puzzle Game

Jotto is a classic word-guessing game that predates modern digital games like Wordle. I chose to recreate this game because:

It has simple yet engaging mechanics - guess a 5-letter word and receive feedback on how many letters match
It offers a pure deduction challenge without revealing letter positions
It has nostalgic value while still being relevant to today's word game enthusiasts
The rules are straightforward but the gameplay requires strategy and vocabulary skills

Unlike Wordle, Jotto focuses purely on letter matching without position information, making it a different kind of deductive challenge that tests your ability to track and eliminate possibilities.

Effective Prompting Techniques

Throughout this project, I discovered several effective prompting techniques when working with AWS Q Developer:

1. Structured Component Creation

Breaking down the application into specific components with clear responsibilities yielded better results:

Generate the shell of a new React app for a word puzzle game called Jotto. Use Vite for setup

This initial prompt established the project structure and technology stack.

2. Iterative Refinement

When facing issues with text visibility, I used specific problem descriptions:

I can't see the texts in the guess and matching letters

This prompted targeted CSS improvements rather than a complete redesign.

3. Feature-Based Expansion

Adding new features was most effective when describing the user experience rather than implementation details:

Do you want to include a panel that explains how the game works? it can pop up when selected by a new user

5. Usability-Focused Improvements

When I noticed usability issues, I asked direct questions about specific features:

Your guesses should automatically scroll when there is a new addition, do you not think?

Do you want to fix the letter tracker though? It does not help me effectively

These prompts led to targeted functional improvements rather than just visual changes.

The Role of AWS Q Developer

For this project, I used AWS Q Developer to assist with various aspects of development. This tool helped me:

Generate initial project scaffolding and component structures
Implement complex game logic like the letter matching algorithm
Create responsive CSS designs that work across different devices
Debug issues in the letter tracker's deduction logic
Refine the user experience with features like auto-scrolling and first-time user onboarding

AWS Q Developer proved particularly valuable for rapidly prototyping ideas and implementing features that would have taken significantly longer to code manually. The tool’s ability to comprehend game mechanics and translate them into functional code significantly expedited the development process.

How AI Tackled Classic Programming Challenges

State Management

Q Developer implemented React state management patterns with a custom hook (useJottoGame) that encapsulated game logic:

const useJottoGame = () => {
  const [secretWord, setSecretWord] = useState('');
  const [guesses, setGuesses] = useState([]);
  const [matches, setMatches] = useState([]);
  const [gameStatus, setGameStatus] = useState('playing');
  // ...other state variables

  // Game logic functions
  const submitGuess = (guess) => {
    if (gameStatus !== 'playing') return;

    const normalizedGuess = guess.toLowerCase();
    const matchCount = countMatchingLetters(normalizedGuess, secretWord);

    setGuesses([...guesses, normalizedGuess]);
    setMatches([...matches, matchCount]);
    setAttempts(attempts + 1);

    // Check if the player won
    if (isCorrectGuess(normalizedGuess, secretWord)) {
      const finalScore = calculateScore();
      setScore(finalScore);
      setGameStatus('won');

      // Save high score
      const newHighScore = {
        score: finalScore,
        word: secretWord,
        attempts: attempts + 1,
        date: new Date().toISOString()
      };
      saveHighScore(newHighScore);
    } 
    // Check if the player lost (used all attempts)
    else if (attempts + 1 >= maxAttempts) {
      setGameStatus('lost');
    }
  };

  const startNewGame = () => {
    const newSecretWord = getRandomWord(sampleWords);
    setSecretWord(newSecretWord);
    setGuesses([]);
    setMatches([]);
    setGameStatus('playing');
    setAttempts(0);
    setScore(0);
  };

  // Return state and functions
  return {
    secretWord,
    guesses,
    matches,
    gameStatus,
    attempts,
    maxAttempts,
    score,
    highScores,
    submitGuess,
    startNewGame
  };
};

This approach cleanly separated concerns and made the game logic reusable.

Algorithm Implementation

The letter matching algorithm was implemented efficiently:

export const countMatchingLetters = (guess, secretWord) => {
  if (!guess || !secretWord) return 0;

  const guessLetters = new Set(guess.toLowerCase().split(''));
  const secretLetters = new Set(secretWord.toLowerCase().split(''));

  let matchCount = 0;
  guessLetters.forEach(letter => {
    if (secretLetters.has(letter)) {
      matchCount++;
    }
  });

  return matchCount;
};

Using Sets for this operation was an elegant solution that handles the Jotto matching rules correctly. The algorithm efficiently:

Converts both words to lowercase for case-insensitive comparison
Creates Sets of unique letters from each word
Counts how many letters from the guess appear in the secret word
Returns the match count

This implementation correctly follows Jotto rules where each unique letter is counted only once, regardless of how many times it appears in either word.

Persistent Storage

For data persistence, I used localStorage to save game progress and high scores:

const loadHighScores = () => {
  const savedScores = localStorage.getItem('jottoHighScores');
  if (savedScores) {
    setHighScores(JSON.parse(savedScores));
  }
};

const saveHighScore = (newScore) => {
  const updatedScores = [...highScores, newScore]
    .sort((a, b) => b.score - a.score)
    .slice(0, 10); // Keep only top 10 scores

  setHighScores(updatedScores);
  localStorage.setItem('jottoHighScores', JSON.stringify(updatedScores));
};

This implementation:

Loads existing scores from localStorage when the game initializes
Adds new scores to the list when the player wins
Sorts scores in descending order to maintain a proper leaderboard
Limits the leaderboard to the top 10 scores to prevent excessive storage use
Persists the updated leaderboard back to localStorage

Development Automation That Saved Time

1. Project Scaffolding

With the help of AWS Q Developer, I generated the complete project structure with a single prompt, saving hours of setup time:

npm create vite@latest jotto-game -- --template react

This included:

Creating the directory structure
Setting up the Vite configuration
Generating component files
Creating utility modules
Setting up CSS files
Implementing the game logic

The project was organized with a clean, maintainable structure:

jotto-game/
├── src/
│   ├── components/
│   │   ├── game/
│   │   │   ├── GameBoard.jsx
│   │   │   ├── GuessInput.jsx
│   │   │   ├── GuessResults.jsx
│   │   │   ├── LetterTracker.jsx
│   │   │   └── GameProgress.jsx
│   │   └── ui/
│   │       ├── HelpPanel.jsx
│   │       ├── ScoreBoard.jsx
│   │       └── FirstTimeExperience.jsx
│   ├── hooks/
│   │   └── useJottoGame.js
│   ├── utils/
│   │   └── wordUtils.js
│   ├── App.jsx
│   ├── App.css
│   ├── main.jsx
│   └── index.css
├── package.json
└── README.md

2. CSS Generation

I developed comprehensive CSS that handled both styling and responsive design:

/* Game Progress Styles */
.game-progress {
  width: 100%;
  max-width: 600px;
  margin-bottom: 1.5rem;
}

.progress-info {
  display: flex;
  justify-content: space-between;
  margin-bottom: 0.5rem;
}

.attempts-count {
  font-weight: bold;
  color: var(--secondary-color);
}

.attempts-remaining {
  color: #666;
}

.progress-bar-container {
  width: 100%;
  height: 0.8rem;
  background-color: #e0e0e0;
  border-radius: 4px;
  overflow: hidden;
}

.progress-bar {
  height: 100%;
  transition: width 0.3s ease;
}

/* Responsive Design */
@media (max-width: 768px) {
  .jotto-app {
    padding: 1rem;
  }

  header h1 {
    font-size: 2rem;
  }

  .guess-input form {
    flex-direction: column;
    align-items: center;
  }

  .guess-input input {
    width: 100%;
    max-width: 200px;
    margin-bottom: 0.5rem;
  }
}

This saved significant time that would have been spent on manual CSS adjustments and testing. The CSS included:

A consistent color scheme using CSS variables
Responsive design for different screen sizes
Animations for user feedback
Accessibility considerations
Consistent spacing and typography

3. Component Creation

The React components were built with proper structure, props, and state management:

const GuessResults = ({ guesses, matches }) => {
  if (!guesses || guesses.length === 0) {
    return <p className="no-guesses">Make your first guess!</p>;
  }

  return (
    <div className="guess-results">
      <h3>Your Guesses</h3>
      <div className="guess-results-container">
        <table>
          <thead>
            <tr>
              <th>Guess</th>
              <th>Matching Letters</th>
            </tr>
          </thead>
          <tbody>
            {guesses.map((guess, index) => (
              <tr key={index} className={index === guesses.length - 1 ? 'latest-guess' : ''}>
                <td className="guess-word">{guess}</td>
                <td className="match-count">
                  <div className="match-indicator">
                    <span className="match-number">{matches[index] || 0}</span>
                    <span className="match-text">
                      {matches[index] === 1 ? 'letter' : 'letters'}
                    </span>
                  </div>
                </td>
              </tr>
            ))}
          </tbody>
        </table>
      </div>

      <div className="guess-tip">
        <p>
          {guesses.length === 1 
            ? "Keep guessing to narrow down the letters!" 
            : "Compare your guesses to deduce the secret word."}
        </p>
      </div>
    </div>
  );
};

This component demonstrates several best practices:

Conditional rendering for empty state
Proper use of map() with key props
Dynamic class names based on component state
Semantic HTML with table for tabular data
Conditional text content based on data values
Nested component structure for better organization

Interesting Solutions

1. Improved Letter Tracker Component with Logical Deduction

One of the most interesting solutions was the enhanced Letter Tracker component that helps players track which letters they've used and make logical deductions:

const LetterTracker = ({ guesses, matches }) => {
  // Create the alphabet
  const alphabet = 'abcdefghijklmnopqrstuvwxyz'.split('');

  // Track which letters have been used in guesses
  const usedLetters = new Set();

  // Track which letters are confirmed to be in the secret word
  const confirmedLetters = new Set();

  // Track which letters are confirmed NOT to be in the secret word
  const eliminatedLetters = new Set();

  // Process all guesses to determine letter statuses using logical deduction
  if (guesses.length > 0) {
    // First, add all guessed letters to usedLetters
    guesses.forEach(guess => {
      const guessLetters = guess.toLowerCase().split('');
      guessLetters.forEach(letter => usedLetters.add(letter));
    });

    // Find words with zero matches - all letters in these words are eliminated
    guesses.forEach((guess, index) => {
      if (matches[index] === 0) {
        guess.toLowerCase().split('').forEach(letter => {
          eliminatedLetters.add(letter);
        });
      }
    });

    // Find words with all 5 letters matching - all letters in these words are confirmed
    guesses.forEach((guess, index) => {
      if (matches[index] === 5) {
        guess.toLowerCase().split('').forEach(letter => {
          confirmedLetters.add(letter);
        });
      }
    });

    // For words with some matches, use deduction
    guesses.forEach((guess, index) => {
      if (matches[index] > 0 && matches[index] < 5) {
        // For each letter in this guess
        guess.toLowerCase().split('').forEach(letter => {
          // If we've seen this letter in a word with zero matches, it's eliminated
          if (!eliminatedLetters.has(letter)) {
            // Check if this letter appears in all guesses with matches
            let appearsInAllMatchingGuesses = true;

            guesses.forEach((otherGuess, otherIndex) => {
              if (matches[otherIndex] > 0 && !otherGuess.toLowerCase().includes(letter)) {
                appearsInAllMatchingGuesses = false;
              }
            });

            // If this letter appears in all guesses with matches, it's likely in the word
            if (appearsInAllMatchingGuesses && guesses.filter((_, i) => matches[i] > 0).length > 1) {
              confirmedLetters.add(letter);
            }
          }
        });
      }
    });

    // Remove any letters from confirmedLetters if they're also in eliminatedLetters
    eliminatedLetters.forEach(letter => {
      confirmedLetters.delete(letter);
    });
  }

  // Get letter status
  const getLetterStatus = (letter) => {
    if (confirmedLetters.has(letter)) return 'confirmed';
    if (eliminatedLetters.has(letter)) return 'eliminated';
    if (usedLetters.has(letter)) return 'used';
    return 'unused';
  };

  return (
    <div className="letter-tracker">
      <h3>Letter Tracker</h3>
      <div className="letter-grid">
        {alphabet.map(letter => (
          <div 
            key={letter} 
            className={`letter-tile ${getLetterStatus(letter)}`}
            aria-label={`Letter ${letter}, status: ${getLetterStatus(letter)}`}
          >
            {letter}
          </div>
        ))}
      </div>
      <div className="letter-legend">
        <div className="legend-item">
          <div className="letter-tile unused"></div>
          <span>Unused</span>
        </div>
        <div className="legend-item">
          <div className="letter-tile used"></div>
          <span>Used (Unknown)</span>
        </div>
        <div className="legend-item">
          <div className="letter-tile confirmed"></div>
          <span>In Word</span>
        </div>
        <div className="legend-item">
          <div className="letter-tile eliminated"></div>
          <span>Not in Word</span>
        </div>
      </div>
    </div>
  );
};
        }
      });
    }
  });

  // Get letter status
  const getLetterStatus = (letter) => {
    if (confirmedLetters.has(letter)) return 'confirmed';
    if (usedLetters.has(letter)) return 'used';
    return 'unused';
  };

  return (
    <div className="letter-tracker">
      <h3>Letter Tracker</h3>
      <div className="letter-grid">
        {alphabet.map(letter => (
          <div 
            key={letter} 
            className={`letter-tile ${getLetterStatus(letter)}`}
            aria-label={`Letter ${letter}, status: ${getLetterStatus(letter)}`}
          >
            {letter}
          </div>
        ))}
      </div>
      <div className="letter-legend">
        <div className="legend-item">
          <div className="letter-tile unused"></div>
          <span>Unused</span>
        </div>
        <div className="legend-item">
          <div className="letter-tile used"></div>
          <span>Used in guesses</span>
        </div>
        <div className="legend-item">
          <div className="letter-tile confirmed"></div>
          <span>Likely in word</span>
        </div>
      </div>
    </div>
  );
};

This component cleverly uses Sets to track letter usage and provides visual feedback without revealing exact letter positions (keeping true to Jotto's mechanics). The implementation:

Creates a visual grid of all alphabet letters

Tracks which letters have been used in any guess

Uses a probabilistic approach to suggest which letters might be in the secret word
Provides a legend explaining the color coding

Includes ARIA labels for accessibility

2. First-Time User Experience

I created a sophisticated first-time user experience that detects new players and shows a welcome modal:

const FirstTimeExperience = ({ children }) => {
  const [isFirstVisit, setIsFirstVisit] = useState(true);
  const [showWelcome, setShowWelcome] = useState(false);

  useEffect(() => {
    // Check if user has visited before
    const hasVisitedBefore = localStorage.getItem('jottoHasVisited');

    if (!hasVisitedBefore) {
      // First time visitor
      setShowWelcome(true);
      localStorage.setItem('jottoHasVisited', 'true');
    } else {
      setIsFirstVisit(false);
    }
  }, []);

  const closeWelcome = () => {
    setShowWelcome(false);
    setIsFirstVisit(false);
  };

  if (!showWelcome) {
    return children;
  }

  return (
    <div className="welcome-overlay">
      <div className="welcome-modal">
        <h2>Welcome to Jotto!</h2>

        <div className="welcome-content">
          <p>Jotto is a word guessing game where you try to figure out a secret 5-letter word.</p>

          <h3>How to Play:</h3>
          <ol>
            <li>Enter a 5-letter word as your guess</li>
            <li>You'll be told how many letters from your guess appear in the secret word</li>
            <li>Use this information to make better guesses</li>
            <li>Try to find the secret word in as few attempts as possible</li>
          </ol>

          <div className="welcome-example">
            <p><strong>Example:</strong> If the secret word is "TRAIN" and you guess "PLANE", you'd get 3 matches (A, N, E).</p>
          </div>

          <p>You have 10 attempts to guess the word. Good luck!</p>
        </div>

        <button className="welcome-button" onClick={closeWelcome}>
          Start Playing
        </button>
      </div>
    </div>
  );
};

This component:

Uses localStorage to detect first-time visitors
Displays a modal overlay with game instructions
Provides a clear example of how the game works
Offers a prominent button to start playing
Only shows once per user (unless they clear their browser data)

3. Score Calculation Algorithm

The scoring system uses a clever algorithm that rewards efficiency:

const calculateScore = () => {
  // Base score: 1000 points
  // Subtract 50 points for each attempt
  // Minimum score is 100
  const baseScore = 1000;
  const penaltyPerAttempt = 50;
  const calculatedScore = Math.max(100, baseScore - (attempts * penaltyPerAttempt));
  return calculatedScore;
};

This algorithm:

Starts with a perfect score of 1000 points
Deducts 50 points for each guess attempt
Ensures a minimum score of 100 points even with many attempts
Creates a scoring system that rewards efficiency but doesn't overly punish exploration

4. Game Progress Component

The game progress component provides visual feedback on the player's progress:

const GameProgress = ({ attempts, maxAttempts }) => {
  const progressPercentage = (attempts / maxAttempts) * 100;

  // Determine color based on progress
  const getProgressColor = () => {
    if (progressPercentage < 40) return 'progress-low';
    if (progressPercentage < 70) return 'progress-medium';
    return 'progress-high';
  };

  // Get encouraging message based on progress
  const getMessage = () => {
    if (attempts === 0) return "Make your first guess!";
    if (progressPercentage < 30) return "Great start! Keep going.";
    if (progressPercentage < 60) return "You're making progress!";
    if (progressPercentage < 80) return "Getting closer!";
    return "Final attempts - think carefully!";
  };

  return (
    <div className="game-progress">
      <div className="progress-info">
        <span className="attempts-count">Attempt {attempts} of {maxAttempts}</span>
        <span className="attempts-remaining">({maxAttempts - attempts} remaining)</span>
      </div>

      <div className="progress-bar-container">
        <div 
          className={`progress-bar ${getProgressColor()}`}
          style={{ width: `${progressPercentage}%` }}
          role="progressbar"
          aria-valuenow={attempts}
          aria-valuemin="0"
          aria-valuemax={maxAttempts}
        ></div>
      </div>

      <p className="progress-message">{getMessage()}</p>
    </div>
  );
};

This component:

Calculates progress as a percentage of attempts used
Changes color based on how many attempts remain (green → yellow → red)
Displays encouraging messages that change as the game progresses
Includes proper ARIA attributes for accessibility
Provides both visual and textual feedback

Game Features and Implementation Details

Core Game Mechanics

The game follows traditional Jotto rules:

Players guess a 5-letter word
After each guess, they're told how many letters from their guess appear in the secret word
The position of matching letters doesn't matter
Players have a limited number of attempts (10) to guess the word

User Interface Components

Header Section
- Game title and brief description
- Help panel toggle button
- High scores panel toggle button

Game Progress Indicator
- Visual progress bar showing attempts used
- Text showing attempts remaining
- Encouraging messages based on progress
Guess Input
- Text input for entering 5-letter words
- Submit button
- Input validation (letters only, exactly 5 characters)
- Error messages for invalid input

Guess Results Table
- List of previous guesses
- Number of matching letters for each guess
- Highlighting for the most recent guess

Letter Tracker
- Visual grid of all alphabet letters
- Color coding to show used and potentially matching letters
- Legend explaining the color codes

Help Panel
- Game rules explanation
- Strategy tips
- Example of gameplay

Score Board
- Current score display
- High scores leaderboard
- Persistent storage of scores

First-Time User Experience
- Welcome modal for new players
- Game instructions
- Example of gameplay

Technical Implementation

React Components and Hooks
- Functional components with React hooks
- Custom game logic hook (useJottoGame)
- Component composition for UI organization
State Management
- React useState for component state
- Custom hook for game state
- Props for component communication
Styling
- CSS variables for consistent theming
- Responsive design with media queries
- Animations for user feedback
- Accessibility considerations
Data Persistence
- localStorage for saving high scores
- localStorage for tracking first-time visitors
Game Logic
- Word matching algorithm
- Score calculation
- Win/lose condition checking

Conclusion

Building this Jotto word puzzle game demonstrated how effective modern development tools can be for rapid prototyping and development. With AWS Q Developer's assistance, I successfully:

Generated a complete React application structure
Implemented game logic following classic Jotto rules
Created responsive UI components with proper accessibility
Added sophisticated features like score tracking and first-time user experience
Provided iterative improvements based on feedback
Implemented intelligent deduction tools like the enhanced letter tracker
Added usability features like auto-scrolling guess results

The final product is a fully functional Jotto game that maintains the classic gameplay while offering modern UI features and responsive design. This project shows how modern development tools can help resurrect classic games for modern platforms while preserving their original charm and gameplay mechanics.

The development process highlighted several strengths of using AWS Q Developer:

Rapid prototyping and iteration
Comprehensive implementation of features
Attention to details like accessibility and responsive design
Ability to generate both functional code and visual styling
Capacity to implement complex game logic and algorithms
Adaptability to changing requirements and feedback

This retro journey demonstrates that modern development tools can be powerful allies for game development, especially when reviving classic games with modern implementations. The ability to quickly iterate on features and improve usability based on feedback makes tools like AWS Q Developer invaluable partners in the development process.

4. UI Evaluation Requests

Asking for UI evaluation led to comprehensive improvements:

What do you think of the user interface as is? is it standard? would it help users play the game appropriately?

This yielded thoughtful analysis and specific enhancement suggestions.

5. Auto-Scrolling Guess Results

The GuessResults component was enhanced with auto-scrolling functionality to improve user experience:

const GuessResults = ({ guesses, matches }) => {
  // Create a ref for the container to enable auto-scrolling
  const resultsContainerRef = useRef(null);

  // Auto-scroll to the bottom when new guesses are added
  useEffect(() => {
    if (resultsContainerRef.current && guesses.length > 0) {
      resultsContainerRef.current.scrollTop = resultsContainerRef.current.scrollHeight;
    }
  }, [guesses]);

  if (!guesses || guesses.length === 0) {
    return <p className="no-guesses">Make your first guess!</p>;
  }

  return (
    <div className="guess-results">
      <h3>Your Guesses</h3>
      <div className="guess-results-container" ref={resultsContainerRef}>
        <table>
          <thead>
            <tr>
              <th>Guess</th>
              <th>Matching Letters</th>
            </tr>
          </thead>
          <tbody>
            {guesses.map((guess, index) => (
              <tr key={index} className={index === guesses.length - 1 ? 'latest-guess' : ''}>
                <td className="guess-word">{guess}</td>
                <td className="match-count">
                  <div className="match-indicator">
                    <span className="match-number">{matches[index] || 0}</span>
                    <span className="match-text">
                      {matches[index] === 1 ? 'letter' : 'letters'}
                    </span>
                  </div>
                </td>
              </tr>
            ))}
          </tbody>
        </table>
      </div>

      <div className="guess-tip">
        <p>
          {guesses.length === 1 
            ? "Keep guessing to narrow down the letters!" 
            : "Compare your guesses to deduce the secret word."}
        </p>
      </div>
    </div>
  );
};

This implementation:

Uses React's useRef hook to create a reference to the scrollable container
Implements useEffect to automatically scroll to the bottom whenever new guesses are added
Ensures the most recent guess is always visible without requiring manual scrolling
Improves user experience by keeping the focus on the latest game information ## Fixing the Letter Tracker

During testing, we discovered issues with the letter tracker component: it was incorrectly identifying letters as being in the secret word. After multiple iterations, we implemented a sophisticated deduction algorithm that properly follows Jotto's logical principles.

The Problem

Earlier implementations of the letter tracker were either too aggressive (showing too many letters as confirmed) or too conservative (not providing enough useful information). The challenge was to create a system that makes logical deductions similar to how a human player would approach the game.

The Solution: Advanced Deduction Logic

We implemented a comprehensive deduction algorithm that applies multiple logical rules iteratively until no more progress can be made:

// Process all guesses to determine letter statuses using logical deduction
if (guesses.length > 0) {
  // Step 1: Eliminate letters from guesses with zero matches
  guesses.forEach((guess, index) => {
    if (matches[index] === 0) {
      guess.toLowerCase().split('').forEach(letter => {
        eliminatedLetters.add(letter);
      });
    }
  });

  // Step 2: Confirm letters from guesses with all 5 letters matching
  guesses.forEach((guess, index) => {
    if (matches[index] === 5) {
      guess.toLowerCase().split('').forEach(letter => {
        confirmedLetters.add(letter);
      });
    }
  });

  // Step 3: Apply more sophisticated deduction logic
  let madeProgress = true;
  // Keep iterating as long as we're making progress in our deductions
  while (madeProgress) {
    madeProgress = false;

    // For each guess, check if we can deduce more information
    guesses.forEach((guess, index) => {
      if (matches[index] > 0) {
        const guessLetters = guess.toLowerCase().split('');

        // Count confirmed and eliminated letters in this guess
        let confirmedCount = 0;
        let eliminatedCount = 0;

        guessLetters.forEach(letter => {
          if (confirmedLetters.has(letter)) confirmedCount++;
          if (eliminatedLetters.has(letter)) eliminatedCount++;
        });

        // Case 3: If all letters except X are eliminated, and we need X more matches,
        // then those X letters must be in the word
        const nonEliminatedNonConfirmed = guessLetters.filter(
          letter => !eliminatedLetters.has(letter) && !confirmedLetters.has(letter)
        );

        if (nonEliminatedNonConfirmed.length === matches[index] - confirmedCount) {
          nonEliminatedNonConfirmed.forEach(letter => {
            if (!confirmedLetters.has(letter)) {
              confirmedLetters.add(letter);
              madeProgress = true;
            }
          });
        }

        // Case 4: If we've confirmed as many letters as there are matches,
        // all other letters in this guess must be eliminated
        if (confirmedCount === matches[index]) {
          guessLetters.forEach(letter => {
            if (!confirmedLetters.has(letter) && !eliminatedLetters.has(letter)) {
              eliminatedLetters.add(letter);
              madeProgress = true;
            }
          });
        }
      }
    });
  }
}

Key Features of the Improved Algorithm:

Iterative Deduction Process
- The algorithm repeatedly applies deduction rules until no more progress can be made
- This mimics how a human player would gradually eliminate possibilities
Multiple Deduction Rules
- Basic rules: Letters in zero-match guesses are eliminated; letters in full-match guesses are confirmed
- Advanced rule 1: If we need X more matches and only X letters remain non-eliminated, those letters must be in the word
- Advanced rule 2: If we've confirmed as many letters as there are matches, all other letters must be eliminated
Logical Consistency Checks
- The algorithm checks for and handles contradictions in the deduction process
- Final cleanup ensures no letter is marked as both confirmed and eliminated

This improved implementation provides accurate feedback to the player, making the letter tracker a truly useful tool for deduction in the Jotto game, while maintaining the core Jotto gameplay that's distinct from Wordle's position-based hints.

Enhancing the User Experience for Jotto Mechanics

After testing the game, we realized that players might not fully understand how Jotto differs from more familiar word games like Wordle. In Jotto, players only learn how many letters match, not which specific letters. This creates a different kind of deduction challenge that might not be immediately intuitive to new players.

To address this, we implemented three key improvements:

1. Simplified Letter Tracker with Clear Help Text

We redesigned the letter tracker to focus on what can be known with certainty in Jotto:

const LetterTracker = ({ guesses, matches }) => {
  const [showHelp, setShowHelp] = useState(false);

  // Track which letters have been used in guesses
  const usedLetters = new Set();

  // Track which letters are definitely eliminated (not in the word)
  const eliminatedLetters = new Set();

  // Process all guesses to determine letter statuses
  if (guesses.length > 0) {
    // Add all guessed letters to usedLetters
    guesses.forEach(guess => {
      const guessLetters = guess.toLowerCase().split('');
      guessLetters.forEach(letter => usedLetters.add(letter));
    });

    // Eliminate letters from guesses with zero matches
    guesses.forEach((guess, index) => {
      if (matches[index] === 0) {
        guess.toLowerCase().split('').forEach(letter => {
          eliminatedLetters.add(letter);
        });
      }
    });
  }

  // Get letter status
  const getLetterStatus = (letter) => {
    if (eliminatedLetters.has(letter)) return 'eliminated';
    if (usedLetters.has(letter)) return 'used';
    return 'unused';
  };

  return (
    <div className="letter-tracker">
      <div className="letter-tracker-header">
        <h3>Letter Tracker</h3>
        <button 
          className="help-toggle-button"
          onClick={toggleHelp}
          aria-expanded={showHelp}
        >
          {showHelp ? 'Hide Help' : '?'}
        </button>
      </div>

      {showHelp && (
        <div className="letter-tracker-help">
          <p>In Jotto, you need to deduce which letters are in the secret word:</p>
          <ul>
            <li><strong>Red letters</strong> are definitely <strong>not</strong> in the word (from guesses with 0 matches)</li>
            <li><strong>Blue letters</strong> have been used in guesses but could be in the word</li>
            <li><strong>Gray letters</strong> haven't been used yet</li>
          </ul>
          <p>Use the match counts from your guesses to deduce which blue letters might be in the word!</p>
        </div>
      )}

      {/* Letter grid and legend */}
    </div>
  );
};

The new implementation:

Focuses on what can be known with certainty (eliminated letters)
Uses clearer color coding (blue for used letters, red for eliminated)
Includes a help button with explanatory text
Adds a deduction tip to remind players of Jotto's mechanics

2. Enhanced Guess Results with Contextual Help

We added help text to the guess results component to explain how to interpret match counts:

const GuessResults = ({ guesses, matches }) => {
  const [showHelp, setShowHelp] = useState(false);

  // Toggle help text
  const toggleHelp = () => {
    setShowHelp(!showHelp);
  };

  return (
    <div className="guess-results">
      <div className="guess-results-header">
        <h3>Your Guesses</h3>
        <button 
          className="help-toggle-button"
          onClick={toggleHelp}
          aria-expanded={showHelp}
        >
          {showHelp ? 'Hide Help' : '?'}
        </button>
      </div>

      {showHelp && (
        <div className="guess-results-help">
          <p>In Jotto, after each guess you'll see how many letters from your guess appear in the secret word.</p>
          <p>For example, if the secret word is "TRAIN" and you guess "PLANE", you'd get 3 matches (A, N, E).</p>
          <p>The position of the letters doesn't matter - only whether they appear in the word.</p>
        </div>
      )}

      {/* Guess results table */}

      <div className="guess-tip">
        <p>
          {guesses.length === 1 
            ? "The number shows how many letters from your guess appear in the secret word." 
            : "Compare your guesses to deduce which letters are in the secret word."}
        </p>
      </div>
    </div>
  );
};

This implementation:

Adds a help button with contextual explanations
Provides a concrete example of how matching works
Includes a tip that changes based on game progress
Emphasizes the need to compare guesses for deduction

3. Improved Help Panel with Jotto vs. Wordle Comparison

We expanded the help panel to clearly explain how Jotto differs from Wordle:

<div className="help-section">
  <h4>How Jotto Differs from Wordle</h4>
  <p>Unlike Wordle, Jotto:</p>
  <ul>
    <li>Only tells you HOW MANY letters match, not which specific ones</li>
    <li>Doesn't give information about letter positions</li>
    <li>Requires deduction across multiple guesses to determine which letters are in the word</li>
  </ul>
</div>

We also added a detailed example table showing how matches are counted:

<div className="help-section">
  <h4>Example</h4>
  <p>Secret word: "TRAIN"</p>
  <table className="help-example-table">
    <thead>
      <tr>
        <th>Guess</th>
        <th>Matching Letters</th>
        <th>Explanation</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>PLANE</td>
        <td>3</td>
        <td>A, N, E are in TRAIN</td>
      </tr>
      <tr>
        <td>STORM</td>
        <td>1</td>
        <td>R is in TRAIN</td>
      </tr>
      <tr>
        <td>BRAIN</td>
        <td>4</td>
        <td>R, A, I, N are in TRAIN</td>
      </tr>
      <tr>
        <td>TRAIN</td>
        <td>5</td>
        <td>All letters match - you win!</td>
      </tr>
    </tbody>
  </table>
</div>

These improvements collectively make the Jotto mechanics much clearer to players, especially those who might be more familiar with Wordle. By emphasizing the deduction aspect and providing clear guidance, we've made the game more accessible while maintaining its classic gameplay.

AmazonQDevCLI #BuildGamesChallenge #AmazonQCLI

Check out this post on one of the non-functional requirements for your applications - Security

Oluwasegun Adedigba — Wed, 08 Jan 2025 21:30:00 +0000

Non-functional Application Requirements: Security

Oluwasegun Adedigba for AWS Community Builders ・ Jan 7

#aws #security #discuss #softwaredevelopment

Non-functional Application Requirements: Security

Oluwasegun Adedigba — Tue, 07 Jan 2025 23:30:12 +0000

When you’re building modern applications, security is paramount. It’s the invisible architecture that keeps user data safe, systems protected, and your organization’s reputation intact. In an era where cyber threats are not just probable but inevitable, overlooking security can have catastrophic results.

So how do you approach security in a meaningful, sustainable way?

This article dives into securing applications on the cloud, with a focus on leveraging AWS’s rich security toolkit. We’ll address the 5Ws (What, Why, When, Where, and Who) of security, explore the vital aspects of a robust security strategy, and discuss best practices that seasoned engineers employ to keep applications safe and resilient.

What: Understanding Security’s Scope in Cloud Applications

Security in the cloud isn’t just about blocking bad actors. It’s about creating a secure, resilient environment that preserves your application's confidentiality, integrity, and availability (CIA). Let’s break down these core components:

1. Confidentiality

Ensuring data is accessible only to authorized users and systems.

Implementation:

Zero-Trust Architecture: Enforces strict identity verification at every access point.
Encryption Standards: Protect data with AES-256 encryption at rest and TLS 1.3 during transmission.
Key Management: Utilize systems like AWS Key Management Service (KMS) for secure encryption key storage and rotation.

In 2024, AT&T experienced a significant data breach affecting approximately 73 million customers, including both current and former users. Sensitive information such as social security numbers, account numbers, and passcodes was compromised. The data, believed to be from 2019 or earlier, surfaced on the dark web in mid-March 2024. This incident underscores the critical importance of robust encryption and stringent access controls to maintain confidentiality.

2. Integrity

Assuring the accuracy and completeness of data throughout its lifecycle.

Implementation:

Cryptographic Hash Functions: Use SHA-256 or SHA-3 to validate data integrity.
Immutable Audit Logs: Maintain unalterable event logs for forensic investigations.
Version Control Systems: Employ tools like Git to track and revert unauthorized changes.

In 2024, Snowflake, a prominent data warehousing company, suffered a breach, in which hackers used stolen passwords to access data from companies like Ticketmaster, Santander Bank, and AT&T. This breach resulted in significant data loss and highlighted the necessity for robust data validation mechanisms and stringent access controls to ensure data integrity.

3. Availability

Ensuring systems remain operational and accessible during critical times.

Implementation:

Multi-Region Redundancy: Host systems across multiple regions to ensure resilience.
DDoS Protection: Utilize services like AWS Shield to mitigate attacks.

In 2024, Chinese hackers, identified as Salt Typhoon, infiltrated U.S. telecommunications networks, enabling them to geolocate millions of Americans and record their phone calls. High-profile victims included President-elect Donald Trump and senior Biden administration officials. This breach, affecting major telecom providers like Verizon and AT&T, underscores the importance of robust security measures to maintain system availability and protect against unauthorized access.

Together, the CIA triad forms the backbone of a secure cloud application and dictates how security should be implemented across various layers.

Security Domains in Cloud Applications

1. Identity and Access Management (IAM)

Securing who can access your systems and what actions they can perform.

Implementation:

Authentication & Authorization: AWS IAM and Cognito provide robust tools for user authentication.
Privileged Access Management: Enforce least-privilege principles for sensitive operations.

2. Data Security

Safeguarding data through its entire lifecycle is critical for compliance and user trust.

Implementation:

Encryption Standards: Apply AES-256 and TLS 1.3.
Data Retention Policies: Regularly dispose of unnecessary data to minimize exposure.

Last year, Meta (formerly Facebook) was fined €1.2 billion ($1.3 billion) for improperly transferring Facebook users’ personal data from the European Union to the U.S., violating GDPR. This significant penalty underscores the necessity for robust data security measures and compliance with international data protection laws.

3. Application Security

Securing codebases and runtime environments is key.

Implementation:

Secure SDLC: Integrate security in development workflows with automated scans.
Runtime Protection: Use tools like AWS AppRunner for secure application deployments.

Key Areas of Security Focus

With the transition to cloud-native architectures, applications now require a multi-layered approach that spans various domains:

Identity and Access Management (IAM):
- This domain centers on authenticating who can access your systems (authentication) and determining what actions they can perform (authorization).
- Key tools include AWS Identity and Access Management (IAM), privileged access management, and single sign-on (SSO) integration.
- Best Practices: Implement strict least privilege policies, use multi-factor authentication (MFA), and enforce short-lived access tokens for sensitive operations.
Data Security:
- Protecting data, whether at rest or in transit, is crucial for compliance and user trust.
- Key strategies include encryption standards and protocols (such as AES-256 for at-rest data and TLS 1.3 for in-transit), regular key rotation policies, and data retention and disposal practices.
- Privacy Compliance: Adhere to regulations like GDPR and CCPA by incorporating privacy-by-design principles into data storage and processing.
Network Security:
- Establishing a secure network perimeter is vital for preventing unauthorized access and segmentation of sensitive resources.
- Core tools include microsegmentation, Web Application Firewalls (WAF), API gateways, and Virtual Private Cloud (VPC) design with network isolation.
- Best Practices: Limit access through security groups, use VPC endpoints for private connections, and implement network monitoring for anomaly detection.
Application Security:
- Application security focuses on securing the codebase and runtime environment.
- Techniques include secure software development lifecycle (SDLC) practices, dependency scanning for vulnerabilities, container security, and runtime protection.
- Best Practices: Emphasize secure coding standards, use automated vulnerability scanning, and implement role-based access control within your development pipeline.
Operational Security:
- Operational security is about maintaining security in day-to-day operations, including monitoring, incident response, and threat modeling.
- Key elements include continuous monitoring, incident response planning, threat modeling, and security automation.
- Best Practices: Integrate monitoring tools like AWS GuardDuty and AWS CloudTrail for real-time insights, conduct regular security drills, and automate incident response with predefined playbooks.

The key to a comprehensive security strategy is a multi-layered approach—one that addresses each of these areas, embedding security into the application's entire lifecycle.

Why: The Critical Importance of Security

Security isn’t just a “nice-to-have” feature. It’s essential. Let’s consider why a robust security strategy is non-negotiable:

Financial Impact: The average cost of a data breach is estimated to be over $4.88 million globally—a 10% increase over last year and the highest total ever, according to IBM’s 2024 Cost of a Data Breach Report. This cost includes data recovery, legal fees, loss of business, and more. These costs can be even higher for companies that handle sensitive information, like healthcare or financial data.
Trust and Reputation: A single data breach can erode user trust for years. The reputational damage can lead to customer churn, media fallout, and loss of market standing—consequences that can be difficult, if not impossible, to recover from.
Compliance Requirements: With the rise of global data privacy regulations like GDPR, CCPA, and HIPAA, companies face strict standards around data handling, storage, and access. Non-compliance can result in heavy fines and sanctions, making security an essential part of business continuity.
Operational Stability: Insecure applications are more vulnerable to cyber attacks, which can lead to downtime, data loss, and operational disruption. Security ensures your application remains stable, even in the face of unforeseen events.

When security is compromised, it’s not just a technical issue—it’s a business crisis. Prioritizing security helps safeguard your organization’s financial health, reputation, and operational resilience.

When: Embedding Security from Day One

In today’s rapid development environments, security needs to be a part of the design and development process from the outset. The earlier security is embedded, the less costly it is to manage and mitigate threats later on. This shift-left approach to security focuses on integrating security practices throughout the entire development lifecycle.

Key Stages to Integrate Security

Design Phase: Consider security requirements and outline data flow models to anticipate potential vulnerabilities.
Development Phase: Emphasize secure coding practices, such as avoiding hard-coded secrets, using secure libraries, and adopting code review processes.
Testing and QA Phase: Use penetration testing and automated vulnerability scanning to identify weaknesses before deployment.
Deployment and Operations Phase: Implement real-time monitoring, automated patching, and incident response plans for continuous security.

By shifting security left, you address potential issues early, reducing the risk of costly fixes and rework down the road.

Where: Leveraging AWS Security Services

AWS offers a broad array of services that cover different aspects of application security. Let’s explore some of the key tools and how they align with specific security needs:

AWS Identity and Access Management (IAM): Centralized access control that enables granular permissions and the principle of least privilege.
AWS Cognito: Provides secure, scalable user authentication and authorization, which is ideal for applications with user sign-ups and logins.
AWS Key Management Service (KMS): Facilitates data encryption at rest and ensures sensitive information is only accessible to authorized users.
AWS Shield and AWS Web Application Firewall (WAF): Protects against DDoS attacks and filters incoming traffic to block malicious activity.
Amazon GuardDuty and AWS CloudTrail: Enables threat detection and continuous monitoring, providing insights into suspicious activity.
AWS Config and AWS Inspector: Ensures compliance by auditing configurations and automatically scanning for vulnerabilities.

AWS makes it possible to implement a multi-layered security approach tailored to your specific needs, whether you’re building a simple application or a complex, distributed architecture.

Who: The Roles and Responsibilities in Security

Security is a shared responsibility, not just within your organization but also with your cloud provider. In AWS’s Shared Responsibility Model, AWS manages the security of the cloud infrastructure, while you are responsible for securing what you deploy on it.

Roles Within Your Organization

Developers: Responsible for secure coding, dependency management, and building secure APIs. Developers ensure that code meets security standards before it reaches production.
Cloud Architects and DevOps Engineers: Focused on infrastructure security, automation of security tasks, and managing access and identity controls.
Security Analysts: Monitor security alerts, conduct risk assessments, and respond to incidents. They implement and oversee security policies across the application lifecycle.
Compliance and Legal Teams: Ensure the application meets regulatory and data protection standards, working closely with technical teams to interpret compliance requirements.

By fostering a security-minded culture and involving each role, you create a more resilient, secure application environment.

Security Best Practices: Building a Resilient Application

Embrace the Principle of Least Privilege: Only grant access permissions that are absolutely necessary, and regularly audit permissions to prevent “scope creep.”
Encrypt Everything: Use AWS KMS to encrypt data at rest and HTTPS for data in transit. Encrypting sensitive data helps prevent unauthorized access, even in the event of a data breach.
Regularly Patch and Update: Outdated software and libraries can be security vulnerabilities. Automate patching to keep your stack up to date and minimize security risks.
Implement Multi-Factor Authentication (MFA): Enforce MFA for both root and user accounts, adding an additional layer of protection against unauthorized access.
Continuously Monitor and Respond: Use AWS CloudTrail and GuardDuty to detect unusual behavior, and implement automated alerts for faster incident response.
Audit for Compliance: Regularly assess your application against regulatory requirements. AWS Config and AWS Artifact can simplify auditing and reporting processes, making it easier to stay compliant.
Conduct Regular Security Reviews: Schedule periodic penetration testing and security assessments to identify vulnerabilities that automated tools might miss.

A security-first approach isn’t just about prevention; it’s about preparation. The best security strategies ensure that if an incident occurs, it’s managed swiftly and effectively.

A Security-First Mindset

In today’s world, security is a differentiator. Applications that prioritize security not only protect data and maintain compliance, but they also build trust. Users are more likely to stay loyal to a product they trust with their information.

Adopting a security-first mindset involves viewing security as an enabler rather than an obstacle. By following best practices, leveraging AWS’s rich suite of security tools, and embedding security at every stage of development, you can create applications that are as secure as they are functional.

Building applications in the cloud has made it easier to scale and innovate, but it has also introduced new security challenges. With AWS’s powerful security tools and a clear, robust security strategy, you can meet these challenges head-on.

Remember: A secure application isn’t just a technical asset; it’s a valuable part of your brand. Make security a priority, and build trust one secure interaction at a time.

Cover Image: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels

3 AM on Christmas: A Cloud Engineer's Holiday Survival Guide🎄

Oluwasegun Adedigba — Wed, 25 Dec 2024 01:19:50 +0000

The blue light of monitoring dashboards illuminates my fourth cup of coffee as I watch traffic graphs climb steadily upward. It's 3 AM on Black Friday, and across the world, DevOps and cloud engineers just like me are sitting in the dark, watching their carefully crafted infrastructure face its ultimate test.

If you've ever been that engineer, you know the unique mixture of excitement and anxiety that comes with the holiday season – that moment when months of preparation meet millions of eager holiday shoppers and gift-givers.

When Perfect Plans Meet Holiday Reality

I remember my first holiday season on call like it was yesterday. Our team had done everything by the book. We had scaled our infrastructure to handle twice our normal traffic. Our automation was tested, our alerts were configured, and our runbooks were updated. We thought we were ready. We weren't.

What we hadn't accounted for was the "last-minute gifter" effect – that heart-stopping moment when thousands of customers simultaneously try to purchase the same limited-quantity holiday deals. It was like trying to funnel an entire shopping mall through a single revolving door. Our servers were handling the load, but our application wasn't designed for this pattern of traffic. It was a hard lesson: sometimes green metrics tell lies.

The Tale of Three Christmas Eves

Year One: The Load Balancer That Wasn't

Everything looked perfect on the monitoring dashboard. Our auto-scaling was working as designed, CPU metrics were well within limits, and memory usage was stable. Perfect, right? That's when I learned one of the most valuable lessons in my DevOps career: green metrics don't always tell the whole story.

We had plenty of capacity that night, but our load balancers were configured with a round-robin algorithm instead of least outstanding requests. Some customers sailed through checkout while others got stuck in a digital traffic jam – it was like having multiple lines at a store where one moves quickly while others barely budge.

The solution we implemented:

resource "aws_lb" "holiday_sales" {
  name               = "holiday-sales-lb"
  internal           = false
  load_balancer_type = "application"

  access_logs {
    bucket  = aws_s3_bucket.lb_logs.bucket
    prefix  = "holiday-sales"
    enabled = true
  }
}

resource "aws_lb_listener" "front_end" {
  load_balancer_arn = aws_lb.holiday_sales.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

resource "aws_lb_target_group" "app" {
  name     = "holiday-sales-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  load_balancing_algorithm_type = "least_outstanding_requests"

  stickiness {
    type            = "app_cookie"
    cookie_duration = 86400
    cookie_name     = "holiday_session"
  }

  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 15
    timeout             = 5
    path               = "/health"
    matcher            = "200"
  }
}

Year Two: The Forgotten Cache

The next year, we thought we had it all figured out. We had a beautifully designed caching strategy using ElastiCache, with carefully tuned TTLs for different types of content. But we discovered a new challenge: cache warming after scaling events. New instances would come up, miss the cache, hammer our database, and slow down just as they were needed most. It was like hiring new holiday staff but forgetting to give them the employee handbook.

The solution came in the form of a pre-warming strategy. We built a Lambda function that would prepare new instances before they received traffic:

resource "aws_lambda_function" "cache_warmer" {
  filename         = "cache_warmer.zip"
  function_name    = "holiday-cache-warmer"
  role            = aws_iam_role.cache_warmer_role.arn
  handler         = "index.handler"
  runtime         = "nodejs18.x"
  timeout         = 300

  environment {
    variables = {
      CACHE_URLS = join(",", [
        "/api/popular-products",
        "/api/holiday-deals",
        "/api/inventory-status"
      ])
    }
  }

  tags = {
    Purpose = "Preload cache for new instances"
    Season  = "holiday"
  }
}

resource "aws_cloudwatch_event_rule" "cache_warm" {
  name                = "cache-warm-schedule"
  description         = "Trigger cache warming before peak hours"
  schedule_expression = "cron(0 */4 * * ? *)"
}

resource "aws_cloudwatch_event_target" "cache_warm" {
  rule      = aws_cloudwatch_event_rule.cache_warm.name
  target_id = "WarmCache"
  arn       = aws_lambda_function.cache_warmer.arn
}

Year Three: The Analytics That Ate Christmas

Then came the year we thought we had our database scaling all figured out. DynamoDB with on-demand capacity? Check. Global tables for redundancy? Check. But we hadn't considered the impact of our seasonal aggregation queries. Every hour, we'd run analytics to update trending products, and during peak hours, these queries were consuming so much capacity that they affected our real-time operations.

We solved this by building a separate analytics pipeline that wouldn't interfere with customer operations:

resource "aws_kinesis_firehose_delivery_stream" "analytics_stream" {
  name        = "holiday-analytics-stream"
  destination = "s3"

  s3_configuration {
    role_arn   = aws_iam_role.firehose_role.arn
    bucket_arn = aws_s3_bucket.analytics_bucket.arn
    prefix     = "raw-events/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/"
    buffer_interval = 60
  }
}

resource "aws_athena_workgroup" "holiday_analytics" {
  name = "holiday-analytics"

  configuration {
    enforce_workgroup_configuration    = true
    publish_cloudwatch_metrics_enabled = true

    result_configuration {
      output_location = "s3://${aws_s3_bucket.analytics_results.bucket}/output/"

      encryption_configuration {
        encryption_option = "SSE_S3"
      }
    }
  }
}

The Christmas Tales

Amidst these technical challenges, there are moments of holiday magic. One year, our team got an unusual alert: a sudden surge in gift card purchases. It turned out to be a last-minute push by a group of coworkers sending digital holiday cheer across their remote team. We optimized the process just in time, ensuring their holiday spirit wasn't delayed.

Another Christmas Eve, we received a frantic message from a single dad trying to purchase a hard-to-find toy. We stepped in to troubleshoot an inventory sync issue that was preventing the order from going through. The look of gratitude on his follow-up call reminded us why we do what we do.

Wisdom Earned After Midnight

Through those long nights and challenging moments, I've learned lessons that no amount of documentation could have prepared me for:

Test Everything, Then Test It Again – But Test It Wrong

Don't just verify that things work; verify how they fail. Pull the plug on an availability zone. Max out your database connections. See what happens when Redis decides to failover at peak traffic. Your system isn't really tested until it's been tested at failure.

Monitor the Business, Not Just the Boxes

CPU, memory, and disk metrics are important, but they don't tell the whole story. Watch the metrics that matter to your customers:

Time to add items to cart
Checkout success rate
Payment processing time
Search response times
Inventory accuracy

Keep It Simple When Stakes Are High

That exciting new service you've been wanting to try out? Save it for February. During peak season, boring technology is beautiful technology. Each additional component is another potential point of failure.

The Magic Behind the Metrics

Remember, at the end of the day, we're not just managing servers and databases—we're helping create holiday memories. Every successful transaction is a gift being bought for someone special, every smooth checkout is a moment of joy, and every millisecond of uptime is part of someone's holiday story.

That time we kept the site running smoothly through Christmas Eve? We helped a father get the exact gaming console his daughter wanted. That cache optimization we did? It helped a grandmother find the perfect sweater for her grandson before it sold out. That database that didn't buckle under pressure? It helped countless families make their holiday wishes come true.

Essential Resources for Holiday Season Preparation 🎁

Load Testing and Performance

Artillery.io Documentation - For realistic load testing
k6 Load Testing - Modern load testing tool
Apache JMeter - For comprehensive performance testing

Infrastructure and Scaling

Monitoring and Alerting

Caching Strategies

Disaster Recovery

Cost Optimization

Community and Learning

Remember to check your CloudWatch alarms twice – Santa's not the only one who should be checking lists this time of year! 🎅

From my terminal to yours, happy holidays and may your deployments be smooth and your alerts be few! 🎄

Written by a DevOps Engineer who survived multiple holiday seasons and lived to tell the tale.

[Boost]

Oluwasegun Adedigba — Tue, 24 Dec 2024 21:45:40 +0000

Non-functional Application Requirements: An Introduction

Oluwasegun Adedigba — Wed, 09 Oct 2024 02:42:12 +0000

When we think about building applications, most of us start with the obvious—functional requirements. We focus on what the app should do—the features, the user flows, and the outputs. But as your application grows, you quickly realize that the real challenges often lie in what the app must be—secure, fast, always available, and easy to maintain.

That’s where non-functional requirements come in.

Inspired by Dr. Werner Vogels' insightful keynote at AWS re:Invent 2023, this series explores these often-overlooked aspects of application development. Non-functional requirements (NFRs) are not just technical jargon—they’re the pillars that determine whether your application will thrive or fall apart as it scales. Whether you’re building a startup MVP or managing a massive enterprise app, you’ll face these challenges.

Why You Should Care About Non-Functional Requirements

Imagine launching an application that looks great and works well—until your first 10,000 users arrive, and it slows to a crawl. Or perhaps you’ve built an app that processes sensitive data but hasn’t accounted for the latest security protocols, leaving you vulnerable to a data breach. What about the cost of maintaining that app over time? How will you handle updates, compliance audits, and infrastructure scaling?

This series isn’t about abstract theory—it’s about solving real problems. Each post will focus on a different non-functional requirement, breaking it down with real-world examples, hands-on tutorials, and insights into AWS services that can make implementation smoother. Whether you're a developer, cloud architect, or DevOps engineer, this guide is for you.

What’s Ahead?

We’ll cover the nine key non-functional requirements that every modern application needs to address:

Security
Compliance
Accessibility
Performance
Availability
Scalability
Maintainability
Cost
Sustainability

The first three are non-negotiable. They’re critical to protecting your users, data, and business. The remaining six require thoughtful trade-offs—you can’t have it all without some compromises, so we’ll dive into how to make those tough decisions.

Breaking It Down: What You’ll Learn

In this series, we’ll answer the 5Ws (What, Why, When, Where, Who) for each requirement, but we’ll also take things a step further. We’ll approach each topic from different angles to ensure you get a well-rounded understanding of how these principles impact your applications, both technically and strategically.

Hands-On Tutorials: You'll get practical guides, walking you through the setup and optimization of key AWS services like AWS Shield, AWS Cognito, EC2 Auto Scaling, and more.
Real-World Case Studies: We’ll learn from the successes and failures of companies that have tackled these challenges head-on, especially in high-stakes environments like e-commerce, healthcare, and startups.
Pitfalls & Lessons Learned: Don’t fall into the common traps—discover what to avoid before it becomes a costly mistake.
Expert Insights: We’ll feature interviews with industry experts who live and breathe security, compliance, and cloud architecture.
Cost-Benefit Analysis: Balancing trade-offs between performance, scalability, and cost efficiency will be a recurring theme.

A Quick Look at What’s Coming

Security: The Bedrock of Trust

In today’s hyper-connected world, your app’s security is always under scrutiny. We’ll dive into encryption, authentication, and threat protection using AWS services like Cognito and AWS Shield—plus a few non-AWS tools like Nessus for vulnerability scanning. Expect step-by-step guidance, code examples, and real-world scenarios.

Compliance: Navigating the Regulatory Maze

Staying compliant with global regulations like GDPR, HIPAA, and SOC 2 is critical to keeping your business afloat. We’ll break down how AWS services like AWS Config and AWS Artifact help you meet these ever-evolving requirements, backed by a case study on how a healthcare company successfully implemented compliance from day one.

Accessibility: Designing for Everyone

Accessibility is about more than ticking boxes—it’s about ensuring your app works for every user, regardless of their abilities. We’ll separate myth from fact, showing you how to use AWS Amplify, React’s accessibility features, and tools like axe DevTools to make your app more inclusive.

Performance: Faster, Smoother, Better

Performance optimization isn’t just about reducing latency; it’s about providing a seamless user experience, even under load. We’ll explore AWS CloudFront for fast content delivery, and look at how serverless can be a game-changer for scaling apps efficiently.

Availability: Your App, Always On

How do you keep your app running, even during server failures or spikes in traffic? We’ll tackle high availability with multi-region architectures and services like Elastic Load Balancing (ELB) and Route 53, ensuring your app has zero downtime, no matter what.

Scalability: Ready to Grow?

As your user base grows, your app needs to grow with it. We’ll break down horizontal vs. vertical scaling, using AWS EC2 Auto Scaling, EKS, and more. Plus, we’ll discuss how to manage costs while scaling efficiently—a key consideration for any growing business.

Maintainability: Preparing for the Long Haul

Building maintainable systems saves you time and headaches in the long run. We’ll share best practices for code organization, testing, and CI/CD using AWS services like AWS CodeBuild, CodeDeploy, and CloudWatch. You’ll learn how to keep your app running smoothly, even as it evolves.

Cost: Optimizing for Efficiency

Cost isn’t just about cutting expenses; it’s about balancing performance, availability, and scalability in the most efficient way. We’ll explore AWS tools like Cost Explorer, AWS Budgets, and Trusted Advisor, along with strategies for minimizing costs without compromising quality.

Sustainability: Building Green Applications

Cloud sustainability is becoming increasingly important. In this post, we’ll explore how to use AWS Lambda and DynamoDB to build energy-efficient, cost-effective applications while reducing your app’s carbon footprint. Plus, we’ll feature insights from experts who are leading the charge in sustainable architecture.

Why This Series Matters

In an era where applications must be fast, scalable, and secure—all while managing costs and sustainability—the importance of non-functional requirements cannot be overstated. These are the elements that ensure your application doesn’t just survive, but thrives in a competitive, rapidly evolving tech landscape.

Whether you're building your first MVP or managing a complex cloud infrastructure for millions of users, this series will equip you with the tools, strategies, and insights you need to build more resilient, reliable, and efficient applications.

Let’s dive in together.

Cover Image: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels

EC2 Snapshot Management: How to get AWS EC2 Snapshot Information with Python

Oluwasegun Adedigba — Thu, 20 Jun 2024 02:23:14 +0000

Introduction

Amazon Elastic Compute Cloud (EC2) snapshots are integral to data backup and disaster recovery strategies within AWS. They provide point-in-time copies of your EC2 instance volumes, allowing you to restore data quickly and reliably in the event of failures, data loss, or system corruption. As organizations scale their cloud infrastructure, managing these snapshots becomes increasingly complex and time-consuming. Automation is the key to simplifying this process, ensuring data integrity, and optimizing operational efficiency.

In this blog post, we'll walk through a Python script that automates the extraction of snapshot information, including associated instance details. This script exports the gathered data to a CSV file for easy analysis and documentation. By leveraging this automated approach, you can streamline your workflow, maintain a robust backup strategy, and gain valuable insights into your AWS environment.

Prerequisites

Before diving into the script, ensure you have the following prerequisites:

AWS Account: You need an active AWS account with EC2 instances and associated snapshots.
AWS CLI and Boto3: The AWS Command Line Interface (CLI) and Boto3 (the AWS SDK for Python) should be installed and configured on your machine.
Python Environment: Make sure you have Python installed on your local machine.
IAM Permissions: The IAM user or role you use must have the necessary permissions to describe EC2 instances and snapshots. Typically, AmazonEC2ReadOnlyAccess is sufficient.

Setting Up AWS CLI and Boto3

First, install the AWS CLI and Boto3. Open your terminal and run:

pip install awscli boto3

Next, configure the AWS CLI with your credentials:

aws configure

You'll be prompted to enter your AWS Access Key ID, Secret Access Key, default region, and output format. This configuration is essential for Boto3 to interact with your AWS environment.

Automating Snapshot Information Extraction

To automate the extraction of EC2 snapshot information, we need to perform the following steps:

Retrieve the names of EC2 instances.
Extract EC2 instance IDs from snapshot descriptions.
Gather snapshot information and export it to a CSV file.

1. Retrieving Instance Names

Each EC2 instance can have multiple tags, one of which is typically the Name tag. This tag is crucial for identifying instances more easily.

import boto3

def get_instance_name(ec2, instance_id):
    response = ec2.describe_instances(InstanceIds=[instance_id])
    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            for tag in instance.get('Tags', []):
                if tag['Key'] == 'Name':
                    return tag['Value']
    return 'N/A'

The get_instance_name function queries AWS to describe the specified instance by its ID and iterates through the tags to find the Name tag. If the Name tag is not present, it returns 'N/A'.

2. Extracting Instance IDs from Snapshot Descriptions

Snapshots in AWS often contain the instance ID in their descriptions. We can use a regular expression to extract these IDs.

import re

def extract_instance_id(description):
    match = re.search(r'i-[a-f0-9]+', description)
    if match:
        return match.group(0)
    return 'N/A'

The extract_instance_id function uses a regular expression to search for instance IDs (which match the pattern i-[a-f0-9]+) within the snapshot description. If a match is found, it returns the instance ID; otherwise, it returns 'N/A'.

3. Exporting Snapshot Information to CSV

Combining the previous functions, we can now gather the snapshot information and export it to a CSV file.

import csv
import boto3

def export_snapshots_info_to_csv():
    ec2 = boto3.client('ec2')  # Connect to EC2 service
    snapshots = ec2.describe_snapshots(OwnerIds=['self'])['Snapshots']

    with open('ec2_snapshots.csv', mode='w', newline='') as csv_file:
        fieldnames = ['Instance Name', 'Snapshot ID', 'Volume Size (GiB)', 'Snapshot Date Started']
        writer = csv.DictWriter(csv_file, fieldnames=fieldnames)
        writer.writeheader()

        for snapshot in snapshots:
            instance_id = extract_instance_id(snapshot['Description'])
            instance_name = get_instance_name(ec2, instance_id)
            snapshot_id = snapshot['SnapshotId']
            volume_size = snapshot['VolumeSize']
            snapshot_date = snapshot['StartTime'].strftime("%Y-%m-%d %H:%M:%S")

            writer.writerow({
                'Instance Name': instance_name,
                'Snapshot ID': snapshot_id,
                'Volume Size (GiB)': volume_size,
                'Snapshot Date Started': snapshot_date
            })

    print("Snapshot information has been written to ec2_snapshots.csv.")

The export_snapshots_info_to_csv function performs the following steps:

Connect to the EC2 Service: Initializes a connection to the EC2 service using Boto3.
Retrieve Snapshots: Fetches a list of snapshots owned by the account.
Open CSV File: Opens a CSV file for writing.
Iterate Through Snapshots: For each snapshot, it extracts the instance ID, retrieves the instance name, and collects other snapshot details.
Write to CSV: Writes the gathered information to the CSV file.

Running the Script

To run the script, save it to a file (e.g., ec2_snapshot_info.py) and execute it using Python:

python ec2_snapshot_info.py

This command will generate a CSV file (ec2_snapshots.csv) in the same directory, containing detailed information about your EC2 snapshots.

Detailed Explanation of Script Components

AWS EC2 Client Initialization

The boto3.client('ec2') call initializes a client to interact with the EC2 service. This client will be used to make API calls to AWS.

ec2 = boto3.client('ec2')

Describing Snapshots

The describe_snapshots method fetches details about the snapshots. We specify OwnerIds=['self'] to retrieve snapshots owned by the account.

snapshots = ec2.describe_snapshots(OwnerIds=['self'])['Snapshots']

Writing to CSV

The CSV module in Python simplifies writing tabular data to files. We use csv.DictWriter to write rows of dictionaries to the CSV file. Each dictionary represents a row in the CSV.

with open('ec2_snapshots.csv', mode='w', newline='') as csv_file:
    fieldnames = ['Instance Name', 'Snapshot ID', 'Volume Size (GiB)', 'Snapshot Date Started']
    writer = csv.DictWriter(csv_file, fieldnames=fieldnames)
    writer.writeheader()

    for snapshot in snapshots:
        instance_id = extract_instance_id(snapshot['Description'])
        instance_name = get_instance_name(ec2, instance_id)
        snapshot_id = snapshot['SnapshotId']
        volume_size = snapshot['VolumeSize']
        snapshot_date = snapshot['StartTime'].strftime("%Y-%m-%d %H:%M:%S")

        writer.writerow({
            'Instance Name': instance_name,
            'Snapshot ID': snapshot_id,
            'Volume Size (GiB)': volume_size,
            'Snapshot Date Started': snapshot_date
        })

Handling Missing Information

The script gracefully handles missing information. If an instance ID or name is not found, it returns 'N/A'. This ensures that the script does not break and provides a complete CSV output.

Time Formatting

The strftime method formats the snapshot start time into a human-readable string. This makes it easier to interpret the snapshot creation dates in the CSV file.

snapshot_date = snapshot['StartTime'].strftime("%Y-%m-%d %H:%M:%S")

Conclusion

Automating EC2 snapshot management with Python significantly enhances your AWS infrastructure management. This script provides a reliable, repeatable process for documenting and analyzing your snapshots, ensuring your backup strategy is robust and well-documented.

Incorporate this script into your regular AWS maintenance routines to gain better visibility into your snapshot strategy, optimize your backup processes, and free up time for more critical tasks. By leveraging automation, you can ensure your data is secure and readily available, enhancing the overall efficiency and reliability of your AWS environment.

Feel free to customize and expand this script to suit your specific needs, such as adding more snapshot details or integrating with other AWS services. Automation is a powerful tool, and this script is just the beginning of what you can achieve with AWS and Python.

Conquering Cloud Chaos: Multi-Account Experiments with AWS FIS Injector

Oluwasegun Adedigba — Wed, 31 Jan 2024 11:35:12 +0000

In the sprawling, multi-account ecosystems of the modern cloud, ensuring application resilience can feel like an endless game of whack-a-mole. Resources scattered across numerous accounts, complex dependencies, and limited visibility make testing fault tolerance a challenging, fragmented affair. But fear not, cloud explorers, for AWS Fault Injection Service (FIS) Injector has just unveiled a weapon to conquer this chaos: multi-account experiments.

Breaking Down the Walls:

Traditionally, FIS Injector experiments were confined to the walls of a single AWS account. While immensely valuable, this limitation left multi-account applications, the norm in enterprise cloud environments, exposed to blind spots. Enter multi-account experiments, a groundbreaking feature that extends FIS Injector's reach beyond account boundaries, enabling you to:

Inject faults across multiple accounts: Simulate real-world failure scenarios that span interconnected resources in different accounts, providing a holistic view of your application's resilience.
Centralized control, decentralized execution: Orchestrate and monitor experiments from a single "orchestrator" account, while FIS Injector seamlessly injects faults in target accounts without requiring additional configuration or access keys.
Fine-grained targeting: Utilize IAM roles and resource tags to precisely specify which accounts and resources within those accounts should participate in the experiment, ensuring efficient targeting and minimizing disruption.

Visibility Like Never Before:

Multi-account experiments aren't just about injecting faults; they're about gaining deep insights into your application's behavior across accounts. With this feature, you'll enjoy:

Unified view of experiment results: The FIS Injector console consolidates logs, metrics, and insights from all participating accounts, offering a comprehensive picture of your application's response to injected faults.
Granular analysis: Drill down into individual account data to pinpoint specific vulnerabilities or areas for improvement.
Streamlined incident response: Identify cross-account dependencies and potential domino effects of failures, enhancing your incident response preparedness.

Beyond Experiments, Automation Awaits:

Multi-account experiments are just the tip of the iceberg. This feature paves the way for robust automation scenarios, including:

Schedule recurring tests: Automate fault injection across multi-account applications on a regular basis, proactively identifying and addressing potential weaknesses.
Integrate with CI/CD pipelines: Inject faults within your CI/CD pipelines to validate application resilience early and often, preventing bugs from reaching production.
Trigger pre-defined response actions: Configure automatic corrective actions, such as scaling up resources or triggering alerts, in response to specific failures identified through multi-account experiments.

A New Era of Cloud Confidence:

Multi-account experiments in FIS Injector mark a significant leap forward in cloud application resilience testing. By shattering the boundaries between accounts, the feature empowers you to:

Build confident architecture: Proactively test and strengthen your multi-account applications, ensuring they can withstand real-world disruptions.
Reduce downtime and operational costs: Identify and address vulnerabilities before they become critical incidents, minimizing downtime and associated costs.
Improve agility and innovation: Experiment freely with new services and configurations across accounts, knowing your applications are resilient and ready to handle change.

If you would like to know more about this tool, check here.

In conclusion, multi-account experiments in AWS FIS Injector are a game-changer for managing complex, multi-account cloud applications. By overcoming the limitations of single-account testing, this feature allows you to build resilient, confident applications that can thrive in the ever-evolving cloud landscape. So, shed your doubts about multi-account resilience and embrace the power of FIS Injector's cross-account reach. The path to a more assured cloud future awaits!

Tame the Cloud Jungle: Mastering Applications with AWS myApplications

Oluwasegun Adedigba — Wed, 31 Jan 2024 11:25:59 +0000

Managing applications in the sprawling wilderness of the cloud can feel like trekking through an untamed jungle. Resources sprawl across regions, services intertwine like hidden vines, and monitoring becomes a herculean task. Fear not, weary explorer, for AWS has unveiled a machete to carve a path through the chaos: myApplications.

What is myApplications?

Imagine a central clearing in the cloud, where your applications stand tall and visible. Each application, meticulously tagged and organized, displays its vital stats like cost, health, security posture, and performance on a customized dashboard. This, my friend, is the essence of myApplications. It's a one-stop shop for managing and monitoring your applications on AWS, simplifying the once-daunting task of navigating the cloud's sprawling ecosystem.

Building Your Cloud City:

Creating Applications:

Forget the days of resource sprawl. With myApplications, you can define your applications by adding relevant resources, be it EC2 instances, S3 buckets, or Lambda functions. The process is as simple as tagging resources with the "application" tag during creation or selecting existing resources you wish to corral under one banner. These tagged resources automatically populate your myApplications dashboard, transforming scattered cloud entities into a cohesive application portfolio.

Visualization is Key:

The myApplications dashboard becomes your application command center. Cost insights, security findings, and performance metrics are presented in clear, actionable widgets. No more digging through cryptic logs or navigating labyrinthine menus. At a glance, you can identify cost spikes, security vulnerabilities, or performance bottlenecks, allowing you to react swiftly and efficiently.

Beyond Monitoring:

myApplications isn't just a glorified dashboard. It empowers you to take action directly from the command center. Need to adjust an autoscaling policy? Optimize an Amazon RDS instance? Deploy a new patch to your Lambda function? With myApplications, these actions are just a click away, reducing context switching and streamlining your workflow.

Extending the Reach:

myApplications integrates seamlessly with your existing tools and workflows. The data displayed isn't confined to the dashboard; it's readily accessible through APIs, the CLI, and SDKs. This means you can build custom scripts, automate alerts, and integrate myApplications data into your preferred infrastructure as code tools like CloudFormation and Terraform.

Benefits Galore:

The advantages of taming your cloud applications with myApplications are numerous:

Enhanced Visibility: Gain a holistic view of your application portfolio, from cost to performance.
Reduced Complexity: Organize resources logically, simplifying management and troubleshooting.
Proactive Monitoring: Identify issues before they become critical through actionable insights.
Improved Resource Utilization: Optimize resource allocation based on real-time performance data.
Streamlined Workflows: Take action directly from the dashboard and integrate with existing tools.
Reduced Costs: Gain insights to optimize spending and avoid unnecessary resource usage.

Getting Started with myApplications:

Embarking on your application management journey with myApplications is as simple as logging into the AWS Management Console. The Console Home welcomes you with an Applications widget, prompting you to create your first application or onboard existing resources. From there, follow the intuitive wizard and watch your applications come to life on the dedicated myApplications dashboard.

For more information on this service, check here.

Conclusion:

AWS myApplications is a game-changer for managing applications in the cloud. It provides the much-needed visibility, control, and efficiency that were missing in the ever-expanding cloud landscape. So, grab your machete, shed your frustration with sprawling resources, and reclaim your sanity with AWS myApplications. The path to a well-managed application portfolio awaits!

AWS Lambda Inventory: How to List and Analyze Lambda Functions and CloudWatch Metrics with AWS SDK

Oluwasegun Adedigba — Mon, 18 Dec 2023 15:39:47 +0000

Introduction:
AWS Lambda has revolutionized serverless computing, providing unparalleled scalability and flexibility. However, efficient management and monitoring of Lambda functions are paramount for optimizing performance. In this blog post, we'll explore a Python script leveraging Boto3 and CloudWatch to create a detailed inventory of Lambda functions, including their runtimes and invocation statistics over the last month.

Prerequisites:

AWS account with Lambda functions deployed.
Basic knowledge of AWS Lambda, CloudWatch, and Python.

Creating a Lambda Inventory:
The Python script utilizes Boto3, the AWS SDK for Python, to interact with AWS Lambda and CloudWatch. Let's break down the key components:

Listing Lambda Functions:

lambda_client = boto3.client('lambda')

def list_lambda_functions():
    response = lambda_client.list_functions()
    return response['Functions']

The list_lambda_functions function retrieves a list of Lambda functions using the list_functions API call.

Checking Lambda Invocations:

cloudwatch_client = boto3.client('cloudwatch')

def check_lambda_invocations(function_name):
    end_time = datetime.utcnow()
    start_time = end_time - timedelta(days=30)  # 1 month

    response = cloudwatch_client.get_metric_statistics(
        Namespace='AWS/Lambda',
        MetricName='Invocations',
        Dimensions=[{'Name': 'FunctionName', 'Value': function_name}],
        StartTime=start_time,
        EndTime=end_time,
        Period=2592000, 
        Statistics=['Sum']
    )
    return response['Datapoints'][0]['Sum'] if response['Datapoints'] else 0

The check_lambda_invocations function queries CloudWatch for invocation statistics for a specified Lambda function over the last month.

Generating the Inventory CSV:

csv_file = 'lambda_inventory.csv'

with open(csv_file, mode='w', newline='') as file:
    writer = csv.writer(file)
    # Write header row
    writer.writerow(['FunctionName', 'Runtime', 'Invocations'])

    # List Lambda functions and write details to the CSV file
    lambda_functions = list_lambda_functions()
    for function in lambda_functions:
        function_name = function['FunctionName']
        runtime = function['Runtime']
        invocations = check_lambda_invocations(function_name)
        writer.writerow([function_name, runtime, invocations])

The script opens a CSV file, writes a header row, lists Lambda functions, checks their invocations, and writes the details to the CSV file.

For more information on CloudWatch API and Lambda API calls, check out the API references for Lambda and CloudWatch.

Conclusion:
With this Python script, you can effortlessly generate a comprehensive inventory of your AWS Lambda functions, including runtime details and invocation statistics over the last month. This inventory is invaluable for performance optimization, resource allocation, and understanding the usage patterns of your serverless architecture. Consider integrating this script into your regular monitoring routine for enhanced AWS Lambda management.

Thank you for making it this far! Kindly comment and review.