Practical tools for system, network, security, and operations administrators.

CLD-C0060 · Serverless & Event-Driven

Serverless Guide for Admins

Plan one function, write its timeout and memory, and keep the event source in an account you run.

Updated 25 October 2026 · Pillar guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A function is a small job with a limit

Serverless here means a function or a small service that runs when an event arrives, and stops when it finishes. The template generator drafts a starter. The comparison helps you choose among the hosted function products you are actually considering. Neither tool deploys, and neither tool calls an account.

Write the event. A queue you administer, an object store you administer, or a timer you meant are events. An event from an account you do not run is not your lab. The function does not receive a customer extract so you can see the log.

Timeout and memory are the two numbers that surprise people. Write both. A default you have not read is not a choice. The cost guide can price the guess. This page records the guess.

A secret in an environment variable that you commit is a secret you have published. The platform's secret store holds it. The template may say prompt-for-this. That string stays until a person substitutes the real reference at deploy time, outside this note.

One function, one event, two numbers

Name the job in one sentence. Pick one product with the comparison and write why the others waited. Draft a template. Read the timeout, the memory, and the identity the function would use. If the identity is an admin, replace it with the narrow identity from the IAM guide.

Point the event at a lab source you can delete. Do not subscribe a production queue to a function you have not run. The first run uses an invented payload you typed.

Read the log plan. The log should show the event id and the result, not the payload if the payload could later hold something private. For this lab the payload is invented, and you still avoid printing secrets.

Deployment belongs to the pipeline guide. This page ends when the template is reviewed. You do not deploy from the generator.

# Function note. A template is not a deploy.
# One event source you administer.
# Write timeout and memory.
# The function identity is not an admin.
# prompt-for-this is not an environment secret you commit.

A change you can finish

The first deploy is a later lab, one function, invented payload.

Rollback is removing that function and the event link. You do not roll back by deleting the log group that explains what happened.

  1. Write the job and the event source.
  2. Choose one product and say why.
  3. Draft a template and read timeout, memory, and identity.
  4. Narrow the identity if it is wide.
  5. Keep secrets out of the file.
  6. Plan an invented payload for the first run.
  7. Hand deploy to the pipeline guide.

Mistakes that outlive the command

serverless fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Decisions to write down before the window

One decision for serverless: The job and the event are named. One product is chosen. Timeout and memory are numbers you chose. The identity is narrow. The template has no secret. The first payload will be invented. No production event is attached. Nothing was deployed in this window. Logs are part of the plan. The pipeline guide owns deploy. The cost guide can see the guess. And one function is this window.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for serverless. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. serverless is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

Serverless checks before a lab deploy

Confirm this before you call the change done: The template is in the ticket. Timeout and memory are written. The identity name is not an admin. The event source is a lab you administer. No secret is in the file. The payload plan is invented data. No deploy happened. A scale surprise is mentioned to the cost guide. A second person can say the event. The product choice is one sentence. Logs will omit secrets. Rollback is removing the function, and that is written. The hostname in the prompt matches the hostname in the ticket for serverless. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for serverless happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.