diff --git a/README.md b/README.md
index 4ff5555b..d2982e35 100644
--- a/README.md
+++ b/README.md
@@ -12,85 +12,9 @@ Datadog Lambda Library for Python (3.6, 3.7, 3.8, and 3.9) enables [enhanced Lam
 
 Follow the [installation instructions](https://docs.datadoghq.com/serverless/installation/python/), and view your function's enhanced metrics, traces and logs in Datadog.
 
-For advanced distributed tracing use cases, check out the [official documentation for Datadog APM client](https://ddtrace.readthedocs.io).
+## Configuration
 
-To connect traces and logs using a custom logger, see [connecting logs and traces](https://docs.datadoghq.com/tracing/connect_logs_and_traces/python/).
-
-## Environment Variables
-
-### DD_API_KEY
-
-If you are using the [Datadog Lambda Extension](https://docs.datadoghq.com/serverless/libraries_integrations/extension/), the Datadog API Key must be defined by setting one of the following environment variables:
-
-- DD_API_KEY - the Datadog API Key in plain-text, NOT recommended
-- DD_KMS_API_KEY - the KMS-encrypted API Key, requires the `kms:Decrypt` permission
-- DD_API_KEY_SECRET_ARN - the Secret ARN to fetch API Key from the Secrets Manager, requires the `secretsmanager:GetSecretValue` permission (and `kms:Decrypt` if using a customer managed CMK)
-
-If you are using the [Datadog Forwarder](https://github.com/DataDog/datadog-serverless-functions/tree/main/aws/logs_monitoring), you must set the Datadog API Key on the Datadog Forwarder instead of your own Lambda function.
-
-### DD_SITE
-
-If you are using the [Datadog Lambda Extension](https://docs.datadoghq.com/serverless/libraries_integrations/extension/), you must set `DD_SITE` on your Lambda function based on your [Datadog site](https://docs.datadoghq.com/getting_started/site/). The default is `datadoghq.com`. 
-
-If you are using the [Datadog Forwarder](https://github.com/DataDog/datadog-serverless-functions/tree/main/aws/logs_monitoring), you must set this on the Datadog Forwarder instead of your own Lambda function.
-
-### DD_LOGS_INJECTION
-
-Inject Datadog trace id into logs for [correlation](https://docs.datadoghq.com/tracing/connect_logs_and_traces/python/) if you are using a `logging.Formatter` in the default `LambdaLoggerHandler` by the Lambda runtime. Defaults to `true`.
-
-### DD_LOG_LEVEL
-
-Set to `debug` enable debug logs from the Datadog Lambda Library. Defaults to `info`.
-
-### DD_ENHANCED_METRICS
-
-Generate enhanced Datadog Lambda integration metrics, such as, `aws.lambda.enhanced.invocations` and `aws.lambda.enhanced.errors`. Defaults to `true`.
-
-### DD_LAMBDA_HANDLER
-
-In order to instrument individual invocations, the Datadog Lambda library needs to wrap around your Lambda handler function. This is usually achieved by setting your function's handler to the Datadog handler function (`datadog_lambda.handler.handler`) and setting the environment variable `DD_LAMBDA_HANDLER` with your original handler function to be called by the Datadog handler.
-
-For some advanced use cases, instead of overriding the handler setting and the `DD_LAMBDA_HANDLER` environment variable, you can apply the Datadog Lambda library wrapper in your function code like below:
-
-```python
-from datadog_lambda.wrapper import datadog_lambda_wrapper
-
-@datadog_lambda_wrapper
-def my_lambda_handle(event, context):
-    # your function code
-```
-
-### DD_TRACE_ENABLED
-
-Initialize the Datadog tracer when set to `true`. Defaults to `false`.
-
-### DD_MERGE_XRAY_TRACES
-
-Set to `true` to merge the X-Ray trace and the Datadog trace, when using both the X-Ray and Datadog tracing. Defaults to `false`.
-
-### DD_TRACE_MANAGED_SERVICES (experimental)
-
-Inferred Spans are spans that Datadog can create based on incoming event metadata.
-Set `DD_TRACE_MANAGED_SERVICES` to `true` to infer spans based on Lambda events.
-Inferring upstream spans is only supported if you are using the [Datadog Lambda Extension](https://docs.datadoghq.com/serverless/libraries_integrations/extension/).
-Defaults to `true`.
-Infers spans for:
-
-- API Gateway REST events
-- API Gateway WebSocket events
-- HTTP API events
-- SQS
-- SNS (SNS messaged delivered via SQS are also supported)
-- Kinesis Streams (if data is a JSON string or base64 encoded JSON string)
-- EventBridge (custom events, where Details is a JSON string)
-- S3
-- DynamoDB
-
-### DD_FLUSH_TO_LOG (Deprecated)
-
-When the [Datadog Forwarder](https://github.com/DataDog/datadog-serverless-functions/tree/main/aws/logs_monitoring) was launched previously, `DD_FLUSH_TO_LOG` was introduced to control whether to send custom metrics synchronously from your own Lambda function directly to Datadog with added latency (set `DD_FLUSH_TO_LOG` to `false` and you also need to set `DD_API_KEY` and `DD_SITE`) or asynchronously through CloudWatch logs (set `DD_FLUSH_TO_LOG` to `true`).
-
-Now you should consider adopting the [Datadog Lambda Extension](https://docs.datadoghq.com/serverless/libraries_integrations/extension/) for sending custom metrics. When the Datadog Lambda Extension is installed and detected, `DD_FLUSH_TO_LOG` is ignored. If you wish to Defaults to `false`. If set to `false`, you also need to set `DD_API_KEY` and `DD_SITE`.
+Follow the [configuration instructions][https://docs.datadoghq.com/serverless/configuration] to tag your telemetry, capture request/response payloads, filter or scrub sensitive information from logs or traces, and more.
 
 ## Opening Issues