We close the module with the piece that is still missing. Everything MercadoFresco has built so far starts from the same idea: there is a server switched on, waiting for work. The shop's EC2 instance is running even when it is Tuesday at 4 in the morning. So is the RDS instance. And all 730 hours of the month are paid for.

But there are tasks that do not fit that model. Generating the thumbnail of a photo when Luis uploads it happens twenty times a day and takes two seconds. Looking up the status of an order is a one-off call. Processing a delivery-route file happens once every morning. Keeping a server switched on for 730 hours to do 40 minutes of work a month is absurd.

AWS Lambda runs code only when something happens and only charges while it is running, with millisecond precision. In this lesson we finally connect the S3 event we left configured back in 02-03 and write the function that generates the thumbnails for MercadoFresco's product catalogue.

1. What serverless computing is and how it differs from EC2
2. The execution model: handler, event, context and response
3. Cold starts and warm starts
4. Concurrency: reserved, provisioned and the account limit
5. Configuration: memory, CPU, timeout, variables and architecture
6. The thumbnail function: the code
7. Packaging with dependencies and layers
8. Deploying from the console and from the CLI
9. Permissions: the execution role and least privilege
10. Logs in CloudWatch Logs and debugging
11. Common event sources
12. A second function: querying an order's status over HTTP
13. The real limits you need to know
14. Pricing, with MercadoFresco's concrete calculation
15. Errors, retries and dead-letter queues
16. Module recap: what is already in AWS and what is still missing

"Serverless" does not mean there are no servers: it means they are not yours, you never see them and you do not pay for them when they are not working. AWS provisions the capacity, scales it and takes it away again, all of it invisible.

The criteria for choosing, in order of practical usefulness:

1. Does the task take less than 15 minutes? If not, Lambda is ruled out.
2. Is the traffic irregular or event-driven? Lambda wins by a mile. If it is steady and constant 24×7, a container or an EC2 works out cheaper.
3. Do you need control of the operating system or state on disk? Then EC2 or containers.
4. How much team time do you want to spend on infrastructure? Lambda is the least possible.

For MercadoFresco, generating thumbnails meets all four criteria perfectly: seconds of duration, triggered by sporadic events, stateless, and with nothing to administer.

A Lambda function is an ordinary function in your language with a specific signature:

The full life cycle, which is worth understanding properly because performance and cost both depend on it:

This is where Lambda's most profitable optimisation comes from, and it is a single line of code:

And this is also where the matching trap comes from: the environment is reused, so global variables persist between invocations. That is handy for caches, but disastrous if you accumulate state by accident:

A cold start is the time AWS takes to prepare a new environment: creating the microVM, downloading the code and the layers, initialising the interpreter and running the global code.

When it really matters: if the Lambda answers a synchronous request from a user (an API), an extra 1.5 seconds is unacceptable. If it processes an asynchronous event (a photo's thumbnail), nobody cares.

Mitigation strategies, from cheapest to most expensive:

1. Move work into the global code and keep the package small. Free.
2. Choose a lightweight language. Python or Node for latency-critical functions.
3. Raise the memory. More CPU speeds up initialisation, and often the total cost does not go up because the execution is shorter.
4. Provisioned concurrency. AWS keeps N environments always ready. It eliminates cold starts entirely, but you pay for it even when it is not used.

Lambda does not queue requests: it creates new environments. If 100 events arrive at the same time, 100 instances of the function run at once. That is its great strength and also its risk.

Reserved concurrency has a double effect that is worth understanding:

• It guarantees that the function will always be able to use that amount, even when others are saturating the account.
• It caps that function at that maximum. It is a brake.

That brake is exactly what MercadoFresco needs in order to protect the database:

Without that limit, a traffic spike could open hundreds of connections to mercadofresco-pedidos and bring the database down. It is a real and frequent case: Lambda scales, RDS does not.

This is the parameter most people get wrong. In Lambda you only allocate memory, from 128 MB to 10,240 MB, and the CPU is allocated proportionally:

The consequence is counter-intuitive and deserves a calculation. Take a function processing an image:

More memory can cost exactly the same or less, and be eight times faster. Setting 128 MB "to save money" is usually a mistake: the function takes so long that the cost does not drop and the latency goes through the roof. The AWS Lambda Power Tuning tool automates this analysis.

From 1 second to 15 minutes (900 s), with 3 seconds as the default. The rule: set it a little above what the function actually takes, never at the maximum. A timeout of 900 s on a function that should take 2 s means a hang will be billed for 15 minutes.

They are encrypted at rest automatically, but they are visible in the console to anyone with read permission. Never put passwords there: use Secrets Manager or Parameter Store (lesson 04-03), as we did with RDS in 02-04.

Choose arm64 unless a dependency stops you. It is a 20 % saving for changing one parameter. The only precaution is that libraries with native code —such as Pillow, which we are about to use— have to be packaged for the right architecture.

Here is the goal. In lesson 02-03 we configured the notification on the mercadofresco-catalogo-fotos bucket so that every .jpg uploaded under productos/ would trigger the function mercadofresco-generar-miniaturas. Now we are going to write it.

The details in that code are what separate a tutorial example from something that survives in production:

• unquote_plus on the key. S3 encodes names in the event. Without this line, any photo with spaces or accented characters would give NoSuchKey. It is the number one bug in S3 Lambdas.
• event["Records"] is a list. A single event can carry several records. Processing it with event["Records"][0] works in testing and fails in production.
• An output prefix different from the input one, plus the explicit check. Double protection against the recursive loop.
• raise on recoverable errors. Lambda automatically retries asynchronous invocations; swallowing the exception with a return would let the failure go unnoticed.
• NoSuchKey is handled separately. It is a non-recoverable error: retrying it three times is time and money wasted.
• Tagging the object with the project's scheme, consistent with what we have been doing.

Pillow is not included in the Lambda environment: you have to supply it. There are three ways and it is worth knowing when to use each one.

For MercadoFresco, a layer with Pillow is the right choice: it will be shared by the thumbnail function and by the ones that come later, and it keeps the code package small (faster cold starts and editing still possible in the console).

The layer's directory structure is not negotiable: Python looks for libraries in /opt/python, and AWS unpacks the layer into /opt. That is why everything has to hang from a directory called exactly python/. Each language has its own path (nodejs/node_modules for Node.js).

1. Console → Lambda → Ireland region → Create function.
2. Author from scratch. Name: mercadofresco-generar-miniaturas. Runtime: Python 3.12. Architecture: arm64.
3. Change default execution role → create a new one (we will tighten it in the next section).
4. Paste the code into the editor or upload the ZIP.
5. Configuration → General configuration: memory 1,024 MB, timeout 30 s.
6. Configuration → Environment variables: the four we defined earlier.
7. Layers → Add a layer → mercadofresco-imagen.
8. Triggers → Add trigger → S3 → bucket mercadofresco-catalogo-fotos, event All object create events, prefix productos/, suffix .jpg.
9. Tags: the project's mandatory scheme.

Updating the code after a change:

--publish creates an immutable numbered version. Combined with aliases (produccion, pruebas), it allows gradual deployments by sending, for example, 10 % of the traffic to the new version. It is another piece against MercadoFresco's problem 4, the risky deployments, which is tackled head-on in module 8.

Testing without uploading anything to S3:

--log-type Tail returns the last 4 KB of the log encoded in base64: the quickest way to debug without leaving the terminal.

Cost warning. Lambda's free tier is permanent, not 12 months: 1 million requests and 400,000 GB-seconds a month, forever. This exercise will not cost you anything. Even so, delete the function when you finish if you are not going on: aws lambda delete-function --function-name mercadofresco-generar-miniaturas. And remember to remove the bucket notification and the layer too if you are not using them.

A Lambda function has no credentials of its own: it assumes an IAM execution role, and that role's permissions are exactly what the function can do. No more, no less.

The trust policy, which defines who can assume the role:

And the permissions policy, which defines what it can do. Here is the principle of least privilege applied rigorously:

Four deliberate decisions, and each one avoids a real problem:

1. s3:GetObject only under productos/. If the function is compromised, it cannot read the sales reports or the database backups.
2. s3:PutObject only under miniaturas/. Even if there were a logic bug, the function cannot overwrite the original photos. It is the last line of defence against the recursive loop: even if the bucket filter failed, the writer has no permission on the input prefix.
3. No s3:DeleteObject. The function does not need to delete anything, so it cannot.
4. Logging scoped to its own log group, not to *.

Compared with the common practice of attaching AmazonS3FullAccess "so that it works", the difference between a minor incident and a full data leak lies in these three statements. The complete logic of IAM, roles, policies and how they are evaluated is lesson 04-01.

Every function automatically writes to a log group called /aws/lambda/<function-name>. Everything you print with print() or logger.info() ends up there.

At the end of every invocation, Lambda writes a REPORT line that is pure gold for tuning the configuration:

How to read it:

In this case the temptation is to drop the memory to 256 MB. Careful: remember that the CPU is proportional. With 256 MB the function would take around 7 seconds instead of 1.8, and the cost would be practically the same with four times the latency. The right move is to try 512 MB and measure.

Two other basic debugging capabilities:

• Automatic CloudWatch metrics: Invocations, Errors, Duration, Throttles, ConcurrentExecutions. An alarm on Errors > 0 is the bare minimum in production.
• Structured JSON logs: by setting the log format to JSON, the fields can be queried with CloudWatch Logs Insights without parsing text.

Monitoring in depth —dashboards, alarms, retention, Logs Insights— is lesson 05-01, and the distributed tracing of a request that crosses several functions and services is 05-02.

Lambda integrates with more than 200 services. These are the ones that matter when you start:

The three invocation modes have very different consequences for error behaviour:

The first function reacted to an internal event. Now we are going to expose a function to the internet so that MercadoFresco's mobile app can look up the status of an order.

There are two ways of putting HTTP in front of a Lambda:

We start with a Function URL for simplicity, knowing that production will ask for API Gateway.

Four design decisions that deserve attention:

• The database connection lives in the global scope and is reused. Opening a connection to PostgreSQL costs tens of milliseconds; doing it on every invocation would multiply the latency and saturate RDS.
• Reserved concurrency of 20 as a ceiling on connections. Without it, a spike could open hundreds of connections and bring mercadofresco-pedidos down. It is the lesson from 02-04 applied: Lambda scales, RDS does not. (For demanding cases there is RDS Proxy, which pools connections; it is outside the scope of this lesson.)
• A parameterised query with %s, never string concatenation. SQL injection avoided.
• Internal errors are not detailed to the client: they are logged to CloudWatch and a generic message is returned.

The 15-minute limit is the one that conditions the most architectural decisions. If the nightly process that recompresses the catalogue's 40,000 photos takes 3 hours, it is not a job for a single Lambda: either it is split into 40,000 two-second invocations (which do fit perfectly), or it runs as a container task. Splitting is almost always the right answer with Lambda.

Lambda charges for two things:

1. Requests: 0.20 USD per million.
2. Duration: 0.0000166667 USD per GB-second (x86_64; arm64 is 20 % less).

And the free tier is permanent, not 12 months: 1 million requests and 400,000 GB-seconds a month, forever.

Case 1: the thumbnail function. Luis uploads about 20 photos a day (600 a month), the function uses 1,024 MB and takes 1.8 seconds:

Zero cost. The equivalent on a t3.micro EC2 kept running to do the same would be around 7.50 USD a month. This is exactly the use case Lambda exists for.

Case 2: the order status endpoint, in the realistic scenario. MercadoFresco receives around 900,000 queries a month, the function uses 512 MB and takes 120 ms, on arm64:

Case 3: growth to three more cities (problem 3). Ten times the traffic: 9 million queries a month:

Less than 4 dollars a month to serve 9 million requests, with no server to administer, patch or watch over. When the load is irregular and event-driven, the serverless model is very hard indeed to beat.

The break-even point, worth keeping in mind: above a sustained utilisation of 50-60 % of a server, a container or a reserved EC2 works out cheaper. Lambda is expensive if you use it as though it were an always-on server.

What happens when the function fails depends on the invocation mode:

"The event is discarded" is the dangerous phrase. If the thumbnail function fails three times on one particular photo, that photo is left with no thumbnail and nobody finds out. The protection is an on-failure destination or a dead-letter queue (DLQ): somewhere for the events that could not be processed to end up, so they can be reviewed and reprocessed.

Three principles to respect from day one:

1. Idempotency. Delivery is "at least once": the same photo can be processed twice. Our function satisfies this because regenerating a thumbnail over itself gives the same result. If the function incremented a counter or charged a payment, it would need explicit protection.
2. Tell recoverable errors from unrecoverable ones. A network timeout deserves a retry; a NoSuchKey does not. Retrying the unrecoverable is time and money thrown away.
3. Watch the DLQ. A failure queue nobody looks at is the same as not having one. An alarm on ApproximateNumberOfMessagesVisible > 0 is mandatory.

Here we are only setting out the concept. SQS is covered in lesson 07-01, and the complete patterns of idempotency, retries and dead-letter queues are lesson 07-05.

This is the point in the course where it is worth looking up. MercadoFresco started module 2 with a physical server in the office; it finishes with this:

What is solved and what is not:

And what still does not exist, which is a great deal:

• A network of our own. Everything lives in the default VPC, with the instances exposed. We still have to design public and private subnets, route tables, and move the database into a subnet with no way out to the internet. Module 3.
• A load balancer. The four instances in the ASG do not get traffic spread across them, and there is no HTTPS or custom domain. 03-03 and 03-05.
• Content delivery. 97 % of the S3 bill was outbound transfer: CloudFront fixes that. 03-04.
• Identity and secrets done properly. We have used roles and Secrets Manager in passing; the full IAM structure, encryption with our own keys and protection against attacks are still missing. Module 4.
• Observability. We have scattered metrics and the odd log. We are missing a system of dashboards, alarms, traces and an audit trail of who did what. Module 5.
• Infrastructure as code. We have created everything by hand or with one-off commands: it is neither reproducible nor reviewable. Module 9.

• Creating boto3 clients inside the handler. You pay 100-300 ms on every invocation. Always in the global scope.
• Not decoding the S3 key with unquote_plus. Any photo with spaces or accented characters will fail with NoSuchKey. It is the number one bug in S3-triggered Lambdas.
• Processing only event["Records"][0]. An event can carry several records. Always iterate.
• Writing to the same prefix that triggers the function. Infinite loop. Filter by prefix and restrict the role's write permissions, as a double defence.
• Allocating 128 MB "to save money". The CPU is proportional to the memory: the function is so slow that the cost does not drop and the latency soars. Measure with Max Memory Used.
• Leaving the timeout at 900 s by default. A hang will be billed for 15 minutes.
• Keeping state in global variables without control. The environment is reused and a global list grows until it exhausts the memory.
• Giving AdministratorAccess to the execution role. Grant only the exact actions and resources the function needs.
• Forgetting lambda:add-permission for the event source. The trigger does not work and no visible error appears anywhere.
• Opening an RDS connection per invocation with no concurrency limit. A traffic spike brings the database down. Connection in the global scope and reserved concurrency.
• Not configuring an on-failure destination or DLQ for asynchronous invocations. Failed events are discarded silently.
• Returning large files in the response. The synchronous limit is 6 MB. Store in S3 and return a pre-signed URL.
• Tip: start on arm64 unless a dependency prevents it. It is a 20 % saving for changing one parameter.

For each MercadoFresco workload, decide between Lambda, EC2/container or a combination, and justify it with the criteria from the lesson:

• A) The PHP web shop, which serves traffic continuously with a peak on Fridays.
• B) Generating the invoice PDF when an order is marked as delivered (around 900 a day, 1.5 s each).
• C) Recompressing the catalogue's 40,000 photos, a process that today takes 3 hours straight.
• D) A job that every night at 03:00 exports the day's orders to S3; it takes 90 seconds.
• E) A recommendation service that loads a 4 GB model into memory and answers in under 50 ms.

The thumbnail function is configured with 1,024 MB and takes 1,800 ms. Tests with AWS Lambda Power Tuning give these results:

MercadoFresco is growing and 200,000 photos a month are now processed (already outside the free tier for duration). Calculate the duration cost of each configuration on arm64 (0.0000133334 USD per GB-second) and decide which one you would choose, taking latency into account as well.

MercadoFresco adds a third function, mercadofresco-exportar-pedidos, which every night:

1. Reads the day's orders from the RDS read replica.
2. Gets the database credentials from Secrets Manager.
3. Writes a CSV file to s3://mercadofresco-informes-analitica/informes/YYYY/MM/.
4. Sends a notification to an SNS topic when it finishes.
5. Writes its logs to CloudWatch Logs.

Write the execution role's permissions policy applying least privilege, and explain two permissions you deliberately do not include even though they might look necessary.

Solution 1.

Solution 2.

Duration cost on arm64, for 200,000 invocations:

A revealing result: the first three configurations cost exactly the same, nothing, because they all fit inside the free tier of 400,000 GB-seconds. The decision, therefore, is not an economic one but a matter of latency and headroom.

Choice: 1,769 MB. Reasons:

• It is the fastest of the three free ones: 1.15 s against 3.4 s, almost three times better.
• 1,769 MB corresponds to a full vCPU, the point where Pillow stops being CPU-bound.
• It sits at 397,900 GB-seconds, very tight against the limit. If the volume grows it will start to cost: at 300,000 photos it would be 596,850 GB-seconds, that is 2.62 USD a month. Still irrelevant.
• 3,008 MB is ruled out: it only gains 100 ms over 1,769 MB (the function is no longer CPU-bound) and it multiplies the GB-second consumption, pushing it out of the free tier.

The general lesson: above one vCPU, carrying on raising the memory stops speeding things up and starts costing money. The sweet spot is usually near 1,769 MB for single-threaded work.

Solution 3.

Two permissions deliberately NOT included:

1. s3:GetObject and s3:DeleteObject on the reports bucket. The function only writes: it does not need to read or delete anything. Leaving them out means that, if the function were compromised by a malicious dependency, it could not exfiltrate the historical sales reports or destroy them. It is the same reasoning we applied to the thumbnail function.

2. Any rds:* permission. It feels counter-intuitive, because the function queries the database, but connecting to PostgreSQL with a username and password does not go through IAM: it is a TCP connection authenticated by the engine itself. The rds:* permissions are for administering instances (creating, deleting, modifying them), and the function must not be able to do any of that. Granting them would be giving permission to delete the database to a process that only needs to read a table. (The exception would be RDS IAM authentication, which does require rds-db:connect on a specific user resource.)

Two further design details: the secret's ARN carries a trailing wildcard because Secrets Manager adds a random six-character suffix to the name; and the ec2:*NetworkInterface permissions are mandatory and with Resource: "*" when the function connects to resources inside a VPC —it is one of the very few legitimate exceptions to least privilege, imposed by the service itself.

With this lesson MercadoFresco closes its first module of real services. You know what serverless computing is and, more importantly, when not to use it: you have compared Lambda with EC2 and with containers in a table of criteria and applied the rule that above 50-60 % sustained utilisation the model stops paying off. You have mastered the execution model —handler, event, context, response— and the environment's life cycle, from which the most profitable optimisation in Lambda follows: creating the boto3 clients in the global scope, outside the handler, because the environment is reused. You know what a cold start is, what lengthens it and the four ways of mitigating it, and you know that reserved concurrency is at once a guarantee and a brake, the brake that protects RDS from Lambda's ability to scale without limit.

You have understood the memory-CPU-cost relationship, the parameter most people get wrong, and you have worked it out with real numbers: allocating 128 MB "to save money" usually costs just as much and is eight times slower. You know to choose arm64 for a 20 % saving, to set a tight timeout and not to keep passwords in environment variables.

And you have written the function that closes the circle opened in lesson 02-03: mercadofresco-generar-miniaturas fires on the s3:ObjectCreated event of the mercadofresco-catalogo-fotos bucket, decodes the key properly with unquote_plus, iterates over every record in the event, writes to a prefix different from the input one so as not to create an infinite loop, tells recoverable errors from unrecoverable ones and tags what it produces. You have packaged it with Pillow in a layer built for the right platform, deployed it from the console and from the CLI with create-function and update-function-code --publish, and given it a least-privilege execution role that can only read under productos/, can only write under miniaturas/ and cannot delete anything. You have added a second function, mercadofresco-estado-pedido, exposed through a Function URL, with the RDS connection reused between invocations, parameterised queries, concurrency capped at 20 and errors that leak no information to the client. You know how to read the REPORT line in CloudWatch Logs to tune the memory, you have walked through the common event sources noting where each one is covered, you know the real limits —15 minutes, 250 MB, 512 MB in /tmp, a 6 MB synchronous payload— and you have done the pricing calculation that shows that serving 9 million requests costs less than 4 dollars a month. Finally, you know what happens when a function fails in each invocation mode and why a dead-letter queue nobody watches is the same as not having one.

Recapping the whole module: MercadoFresco now has, in eu-west-1, an Auto Scaling group for the shop spread across two Availability Zones, EBS disks with automated snapshots managed by Data Lifecycle Manager, the photo catalogue in S3 with versioning and lifecycle rules, the orders database in RDS PostgreSQL with Multi-AZ, a read replica and point-in-time recovery, and two Lambda functions that react to events and answer over HTTP. Problem 2, the unreliable backups, is solved from start to finish. The other three are under way but they are still incomplete.

And what is missing is, precisely, what holds everything else up. All of this lives in the default VPC: the instances are exposed where they should not be, the database shares network space with the shop, there is nothing spreading the traffic across Friday's four instances, there is no HTTPS or custom domain, and 97 % of the S3 bill is still outbound transfer with no cache. In module 3, "Networking and Content Delivery", starting with lesson 03-01 "Amazon VPC", we will build MercadoFresco's own network: public and private subnets across two Availability Zones, route tables, gateways and a database that stops being reachable from the internet. On top of that network we will then build the security groups, the load balancer that completes the answer to the Friday peak, CloudFront to make the photos cheaper and faster, and Route 53 so that mercadofresco.example finally points to the cloud.