AWS Config Recorder Stopped: Restart It, Fix the Bill

If your AWS Config recorder is stopped, the fix takes about a minute: open the AWS Config console, choose Settings, and on the Customer managed recorder tab choose Start recording, then Confirm. But if a bill is why somebody stopped it, pause before you restart. The switch people flip to save money, daily recording, costs $0.012 per configuration item against $0.003 for continuous recording (US East (N. Virginia) prices). That is four times the price per item, so the "cheaper" setting can raise your bill.

Jake runs a small phone shop, and his repair-ticket app lives on AWS. One Tuesday he opened the AWS Config console and saw the words "Recording is off." A freelancer had set Config up a year earlier, and nobody could say who switched it off or why. He lost most of an afternoon to it, and a customer's cracked-screen repair got pushed to Thursday.

Ethan, the friend who keeps Jake's cloud account out of trouble, had a guess before Jake finished the story. "Somebody opened the bill, saw a Config line that made their eyebrows jump, and hit Stop," he said. "It's the cloud version of pulling the battery out of a smoke alarm because it chirps at 3 a.m. The chirping stops. The smoke alarm stops too."

Ethan's guess is a guess, and nothing in AWS can prove it. Jake and Ethan are this blog's teaching duo, and the fixes below rest on how the service actually behaves, not on how Jake's Tuesday turned out. The post covers how to read your recorder's state, how to restart it, and what an AWS Config bill is made of. It also covers why people reach for Stop, what stopping breaks, and what to do instead. AWS changes its docs and prices, so I say where a number is only an example.

Why the AWS Config recorder is stopped, and who stopped it

First, plain-English definitions. AWS Config is the service that keeps a diary of how your AWS resources are set up. Think of a security group (a firewall rule set), a storage bucket or a server. The configuration recorder is the part that writes the diary. Each diary entry is a configuration item, or CI, and it works like a dated receipt: this is what the resource looked like at this moment. Config bills you mostly by the number of receipts it writes.

There are two kinds of recorder. A customer managed recorder is the one you, or whoever set up your account, control. You can have only one per account per Region, and you are charged service usage fees when it starts recording. A service-linked recorder belongs to another AWS service that uses Config behind the scenes, and the linked service sets its settings.

When someone says "the recorder stopped," it is usually one of these:

• Someone stopped it on purpose. You can stop the customer managed recorder at any time, from the console or the CLI. It takes seconds and needs no ceremony.
• The delivery channel was deleted. The delivery channel is the mailbox Config uses to hand its receipts to an S3 bucket (S3 is AWS's file storage) and to send notifications through SNS (a messaging service). AWS's support article says that deleting the delivery channel with the CLI turns the recorder off.
• The recorder was deleted, not just stopped. Deleting the customer managed recorder takes the CLI and is a bigger step than stopping.
• It is not stopped at all, just failing. The status can show recording while the latest recording event ended in a failure. IAM policies and Organizations policies can affect whether Config has permission to record your resources.
• You are looking in the wrong place. The recorder is per Region, so you may be viewing a Region where it was never on. The service-linked recorders sit on their own tab.

Notice that the console will not tell you who did it. If your team uses a tool to manage Config across many accounts, such as Systems Manager Quick Setup (which can create recorders across organizational units and Regions), ask whoever runs that tool before you change anything. Two people fixing one setting in opposite directions is how a Tuesday turns into a Thursday.

Which of these is happening to you?

Different symptoms point to different fixes. Find the row that sounds like your situation, then jump to the section that handles it.

Step one: find out whether it is really stopped

Before you restart anything, get the facts. A printer that "won't print" on Monday morning is often just sitting in the wrong mode. Same idea here: read the status before you press buttons.

1. Open the console. Sign in to the AWS Management Console, open AWS Config, and choose Settings in the navigation pane. Look at the Customer managed recorder tab first, then the Service-linked recorders tab.
2. Or use the CLI. The CLI (command-line interface) means typing commands instead of clicking. Run aws configservice describe-configuration-recorder-status. If you name no recorder, it returns the status of the customer managed recorder for the account, if there is one. A single request can name only one recorder.
3. Repeat per Region. Add --region with the Region name for each Region you use, because each Region has its own recorder. If you use only two, a small loop does it: for r in us-east-1 us-west-2; do aws configservice describe-configuration-recorder-status --region $r; done, swapping in your own Regions.
4. Read the fields. They are explained just below.
5. Compare dates. Look at lastStopTime and match it against your calendar. In AWS's CLI example the times appear as long numbers, which are seconds since 1970, so a converter helps. A stop that lines up with the day after a big bill tells its own story.

Here is what the status fields mean:

• recording says whether the recorder is currently recording. false is the stopped state you came here about.
• lastStartTime and lastStopTime are the last times the recorder was started and stopped.
• lastStatus is the status of the latest recording event the recorder processed. The values are Pending, Success, Failure and NotApplicable.
• lastErrorCode and lastErrorMessage hold the latest error from when the recorder last failed. If you see text there, read it before doing anything else.
• lastStatusChangeTime is when the status of a recording event last changed.

Reading the status: four situations and what each means

The status output can look like a wall of fields. In practice you will land in one of four situations. These are descriptions of what the fields mean, not real captured output.

Situation 1: recording is false

The recorder exists and is stopped. Look at lastStopTime to see when. This is the situation the restart steps below were written for. If starting it then fails with a delivery channel message, jump to the channel rebuild.

Situation 2: recording is true, but lastStatus is Failure

This is the router that only misbehaves on Sunday nights: the light is on, and the thing still is not doing its job. The recorder is switched on, but the latest recording event failed. Read lastErrorCode and lastErrorMessage. IAM policies and policies managed in AWS Organizations can affect whether Config has permission to record your resources, so a permissions cause is worth looking at first. One hint from the delivery side: if your bucket has no configuration files, the role may be missing permissions.

Situation 3: recording is true and the status looks healthy, but resources are missing

Then the recorder is running and the question is what it records. Run aws configservice describe-configuration-recorders. AWS's example response shows the recording group, with the strategy and any excluded or included resource types, and the recording mode, with the default frequency and any overrides. A resource type someone excluded will produce no detailed history, which can look like a stopped recorder from the outside.

Situation 4: the command returns an error instead of a status

The status call has two errors. NoSuchConfigurationRecorderException means the recorder you named does not exist. If the name you typed was right, no recorder exists in that Region, and it may have been deleted. InvalidConfigurationRecorderNameException comes with a note that the prefix "AWSConfigurationRecorderFor" is reserved for service-linked recorders. If you pasted the name of a service-linked recorder into a command written for the customer managed one, this is why it fails.

What an AWS Config bill is actually made of

You are charged for three things: the number of configuration items recorded, the number of active Config rule evaluations, and the number of conformance pack evaluations. A rule evaluation is Config checking one resource against one rule, such as "is this bucket encrypted?" A conformance pack is a bundle of rules deployed together, and AWS bills the evaluations inside it separately. Beyond those three lines, the bucket, the notifications and any custom rule code are billed by their own services.

Two cautions on that table. The prices are the ones AWS uses in its pricing examples for US East (N. Virginia), so other Regions differ and your Region's pricing page is the authority. There are also rates for evaluations beyond the first 100,000, which I left out because most small accounts never reach them.

Here is a worked example of how the pieces stack. In one month, 10,000 CIs at $0.003 cost $30. Then 50,000 rule evaluations at $0.001 cost $50, and 15,000 conformance pack evaluations at $0.001 cost $15. The total is $95. In that example, the rules cost more than the recording, more than half of the bill. People who stop the recorder to save money sometimes find the money was going somewhere else.

One more piece is easy to forget. Config delivers your recorded history to the S3 bucket you chose, and standard S3 and SNS rates apply. If the bucket keeps filling for years, that storage line keeps growing, even in a quiet month for CIs.

The bill spikes that make people hit Stop

Config bills climb for a handful of predictable reasons. Here they are in one place. Skim the table, then read the two I think catch the most people.

Spike one: ephemeral workloads

An ephemeral workload is a temporary use of computing resources that gets loaded and run when needed. AWS's examples are EC2 Spot Instances, Amazon EMR jobs and AWS Auto Scaling. Every time one of these appears or disappears, Config writes receipts. A team that runs a hundred short jobs a day pays, in effect, a fee for each job appearing.

Ethan's take is blunt. "If a workload lives for forty minutes, ask whether you need its diary at all," he tells Jake. "My advice is to exclude those resource types, or to run that kind of work in a separate account with Config turned off. I'd do the second one first, because it doesn't depend on anyone remembering an exclusion list."

Spike two: the CI type nobody knew they were buying

AWS::Config::ResourceCompliance is a CI type that records the compliance result of a resource, meaning whether it passed or failed your rules. Security Hub can raise your recorder cost by updating this CI each time a control changes compliance state, is enabled or disabled, or has parameter updates. It also says that if you use the recorder only for Security Hub and do not use this CI for anything else, turning off its recording can reduce your Config costs, because Security Hub checks do not need it to work. AWS's blog on recording frequencies notes that in its sample environment this type had the largest CI count.

The word "if" carries weight in that advice. AWS's Config blog also says that for accurate compliance reporting, and to use the Config configuration timeline, you must record this resource type. The right answer depends on what you use Config for. That is a decision for a person, not a default.

The daily-recording trap: cheaper on paper, pricier in practice

Daily recording, also called periodic recording, gives you one CI per resource per 24 hours, and only if the resource is different from the last recorded state. The idea is sound. If a server changes ten times in a day, you get one receipt instead of ten.

Now look at the unit price. Each periodic CI is $0.012 and each continuous CI is $0.003, which is four times as much per receipt. Here is the good case: 100 EC2 instances that each produced 10 CIs in a day cost $3.00 under continuous recording (1,000 CIs at $0.003) and $1.20 under periodic recording (100 CIs at $0.012).

The break-even arithmetic falls straight out of those two prices. Four continuous CIs cost $0.012, the same as one daily CI. A resource type that changes more than about four times a day per resource can be cheaper on daily recording, and a type that changes fewer than four times a day costs more. The table below is my own arithmetic on the list prices, per resource per day, assuming the resource changed and its end state differs from the last recorded state.

The same blog gives a rule of thumb for spotting good candidates: look for resource types with more than four daily CIs under continuous recording and a reduction of more than 75 percent under periodic recording. In its sample, EC2 instances showed about 90 percent fewer CIs, while network interfaces saved about 34 percent and volumes about 30 percent, which was not enough. Be aware, too, that daily recording does not capture transient changes for resources that start and stop inside 24 hours, which can leave gaps in your operational picture.

Three more facts about daily recording surprise people:

• Some types cannot go daily. Daily recording cannot be specified for AWS::Config::ResourceCompliance, AWS::Config::ConformancePackCompliance and AWS::Config::ConfigurationRecorder. With the record-all-supported strategy, those types stay on continuous recording. So "set everything to daily" does not really set everything to daily.
• Firewall Manager wants continuous. Firewall Manager depends on continuous recording, so keep continuous if you use it.
• Another service can override you. If a paid service-linked recorder records the same resource types continuously, those types are recorded continuously even though your settings still show daily. You are charged once per CI in that case, not twice.

Worked numbers: what a month looks like

Numbers stick better than rules. These three examples extend AWS's pricing example (100 EC2 instances, US East prices) over a 30-day month. The arithmetic is mine, the prices are AWS's, and real bills also include rules and storage.

• Busy resources, 10 changes a day. Continuous: 100 × 10 × 30 = 30,000 CIs × $0.003 = $90. Daily: 100 × 30 = 3,000 CIs × $0.012 = $36. Daily saves $54.
• Calm resources, 2 changes a day. Continuous: 100 × 2 × 30 = 6,000 CIs × $0.003 = $18. Daily: 3,000 CIs × $0.012 = $36. Daily costs double.
• Quiet resources, 1 change a day. Continuous: 3,000 CIs × $0.003 = $9. Daily: 3,000 CIs × $0.012 = $36. Daily costs four times as much.

Same account, same 100 servers, and the "save money" setting swings from saving $54 to costing an extra $27, depending on how often the servers change. This is why the advice is per type, not per account. It is also why reading your own CI counts, covered next, comes before any change.

Now put the rule bill next to it. In that example, 50,000 rule evaluations cost $50, more than the $30 of recording in the same month. If your Config charges are mostly rules, changing recording frequency will not touch them, and neither will stopping the recorder be the whole answer. Scope the rules, or remove the ones nobody reads.

Ethan's rule of thumb is simple. "Before you change any switch, write down which of the three bill lines is the big one," he says. "You'll be surprised how often it is the line you weren't looking at."

Read your own bill before you touch a setting

You cannot trim what you have not measured. To track spending over time, use AWS Cost Explorer and detailed billing reports, and use Amazon Athena queries to find the resources that generate the most CIs. Athena is a tool that lets you ask questions of files sitting in S3 using ordinary query language. You do not need a third-party tool for this step, because these are the ones AWS points to.

Here is how the plumbing works. Config delivers CIs to your bucket as configuration history files every 6 hours, so the raw data is already sitting in the bucket you chose. There are sample Athena table definitions for a standard setup and for AWS Control Tower environments, plus example queries for changes per resource and CIs per day.

Three details from that article keep you from reading the numbers wrong:

• Non-recorded resources look like receipts but are free. When you exclude a resource type, Config still records its creation and deletion at no cost. Those rows carry the statuses ResourceNotRecorded and ResourceDeletedNotRecorded, so filter them out of your counts.
• Month boundaries blur. CIs are metered by their capture time, and Athena results can cross day boundaries into adjacent months, so your query totals and your bill can differ. AWS suggests adding one day to the end of the month in your query.
• An empty bucket is a clue. If the bucket holds no configuration files, the role may be missing permissions.

Ethan has a rule for this step. "Sort by resource type, not by resource," he says. "One noisy resource is a bug you fix once. One noisy type is a setting you fix everywhere."

If you see an unexpected, significant rise in Config usage and cost, review your Config settings for unintended changes to recording or rule evaluations, and look for recent infrastructure changes that started a large number of recordings. That order matters: settings first, then what changed in your account.

How to restart a stopped recorder

Restarting is the easy part. One decision comes first. If the bill is why the recorder was stopped, settle on the trimmed scope from the next section before you start, or you will be back here next month. Also make sure whoever owns the account knows you are restarting it.

1. Use the console. Open the AWS Config console, choose Settings, open the Customer managed recorder tab, choose Start recording, and choose Confirm when prompted.
2. Or use the CLI. Run aws configservice start-configuration-recorder --configuration-recorder-name default, replacing default with your recorder's name if it has another. Config assigns the name "default" when it creates the recorder.
3. If you get the delivery-channel error, the message reads "Delivery channel is not available to start configuration recorder." That means the delivery channel was deleted, and you cannot recreate it from the console. Use the channel rebuild below.
4. Read the status again. Run the status command and confirm recording shows true and that the error fields are empty.

Rebuilding a deleted delivery channel

AWS's support article lists the pieces Config needs: an S3 bucket, an SNS topic and an IAM role. An IAM role is a set of permissions that a service can borrow, like a visitor badge with specific doors on it. If you did not delete the bucket, topic and role that went with the old channel, you can skip creating them.

If you did delete them, the article's outline runs like this:

• Bucket. Create an S3 bucket in the same Region as Config, and attach a bucket policy that lets the Config service check the bucket ACL, list the bucket, and put objects under the Config path, restricted to your own account.
• Topic. Create an SNS topic, subscribe an email address, and confirm the subscription.
• Role. Create an IAM role for Config with permission to put objects into the bucket path, read the bucket ACL and publish to the topic.
• Optional KMS key. Encryption with a KMS (Key Management Service) key is the best practice for delivered objects, and there are separate key-policy statements for a custom role and for the service-linked role.
• Channel. Save a JSON file with the channel name, bucket, optional key prefix, topic ARN, optional KMS key ARN and a delivery frequency (AWS's example uses Twelve_Hours), then run aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json. Check it with describe-delivery-channels.
• Start. In the console Settings page choose Turn on under "Recording is off" and then Continue, or run the start command.

Copy the bucket policy and role policy from AWS's article itself, not from this summary. Those policies have placeholders for your account ID, bucket name and topic, and a wrong character in one of them can produce the same permission failure you are trying to escape. The article also says you must provide the key prefix if your bucket policy restricts writes to a specific prefix instead of the default.

Trim instead of stop: the cheaper fixes, cheapest first

Stopping the recorder is an all-or-nothing move. Trimming lets you keep the diary for the things that matter and skip the things that only generate noise. Work down this list in order, because each step is a little more disruptive than the one before it.

1. Find the noisy types first. Use the Athena and Cost Explorer approach from the last section. Never trim blind.
2. Exclude the types you do not need. In the console, choose the recording strategy Record all resource types with customizable overrides, pick the resource type, and choose the override Exclude from recording. In the CLI, use put-configuration-recorder with the strategy EXCLUSION_BY_RESOURCE_TYPES and list the types under exclusionByResourceTypes. When you stop recording a type, the CIs already recorded stay unchanged.
3. Decide on ResourceCompliance deliberately. If the recorder exists only for Security Hub checks, you do not need this CI for those checks to work. If you rely on compliance timelines, keep it.
4. Move selected types to daily. Do this only for types that pass the four-CIs-a-day math above. In the CLI, set a recordingModeOverrides entry with DAILY and the list of types. AWS's console steps route this through the recording method setting, so follow the current screen.
5. Record global IAM types once. IAM users, groups, roles and customer managed policies are global, and AWS advises recording them in only one Region to avoid duplicate CIs, extra evaluations and throttling.
6. Scope your rules. Give every custom Lambda rule a list of resource types so it does not run against everything. Deploy rules about global IAM types in only one Region.
7. Separate the noisy accounts. AWS's blog recommends using multiple accounts to separate environments and workloads, so you can set recording more granularly. Ephemeral work can live in an account with Config off.

Start with exclusions and account separation, and treat daily overrides as the last tool you reach for. Exclusions cut CIs without raising the per-item price, and they leave your compliance evidence intact for the resources that matter. Popular advice tends to jump straight to "just switch everything to daily." As the math above shows, that is wrong for any resource type that changes less than about four times a day.

What stopping the recorder actually breaks

Stopping is not always wrong. If you are running a planned migration and you know the noise will be enormous, a short stop can be a sound choice. But if it stays stopped, here is the fallout.

Changes happen and nobody writes them down

A stopped customer managed recorder disables Config's ability to track changes to the resources you specified, including their deletions. That has a strange side effect: you might see stale evaluation results for deleted resources, because Config cannot capture deletion events while recording is off. A compliance dashboard can keep showing a resource as noncompliant long after that resource is gone.

The good news is that AWS also says that after you stop recording, Config keeps the configuration information it captured earlier, and you can still access it. Stopping does not erase your history. It stops adding to it.

The recorder keeps a diary of itself

Config has a CI type for the recorder itself, AWS::Config::ConfigurationRecorder. It tracks whether you stopped, started or deleted the recorder, and whether the resource types you record changed. A recorder that has changed from its previous state is called drifted, and a drifted recorder means you are not accurately detecting changes to the resource types you intended, which can produce false negatives or false positives in compliance results. Recording of this type is on by default in supported Regions and carries no additional charge.

Security Hub starts complaining

If you use AWS Security Hub CSPM (the part of Security Hub that runs configuration checks) without the newer Security Hub, the Config.1 control produces FAILED findings when Config is disabled, and also when Config is on but recording is not turned on. If recording is off for a resource type that an enabled control checks, you get a FAILED finding for Config.1 plus WARNING findings for that control and those resource types. AWS also says that if you disable recording for a type that a control evaluates, Security Hub keeps the earlier findings and changes their compliance status to WARNING, and those retained findings might not reflect the resource's current state.

There is a twist. When both Security Hub CSPM and Security Hub are enabled, Config.1 always shows PASSED, because Security Hub CSPM reads configuration items directly through a service-linked recorder. That leads to the next section.

The recorders you cannot stop: service-linked recorders

Here is where "I stopped it and it is still billing me" stories can come from. Service-linked recorders are always recording. You cannot stop one directly, and you cannot change its settings. To start, stop or update it, you make the change through the AWS service that owns it. To stop recording for good, you delete the service-linked recorder.

AWS lists three services that use them: Amazon CloudWatch (through Observability Admin), AWS Security Hub, and AWS Security Hub CSPM. Their recorder names begin with AWSConfigurationRecorderFor, a prefix AWS reserves for them.

Whether one adds to your bill depends on its recording scope, which the linked service sets. The scope determines whether the CIs are recorded for free (INTERNAL) or whether they affect your bill (PAID). If the scope is INTERNAL, you also do not receive those CIs in your delivery channel.

AWS gives an example of the precedence rule. Say your customer managed recorder records EC2 instances daily. Later you enable a service feature whose paid, continuous service-linked recorder also records EC2 instances. Your settings still say daily, but those instances are recorded continuously and you pay for continuous recording. Other types recorded only by your recorder stay on daily. That is why "my daily setting is not saving money" can have the answer "another service overruled it."

To delete a service-linked recorder, AWS gives two routes. In the console, go to Settings, open the Service-linked recorders tab, choose the recorder, and choose Delete. In the CLI, use delete-service-linked-configuration-recorder with the service principal of the linked service. Read the warning below before you do either.

When the account is not really yours: policies and shared setups

Plenty of people meet this problem in an account somebody else set up. That might be a company account managed centrally, or a client account where you are a guest. Two things are worth knowing.

First, IAM policies and other policies managed in AWS Organizations can affect whether Config has permission to record configuration changes for your resources. It also says rules evaluate a resource's configuration directly and do not take those policies into account. In plain terms, your dashboard can show a rule result for a resource the recorder was not actually allowed to record. If the status shows a Failure with an access-style error, the cause may be a policy above your account rather than anything inside it.

Second, AWS Control Tower has its own well-known errors around the Config delivery channel and configuration recorder. AWS Control Tower is the service that sets up and governs multi-account environments. I will not invent steps for it here, because they depend on how your landing zone is set up. If your account belongs to one, start with that article, and ask the team that runs the organization before editing the recorder yourself.

Ethan puts it in shop terms. "If you rent a unit in a mall, you can repaint your own wall," he tells Jake. "You don't move the fire exit. Find out which of these settings is your wall."

If you truly want Config off: stop, delete, and the right order

Sometimes the honest answer is that you do not need Config in that account. A test account that will be gone next month does not need a diary. If so, do it cleanly, because a half-off Config is the worst of both worlds.

Stop versus delete. Stopping pauses recording and leaves the recorder in place, so you can start it again. Deleting the customer managed recorder needs the CLI, using aws configservice delete-configuration-recorder --configuration-recorder-name default. There is no console button for that one. A service-linked recorder can be deleted in the console or the CLI, as covered above.

Mind the order. Two AWS points should shape your sequence:

• Rules first, and think about ResourceCompliance. Deleting rules creates ResourceCompliance CIs, which can spike your recorder cost if the rules cover many resource types. It suggests you could disable recording for that type before deleting rules and re-enable it afterward. It also says rule deletion is asynchronous and can take an hour or more, and that rule evaluations are not recorded in the resource history while that type is off. Weigh this case by case.
• The delivery channel affects the recorder. AWS's support article says that deleting the delivery channel with the CLI turns the recorder off, and the recorder cannot start again until the channel exists. Do not delete it by accident while trying to save money.

After that, tidy the leftovers: the S3 bucket with the history files, which keeps billing at S3 rates while it holds data, plus the SNS topic and the IAM role. Decide about the bucket only after you are sure you no longer need the history, and understand how bucket deletion works first. Organization-level service access also matters here, which may matter if the account was enrolled through an organization.

Make sure it never stops silently again

Jake's real problem was not the stop itself. It was that nobody noticed for a while. AWS gives you a tool for exactly this: the resource type AWS::Config::ConfigurationRecorder, which tracks stop, start and delete and carries no additional charge.

AWS's Cloud Operations Blog shows how to build an alarm on it. You deploy a custom Config rule written in Guard (a policy language for writing checks) that looks at whether recording is enabled on the recorder resource. If recording is off, the rule marks the recorder noncompliant. The blog deploys it with CloudFormation StackSets from the organization management account or a delegated administrator, and mentions organizational Config rules as an alternative.

The status API also points to CloudWatch. AWS's reference says that for a detailed status of recording events over time, you can add your Config events to CloudWatch metrics and use them. That is the route if you want a trend line, not just a yes or no.

Pair the technical alert with two habits. First, make one person the owner of Config settings, and write down when and why a stop is allowed. Second, look at the Config line on your bill each month with Cost Explorer, as AWS suggests. The gap between "the recorder stopped" and "someone noticed" is where the trouble grows.

When nothing works

Some problems cannot be fixed from where you are sitting, and it is better to say so plainly.

• You lack permission. If your login cannot start the recorder or edit the delivery channel, no setting in this post will help. You need someone with the right access.
• The missed period cannot be backfilled. Config cannot capture deletion events when recording is off, and stale results can follow. There is no way to fill in the gap afterward, so treat the stopped window as a hole in your records.
• A policy above your account is blocking recording. If the status error points to access and your own role looks fine, the cause may be an organization-level policy. That fix belongs to whoever runs the organization.
• The recorder belongs to another service. If it is a service-linked recorder, you change it through the owning service, and there is nothing to edit on the Customer managed recorder tab.
• The bill still looks wrong. Use Cost Explorer and the Athena approach to find the line, then compare it with your rule evaluations, S3 storage and any Lambda-backed rules. AWS Support can look at the billing side in ways this post cannot.

As for Jake, picture the sensible ending. He restarts the recorder, excludes the noisy job resource types, moves the throwaway work into its own account, and asks the freelancer to write down who may stop Config and why. His Tuesday ends better than it began. As for the customer with the cracked screen, Ethan's advice was to say the phone would be ready Thursday, and to mean it.

Frequently asked questions

How do I check if my AWS Config recorder is stopped?

Open the AWS Config console, choose Settings, and look at both the Customer managed recorder tab and the Service-linked recorders tab. Or run aws configservice describe-configuration-recorder-status and read the recording field, which says whether the recorder is currently recording. Do this once per Region, because each Region has its own recorder. If the field is false, compare lastStopTime with your calendar to see when it happened.

How do I start a stopped AWS Config recorder?

In the Config console choose Settings, open the Customer managed recorder tab, choose Start recording and confirm. From the CLI, run aws configservice start-configuration-recorder with your recorder's name, which is "default" unless someone renamed it. If a bill was the reason it was stopped, decide on a trimmed scope first, and tell the account owner you are restarting it. After it starts, run the status command again to confirm.

What does "Delivery channel is not available to start configuration recorder" mean?

It means the delivery channel, the mailbox Config uses to hand records to your S3 bucket and SNS topic, was deleted. AWS's support article says deleting it with the CLI turns the recorder off, and that you cannot recreate it from the console. Rebuild it from the CLI with the put-delivery-channel command, using a JSON file that names your bucket, topic and delivery frequency, then start the recorder. If the bucket, topic and role still exist, you can skip creating them.

Does stopping the AWS Config recorder stop the charges?

It stops new configuration items from that recorder, and CIs are one of three usage-based Config lines. Rule evaluations, conformance pack evaluations, S3 storage, SNS and Lambda are billed separately, and stopping the recorder does not remove those. A service-linked recorder cannot be stopped directly and may be recorded as paid. Read your bill line by line to see what is left after a stop.

Will I lose my configuration history if I stop the recorder?

No. After Config stops recording a resource, it retains the configuration information it previously captured, and you can still access it. What you lose is new history for the stopped period. That includes deletions that happen while recording is off, which is why deleted resources can keep showing stale evaluation results until recording resumes and Config catches up on later changes.

What is the difference between stopping and deleting the recorder?

Stopping pauses recording and leaves the recorder in place, so you can start it again with one click. Deleting the customer managed recorder takes the CLI, using the delete-configuration-recorder command, and you must create a recorder again before Config can record anything. Service-linked recorders work differently: you cannot stop them, and you delete them from the console or with a separate CLI command that names the service principal.

Why can't I stop a service-linked configuration recorder?

Service-linked recorders are always recording and their settings are fixed. You change them through the AWS service that owns them, such as Security Hub or CloudWatch. To stop recording, you delete the service-linked recorder, from the Service-linked recorders tab in Settings or with the delete-service-linked-configuration-recorder command. Think first about whether the owning service still needs its data before you delete one.

Is daily recording cheaper than continuous recording?

Only sometimes. A daily configuration item costs $0.012 and a continuous one $0.003, so daily wins only when a resource type would produce more than about four continuous items per resource per day. For stable resource types it can cost several times more. Use it as a per-type override on busy, non-critical types, not as a blanket setting, and remember that some types cannot be recorded daily at all.

What is AWS::Config::ResourceCompliance, and can I turn it off?

It is a configuration item type that records the compliance result of a resource. Security Hub can raise recorder cost by updating it, and if you use the recorder only for Security Hub you can turn off this type without breaking security checks. If you need compliance timelines, keep it recorded. Daily recording cannot be set for this type, so exclusion is the way to cut its volume.

Why was my first month of AWS Config so expensive?

You may see more activity in the first month because Config runs evaluations on all the resources you selected during initial bootstrapping. Ephemeral workloads such as Spot Instances, EMR jobs and Auto Scaling can add more, since each created or deleted resource is recorded. Compare month two before making big changes, and exclude noisy types or separate ephemeral work into its own account if the pattern continues.

Do resources I exclude from recording cost anything?

No. For a non-recorded resource, Config captures only its creation and deletion, at no cost, and shows few configuration details. Those items carry the statuses ResourceNotRecorded and ResourceDeletedNotRecorded, so filter them out when you count billable items. AWS also notes they appear during a periodic baselining process, not at the moment of creation or deletion.

How do I find which resource types generate the most configuration items?

Use Amazon Athena on the history files Config delivers to your S3 bucket. Group by resource type, exclude the not-recorded statuses, and add a day to your month-end date so boundaries line up with billing. Cost Explorer and detailed billing reports show the spending trend over time, so use both together.

Should I record global IAM resources in every Region?

No. IAM users, groups, roles and customer managed policies are global. AWS advises recording them in only one Region to avoid duplicate configuration items, unnecessary evaluations and API throttling. Deploy the rules that cover them in only one Region too, since periodic rules on these types run in every Region where they are added once you record the types anywhere.

Will Security Hub complain if the recorder is stopped?

For Security Hub CSPM without the newer Security Hub, yes. The Config.1 control produces FAILED findings when Config is disabled or recording is off, along with WARNING findings for the affected controls. When both services are enabled, Config.1 shows PASSED because a service-linked recorder supplies the data directly. Either way, retained older findings can be out of date after a stop.

Can I be alerted when the recorder stops?

Yes. Config records a configuration item for the recorder itself that tracks stops, starts and deletes, at no additional charge. AWS's Cloud Operations Blog shows a Guard-based Config rule, deployed with CloudFormation StackSets, that marks the recorder noncompliant when recording is disabled. AWS also says you can add Config events to CloudWatch metrics for a detailed view of recording status over time.

What if the recorder says recording is on but the status shows Failure?

Then it is not stopped, it is failing, and pressing Start will not help. Read lastErrorCode and lastErrorMessage from the status command. IAM and Organizations policies can affect Config's permission to record, and an empty delivery bucket can point to a missing-permission problem. Fix the named cause, then read the status again.

Revision note. Written September 2026, covering the customer managed and service-linked configuration recorders with prices for US East (N. Virginia) as of September 2026. A change to AWS Config pricing, the recording options or the console labels would change this post, so treat every dollar figure as an example and check the current pricing page for your Region. If a stopped recorder and a scary bill have been ruining your week, I hope this got you to a calm, boring Config page, which is exactly where you want to end up.