AWS Cloud Development Kit (CDK)
AWS CDK is a software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation.
Use the AWS CDK to define your cloud resources in a familiar programming language.
Developers can use one of the supported programming languages to define reusable cloud components known as Constructs.
You compose these together into Stacks and Apps.
Other advantages of the AWS CDK include:
- Use logic (if statements, for-loops, etc) when defining your infrastructure.
- Use object-oriented techniques to create a model of your system.
- Define high level abstractions, share them, and publish them to your team, company, or community.
- Organize your project into logical modules.
- Share and reuse your infrastructure as a library.
- Testing your infrastructure code using industry-standard protocols.
- Use your existing code review workflow.
- Code completion within your IDE.
Amazon CloudWatch Logs
Monitor, store, and access log files from EC2 instances, AWS CloudTrail, Route 53, and other sources.
Centralize the logs from all of your systems, applications, and AWS services.
Enables you to view logs, search logs for specific error codes or patterns, filter logs based on specific fields, or archive logs securely for future analysis.
- Query Your Log Data – You can use CloudWatch Logs Insights to interactively search and analyze your log data.
- Monitor Logs from Amazon EC2 Instances – You can use CloudWatch Logs to monitor applications and systems using log data.
- Monitor AWS CloudTrail Logged Events – You can create alarms in CloudWatch and receive notifications of particular API activity as captured by CloudTrail and use the notification to perform troubleshooting.
- Log Retention – By default, logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a retention period between 10 years and one day.
- Archive Log Data – You can use CloudWatch Logs to store your log data in highly durable storage.
- Log Route 53 DNS Queries – You can use CloudWatch Logs to log information about the DNS queries that Route 53 receives.
Works with on-premises and AWS
Export to S3 possible with CreateExportTask – takes 21 hours.
Neal real-time or persistent logs use Kinesis Firehose.
Use Firehose for any Firehose supported destinations.
Real-time use Lambda or Kinesis Data Stream with KCL consumers.
Metric filer for scanning log data, generates a CloudWatch metric.
Subscription filters created for sending data to a subscriber.
AWS Service Catalog
AWS Service Catalog enables organizations to create and manage catalogs of IT services that are approved for AWS.
These IT services can include everything from virtual machine images, servers, software, and databases to complete multi-tier application architectures.
AWS Service Catalog allows organizations to centrally manage commonly deployed IT services, and helps organizations achieve consistent governance and meet compliance requirements.
End users can quickly deploy only the approved IT services they need, following the constraints set by your organization.
AWS Service Catalog supports the following types of users:
- Catalog administrators (administrators) – Manage a catalog of products (applications and services), organizing them into portfolios and granting access to end users. Catalog administrators prepare AWS CloudFormation templates, configure constraints, and manage IAM roles that are assigned to products to provide for advanced resource management.
- End users – Receive AWS credentials from their IT department or manager and use the AWS Management Console to launch products to which they have been granted access.
- A product is an IT service that you want to make available for deployment on AWS.
- A product consists of one or more AWS resources, such as EC2 instances, storage volumes, databases, monitoring configurations, and networking components, or packaged AWS Marketplace products.
- AWS CloudFormation templates define the AWS resources required for the product, the relationships between resources, and the parameters that end users can plug in when they launch the product to configure security groups, create key pairs, and perform other customizations.
- A portfolio is a collection of products, together with configuration information.
- Portfolios help manage who can use specific products and how they can use them.
- With AWS Service Catalog, you can create a customized portfolio for each type of user in your organization and selectively grant access to the appropriate portfolio.
- When you add a new version of a product to a portfolio, that version is automatically available to all current users.
- You also can share your portfolios with other AWS accounts and allow the administrator of those accounts to distribute your portfolios with additional constraints, such as limiting which EC2 instances a user can create.
- Through the use of portfolios, permissions, sharing, and constraints, you can ensure that users are launching products that are configured properly for the organization’s needs and standards.
- AWS Service Catalog allows you to manage multiple versions of the products in your catalog.
- This allows you to add new versions of templates and associated resources based on software updates or configuration changes.
- When you create a new version of a product, the update is automatically distributed to all users who have access to the product, allowing the user to select which version of the product to use.
- Granting a user access to a portfolio enables that user to browse the portfolio and launch the products in it.
- You apply AWS Identity and Access Management (IAM) permissions to control who can view and modify your catalog. IAM permissions can be assigned to IAM users, groups, and roles.
- When a user launches a product that has an IAM role assigned to it, AWS Service Catalog uses the role to launch the product’s cloud resources using AWS CloudFormation.
- By assigning an IAM role to each product, you can avoid giving users permissions to perform unapproved operations and enable them to provision resources using the catalog.
- Constraints control the ways that specific AWS resources can be deployed for a product.
- You can use them to apply limits to products for governance or cost control.
- There are different types of AWS Service Catalog constraints: launch constraints, notification constraints, and template constraints.
- With launch constraints, you specify a role for a product in a portfolio. This role is used to provision the resources at launch, so you can restrict user permissions without impacting users’ ability to provision products from the catalog.
- Notification constraints enable you to get notifications about stack events using an Amazon SNS topic.
- Template constraints restrict the configuration parameters that are available for the user when launching the product (for example, EC2 instance types or IP address ranges). With template constraints, you reuse generic AWS CloudFormation templates for products and apply restrictions to the templates on a per-product or per-portfolio basis.
Sharing and Importing Portfolios
To make your AWS Service Catalog products available to users who are not in your AWS account, such as users who belong to other organizations or to other AWS accounts in your organization, you share your portfolios with them. You can share in several ways, including account-to-account sharing, organizational sharing, and deploying catalogs using stack sets.
Before you share your products and portfolios to other accounts, you must decide whether you want to share a reference of the catalog or to deploy a copy of the catalog into each recipient account. Note that if you deploy a copy, you must redeploy if there are updates you want to propagate to the recipient accounts.
You can use stack sets to deploy your catalog to many accounts at the same time. If you want to share a reference (an imported version of your portfolio that stays in sync with the original), you can use account-to-account sharing or you can share using AWS Organizations.
When you share a portfolio using account-to-account sharing or AWS Organizations, you allow an AWS Service Catalog administrator of another AWS account to import your portfolio into his or her account and distribute the products to end users in that account.
This imported portfolio isn’t an independent copy. The products and constraints in the imported portfolio stay in sync with changes that you make to the shared portfolio, the original portfolio that you shared. The recipient administrator, the administrator with whom you share a portfolio, cannot change the products or constraints, but can add AWS Identity and Access Management (IAM) access for end users.
The recipient administrator can distribute the products to end users who belong to his or her AWS account in the following ways:
- By adding IAM users, groups, and roles to the imported portfolio.
- By adding products from the imported portfolio to a local portfolio, a separate portfolio that the recipient administrator creates and that belongs to his or her AWS account. The recipient administrator then adds IAM users, groups, and roles to the local portfolio. The constraints that you applied to the products in the shared portfolio are also present in the local portfolio. The recipient administrator can add additional constraints to the local portfolio, but cannot remove the imported constraints.
AWS Systems Manager
- Session Manager is a fully managed AWS Systems Manager capability that lets you manage EC2 instances, on-premises instances, and virtual machines (VMs) through an interactive one-click browser-based shell or through the AWS Command Line Interface (AWS CLI).
- Session Manager provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
- Session Manager also makes it easy to comply with corporate policies that require controlled access to instances, strict security practices, and fully auditable logs with instance access details, while still providing end users with simple one-click cross-platform access to your managed instances.
AWS Systems Manager Parameter Store
AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data management and secrets management.
You can store data such as passwords, database strings, Amazon Machine Image (AMI) IDs, and license codes as parameter values.
A Parameter Store parameter is any piece of data that is saved in Parameter Store, such as a block of text, a list of names, a password, an Amazon Machine Image (AMI) ID, a license key, and so on.
When you reference a parameter, you specify the parameter name by using the following convention.
Parameter Store provides support for three types of parameters: String, StringList, and SecureString.
You can store values as plain text or encrypted data.
You can reference Systems Manager parameters in your scripts, commands, SSM documents, and configuration and automation workflows by using the unique name that you specified when you created the parameter.
You can configure change notifications and trigger automated actions for both parameters and parameter policies.
You can tag your parameters individually to help you quickly identify one or more parameters based on the tags you’ve assigned to them.
You can associate an alias for versions of your parameter by creating labels. Labels can help you remember the purpose of a parameter version when there are multiple versions.
You can create parameters that point to an Amazon EC2 instance and Parameter Store will validate these parameters to ensure that it references expected resource type, that the resource exists, and that the customer has permission to use the resource.
Parameter Store is integrated with AWS Secrets Manager so that you can retrieve Secrets Manager secrets when using other AWS services that already support references to Parameter Store parameters.
AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources.
AWS accounts are natural boundaries for permission, security, costs, and workloads. Using a multi-account environment is a recommended best-practice when scaling your cloud environment.
AWS Organizations provides many features for managing multi-account environments, including:
- Simplify account creation by programmatically creating new accounts using the AWS Command Line Interface (CLI), SDKs, or APIs.
- Group accounts into organizational units (OUs), or groups of accounts that serve a single application or service.
- Apply tag polices to classify or track resources in your organization, and provide attribute-based access control for users or applications.
- Delegate responsibility for supported AWS services to accounts so users can manage them on behalf of your organization.
- Centrally provide tools and access for your security team to manage security needs on behalf of the organization.
- Set up Amazon Single Sign-On (SSO) to provide access to AWS accounts and resources using your active directory, and customize permissions based on separate job roles.
- Apply service control policies (SCPs) to users, accounts, or OUs to control access to AWS resources, services, and Regions within your organization.
- Share AWS resources within your organization using AWS Resource Allocation Management (RAM).
- Activate AWS CloudTrail across accounts, which creates a log of all activity in your cloud environment that cannot be turned off or modified by member accounts.
- Organizations provides you with a single consolidated bill.
- In addition, you can view usage from resources across accounts and track costs using AWS Cost Explorer, and optimize your usage of compute resources using AWS Compute Optimizer.
Best practices for the management account:
- Use the management account only for tasks that require the management account.
- Use a group email address for the management account’s root user.
- Use a complex password for the management account’s root user.
- Enable MFA for your root user credentials.
- Add a phone number to the account contact information.
- Review and keep track of who has access.
- Document the processes for using the root user credentials.
- Apply controls to monitor access to the root user credentials.
Service Control Policies
Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization.
SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines.
SCPs are available only in an organization that has all features enabled.
SCPs aren’t available if your organization has enabled only the consolidated billing features.
SCPs alone are not sufficient to granting permissions to the accounts in your organization.
No permissions are granted by an SCP. An SCP defines a guardrail, or sets limits, on the actions that the account’s administrator can delegate to the IAM users and roles in the affected accounts.
The administrator must still attach identity-based or resource-based policies to IAM users or roles, or to the resources in your accounts to actually grant permissions.
The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM and resource-based policies.
- SCPs affect only IAM users and roles that are managed by accounts that are part of the organization. SCPs don’t affect resource-based policies directly. They also don’t affect users or roles from accounts outside the organization.
- An SCP restricts permissions for IAM users and roles in member accounts, including the member account’s root user.
- Any account has only those permissions permitted by every parent above it.
- If a permission is blocked at any level above the account, either implicitly (by not being included in an
Allowpolicy statement) or explicitly (by being included in a
Denypolicy statement), a user or role in the affected account can’t use that permission, even if the account administrator attaches the
AdministratorAccessIAM policy with */* permissions to the user.
- SCPs affect only member accounts in the organization. They have no effect on users or roles in the management account.
- Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.
- If a user or role has an IAM permission policy that grants access to an action that is also allowed by the applicable SCPs, the user or role can perform that action.
- If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can’t perform that action.
- SCPs affect all users and roles in attached accounts, including the root user. The only exceptions are those described in Tasks and entities not restricted by SCPs.
- SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can’t be restricted by SCPs.
- When you disable the SCP policy type in a root, all SCPs are automatically detached from all AWS Organizations entities in that root. AWS Organizations entities include organizational units, organizations, and accounts.
- If you reenable SCPs in a root, that root reverts to only the default
FullAWSAccesspolicy automatically attached to all entities in the root.
- Any attachments of SCPs to AWS Organizations entities from before SCPs were disabled are lost and aren’t automatically recoverable, although you can manually reattach them.
- If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action.
You can’t use SCPs to restrict the following tasks:
- Any action performed by the management account.
- Any action performed using permissions that are attached to a service-linked role.
- Register for the Enterprise support plan as the root user.
- Change the AWS support level as the root user.
- Manage Amazon CloudFront keys as the root user.
- Provide trusted signer functionality for CloudFront private content.
- Configure reverse DNS for an Amazon Lightsail email server as the root user.
- Alexa Top Sites.
- Alexa Web Information Service.
- Amazon Mechanical Turk.
- Amazon Product Marketing API.Tasks on some AWS-related services: