Deployed a serverless solution with two chained Lambda functions: one extracts sales data from a MySQL database running on EC2 inside a VPC, the other formats the report and publishes it to SNS for email delivery. Includes a real troubleshooting cycle around VPC networking and a scheduled trigger via EventBridge.
Two Lambda functions chained behind an EventBridge schedule. The orchestrator
(salesAnalysisReport) invokes the extractor (salesAnalysisReportDataExtractor),
which queries the café MySQL database living inside a private VPC subnet. The orchestrator then
publishes a formatted email message to SNS.
| # | Action |
|---|---|
| 1 | An EventBridge / CloudWatch Events rule fires the salesAnalysisReport Lambda daily at 8 PM UTC, Monday – Saturday. |
| 2 | salesAnalysisReport invokes salesAnalysisReportDataExtractor synchronously, passing DB connection params from SSM Parameter Store. |
| 3 | salesAnalysisReportDataExtractor runs an analytical SQL query against the cafe_db MySQL database on an EC2 LAMP instance. |
| 4 | The result set is returned to salesAnalysisReport as JSON. |
| 5 | salesAnalysisReport formats the report into a plain-text message and publishes it to the salesAnalysisReportTopic SNS topic. |
| 6 | SNS fans the message out to the email subscriber (the administrator). |
salesAnalysisReportRole — used by the orchestrator. Grants sns:Publish, ssm:GetParameter and lambda:InvokeFunction.
salesAnalysisReportDERole — used by the extractor. Includes AWSLambdaVPCAccessExecutionRole so Lambda can create the ENIs needed to reach the VPC, plus CloudWatch Logs.
The extractor is the only function that needs to live inside the VPC (it must reach the MySQL EC2 instance). Keeping the orchestrator outside the VPC lets it publish to SNS over the public AWS endpoint without needing a NAT gateway or VPC endpoint, and keeps cold-start cheap.
Tasks with screenshot evidence are documented in detail; tasks without evidence are summarized in a few lines so the report stays a logbook, not a transcription of the guide.
Uploaded pymysqlLibrary.zip to the Layers section of the Lambda
console as pymysqlLibrary, compatible with Python 3.9. The zip
respects the Lambda path convention
(python/lib/python3.X/site-packages/…) so the runtime can import pymysql
with no extra configuration. The layer is later attached to the extractor function — visible as
Layers (1) in the next screenshot.
salesAnalysisReportDataExtractor Lambda functionsalesAnalysisReportDataExtractor-v2.zip as the function code.pymysqlLibrary layer — the function now imports pymysql at runtime.dbUrl, dbName, dbUser, dbPassword — and opens a connection with pymysql.connect(...). The SQL aggregates daily sales grouped by product.
boto3, pymysql and sys, with the try / pymysql.Error pattern that produces the diagnostic message used later.vpc-0e848e4cccd4f29f1 (10.200.0.0/20) — the Café VPC.
AWSLambdaVPCAccessExecutionRole in the role is what lets Lambda
attach those ENIs on demand.
SARDETestEvent with the four DB parameters as JSON.Runtime.ExitError.
Runtime.ExitError; the log output shows the underlying pymysql.Error bubbling up through the sys.exit() call.The full error from the log:
ERROR: Failed to connect to the Cafe database.
Error Details: 2003 Can't connect to MySQL server on '<value of /cafe/dbUrl parameter>' ([Errno 16] Device or resource busy)
Runtime.ExitErrorThis is the most honest piece of evidence in the lab: it proves the extractor was actually deployed, tested, and reached the network layer before failing. The next section diagnoses and fixes it.
The failure above was the most useful moment of the lab. Walking through it forced a real diagnosis of how Lambda networking interacts with EC2 security groups.
Runtime.ExitError after ~1 s. Log: 2003 Can't connect to MySQL server.
The function reached the network and tried TCP/3306, but the connection timed out. DNS works, the IP is reachable, so the problem is at L4 — a firewall is dropping the packets.
CafeSecurityGroup had inbound rules for HTTP/80 and SSH/22, but nothing for MySQL/Aurora 3306. The Lambda ENI lives in the same SG, but an SG does not allow internal traffic unless an explicit rule says so.
Added an inbound rule: MYSQL/Aurora · TCP · 3306 with source = CafeSecurityGroup (self-reference). Now any ENI in that SG — including the Lambda's — can open a TCP connection to 3306 on any other ENI in the same SG.
53.29 ms. Response {"statusCode":200,"body":[]} — empty list because there were no orders in the Café database yet.The second Lambda formats the email and publishes to SNS. The interesting bit is that it was created from the AWS CLI, not the console — exactly the kind of one-liner that belongs in a SysOps logbook.
Created a standard SNS topic salesAnalysisReportTopic in us-west-2,
then added an Email subscription with the personal Gmail address.
Confirmed the subscription via the "AWS Notification — Subscription Confirmation"
email. The topic ARN is later wired into the orchestrator function as an environment variable.
salesAnalysisReport via AWS CLI
Connected to the EC2 instance via Session Manager / EC2 Instance Connect and
ran aws lambda create-function directly. The zip was uploaded to the instance
beforehand by the lab provisioning.
aws lambda create-function \
--function-name salesAnalysisReport \
--runtime python3.9 \
--zip-file fileb://salesAnalysisReport-v2.zip \
--handler salesAnalysisReport.lambda_handler \
--region us-west-2 \
--role <salesAnalysisReportRoleARN>
State: Pending, then FunctionArn: arn:aws:lambda:us-west-2:…:function:salesAnalysisReport.--runtime python3.9,
but the screenshot shows the function created with python3.14. The CLI output is
the real one; the command is shown above with the guide's requested runtime for fidelity, and
the divergence is documented here because it shows the lab actually being executed with whatever
runtime was current at the time.
After creation, the orchestrator was configured with an environment variable
topicARN pointing to the SNS topic ARN — the Python code reads it at line ~26 to
publish the report.
salesAnalysisReport manually from the console with an empty test event.SNS:Publish.
Created an EventBridge rule with a cron schedule expression and the
salesAnalysisReport Lambda as target. AWS cron has 6 fields in UTC:
cron(Minutes Hours Day-of-month Month Day-of-week Year)
# Example for the lab — 8 PM UTC, Monday through Saturday:
cron(0 20 ? * MON-SAT *)
Either Day-of-month or Day-of-week must be ? — they
can't both be specified, because that would over-constrain the date. No screenshot — the rule
creation page itself is not interesting, what matters is the expression above.
PyMySQL) — they keep the function package small and reusable across functions.? is mandatory in one of the two day fields. Forgetting this is the #1 reason scheduled rules silently fail to save.The lab is a small but complete serverless pipeline: cron → orchestrator Lambda → extractor Lambda in VPC → MySQL → SNS → email. The real lesson is not the wiring itself — it's the networking layer.
The MySQL timeout error was not a bug in the code, the IAM role or the layer; it was the
security group missing a rule. That kind of failure is invisible from the function logs until
you read them carefully — 2003 Can't connect always means a network boundary, not
a credential problem.
Fixing it once leaves a permanent intuition: when a Lambda inside a VPC fails to reach a resource, the first thing to check is the target's SG inbound rules and whether the Lambda's SG is allowed there.