Cloud security checklists for Aws, azure and Gcp before going to production

Use a repeatable, provider-specific security checklist before production to block the most common cloud incidents: leaked keys, overexposed networks, missing encryption and no logging. This guide gives safe, concrete checks for AWS, Azure and GCP, aligned with Brazilian teams (pt_BR), and can be used both internally and with external cloud security consultants.

Pre-production security snapshot

• Lock down identities: no shared root/owner accounts, mandatory MFA and least-privilege roles across AWS, Azure and GCP.
• Restrict network exposure: only required ports from known sources, no public databases or admin panels.
• Encrypt sensitive data in transit and at rest, with managed keys and tested backup-restore procedures.
• Harden workloads (VMs, containers, serverless) with minimal permissions, patched runtimes and secure images.
• Enable centralized logging, alerting and security posture tools per provider before first production deploy.
• Define change management, approvals and tagging to keep costs and compliance under control after go-live.

Identity and access management: what to verify in AWS, Azure and GCP

This section is for intermediate DevOps and cloud engineers in Brazil who already operate non-critical workloads and are preparing their first serious production deployment. If your team has no basic IAM understanding yet, do not try to build a full checklist alone: use temporary consultoria segurança em nuvem aws azure gcp or provider training first.

Before you run any checklist segurança aws antes de produção, ensure that your organization is ready to enforce the results: someone must own IAM, approve changes and monitor drifts. Running a checklist without the authority or discipline to apply fixes usually produces noisy reports and a false sense of safety.

Provider / scope	What to check (must-have vs recommended)	Why it matters	How to verify safely
AWS – Accounts & root	Must-have: root user not used for daily work, MFA enabled; break-glass procedure documented.	Root has unrestricted power; its compromise often means full account loss.	In AWS console, open IAM > Dashboard > Security recommendations; confirm root MFA and no active access keys.
AWS – IAM policies	Must-have: roles for apps, no long-lived user keys; Recommended: permissions boundaries for teams.	Long-lived keys and wildcards like * in policies are a primary breach vector.	Use IAM Access Analyzer and AWS Config rules to find overly permissive policies and unused keys.
Azure – Tenants & subscriptions	Must-have: dedicated production subscription; separate RBAC from dev/test.	Separation reduces blast radius and simplifies access management and billing.	In Azure Portal, go to Subscriptions; verify production workloads are not mixed with dev/test resources.
Azure – Identities & roles	Must-have: Azure AD MFA for admins; role-based access with groups; Recommended: Privileged Identity Management.	Multi-factor and just-in-time elevation block many credential attacks.	Check Entra ID security defaults or conditional access; review Role assignments at subscription and resource group levels.
GCP – Projects & org	Must-have: separate projects per environment; no owner roles on user accounts.	Project isolation and minimal roles/owner reduce the damage from compromised accounts.	Use IAM & Admin > IAM in the console; list principals with Owner role and replace with narrower roles.
GCP – Service accounts	Must-have: unique service accounts per app; keys minimized; Recommended: Workload Identity Federation.	Shared or key-heavy service accounts are hard to rotate and audit.	In IAM & Admin > Service accounts, list keys and disable unused ones; ensure GCE/GKE use attached service accounts, not user credentials.

Across all providers, align IAM changes with LGPD-relevant data access: privileged roles that can export personal data must be specially tracked and periodically reviewed. For teams that rely on SSO, integrate your IdP groups with cloud roles so that offboarding users automatically removes their cloud access.

Network and perimeter controls to validate before launch

To run a robust checklist segurança gcp devops antes de deploy or similar checks in AWS and Azure, you need a clear view of how traffic flows between users, services and data stores. Prepare:

1. Network diagrams covering public entry points, internal services and data layers.
2. Access to cloud consoles and CLIs with read-only permissions for networking and security resources.
3. At least one non-production environment mirroring production topology to test firewall and routing changes safely.
4. A list of allowed source IP ranges, ports and protocols approved by security and application owners.

Use built-in ferramentas auditoria segurança cloud aws azure gcp to automate verification where possible:

Provider	Tool / feature	Primary use	How to use for pre-production checks
AWS	VPC Reachability Analyzer	Simulate and debug network paths.	Model paths from the internet to your workloads; ensure only intended endpoints are reachable on required ports.
AWS	AWS Security Hub	Security posture across accounts.	Enable in each production account; review findings for public security groups, open S3 buckets and missing flow logs.
Azure	Azure Network Watcher	Traffic diagnostics and topology.	Use IP flow verify and effective security rules to confirm that NSGs and firewalls match documented access requirements.
Azure	Microsoft Defender for Cloud	Hardening recommendations.	Run a baseline before go-live; fix high-severity issues related to exposed ports and missing just-in-time VM access.
GCP	VPC Firewall Rules logging	Visibility into allowed/denied traffic.	Enable logging on critical rules; review logs in Cloud Logging to detect unexpected source IPs or protocols.
GCP	Security Command Center	Central security and risk view.	Turn on the Standard tier; review findings about open Cloud SQL instances and public storage buckets.

Combine these tools with simple external scans (for example, from a jump host) to validate that only approved ports on load balancers or application gateways are exposed, and that admin interfaces remain internal or VPN-only.

Data protection: encryption, classification and backup checks

1. Map data types and LGPD relevance

   List all datasets (databases, object storage, logs, caches) and mark which contain personal or sensitive data under LGPD. This mapping drives stricter controls and audit requirements.

   • Tag resources with data classification labels (for example: public, internal, confidential, personal).
   • Involve legal or compliance for ambiguous cases.
2. Enforce encryption at rest for all storage

   Enable managed encryption for databases, block storage and object storage in AWS, Azure and GCP. Prefer provider-managed keys for simplicity unless compliance forces customer-managed keys.

   • AWS: verify EBS, RDS, S3 default encryption; enforce via service control policies or Config rules.
   • Azure: check Storage accounts, managed disks and databases for encryption settings.
   • GCP: ensure CMEK or default encryption is active for disks, BigQuery and Cloud Storage buckets.
3. Secure data in transit with TLS everywhere

   Require HTTPS for public endpoints and TLS for internal service-to-service connections where supported. Disable legacy protocols and weak ciphers in load balancers and gateways.

   • Terminate TLS at managed services (ALB, API Gateway, Application Gateway, Cloud Load Balancing) using current certificates.
   • Test using tools like curl -v or browser dev tools to confirm HTTPS redirects and certificate validity.
4. Harden key management and access to secrets

   Centralize keys and secrets in managed services, applying least privilege to who and what can read them. Avoid embedding secrets in code, images or CI/CD variables without rotation.

   • AWS: use KMS and Secrets Manager; restrict decrypt permissions to specific roles.
   • Azure: store secrets in Key Vault; grant access via managed identities instead of application keys.
   • GCP: use Cloud KMS and Secret Manager; audit access through Cloud Audit Logs.
5. Define and configure backup and snapshot policies

   Set automated backups and snapshots with retention aligned to business and legal requirements. Include both databases and critical configuration stores.

   • Document RPO/RTO expectations and confirm your schedules meet them.
   • Enable cross-zone or cross-region copies for disaster scenarios when allowed by data residency rules.
6. Test restore procedures before production cutover

   Restores must be tested in a non-production environment using production-like data patterns. This validates that backups are usable and that your team knows the steps.

   • Simulate accidental deletion or corruption and measure restore time.
   • Verify application functionality after restore, not just database integrity.

Fast-track mode for data protection

1. Confirm encryption at rest is enabled on all production databases, disks and storage buckets.
2. Ensure all public endpoints use HTTPS only and redirect HTTP to HTTPS.
3. Move all secrets into the provider’s secret manager and remove them from code and plain-text configs.
4. Enable automatic database backups and run at least one full restore test in a staging environment.

Workload posture: compute, containers and serverless validations

Use this checklist as a final workload posture review before production deployment:

• Virtual machines use hardened base images, with unnecessary services disabled and OS auto-updates enabled where compatible with the application.
• SSH or RDP access is restricted via bastion hosts, VPN or just-in-time access features; no direct public access to admin ports.
• Container images are built from minimal base images, scanned for vulnerabilities and signed; only trusted registries are allowed.
• Kubernetes clusters (EKS, AKS, GKE) restrict anonymous access, use RBAC and do not expose the API server directly to the internet.
• Pod security settings avoid running as root, enforce read-only filesystems where possible and limit hostPath and privileged containers.
• Serverless functions (Lambda, Azure Functions, Cloud Functions) run with least-privilege roles, accessing only the resources they need.
• Startup and readiness probes are configured so faulty workloads do not receive traffic during deployment.
• CI/CD pipelines deploy via roles or managed identities, not user accounts or hard-coded keys.
• Autoscaling policies are defined and tested so that security controls (logging, IAM, network) scale with the workload.
• Health dashboards exist for each critical service, combining metrics (CPU, memory, errors) with log and trace views.

Logging, monitoring and alerting prerequisites for incident readiness

Common issues to avoid before you push production traffic:

• Logging enabled but not retained long enough to investigate incidents or compliance inquiries.
• No centralized log collection: logs stay inside isolated services or instances, making correlation slow and incomplete.
• Metrics without alerts: dashboards look good in demos, but nobody is paged when error rates or latencies spike.
• Alerts configured but routed only to email lists that people do not actively monitor outside business hours.
• Audit logs (management and data access) disabled or not protected against tampering.
• No separation between production and non-production monitoring, causing either noise or gaps in visibility.
• Lack of runbooks or playbooks for handling common alerts like CPU saturation, database connection exhaustion or 5xx bursts.
• Security posture tools turned on (Security Hub, Defender for Cloud, Security Command Center) but findings are not triaged or assigned owners.
• Excessive sampling or filtering of logs that drops critical security and error information.
• Missing synthetic checks from user perspective (for example, HTTP probes to key endpoints) that detect external outages faster than internal metrics.

Governance and compliance controls tied to cost and change management

Choose the governance approach that matches your team maturity and regulatory obligations:

• Lightweight, tag-based governance – For small teams without strict regulations. Use naming conventions and tags (owner, environment, data classification, cost center) plus basic budget alerts and manual change approvals in tickets.
• Policy-as-code with guardrails – For growing organizations. Implement organization-level policies (AWS SCPs, Azure Policy, GCP Organization Policies) to block risky configurations like open storage or unencryped disks, and use infrastructure-as-code with mandatory reviews.
• Formal compliance framework aligned with LGPD – For regulated sectors or sensitive personal data. Map cloud controls to frameworks (for example ISO-based) and ensure DPO and security teams approve changes that impact personal data processing.
• Managed service or external consulting – When internal expertise is limited. Use experienced partners to set up baseline guardrails, continuous posture management and periodic reviews while your team gains skills.

Top deployment security concerns and clarifications

How strict should IAM be before the first production release?

Ensure there are no shared admin accounts, root or owner accounts are protected with MFA and application roles are limited to required actions. You can tighten fine-grained permissions iteratively, but fixing over-privileged admin access should not be postponed.

Do I need separate AWS, Azure or GCP accounts/projects for staging and production?

Yes, use separate accounts or projects per environment whenever possible. This limits blast radius, reduces accidental changes to production and makes access control and billing clearer.

Is encryption at rest mandatory if my application data is not highly sensitive?

Enable encryption at rest by default because it is a low-friction control and often required by clients or future regulations. Managed encryption usually has minimal performance impact and simplifies audits.

Which provider tools should I enable first for security posture visibility?

Start with AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center. These services give a consolidated view of critical misconfigurations and are a practical next step after running manual checklists.

How can I keep network rules from drifting after go-live?

Manage security groups, firewall rules and load balancer settings through infrastructure-as-code and pull requests. Add periodic scans and policy-as-code rules that block changes introducing new public exposure without review.

What is the minimum logging setup I should have before going live?

Centralize application logs, enable platform audit logs and configure alerts for error spikes and access anomalies. This provides enough visibility to investigate incidents and tune your monitoring over time.

When should I consider external cloud security consulting?

Consider external consulting if you process personal or financial data, lack in-house expertise or are planning a major migration. A short engagement can establish guardrails and checklists that your team then maintains.