Busca en todas las páginas de la documentación
Systems Manager rewards a handful of consistent habits across Parameter Store, Run Command, Automation, and Session Manager. Get the managed-instance prerequisite, targeting, and versioning right once, and the rest of your fleet operations stay predictable, auditable, and cheap to run.
Walk this list once now, then use it as a review checklist before shipping any code that touches Systems Manager.
Type choice, available at either tier.WithDecryption deliberately. Reading a SecureString without it returns ciphertext; set it only where the plaintext is actually needed, not as a blanket default./app/env/component/key makes GetParametersByPath and access-scoping by prefix straightforward.GetParametersByPath, not a loop of GetParameter. One call beats N calls for both latency and API cost.InstanceIds list. Targets with tag:Key scales as the fleet changes; InstanceIds is capped at 50 and goes stale.MaxErrors. The default halts a rollout after a single failure - know that behavior, and tune it deliberately for your risk tolerance.MaxConcurrency. Rolling a command out over waves, not all at once, limits blast radius from an unexpected failure.ListCommandInvocations, not just one instance. Checking a single GetCommandInvocation gives a false sense of fleet-wide success; check the whole set.StandardOutputContent truncates at a few KB - set OutputS3BucketName for verbose commands you need to inspect fully.DocumentVersion explicitly in production. An implicit $DEFAULT changes behavior the moment someone promotes a new version, silently, for every future run.aws:executeAwsApi; grant only what each runbook's steps actually need.aws:branch for rollback or notification steps so a failed step does something better than stop silently.CreateDocument rejects malformed schema, and catching it locally is cheaper than a failed API round trip.GetAutomationExecution per step, not just overall status. StepExecutions tells you exactly where a multi-step runbook stalled or failed.aws ssm start-session or the Console) to consume a StartSession response - do not reimplement the stream client.AWS-StartPortForwardingSession for one-off tunnels. It gets you at a private port (a database, an admin UI) without opening a wider hole than necessary.TerminateSession as part of access revocation instead of relying only on idle timeout.DescribeInstanceInformation/PingStatus first - a non-managed target fails quietly (TargetNotConnected), not with an obvious error.AmazonSSMManagedInstanceCore and nothing broader by default. Add extra permissions per use case rather than over-scoping the baseline instance role.max_attempts/retry mode rather than reimplementing retry loops.ResponseMetadata.RequestId (boto3) or $metadata.requestId (SDK v3) for support and correlation across all four capabilities.No, only sensitive values. Non-sensitive config as plain String avoids unnecessary KMS calls and permission scoping for data that was never secret.
The instance is very likely not a managed instance - check DescribeInstanceInformation for its PingStatus before assuming the command itself is broken.
Tag consistently, then target Run Command and other operations with Targets/tag:Key instead of a hardcoded instance list that needs constant updating.
So a later UpdateDocument that changes the default version does not silently alter the behavior of runbooks you already depend on in production.
Session start and end are always recorded in CloudTrail. Full command transcripts require explicitly enabling CloudWatch Logs or S3 logging in Session Manager preferences.
Only when you need more than 4 KB, more than the account's Standard-tier limit, or a parameter policy like Expiration - Advanced bills per parameter per month.
Set MaxErrors to a conservative threshold and MaxConcurrency to stagger execution, so a bad command is caught after a handful of instances, not all of them.
No, scope it to exactly what the runbook's steps need. Automation can reach any AWS API permitted by its role, so an over-broad role is a real risk, not just an EC2-adjacent one.
Usually no. Both SDKs retry throttling and transient errors with backoff by default; adjust retry configuration rather than reimplementing it.
Converting a large parameter tree wholesale to Advanced tier when only a few actually need it, and Automation steps that fan out into other billed services (Lambda, other API calls) without that cost being obvious upfront.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026