ACME-Built Solutions
Four production-proven automation solutions built by the ACME engineering team and deployed for clients across Bahrain. Each one solves a specific, common cost or reliability problem on AWS.
Eliminates cost waste from test and development environments running 24/7. Lambda functions automatically stop instances outside business hours and restart them on schedule or on demand,with a typical saving of 65–75% on non-production compute costs.
In most organisations, non-production environments (development, staging, testing, UAT) run continuously even though they are only actively used 8–10 hours per day during business days. A team with 10 non-production instances paying $0.10/hr per instance wastes approximately $14,400/year running instances overnight and on weekends,for zero business value.
Two Lambda functions are deployed,one to stop instances, one to start them. CloudWatch Events rules trigger these functions on a configurable schedule (e.g. stop at 8 PM, start at 7 AM Sunday through Thursday). Instances to be managed are identified by a tag (AutoStop=true). The solution handles licensed software correctly via AWS License Manager integration, ensuring software licenses are released and reacquired properly.
CloudWatch Events (schedule)
|
v
Lambda: stop-ec2-instances
|--> Reads EC2 tags (AutoStop=true)
|--> Saves instance state to S3
|--> Calls ec2:StopInstances
|--> Publishes SNS notification
|--> Notifies AWS License Manager
CloudWatch Events (schedule)
|
v
Lambda: start-ec2-instances
|--> Reads state file from S3
|--> Calls ec2:StartInstances (running only)
|--> Publishes SNS notification
Assuming a 40-hour business week in a 168-hour week, non-production instances run approximately 76% of the time unnecessarily. For a typical environment with 10 medium instances at an average of $0.10/hr:
Real deployment: ACME deployed this solution for the Ministry of Youth & Sports as part of their iGA migration project, delivering ongoing post-migration cost savings on all non-production environments.
A CloudFormation template that automatically provisions CloudWatch alarms for EC2 auto-recovery. When an underlying hardware failure is detected, the instance recovers automatically,retaining its Instance ID, private IP, Elastic IP, and all EBS volumes. Zero manual intervention. Full audit trail in CloudTrail.
EC2 instances can fail due to underlying hardware issues,network failures, power loss on a host, or hardware degradation. Without automated recovery, these failures require manual detection, a support ticket to AWS, and manual intervention to restart or migrate the instance. Mean time to recover (MTTR) can be 30–90 minutes or more. For critical workloads, this is unacceptable.
The CloudFormation template creates a CloudWatch alarm for every EC2 instance using the StatusCheckFailed_System metric. When this metric triggers (indicating an AWS hardware failure, not an OS-level issue), the alarm action calls ec2:RecoverInstances,AWS's built-in recovery action that migrates the instance to healthy hardware.
Resources:
EC2RecoveryAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: !Sub "EC2-AutoRecovery-${InstanceId}"
MetricName: StatusCheckFailed_System
Namespace: AWS/EC2
Statistic: Minimum
Period: 60
EvaluationPeriods: 2
Threshold: 1
ComparisonOperator: GreaterThanOrEqualToThreshold
Dimensions:
- Name: InstanceId
Value: !Ref InstanceId
AlarmActions:
- !Sub "arn:aws:automate:${AWS::Region}:ec2:recover"
- !Ref PagerDutySNSTopic
EC2 auto-recovery works on instances with an EBS root volume (not instance store). It also requires instance types that support the feature (most current generation types do). ACME validates these requirements during deployment. For instance store instances or unsupported types, ACME configures Auto Scaling group health checks as an alternative.
Important: This solution recovers from hardware failures, not OS-level crashes. For OS-level resilience, pair with CloudWatch agent monitoring and application-level health checks via an Application Load Balancer.
Solves the silent risk of new EC2 instances being missed by AWS Backup because they lack the required tag. A Lambda function automatically detects newly launched instances and applies the backup enrollment tag,no manual step required, no instance left unprotected.
AWS Backup uses tag-based policies to identify which resources to protect. When a new EC2 instance is launched without the required backup tag, it is silently excluded from backup plans,until someone notices, which is often only after a data loss event. In environments with frequent instance launches (auto-scaling groups, developer provisioning, migration waves), this gap grows rapidly.
A CloudWatch Events rule monitors EC2 instance state changes for the running state. When a new instance enters the running state, it triggers a Lambda function that:
ec2:DescribeTags to check if the backup tag existsBACKUP=YES (or your organisation's configured tag) via ec2:CreateTagsThe solution supports multiple AWS accounts via IAM cross-account roles, enabling centralised backup governance from a single management account.
Management Account
|
|-- Lambda (backup-tagger)
| |-- Assumes cross-account role in Account A
| |-- Assumes cross-account role in Account B
| |-- Assumes cross-account role in Account C
|
CloudWatch Events (ec2:state-change)
SNS (tagging summary notifications)
CloudWatch Logs (full audit trail)
Each Member Account:
IAM Role (backup-tagger-role)
Permissions: ec2:DescribeTags, ec2:CreateTags
Trust: Management Account Lambda role
Zero-gap protection: Because the Lambda triggers on the running state event (not a scheduled scan), new instances are tagged within seconds of launch,before any backup window could be missed.
ACME configures the solution to match your organisation's tag schema and backup policy. Common customisations include:
An innovative solution integrating WhatsApp (via Twilio API) with Amazon Lex and AWS Cost Explorer to deliver on-demand and scheduled billing reports through a conversational chatbot. Ask your bill in plain English,get an instant answer on WhatsApp.
AWS cost visibility is critical, but Cost Explorer requires AWS Console access,a barrier for finance teams, department managers, and non-technical stakeholders who need billing awareness. Traditional reporting relies on email digests that get ignored. Finance teams end up chasing IT for cost updates, and surprises appear at month-end.
Users send messages to a dedicated WhatsApp Business number via Twilio. The Twilio webhook forwards the message to an API Gateway endpoint, which triggers a Lambda function. Lambda passes the message to Amazon Lex for intent classification. Based on the detected intent, Lambda queries AWS Cost Explorer and returns a formatted response,all within seconds.
Example conversations supported:
WhatsApp User
|
v
Twilio API (WhatsApp Business)
|
v
API Gateway (POST /webhook)
|
v
Lambda: message-router
|--> Amazon Lex (intent classification)
|
|-- Intent: GetMonthlyCost
| --> Cost Explorer API --> formatted response
|
|-- Intent: GetServiceBreakdown
| --> Cost Explorer + Dimensions --> response
|
|-- Intent: GetInventory
| --> EC2 DescribeInstances --> response
|
|-- Intent: ScheduleReport
--> CloudWatch Events (create rule)
Amazon Connect: voice escalation fallback
CloudWatch Events: scheduled report triggers
Security note: The WhatsApp number is restricted to a whitelist of authorised phone numbers. All Cost Explorer queries use a read-only IAM role. No write permissions are granted to the chatbot.
WhatsApp has near-universal adoption across the GCC. Unlike email dashboards or Slack bots, WhatsApp notifications are read immediately. For organisations where finance and operations teams are not AWS Console users, WhatsApp is the most natural interface for cost awareness. The solution requires no app installation, no training, and no new accounts for end users.
ACME can deploy any of these solutions within days. Talk to our AWS engineers about which ones fit your cost and reliability goals.
Start the Conversation